gshc2020.com

I hear this pattern from engineering teams constantly. They adopted AI coding tools, watched output climb and celebrated. Pull requests got bigger, code moved faster and feature rollout was on a roll. Then something quieter happened. The bottleneck moved, and almost nobody moved with it.

Writing code used to be the expensive part of software. It is not anymore. The expensive part is now deciding whether the code you just got is correct, safe and something you actually want to own for the next five years. That work is called verification, and most organizations still treat it as an afterthought bolted onto a process designed for a world where humans typed every line.

The Review Process Quietly Failing

Here is the uncomfortable pattern. AI tools multiply the volume of code entering review, but they do nothing to multiply the humans doing the reviewing. So reviewers adapt the only way they can. They skim. They approve. They trust the green checkmarks. The data backs this up. One study of roughly 800 developers found that engineers using an AI coding assistant produced 41% more bugs, with no meaningful gain in throughput.

Ask your senior engineers, privately, how carefully they read a 900-line AI-assisted pull request at 4 p.m. on a Thursday. You already know the answer. The approval still lands, because the team has a velocity goal and the code looks plausible. Plausible is exactly what these models are trained to produce. That is the trap. AI-generated code fails differently than human code. It rarely looks lazy. It looks confident, idiomatic and complete, right up until it is subtly wrong about your business logic in a way no linter will catch.

When review becomes a formality, you have not sped up your team. You have deferred the cost. It comes back as incidents, rework and a codebase nobody fully understands, including the people whose names are on the commits.

Verification: A System, Not A Vibe

The fix is not telling reviewers to try harder. Attention does not scale. Systems do. Engineering leaders should treat verification as a first-class discipline with its own architecture, the same way we treat CI or observability.

In practice, that means three shifts.

First, move trust from reading to checking. Deterministic gates should carry as much of the load as possible: type systems, contract tests, property-based tests, static analysis, policy checks that block known-bad patterns. If a machine wrote the code, machines should do the first several rounds of interrogation. Humans should be the last check, not the only one.

Second, make tests the specification. When an engineer prompts an AI to build a feature, the most valuable artifact is not the generated code. It is the test suite the engineer writes or approves first, because that is where human intent actually lives. Teams that write intent down before generation can verify against it. Teams that generate first end up reverse-engineering their own requirements from output they barely read.

Third, budget review like the scarce resource it is. Not every change deserves the same scrutiny. A dependency bump and a change to your billing logic should not travel the same path. Route high-risk changes to deep review with fresh eyes and real time allocated. Let low-risk changes flow through automated gates. Most teams apply one uniform process to everything, which guarantees that critical changes get the same 90 seconds as trivial ones.

The Accountability Question Nobody Assigned

There is a second problem hiding inside the first, and it is organizational rather than technical. When an AI agent writes code, who is accountable for it?

The instinctive answer is "whoever merged it," and that is the right answer, but only if your process makes it true. Accountability requires visibility. You need to know, later, what was generated, what was modified, what was checked and who made the call. Engineering activity is surprisingly ephemeral. Context lives in chat threads, tool sessions and people's heads, and it evaporates within weeks. Six months from now, when an auditor, a security team or your own postmortem asks how a piece of code came to exist, the honest answer at most companies is a shrug.

This matters beyond incident response. Provenance of code is becoming a compliance and financial question, not just an engineering one. Regulators, insurers, acquirers and tax authorities are all starting to ask what your engineers actually did and whether you can show it. The teams that capture that record as work happens will answer in minutes. The teams that plan to reconstruct it later will discover there is nothing left to reconstruct.

What To Do Monday Morning

Start small and start concrete. Pick one high-risk surface in your codebase and give it a real verification path: required tests written before generation, automated policy checks and a named human owner for every merge. Measure how often your reviewers request changes on AI-assisted pull requests. If the answer is almost never, your review process is decorative, and now you know.

Then have the accountability conversation explicitly. Write down who owns agent output, what record you keep of how code was produced and checked, and what evidence you would want in hand if someone asked you to explain a change a year from now. Capture it as you go. You may not get a second chance to collect it.

The industry spent two years learning to generate. The next advantage belongs to teams that learn to verify, because speed you cannot trust is not speed. It is risk on a delay timer.

Generation is solved. Verification is not. Build for the part that is still hard.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?