Building in Pieces: Letting AI Slice the Work While You Set the Checkpoints

You’ve got a feature to build. Something real, with a few moving parts. Say you’re building a tool that lets tutors schedule sessions with students, and the feature you want next is “let a student book an open slot on a tutor’s calendar.” So you describe it to your AI assistant and say build it. And it does. A minute or two later there’s a pile of new code: a calendar view, a booking form, the logic that saves the booking, a confirmation message, maybe an email. It’s all there. You run the app, click through, and it mostly works. You feel like you just built a whole feature over a coffee break.

And then you find the thing that’s wrong. A booking saves even when the slot’s already taken, say, or the confirmation fires before the save actually finishes. Now you’re staring at a big block of freshly generated code trying to work out which of its several parts is lying to you, and none of it is code you watched get written. The careless version of this job isn’t asking AI to build a feature. It’s letting AI build the whole feature in one swing, so that when something breaks (and something always breaks) you’re debugging a finished thing you never saw assemble itself, with no idea which piece went wrong or when.

What this job actually is

Breaking a build into pieces is two jobs that look like one. The first is slicing the work: taking a feature and cutting it into a sequence of smaller steps, each one a buildable unit. That’s a decomposition problem, and AI is genuinely good at it. Hand it “let a student book a slot” and it can lay out the pieces cleanly: show the available slots, let the user pick one, validate that it’s still open, save the booking, confirm it. It can order those sensibly and tell you what each one depends on. That breakdown is real, useful work, and you should take it.

The second job is deciding how much of that sequence you actually build before you stop and check it works. Where does one chunk end and the next begin? After which step do you pause, run the thing, and confirm it does what you think before you pile more on top? That’s not a decomposition problem. It’s a judgment call about where you need proof, and it depends on which steps are risky, which are load-bearing, and which are the ones you’d hate to discover were broken only after you’d built three more things assuming they worked.

Here’s the distinction that matters: AI can generate the slices, but deciding where the checkpoints go is yours. A list of steps is not a build plan. The value of building in pieces comes from never getting far ahead of what you’ve verified, so that when something breaks you know it’s in the small thing you just added and not buried somewhere in a slab of code you accepted all at once. AI can cut the feature into steps perfectly and still have no idea where you need to stop and look, because that depends on what you’re worried about and what you can’t afford to get wrong, and AI doesn’t know either unless you tell it.

How to delegate the slicing

So lean on AI for the part it’s good at, which is the decomposition itself. The careless version is “build this feature,” which invites the one big swing. The good version asks AI to break the feature down first, before it writes anything, so you can see the shape of the work and decide how to take it on.

Describe the feature and ask AI to lay out the steps to build it, in order, smallest sensible units first, with what each step does and what it depends on. Ask it to be honest about which steps are straightforward and which ones are fiddly or easy to get wrong. Ask it to flag the places where a step could quietly fail in a way you wouldn’t notice just by clicking around. What you’re after is a clear, ordered map of the build, detailed enough that you can look at it and see where the risky moments are.

Then, and this is the move that makes it work, you build it with AI one chunk at a time, stopping where you decided to stop. You take the first slice, or the first couple of slices up to your first checkpoint, and you have AI build just that. You run it. You confirm it works. Only then do you go back for the next piece. You’re using AI’s breakdown as the plan and its speed to execute each step, but you’re the one deciding how far each step goes before you check.

What you don’t do is hand over the whole sequence and say build all of it. The moment you do that, the slicing you just got becomes decorative, because it all arrives fused together anyway and you’re back to debugging a monolith. Keep the ask on mapping and then on building one piece at a time. Show me the steps, then build me this much, and stop.

The judgment you keep

Where the checkpoints go is the call, and it’s yours because it turns on something AI can’t see: which steps you need to prove before you’re willing to build on top of them.

This is hard because AI’s breakdown will look so clean that the obvious move is to just let it run the whole thing, especially when the first few steps are easy and it’s flying through them. Stopping feels like slowing down for no reason when everything’s going well. But the checkpoint isn’t about doubting the easy steps. It’s about refusing to stack new code on top of a step you haven’t confirmed, because the cost of a hidden mistake grows every layer you add over it. The judgment is in looking at the sequence and deciding this step right here, the one where a taken slot has to actually get rejected, is a place I stop and prove it works before anything depends on it, while these other three steps can be built together and checked at the end. For the tutoring app, if the whole feature quietly falls apart when two students grab the same slot, then the “is this slot still open” step is a checkpoint you do not skip past, no matter how boring the surrounding steps make it look to stop there.

AI can’t make this call because it doesn’t know what you’re afraid of. It can tell you the steps and even which ones are technically tricky, but it can’t weigh which failure would be a two-minute fix versus which one would rot silently under a week of new code, because that weighing depends on how the pieces of your app lean on each other and what you can’t afford to have quietly broken. Get this wrong and you build fast right up until you don’t, and then you pay it all back at once, digging through a mountain of accepted code trying to find the floor that was never solid. The checkpoints are what keep every bug small enough to catch the moment it happens.

Before you ship this job

Here’s what good delegation looks like, and the line it can’t cross.

The sample prompt. Something real you might send:

I’m building TutorSlot, an app where students book sessions with tutors on the tutor’s open calendar slots. My main user is someone like Aisha, a tutor with about twenty regular students who currently arranges everything over text and constantly double-books herself. The feature I want to build next is letting a student book an open slot. Before you write any code, break this feature down into the smallest sensible steps to build it, in order. For each step, tell me what it does, what it depends on, and whether it’s straightforward or fiddly. Especially flag any step that could fail quietly in a way I wouldn’t catch just by clicking through the app (for example, two students booking the same slot at the same time). I want the ordered map first so I can decide where to build carefully and where to check my work. Don’t build anything yet; just give me the breakdown.

Use this and you get a plan you can build against in controlled pieces. Copy it as-is and you’re chunking TutorSlot’s feature instead of yours, and worse, you’ve skipped the part that was yours to do. Aisha’s dangerous step is the double-booking; your feature’s risky moment sits somewhere else, and the breakdown only helps if you’re the one deciding where to stop and prove it.

The part you can’t hand off is where the checkpoints go: deciding after which steps you stop, run the thing, and confirm it works before you let anything build on top of it, judged against which steps would hurt most if they broke quietly. That placement is the decision, and it’s the thing the prompt above deliberately doesn’t ask AI to make.

How to check AI did its part: before you build a single line, take AI’s breakdown and try to point at the step where the feature would most likely break in a way you couldn’t see by clicking around. If you can find it in the list (the concurrent-booking step, the step that saves before it validates), the breakdown is detailed enough to plan your checkpoints from. If every step reads as equally safe and you can’t locate a single risky moment, the breakdown is too smooth to trust; it’s hiding the exact steps you most need to stop and verify, and you send it back and ask specifically where this could fail silently. A build plan with no visible risky step isn’t a plan, it’s a to-do list that’ll let you sail right past the thing that breaks.

What you get for doing it this way

Go back to that pile of freshly built code and the small dread of finding the thing that’s wrong inside it. The difference between letting AI build the whole feature in one swing and building it in checkpointed pieces is the difference between debugging a finished mystery and catching each mistake the moment you make it. When you let AI slice the work and you decide where to stop and check, every bug you hit lives in the small thing you just added, which means you find it in minutes instead of excavating for it, and you never end up standing on a floor you never confirmed was there.

AI can cut any feature into clean steps and build each one as fast as you can read. Where to stop and make sure it actually works before you keep going was always your call, because only you know which pieces you can’t afford to get quietly wrong. That’s the job: let AI slice the work as fine as it likes, then decide for yourself how much to build before you look.