The perception-gap framing is useful, and I think the 'correction budget' idea could be made sharper by making it measurable per task type. If a team logged agent-assisted PRs with a couple of fields (number of review rounds, whether tests were edited by the agent, and time from first draft to merge), they could compare those against hand-written PRs of similar size and see which categories actually pay off rather than relying on feel. The point about the agent fixing a failing test by changing the assertion deserves a guardrail of its own: a CI rule or review checklist item that flags any diff where test assertions change in the same commit as source code. I'd also be curious whether you see the post-merge cost, such as reverts and follow-up bug fixes within two weeks, as a better signal than review time alone, since that is where the hidden cost of large diffs seems likely to show up.