AI Made Implementation Faster. Verification Is Still the Bottleneck

Leonid Bugaev — Thu, 23 Apr 2026 15:35:12 +0000

AI made implementation dramatically faster.

Trust did not.

I live in two different worlds now.

In one, I build my own projects with AI and ship more software than ever. I have written more software in the last two years than across the rest of my career, and I have barely written any code manually in the last year.

In the other, I lead engineering for software used by banks, governments, and other regulated environments, where mistakes are expensive and confidence matters more than speed.

In both worlds, I keep hitting the same wall:

Implementation got dramatically faster. Trust did not.

That is the part I think the industry still keeps smoothing over.

Faster code generation is not faster engineering

The current AI coding conversation often assumes that if code generation speeds up, engineering speeds up too.

That is not what I see.

On my own projects, I can build much faster than before. AI helps me move quickly, clean things up, write tests, refactor, and push ideas further in less time.

But it also asks me to trust more.

I am not just delegating typing.

I am delegating thinking, validation, and judgment too.

And I am still not sure where the safe line is.

In enterprise software, the picture is different but the problem is the same.

AI absolutely helped us in some areas. It reduced noise. It reduced interruption-based work. It helped other teams answer questions about system behavior without constantly pulling senior engineers into ad hoc investigations.

That mattered.

People were less interrupted. Context switching got better. Engineers were happier.

But it did not suddenly make us ship features 2x faster.

Not even close.

Because implementation was never the whole job.

Verification is the bigger slice.

The verification gap

The phrase I keep coming back to is:

verification gap

By that I mean the distance between what I intend the software to do and what I can actually prove about its behavior.

Between intended behavior and demonstrated behavior.

That gap always existed.

AI did not invent it.

It amplified it.

Why AI makes this problem worse

When humans wrote the code, the same brain often held the intent, the implementation, and the validation loop together.

Not perfectly. People still shipped bugs. Specs were incomplete. Tests missed things.

But there was at least one place where the system could be understood as a whole: the person writing it.

That is no longer the default.

Now the human writes the prompt.

The model writes the code.

The model writes the tests.

The human skims the diff.

The model writes the cleanup.

The CI passes.

The feature ships.

And if the original intent was slightly wrong, incomplete, or misunderstood, that mistake does not stay in one place anymore.

It gets propagated through the whole stack.

The plan is based on the wrong assumption.
The implementation is based on the wrong assumption.
The tests are based on the wrong assumption.
The documentation often reflects the same wrong assumption.
The "manual validation" is often the same model being asked to sanity-check itself.

At that point, what exactly are we proving?

Often just that the system is internally consistent with the assumption it invented for itself.

Not that it matches our intent.

Bug free is not the same as intent-correct

This is why I think a lot of AI productivity discourse still misses the real problem.

People say: just write better tests.

I do write tests.

AI writes tests for me too.

That is not the point.

Tests verify behavior for cases somebody thought of.

That somebody used to be a human.

Now it is often a human plus a model.

That is still not the same thing as verifying intent.

You can have 100% line coverage and still miss the thing that matters.

You can have a green CI run and still not know whether the software behaves the way you intended.

A green pipeline can still be a polished misunderstanding.

Bug free is not the same as intent-correct.

Software is not flat. It is layers.

This gets worse as software gets bigger.

Software is not flat.

It is layers.

It is wide, deep, and full of interacting components, hidden assumptions, old decisions nobody remembers, backwards compatibility constraints, and behavior that only makes sense if you know four other subsystems.

Any project that lives long enough eventually reaches a point where one brain is no longer enough.

That was true before AI.

It is still true now.

AI does not remove that limit.

In some cases it makes you hit it faster, because you can generate change faster than you can understand its consequences.

A lot of our engineering process exists because of this:

CI/CD
QA
RFCs
architecture reviews
team boundaries
approval workflows

These are not random rituals.

They are patches over the same underlying problem: software complexity grows beyond what one brain can safely manage.

Where does intent actually live?

I think mainstream software engineering is still missing something fundamental.

We do not maintain a real source of truth for intent.

If I ask where the intended behavior of a system lives right now, the honest answer in most teams is:

all of it combined badly

Some of it is in source code.

Some of it is in tests.

Some of it is in RFCs.

Some of it is in Jira tickets.

Some of it is in Confluence.

Some of it is in the heads of senior engineers.

None of those is the place where I can go and see, clearly, how the system is supposed to behave right now.

That is not a source of truth.

That is archaeology.

And that feels like a major difference between mainstream software and more regulated domains like aerospace or automotive, where intended behavior is at least treated as a first-class artifact.

In mainstream software, especially in large, complex systems, we mostly reconstruct intent after the fact from scattered artifacts.

And then we act surprised when regressions keep happening.

So what is the actual bottleneck now?

If a feature can be implemented in hours instead of weeks, why have so many teams not seen the full payoff?

Because implementation was never the only bottleneck.

The harder part is deciding what should be built, making that intent explicit enough, and then verifying that the resulting system still matches it after the code, tests, and surrounding context have all changed.

That is where the time goes.

That is why I think AI did not remove the hard part of engineering.

It moved it from writing to verification.

If you want the next essays on this topic, subscribe on Substack: https://blog.reqproof.com/p/ai-writes-your-code-nobody-verifies

DEV Community: Leonid Bugaev