Late-night developer running Claude Code with a 1-day estimate that finishes in 10 minutes

One-Day Estimate, Ten-Minute Run

Late at night, I often have to decide whether to call it a day or start the next item in my backlog. Recently, Claude Code estimated a task at 1 full day of work. I ran it anyway. It finished in 10 minutes.

Ask Claude Code how long a change will take, and it regularly quotes 4 hours or 2 weeks (Reddit, Facebook). Tell it to go ahead, and the code is done in 5 minutes.

The model learned this habit from its training data. Claude was trained on millions of Git repositories, Jira tickets, Linear issues, pull requests, and Slack threads. When human software engineers give an estimate to a product manager, they pad the numbers. A 4-hour estimate accounts for getting coffee, waiting on slow CI pipelines, writing tests, and protecting the weekend. Claude reads human ticket estimates and repeats the same sandbagging.

If you want a real number, ask for agent execution time in minutes: "Estimate the time in minutes based on your own automated execution speed as an AI agent." You can also ask Claude to list the required file reads, code edits, and shell commands, then estimate each step. Adding up individual tool calls keeps the model from quoting human project timelines.

Inflated estimates make late-night triage tricky. A “1-day” quote could mean 5 minutes of automated edits or 2 hours of manual debugging. I look at what the code changes will touch:

  • Local refactoring (like adding an async feature to a standalone driver crate) takes 5 to 15 minutes. Start it. The changes stay in one place, and Claude handles localized syntax updates well.
  • Isolated micro-features (like a helper method or enum mapping) take about 5 minutes. Start it, since clear boundaries usually compile on the first pass.
  • New hardware or protocol support (like writing a new e-paper driver layer) takes 15 to 30 minutes to generate, but you’ll spend hours debugging it by hand. Call it a day. The model frequently invents register addresses or timing values when reading hardware specs.
  • Dependency and build fixes (like resolving strict no_std constraints or compiler errors) have no predictable timeline. Call it a day. Claude easily gets stuck in a loop where fixing 1 compiler error causes 2 new ones.

Before starting a backlog item at midnight, I run one check:

List the exact files and functions you plan to modify, along with any compiler or logic edge cases you expect. Wait for confirmation before editing.

If the list is short and stays inside 1 or 2 files, start the run. It’ll probably finish while you get a glass of water. If the plan touches multiple modules or tricky build dependencies, close the laptop and go to sleep.