Agentic development
An agent can hold far more of a codebase than we can. So instead of assembling software one finished part at a time, we rough in the whole product at once — then ground it, pass by pass. It's a different way to build, and a faster one.
For decades we built software brick by brick, because that is what human attention forced on us: hold one piece in mind, finish it, move to the next — and see the whole product only when the last part is laid.
Agentic development removes that limit. An agent can read and manipulate far more of a codebase at once than any person can, so it can rough in the entire product in a single sweep — every panel and screen, roughly in place. The first pass hands you the whole thing, but ungrounded: the panels exist, yet the numbers inside them are placeholders that don't mean anything yet.
First the structure settles. Then the real numbers arrive. Then the signals that tie them together — trends, deltas, states. The unit of work isn't a finished part; it's a pass over everything.
Why it's faster
The slow part of the old way was never the typing — it was finishing and integrating each part in isolation before anything worked together. Grounding the whole at once collapses that. A usable, roughed-in product exists on pass one, feedback starts on day one, and the rough whole comes together fast — because every pass refines something that already hangs together.
A different axis
This isn't agile's thinner slices either — those are still parts arriving over time. The whole product is present from pass one. What changes is how grounded it is.
The old axis
How much of the product exists yet. Each piece is fully real, but the whole stays invisible until coverage reaches 100%. "Early" can only mean partial.
The new axis
Coverage is pinned at 100% from pass one. What moves is how real the already-whole thing is — and moving up it quickly is the whole win.
Frame by frame
Step through it. Nothing is added — the same whole dashboard simply becomes real, a layer at a time.
Who it rewards
An ungrounded whole is genuinely ambiguous. The same rough first pass can be on its way to something sound — or to something subtly wrong that merely looks like a finished product. Which one it becomes depends on how it's handled while it's still soft.
Experienced developers don't just predict where the blur is heading — they push it there. They've built this kind of thing before, so they know which broad strokes to lay first, and where, shaping the rough whole so it grounds into something coherent. And they feel a bad trajectory while it is still cheap to redirect. That is what turns the whole-first method into a capacity multiplier: they can carry many roughed-in products and steer each one toward done with confidence.
Juniors can't work the blur the same way yet. They don't have the priors that tell them which strokes the rough whole needs, and the blurriness hides the gap: a plausible-looking rough pass reads as "fine," so a wrong path gets accepted and grounds across the entire product before its flaws surface — which is exactly when fixing it is most expensive. The result is rework, or starting over.
There's a structural reason it lands harder on them. Brick by brick had a built-in safety rail: you couldn't move on until each piece was actually finished and correct, so mistakes were caught locally. The whole-first method removes that rail — a wrong direction can be present everywhere at once and still look plausible. The judgment to lay the right strokes yourself is what replaces it. Without that judgment, the same method that multiplies a senior's output can leave a junior slower than before.
Where the effort lands
The work isn't spread evenly across the passes. It's light at the start and piles up at the end.
Because an experienced developer can trust the rough passes to resolve, the early work moves fast: broad strokes, the whole product roughed in, an MVP standing up in a fraction of the old time. The foresight is what licenses the speed — you can sprint through the blur because you know how to steer it where it needs to land.
The effort doesn't disappear; it moves to the end. The final passes — the sharpest image — are where the care concentrates: correctness, edge cases, the load-bearing detail that has to be exactly right. The old rhythm inverts. You go fast while it's blurry and slow down as it comes into focus.
That front-loads a developer's capacity. Starting is cheap, so an experienced developer can spin up — and hold — many more projects at once than before. But attention piles up near delivery, so finishing stays expensive: you can begin far more than you can ship in parallel. Capacity is highest at the outset of a project and tightens as it nears done.
One honest caveat
A roughed-in whole can look more finished than it is. Sharpening a blurry photo assumes the photo was pointed at the right thing — software's blur can hide that you framed the wrong product, or that a convincing surface sits on unfinished foundations. The discipline of working this way goes into grounding the parts no one can see — auth, edge cases, data integrity — not just the ones that show.