It is 4 PM and you have been "almost done" since lunch. The agent wrote the first version of the feature in eight minutes. Since then you have read its diff three times, asked it to fix a test it brok
Markdown supported · ⌘↵ to post
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.
Kartik N V J K
AI Developer | Making AI reliable, trustworthy & accessible to everyone | Active community contributor
On tests for code that already works, the wrong test I run into doesn't fail loudly. It asserts whatever the code does today, bug included, and goes green. So I check where each expected value came from before I trust a generated test.