For most of software history, writing code was the expensive part.

A developer might spend hours or days implementing a feature, while review was a relatively small step at the end. AI coding tools have quietly flipped that equation. A model can now draft a function in seconds and produce an entire feature in minutes. In other words, producing code become cheap. Way too cheap. But the review (hopefully with human in the loop) is still expensive.

The bottleneck hasn’t disappeared. It has moved.

Today, the scarce resource is increasingly the work that comes after code generation: reading the code, understanding its behavior, testing it, identifying what is wrong, and deciding whether it is safe to ship.

This isn’t simply a matter of perception. Research on AI-assisted development has found that delivery stability can decline as teams adopt more AI, while developer trust in AI-generated code remains far from universal. In one controlled study of experienced open-source developers, AI assistance actually made participants about 19% slower on real-world tasks—even though they expected to be faster and believed afterward that they had been.

The extra time went into prompting, reviewing generated code, debugging it, and fixing things that didn’t quite work.

The lesson isn’t that AI coding tools are bad.
Quite the opposite: they are extremely good at making code cheap.

The problem is that everything downstream of code generation—understanding it, validating it, and trusting it—hasn’t become cheap at the same rate.

That changes where engineering teams need to invest.

Verification Is a Stack of Filters, Not a Single Gate

Code verification isn’t one activity.
It’s a stack of increasingly expensive filters, each designed to catch problems the cheaper layers missed:

• Type checkers and linters — fast and inexpensive, catching mechanical mistakes and violations of known rules before code runs.
• Automated tests — validate behavior that static checks cannot. A function can be perfectly typed and still return the wrong answer.
• Static analysis and security scanning — look for deeper structural, reliability, and security problems that ordinary linters and tests may miss.
• Human review — evaluates things machines struggle to judge reliably:
  Is this the right design?
  Does it fit the architecture?
  Does it solve the actual problem?
  Will someone be able to maintain it six months from now?
• Production monitoring — the final safety net, detecting problems that survived everything before it.

These filters fall broadly into two categories.

Continue reading →