The Library · Perspective
QA is not the thing to cut
Generation raises the volume of code and lowers the cost of producing it. Neither of those reduces the need to find out whether it is right — both increase it.
The argument for cutting QA in the age of generated code runs roughly: the model writes the tests too, so the expensive human step can go. The argument is wrong in a specific and checkable way, and the mistake is worth naming because the cut is being made.
The tests and the code come from the same place
A test written by the same process that wrote the implementation, from the same description, encodes the same misunderstanding twice. It will pass. It confirms that the code does what the code does.
This is not a flaw in the tooling. It is a structural property of using one source for both the claim and the check, and it is why independent verification exists at all. The value of a test has always come from the difference between the tester's model of the problem and the implementer's.
What actually changed
Three things, none of which point toward less QA.
Volume went up. More code is being produced per engineer-hour than before. Defect density per line may be flat or better, and total defects still rise with volume.
The defects moved. Generated code has fewer syntax errors, fewer obvious null-handling mistakes, fewer typos — precisely the class of defect that automated checks and compilers already caught cheaply. What remains is the class that requires understanding intent: right function, wrong requirement; correct in isolation, incoherent with the rest of the system; handles the stated case and not the one the customer actually has.
Plausibility went up faster than correctness. Output reads well. Reviewers are calibrated on a world where code that reads well was usually written by someone who understood the problem, and that correlation is weaker than it was.
On the left, a claim and its check leaving one origin: they agree, and they fix nothing. On the right, two independent origins crossing — and the crossing is the only thing that locates a point.
What QA should be doing now
The role shifts rather than shrinking, and it shifts toward the parts that were always the hardest.
- Requirements interrogation, before implementation. The highest-leverage question is now "is this the right behaviour," asked early. Generation has made building the wrong thing much faster.
- Adversarial and exploratory testing. The unscripted work — trying what nobody specified — is exactly the work that cannot be generated from the specification, because it is defined by being outside it.
- Cross-cutting properties. Does this change violate an invariant three modules away? No local test asks this, and no local generation considers it.
- Judging the test suite itself. Someone has to assess whether the tests are meaningful or merely green. Coverage was always a weak proxy; against generated tests it is weaker.
The economics
Cutting QA reduces a visible line item and raises an invisible one. Defects found by customers cost more than defects found internally — in engineering time to reproduce and fix, in support load, and in trust, which is the expensive one and the slow one to rebuild.
That relationship did not change when generation arrived. What changed is that the rate of change entering the system went up, which raises the value of the function that decides whether the change was correct.