Can a Candy Bar Price a Code Review?
In the mid-1990s, ten daycare centers in Haifa had a problem: parents showed up late to pick up<br>their kids. A teacher had to stay late every time, unpaid, waiting. So the daycares ran an experiment.<br>Six of them introduced a small fine for picking up more than ten minutes late.
Late pickups didn’t go down. They roughly doubled, and stayed doubled even after the fine was later<br>removed.
Why it backfired
Uri Gneezy and Aldo Rustichini, the economists who ran the study, had the following explanation: before the<br>fine, showing up late meant a teacher was doing you a favor. That’s a social obligation, and guilt is a<br>strong incentive. After the fine, showing up late meant paying a few dollars for an extra twenty minutes<br>of babysitting. That’s a monetary transaction, and a cheap one. The fine didn’t put a price on lateness<br>– it announced that lateness was for sale, and named the price.
Removing the fine afterward didn’t restore the guilt. Once a relationship has been reframed as monetary,<br>you can’t reframe it back by changing the price to zero. It’s one of those findings that ruins a whole<br>category of intuitive fixes once you’ve seen it: you cannot assume that pricing an undesirable<br>behavior discourages it. Sometimes it just legitimizes it.
Code review has the same shape
Most code review still runs on the pre-fine mechanism. Nobody invoices you for reviewing a coworker’s<br>PR. You do it because you’d want the same back, because norms say so, because leaving someone’s PR<br>unreviewed for three days feels bad. It’s a social obligation, held together by reciprocity and mild<br>guilt – exactly like the daycare pickup, before anyone touched it with a price.
And that mechanism is changing. AI-assisted coding didn’t make review easier – it made there be far<br>more of it. A Faros AI telemetry study from July<br>2025 tracked more than 10,000 developers across 1,255 teams. The ones that relied hardest on AI, merged<br>98% more pull requests, and bigger ones – average PR size up 154%, review time up 91% – with no<br>matching gain in whether any of it actually shipped faster. That’s a correlation across teams, not proof<br>that AI caused it. But the shape is hard to miss: the bottleneck moved from writing code to reading it,<br>and nothing in the workflow says so. A 600-line PR and a 60-line PR show up in the queue looking<br>identical – one line in a list, no cost attached, no signal that one of them is going to eat someone’s<br>afternoon.
The obvious fix is to supply the missing signal: estimate what each PR will cost to review, in minutes,<br>and post that number right on the PR. Which should make you nervous, because that’s what the<br>daycare did. But the daycare did two things at once: it named a price and it collected the money, and<br>the study can’t tell you which half did the damage. That number only does the first half – it says what<br>a review will cost and collects nothing. So maybe the danger doesn’t transfer: the sharp end of the fine<br>was the invoice, and there’s no invoice here.
Someone pulled those two halves apart, though, and the result isn’t reassuring. Not with daycare<br>pickups – with candy. Heyman and Ariely had people do a dull little task – dragging shapes across a<br>screen – in exchange for a gift, and told one group exactly what the gift was worth: “this retails for<br>50 cents,” with no money changing hands. That group stopped working like they’d been handed a favor and<br>started working like they’d been paid – effort dropping when the gift was cheap, rising when it was<br>pricey, the shape of an actual wage. Naming a price, with nothing payable, was enough by itself to flip a<br>favor into a transaction.
Which leaves us with a question: does a bot commenting “this PR costs about 40 minutes of someone’s<br>attention” do to a code review what naming the candy’s price did to a favor – flip it into a<br>transaction?
I don’t know – but I don’t think the candy study gets the last word here, because a pull request isn’t a<br>wrapped gift. And notice who flipped in that experiment: the person doing the work, which in a code review<br>is the reviewer. The number doesn’t land on the reviewer first, though. It sits on the PR, so the person<br>who sees it before anyone else is the one who wrote it – and the two of them read it completely<br>differently. Take them one at a time.
Start with the developer, the one being nudged to split. The candy priced your own effort. This number<br>prices what you’re about to ask of someone else – which is exactly where the reciprocity and mild<br>guilt that ran code review in the first place still live. A 50-cent gift labeled “50 cents” just feels<br>cheap. But a PR labeled “two hours of a colleague’s afternoon” might not read as now it’s a<br>transaction. It might read as that’s a big thing to ask – the same guilt code review always ran on,<br>only now with a number making it concrete. So the very same label could cut two ways: it could let the<br>developer off the hook – I paid the toll, we’re square – or press the...