AI code verification is the new bottleneck, not writing code

When a team adopts AI coding, code gets written faster. It does not get deployed faster unless the team has somewhere to check that the result is right. The queue moves from "how do we build this" to "how do we know it works", and a missing test environment or test suite caps the speed-up long before it reaches production.

We see this often enough that our colleague Jiří Kuldanek describes it as the usual sequence: "Typically it goes like this. We teach a company to work with AI, it generates a lot of code that looks good, but they are afraid to deploy it, because they don't know what they actually wrote."

In one recent engagement we visited the same team three times. With AI, its developers could now produce working applications. What they could not do was put them in front of users with any confidence.

We told them this was good news, and we meant it. The point of AI adoption is to clear a backlog that used to pile up faster than anyone could work through it. That team had reached the point where building was no longer the hard part. The question had moved from "how do we develop this" to "how do we make sure it is right". That is a better problem to have, and a solvable one.

The reason was dull and structural. There was no sandbox, no dev and no staging environment. Developers had nowhere to click through a change before it reached the people who depend on it.

So every change that AI helped write faster joined a queue of changes nobody had verified. The speed AI added did not disappear. It turned into inventory. A CI/CD pipeline cannot help much either, when there is nowhere to deploy to before production.

What we find most telling is that the team concluded on its own it needed automated tests. For a long time it had managed without them. Once a human stopped writing most of the code, the team needed another way to know what the code did, and tests were the obvious one.

Jiří describes what we usually do next. "At that point we teach them to write with AI so that the AI maintains a complete test suite and follows the testing pyramid, or whatever general testing conventions apply."

Practices like test-driven development stop being a matter of taste when the author of the code is a model.

Jiří goes a step further than a generic test suite. "The killer shot is that every application looks different, and for almost every application you can come up with a creative way to verify it. The implementation of that verification is left to the AI, under a developer's supervision."

The examples he gives are practical:

There is a positive loop here too. As a company writes more code with AI, its AI literacy grows, and it gets better at designing its own ways to verify code with AI.

The trust gap is well documented. In Sonar's 2026 State of Code survey of more than 1,100 developers, 96% said they do not fully trust AI-generated code, yet only 48% always check it before committing. Sonar sells code verification tools, so read that with its interest in mind, but the direction matches what we see.

Most of the articles we found on this frame the bottleneck as review capacity: pull requests that are too large, seniors who are overloaded, review that needs automating. That is real. Our observation sits one step earlier. Some teams do not have a place where a change can be verified at all, and no amount of faster review fixes that.

Where the environment exists, review is the next constraint. Deterministic checks at the end of the pipeline, such as build checks and security checks, speed up review because a human no longer has to look for what a machine can catch.

Size matters as much. Pull requests must not get out of hand again. They need to stay reasonably sized.

In October 2026, Anthropic described how the Claude Code team handles this in How the Claude Code team does code review. A classifier reads each change and assigns a risk tier. A low-risk change needs no human approval once automated review and security checks are green, a medium-risk change needs one person, and a high-risk change needs two. They also note that most pull requests over 1,000 lines get findings, while most small ones come back clean. By their own numbers, merged pull requests to their codebase more than doubled from June to September, while the share that had to be reverted fell by more than 40 percent.

You do not need their tooling to borrow the idea. Decide in advance which changes an agent may verify alone, which need a second agent, and which need a person.

Verification is not the only queue that grows. When development speeds up, the work before it shows its limits. Preparing a good specification for the developers turns out to be a gap, just like checks and testing.

It happens after delivery as well. In one case a client's own customers were not ready for that many new features. Marketing and product marketing had to slow the pace of releases so that users could take the changes in gradually. The bottleneck is usually people.

Jiří names the warning sign plainly. "The absence of the classic, proper processes for writing and delivering code is the best indicator that a team won't be able to deliver that much faster after adopting AI."

The opposite case exists too. We have worked with teams where, after adoption, the developers themselves came to us saying they suddenly had a lot more capacity. Their whole development environment was set up properly, and the new code from AI fitted into the lifecycle they already had.

So before we promise a team any speed-up, we ask:

If the answers are thin, that is where the work starts. These questions are about how software gets built and shipped. An AI readiness assessment takes the wider view: use cases, data and systems, skills, and governance.

The velocity we sell does not show up at a customer who is not ready for it. Worse, it takes a few weeks before anyone notices. We would rather ask the questions above before the first workshop than explain the gap after it.

This comes from field work. The detailed case is one engagement observed over three visits, without any before-and-after measurement. Jiří's "typically" tells us it was not a one-off, but we have not counted how often it happens. We keep running into the pattern. That does not make a missing test environment the most common thing slowing AI adoption down.

If you want your team to go through the whole cycle with AI, from requirements analysis through implementation and tests to deployment, that is what our End-to-end AI for IT training covers.