AI Writes the Code Now. Who Proves It?

Sometime in the last eighteen months, the default answer to "who wrote this function?" became "the agent did." Claude Code, Cursor, and their cousins are shipping meaningful fractions of production code at most companies I talk to. The people I know aren't debating whether to use them anymore — they're debating how much to trust them, and that debate is happening in exactly the wrong place: vibes.

The bottleneck moved

Software has always had a generation side (write the thing) and a verification side (convince yourself the thing works). For seventy years they were done by the same slow mammals at roughly the same speed, so nobody had to think hard about the ratio.

Agents broke the ratio. Generation got two orders of magnitude faster. Verification got... a nicer diff viewer.

The result is a growing pile of code that is plausible, well-formatted, confidently named — and reviewed by a human who is now the slowest, sleepiest component in the pipeline. Everyone privately knows the review depth per line has collapsed. We used to read code; now we skim narratives about code.

"The tests pass" is doing a lot of load-bearing work

The standard answer is: that's fine, the tests gate the merge. Which would be comforting if the tests weren't increasingly written by the same agent, in the same session, from the same understanding of the code — including the same misunderstandings.

An agent that misreads a boundary condition writes the implementation and the test from the same wrong belief. Both artifacts agree with each other. CI is green. The bug ships wearing a seatbelt.

This isn't hypothetical; run the experiment yourself. Have an agent write a module and its tests, then flip a comparison operator in the source. In my experience a disturbing fraction of the suite stays green — I wrote up a week of field notes doing exactly this.

Trust needs a mechanical basis

Here's my actual position: the answer to "who proves the code?" cannot be "a human, carefully." Humans don't scale to agent throughput, and asking reviewers to try harder is a process answer to a physics problem.

The answer has to be mechanical, and the mechanics exist:

• Specs already live in the code. Docstrings, type hints, Pydantic constraints, guard clauses — the documented contract. Machines can extract it.
• Tests can be proven, not trusted. Inject the violation a test claims to catch; demand the test fail. A test that can't fail is not evidence of anything.
• Readiness can be a number derived from proofs, not from executed lines — so the gate survives being gamed by high-throughput generators.

None of this removes humans from the loop. It changes what the human reviews: not "does this diff look right?" but "the contract says X, the proven tests cover X except these two flagged gaps — do I accept the gaps?" That's a decision a person can actually make well in thirty seconds.

The uncomfortable symmetry

The tools that created the verification gap are also the right operators of the fix. An agent that can call a verifier mid-session — write function, prove tests, read the flagged gaps, refactor for testability, re-prove — closes the loop at agent speed. That's precisely why we just made Quelltest agent-native: the proving machinery has to live where the code is being written, or it becomes the weekend chore nobody runs.

Generation is solved and getting cheaper. Proof is the scarce good now. Teams that internalize that swap early are going to ship faster and sleep better — the rest are going to keep discovering, one incident at a time, that green was never the same thing as correct.