I'm increasingly convinced that pushing towards single-prompt "one-shot" solutions leads to the best throughput with AI coding, today.
This means no plan mode, no swarms, no multi-step agents.
This is based on one primary driver: to get the greatest throughput you need to be executing as many parallel execution paths as possible. To maximize this you need the fastest iteration possible[1]. Instead of trying to personally drive the AI towards the right outcome, I'm spending my time making changes that enable the AI to complete tasks in a single-prompt[2].
Why
For the most part, I'm the bottleneck. This means the fewer "touches" I have to get something shipped, the better. My endgame is "zero to one" touches of the code after prompting.
I alluded to the core reasoning on this in my short on infinite monkeys. In my experience, AI coding tasks have a bimodal "U-shaped" distribution. They will either tend to land quickly and correctly; or go sideways. And the ones that go sideways take a disproportionate amount of my time... and by implication, wall-clock time.
The primary reason for this distribution is the context. If you hit the context limit, quality can (will) drop dramatically. You may know that sinking feeling when Claude Code starts "compacting".
Multi-agent swarms can make this worse. Each handoff and interaction is the opportunity for "drift". If the overall direction is off, this will compound, and quickly[3]. It's a little like a scaled-up version of the Mythical Man Month.
Single-prompt one-shot outcomes are faster and clearer. Thus in my view easier to optimize.
This isn't to say it's not possible. What I would argue strongly is that Claude Code absolutely crushes tasks that fit neatly in its capability and context. This is the sweet spot I'd like to hit repeatedly and consistently.
How
Easy to say, hard in practice: Make it easier for the AI to get it right first time.
I aim for "Working Software" from each prompt[4]. Then the challenge is on you to keep the machine fed. In practice there are three major levers:
-
Fit in the context: Better Prompts, Stupid.
You need to learn the limits of your context and what works best. Decomposing tasks to a particular domain like Frontend or Backend is an obvious one. -
Get more out of the context[5]: Guides not Plans.
If you're building a plan, step back and see how the plan could be obvious. This could be structuring the codebase around domains, having template "gold" patterns to point the AI at, or having more compound skills. -
Do as much as you can in parallel: Manage WIP.
Each "thread" of delivery could be slower wall-clock time, but the implication is you can run more in parallel. To realize these benefits, you need to really maximize the number of threads. This means decomposition is on you. Managing WIP is the key; I spend almost half the time "sharpening the axe" which includes my own tooling to manage WIP. You need to be the multi-headed product manager hydra.
All of these are difficult or an investment in their own way. The good news is they are multiplicative. The better news is they're beneficial no matter what approach you prefer.
But... Plans
I was a heavy user of plans and specs and I've reduced this dramatically in favor of investing in the "How" items.
But why plan? The two reasons I hear cited the most are (1) to make sure certain steps are done and (2) to confirm the AI understands the problem.
On the first point, if the task is sufficiently complex, the plan will eventually degrade. Either the AI starts to get a bit lossy, or the plan will be shown to be incomplete as the task evolves. Either way, you end up managing the plan rather than the task and in my experience that's a losing (or at the very least frustrating) battle.
The second is more subtle. Some engineers favor an interview approach. I think this has plenty of merit, but I do it elsewhere and not "right next to the coding". In the end I've found pushing myself to not use plans with Claude Code has led to an overall better setup.
To put it in much softer terms; there are investments you can make to minimize or eliminate planning work. These are well worth it.
Caveats and Commentary
If I haven't caveated enough, here is a section on it.
Vibe Coding and Exploration: This is absolutely not true for vibe coding. If you're experimenting with what you even want to build then you need to stay in dialog with the AI. In this case the goal isn't straight line throughput, it's ideation and iteration. Subagents are terrific here, no question. Plus, this approach is a major investment in the infrastructure of your codebase, and it's definitely not warranted in the ideation phase.
Task Selection: Fine, yes. Some tasks simply are just "big", complex, unwieldy, or simply don't fit this model. Here I might regress to a plan, or use something like a comment-only prompt. I might even opt to code it myself (!) to keep my skills sharp. In some ways being really aware of this gear-change is an advantage. It's explicit. I don't get frustrated by a task that unexpectedly explodes my afternoon.
Be prepared to throw software away: If a prompt fails and goes off track, I'm willing to ditch the outcome and start again with a better input. Could be a different or smaller prompt (usually), or investing in templates/examples to get a better outcome.
Drop DRY: Be prepared to repeat code. If it works, it works. You're better off delivering the software and refactoring later. The bad news is you need to be on top of it. The good news is this type of refactoring is a really great task for AI. It's something you can throw in the mix once you've proven out your feature.
Low Dogma: A prompt that requires a nudge or a quick smoke test is fine. Despite the distribution, there are plenty that fall in near the margins. I count that as the cost of understanding and expanding the limits of what I can get done.
On Being Wrong (Eventually)
For the record, I already break my rule in one particular way - I use GitHub Copilot for reviews. It's great at it and provides a counter-balance to otherwise heavy use of Claude Code[6].
Highly capable agents tuned to things like reviews and security will eventually be hard to ignore. Agent frameworks are improving fast, and the compounding-error problem will get better as models get more capable. Improvements to context sizes, memory, and multi-step artifacts could be dramatic. That said, they also benefit single-prompt scenarios in lots of useful ways.
Addy Osmani's writeup on Claude Code swarms and the Compound Engineering methodology show how multi-agent is becoming mainstream. But even Addy's advice is: "If a single agent in a focused session gets you there faster, use that." I agree - just make it as fast as you can.