The verification gap nobody budgets for

Look at any engineering budget and you'll find the cost of writing code. Seats for coding assistants. CI minutes. Cloud bills for preview environments. It's all there, itemized, reviewed every quarter.

Now look for the line that pays for checking whether the code works. Usually there isn't one. Verification is paid for anyway, just not on purpose. It shows up as a senior engineer's afternoon spent reviewing a diff they didn't write, as a weekend on-call page, as a support ticket from a customer who found the bug first.

We call this the verification gap, and we think it's the most underpriced problem in software right now.

Generation is cheap, reading is not

Here's a scene that will be familiar to anyone shipping with agents. A coding agent produces a 600-line pull request in a few minutes. It touches the cart, a pricing helper and two templates. It includes tests, and they pass.

Reviewing that pull request properly takes the better part of an hour. You have to understand what was asked, what was changed, and what else depends on the changed code. Most reviewers, being human and busy, don't spend that hour. They read the summary, skim the diff, see green checks and approve.

The cost of producing code dropped sharply. The cost of understanding it didn't move at all.

Green tests from the same author

The green checks are the part that worries us most. When the same agent writes the code and the tests, the tests tend to share the code's assumptions.

Say the ticket reads "free shipping on orders over $50." The agent implements total >= 50 and writes a test that asserts a $50.00 order ships free. Everything is consistent. Everything is green. And it may be wrong, because "over" might mean strictly more than $50, and the marketing page promised exactly that. Nobody checked the code against the ticket. The tests checked the code against itself.

This isn't a knock on agents. Humans do the same thing when they write tests for their own code. The difference is volume. When one person writes ten features a month, a reviewer can keep up. When agents help that person write forty, the review becomes a formality.

Where the cost actually lands

Because nobody budgets for verification, its cost lands wherever it falls:

• On reviewers, as a growing pile of diffs they can't read carefully.
• On whoever is on call, as incidents that a five-minute check would have caught.
• On support and customers, as bugs discovered in production.
• On the release calendar, as freezes and "let's wait until Monday" that slow everyone down.

Each of those is real money. None of them shows up as "QA."

What a budget would buy

If teams did budget for verification, what would they want for the money? We keep coming back to three things.

First, checks that run on every deploy without anyone remembering to run them. Second, someone, or something, that looks at what changed and goes poking around in exactly those places. Third, evidence. Not "looks fine to me," but steps, screenshots and a replay you can watch.

Those three are roughly what we're designing Testomatica to provide. We wrote about where the idea came from in our first post. This week we're mostly reading, because before we build anything we want to know what the research says works, and what only works in a demo.

If your team does have a line item for verification, we'd honestly like to know what's on it.