AI coding tools have changed one of the basic assumptions behind software development: writing the code is no longer necessarily the slow part.
Developers are producing significantly more code with AI assistance, but release velocity hasn’t increased at nearly the same rate. Recent research found developers are producing 741% more code while release velocity has increased by less than 20%. Additionally, 80% of organizations surveyed said they’d traced a production incident, outage, or customer-impacting defect to AI-generated code.
The problem is bigger than whether an AI model writes good or bad code. AI has accelerated one part of the software development lifecycle while much of the system used to verify that code still operates at the old pace.
That mismatch has created a new hard bottleneck for development teams: verification.
Code Generation Is Only One Part of the Job
Writing code faster sounds like an obvious productivity win. But code only creates value when a team can confidently move it into production.
That means understanding whether a change works across the application, whether it affects existing functionality, whether it introduces security vulnerabilities, and, perhaps most importantly, whether the software still behaves the way users and the business expect.
This is where the speed advantage starts to disappear. Test creation, maintenance, and analysis haven’t accelerated at the same rate as code generation. End-to-end testing can be especially difficult because user journeys often cross multiple functions, services, and systems. A seemingly minor semantic change in one place can affect behavior somewhere else entirely.
Creating tests that accurately capture those relationships has traditionally required substantial engineering work. Then, when a test fails, someone still has to determine why. Did the product break? Did the expected behavior change? Is the test itself outdated? Is the failure environmental, intermittent, or the first sign of a larger problem?
AI can generate another block of code in seconds. Answering those questions still requires context. The result is a growing verification backlog.
Release Pressure Makes the Gap Worse
Engineering teams are already feeling the consequences. In the same research, 53% of organizations said they routinely release software despite knowing it contains critical issues. Another 66% said they’d compromised quality or testing standards to meet a release deadline.
The pressure behind those decisions is straightforward. Release targets are tied to immediate product, customer, and revenue commitments. Defect costs often emerge later and can spread across engineering, support, security, operations, and customer teams.
The result is that release speed gets rewarded immediately, while the consequences of poor quality often show up later. Verification becomes a final checkpoint that has to fit whatever time remains.
AI coding makes that approach harder to sustain because it keeps increasing the amount of software flowing toward the same checkpoint.
Hiring more testers cannot close the gap. In the same research, 64% of organizations said they’d increased QA headcount over the previous year even as incidents continued to rise. Code volume scales much faster than headcount can, and adding people only creates more handoffs and coordination issues.
Verification itself has to become more scalable.
Testing Needs to Start With Intent
As AI generates more of the implementation, verification has to move beyond exercising some paths in the code and assuming that implies correctness. Teams have to verify whether the resulting application behaves according to its requirements, guardrails, business rules, acceptance criteria, all applicable user journeys, and on interfaces or devices of choice
That starts with an understanding intent.
Product teams can define the expected outcome, while engineering and quality teams translate that outcome into behavior the system can verify. Actual customer behavior can add another signal, particularly when it reveals how users interact with an application differently from what teams originally expected.
This becomes increasingly important as AI takes on more of the implementation work.
If a coding agent produces technically valid software based on an ambiguous or incorrectly understood requirement, a test generated from that same assumption may confirm the wrong behavior. If both the code and its tests are generated from the same faulty assumption, automating both only validates the mistake faster.
That’s why deriving correctness from requirements matters. When they are incomplete, the process should discover and surface that ambiguity for human review while agentically automating the rest.
Human involvement thus becomes more targeted. Instead of spending engineering time on repetitive execution and analysis, teams can focus that attention on ambiguous or incomplete requirements, unexpected behavior, security risks, and release decisions that require judgment.
Developers and QA Teams Will Have Different Jobs
As more test authoring, execution, maintenance, and analysis become automated, responsibilities across engineering will shift.
Developers will need to become more explicit about intent. When software can be generated rapidly from a prompt or requirement, ambiguity upstream becomes much more expensive downstream.
Quality engineers will spend much less time maintaining brittle scripts and more time thinking about risk, coverage, edge cases, and governance. Site reliability teams can bring production behavior back into the development process so incidents and unexpected user behavior influence future verification.
AI agents can handle more of the repetitive execution and analysis between those groups, but there need to be clear boundaries around what they can decide independently.
A release should require human review when results can’t be adequately explained or reproduced, requirements are unclear, potential security vulnerabilities remain, third-party components haven’t been sufficiently validated, or a failure could meaningfully affect sensitive data, revenue, customer experience, or mission-critical operations.
That also requires traceability. If an agent authors, changes, executes, or interprets a test, teams need to be able to see what changed, why it changed, and what evidence supported the eventual release decision.
Autonomy without that visibility makes it harder to understand why software reached production when something goes wrong.
Measure What Reaches Production
There’s also a measurement problem. Organizations naturally want to know whether their AI investments are improving developer productivity. Lines of code generated, tasks completed, tests executed, and development time saved are easy metrics to collect they don’t necessarily tell you whether either the software or its production got better.
Engineering leaders should pair productivity metrics with outcomes such as production incidents, escaped defects, customer impact, security exposure, rework, and the frequency with which AI-generated changes cause problems after release.
The question shouldn’t simply be, “How much faster can we create software?” Teams also need to ask, “How confidently can we put that software in front of a customer?”
AI has already changed how quickly developers can build. Now verification, governance, and release decisions have to operate at the same scale. If they don’t, companies risk using AI to accelerate the one thing no development team wants to produce faster: defects.
