10 ms·

Parallel AI agents are a game changer

77 points by shiroyasha 1y ago

lawlessone 1y ago
Wouldn't the first "AI" use in coding be code suggestions that IDE's have already had since before LLMS? Or UML tool that generate code?
- deleted 1y ago
  [deleted]
epolanski 1y ago
Look, I like AI coding but we're already way past the need for parallelism. LLMs write so much code in such a short time that the bottleneck is already the human having to review, correct, rewrite. Parallel agents working on different parts of the application just compound this problem worse, it's impossible to catch up. The only far fetched use case I can see is swarming hundreds of solutions against a properly designed test case and spec documents and having an agent selecting the best solutions. Still, I'm quite convinced humans would be the bottleneck.
- rcarr 1y ago
  You are the main thread: https://www.claudelog.com/mechanics/you-are-the-main-thread/ https://www.claudelog.com/mechanics/you-are-the-main-thread/
  - deleted 1y ago
    [deleted]
- SatvikBeri 1y ago
  It really depends on the project. For example, there's a lot of thorny devops debugging where I can just let Claude spin for 30 minutes and it'll solve the problem (or fail) with a relatively short final answer. The sweet spot for me tends to be running one of these slower projects on a worktree in the background, and one more active coding project.
  - epolanski 1y ago
    Yeah sure, I mean, there always be problems you can swarm..
- OutOfHere 1y ago
  Exactly. With other models that are not Claude, the code generation for an issue takes a minute at most, whereas writing the detailed specification for it as a human takes me days or longer. Parallel code generation is as relevant to me as having a fast car stuck in traffic at a red light.
deleted 1y ago
[deleted]
furyofantares 1y ago
The sweet spot for me is 2 agents on different projects. Surprisingly the context switch is easy. It's harder when doing 2 tasks on the same project.
- merlincorey 1y ago
  > on different projects This seems like an important caveat the author of the article failed to mention when they described this: > you can have several agents running simultaneously - one building a user interface, another writing API endpoints, and a third creating database schemas. If these are all in the same project then there has to be some required ordering to it or you get a frontend written to make use of a backend that doesn't have the endpoints used, and you get a backend that makes use of a different database schema than the separately generated database schema.
  - furyofantares 1y ago
    On the same project you can use worktrees or otherwise separate clones of the repo - that part is not that bad. My comment was just about my own context switch.
  - kasey_junk 1y ago
    This is just project management. Teams of software devs have been doing this for decades. And it’s easier with agents because there is no harm in letting one sit idle.
- rcarr 1y ago
  A technique I have found that works well is to have it working on one feature and then to have another session planning the next. Whilst it's busy generating some code, I open up another instance, tell it the next task and instruct it to create a gherkin feature file with an implementation plan. I then go back and forth between reviewing the code for the current feature and the plan for the next one.
manveerc 1y ago
When I read the title, I thought you were referring to https://parallel.ai https://parallel.ai, which also is a game changer in my opinion :) PS: I have no affiliation with Parallel the company
zzzeek 1y ago
I use Claude every day. When I give it a program that does something straightforward in one file and it writes it from scratch, it does great. When I have it fix issues or add functionality to small to medium sized apps that have a mostly simple design, it does great. When I point it at codebases that are 20 years old and have a lot of indirection in their design due to years of hard lessons learned and a lot (like a LOT) of cases covered, it really struggles (just read my profile to know what codebase this is). I mostly try to get it to write changelog messages, docs and tests, where it works, but I have to really wrestle with it. I can't imagine doing anything on "vibes" and it all seems quite ridiculous if you are working on hardcore library oriented software with tens of thousands of users. If we're going to say, who cares, with LLMs we'll never need 20 year old codebases we'll just keep writing new stuff, OK you do you.
- localhost 1y ago
  one thing that i find works really well is to ask it to research things in the codebase and write a plan first. codex with gpt-5 is exceedingly good at doing this. then ask it to write a plan for what it would do with that information, i.e., i want you to research codebase for <goal>. then write a plan for how you would achieve <goal> given what you have learned.
  - zzzeek 1y ago
    Claude writes out plans and all that, it's good about that. Sure would be great if ai agents could learn from conversations. That would really makes things better. I tell Claude to capture things in the Claude.md file, but I have to manually tend to that quite a lot.
ambicapter 1y ago
Obviously I'm an AI-tools skeptic, but this is hilarious: > 1. Prepare issues with sufficient context > Start by ensuring each GitHub issue contains enough context for agents to understand what needs to be built and how it integrates with the system. This might include details about feature behavior, file locations, database structure, or specific requirements such as displaying certain fields or handling edge cases. > You can’t do half-hearted prompts and fix as you go, because those fixes come an hour later. > Skills That Become More Important > Full-stack understanding > Problem decomposition > Good writting skills > QA and Code Review skills This is just software engineering?!? edit: On the other hand, maybe I can convince people in my org to get better at software engineering by telling them its for the AI to work better.
- shiroyasha 1y ago
  Yes. AI assisted software engineering is still software engineering. I don't see that part changing anytime soon.
- DetroitThrow 1y ago
  >This is just software engineering?!? Absolutely. The existence of vibe coding does not mean production code is going to be engineered without the same principles we've always used - even if we're using AI to generate a lot more code than before. Any crowd suggesting that this was not the case has lost the plot, imo.
  - Aeolun 1y ago
    People find it a lot more palatable when the AI requires all this information than when software engineers do though. If I ask for clear requirements I’m asked to just figure it out. But if the AI implements nonsense without clear requirements that the fault of the specs.
    - lazide 1y ago
      Well, that’s because the software engineers are irritating when they push back and say ‘no’ or ‘wtf’. When the AI does it, it’s being polite and stuff. /s, kinda.
osn9363739 1y ago
Can this guy, or someone else post a full days (4-8 hours, or what ever is spent in the weeds) stream of work to youtube or something. I just want to watch the process to see what I'm missing. Or if there is anyone that already does that can they recommend it to me. I would appreciate it.
- slig 1y ago
  https://youtu.be/xAKVi_jvvg4 https://youtu.be/xAKVi_jvvg4 Two hours of Web Dev Cody.
  - pton_xd 1y ago
    Got through about 45 min at 2x speed / some skipping ahead out of pure fascination. Man that's something else. It's like bug-driven-development. Get the LLM to churn out a huge chunk of text, then skim the code for about 10 seconds and say it looks good. Then spend a while testing and hitting one error after the next until it finally seems to work. Repeat.
  - ath3nd 1y ago
    Wow, I didnt expect that dystopias can be so boring. If somebody like that producing code of like that low quality worked with me, I can see myself spilling coffee or acid on them or their laptop.
    - dehugger 1y ago
      Assaulting underperforming devs is one way to ensure code quality, I guess.
      - ath3nd 1y ago
        Keep in mind that in their mind they are performing very well as they (or rather Claude) are churning PR after PR. We gotta stop the endless characters production at least for a bit so we and the git servers get some time to breathe free from slop. A tactical coffee spill is a small price to pay.
kasey_junk 1y ago
Very strange that Devin and Claude code weren’t in the list of systems that support these workflows.
tomlockwood 1y ago
So the solution that gets upvoted during this hype cycle is the one that requires throwing more money at these companies? Curious.
muratsu 1y ago
I find Codex and Claude Code to have different strength/weaknesses and wanted to be able to use them from a single interface. Currently hacking on https://devfleet.ai https://devfleet.ai to make agent management more easy on myself. Briefly mentioned on the article but async agents really thrive on small and scoped issues. Imagine hooking them up to your feedback tool (eg canny) and automatically having a PR as you review the customer feedback. Now this would likely not work for large asks but for smaller asks, you can just accept the PR and ship it really fast!
- conradkay 1y ago
  Cool project! Do you think a lot of Codex's strengths are just from using GPT-5 as the model?
  - muratsu 1y ago
    The codex model is trained differently than the normal models. It has extra training on how to use cli and I find it to be better at project scope tasks (eg running tests, migrations, etc). Whereas in my experience Claude is the better coding model.
asdev 1y ago
Context switching between more than 2 threads of work is untenable if you want to really review code in depth. And with AI, you need to go through everything with a fine toothed comb
- CuriouslyC 1y ago
  Counterpoint, you need to develop more robust automated systems so you don't have to go through everything with a fine toothed comb.
- Aeolun 1y ago
  Yeah, I find I need to interrupt Claude at least once every two turns to prevent it from going off into the wrong rabbit hole.
- shiroyasha 1y ago
  The same work as any senior software engineer reviewing his teams work, imho.
  - aisizbzbzh 1y ago
    [dead]
  - lazide 1y ago
    Eh, you quickly learn who you can trust and who needs the super skeptical detailed look with humans. With LLM’s you have you to super skeptical of everything.
modarts 1y ago
It still amuses me how literally people took Kapathy's famous tweet around vibe coding https://x.com/karpathy/status/1886192184808149383 https://x.com/karpathy/status/1886192184808149383 If people were to actually read beyond the first sentence, it would become clear very quickly that this was meant to be tongue in cheek.
- krapp 1y ago
  People took it seriously because that's exactly how a lot of LLM users think and exactly what they want 'coding' to be. Honestly I'm not even certain it is satire.
- pvtmert 1y ago
  Because most people have the context-window of 10 tokens, they do not read further than the first sentence (or two).
- stavros 1y ago
  I don't think it's tongue-in-cheek at all. It refers to a specific type of LLM coding, where you literally don't care about how bad the code is and just code stuff and hope it works. That's how I use the term, and that's why I use it rarely.
tptacek 1y ago
So: (1) I feel like most people call these async agents, though maybe "parallel" is the term that will stick. (2) Async is great for reasons other than concurrent execution. (3) Concurrent execution is tricky, at least for tightly defined projects, because the PRs will step on each other, and (maybe this is just me) I would rather rewrite an entire project than try to pick through a complicated merge conflict.
- shiroyasha 1y ago
  I agree, async does feel like a better description. I wish I used that term for the title.
- CuriouslyC 1y ago
  Nah, I saw this problem a while ago and already spec'd out the solution. First, agents need to be doing atomic commits, and second you can just have a massive merge queue with bisection, if you're using bazel you can handle ci gating on thousands of PRs with very little overhead, and when a merge batch fails you find the bad patch set in O(log(n)) time and dispatch to an agent for reconciliation. I even built a prototype, works great in benchmarks but I don't have a need for it over merge trains in gitlab yet.
mmaunder 1y ago
The author is lying. My team and I are heavy users of Claude code and other agents and it ain’t like this. You need to manage an AI coding agent carefully and course correct frequently. There are cases for parallel agents but they are tasks like parallel document fetches and summarization, and other tasks that don’t require supervision. The idea of having multiple parallel agents merge pull requests or resolve issues in parallel is still just an idea. Please don’t post or upvote attention seeking crap like this. It gives a very exciting and promising technology a bad name.
- hu3 1y ago
  Your comment is disproportionately rude. Just because your team can't leverage multiple coding agents doesn't mean no one else can. And even if OP also can't, this is a good place to discuss possible problems and solutions for parallel development using coding agents. Please refrain from gatekeeping.
  - mmaunder 1y ago
    “With this approach, I can manage to have 10–20 pull requests open at once, each handled by a dedicated agent.” A quote from the post. No, I think my post is calibrated quite well considering what OPs post does to our industry.
    - hu3 1y ago
      Having 20 PRs open at once doesn't necessarily mean managing 20 agents simultaneously. It can mean, for example, that 2 agents worked for some time in a list of 20 TODO features and produced 20 PRs to be reviewed. They could have worked overnight even. You're seemingly judging from the least generous interpretation, which is not constructive and is also against HN guidelines fyi.
      - shiroyasha 1y ago
        Exactly! To make it more clear, here is how I approach my day: 9-10am: I comb through our issue list, figuring out which issues are well defined, which need more input or design decision. => I pick a hand-full, lets say 10 that I kick off to run in the background, and lets say another 10 for further specification. 10-2pm: I thinker with 10 issues to figure out the exact specs and to expand the requirement list. 2pm-6pm: I review the code written by the agents, one by one. I kick off for further work things that need more input, or merge things that look good.
pvtmert 1y ago
Is it me or the post sounding (showing!) that they haven't tried the mentioned approach in real life. Because in real life, one agent tries to fix build issue with rm -rf node_modules and the other is already running a server (ie: npm server), conflicting with each other nearly all the time!. (even if it's not a destructive action, the second npm server will most likely to fail due to port-allocation conflicts!) Meanwhile, what I found helpful is that: 1. Clone the same repo twice or three times 2. In each terminal or whatever, `cd` into it 3. Create a branch, run your ~commands~ prompts (each is their own session with their own repo) 4. commit/push then merge/rebase (also resolve conflicts if needed, use LLM again if you want) Any other way multiple agents work in harmony in a single repo (filesystem/directory) at the same time is a pipe-dream with the current status of the MCP and agents. Let alone being aware of each other (agents), they don't even have a proper locking mechanism. As soon as you make a new change, most of the editing (search/replace) functionality in the MCPs fail miserably. Then they re-read the entire file, just creating context-rot or over-filling with already-existing stuff. Soon you run out of tokens (or just pay extra for no reason) > edit: comments mentioned that each agent runs in a VM isolated from others, kinda makes sense but still, there will be massive merge-conflicts unless each agent runs in a completely different set of service/code-base (ie frontend vs backend or couple of micro-services)
- GZGavinZhao 1y ago
  git workspaces?
  - lacasito25 1y ago
    u mean worktrees
    - GZGavinZhao 1y ago
      Ah yes I used much jj lol
- abound 1y ago
  The post is about using GitHub's integrated Copilot tooling, where each issue gets its own instance presumably running in a sandbox. This sidesteps the issues you're talking about here.
anthem2025 1y ago
Less convincing when you open up by gushing about every other lame AI tech then proceed to insist that this new thing is the real revolution. Comes across as someone who just wants to shill for AI for some reason.
adriand 1y ago
I'm starting to think that the rather slow nature of Claude Code is a feature. In fact if they suddenly sped things up by 10X, I would want an option to slow it back down. Sometimes I am fine with it working unsupervised while I empty the dishwasher or take a shower, but a lot of the time I watch it work. Not only does this help me stop it from going down rabbit holes / chewing through all of my Opus usage cap, but I have a much better understanding of what it's built, in the same way I might if I was pair-programming with someone and they were driving. The idea of having multiple instances working in parallel sounds like a nightmare to me. I find this technology works best when it is guided, ideally in real time.
sovietmudkipz 1y ago
To those who have worked with autonomous background agents techniques, can you describe the stack and the workflow? Has anyone set up a local only autonomous agent, using an open source model from somewhere like huggingface? Still a bit confused on the details of implementing the technique. Would appreciate any explanations (thanks in advance).
ravila4 1y ago
My experience with parallel agents is that the bottleneck is not how fast we can produce code but the speed at which we can review it and context switch. Realistically, I don’t think most people have the mental capacity to supervise more than one simultaneous task of any real complexity.
jongjong 1y ago
I totally disagree about the monorepo argument. Mono-repos exist as a reaction to poor modularization and tight coupling which creates a need to update dependencies frequently. The reason for having dependencies in the same repo as the trunk of the project code is precisely because the dependencies aren't sufficiently generic, too dependent on the project's business domain and so they require constant maintenance. This tight coupling means that the agent requires more context to solve problems and implement simple features. The need for more context is a problem for agents, not a benefit. Agents benefit from modularization, loose coupling and well-chosen abstractions. These attributes do not correspond to the kinds of complex, tightly integrated codebases which benefit from having a monorepo structure. Dependencies should be like tools. If you think of a hammer, you can do a lot of different jobs with the same hammer... You can debate whether or not a hammer is the right tool for any given job, but for those jobs where a hammer is the right tool, how often do you need to tweak the hammer itself? A hammer solves a very specific problem but that problem can be generalized to countless different use cases. A hammer would make a good module. Now if you did a project for a candle factory and let the project business domain leak into the design of your tools/modules; you may build a hammer out of wax to straighten out candles... Then in your next project building a house you will find that this hammer doesn't work for that case and needs to be modified. This is a failure of separation of concerns. The tool was not originally optimized for the specific task of applying blunt force to a limited area; it couldn't do that narrow job very well and that's why it needs to be changed. Had you built a hammer out of steel, it would likely have solved both problems even through it's a completely different use case.
ath3nd 1y ago
Counteropinion: neither parallel nor single threaded agents are a gamechanger. I mean they might be changing the game into prodicing more hard to maintain software, faster, but if that is the game you are playing, I dont wanna participate.

77 points by shiroyasha 1y ago

Wouldn't the first "AI" use in coding be code suggestions that IDE's have already had since before LLMS? Or UML tool that generate code?

deleted 1y ago
[deleted]

epolanski 1y ago

Look, I like AI coding but we're already way past the need for parallelism. LLMs write so much code in such a short time that the bottleneck is already the human having to review, correct, rewrite. Parallel agents working on different parts of the application just compound this problem worse, it's impossible to catch up. The only far fetched use case I can see is swarming hundreds of solutions against a properly designed test case and spec documents and having an agent selecting the best solutions. Still, I'm quite convinced humans would be the bottleneck.

rcarr 1y ago
You are the main thread: https://www.claudelog.com/mechanics/you-are-the-main-thread/ https://www.claudelog.com/mechanics/you-are-the-main-thread/
- deleted 1y ago
  [deleted]
SatvikBeri 1y ago
It really depends on the project. For example, there's a lot of thorny devops debugging where I can just let Claude spin for 30 minutes and it'll solve the problem (or fail) with a relatively short final answer. The sweet spot for me tends to be running one of these slower projects on a worktree in the background, and one more active coding project.
- epolanski 1y ago
  Yeah sure, I mean, there always be problems you can swarm..
OutOfHere 1y ago
Exactly. With other models that are not Claude, the code generation for an issue takes a minute at most, whereas writing the detailed specification for it as a human takes me days or longer. Parallel code generation is as relevant to me as having a fast car stuck in traffic at a red light.

deleted 1y ago

[deleted]

furyofantares 1y ago

The sweet spot for me is 2 agents on different projects. Surprisingly the context switch is easy. It's harder when doing 2 tasks on the same project.

merlincorey 1y ago
> on different projects This seems like an important caveat the author of the article failed to mention when they described this: > you can have several agents running simultaneously - one building a user interface, another writing API endpoints, and a third creating database schemas. If these are all in the same project then there has to be some required ordering to it or you get a frontend written to make use of a backend that doesn't have the endpoints used, and you get a backend that makes use of a different database schema than the separately generated database schema.
- furyofantares 1y ago
  On the same project you can use worktrees or otherwise separate clones of the repo - that part is not that bad. My comment was just about my own context switch.
- kasey_junk 1y ago
  This is just project management. Teams of software devs have been doing this for decades. And it’s easier with agents because there is no harm in letting one sit idle.
rcarr 1y ago
A technique I have found that works well is to have it working on one feature and then to have another session planning the next. Whilst it's busy generating some code, I open up another instance, tell it the next task and instruct it to create a gherkin feature file with an implementation plan. I then go back and forth between reviewing the code for the current feature and the plan for the next one.

manveerc 1y ago

When I read the title, I thought you were referring to https://parallel.ai https://parallel.ai, which also is a game changer in my opinion :) PS: I have no affiliation with Parallel the company

zzzeek 1y ago

I use Claude every day. When I give it a program that does something straightforward in one file and it writes it from scratch, it does great. When I have it fix issues or add functionality to small to medium sized apps that have a mostly simple design, it does great. When I point it at codebases that are 20 years old and have a lot of indirection in their design due to years of hard lessons learned and a lot (like a LOT) of cases covered, it really struggles (just read my profile to know what codebase this is). I mostly try to get it to write changelog messages, docs and tests, where it works, but I have to really wrestle with it. I can't imagine doing anything on "vibes" and it all seems quite ridiculous if you are working on hardcore library oriented software with tens of thousands of users. If we're going to say, who cares, with LLMs we'll never need 20 year old codebases we'll just keep writing new stuff, OK you do you.

localhost 1y ago
one thing that i find works really well is to ask it to research things in the codebase and write a plan first. codex with gpt-5 is exceedingly good at doing this. then ask it to write a plan for what it would do with that information, i.e., i want you to research codebase for <goal>. then write a plan for how you would achieve <goal> given what you have learned.
- zzzeek 1y ago
  Claude writes out plans and all that, it's good about that. Sure would be great if ai agents could learn from conversations. That would really makes things better. I tell Claude to capture things in the Claude.md file, but I have to manually tend to that quite a lot.

ambicapter 1y ago

Obviously I'm an AI-tools skeptic, but this is hilarious: > 1. Prepare issues with sufficient context > Start by ensuring each GitHub issue contains enough context for agents to understand what needs to be built and how it integrates with the system. This might include details about feature behavior, file locations, database structure, or specific requirements such as displaying certain fields or handling edge cases. > You can’t do half-hearted prompts and fix as you go, because those fixes come an hour later. > Skills That Become More Important > Full-stack understanding > Problem decomposition > Good writting skills > QA and Code Review skills This is just software engineering?!? edit: On the other hand, maybe I can convince people in my org to get better at software engineering by telling them its for the AI to work better.

shiroyasha 1y ago
Yes. AI assisted software engineering is still software engineering. I don't see that part changing anytime soon.
DetroitThrow 1y ago
>This is just software engineering?!? Absolutely. The existence of vibe coding does not mean production code is going to be engineered without the same principles we've always used - even if we're using AI to generate a lot more code than before. Any crowd suggesting that this was not the case has lost the plot, imo.
- Aeolun 1y ago
  People find it a lot more palatable when the AI requires all this information than when software engineers do though. If I ask for clear requirements I’m asked to just figure it out. But if the AI implements nonsense without clear requirements that the fault of the specs.
  - lazide 1y ago
    Well, that’s because the software engineers are irritating when they push back and say ‘no’ or ‘wtf’. When the AI does it, it’s being polite and stuff. /s, kinda.

osn9363739 1y ago

Can this guy, or someone else post a full days (4-8 hours, or what ever is spent in the weeds) stream of work to youtube or something. I just want to watch the process to see what I'm missing. Or if there is anyone that already does that can they recommend it to me. I would appreciate it.

slig 1y ago
https://youtu.be/xAKVi_jvvg4 https://youtu.be/xAKVi_jvvg4 Two hours of Web Dev Cody.
- pton_xd 1y ago
  Got through about 45 min at 2x speed / some skipping ahead out of pure fascination. Man that's something else. It's like bug-driven-development. Get the LLM to churn out a huge chunk of text, then skim the code for about 10 seconds and say it looks good. Then spend a while testing and hitting one error after the next until it finally seems to work. Repeat.
- ath3nd 1y ago
  Wow, I didnt expect that dystopias can be so boring. If somebody like that producing code of like that low quality worked with me, I can see myself spilling coffee or acid on them or their laptop.
  - dehugger 1y ago
    Assaulting underperforming devs is one way to ensure code quality, I guess.
    - ath3nd 1y ago
      Keep in mind that in their mind they are performing very well as they (or rather Claude) are churning PR after PR. We gotta stop the endless characters production at least for a bit so we and the git servers get some time to breathe free from slop. A tactical coffee spill is a small price to pay.

kasey_junk 1y ago

Very strange that Devin and Claude code weren’t in the list of systems that support these workflows.

tomlockwood 1y ago

So the solution that gets upvoted during this hype cycle is the one that requires throwing more money at these companies? Curious.

muratsu 1y ago

I find Codex and Claude Code to have different strength/weaknesses and wanted to be able to use them from a single interface. Currently hacking on https://devfleet.ai https://devfleet.ai to make agent management more easy on myself. Briefly mentioned on the article but async agents really thrive on small and scoped issues. Imagine hooking them up to your feedback tool (eg canny) and automatically having a PR as you review the customer feedback. Now this would likely not work for large asks but for smaller asks, you can just accept the PR and ship it really fast!

conradkay 1y ago
Cool project! Do you think a lot of Codex's strengths are just from using GPT-5 as the model?
- muratsu 1y ago
  The codex model is trained differently than the normal models. It has extra training on how to use cli and I find it to be better at project scope tasks (eg running tests, migrations, etc). Whereas in my experience Claude is the better coding model.

asdev 1y ago

Context switching between more than 2 threads of work is untenable if you want to really review code in depth. And with AI, you need to go through everything with a fine toothed comb

CuriouslyC 1y ago
Counterpoint, you need to develop more robust automated systems so you don't have to go through everything with a fine toothed comb.
Aeolun 1y ago
Yeah, I find I need to interrupt Claude at least once every two turns to prevent it from going off into the wrong rabbit hole.
shiroyasha 1y ago
The same work as any senior software engineer reviewing his teams work, imho.
- aisizbzbzh 1y ago
  [dead]
- lazide 1y ago
  Eh, you quickly learn who you can trust and who needs the super skeptical detailed look with humans. With LLM’s you have you to super skeptical of everything.

modarts 1y ago

It still amuses me how literally people took Kapathy's famous tweet around vibe coding https://x.com/karpathy/status/1886192184808149383 https://x.com/karpathy/status/1886192184808149383 If people were to actually read beyond the first sentence, it would become clear very quickly that this was meant to be tongue in cheek.

krapp 1y ago
People took it seriously because that's exactly how a lot of LLM users think and exactly what they want 'coding' to be. Honestly I'm not even certain it is satire.
pvtmert 1y ago
Because most people have the context-window of 10 tokens, they do not read further than the first sentence (or two).
stavros 1y ago
I don't think it's tongue-in-cheek at all. It refers to a specific type of LLM coding, where you literally don't care about how bad the code is and just code stuff and hope it works. That's how I use the term, and that's why I use it rarely.

tptacek 1y ago

So: (1) I feel like most people call these async agents, though maybe "parallel" is the term that will stick. (2) Async is great for reasons other than concurrent execution. (3) Concurrent execution is tricky, at least for tightly defined projects, because the PRs will step on each other, and (maybe this is just me) I would rather rewrite an entire project than try to pick through a complicated merge conflict.

shiroyasha 1y ago
I agree, async does feel like a better description. I wish I used that term for the title.
CuriouslyC 1y ago
Nah, I saw this problem a while ago and already spec'd out the solution. First, agents need to be doing atomic commits, and second you can just have a massive merge queue with bisection, if you're using bazel you can handle ci gating on thousands of PRs with very little overhead, and when a merge batch fails you find the bad patch set in O(log(n)) time and dispatch to an agent for reconciliation. I even built a prototype, works great in benchmarks but I don't have a need for it over merge trains in gitlab yet.

mmaunder 1y ago

The author is lying. My team and I are heavy users of Claude code and other agents and it ain’t like this. You need to manage an AI coding agent carefully and course correct frequently. There are cases for parallel agents but they are tasks like parallel document fetches and summarization, and other tasks that don’t require supervision. The idea of having multiple parallel agents merge pull requests or resolve issues in parallel is still just an idea. Please don’t post or upvote attention seeking crap like this. It gives a very exciting and promising technology a bad name.

hu3 1y ago
Your comment is disproportionately rude. Just because your team can't leverage multiple coding agents doesn't mean no one else can. And even if OP also can't, this is a good place to discuss possible problems and solutions for parallel development using coding agents. Please refrain from gatekeeping.
- mmaunder 1y ago
  “With this approach, I can manage to have 10–20 pull requests open at once, each handled by a dedicated agent.” A quote from the post. No, I think my post is calibrated quite well considering what OPs post does to our industry.
  - hu3 1y ago
    Having 20 PRs open at once doesn't necessarily mean managing 20 agents simultaneously. It can mean, for example, that 2 agents worked for some time in a list of 20 TODO features and produced 20 PRs to be reviewed. They could have worked overnight even. You're seemingly judging from the least generous interpretation, which is not constructive and is also against HN guidelines fyi.
    - shiroyasha 1y ago
      Exactly! To make it more clear, here is how I approach my day: 9-10am: I comb through our issue list, figuring out which issues are well defined, which need more input or design decision. => I pick a hand-full, lets say 10 that I kick off to run in the background, and lets say another 10 for further specification. 10-2pm: I thinker with 10 issues to figure out the exact specs and to expand the requirement list. 2pm-6pm: I review the code written by the agents, one by one. I kick off for further work things that need more input, or merge things that look good.

pvtmert 1y ago

Is it me or the post sounding (showing!) that they haven't tried the mentioned approach in real life. Because in real life, one agent tries to fix build issue with rm -rf node_modules and the other is already running a server (ie: npm server), conflicting with each other nearly all the time!. (even if it's not a destructive action, the second npm server will most likely to fail due to port-allocation conflicts!) Meanwhile, what I found helpful is that: 1. Clone the same repo twice or three times 2. In each terminal or whatever, `cd` into it 3. Create a branch, run your ~commands~ prompts (each is their own session with their own repo) 4. commit/push then merge/rebase (also resolve conflicts if needed, use LLM again if you want) Any other way multiple agents work in harmony in a single repo (filesystem/directory) at the same time is a pipe-dream with the current status of the MCP and agents. Let alone being aware of each other (agents), they don't even have a proper locking mechanism. As soon as you make a new change, most of the editing (search/replace) functionality in the MCPs fail miserably. Then they re-read the entire file, just creating context-rot or over-filling with already-existing stuff. Soon you run out of tokens (or just pay extra for no reason) > edit: comments mentioned that each agent runs in a VM isolated from others, kinda makes sense but still, there will be massive merge-conflicts unless each agent runs in a completely different set of service/code-base (ie frontend vs backend or couple of micro-services)

GZGavinZhao 1y ago
git workspaces?
- lacasito25 1y ago
  u mean worktrees
  - GZGavinZhao 1y ago
    Ah yes I used much jj lol
abound 1y ago
The post is about using GitHub's integrated Copilot tooling, where each issue gets its own instance presumably running in a sandbox. This sidesteps the issues you're talking about here.

anthem2025 1y ago

Less convincing when you open up by gushing about every other lame AI tech then proceed to insist that this new thing is the real revolution. Comes across as someone who just wants to shill for AI for some reason.

adriand 1y ago

I'm starting to think that the rather slow nature of Claude Code is a feature. In fact if they suddenly sped things up by 10X, I would want an option to slow it back down. Sometimes I am fine with it working unsupervised while I empty the dishwasher or take a shower, but a lot of the time I watch it work. Not only does this help me stop it from going down rabbit holes / chewing through all of my Opus usage cap, but I have a much better understanding of what it's built, in the same way I might if I was pair-programming with someone and they were driving. The idea of having multiple instances working in parallel sounds like a nightmare to me. I find this technology works best when it is guided, ideally in real time.

sovietmudkipz 1y ago

To those who have worked with autonomous background agents techniques, can you describe the stack and the workflow? Has anyone set up a local only autonomous agent, using an open source model from somewhere like huggingface? Still a bit confused on the details of implementing the technique. Would appreciate any explanations (thanks in advance).

ravila4 1y ago

My experience with parallel agents is that the bottleneck is not how fast we can produce code but the speed at which we can review it and context switch. Realistically, I don’t think most people have the mental capacity to supervise more than one simultaneous task of any real complexity.

jongjong 1y ago

I totally disagree about the monorepo argument. Mono-repos exist as a reaction to poor modularization and tight coupling which creates a need to update dependencies frequently. The reason for having dependencies in the same repo as the trunk of the project code is precisely because the dependencies aren't sufficiently generic, too dependent on the project's business domain and so they require constant maintenance. This tight coupling means that the agent requires more context to solve problems and implement simple features. The need for more context is a problem for agents, not a benefit. Agents benefit from modularization, loose coupling and well-chosen abstractions. These attributes do not correspond to the kinds of complex, tightly integrated codebases which benefit from having a monorepo structure. Dependencies should be like tools. If you think of a hammer, you can do a lot of different jobs with the same hammer... You can debate whether or not a hammer is the right tool for any given job, but for those jobs where a hammer is the right tool, how often do you need to tweak the hammer itself? A hammer solves a very specific problem but that problem can be generalized to countless different use cases. A hammer would make a good module. Now if you did a project for a candle factory and let the project business domain leak into the design of your tools/modules; you may build a hammer out of wax to straighten out candles... Then in your next project building a house you will find that this hammer doesn't work for that case and needs to be modified. This is a failure of separation of concerns. The tool was not originally optimized for the specific task of applying blunt force to a limited area; it couldn't do that narrow job very well and that's why it needs to be changed. Had you built a hammer out of steel, it would likely have solved both problems even through it's a completely different use case.

ath3nd 1y ago

Counteropinion: neither parallel nor single threaded agents are a gamechanger. I mean they might be changing the game into prodicing more hard to maintain software, faster, but if that is the game you are playing, I dont wanna participate.