Something has happened to the economics of software that most planning has not caught up with. Producing code, the part that used to take the bulk of an engineer’s week, has become cheap and fast, and a founder can now watch a working feature appear from a paragraph of description in the time it once took to set up the project. What has not become cheap is knowing that the feature is right, that it holds under load, that it does not quietly corrupt a record or expose a customer’s data, and that the person who has to fix it at two in the morning understands what it does. Generation got cheap. Verification did not. A company that plans around the first number while ignoring the second will ship faster than it ever has, straight into a wall it never saw coming.
The asymmetry is not unique to code, and seeing it elsewhere makes it easier to take seriously. Text, images and answers of every kind have all become cheap to produce, and in each case the burden has moved to the reader, who now has to decide what to trust. Code is the same story with higher stakes, because a plausible paragraph that is wrong wastes a minute, while a plausible function that is wrong can wipe an account, and the difference is that the paragraph announces itself as text to be judged while the function slips into a system and behaves like every other function until the day it does not. The output looks finished. Whether it is finished is a separate question, and the separate question is now the expensive one.
Where the bill actually lands
The verification cost does not disappear when nobody pays it up front. It moves, and it moves to the worst possible places. The first is incident response, because code nobody fully understood at the time it was written is code nobody fully understands when it fails, and the hours saved in generation come back with interest as hours spent reconstructing what a system was supposed to do. The second is customer trust, which is spent invisibly every time a feature behaves oddly and recovered slowly if at all. The third, and the one founders notice last, is the senior engineer who used to be able to hold the whole system in their head and now cannot, because the system grew faster than any person’s model of it, and the model was the thing that made the senior engineer valuable.
That last cost deserves a closer look, because it compounds. A team that generates code faster than it can read it accumulates a system that fewer and fewer people can reason about, and reasoning about the whole thing is exactly the capability that verification depends on. Tests catch the failures you thought to test for. Understanding catches the ones you did not. When understanding thins out, the tests start to look like coverage without being it, and the team discovers the gap at the moment a customer does. None of this shows up in the sprint velocity chart, which is why the chart keeps rising right up until the quarter it matters.
Not every line deserves the same scrutiny
The tempting response is to demand rigorous verification of everything, which is both unaffordable and wrong. The old pharmacological idea that the dose makes the poison applies directly here: verification is a treatment with a cost, and the right amount depends on what is being treated. A marketing page that renders slightly wrong for an hour costs almost nothing. A billing calculation that is wrong by a rounding rule costs real money and a reputation. An authorisation check that is wrong costs the company. Treating these three with the same level of scrutiny either starves the third or bankrupts the first, and the honest job is to draw the lines deliberately rather than let them fall where the enthusiasm happens to run out.
The output looks finished. Whether it is finished is a separate question, and the separate question is now the expensive one.
Drawing those lines means naming, in writing, which parts of the product carry real consequences and therefore earn expensive verification: money, identity, permissions, data that cannot be regenerated, anything a regulator will ask about. Everything outside those lines can be produced fast and checked lightly, on the understanding that when it breaks the fix is cheap and the blast radius is small. This is not a licence to be careless in the cheap zone. It is a decision to spend the scarce, expensive attention where being wrong is catastrophic and to accept ordinary bugs where they are merely annoying. Companies that refuse to make this distinction end up making it anyway, badly, by accident.
When the frontier default is the wrong tool
There is a related choice that founders with real stakes in their domain should not skip. The default generation tooling is built for the general case, and for most teams it is the right starting point, but a company whose product lives inside a regulated or high-consequence domain often finds that the general tool cannot see the constraints that matter most to them. Some firms have found it worth building their own coding agent precisely so that it knows their codebase, their rules and their failure modes, rather than adopting the frontier default and layering review on top. That is not the right call for everyone, and it carries its own maintenance cost, but it illustrates the principle: the verification burden shrinks when the generation step already understands what correct means in your context, and grows when it does not.
The practical test is whether your domain has failure modes the general tool would not recognise as failures. A consumer app mostly does not. A payments company, a healthcare product, a system that moves other people’s money or holds other people’s records, mostly does. In the second group, investing in tooling that carries your constraints is a form of verification spending, paid once rather than on every diff, and it is often cheaper than the alternative of catching domain mistakes one incident at a time.
Budget for it the way you budget for compute
The shift in posture that all of this points to is simple to state and hard to hold: treat verification as a line item, planned and funded, rather than as the thing engineers do in whatever time is left after shipping. Compute gets budgeted because it is visibly metered and the bill arrives monthly. Verification gets skipped because its bill arrives as an incident, months later, with no invoice attached to the decision that caused it. A founder who puts a number on verification, in hours, in tooling, in the deliberate slowness of the high-stakes zone, is doing nothing more exotic than accounting for a cost that exists whether or not it is written down.
The companies that come through this transition well will not be the ones that generated the most code. They will be the ones that understood, early, that the cheap part had stopped being the bottleneck and moved their attention to the part that had become one. Ship fast where fast is safe. Be slow, deliberately and visibly, where being wrong is expensive. And keep enough people who can still reason about the whole system that when the cheap code fails, someone knows why.