I'd like others' input on this: increasingly, I see Cursor, Jetbrains, etc. moving towards a model of having you manage many agents working on different tasks simultaneously. But in real, production codebases, I've found that even a single agent is faster at generating code than I am at evaluating its fitness and providing design guidance. Adding more agents working on different things would not speed anything up. But perhaps I am just much slower or a poorer multi-tasker than most. Do others find these features more useful?
I usually run one agent at a time in an interactive, pair-programming way. Occasionally (like once a week) I have some task where it makes sense to have one agent run for a long time. Then I'll create a separate jj workspace (equivalent of git worktree) and let it run.
I would probably never run a second agent unless I expected the task to take at least two hours, any more than that and the cost of multitasking for my brain is greater than any benefit, even when there are things that I could theoretically run in parallel, like several hypotheses for fixing a bug.
IIRC Thorsten Ball (Writing an Interpreter in Go, lead engineer on Amp) also said something similar in a podcast – he's a single-tasker, despite some of his coworkers preferring fleets of agents.
My CTO is currently working on the ability to run several dockerised versions of the codebase in parallel for this kind of flow.
I’m here wondering how anyone could work on several tasks at once at a speed where they can read, review and iterate the output of one LLM in the time it takes for another LLM to spit an answer for a different task.
Like, are we just asking things as fast as possible and hoping for a good solution unchecked? Are others able to context switch on every prompt without a reduction in quality? Why are people tackling the problem of prompting at scale as if the bottleneck was token output rather than human reading and reasoning?
If this was a random vibecoding influencer I’d get it, but I see professionals trying this workflow and it makes me wonder what I’m missing.
Rather than having multiple agents running inside of one IDE window, I structure my codebase in a way that is somewhat siloed to facilitate development by multiple agents. This is an obvious and common pattern when you have a front-end and a back-end. Super easy to just open up those directories of the repository in separate environments and have them work in their own siloed space.
Then I take it a step further and create core libraries that are structured like standalone packages and are architected like third-party libraries with their own documentation and public API, which gives clear boundaries of responsibility.
Then the only somewhat manual step you have is to copy/paste the agent's notes of the changes that they made so that dependent systems can integrate them.
I find this to be way more sustainable than spawning multiple agents on a single codebase and then having to rectify merge conflicts between them as each task is completed; it's not unlike traditional software development where a branch that needs review contains some general functionality that would be beneficial to another branch and then you're left either cherry-picking a commit, sharing it between PRs, or lumping your PRs together.
Depending on the project I might have 6-10 IDE sessions. Each agent has its own history then and anything to do with running test harnesses or CLI interactions gets managed on that instance as well.
Even with the best agent in plan mode, there can be communication problems, style mismatches, untested code, incorrect assumptions and code that is not DRY.
I prefer to use a single agent without pauses and catch errors in real time.
Multiple agent people must be using pauses, switching between agents and checking every result.
I think this is the UX challenge of this era. How to design a piece of software that aids in promoting the human-level of attention to a distributed state without causing information loss or cognitive decline over many tasks. I agree that for any larger piece of work with significant scope the overhead of ingesting the context into your brain offsets the time saving costs you get from multitask promises.
My take on this is that the better these things get eventually we will be able to infer and quantify signals that provide high confidence scores for us to conduct a better review that requires a shorter decision path. This is akin to how compilers, parsers, linters, can give you some level of safety without strong guarantees but are often "good enough" to pass a smell test.
No... I've found the opposite where using the fastest model to do the smallest pieces is useful and anything where I have to wait 2m for a wrong answer is just on the way.
There's pretty much no way anyone context switching that fast is paying a lick of attention. They may be having fun, like scrolling tiktok or playing a videogame just piling on stimuli, but I don't believe they're getting anything done. It's plausible they're smarter than me, it is not plausible they have a totally different kind of brain chemistry.
The parallel agent model is better for when you know the high level task you want to accomplish but the coding might take a long time. You can split it up in your head “we need to add this api to the api spec” “we need to add this thing to the controller layer” etc. and then you use parallel agents to edit just the specific files you’re working on.
So instead of interactively making one agent do a large task you make small agents do the coding while you focus on the design.
My context window is small. It's hard enough keeping track of one timeline, I just don't see the appeal in running multiple agents. I can't really keep up.
Right. A computer can make more code than a human can review. So, forget about the universe where you ever review code. You have to shift to almost a QA person and ignore all code and just validate the output. When it is suggested that you as a programmer will disappear, this is what they mean.
I'm with you. The industry has pivoted from building tools that help you code to selling the fantasy that you won't have to. They don't care about the reality of the review bottleneck; they care about shipping features that look like 'the future' to sell more seats.
I have to agree, currently it doesn't look that innovative. I would rather want parallel agents working on the same task, orchestrated in some way to get the best result possible. Perhaps using IntelliJ for code insights, validation, refactoring, debugging, etc.
Completely agree. The review burden and context switching I need to do from even having two running at once is too much, and using one is already pretty good (except when it’s not).
I think the problem is that current AI models are slow to generate tpkens so the obvious solution is 'parallelism'. If they could poop out pages of code instantly, nobody would think about parallel agents.
I wish we'll get a model that's not necessarily intelligent, but at least competent at following instructions and is very fast.
I overwhelmingly prefer the workflow where I have an idea for a change and the AI implements it (or pushes back, or does it in an unexpected way) - that way I still have a general idea of what's going on with the code.
Not to rain on their parade, but I do find it at least a little bit funny that Kotlin Multiplatform is JetBrains's prerogative and the app is Mac only, lol...
I really like this initiative, I think the biggest value here isn't the multiple sessions or worktrees, but an interoperable protocol between these coding agents through a new UX. A sort of parent process orchestrator of the many agents is something I want, is there other tools that do that today? e.g. run Claude, Codex, Gemini, all together and sharing data with one another?
So do we actually get to edit any of the AI code additions or changes or is this just "PR merge hell mode" in Project Manager Simulator? Yes, I could flip over to my editor, but that kind of misses the whole point of the 'I' in "IDE".
I'm team JetBrains4Life when it comes to IDEs, but their AI offerings have been a pretty mixed bag of mixed messages. And this one requires a separate subscription at that when I'm already paying for their own AI product.
Not to be overly negative but I’m kinda disappointed with this and I have been a JetBrains shill for many years.
I already use this workflow myself, just multiple terminals with Claude on different directories. There’s like 100 of these “Claude with worktrees in parallel” UIs now, would have expected some of the common jetbrains value adds like some deep debugger integration or some fancy test runner view etc. The only one I see called out is Local History and I don’t see any fancy diff or find in files deep integration to diff or search between the agent work trees and I don’t see the jetbrains commit, shelf, etc. git integration that we like.
I do like the cursor-like highlight and add to context thing and the kanban board sort of view of the agent statuses, but this is nothing new. I would have expected at the least that jetbrains would provide some fancier UI that lets you select which directories or scopes should be auto approved for edit or other fancy fine grained auto-approve permissions for the agent.
In summary it looks like just another parallel Claude UI rather than a Jetbrains take on it. It also seems like it’s a separate IDE rather than built on the IntelliJ platform so they probably won’t turn it into a plugin in the future either.
A cursor style "tab" model, but trained on jetbrains IDEs with full access to their internals, refactoring tools and so on would be interesting to see.
Umm, it ain't ever gonna be over, it is a new era.
We need to adapt to new ways of thinking and ways of working with new tooling. It is a learning curve of sorts. What we want is to solve problems, the new tooling enables us to solve problems better by letting us free up our thinking by reducing blockers and toil tasks, giving us more time to think about higher level problems.
I remember this same sentiment towards AI when I was growing up, but towards cell phones...
Umm, it ain't ever gonna be over, it is a new era.
We need to adapt to new ways of thinking and ways of working with new tooling. It is a learning curve of sorts. What we want is to solve problems, the new tooling enables us to solve problems better by letting us free up our thinking by reducing blockers and toil tasks, giving us more time to think about higher level problems.
Ooof I forgot to cancel my jetbrains all products license when I switched to vs code. I better go do that now before it renews. Not because of AI but it also doesn’t help
rfw300|2 months ago
SatvikBeri|2 months ago
I would probably never run a second agent unless I expected the task to take at least two hours, any more than that and the cost of multitasking for my brain is greater than any benefit, even when there are things that I could theoretically run in parallel, like several hypotheses for fixing a bug.
IIRC Thorsten Ball (Writing an Interpreter in Go, lead engineer on Amp) also said something similar in a podcast – he's a single-tasker, despite some of his coworkers preferring fleets of agents.
kace91|2 months ago
My CTO is currently working on the ability to run several dockerised versions of the codebase in parallel for this kind of flow.
I’m here wondering how anyone could work on several tasks at once at a speed where they can read, review and iterate the output of one LLM in the time it takes for another LLM to spit an answer for a different task.
Like, are we just asking things as fast as possible and hoping for a good solution unchecked? Are others able to context switch on every prompt without a reduction in quality? Why are people tackling the problem of prompting at scale as if the bottleneck was token output rather than human reading and reasoning?
If this was a random vibecoding influencer I’d get it, but I see professionals trying this workflow and it makes me wonder what I’m missing.
tcdent|2 months ago
Then I take it a step further and create core libraries that are structured like standalone packages and are architected like third-party libraries with their own documentation and public API, which gives clear boundaries of responsibility.
Then the only somewhat manual step you have is to copy/paste the agent's notes of the changes that they made so that dependent systems can integrate them.
I find this to be way more sustainable than spawning multiple agents on a single codebase and then having to rectify merge conflicts between them as each task is completed; it's not unlike traditional software development where a branch that needs review contains some general functionality that would be beneficial to another branch and then you're left either cherry-picking a commit, sharing it between PRs, or lumping your PRs together.
Depending on the project I might have 6-10 IDE sessions. Each agent has its own history then and anything to do with running test harnesses or CLI interactions gets managed on that instance as well.
nurettin|2 months ago
I prefer to use a single agent without pauses and catch errors in real time.
Multiple agent people must be using pauses, switching between agents and checking every result.
hmokiguess|2 months ago
My take on this is that the better these things get eventually we will be able to infer and quantify signals that provide high confidence scores for us to conduct a better review that requires a shorter decision path. This is akin to how compilers, parsers, linters, can give you some level of safety without strong guarantees but are often "good enough" to pass a smell test.
coffeefirst|2 months ago
There's pretty much no way anyone context switching that fast is paying a lick of attention. They may be having fun, like scrolling tiktok or playing a videogame just piling on stimuli, but I don't believe they're getting anything done. It's plausible they're smarter than me, it is not plausible they have a totally different kind of brain chemistry.
faizshah|2 months ago
So instead of interactively making one agent do a large task you make small agents do the coding while you focus on the design.
tortilla|2 months ago
ivape|2 months ago
jasonsb|2 months ago
NumerousProcess|2 months ago
dwb|2 months ago
torginus|2 months ago
I wish we'll get a model that's not necessarily intelligent, but at least competent at following instructions and is very fast.
I overwhelmingly prefer the workflow where I have an idea for a change and the AI implements it (or pushes back, or does it in an unexpected way) - that way I still have a general idea of what's going on with the code.
minus7|2 months ago
minus7|2 months ago
- syntax errors displaying persistently even after being fixed (frequently; until restarted; not seen very recently)
- files/file tree not detecting changes to files on disk (frequent; until restarted; not seen very recently)
- cursor teleporting to specific place on the screen when ctrl is pressed (occasionally; until restarted)
- and most recently: it not accepting any mouse/keyboard input (occasionally; until killed))
dzhiurgis|2 months ago
piker|2 months ago
amateurhuman|2 months ago
https://news.ycombinator.com/item?id=44043231
gavinray|2 months ago
buster|2 months ago
gfody|2 months ago
cheptsov|2 months ago
Congrats to the team. Can’t wait to try it.
hmokiguess|2 months ago
jmalicki|2 months ago
BrandonSmith|2 months ago
https://blog.jetbrains.com/codecanvas/2025/10/jetbrains-is-s...
otekengineering|2 months ago
https://omnispect.dev
torginus|2 months ago
onionisafruit|2 months ago
tecoholic|2 months ago
chuckadams|2 months ago
I'm team JetBrains4Life when it comes to IDEs, but their AI offerings have been a pretty mixed bag of mixed messages. And this one requires a separate subscription at that when I'm already paying for their own AI product.
bjacobso|2 months ago
faizshah|2 months ago
I already use this workflow myself, just multiple terminals with Claude on different directories. There’s like 100 of these “Claude with worktrees in parallel” UIs now, would have expected some of the common jetbrains value adds like some deep debugger integration or some fancy test runner view etc. The only one I see called out is Local History and I don’t see any fancy diff or find in files deep integration to diff or search between the agent work trees and I don’t see the jetbrains commit, shelf, etc. git integration that we like.
I do like the cursor-like highlight and add to context thing and the kanban board sort of view of the agent statuses, but this is nothing new. I would have expected at the least that jetbrains would provide some fancier UI that lets you select which directories or scopes should be auto approved for edit or other fancy fine grained auto-approve permissions for the agent.
In summary it looks like just another parallel Claude UI rather than a Jetbrains take on it. It also seems like it’s a separate IDE rather than built on the IntelliJ platform so they probably won’t turn it into a plugin in the future either.
GiorgioG|2 months ago
NitpickLawyer|2 months ago
A cursor style "tab" model, but trained on jetbrains IDEs with full access to their internals, refactoring tools and so on would be interesting to see.
ur-whale|2 months ago
Said the assembly senior specialist when first confronted with this newfangled fortran compiler shit.
ElijahLynn|2 months ago
We need to adapt to new ways of thinking and ways of working with new tooling. It is a learning curve of sorts. What we want is to solve problems, the new tooling enables us to solve problems better by letting us free up our thinking by reducing blockers and toil tasks, giving us more time to think about higher level problems.
I remember this same sentiment towards AI when I was growing up, but towards cell phones...
ElijahLynn|2 months ago
We need to adapt to new ways of thinking and ways of working with new tooling. It is a learning curve of sorts. What we want is to solve problems, the new tooling enables us to solve problems better by letting us free up our thinking by reducing blockers and toil tasks, giving us more time to think about higher level problems.
AJRF|2 months ago
matt3210|2 months ago