It's Not the Plan; It's the Planning

Once developers are using agents on real work, the next failure mode appears. Teams jump to execution. The agent produces something. It’s not quite right. They prompt again. Still not right. They prompt a third time, get something workable, ship it, and conclude the agent did its job.

That workflow looks productive. It misses what the planning step would have caught.

We saw this play out concretely in one of our early team sessions. The team had picked a real backlog item — a new service to build out — and went straight from describing the feature to asking the agent to implement it. The agent produced something plausible. Halfway through, someone noticed it was missing a key architectural constraint. The agent rewrote the service. Then the next constraint surfaced. The agent rewrote it again. By the third rewrite, the team realized they’d skipped the part where they aligned on how the service should be built before letting the agent build it. The thirty minutes of planning they didn’t do cost them most of the session.

The lesson stuck. The team’s retrospective named it directly: collaborating on the plan was essential.

Code is the easy part now. Deciding what to write is the hard part. The leverage isn’t in how fast the agent produces code — it’s in how much thinking happens before the agent starts. Skip the thinking and you’ll get fast output that doesn’t fit the problem. Do the thinking and you’ll get less iteration, better fit, and code that integrates cleanly with what already exists.

Why planning matters more now

Pre-agent, planning happened in your head while you were typing. You’d start a function, realize you needed to refactor first, abandon the function, do the refactor, come back. The plan emerged through the act of writing. Thinking was bound to typing.

Agents break that binding. The agent writes code very fast, and it commits to an approach as soon as you ask. If your thinking hasn’t caught up to your typing speed, the agent runs ahead of you. By the time you realize the approach was wrong, you have hundreds of lines that need to be undone or rewritten.

The fix is short, focused thinking before code generation. Five or ten minutes that saves an hour. This isn’t a return to waterfall design — engineers have always benefited from “go slow to go fast.” What’s new is the cost of skipping it. The agent runs ahead of you faster than you can correct it.

Developer steering → The single highest-leverage habit is asking the agent to study the problem and propose a plan before writing any code. Three things to ask for: what’s the problem actually asking for, what are two or three possible approaches, and what are the trade-offs between them. You’ll catch most architectural mistakes here, when fixing them is free.

What developer-steered agents means

A particular workflow:

• The developer brings the intent: what’s being built, why, what constraints exist.
• The agent brings the implementation: code, tests, documentation, refactors.
• The developer steers: reviewing the plan, redirecting when off, catching mistakes early, asking for alternatives.
• The developer commits: the work is the developer’s, even though the typing wasn’t.

The developer is in the loop, but not for typing. They’re in the loop for judgment. Where to start, what trade-offs matter, when an approach is wrong, when to stop and rethink. Those are decisions the agent shouldn’t make alone.

This is different from “let the agent figure it out.” That’s fine for low-stakes throwaway work. It’s not how to operate on real production code.

What good planning looks like with an agent

A few patterns that make the planning conversation productive:

Start with context, not the task. Before you ask the agent to plan anything, give it what it needs to plan well. The relevant repos and documentation, the relevant existing patterns, the constraints that aren’t obvious from the code. We use this auth pattern, not that one. This service handles X, that one handles Y. The team’s convention for error handling is here. The agent’s plan is only as good as the context it has.

Ask for options. Two or three possible approaches with their trade-offs. The first plan an agent produces is rarely the best one — it’s the most obvious one. Asking for alternatives forces the agent to reason about the space, and forces you to make a choice you can defend.

Choose the pragmatic path explicitly. Once you have options, pick one and say why. We’re going with approach two because it reuses existing infrastructure and we don’t want to introduce a new dependency right now. Stating the choice explicitly anchors the agent for the rest of the session.

Adjust the plan before any code generation starts. This is where developer judgment directs the agent. Read the plan. Mark what you’d change. Push back on assumptions. The plan is cheap to revise. The code that gets generated from a bad plan is not.

Developer steering → A common mistake is treating the plan as a deliverable instead of a tool. The plan is for you. Use it to think clearly, then use it to communicate the change in source control, but don’t optimize the plan for someone else’s reading. Optimize it for clarifying your own intent.

Cognitive debt

Technical debt accumulates in code when you take shortcuts. Cognitive debt accumulates in your head when you stop fully understanding the codebase. It happens slowly. The agent writes code. You skim it. You approve it. Repeat for a couple weeks and your mental model of how the system works gets hazy. You can no longer reason about the system from first principles.

Planning is one of the main ways to fight it. When you make the agent walk through the problem before writing code, you’re forcing yourself to engage with the design at a level surface-skimming doesn’t reach. You’re rebuilding the mental model that typing the code used to build for you.

Watch out → If you find yourself approving PRs you couldn’t explain, you’re already in cognitive debt. Slow down. Spend more time in the planning conversation. Ask the agent to walk you through the trade-offs even on changes you’d normally skim.

Multiple sessions, one developer

Once a developer is good at planning, steering, and review, they can run more than one agent session at a time. That’s one of the larger productivity unlocks in the model.

The number you can sustain isn’t the number you can start. It’s the number you can steer well. Two is comfortable for most. Three is challenging. Four is probably too many. Routine work scales further than novel work. A developer running four agents poorly is not better than one who runs one well.