For most of my career the hard part of shipping software was writing the code. That is the part that got cheap this year. I can hand an agent a clear brief and get a working module back in minutes. So the bottleneck moved. It did not disappear. It moved one step downstream, to the part nobody automated: deciding whether the code is actually correct, safe, and worth keeping.
That is the real bottleneck now. Not writing. Verifying.
The short version
When code was expensive to write, verification was cheap by comparison. A human wrote a little, a human checked a little, and the two stayed in balance. AI broke that balance. It writes more code, faster, than any team can review by reading it line by line. If your only quality gate is a senior engineer reading a diff, you have moved the traffic jam from the keyboard to the reviewer, and the reviewer does not scale.
The fix is not to slow the writing back down. The fix is to make verification a system, not a person. Build the gates that decide correct-or-not without a human in the loop, and keep a human only for the calls a machine cannot make.
That is the whole argument. The rest is what those gates look like, from a live product I run.
Why the balance broke
Think about the old ratio. A mid-level engineer wrote a feature over three days. A senior spent an hour reviewing it. The writing was the cost. The checking was a rounding error on top.
Now the agent writes that same feature in twenty minutes, and then writes the next four while you are still reading the first. The writing is the rounding error. The checking is the cost. If you keep verifying the old way, by having one experienced person read everything, that person becomes the slowest part of the whole pipeline. You did not get faster. You moved the wall.
I felt this directly. I run a US referral-marketing SaaS as fractional CTO and I have shipped more change in the last eighteen months, with agents, than in years before them. The output went up. My ability to eyeball every line did not. The only way through was to stop reviewing by reading and start reviewing by system.
What a verification system actually is
Verification as a system means the answer to “is this change correct” comes from gates that run every time, not from whether a tired human happened to catch it. On the product I run, that meant building the checks up in layers.
The first layer is the boring one everybody skips: tests that fail loudly and a build that will not ship red. I moved the whole build to Vite and put the test suite where it runs on every change, not on request. A gate you have to remember to run is not a gate.
The second layer is instrumentation, so you can verify in production, not just before it. I stood up the first phase of distributed tracing on this product. Once you can follow a single request across the system, “did this change break anything” stops being a guess and becomes a thing you can watch. That is verification too. It just happens after deploy instead of before.
The third layer is the one AI made non-negotiable. When an agent writes a whole subsystem, you cannot verify it by trusting the author, because the author is a model that will hand you confident and wrong with the same face as confident and right. So you verify the output against rules you wrote when you were thinking clearly. On this product the fraud-scoring pipeline is exactly that: a live, event-driven re-scoring flow that checks referral behavior against thresholds a human decided, and suppresses the bad ones on its own. The machine runs the check. The human wrote the definition of bad. That split is the whole game.
The one thing you still cannot automate
Here is the honest limit. You can automate whether the code passes. You cannot automate whether the code should exist.
A gate can tell you the function is correct, fast, and safe. It cannot tell you the feature was worth building, or that the premise underneath it was right. That judgment stays human, and it is now the scarcest thing in the room, because everything cheaper than it got automated around it. The senior engineer’s job is not to type anymore. It is to define what “good” means precisely enough that a machine can enforce it, and then to spend their scarce attention only on the calls no gate can make.
That is a real shift in what the job is. Less writing. More deciding what to measure and where the line sits. If you get that part wrong, the agent will very efficiently build you the wrong thing, verified and green the whole way down.
What this means if you run a product on AI
Stop measuring your speed by how fast you write. Everyone writes fast now. Measure it by how fast you can trust what got written.
Look at your pipeline and find the human bottleneck. It is almost always the same person: the one senior reading every diff by hand. That is the balance that broke. The move is to take what that person knows and turn it into gates that run without them, so their judgment goes to the decisions that actually need a human, not to catching typos an agent could have caught.
Writing code is cheap now. The teams that win the AI era are not the ones that write the most. They are the ones that can verify the most, the fastest, with the fewest humans in the hot path.
Frequently asked questions
Has AI made writing code cheap? For most execution work, yes. A coding agent can scaffold modules, write tests, and refactor across a codebase in minutes, at a cost no human typing can match. The scarce, expensive part is no longer producing the code. It is verifying that the code is correct, safe, and worth keeping.
Why is verifying code the real bottleneck now? Because AI writes more code, faster, than any team can review by reading it line by line. When writing was slow, human review kept up. When writing became instant, the reviewer became the slowest part of the pipeline. The bottleneck moved from the keyboard to verification.
How do you verify AI-written code at scale? You make verification a system instead of a person. That means automated tests that block a red build, production instrumentation like distributed tracing so you can verify after deploy, and rules-based gates that check output against thresholds a human defined. The machine runs the checks. The human defines what correct means.
What can AI verification not do? It cannot decide whether a feature should exist or whether the premise behind it is right. A gate can prove code is correct. It cannot prove the code was worth writing. That judgment stays human, and it is the scarcest and most valuable part of the job now.
The takeaway
The cost of software moved. It used to sit in writing code. It now sits in verifying it. If you are still verifying by hand, one senior reading every line, you have not sped up. You have just moved the wall.
I build these gates for a living, on a live product, every week. If your team is shipping AI-written code faster than it can trust it, that is the exact problem I solve. Let us talk.
