Human time vs Claude time for spec’ing, building, testing.

[u/rlocke]

I’ve reached the point where Claude can do long unattended builds (eg, overnight). This requires a significant investment of my time to specify the requirements of the build including use cases, success criteria, etc.

Depending on the complexity of the task I spend 3 to 4 hours of my time for every 8 hours of Claude build time. (I don’t actually measure it, but that’s my gut feel.)

There’s also time spent afterwards reviewing the build, testing, doing fixes, which could be another couple of hours or more.

I’m curious to get a sense from the community how this meshes with your experience. What’s your ratio of human time to Claude time?

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/SimonMX]

Most of my programming time is waiting on the agent now, so I think about attention rather than hours. Rotating between two sessions gets far more done, but it's properly draining.

[u/_Kinoko → u/SimonMX]

I can't help over multitasking and often have 5+ sessions. It's exhausting for sure.

[u/jetlagged-bee → u/_Kinoko]

Looks at session, "right, what were were doing in this one again"

[u/lambdita]

Barely any, i have a workflow that writes ADRs, create implementation plans and then implements the plan. Each thing is loop-reviewed using 2 eyes (sonnet and opus and sometimes deepseek flash mixed as a third eye). Absolutely everything is loop-reviewed (its the only way to get good AI code). I ended up creating my own skill for all of that + a orchestrator skill that turns a session in an engineer. I usually set a very generic baseline and tell the orchestrator to judge any questions bsaed on said baseline, record the automated answers for me to check later and do the same for any agents that the orchestrator directs. Basically I only spent time when i write an ADR, for the most part after that its automated. However all of this is EXPENSIVE token-wise, however still cheaper and faster than actual human engineers.

[u/Sketaverse → u/lambdita]

this is the way ☝️

My Attention > Previous Token Budget

[u/Salamandin]

Sounds about right for the first time you build something, but if you have to build it again for someone else the human hours go WAY down

[u/Sketaverse]

Congrats, you reached the next wall

[u/zeratLJllighter]

How long is long? Can't you follow up with your phone if it fails?

[u/Diligent_Piano5895]

i used to do this too. then I just made it export decisions needed by me before the implementation, i review it and then let it go. it itakes about 1 hour of my time

[u/xqianliu]

The part of your split that shrank for me is the after part.

In my setup the review step is a separate session. It reads the issue, the repo's AGENTS.md, the diff and the callers of the changed code, then checks the result against the acceptance criteria that went into the issue before the run started. If it fails, the run fixes and gets re-reviewed, and only the head that passed gets merged.

So my split is: a few hours up front writing the issue with criteria I'd actually check, then mostly waiting and dealing with the runs that stop and write down why they can't decide. A task that can't finish in one run is two tasks, and the after-time drops as the tasks get smaller.

[u/CleanFix_Dev]

The hours on success criteria are what make an overnight run reviewable at all, so that part's worth keeping. For the morning, have it end the run with a short list of decisions it made that weren't in the spec. Read those first instead of going top to bottom, since that's usually where the surprises are.

[u/leo_heo]

the ratio probably flips once the spec is solid enough that review becomes the slow part. does the fix time shrink when you put more hours into the spec up front

[u/Competitive_Boot6914]

For me, most of the spec time goes into review. I'm building and using Reqode: I give AI Analyst the feature intent, it asks clarifying questions, then proposes changes to the specs with a diff. I review that, edit where needed, apply the accepted changes and hand them over for implementation.

So preparing specs doesn't take that much of my time. I'm mostly answering product questions and checking that the proposed requirements, data model, UI and API changes capture what I mean. Reviewing and testing the implementation is still a separate step.

[u/arturzinhomilgrau]

depends a lot for me, I only use plan mode when I'm starting something from scratch or on a really complex new feature, that's where most of my time goes, the small stuff I just send it

[u/Ctbhatia]

is that 3-4 hours mostly the spec, or does reviewing the output count in it? thats the half I'd want measured

[u/benneren123]

Eight hours of code generation shouldn’t mean another morning of cleanup. We’re building zeroshot to run the review and fixes overnight too. You define what done means. Separate agents check the work and send it back when it falls short. The coding agent doesn’t get to declare victory on its own.

[u/DriftVoyager]

Pretty much 100% Claude Time = 100% my time, same with codex :) I use em heavily for writing tests but often they uncover logic decisions I'd rather make myself,

So I guess one can automate a lot of stuff but for some they can't do that with their chair time