Think about where the effort used to go. For most of the history of software, the expensive part was making the thing exist: writing the code, getting it to compile, wrestling it until it worked at all. Everything in how we organized teams assumed that production was the scarce resource. Estimates were about how long it would take to build. Hiring was about how much could get built. The bottleneck was the keyboard.
Agents moved the bottleneck, and a lot of processes are still optimizing the station that is no longer the constraint.
What got cheap and what didn’t
Be precise about what changed. Producing code got dramatically cheaper. An agent turns a description into a working implementation in minutes, and it does it again, and again, across parallel sessions, faster than any team of humans could. The production station, the one everything used to bottleneck at, now runs almost for free.
What did not get cheaper is knowing that the produced code is correct, that it is safe, and that it is coherent with everything around it. That work, call it assurance, costs exactly what it always did, and arguably more, because now it has to keep up with a production rate that no longer waits for it. The model can write the feature in five minutes. Deciding whether to trust the feature still takes a human the same careful hour it always took.
When one station on a line speeds up enormously and the next one does not, the constraint moves to the slow station. This is not a metaphor, it is how any pipeline behaves. The bottleneck in building software has moved from production to assurance. The scarce, expensive resource is no longer generating code. It is establishing that the generated code can be trusted.
The symptom: fast growth, faster rot
You can spot a team that has not noticed the shift by its symptoms. The codebase grows quickly, which feels like progress. Then it starts to rot faster than it grows, which feels like bad luck and is actually structure. Features that individually passed review combine into behavior nobody designed. Each change was locally correct and the whole drifts into incoherence, because the production station was running at full speed while assurance stayed a rubber stamp at the end.
The tell is where the pain shows up. If your hard days are about generating code, you are living in the old world. If your hard days are about trusting code, reviewing it, reconstructing why it exists, deciding whether the last green was real, then the bottleneck already moved and your process may not have moved with it.
The trap is that the old-world instincts still feel productive. Generating more looks like momentum, and momentum is satisfying, so the natural response to falling behind is to point the agents at more work. But if the constraint is assurance, that response makes the problem worse, not better: it widens the gap between what has been produced and what has been trusted, and the widening gap is precisely the rot. Feeling busy and being blocked look identical from the inside when you are optimizing the wrong station.
Assurance is not more testing
It would be easy to hear “assurance” and reach for “write more tests.” Tests are part of it, but assurance is the larger question tests serve: can this output be trusted, and how do I know? That includes whether the tests ran at all, which is not something the agent’s word can settle. It is the whole problem behind a false success claim, where “tests pass” is a generated sentence rather than an observed event.
Assurance is the discipline of turning claims into evidence at the rate the claims arrive. It covers what a green build actually proves and what it doesn’t, whether completion cost a real demonstration, and whether the evidence survives past the terminal it printed in. Testing is a tool inside assurance. Assurance is the station.
What changes when assurance is the constraint
Naming the bottleneck is only useful if it changes what you do. A few things shift the moment you accept that assurance, not production, is the scarce resource.
Estimates stop being about build time. The old question, “how long to write this,” is nearly free to answer now and nearly useless, because writing it is the cheap part. The question that predicts your actual throughput is “how long to trust this,” and that is the number worth planning around. A change an agent writes in five minutes but that touches a payment path is not a five-minute change. It is however long assurance takes, and pretending otherwise is how teams commit to a velocity they cannot actually sustain.
Capacity planning inverts too. Adding more generation, more agents, more parallel sessions, does not raise output past the point where assurance saturates. It just deepens the queue of unverified work waiting for the one human who can decide whether to trust it. Beyond that point, more production is not more shipping, it is more inventory. The lever that moves finished, trustworthy software is assurance capacity, and that is where investment belongs once the constraint has moved.
And the definition of progress changes. On a production-bound line, a big diff feels like a good day. On an assurance-bound line, a big diff that arrives without evidence is a liability you now have to work off, and a small change that closes with its proof attached is the thing that actually advanced the system. The team that internalizes this stops celebrating volume and starts celebrating verified, coherent change, which is the only kind that compounds instead of rotting.
Optimizing the right station
Once you accept the constraint moved, the work becomes obvious even if it is not easy. You stop pouring effort into producing more, faster, because production is not the bottleneck and speeding up a non-bottleneck just piles inventory in front of the real one. More generated code in front of an assurance step that cannot keep up is not progress, it is a growing queue of unverified changes.
Instead you invest in assurance throughput. Make evidence a byproduct of the work so it does not cost a separate manual pass. Review at the moments that carry the most information rather than trying to read everything, which is the way out of review fatigue. Close each task with proof attached so trust does not have to be rebuilt by hand later, the argument for evidence-based development. Every one of those moves is aimed at the same target: raising how much output you can assure per hour, because that number, not how much you can produce, is now what caps the whole system. It is the concrete form of the claim that trust, not output, is the bottleneck.
Where PaellaDoc fits
PaellaDoc is, in these terms, a bet on assurance being the constraint. It refuses self-reported success, executes the acceptance contract against the real result, and captures the evidence next to the change, so the assurance station can keep pace with a production station that got very fast. The point is not to slow down generation. It is to make trusting the generation cheap enough that the two stations run at the same speed instead of one flooding the other.
Producing software stopped being the hard part. Assuring it became the whole game. Build for the station that is actually the bottleneck.
Frequently asked questions
What is software assurance in the age of AI coding?
Assurance is the work of knowing that produced code is correct, safe, and coherent with everything around it, and being able to show how you know. It is the larger question that testing serves: can this output be trusted, including whether the tests ran at all. Agents made producing code cheap. Assurance costs what it always did, so it became the constraint on how much finished software actually ships.
Why did the bottleneck move from writing code to verifying it?
When one station on a line speeds up enormously and the next does not, the constraint moves to the slower station. Agents turn a description into a working implementation in minutes, across parallel sessions. Deciding whether to trust that implementation still takes a human the same careful hour. Production collapsed in cost, assurance did not, so the scarce resource is no longer generating code but establishing that the generated code can be trusted.
Is software assurance just writing more tests?
No. Tests are a tool inside assurance, not the whole of it. Assurance is the discipline of turning claims into evidence at the rate the claims arrive: whether a green build proves the feature is correct, whether completion cost a real demonstration, whether the tests ran at all, and whether the proof survives past the terminal it printed in. Testing is one instrument; assurance is the station.
How should estimates change when assurance is the bottleneck?
Stop estimating build time and start estimating trust time. “How long to write this” is nearly free to answer now and nearly useless. A change an agent writes in five minutes but that touches a payment path is not a five-minute change, it is however long assurance takes. Planning around build time commits you to a velocity you cannot sustain, because the unverified work just queues in front of the one human who can trust it.