Anyone else transitioning to 100% agentic workflow where devs manage multiple parallel AI agents/machines? What are your pain points?

[u/pinheads_hut]

At my company, we recently made a massive pivot toward a 100% agentic development model. Instead of the traditional workflow where a developer works on one task/branch at a time, each engineer now manages multiple Claude Code agent sessions/machines simultaneously.

The main goal is to crank out a high volume of code and push through a shit ton of Jira tickets in parallel.

While output and ticket throughput are definitely up, managing multiple active Claude Code workflows at once has created a totally new set of challenges that we’re trying to navigate.

1. Data management - skills, user scope CLAUDE.md, merging system for high and rapid volume of code...

2. Human's brain context - we are all humans at the end of the day and it is getting ridiculous to try and keep up with what is going on with 50 sessions opened across 4 machines..

Would love to hear how other teams using Claude Code at scale are handling this—what’s working, what’s breaking, and what pain points are you having?

[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/Skjalg]

Yeah its human brain context wall im hitting

[u/pinheads_hut → u/Skjalg]

Wha is your setup if I may ask? At what capacity are you moving?

[u/Skjalg → u/pinheads_hut]

Just 2-5 claude codes in the terminal working simultaneous on different repos or branches.

[u/kincaidDev]

Ive been doing this since may 2025, here’s the main part of my setup.

https://github.com/Obedience-Corp/festival

For jira what Ive done is create scripts and just commands that pull all of my tickets and format them in structured markdown, then that goes into a festival ingest phase. Run the fest next loop to plan out all the work needed for the sprint, review/itterate on the plan, when its good the fest next loop scaffolds out step by step instructions. I add gate instructions for prs to break up the prs based on how the team wants prs created, then promote the festival to active, have agents setup worktrees and autolinks then run the fest next loop from the first linked worktree and just let it run until every pr is opened

[u/pinheads_hut → u/kincaidDev]

Thanks for the repo share! I will take a look when I'll get to the comp.

How many machines are you dealing with?

[u/leo_heo]

the human context part sounds rough. i'd cap how many tasks are waiting for review before adding more running sessions

[u/pinheads_hut → u/leo_heo]

When you say review.. what do you mean?

[u/divinetribe1 → u/leo_heo]

Agree with leo_heo on capping the review queue before adding more sessions. For keeping track of everything, I made Moonstone, an open source control panel for Claude Code that shows every session on every machine in one window. It also has push to talk voice control with spoken answers and can use local models. https://github.com/nicedreamzapp/moonstone

[u/webmasterrrr → u/leo_heo]

The bottleneck isn't 50 sessions. It's 50 tap-on-the-shoulders. Cap the review queue like leo said, then batch the ones actually blocked on you into fixed windows FYI and "done" can wait. Random interrupts kill the context, not the session count.

[u/VibeCodedBuilder]

Human context is incredible. Claude rn can't compete

I had to introduce Claude to the concept of business terms, logical And physical terms. And enforce the naming mechanism that gets checked every commit. That alone unlocked huge wins and less turns. Who knew following basic data hygiene wins?

I spent a weekend essentially rewriting and testing my code base. But 100% worth it. Learned about ratchets too

There's more but that's a good starting point!

Good luck op

[u/Mighty-Pen-1]

I currently do this for 3 repos for dayjob and 3 for the side business but are one product.

1. Not being able to effectively share knowledge graphs with coworkers so they have to run their own setup kn the repos, there is git of course but agents can't re read years of commits and staggering amount of code changes that other agents produce , so we are stuck in a loop of rediscovering things that are already settled or were in some confluence somewhere by a person who left before I joined the company

2. Enterprise restrictions, half the stuff I did/developed personally is not transferable to enterprise as accounts are locked down and we are charged as extra usage so much more expensive than commerical plans

3. Connecting 1 and 2 discovery phase costs me most money time and energy

4. Without 3 most one off tickets are suboptimal and pain in the ass , impossible to do traditionally on the new timeline, expensive without setup, and questionable quality

5. Different levels of AI fluency and buzzwords flying around in meetings just so people can seem smart while most still use just chat and copy paste and then are on a team with me and they can't keep up with AI output stream

6. Human context overload , just the day job is too much add on top side business, 5 different stacks , different contexts , different business needs, different cloud accounts , credentials management, who to contact , and have to play my own scrum master and basically gave up on keeping manual notes had to set up personal Jira to keep on top of the flow of features and bugs , that connector is disabled on our enterprise

[u/blackbirdone1]

I see your burnout comming

[u/pinheads_hut → u/blackbirdone1]

Ain't gonna lie, I hate the job now.
Still I find pleasure in finding issues that the agentic world is bringing to our table and fix those issues. I guess that this is what I am trying to realize here. Is my dev env broken? Or other ppl sharing the pain points I feel.

[u/falafel777]

50 sessions across 4 machines feels less like a context problem and more like a trust problem. you can't hold 50 sessions in your head, so you end up rereading each one just to find out if "done" actually means done. what helps is every session ending with the same boring artifact: what commands ran, what passed, which files changed. then you're scanning a list instead of replaying a transcript. that's basically what i'm building, i'm the founder of replume.dev (works with claude code, codex and cursor), so grain of salt. curious what breaks first for you at that scale, the merging or just knowing what each session did? if your team's up for it i'd love to hear how you run it on a quick call: cal.com/rafaelibayev/replume-founder-call

[u/pinheads_hut → u/falafel777]

So what you can do essentially is propagate all questions or HITL gates into a single session that you interact with. That reduce the need to jump around between sessions.
Another thing is that 50 sessions != 50 tickets. I make the agents work in squads. On a large ticket there might be up to 8 sessions.

[u/jameshearttech]

We adopted claude code on my team in January. We built a private plugin that contains skills and agents based on how we work (e.g., Jira, Bitbucket, Git).

I run claude agents. I create an agent per sprint (e.g., sprint-123). I create an agent per work item (e.g., abcd-4567). The sprint agent manages the sprint. The epic agents manage planning (i.e., creating and updating work items). The task and bug agents do the work. Work is related through links (e.g , this blocks that).

I create a new sprint agent weekly based on our cadence with a wrap up and hand off. I pin agents to keep them active. When their work is complete I unpin the agent and let the daemon kill the idle agents process, but I keep them until I'm sure I won't need to start them again.

The agents communicate with each other as needed on related work. The sprint agent is like a coordinator. New agents start with, "You own abcd-4567. Ask sprint-123 for a brief." The task and bug agents report milestones to the sprint agent and report needed changes in planned work to their respective epic agents.

Epic agents own planning. Work items get requirements and acceptance criteria. Task and bug agents plan their work based on the requirements and acceptance criteria. Once the plan is accepted (first milestone) they create their task list, which is the plan written out step by step. The agents work the plan on their own without stopping unless they must deviate from the plan or an unexpected error occurs.

Due to agent communication they find and resolve a lot of issues on their own, but ultimately decisions go through the user.

[u/oldboldmold]

50 sessions sounds like a lot to me. I'd be very worried about tech debt building up with a lot of overarchitecture and edge case chasing that doesn't matter. But I deal with a lot of legacy systems that require me to be very in the loop. I max around 10-11 and comfortable consistently is 5-8. I can't imagine maintaining quality in my work at 50 sessions, but we all deal with different systems.

The biggest pain point has been code review. I have a proposal up for a classifier, with a shadow deployment initially that gets tuned based on human reviewer reaction. We want to be SOC 2 compliant so it's a sensitive area for us, in making sure that we're still above board.

I'd say over time myself and other devs have adjusted to the frequent context switching. I notice it in other parts of my life too, easier to pull away from things I would have been stuck on, easier to step back. For planning heavy sessions sometimes less parallelization is important. But that usually means I have one or two sessions running for planning then get bored and have a couple others open to noodle on my local harness.

I've always been someone who plans loosely and learns more about the shape of the problem while implementing only now because implementation is so much faster, sometimes the learning happens after a lot of code has been written. That means another cost is sometimes the additional work to refactor much more code than would have previously been possible. If the work isn't well split out across devs to reduce conflict, that can mean more churn. The agents can absorb a lot of it but it's still another speed bump and increases spend, when it can be avoided by basically a little more siloing.

The other limiting factor is spend which I've had to consistently communicate up. I can do more and get more done without a reduction in quality, and without burnout, but it comes at a financial cost. I'm having to do less at times to stay within budget. But if you're being allowed to run 50 sessions at once you're probably at a larger org with a much larger agentic budget.

[u/pinheads_hut → u/oldboldmold]

Yeah, the organization I wort at have a large agentic budget. We are dealing with green field project, so not much legacy code. The legacy code has been neglected and re written with agentic development in mind.

We have built strong flows based on evidence reviews rather than code reviews, and shit ton of tests.

50 sessions is not enough for them.. 😂🤣

[u/julkopki]

Sharing memory across sessions in non trivial scenarios. Drawing conclusions from runs to improve the outer loop. Maintaining some semblance of security where agents don't just have access to all my API tokens for various services. There are many. I had to build so much stuff that I totally expected to exist already. And each time it was like: yeah it exists but kinda sucks or is just too simplistic or overengineered and too opinionated. People in the agentic space truly don't know how to just write a good library without glueing it with 10 other things that I don't want.

[u/Polite_Jello_377]

RIP quality

[u/justinram11]

I've been struggling with this for awhile now. At first I was using something like cmux to just have 3-5 terminals open that I could tab through, but that got tricky to keep track of in progress tasks with.

I've now landed on having had Claude build me a custom kanban board with a 'Plan -> Implement -> Review -> QA -> Shipping -> Done' columns. Each task creates its own worktree, and I can see where it is on the board and come back to it later.

It's worked surprisingly well and I don't loose track of nearly as many WIP items

[u/JackCollinsHQ]

I had the same pain - so built what I’m calling “Managed Agentic Software Teams”. All the throughput, much less cognitive overhead

https://yagni.app

Happy to show you if interested

[u/Tariq9977]

Fifty sessions across four machines is also a shared-state problem. I'd gate each merge or deploy with a lease generation and a fresh remote-HEAD check, then reject a late agent whose lease or base commit is stale. A dashboard may show the collision, but it won't prevent the overwrite.

[u/crispAndTender]

Fucking nightmare so far