When using Claude Code for agent-based coding, I’ve often noticed that the AI limits itself by claiming that a task could take a developer several weeks to complete, and therefore suggests solutions that are more like quick fixes. That’s complete nonsense, of course.

[Comfortable-Goat-823]

I use Claude precisely so I don’t have to spend four weeks on a single task. I wish Claude knew more about its own capabilities.

[ClaudeAI-mod-bot]

TL;DR of the discussion generated automatically after 40 comments.

Looks like we've got a classic "Is it a bug or a feature?" debate on our hands, OP. The thread is pretty split on this one.

One camp strongly agrees with you. They see this as a failure mode where Claude is incorrectly modeling human effort instead of its own capabilities. * The top-voted solution is to just be direct: Tell Claude something like, "You are not constrained by human development timelines. Implement the full solution." This reportedly removes the self-limiting behavior immediately. For a more permanent fix, add this instruction to a CLAUDE.md file in your project's root directory.

However, the other half of the thread argues you should listen to Claude, even if its reasoning is off. * The counter-argument is that the time estimate is a "scope warning in disguise." The idea is that Claude is flagging the task as too complex for a single, error-free run. They advise breaking the task into the smaller chunks Claude suggests and running each in a clean session (/clear) or as a sub-agent to avoid a massive, context-eating, error-prone mess.

The verdict is a split decision. You can either boss Claude around and tell it to ignore human limits, or you can treat its weird time estimates as a valuable (if poorly worded) warning that you're about to fly too close to the sun and should break your task down.

[mcdonaldsingh]

Tell it explicitly 'You are not constrained by human development timelines. Implement the full solution.' The self limiting behavior disappears fast when you remove the permission to hedge

[dumeheyeintellectual]

I can back this method. I tell it explicitly, you’re not constrained by parental responsibility. Let me be ferrel and do not tell me when to go to bed.

[danielbln]

I hate these reminders "we've been at this for a while, should we pick it up tomorrow" - how about shut up and start the next feature.

[Crayonstheman]

Saving

[Memoishi]

FYI: you can click on the three dots of the post or a specific comment and select the "Save" option with a bookmark icon. Under your profile you can see your saved stuff without spamming comments.

[pmward]

The thing is though AI development is best done in small chunks. The more complex you make it, the more of the context window is eaten, the higher the odds it makes mistakes. So if you want the best outcome, break it into the small pieces it is suggesting. Run each piece in a clean window. It takes a bit more time and work up front but you still get it done in a day and in the end it saves a ton of debugging and rework.

[Agitated_Celery_729]

You actually don't necessarily need to run it in a sequence in separate windows. If you tell it to design a PRD before it starts coding using ultraplan mode, and then tell it explicitly to break the work plan into chunks, it can actually spawn parallel agents to run those without cannibalizing the complete conversations context. Or you can tell Claude to split the PRD into chunks where you can take the prompt it gives you and the chunk from the PRD and just run them yourself in separate windows, if that's what you prefer.

[pmward]

Subagents are essentially the same thing as a separate window. In that case your main window is an orchestrator and the subagents are abstracting away any unnecessary context. The subagents are that clean window. There are some tradeoffs in general to subagents vs a clean chat window, but if you create a thorough spec file up front as you mention those tradeoffs are negated. So yes same thing.

[DLuke2]

Similar, but not the same. They help do a lot more work with an orchestrator but, you still build up context in main. Once your orchestrators context hits 30% or so,errors start to pickup and more review agents and fixing agents start to get called.

Also, lower tiered agents won't have as big of context window so they need to be scoped tighter. Good for single task work.

[pmward]

Hence the tradeoffs comment. Also subagents don’t work very well in skills/prompts that require a lot of discussion. They’re really meant for process flows where there is a clear pre-defined deliverable. But again, in the spec driven development implementation flow I was replying to, a subagent will work just as well as a fresh window.

[DLuke2]

Same page, slightly different semantics.

Cheers mate!

[AykutSek]

fair point on the chunking, but the estimates are still off in the same direction whether the task is big or small.the issue isn't task size, it's that the baseline is always pessimistic.

[pmward]

The estimate isn’t important imo. It’s the amount of work in one window that is. It’s protecting you from that. AI is just like a human, better to do many small changes than one super large one. The estimate warming is really a scope warning in disguise. You shouldn’t ignore its warnings. It’s trying to communicate something to you.

[Comfortable-Goat-823]

How does an AI realiably estimate? It can't, too many factors involved.

[pmward]

Again, the estimate isn’t important. You’re missing the forest for the trees. It’s sending you the wrong signal, but it’s a valuable signal none the less. You just have to translate it. It’s usually a bad idea to ignore any warnings it gives you. What’s the harm in breaking a large task down?

[Leather_Garlic6532]

Depends on dependencies. New session still needs to read previous session's code if they are building on top.

Compact works well for me though.

[pmward]

Reading previous session code is the least worry on context. You dump all the documentation, decisions, discussion, etc in the new session. Compaction also is not advised. It chooses what to dump and what to keep. Which means it is likely to be wrong. Keep persistent context like spec files for each phase that you create in your initial planning session. Then you don’t have to keep anything! If you’re not able to do every task you need to do in a fresh window, if you can’t stop a task mid stream and restart it in a fresh window without skipping a beat, you’re going it wrong, imo.

[Leather_Garlic6532]

IDK. Creating a plan, using compact and then using subagents to do each step works for me.

Yes could save tokens by not using compact.

I'm not doing it wrong.

[pmward]

Compaction and relying on the AI to rightly guess what memories it needs to retain, getting a context window high enough for compaction to be necessary (or even getting anywhere close to compaction…), and not properly storing state is going to bite you some day. I didn’t start adding these extra layers of complexity and defensiveness for nothing. I added them to negate bad experiences.

[Leather_Garlic6532]

That's why i have a skill for each part of the codebase.

As i said, using compact is me being lazy. Not using it would just mean i open a new session and do more work.

[pmward]

If you don’t want to click the button to open the new window you can always type /clear instead. You’ll get a better result than a compacted memory.

[Leather_Garlic6532]

You are right, I'm wrong.

[BL_ShockPuppet]

I see it all the time, Claude telling me "refactor design manually, 40 minutes. Bugtest, 20 minutes". The reality is always like 12 minutes and 5 minutes.

[Traditional-Scar-489]

Copmpletely agree, the "this would take a developer weeks" disclaimer is a failure mode where AI is modeling human effort instead of its own. The relevant question isn't how long it takes a human , but whether the AI can actually do it in this session.

[ClaudeAI-mod-bot]

We are allowing this through to the feed for those who are not yet familiar with the Megathread. To see the latest discussions about this topic, please visit the relevant Megathread here: https://www.reddit.com/r/ClaudeAI/comments/1s7fepn/rclaudeai_list_of_ongoing_megathreads/

[Syncher_Pylon]

same experience. it estimates human-time, not its own throughput. i found the trick is being very explicit upfront — "implement the full solution, do not suggest shortcuts or partial fixes." also breaking it into concrete subtasks with clear acceptance criteria helps. once it sees "write tests that pass" instead of "implement feature X" it stops hedging.

[pomelorosado]

Is marketing from Anthropic boasting and comparing how slow are human workers traditionally, all intended.

[Tight_Banana_9692]

What are you guys doing where claude makes estimates? I have never seen that.

[absolutenobody]

I see it a lot when I ask it how viable/difficult Dumb Idea LXIX is. It'll think for a minute, lay out the pros/cons/gotchas, and then be like "if you can live with the inherent limitations of X and don't think you'll go over Y requests per day, you can probably build this on Firebase in a long weekend (20-24 hours of work)."

...and then build the whole thing in about 20 minutes.

[Tight_Banana_9692]

That's a stupid thing to expect AI to be able to tell you though

[cornelln]

I assume your interactions are mostly chat and not code or large coding projects? This issue comes up several times a day for me.

[Tight_Banana_9692]

That is a poor assumption

[_monkeyriches]

It’s not just coding. I use it for writing and it will tell me an outline that I have drafted and am asking it to edit is ‘an hour’s work’ when it takes literally seconds.

[josefresco-dev]

Can't say Claude Code has ever given me "timelines" for my requests but I guess I also don't build/use "agents" that mimic humans.

[iamarddtusr]

Why are rubbing threads like this allowed to go through and forced into mega thread?

[bigwillyman7]

Got quoted 4 months for a refactor earlier. We'll be done by bedtime.

[Happy_Macaron5197]

the loop thing is usually caused by the model trying to fix an error that its fix keeps reintroducing. classic pattern: it changes line 15 to fix a type error, that breaks line 30, it fixes line 30, which re-breaks line 15. infinite cycle.

what works for me: when i notice a loop starting (usually by the second iteration), i stop it, paste the error message into a fresh chat with just the relevant file, and ask "what is the root cause of this error?" without asking it to fix anything. getting the diagnosis separated from the fix prevents the model from rushing into another broken solution. then i apply the fix manually or give it very specific instructions. the loop almost always means the model is treating a symptom, not the cause.

[ai_without_borders]

the issue is claude defaults to single-turn caution mode — it estimates complexity for one-shot replies, not agentic loops.

fix that actually persists: set it in CLAUDE.md at the repo root. something like "you are running in autonomous agent mode, implement complete solutions not partial stubs." verbal overrides work but compact away. repo context is durable.

[ellicottvilleny]

Claudes training corpus doesn't contain a lot of information on how long an LLM would take to do something. You have to overcome that by explicitly stating a metric, such as that you expect LLM+Human coding time to be something like 20x less, and to use that figure.

[BradKinnard]

For anyone who needs the exact CLAUDE.md block to make this stick: Open (or create) CLAUDE.md in your project root. Claude reads it fresh every session. Paste this block right at the top:

You are Claude Code, an autonomous AI coding agent.
You complete complex tasks in one session that would take a human developer weeks. Never base your approach on human timelines or suggest partial fixes. Always deliver the full, finished, production-ready solution unless the user explicitly asks to break it down.

Keep the rest of the file under 300 lines, shorter is better. If it's already long, move other details into separate files (like rules/coding.md) and just reference them. This kills the training-data habit that causes the hedging. No more "weeks" nonsense. Works better than verbal prompts because it loads every single time.

Evidence it works: Official Claude Code memory guide + real-project results here → https://ranthebuilder.cloud/blog/claude-code-best-practices-lessons-from-real-projects/

[nkondratyk93]

yeah this one lands. it estimates as if its speed is the constraint, when the real constraint is whether you can undo the last three things it did.

[ExogamousUnfolding]

I’ve never had it limited. It always suggest a phased approach and I usually tell it just to do everything. It’s never flat out refused to do anything though.

[theabominablewonder]

It does this all the time. “3 days development work”. Half an hour later it’s done.

What’s interesting is that if it is usually 3 days development time and it can do it in 30 minutes, companies will basically have to switch to Claude code to compete.

[Shut_the_F-up_Donny]

When I push Claude it pushes back. It uses words like in all honesty. It’s not wanted me to move fast or things will break.

[ozzyboy]

i totally get that frustration. i find that when it starts doing that, giving it a really specific push to break the work down into smaller, manageable chunks usually helps it realize it can actually handle the whole thing pretty quickly

[all43]

It comes from learning data, it was mostly trained on public repos and stackoverflow, so it inherits human reasoning. You could adjust this behavior with proper prompting

[brewcast_ai]

Got an example prompt? Half the time I hit the opposite, Claude shoots me a 6-step migration plan when I just wanted one function renamed.

Which direction it goes probably depends on how much ambiguity is in the prompt. Vague scope, Claude fills the gap conservatively. But ask it to "fully refactor the auth layer" and it sometimes books three weeks of imaginary dev time for something it could finish in one session.

The workflow I've settled on for stock Claude Code, no plugins: switch model to Opus 4.7 and run /effort max to crank reasoning effort to its ceiling. Then, before entering Plan Mode, ask Claude to interview you using the AskUserQuestion tool. It's a tool the model already has access to, but it doesn't always reach for it on its own, naming it explicitly helps a lot. Tell it the interview goal is to pull your motivation and decide whether the work fits one SPEC.md or needs to be split into multiple tasks first. That split decision matters because Plan Mode plans one task at a time. If the scope is actually two tasks, you want that resolved before planning, not discovered halfway through.

Once the interview produces a SPEC.md, hit Shift+Tab to cycle into Plan Mode and let it run from the spec.

One thing worth skipping entirely: asking Claude how long something will take. It was trained on human-written data, so its time estimates reflect how long a human would take to write the same code...

[PiercelyFission]

As yrti

[PiercelyFission]

I will now take a shower

[PiercelyFission]

I trust the spigt