The work looks convincing before it has been checked
This is one result from the free test Is Evidence Keeping Up With Your Output? Your checking is not broken and your tools are not the villain. The two speeds have separated. Producing something that looks finished got dramatically faster, and finding out whether it is right did not, so appearance now arrives well ahead of evidence.
Only one side of the loop got the upgrade
The test compares two distances: how much work remained after the tool's first version, and how much faster a useful correction arrives than it used to. You answered that the first shrank a lot and the second barely moved. That gap is the result.
This is the specific thing that changed in the last few years. Previously, effort was a rough proxy for scrutiny. A document that took a day had a day of thinking inside it. That proxy is now broken, and nothing replaced it, so we are still reading polish as evidence of care.
You can see the same gap measured elsewhere. Analyses of engineering teams with heavy AI adoption report large increases in merged pull requests alongside sharply longer review times. The output side scaled. The verification side did not, and became the constraint.
Fluency is doing work it was never entitled to do
We learned to read confident structure as a signal of competence, because for most of human history producing confident structure was expensive. Coherent prose meant someone organized their thinking. Working code meant someone understood the problem.
Generation removed the cost without removing the signal. The output still looks like the product of understanding. Nothing about its surface tells you whether the understanding happened.
The practical consequence is that your readiness judgment is now firing on the wrong input. You feel done when the artifact looks done, and that feeling now precedes the evidence rather than summarizing it.
Where the gap shows up
A four-page competitive analysis produced in ninety seconds, formatted, sourced, and confident. Reading it carefully enough to catch a wrong claim takes an hour. It gets fifteen minutes, because it does not look like it needs an hour.
A pull request of six hundred lines from an agent, written in one pass. Reviewing six hundred lines properly is most of a day. It gets the same review budget a hand-written sixty-line change used to get.
A set of AI-drafted answers for a support macro library. Twelve of them. All plausible. Verifying twelve policy statements against the current policy takes longer than writing them did, so nine get skimmed.
The pattern is constant: volume went up, per-item scrutiny went down, and nothing announced the change.
The unhelpful answer is "review more carefully"
It fails for a boring reason. Careful review does not scale with generation. If you produce five times as much, you do not have five times the attention, and asking for it produces a slow team that still misses things.
The useful move is to stop trying to match volume with attention, and instead change what counts as ready. Right now, "ready" fires when the work looks complete. It has to fire on something else.
Give readiness a different trigger
- Define ready as "one outside check has finished," not "the draft is done." Write the sentence down for one kind of work: this is ready when the comparison against the reference has passed. Now polish cannot end the task, because polish is no longer the condition.
- Attach the check to the send step. A readiness rule you have to remember loses to a document that already looks finished. Bind it to the step where the work leaves you, so the appearance never gets to decide alone.
- Spend the whole check budget on one claim. When volume rises, spreading attention evenly makes every item shallow. Pick the single claim per item whose failure would change the decision, and check that one properly rather than skimming all of them.
You know it is working when the moment a piece feels finished and the moment it is allowed to leave are two different moments, and you can name what happens in between.
The boundary
This is not an argument for producing less. Faster first versions are genuinely valuable, and slowing generation to match a slow check is paying twice for the same problem.
It is also not universal. Reversible, private, low-cost work should ride the speed with no gate at all. Apply the readiness rule to work someone will act on and that is expensive to take back.
One warning about sequencing. If your check has no independent answer behind it, making it a release condition will just certify the same mistake faster. Confirm you have a real falsifier first, at Nothing outside the work can prove it wrong, before you make it a gate.