I asked Claude how long a small side project would take. It said two months. I laughed out loud, alone, at my desk. That is what broken AI project time estimates look like. The habit behind them is judging AI work by the clock.

Two months of what?

Claude doesn't sleep.
Claude has no designer to wait on.
Claude has never once taken a weekend.

Two months is a number a person gives you. A model never earned that number, it borrowed it. And every model I've used does the same borrowing, because it has no other number to reach for.

You do the same borrowing. You expect AI work to take as long as human work, and you read a long timeline as serious work. I checked both instincts against the research.

The short version.

Claude Code quoted 3 weeks for a task that took 126 minutes.
People read time as quality, but a 2026 study found that longer AI generation time raised perceived effort and left quality ratings flat.
People also cut credit for AI-assisted work, even when the output is identical.
The fix is a five-rule CLAUDE.md block, a timed build, and checks in place of the clock.

Claude Code Quotes Weeks for Work That Takes Minutes

Ryan Hoover watched Claude Code reply that the implementation would take 3 weeks. He posted the reply on 23 July 2026 with the line "AI, they're just like us." Then he added an update. It took 126 minutes. Digg's page for the thread holds both posts.

Greg Kamradt sees the same gap whenever a model quotes hours. Models carry old human timescales, he wrote, because they trained on old human data. When one says a few hours, he expects "30 seconds and a few tool calls."

Greg Kamradt, creator of the Needle in a Haystack test, put the pattern in one post.

Kun Chen ran the same test on camera. He asked Claude to estimate a 3D first person shooter that runs locally with AI enemies. The answer came back in days, weeks and months. Then he asked an agent to build it. He says a playable version arrives in a few minutes, because he has run the test many times.

Kun Chen, a former L8 principal engineer who worked at Meta and Microsoft, starts the test at 12:58.

His diagnosis is short. The models trained on human data, so they quote what a typical human developer would quote. He puts it this way: AI does not yet seem to know that it codes faster than humans.

Claude quoted days to months for a game an agent builds in minutes, because the model learned human estimates.

Models Default to Human Timelines Because That's All They've Seen

Every timeline the model has ever read came stapled to human constraints. GitHub issues say "targeting next sprint." Blog posts describe "a weekend hackathon." Job postings assume 8-hour days, 5-day weeks, a commute, a lunch break, and a standup.

Almost no training text records how fast a system with no body and no sleep cycle finishes a task. That example is missing from its training data.

reaches the same diagnosis for Claude Code: "Claude has essentially been trained on human estimates of time."

So it does what it always does when a category of experience is missing. It grabs the nearest pattern, and that pattern is a human describing human work.

The model treats those constraints as facts about software in general. They are really facts about the humans who write software.

My two months quietly assumes four of them:

Nobody works evenings.
A weekend interrupts the work.
Code review adds a wait.
The art asset waits on a teammate.

None of that applies to the model doing the work. Its real bottlenecks are tool call latency and context window size. The context window is the amount of text a model can hold at once. The model never measured two months. It copied the number from every project retrospective it read.

A two month estimate counts evenings, weekends, review and teammates, and none of the model's real limits.

A Wrong Estimate Also Steers the Model Toward Cheap Designs

The number does damage beyond the number. Kun points to what happens when the model chooses between technical options.

The model assumes the expensive options cost more than they do for an agent. So it picks the cheap one. He says those picks are often low quality, hard to scale or hard to maintain.

You never see that choice as a mistake, because no number sits next to it to argue with.

You Believe the Number Because You Count in Sprints Too

The model is not the only one on a human clock. You are on it too.

Two months sounds right to you for the same reason it sounds right to the model. Both of you learned what software takes from people. So you accept the number, shrink the scope to fit it, or never start.

Asana planned on the same clock. The company says removing its Enzyme testing system was expected to take at least 5 years, with a staffing estimate near $6 million.

Codex finished the job in about 2 weeks, and a human reviewed every change. Wes Roth reported the numbers, and they come from Asana, so read them as the company's claim.

Wes Roth reported the Asana numbers on X.

Even the best-known chart of AI progress counts in human time.

defines his version this way: "The benchmark measured the amount of human work that an AI can do with at least a 50% chance of success from a single prompt."

His numbers cover one book cycle. The human work a model completes at 50% success grew from 4 minutes to 17 weeks.

Ethan Mollick, who writes the One Useful Thing newsletter, shared the numbers in October 2026.

The yardstick says how big a task is for a person. It does not say how long the model takes. A reader who skims the chart can still walk away with the human clock in their head.

Kun does not accept the number. He runs the build. His trust comes from repetition, because he has run the test so many times.

Your gut has no run history with agents. It falls back on the calendar it learned from people. This is my claim, and the evidence above is anecdote. None of it is a controlled study.

The Clock Predicts Human Quality and Misses AI Quality

You also read hours as quality. Psychologists call that habit the effort heuristic. Kruger and colleagues tested it in 200400065-9). Participants rated a poem, a painting and a suit of armor higher on quality, value and liking when they believed it took more time and effort.

In the painting test, the story changed from 4 hours to 26 hours and the painting stayed the same. The ratings rose with the hours.

names the same shortcut in AI video: "so much of what makes something interesting is implied effort."

Treat that as a moderate effect, not a law. A 2023 replication with 1,405 participants backed the painting result and failed on the poem. A retest of the poem split. Quality and liking held, and monetary value did not.

Now swap the worker for an AI. The rule changes in three ways.

Time raises perceived effort and nothing else. A 2026 pair of pre-registered studies showed AI artworks with different generation times. Longer times raised perceived effort. They did not raise liking, beauty, quality or monetary value.

A slow algorithm looks worse. A 2020 paper in a decision science journal ran seven studies. People rated slowly generated algorithm predictions as less accurate. Slow human predictions got rated as more accurate. For algorithms, perceived effort did not track quality.

AI help costs credit. Across 11 studies, participants cut pay for workers who used AI, even with output quality held constant. In another experiment, 1,026 engineers reviewed identical Python code. They rated the engineer 9% lower on competence when they believed AI helped.

gives the engineering version of the same gap: "Generating a beautiful chart takes about the same effort for an AI as generating an ugly one."

So the verdict on the bias has two halves. People do read time as quality for human work, though weakly. They do not extend that credit to AI. Longer AI time earns no quality, and AI help earns less credit.

For an agent, the hours on the clock say little about the quality of the diff.

These studies measure judgments, not output. None of them shows that fast agent work is good. They show that the clock is a bad way to judge it.

One Rule and One Timed Build Replace the Clock

Kun's fix is one line in his global memory file, the file loaded into every agent session. His file runs 27 lines. The line tells the agent to give development cost little weight when it chooses between technical options.

The block below is mine. It keeps his rule and extends the idea to estimates. The agent names its own constraints before it gives you a number.

Paste it into CLAUDE.md or your system prompt:

## Timeline and Effort Estimates

When estimating how long a task will take for you (the AI) to complete,
do not default to human work patterns. Your training data overwhelmingly
describes human-paced work: sprints, days off, meetings, context switching,
sleep. You do not have these constraints. Before giving any timeline:

1. State your actual constraints for this task: context window limits,
   tool call latency, number of files or lines involved, verification
   steps required. Do not cite "team velocity" or "sprint capacity"
   unless a human is actually doing that part of the work.
2. Distinguish "how long would a human team take" from "how long will
   you take" as two separate numbers if both are relevant. Never merge
   them into one estimate by default.
3. Express your own estimate in hours or tool call rounds, not in days
   or weeks, unless the task is genuinely bottlenecked on something
   outside your control (human review, external API rate limits,
   a dependency you're waiting on).
4. If you're uncertain, say what specifically is uncertain (ambiguous
   scope, unverified assumption, missing test coverage) instead of
   padding the number "to be safe" the way a human engineer would.
5. When choosing between technical options, give development cost
   little weight. An option that is expensive for a human team can be
   cheap for you.

An hour figure from an agent is still a guess. The block changes the inputs to the guess. It does not make the guess true.

names the cost most estimates leave out: "The cost of verifying that the work is correct has moved much less."

Put verification time inside the number. Rule 1 of the block asks the agent for it.

So check the guess with a build. Tonight, pick one task you would estimate in days. Ask the agent for the number with the block in place. Then run the build and write down the real time.

Then judge the result by its checks. Read the diff and run the tests. The time it took tells you nothing about whether it works.

The gap between the two numbers is the estimate error for your agent and your tasks.

Stop Judging AI Work by How Long It Took