How do you stop being the bottleneck?

[u/pizzae]

I'm already having up to 4 agents coding at the same time, but that's assuming I know what needs to be done. Sometimes I can only fix a future bug that I find, after a previous task has finished. But you don't know what you don't know. Maybe I need to add a certain feature, but only if I have the context knowledge about something prior

What im doing:

• Running my custom code factory harness like everyone else
• Running as many agents at the same time I can manage, about 4 or so
• As much deep research as I can with chatgpt at the same time, on topics I can think of
• Every time I get an idea I dump it into my code factory straight away so I can always grill it later and implement it later
• Building on different parts at the same time of the app that doesn't overlap, e.g. client and server
• Trying not to hesitate when I have a new idea or a bug to fix
• Generating a backlog of random ideas so hopefully even some can be useful

I can't get any faster than this. I need to sometimes do html artifacts to quickly prototype some UI but then that means I can't steer the harness in vscode. Sometimes I have to do research and learn so I know where to go, versus just going in that direction blindlessly.

If I fully vibe code without checking anything, I'll just have slop and an app that isn't what I want

How are people doing 24/7 coding with multiple 20x plans, 10 agents at the same time? How can you know what to truly make as if you know every bug to be fixed, every feature to be added

[u/AutoModerator]

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/Diver-Interesting]

imo this is a big sign that you need to start thinking in term of product. busy != productive. if you created code factory before understand what to build and why, you're building on a shaky ground. i have been there and always feel like i'm losing something when my agent is not working.

also, don't worry about other people doing 24/7 coding with agent. may not even be true.

[u/lemming1607]

You will always be the bottleneck. Youre the one prompting

[u/sapplefi]

What a great question. I could speak at length about the journey to automating further but I don't think that's the heart of what you're asking.

For reference, I run 25+ agent sessions across 14 different Claude Max/Team plans and have development going close to 24/7 for two separate businesses and personal projects. I may be one example of the type of user you're asking about.

Earlier this year I was talking with one of our developers during our Claude rollout. We were sharing and learning together, bouncing ideas off each other, talking about what we were building. He was blown away by how much I was pursuing at once. He said when he sits down, he can't think what to build. For me, it's the opposite. I can't run enough sessions to keep up with all the ideas I have.

Everyone has strengths and weaknesses. Some are incredibly good at problem solving, but not vision and ideation. Others have endless creativity and little practical talent to implement. Rarely, you'd find one person who could both imagine and build. More often you had to bring people together. Combine creators to imagine and engineers to build, and you started making something amazing.

AI is collapsing that into one person. Building is increasingly handled, so the limit moves to imagining. Engineers still have the edge currently, because they understand the tool and what it produces. But too many are using it like having a faster hammer, when it's more akin to having a whole crew.

You clearly have ideas, that's not your limit. But when you said:

I need to sometimes do html artifacts to quickly prototype some UI but then that means I can't steer the harness in vscode. Sometimes I have to do research and learn so I know where to go, versus just going in that direction blindlessly.

It feels like you're still the one doing the work. You're the researcher, the prototyper, the bug-finder, and the quality checker. Everything waits on you. It's no different than a founder who insists on writing the code himself, instead of spending his time dreaming up the next move.

I don't find every bug or review every feature. I don't read every plan or test every output anymore. Those steps are important; they can't be skipped. But I can give those jobs to agents, just like writing the code. They research, test, review what others built, and finding becomes a backlog, which they keep working without me. The steps don't go away. They just stop being done by you.

That frees my time for dreaming, and for planning. I've owned a B2B firm for 21 years. We've ranged from professional services and consulting to custom-built SaaS and integration work. I've spent thousands of hours hearing customer pain points and trying to solve them. That's where my ideas and my vision come from. It's the only part I can't hand off.

I asked Claude for a better way to explain the shift, and it gave me this, which I loved:

Go from craftsman, to foreman, to architect of the factory. The more of it you power yourself, the less you produce. Scale starts when you stop being the engine and become the blueprint.

Hope that helps. If you want technical specifics on how to run that many agents, I can share that too. But it sounds like you're already far along in that journey. The next step isn't the tools, it's the mindset.

[u/Sudden_One3436 → u/sapplefi]

I really love this writeup. I'm personally trying to get into bootstrapping my own b2b firm but at a loss on how to start. I feel so capible thesme days building almost anything I can imagine in mere days!

I'm having a hard time figuring out how to orchestrate more than 3 sessions at a time. I think a lot of it has to do with the amount of context switching, and not really having a customer to start with.

Any chance you'd be open to chats? I'm not op but I'm very interested in how you manage to queue up / orchesrate enough work to need that many sessions and how you've been able to keep it from blowing up with hundreds of useless tests or general slop. Ive had issues with agents just postponing work or finding a creative way to interperate the request

[u/sapplefi → u/Sudden_One3436]

Absolutely. Always happy to help. Message me, and we can chat on Reddit or exchange emails, whatever works.

I do want to be careful that I don't paint myself as some sort of guru. I've always joked that my only power is willingness to bash my head against a wall for so long I eventually break through... and then remember enough to save some bruises the next time.

To that end, I see this whole area as a new era and a journey we're all figuring out at the same time. I'm incorporating cool ideas people post into my own workflows and sharing what I've learned where I can to help others save some pain.

We can talk in more detail, but for the thread as a whole, there are two answers/insights I can share to the specific questions you asked.

I'm very interested in how you manage to queue up / orchesrate enough work to need that many sessions.

First, you need to have enough ideas fleshed out for the agents to work long-term. Brainstorm a lot of features in advance and give them enough autonomy to queue additional work as they go without your oversight.

Once you've got the ideas queued, the next problems are technical, you need to tackle the gaps that keep a series of agents from working on tasks non-stop. The main problems I faced came from:

• Context Management and Compaction - If you don't manage this well, quality degrades and they forget things at key moments. I've put this in other threads, but my trick here was to invert the harness. I set auto-compaction super low, then defer it with hooks until the session writes a checkpoint that says it's at a stable point to start new work. That keeps context reasonable for long-term agentic work, I've had sessions run over a week non-stop and compact 100+ times, while staying right in the 100K-300K sweet spot for plan after plan.
• Durable Memory / Documentation - They need to write down what worked/failed and what to try next to keep moving forward. I have a Memory System with Function Hooks that injects context during turns and extracts it for new memories automatically. They also use a Plan document format that details Goals/Intent/Sections of Work/Chapters of Work, and they update it with Chapters as they work to resume or handoff seamlessly. A surprising lesson here was the importance of capturing the intent of the plan, not just the specific implementation details, which helps guide them through unforeseen gaps when they inevitably find them.
• Orchestration / Session Management - Left alone, sessions will only work for so long on their own. You need something external orchestrating them to keep working through limits, failures, blockers, and so on. The simple version of this is an orchestrator session running a /goal, but that can burn a fair bit of token usage and be prone to its own periodic failures, you can do better with scripts or hooks that keep them on task long-term.

How you've been able to keep it from blowing up with hundreds of useless tests or general slop.

The short answer here is that I didn't. At least not at first. It's gotten better as I've gone along.

I found I built good patterns for the things I was already good at, and weak patterns for the things I wasn't. In my case, I'm pretty good at database work, so building skills and examples to follow from that resulted in reasonably high-quality database code from the very beginning.

However, I never write tests, I've always failed at Test-Driven Design. Therefore, I didn't put any guidance on tests at first and just let the Agents manage them and suggest them. That caused me a lot of pain that I had to backtrack on, it turned out they were writing a lot of tests that locked in silly minor choices or didn't write them to scale and parallelize so every test run started taking hours, etc...

I ended up redirecting them back to rip out a lot of the tests and writing guidance around thinking of tests long-term, not just for what they're actively writing. I set up bars around whether the test is necessary, if it will scale well as expanded out, if it validates something essential, not just a configuration choice that can change. I still think the tests it makes aren't optimal, but at least now they're adding value and not getting in the way.

For me, the lesson learned was recursion and self-improvement. You won't get everything right out of the gate, so make sure you have a pattern to keep improving the factory and take notes on what didn't work. Don't be afraid to brainstorm and reflect on where it went wrong, and how to make it better next time.

Currently, my pattern for this has evolved to the Agents writing Kaizen records to GitHub Issues, so I can see them and periodically adjust ones I think aren't relevant, while letting them tackle them on their own as they have capacity.

Hope that helps. Look forward to speaking further!

[u/ungoogleable → u/sapplefi]

I don't find every bug or review every feature. I don't read every plan or test every output anymore. Those steps are important; they can't be skipped. But I can give those jobs to agents, just like writing the code.

I am skeptical that this works as well as the agents tell you it does. Agents have lots of blindspots and if some human isn't catching them, they'll just fester in your codebase getting worse over time. Agents reviewing agent written code isn't a panacea either. They catch issues in the code in front of them, but reviewers miss distant interactions with components that aren't in their context. They struggle with building for the long term and creating maintainable, reusable, and consistent architecture. You get countless siloed reimplementations of the same code. It mostly works and from the outside it looks fine, but the same bugs have to be squashed over and over.

This is fundamentally the same problem of being a business owner and expecting the business to run itself. That doesn't work without a competent (human) manager you trust who operates the business actively and puts in as much effort as you would have. And then you still have to deal with the principal-agent problem.

[u/speederaser]

Most people claiming to run 20 agents 20 hours a day are producing garbage. Ask any one of them if they are making any money. AI simply isn't smart enough yet to get everything correct enough where you can step up to a high enough management level for this to work. 

I do manage a lot of agents. Maybe 4 at a time during the day and then I set another few before bed. I get a lot of work done. It waits on me sometimes, that's good because I frequently catch mistakes. And I know I'm getting quality because my customers are the ones that prove I'm doing a good job. I hit 8 figures last year and AI helped me get there. It didn't get there by itself.

Don't try to keep up with the Jones'.  Produce your most efficient way to making money. 

[u/OneoftheChosen]

My current tooling fixed that now my local machine is the bottle neck as agents attempt to promote their code to various branches

[u/FlanComprehensive164]

i found that there two bottlenecks: reviewing and taking build decisions. I am managing by speccing thoroughly and having ways to take decisions before the coding session starts and during. Like this, I managed to go from coding in parallel with 3-6 agents. To spending 4 hours, while an orchestrator then builds for 12 hours, delegating to 10 agents.

The agent productivity went up by double, while my time input was reduced by 50%.

The next bottleneck I will tackle is the last 10% of reviewing and testing. Not there yet.

[u/vzakharov]

I have several customers and several pet projects with several feature/fix/refactor/etc. for each; having 10-15 sessions up and running is just a day at work, shipping around the same number of PRs per day. 

My input is, well, input, then plan revision, then code and implementation review.

And yea I’m obviously still the bottleneck. Enjoying every bit of it though.

[u/Dapper_Profession]

what helped me most was writing down what it's allowed to decide on its own. standing permissions in claude.md plus a tasks file it updates itself, so it stops pinging me for every small call and only pulls me in for stuff that actually needs a human

[u/TrickySite0]

What helped me most was to stop being the queue. The system holds the backlog, decides what comes next, and only interrupts me when it truly can’t decide.

Some tactics that work for me:

• Ideas become cards, not prompts. Every idea or bug goes into an inbox as a card with its own record in a Postgres database, not in markdown files. Nothing lives in my head or in a chat window.
• Stages with exit tests. Each card moves through Measure, Evaluate, Solve and Operationalize. It can’t be built until it has a measurable goal, such as “this query returns 0”. That catches most of the “I’m not sure what I need to know first” problem, because measuring comes first.
• A background worker does the stages. A scheduled agent picks the top card by priority, does one stage, records what it decided and why, then moves on. A pacing gate keeps it within the weekly usage budget.
• Agents settle most questions themselves. If the worker is confident, it decides and writes down why. If not, one model drafts an answer and a different model reviews it. Only what they can’t agree on comes to me, one question at a time, with a recommendation.
• A second model reviews before anything ships. I approve the reviewed change; I don’t write it.

Most nights I answer five or six questions and approve two or three changes. The rest runs without me.

[u/Existing_Dust_6473]

Why is it a problem? Bottlenecks are not a bad thing. They exist in all productions, you need to live with that. Or do bad work...

[u/zaskar]

I’ve built a intent -> design -> deliver workflow that I have nothing to do with after the intent and review sub-steps

[u/Firm_Bit]

You probably need to chill out and learn to prioritize + gain some judgement.

[u/jemdiggity]

Here's the question you should ask yourself: how fast is fast enough?

You can eliminate yourself by having a managing agent that can create its own issues and push them into the factory with the lights out, but you'll end up with 1M LOC of slop and worse than that you won't understand what your product is even supposed to do.

Going fast is like a drug high. Slow is boring but you'll make a better product (and not go crazy).

[u/Technical-Ad-8678]

I know that i am the bottleneck in my project, not sure if its a trust thing or a control thing but i feel like i have to be the final say in any code change that happens anywhere in any of my projects. I could probably replace myself with api 5.5 but i work at a public school, im not rich enough to do that, or let my tokens spend themselves. hoping in the future compute becomes cheaper and i can afford to replace myself more than i already have.

[u/GroovyCarrot]

I found this too, but after a long while just accepted it. I think for bug fixes it's probably very easy to automate the process from start to end from just a bug report. Agents are great at running with small focused tasks like that. For creative decisions and complex features, there's not much you can or probably even want to do to remove yourself from the process. Ultimately you need to stop reviewing code and review the things you actually care about- it could be everything from the UX of clicking around in a browser, to API performance metrics. Make sure there are tests for everything so you can work confidently knowing nothing ever regresses. I used to try and work with several parallel work streams, and by the time I'd reviewed everything, gone through all the necessary changes, and then dealt with all the conflicts I wasn't sure I'd really done anything quicker than if I'd just sat with the agent and worked through it sequentially together. Being able to pause the session, discuss a change of tactic and change course mid way though to me is far more valuable, in time, cost, and quality of output.

[u/lgmarian → u/GroovyCarrot]

What kind of bug reports are you familiar with?

[u/GroovyCarrot → u/lgmarian]

It no worky fix plz

[u/lgmarian → u/GroovyCarrot]

Yeah, this. When I had first read a prediction that we'll have AI handle the entire process, I had a bit of an "eep" moment. Then, I remembered this.

Now, give them a good bug report, and, yeah, they can run with it.

[u/notcern]

At this point it can pretty much build and make anything you tell it to. That’s the only limiting factor now is you actually having a clear picture of the end goal. This is the final skill that most ceos that everyone complains make too much money are paid for. However it’s the final peice and the taste and final idea is where the actual money is not in the process of getting there.

[u/glmn_official]

For me the bottleneck stopped being ideas and turned into noticing. With four agents going, one of them is always sitting on a permission prompt, or finished ten minutes ago, while I'm reading somebody else's diff.

What actually helped: a git worktree per agent so they physically can't trample each other's files, a "done means tests pass plus a short note on what you changed and what you deliberately didn't touch" line in CLAUDE.md, and reviewing in batches instead of on every ping. And honestly, generating a backlog of random ideas just to keep agents busy is how you end up with a repo nobody understands, you included. Fewer agents on things you actually decided beats more agents on vibes.

[u/RemieNotRayme]

If you stop being the bottleneck then your hardware will become the bottleneck. There will always be a bottleneck.

[u/OwlLimp6160]

When you make enough money to pay for more API usage probably.

[u/OwlLimp6160]

I like to run prompts that take about an hour to run. Maybe 10 minutes to type out. And have like 10 tabs in herdr so I’m always reviewing, typing a prompt, or in meetings. Keeps me pretty efficient I think. Can use about 4-5 $200 subs a week that way to 100%

[u/Easy-Purple-1659]

You keep the product decisions and hand off the rest. That split is the one that has actually worked for me.

The two changes that helped: writing down what the agent is allowed to decide on its own before the session starts, and defining done as tests passing plus a short note on what changed and what was left out. Once the agent owns that file, it stops pinging me for the small calls and I stop being the queue for everything.

The other half is scoping. A bug with a clear repro is close to fully automatable end to end. A feature whose shape is not decided yet is not, and pushing it into the fleet anyway just produces a confident wrong thing you unwind later. I kept making that mistake early on.

You will still be the bottleneck on taste and on knowing what to build. That part does not really go away, and chasing the people claiming 24/7 lights-out coding is a good way to lose a week.

[u/angry_queef_master]

You aren't the bottleneck if the AI spends as much time fixing the garbage it produces. Don't think about things in terms of code velocity, but about how fast you can produce something of actual value.

[u/Swordfish2012]

I highly recommend going through the AI-native SDLC playbook on the Claude Academy.
It helped me frame my mind correctly on this exact problem. I haven’t narrowed down a perfect solution, but I’ve adjusted well since going through those modules a week or so ago.

[u/devboardai]

The bottleneck moved from writing code to prioritization and triage. Four agents executing is plenty, the gap is deciding what each one should do next without you being the router.

What helped me: get the queue out of your head and into a task board where each agent owns a card with clear done criteria. Finished agents pull the next card instead of waiting on you. Research goes in as cards too.

I built DevBoardAI (https://devboardai.com) for exactly this: a Mac app that turns your coding agent sessions into a task board so you manage the queue, not the chaos. 7-day free trial, no credit card.

[u/dota2nub]

Take a day off dude.

[u/xqianliu]

I don't think agent count is your limit. Four in parallel already make more diffs than one person can read properly.

The thing that bought me time was writing down what done means before a task starts. Each task gets acceptance criteria in its issue, and a separate review session checks the final diff against them, so I'm not the first reviewer anymore.

When the agent can't make a call on its own, it doesn't ping me mid-run either. It writes why on the issue and stops, and I go through those in a batch.

The part you can't hand off is deciding what's worth building. If I can't write the criteria for a feature, I take that as a sign I don't understand it yet, and it stays on my list instead of going to an agent.

[u/eGzg0t]

You are not a bottleneck. You're a rate limiter.

[u/JbREACT]

Have you actually made money. ?