What surprised me most here is not that Claude Code overestimates. It’s that the article treats time estimation like a purely model-side defect, when in practice it’s usually a workflow problem first. If you ask a coding agent, “How long will this take?”, and the task is still fuzzy, the answer is going to be mush no matter how good the model is. Humans do this too.
The piece is right about one thing, though: out-of-the-box estimates from Claude Code can be wildly anchored to human-era assumptions. If the model has mostly seen internet-era project timelines, then “3–4 weeks” for something that a developer with an LLM can knock out in a day is not some shocking failure. It’s a mismatch between the data it learned from and the way we’re using it now. That part makes sense to me.
Where I’m less convinced is the idea that the fix is mainly “train it on your own historical task durations” via a skill or a markdown file. That sounds useful, but I’d be careful about overselling it. Historical data only helps if your tasks are genuinely comparable, your team is consistent about logging start/finish times, and the work isn’t constantly shifting under your feet. In real software work, those conditions break all the time. A clean estimate history is nice in theory; in practice it turns into half-remembered issue notes and weird outliers.
The more interesting suggestion is the second one: estimate smaller subtasks and explicitly ask the model to think in terms of LLM-driven execution, not human-only execution. I think that’s the part people should actually try. Not because the model “knows itself” in any mystical sense, but because breaking work into research, implementation, and testing forces you to expose the hidden assumptions. It turns a vague gut-check into something you can interrogate. Even if the final number is still wrong, it is usually wrong in a more legible way.
Still, I wouldn’t trust an LLM to be the source of truth for scheduling. I’d treat it as a planning aid, then sanity-check the result against my own experience. If you already know a feature is a half-day task, Claude telling you it’s a month-long project isn’t a data point; it’s a signal that your prompt is underspecified or the model is leaning on stale priors. That’s useful, but only if you read it that way.
What I take from the article is simple: coding agents are bad estimators when you ask them to pretend they’re humans from 2021. They get more useful when you give them your own team’s history and force them to estimate like a tool-assisted developer, not like an abstract software consultant. That sounds right to me. Just not magically right.
Reference: Why Claude Code Time Estimates Are Poor | Towards Data Science
