How to Build Software with AI | Ep 4: Think in Slices

Transcript

The full word-for-word transcript of this episode. Plain text version

Marcus: When you set out to build a massive project, well, I mean, the absolute most natural human instinct is to plan the entire cathedral up front.

Devon: Right, you want the grand design.

Marcus: Exactly. You want the sweeping blueprints, you know, every single spire mapped out in your mind before you lay a single brick.

Devon: It feels like the responsible thing to do.

Marcus: It does. But when you're using a coding AI to build software, leaning into that instinct is incredibly dangerous.

Devon: It really is.

Marcus: Because a coding agent will happily hand you a stunning, entirely convincing cathedral in a single afternoon.

Devon: And it looks brilliant, at first.

Marcus: Right. But it's only weeks later that you realise it's a mere film set. I mean, you've got beautiful facades, perfectly painted doors, and absolutely no plumbing behind them.

Devon: It's the perfect delusion of progress, isn't it?

Marcus: It really is.

Devon: And it's exactly why so many beginner projects collapse under their own weight. You see, the common story we tell ourselves is that if you map it all out, you're being responsible.

Marcus: You're being thorough.

Devon: Exactly. But the reality is, when you ask an AI for a cathedral on day one, you get that Hollywood film set, and you have absolutely no idea how to turn those fake wooden fronts into a real, functional building.

Marcus: And that's exactly the problem we're tackling in this deep dive into the source material.

Devon: Which is part four of the ten-part beginner series on building software with AI for non-coders.

Marcus: Spot on. So, just to recap where you, the listener, are on this journey based on the previous materials, we've established your fundamental job, which is to decide, brief, and verify.

Devon: Right.

Marcus: We set up your working pattern, so that's separating the planner you talk to from the builder that actually writes the code.

Devon: While you stand at the gates, holding them to account.

Marcus: Yes, exactly. And we even built your memory system, which is that project handbook, because, as we know, these agents forget absolutely everything the moment you close the browser window.

Devon: They have zero object permanence.

Marcus: Literally none. So, you have the tools and you have the rules of engagement, but the immediate, glaring danger becomes what you actually choose to build first.

Devon: Precisely. And the most tempting approach, that grand cathedral we just mentioned, is guaranteed to fail.

Marcus: It is a trap.

Devon: A massive one.

Marcus: Yeah.

Devon: To understand what you should build instead, we really have to look at the underlying mechanics of why beginners fall into this trap in the first place.

Marcus: I love how the source material handles this. They use a rather brilliant analogy about two neighbours renovating houses on the same street.

Devon: It perfectly captures the emotional toll of building.

Marcus: It really does. So, they have the exact same budget, the same ambition, and in both cases, well, the entire house needs doing.

Devon: Every single room.

Marcus: Right. So, let's look at the first neighbour. They decide to go with the entire house everywhere at once.

Devon: The cathedral approach.

Marcus: Exactly. So, in week one, the carpets come up in every single room, the wallpaper gets stripped in the hallway...

Devon: The kitchen is half pulled out.

Marcus: ...the bathroom tiles are smashed to bits, and six months later, there is not one single finished room in the house.

Devon: It's just a nightmare to live in.

Marcus: You've got plaster dust in your tea, dinner happens on a camping stove in the living room, every room you walk into is a reproach.

Devon: A physical reminder of work undone. And eventually, the project just quietly stalls, because, honestly, who has the heart for that kind of relentless chaos?

Marcus: Exactly. The emotional economics of that approach are completely ruinous. You just burn out.

Marcus: You do. But the second neighbour takes a completely different path.

Devon: They pick the small bedroom.

Marcus: Just that one tiny room. And they take it the whole way.

Devon: They strip it, they rewire the electrics, they plaster, they paint.

Marcus: They put the carpet down, hang the curtains, and move the furniture back in.

Devon: And then the door closes on a completely finished room. And crucially, along the way, they learn incredibly valuable lessons. They discover that the plastering took twice as long as the tradesman quoted.

Marcus: Or, even more importantly, they might pull off the skirting board and find damp behind the wall.

Marcus: Yes. And they find it early, while it's isolated to one small room, and it's still relatively cheap to fix.

Devon: Which means every subsequent room benefits from the lessons of that first small bedroom.

Marcus: And if life interrupts the project, say, money runs low, or your enthusiasm simply runs out, they still live in a house with finished rooms.

Devon: Rather than a permanent building site.

Marcus: Right. It's a huge difference.

Devon: And software has exactly the same two shapes. The cathedral approach, the first neighbour ripping up all the carpets at once, is the ultimate trap.

Marcus: So, why do beginners always start there?

Devon: Well, it's because when you don't know enough to design a system well, you assume the solution is just more planning. You think if you just map out every single screen...

Marcus: ...every notification bell, every settings toggle...

Marcus: ...you think you'll somehow avoid mistakes. But the cheapest teacher in software development is a small, working thing. Blueprints teach you almost nothing until something real actually exists in the world.

Devon: Because reality is where you discover the damp behind the wall in your software.

Marcus: Precisely.

Devon: And here is where it gets both horrifying and, well, highly amusing. AI makes this trap incredibly seductive.

Marcus: It completely removes the friction.

Marcus: Exactly. In traditional software development, if you wanted to build a cathedral, you had to physically type the code yourself, which was exhausting...

Devon: ...and expensive.

Marcus: ...very expensive. That natural friction naturally kept things small. But with an AI agent, you don't have that. You say, "build me a project management suite," and it literally says, "certainly."

Devon: Yes, the agent can generate screens, gorgeous menus, buttons, and visual structure instantly.

Marcus: It looks like astonishing progress.

Devon: Right, it really does. But remember how software actually works. The visual surface of an application does not reveal the internal mechanics.

Marcus: You're just looking at facades.

Devon: Exactly. None of those beautiful buttons actually talk to a database. None of those sleek menus route data correctly through a server.

Marcus: The AI is basically drawing you a picture of an app.

Devon: A very convincing picture, but yes. Every real, complex engineering problem is now hidden somewhere inside a vast, half-built everything.

Marcus: Which has a real, tragic human cost attached to it. A beginner can pour six weeks into this fake cathedral...

Devon: ...working on it every night.

Marcus: Right. They show their friends on their phone, they click around the menus, they feel like an absolute genius.

Devon: Uh-huh.

Marcus: And then, around week six, the motivation just quietly dies.

Devon: Because they finally try to make the data actually save.

Marcus: Or they try to make the user accounts securely log someone in, and the entire fragile film set just shatters.

Devon: It turns out none of the pieces were actually plumbed together.

Marcus: And worse, they've lost their most important safety mechanism.

Devon: The gate.

Marcus: Yes, the gate. If you recall from our earlier discussions in this series, we defined verify as checking the work with your own eyes and in under a minute.

Devon: A crucial habit.

Marcus: But if you ask an agent to build a massive, sprawling app in one go, you physically cannot verify it.

Devon: No, you can't verify everything. It's impossible.

Marcus: The cathedral makes your most crucial habit impossible to perform.

Devon: It structuralises failure. So, if the cathedral destroys our ability to verify, and it kills our motivation, what's the alternative? How do we force reality to exist from day one, so we don't end up with a dusty building site?

Devon: The antidote is what the software industry calls the vertical slice.

Marcus: The vertical slice.

Devon: Yes. It's defined as the thinnest complete path through the whole system that a real person could actually use from end to end.

Marcus: Okay, those two words seem paramount here: thin and complete.

Devon: They are everything.

Marcus: Right, let's really unpack that, because it sounds simple, but the mechanics in the sources are very strict. What does thin and complete actually look like in practice?

Devon: Thin means one single path. Not five features, not three variations for different types of users, just one route.

Marcus: Got it.

Devon: And complete means it goes all the way through the underlying technology stack.

Marcus: So, from the screen all the way to the back.

Devon: Exactly. The user performs the action on the screen, the system processes it, stores it in a real database, and retrieves it.

Marcus: Everything along that route is real. Nothing is faked, mocked up, or painted on.

Marcus: The source material uses a to-do list app as the concrete example here, which I think is great, because everyone knows what a to-do app is.

Devon: It's the classic starter project.

Marcus: Right. So, the cathedral version of a to-do app, the one we all naturally want to build, has user accounts...

Devon: ...sharing capabilities with colleagues...

Marcus: ...daily email reminders...

Devon: ...colour-coded categories...

Marcus: ...a bespoke mobile layout, you know...

Devon: ...a massive undertaking. But the vertical slice version is brutal in its simplicity.

Marcus: How brutal?

Devon: The very first slice of that project is exactly this: you type a task, you save it, you close the app entirely...

Marcus: Okay.

Devon: ...you open the app again, and the task is still there.

Marcus: And that's it?

Devon: That is it.

Marcus: No accounts, no reminders?

Devon: None.

Marcus: Okay, I have to push back here.

Devon: Go on.

Marcus: Because I'm speaking on behalf of everyone listening who wants to actually enjoy this process.

Devon: Fair enough.

Marcus: Building a to-do list that just remembers a single task sounds incredibly joyless. I mean, painfully slow.

Devon: It does sound mundane, I grant you.

Marcus: The entire appeal of using AI tools to build software is the magic of it. We want to see something brilliant appear on the screen.

Devon: The speed.

Marcus: Yes, the speed. Where is the fun in something so unbelievably plain? It feels like you're telling someone who just bought a sports car that they're only allowed to drive it at ten miles an hour in an empty car park.

Devon: I completely understand the frustration.

Marcus: Mm-hmm.

Devon: But you have to distinguish between fake momentum and real momentum.

Marcus: Fake momentum.

Devon: Yes. The fast-looking cathedral is a trap that leads to project death.

Marcus: Yeah.

Devon: True momentum in software doesn't come from how many pretty screens you can generate in an afternoon.

Marcus: What does it come from then?

Devon: It comes from proving that the route actually connects.

Marcus: Wait, so when you say proving the route, you mean the physical journey of the data?

Devon: Exactly. Surprises and errors in software live at the joins.

Marcus: The joins.

Devon: Yes. The joins are the places where one piece of technology hands data over to another piece.

Marcus: Ah, okay. So, from the physical keyboard to the user interface to the back-end logic to the database storage and back again.

Devon: Right. Proving one unimpressive slice saving that single task means you've proven that the interface, the saving mechanism, the storage database, and the retrieval system actually connect.

Marcus: You've forced every single join to exist.

Devon: And to work, on day one, while the project is tiny and the problems take seconds to fix.

Marcus: Ah, I see. So, the joy doesn't come from the visual magic of a dozen screens.

Devon: No.

Marcus: The joy comes from the absolute certainty that the foundation is solid. You're proving the plumbing works before you build the rest of the house.

Devon: Precisely. Builders of serious systems, systems with real security, real databases, real users, always prove that one single record can make a complete round trip before they add a single additional feature.

Marcus: That makes total sense.

Devon: They send a piece of data in through the front door, watch it travel through all the machinery, and make sure it comes back out the other side as the correct answer.

Marcus: And once you prove that path, the rest of the build feels almost boring, in the best possible way.

Devon: Widening a proven path is calm, predictable work. Laying a new path underneath a half-built cathedral is absolute chaos.

Marcus: It goes right back to the finished rooms analogy.

Devon: Exactly.

Marcus: If life interrupts your project on week two, you return to a working thing, not a dusty building site.

Devon: You have a genuinely finished room.

Marcus: And you have your verify habit completely intact. A vertical slice is the natural size of a brief. It ends at a gate you can actually check with your own eyes in under a minute. But, and this is a massive but...

Devon: Here we go.

Marcus: ...once you start building that thin slice, you're going to face the single greatest threat to keeping it thin.

Devon: The incredibly seductive whisper of "while we're at it."

Marcus: Scope creep.

Devon: The quiet, deadly growth of a project.

Marcus: It's hilarious how human this is, because we've all seen it in the flesh. It's the kitchen renovation again.

Devon: You decide to refit the cabinets.

Marcus: Then you look at the wall and think, "well, while the builders are here, we might as well knock through that wall to open up the space."

Devon: Naturally.

Marcus: But then you need new flooring to match the knocked-through room, then you look at the hallway flooring...

Devon: And suddenly you're redesigning the entire ground floor.

Marcus: And remortgaging the house. Nobody ever sits down and deliberately decides to double the scope of a project. It creeps, one entirely reasonable sentence at a time.

Devon: And AI turbocharges scope creep to an alarming degree.

Marcus: Oh, absolutely. Think about traditional software development. If you ask a human developer to add a feature mid-build, what do they do?

Devon: They sigh.

Marcus: They suck air through their teeth.

Devon: And they pull up a spreadsheet to tell you exactly how much extra it will cost and how many weeks it will add to the timeline.

Marcus: There's friction. And that friction makes you consider if you really need the feature. But with AI, adding a massive feature costs exactly one sentence.

Devon: The agent never sighs.

Marcus: It never sucks air through its teeth.

Devon: You just casually say, "actually, let's make the tasks colour-coded based on urgency," and the AI says, "certainly, I've updated five files."

Marcus: Every grand idea sounds completely free.

Devon: But it's not free.

Marcus: It's incredibly expensive in terms of complexity. Every addition makes your current slice wider, it makes your brief vaguer, and it makes your gate harder to hold.

Devon: You stretch the thin slice until it snaps.

Marcus: And you're back in the cathedral trap.

Devon: So, how do we fix it?

Marcus: Yeah.

Devon: Because telling people "just don't have good ideas" isn't going to work. When you're in the flow, brilliant ideas pop into your head constantly.

Marcus: The source material provides a polite, organisational fix.

Devon: I love this bit.

Marcus: It's arguably the most powerful sentence in software development.

Devon: "Not in this slice."

Marcus: "Not in this slice."

Devon: I genuinely love that. It's not a rejection, it's just a boundary.

Marcus: Exactly. You aren't killing good ideas, you're actively managing them. The workflow is simple. You park the idea on a written list.

Devon: The parking list.

Marcus: Yes. You keep a literal document in your project handbook called the parking list, and you tag that new idea as specified.

Devon: Right, tying it back to our tags from the previous deep dive. Specified means it's a wish with paperwork.

Marcus: It exists, it's documented so you won't forget it, but it absolutely isn't being built yet.

Devon: That's the key mechanism. You park the idea where it can't cause damage to the current build.

Marcus: You finish the thin thing first, the good idea waits its turn in writing.

Devon: And as you complete these thin slices, you naturally start grouping them into milestones to track your progress.

Marcus: But the sources are very strict about what actually counts as a milestone.

Devon: It's not just a vibe check.

Marcus: Not at all. A milestone must be something you cannot argue with. You have to phrase them as statements that are empirically true or false.

Devon: Give me an example.

Marcus: "I've used this to-do app every day for a week" is a valid milestone.

Devon: Because it's a fact.

Marcus: Exactly. It proves the app is stable enough for daily use. You can't fake that.

Devon: Whereas something like "60% of the screens exist" is completely fake progress.

Marcus: Because a film set has screens.

Devon: Right. Generating visual assets proves absolutely nothing about the underlying engineering. A true milestone is just the verify habit scaled up to a larger level.

Marcus: All right, so we understand the slice, we understand the absolute necessity of proving the joins, and we know how to defend against scope creep with the parking list.

Devon: Yes.

Marcus: How do we actually execute this in the AI tools we're using? Because the sources specifically bring up Claude Code and Codex.

Devon: The mechanism that makes this work in those specific tools is the concept of a planning mode.

Marcus: A planning mode.

Devon: Yes. These tools handle the slice brilliantly by enforcing a strict separation between the thinking phase and the doing phase.

Marcus: Let's start with Claude Code, because I think the way it operates illuminates the whole concept really well.

Devon: Claude Code features a setting literally called Plan Mode.

Marcus: And what does that do?

Devon: When you switch this on, it restricts the agent to reading and investigating your project.

Marcus: It is physically locked out of changing your code.

Devon: Exactly. It explores your files, asks you clarifying questions about the slice you want to build, and then produces a step-by-step plan in plain English.

Marcus: And mechanically, why is locking it out so important?

Devon: Because large language models are probabilistic.

Marcus: Right, they guess.

Devon: They predict the next most likely word or line of code based on patterns. If you let an AI start writing code before the underlying logic of the whole slice is perfectly sound, it will literally hallucinate connections that don't exist.

Marcus: It will write code that calls for databases it hasn't built yet.

Devon: Exactly. Plan Mode prevents that by forcing the AI to establish the logic in plain English first.

Marcus: And you must approve that text plan before any code changes are made.

Devon: It physically forces you to hold the gate.

Marcus: It stops the agent from running off and enthusiastically building a cathedral while you aren't looking.

Devon: Exactly that.

Marcus: And Codex handles this in a very similar fashion, doesn't it?

Devon: It does. It has its own plan mode, explicit approval settings, and read-only settings.

Marcus: So, you can have a pure, exploratory planning conversation, thinking out loud with the agent, while it's safely locked away from the actual codebase.

Devon: Which means we can synthesise all of this into a universal rhythm for building.

Marcus: A repeatable loop.

Devon: A loop that you use for every single vertical slice.

Marcus: Let's walk through that loop. Step one.

Devon: Step one: name the slice. Keep it simple, like "save one task."

Marcus: Step two.

Devon: Ask the agent for the plan.

Marcus: Step three: read that plain English plan and fix any misunderstandings.

Devon: And fixing it at step three is a breeze, because it only costs one sentence to correct a plain English document.

Marcus: Right. If you wait until it's written the code, you're trying to unpick a tangled mess of interconnected logic, which takes hours.

Devon: Exactly. So, step four: approve the plan.

Marcus: Step five: unlock the agent and let it build.

Devon: Step six: verify the result with your own eyes in under a minute.

Marcus: Step seven: update your tags. Move the slice from specified to built, and eventually to live.

Devon: And finally, step eight: move to the next slice on your parking list.

Marcus: That rhythm is the whole secret, isn't it? That loop is what keeps the momentum real rather than fake.

Devon: It completely transforms the experience from chaotic, stressful hacking...

Marcus: ...where you're constantly terrified of breaking things...

Devon: ...into calm, predictable progress.

Marcus: The guarantee is that you're always moving forward from a position of strength.

Devon: You always have a working system.

Marcus: You always have finished rooms.

Devon: This changes the entire philosophy of approaching a big project. You aren't actually building a massive thing.

Marcus: No, you're repeatedly building tiny, complete things until they aggregate into a massive thing.

Devon: And crucially, it protects your time, your energy, and, most importantly, your motivation.

Marcus: The graveyard of beginner software projects is filled entirely with grand cathedrals.

Devon: It really is.

Marcus: The economics here are emotional just as much as they are technical. Finished rooms pay you back with a sense of pride every time you look at them.

Devon: Building sites just charge rent on your mental bandwidth until you give up.

Marcus: Well said. Which brings us to the takeaway for this deep dive. We always want to leave you with a concrete challenge, something you can apply immediately to your own project to cement this knowledge.

Devon: Take a look at the brief you created from our earlier steps in this series.

Marcus: And then...

Devon: I want you to write the very first slice of that project in exactly one sentence.

Marcus: Just one single sentence.

Devon: Then test it ruthlessly against the rules we've discussed. Is it thin?

Marcus: Does it represent one single path through the app?

Devon: Is it complete? Does it go all the way through the system with absolutely nothing faked?

Marcus: And, most importantly, can you verify it with your own eyes in under a minute?

Devon: And once you have that single sentence nailed down, start your parking list.

Marcus: Write down three things you are deliberately avoiding in this first slice. Three features that sound incredibly fun, but firmly belong in a future update.

Devon: Tag them as specified.

Marcus: I want you to experience the sheer relief of parking a good idea instead of letting it ruin your focus.

Devon: The profound calm you feel when you do that. That's the vertical slice working.

Marcus: Think about that single task you just saved in your hypothetical slice. You typed it in, you hit save, you closed the app entirely, and the next day you opened it, and your task was magically still there. But where, exactly, was it sitting in the dark while your computer was physically switched off? Next time, we're going to explore the filing cabinet at the absolute heart of all software. But until then, ask yourself: how much do you actually know about where your digital life is physically kept?