AI compresses the work of writing code, and most of the work around it: documentation, test-case drafting, the operational setup. It does not compress the manual verification that confirms a high-stakes output is actually correct. So the estimate keeps its size in some lines and loses it in others, and the ratios we used to estimate by stop holding.
On a project we just finished, development came in at 220 hours and quality assurance came in at around the same. A year ago the build alone would have run well over 400 hours by hand. And on the QA rule we used then, a third of the development we actually ran, we would have set aside about 70 hours for it.
This is not a one-off. We have shipped a handful of AI-built projects through 2026, and the same gap has shown up across them: development keeps compressing, verification does not. This is the one where we instrumented it closely enough to trust the numbers, and it changed how we scope the next one.
The project
This was a small project for a startup, promoting an early prototype to a proper-quality MVP. A greenfield build on Supabase with a React frontend, written AI-first from the start. It renders documents that have to match an exact format. When the format is wrong the document gets rejected downstream, and a rejected document is lost revenue, so “looks about right” was never going to be good enough.
Speed did not come from cutting corners. Delivering it at roughly twice the pace of a hand-written build was not a matter of skipping the work that protects it: the build shipped with strong automated unit coverage on the backend and the infrastructure automation underneath it, more than a budget this size usually buys, because AI made both cheap to build. The point of saying so is that the QA load below is not a sloppy build catching up with us. It is the cost of verifying a correct build against a bar that does not move.
The line that did not move
The amount of product you have to check by hand is set by the product, not by how fast the product was built.
The number of formats to verify, the edge cases that change revenue, the real documents to run through the system: none of that got smaller because the code arrived sooner. It arrived sooner and then sat in front of the same verification it always needed.
AI helped on either side of that verification, drafting and automating faster. What it did not do was make the judgment call at the critical path: does this output actually clear the real-world bar. That call stayed manual, because the cost of being wrong is paid in revenue. An automated check we have not yet confirmed against reality is not the thing standing between the client and a rejected document.
The flip, in numbers
For years we estimated QA at roughly a third of development time. It was a fair rule when development and verification scaled together. On this project the rule broke:
- Old rule: QA ≈ 1/3 of dev. At 220 dev hours, that budgets about 70 hours of QA.
- What happened: QA came in at 213 hours, almost exactly level with development.
The rule did not just become inaccurate. It failed in the dangerous direction. It would have under-funded the one part of the work that got larger relative to everything else, on the project where being wrong was most expensive. If you anchor QA to dev hours and AI keeps halving dev hours, you will keep cutting the verification budget precisely as the amount to verify holds steady.
QA signs off the behavior, then automation freezes it
So why didn’t that cheap automation, the backend coverage and infrastructure work above, take the place of the manual QA?
The answer is sequencing. An automated test freezes a behavior so the system cannot drift away from it later. You can only freeze a behavior once someone has confirmed it is the right one. During development that confirmation is a QA signing off on what correct looks like, against real documents, by hand. On a high-precision output, where the bar is an exact format a person downstream will accept or reject, that sign-off is the work itself, and the automation captures it rather than producing it.
So the manual verification and the automation are two steps in order, not two ways of doing the same thing. The verification happens now, at full size, because it is the prerequisite. The automation pays off later, in maintenance: once the behavior is frozen, the tests hold it in place every time the system changes, and the infrastructure absorbs the change without hand-holding. On a greenfield build there is nothing to hold in place yet, which is why the payoff sits in the future, not in the first pass. They are two different lines in the estimate, and collapsing one into the other is how you under-fund the work.
The constraint moved
There is a second effect that does not show up in the totals. Development ran at AI pace, which meant work arrived at QA faster than QA could clear it. The bottleneck moved. For a decade the slow step was building the thing; here the slow step was confirming it, and the queue formed in front of QA instead of in front of the developers.
How we scope it now
Two assumptions in the baseline moved, and both are straightforward to price in. We assume the build takes far fewer hours now, because AI compresses it. And we assume a higher quality standard inside the same budget, because the automated coverage and infrastructure work that used to be the first line cut are now cheap enough to include by default. Less development, more quality built in, the same envelope.
The change that is easy to miss is the QA line. We scope verification from the product, not from the development estimate. We list what has to be checked and how exactly, then size that directly.
Development hours inform the schedule, but they no longer set the QA budget. That is the correction that keeps an estimate from quietly under-funding the work AI just made larger relative to the build.
Two disciplines did not change, the finding only raises the stakes on them. Automated coverage and manual verification were always separate lines, one a maintenance asset and one a present cost; now that AI lets us afford far more automation, keeping them apart matters more, not less. And precision was always priced by what a wrong output costs, not by how the code was built.