Shift Left Into Planning

Agentic coding has accelerated the part of software development that was already the fastest part. Writing code is quicker now than it's ever been. Deciding whether that code should get written — what to build, in what order, without colliding with something else already in flight — hasn't kept pace. That thinking still happens in someone's head, in a meeting, or not at all.

Shift left has meant the same thing every time I've watched a discipline stumble onto it: catching a problem closer to where it starts is cheaper than catching it after it's had time to compound. Testing shifted left. Security shifted left. Each time, the realization arrived the hard way — by paying for the alternative first, not by reading about it in advance.

That's the move still sitting on the table. Not agentic coding — I don't know a team at this point that isn't already doing some version of that. Agentic planning, done on purpose, as its own discipline: that's the part I haven't seen anyone actually stop and build.

What makes it agentic, not just planning

Most planning artifacts record decisions after people have done the reasoning — a doc, a ticket, a diagram somebody updates when they remember to. What I mean by agentic planning is putting the same reasoning capability that now writes the code to work one layer up: pulling in what's actually in the repos, the specs, the backlog, and reasoning across all of it to surface a collision or a missing dependency before anyone commits to a sequence. The discipline itself isn't new — architects and product leads have always done that synthesis in their heads, and the documents only ever captured the result.

What's new is having something that can participate in the reasoning itself, holding the whole picture in context at once instead of relying on one person's memory of every repo in flight.

This also answers the obvious objection that testing already shifted left. It did — and code review may catch a planning problem too. But both encounter it after implementation has already begun. Planning has a chance to catch it while changing the answer still costs almost nothing.

What planning actually needs that code doesn't

A single repository can be doing something narrow and correct and still add up to nothing anyone can picture. I can hand a stakeholder my source code and nothing resembling a vision comes out the other side. I can hand them a spec instead, and a spec is precise about a part, not legible about the whole. Planning needs a different altitude than any single repo is built to offer — no single repo is supposed to know about the others, and no single spec is supposed to explain why it exists relative to everything around it.

That altitude question runs the whole way down. It starts with something like an epic — what is this actually trying to accomplish — narrows into the features underneath it, narrows again into user stories, and only after that turns into engineering planning: does this need one spec or several, is a spec tied to one story or does it reasonably cover three. There's no fixed answer to that, and there shouldn't be — it's looked different on every team and every problem I've brought it to. What matters isn't getting the slicing right on paper. It's having a level where that thinking can happen at all, separate from the pressure of "we need code by Friday."

That same level is where reprioritization gets reasoned through, and it's where the case for doing this deliberately is strongest. A request comes in to pull a feature forward that was planned for much later. Fine — pull it forward. But now the real question shows up: what has to move with it? What does it depend on, and what needs to be at least partially built before pulling it forward is even viable? That's the kind of dependency thinking that belongs before code, not discovered halfway through a pull request, three engineers deep into a feature that turns out to need something nobody built yet.

The same level catches the small stuff before it becomes expensive, too — though the failure mode isn't usually as local as it looks. Rename a field in an API response or a database column, and the change can sail through code review clean while it quietly breaks a downstream report or another team's integration that nobody remembered depended on the old name. That's a planning problem wearing a testing problem's clothes: nothing in the diff was wrong, and nothing in the test suite was wrong either. The missing information wasn't in the changed repo. The dependency lived somewhere else.

Wide when the question is big, narrow when it isn't

Agentic planning creates an obvious temptation: give the agent everything, all the time, forever. It isn't that simple. The wide view earns its keep specifically during planning, when missing a collision between two pieces of work is expensive and reading broadly is worth the cost of reading broadly. Once a piece of work is scoped and ready to build, the context should narrow straight back down to the one thing being built — because at that point, staying wide isn't thoroughness anymore. It's just cost with nothing left to buy.

That narrowing pays off twice. It's cheaper, in the literal token-and-time sense. And it makes the question of which model or how much reasoning to spend on a given step worth actually asking, instead of defaulting to the biggest available option out of habit — planning work that has to hold several moving pieces at once earns the heavier reasoning; a well-scoped, already-understood build step doesn't.

Not a freeze, a rehearsal

None of this is about locking a plan in place and defending it. It's closer to the opposite — a space to imagine what the work could actually look like, unconstrained by what the code currently does, and pivot fast when that imagination turns out to be wrong. Planning isn't where uncertainty disappears. It's where being wrong is still cheap. When priorities shift, or a customer needs something nobody anticipated, or one piece of work quietly becomes worth more than another, that gets worked out at this level, separate from the code, until it's precise enough to hand off and just build.

Testing shifted left. Security shifted left. The principle was the same: find the expensive mistake while it's still cheap to change. What travels across all of them isn't any specific tool. It's the instinct: give planning a level of its own, wide enough to hold the whole picture when the question demands it, narrow enough to stay cheap when it doesn't.

Code is getting cheaper to produce — that's what agentic coding actually delivered. Which means deciding what code deserves to exist is becoming the more valuable skill, not the less important one. That part hasn't shifted left yet.

Explore More

• Why I Built DevSpark — the spec-driven discipline that agentic planning builds on top of
• Evolution over Revolution: A Pragmatic Approach — on scoping change deliberately rather than all at once
• Autonomy Guardrails: Bounding Agent Action Safely — the other half of giving agents more reasoning room: knowing where to stop it
• The Beaver Builds a Pond — a companion piece on reading what the environment is actually asking for before building