The homework problem
Would you trust a student to grade their own homework? Nobody says yes out loud. Then we cheerfully wire the same model that wrote a patch into the pipeline step that decides whether that patch is safe to ship, and call it a productivity win.
A DevOps.com column by Mike Vizard, published on 2026-08-12, gives that pattern a useful name: the verification gap. The framing is narrow on purpose. It steps back from the broader debate about AI-written code in general and locates the risk at one specific stage of the delivery pipeline, the moment between a model producing a diff and that diff being cut into a release.
What the column actually claims
Vizard's argument, drawing on Sauce Labs' Kohli, is that code creation has never been faster while the machinery around it (testing pipelines, review processes, device coverage) has not sped up in step. A familiar complaint. The new twist is Kohli's warning against a specific antipattern: using the same AI model to write the code and to verify it, which he likens to letting a student grade their own homework.
He also draws a line between code velocity and product velocity. Shipping is not committing. Shipping requires authored tests, reviews, environment coverage and production-like validation, all things a model that just produced the change is uniquely unqualified to sit in judgement of.
The piece cites Sauce Labs research to justify the alarm. 80 percent of surveyed organisations traced production incidents to AI-generated code. 90 percent said the impact on the business was serious. 66 percent admitted they had compromised quality standards to meet a deadline. Weigh a single vendor survey however you like; the direction is not surprising.
Where the trust boundary actually moves
The useful bit, for anyone maintaining a CI/CD platform, is that "verification gap" reframes an AI problem as a release-engineering problem. Which is where it belonged all along.
You already know how to think about this shape. Signing keys do not verify themselves. A builder does not attest its own provenance in a way you should trust downstream. A linter does not certify its own security. Whenever the party that produced an artifact is also the party that vouches for it, the boundary is nominal at best. Attach a model to both ends of the same pipeline and you have rebuilt that antipattern from parts.
The prescription Vizard lands on is to invest in verification at the same rate as generation, and to make sure the verifier is independent of the generator. Different model, different owner, different test authorship. Tests the change did not propose for itself. Environments the model did not pick. The verifier should be the boring, unimpressed part of your pipeline; that is a feature.
The uncomfortable part
None of this is free. Independent verification means someone has to write the tests the AI did not, maintain the environment coverage the AI does not care about, and hold a line on merge criteria when the dashboard says velocity is up and everyone is happy. Unfashionable work. It is also the only work in that list that is actually load-bearing.
If your rollout of AI coding tools moved the "code" arrow to the right and left the "verify" arrow where it was, you did not adopt AI. You bought a faster way to ship un-audited change. There is a name for that pattern too. An outage waiting for a calendar.
Signed. Merged. Not verified.
