Reading Claude's code out loud dropped accept rate to 40%
For about a year, a developer worked by letting Claude write a , skimming it, and accepting it if it looked reasonable — fast and satisfying in the moment, but it led to repeatedly on a Thursday something accepted without real understanding on Monday. Two months ago, they set one rule: before accepting any change, read the changed lines out loud, actually moving their mouth, not just skimming. Having to explain the code to an empty room forces real understanding, and that process catches things the eye slides past on a skim — a variable name spelled almost right, an handled confidently but incorrectly, or a function that works fine but solves a problem that didn't actually exist.
After adopting this habit, the accept rate dropped from nearly 100% to around 40%, and bugs dropped even more. Most of the remaining 60% wasn't the model being wrong — it was the developer stopping to ask "wait, why this approach," engaging instead of nodding, and getting a better answer as a result.
Key points
- Spent roughly a year skimming and accepting Claude's diffs quickly, then losing time later code never truly understood
- Adopted a rule two months ago: read every changed line out loud before accepting it
- Accept rate fell from near 100% to about 40%, with an even bigger drop in bugs
- Most of the rejected 60% wasn't bad model output — it came from asking follow-up questions and getting better answers
- Key takeaway: as models improve, it's easy to become a , so a deliberate habit is needed to stay engaged in review