Verification Is the New Bottleneck in Software Development

Livia
October 23 2026 • 5 min read
check mark with tech blurred elements on background and title on top

Verification has always determined whether code deserves to reach production, but its economic importance was partly obscured by the difficulty of producing software in the first place. Human development capacity restricted how many features, migrations and infrastructure changes a company could create. Testing, review and deployment systems were built around that pace.

That balance is disappearing. Coding agents can now produce changes faster than many engineering organizations can understand, test and safely absorb them. The result is a shift in where technical value accumulates: from the production of code toward the systems, practices and judgment required to establish whether it is correct, secure and suitable for the environment in which it will run.

The clearest evidence arrived this week from Blacksmith, an infrastructure company that builds and tests software before deployment. It raised $66 million at a $1 billion valuation after reporting that the number of validation jobs running on its platform had risen from five million a week at the beginning of the year to 90 million. Its annual recurring revenue increased seventeenfold over the same period.

Blacksmith’s growth suggests that the productivity gains from code generation are already creating demand elsewhere in the development lifecycle. Every additional change still has to be built, tested, integrated and evaluated. Making code easier to produce does not remove those obligations. It increases the volume they must absorb.

Production can scale faster than confidence

The conventional account of AI coding begins with the developer and measures how quickly a task can be completed. That perspective captures only one stage of software delivery.

A generated implementation may compile and satisfy its immediate prompt while remaining poorly suited to the system around it. It can reproduce an outdated pattern, introduce an insecure dependency, violate an architectural decision or mishandle a business condition absent from the model’s context. Even technically correct code can create operational risk when several individually reasonable changes interact after deployment.

Google’s DORA research on generative AI in software development found that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. The researchers attributed part of the effect to larger batches of generated code, which take longer to review and create more opportunities for instability.

The finding does not imply that AI coding tools reduce productivity in every environment. It shows that local acceleration does not automatically improve the performance of the wider delivery system. A developer may produce a change more quickly while the organization spends additional time reviewing, integrating or repairing it.

A randomized study conducted by METR reached a similarly useful conclusion from a different direction. Sixteen experienced open-source developers completed 246 tasks in mature repositories, with AI tools randomly permitted for some assignments. The developers expected AI to reduce completion time by 24%, yet the tasks completed with AI took 19% longer.

The scope of the study was narrow, and the tools it evaluated have since improved. Its value lies in exposing the verification work hidden inside perceived acceleration. Developers spent time reading generated code, correcting unsuitable suggestions and confirming that changes met the standards of repositories they already knew well. Producing an answer and establishing that the answer belongs in a production system are separate forms of work.

DORA describes this as a verification tax. As generation becomes faster, part of the saved time reappears as auditing. Thirty percent of developers in its research reported little or no trust in AI-generated code. The industry has therefore improved its ability to create candidate solutions faster than its ability to turn those candidates into justified engineering decisions.

Security timelines are compressing too

This week’s PHP crisis shows the same imbalance at infrastructure scale.

Researchers using AI-assisted security tools identified critical vulnerabilities in PHP, the programming language behind a large share of the web. The PHP Foundation subsequently acknowledged that early evidence of one flaw had been reported in 2024, but the issue was treated as theoretical because researchers had not yet demonstrated a practical attack path.

AI helped close that gap. Once the vulnerabilities became actionable and details leaked ahead of the coordinated disclosure, governments and other organizations began taking systems offline while maintainers rushed to distribute patches. PHP developers released emergency updates, while US authorities advised organizations unable to patch immediately to disconnect exposed systems. Reuters described the episode as a race to secure installations before attackers could reverse-engineer the fixes.

The incident demonstrates that AI can strengthen defensive research by finding vulnerabilities that survived years of human inspection. It also shortens the interval available for response. Attackers can inspect patches, generate exploit variations and scan large numbers of targets more quickly, while defenders still need to identify affected systems, test updates against production dependencies and deploy them without disrupting essential services.

That asymmetry makes verification and operational readiness inseparable. Discovering a vulnerability faster has limited value if an organization cannot establish where the vulnerable component is running. Generating a patch faster provides limited protection if deployment processes cannot release it safely. The decisive capabilities are accurate software inventories, automated testing, controlled deployment and the ability to isolate or roll back affected systems.

The attack surface is also expanding into the AI development infrastructure itself. The Wall Street Journal has documented the rise of “LLMjacking”, in which attackers use stolen credentials or weak authentication to hijack model access. Compromised endpoints can then be used for data extraction, credential theft, cryptocurrency mining or other expensive workloads while the victim absorbs the inference cost.

Engineering teams must consequently verify more than the code an agent produces. They must control the credentials it uses, the tools it can call, the environments in which it executes and the data it can reach.

Discipline becomes a scaling mechanism

It is tempting to treat review, testing and security controls as friction imposed on AI-assisted development. In practice, they determine how much acceleration an organization can use.

A team with weak automated tests cannot safely absorb a sharp increase in generated pull requests. An organization without reproducible builds cannot reliably establish what it is deploying. Poor observability makes it difficult to distinguish a successful release from a failure whose consequences have not yet surfaced. Slow rollback turns every increase in deployment frequency into additional operational exposure.

Engineering discipline therefore becomes a scaling mechanism. Clear architecture limits the number of plausible implementations. Strong interfaces reduce the context an agent needs to modify a system safely. Automated tests convert assumptions into checks that can run at machine speed. Isolated execution allows generated changes to fail without reaching sensitive environments. Staged releases, observability and rollback reduce the cost of discovering an error after deployment.

This also changes how companies should measure AI coding productivity. Lines of code, generated pull requests and completed tasks describe how much the system produces. They reveal little about how much useful software reaches customers.

The more meaningful measures sit further downstream: the proportion of generated changes accepted without extensive rework, review time per change, escaped defects, failed deployments, security findings and recovery time. These show whether greater production is improving the engineering system or merely feeding a larger verification queue.

AI removes a natural limit that once contained software risk. When humans could create only a finite number of changes, production capacity placed an indirect ceiling on the number of mistakes, interactions and vulnerabilities entering the delivery process. Agents weaken that ceiling by making plausible code available almost instantly.

The organizations that benefit most will be those capable of verifying more software without lowering the standard required for production. Once code becomes abundant, confidence in that code becomes the scarce engineering output.