← Back to blog

Stop Asking Your AI to Do Everything at Once

Header image for Stop Asking Your AI to Do Everything at Once

I’ve been using Claude Code a lot recently, and I found something that made a surprisingly big difference to the quality of what it produces. It’s not a clever prompting trick or some exotic framework. It’s just: don’t ask it to do everything in one go.

When I want Claude to build something non-trivial, I’ve stopped saying “build me X” and started breaking it into separate steps:

  1. Create a high-level design for X
  2. Review that design and save the marked-up version
  3. Create an implementation plan based on the design
  4. Review the plan
  5. Now implement

The key breakthrough piece here is that I don’t just ask Claude to do all five things in one message, but instead have it do each one in a separate context, coming back to the output so far fresh for the next step.

Why bother?

Because if you ask Claude to design something and then immediately review its own design in the same context, it already knows what it meant. It’s reviewing with full knowledge of its own intent, so it’s much less likely to spot problems. It’s like proofreading an email you just wrote - you read what you meant to say, not what you actually said.

But if you take that design document and bring it into a fresh context and say “review this design” - now Claude is encountering it more like a reader would. It catches things. Ambiguities that were obvious-to-the-author but not obvious-to-anyone-else. Assumptions that weren’t stated. Edge cases that got hand-waved.

The difference in review quality is striking. Same model, same capabilities, but the fresh-context review consistently catches things that the same-context review misses.

This is not a new idea

Anyone who’s been in software engineering for a while will recognise this pattern immediately. We’ve been doing this with humans forever - it’s why we have code reviews, why we have separate test teams, why we get someone else to proofread the spec before we send it out. The whole point is that a different person, encountering your work without your context, will see things you can’t.

The twist is that with AI, you can get this “different perspective” benefit from the same model just by splitting things across context windows. You don’t need a different AI. You just need to stop the first one, take its output, and hand it to a fresh instance.

It’s a very cheap second pair of eyes. And third pair. And so on up to n.

Even for vibe-coding

I know what you’re thinking - “I’m just knocking something together, I don’t need a formal design process.” Fair enough. But even if you’re vibe-coding a quick prototype, try this: before you let the AI start writing code, ask it to spend one message creating a briefing describing what it’s going to build and how “that you could give to a new context to implement”. Then start a fresh context with that description and say “implement this.”

That tiny bit of separation (forcing the plan to exist as a document that has to make sense on its own, rather than as context the AI is already holding in its head) catches a bad approach before you’ve spent twenty minutes watching it code itself into a corner.

The “trick” that makes it work

The key insight is that each step needs to produce an artefact (a document, a design, a plan, an updated-reviewed-plan, whatever) that stands on its own. Not “think about the design and then start coding” but “write the design down, save it, and we’ll come back to it.” The artefact is what crosses the context boundary. It’s the thing that forces clarity.

This is exactly why, in the human world, we write things down rather than just talking about them. The act of writing forces you to be precise in a way that thinking-and-then-doing doesn’t. Same thing seems to apply to AI - the act of producing a readable document forces a quality of thought that “hold the design in context and keep going” doesn’t.

What I actually do

For anything beyond trivial changes (and increasingly for trivial changes!) my current workflow looks roughly like this:

  • Ask Claude to create a high-level design. Save it.
  • Fresh context: “Review this design. What’s unclear, what’s missing, what could go wrong?” Save the review. (Lather rinse repeat this step until Claude and I are both happy.)
  • Either iterate the design or move on. Ask Claude to create a low level detailed design from the reviewed design. Save it.
  • Fresh context: review the detailed design/plan. I sometimes ask it to run a devil’s advocate pass - “argue against this plan, what are the weaknesses?” Save your notes.
  • Then implement from the reviewed plan.

Is this slower than just saying “build me the thing”? Yes, a bit. But the implementation step goes much more smoothly because the thinking has already been done properly, and the end result is noticeably better. The total time is often about the same, sometimes less, but it’s just distributed differently and has less annoying debugging (yay!)

And as a bonus, you end up with a trail of design documents and decision records sitting in your repo. Which turns out to be incredibly useful later, but that’s a topic for another post.

The Bottom Line

Fresh context improves AI review quality dramatically. Split your work into steps that produce standalone documents, and review those documents in separate contexts. It’s the same principle as getting a colleague to review your code - except the colleague is the same AI with a cleared whiteboard.

You’ve been doing this with humans for years. Do it with your AI too.


Originally published on Edmund Pringle’s Substack. Follow Ed for more on software quality and engineering leadership.