Claude sized up a feature for me today. I hadn't asked. Before it started, it dropped this on me:
Rough size: about 4-5 days for backend, picker, optional publish-time ID check, and tests. Nothing blocks it.
We shipped it a few hours later.
What makes me laugh isn't that the estimate was wrong. Estimates are always wrong; I spent enough years producing them to know that. It's that the estimate came both unbidden and in days. Not tokens, not context windows, not "about three PRs". Days, with "nothing blocks it" on the end, like it was reporting to a standup it had never been invited to.
For now, everything a model knows about estimating software it learned from humans estimating software. Humans estimate in days because humans have calendars, and the number is mostly about the calendar: the meetings, the review that sits overnight, the context switch after lunch, the person in another time zone. "Four to five days" is a week of being a person at a company. The model inherited the unit and none of the week.
The corpus isn't a great teacher. Kahneman and Tversky named the planning fallacy in 1979[1], Hofstadter wrote his law the same year[2], and people have been confidently, specifically wrong ever since. Claude reproduced that faithfully. It just got the direction backwards. Humans undershoot. Claude, speaking in human days about machine work, overshot by most of a working week.
For the record, I don't size things in days anymore, and haven't for a while. The question isn't how long a piece of work will take, it's how much meaningful work I can have in parallel without becoming the bottleneck. That's what the hundred measures. Duration stopped being interesting once the answer was always "sooner than I can review it."
That's all the quirk is. The training data describes a world where this took a week, and the model hasn't noticed it's living in the one where it doesn't. I expect that fixes itself once the corpus is full of its own PRs. Until then I read the days, divide by ten, and get on with it.