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.
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.
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.
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.
For some things its helpful, like have one agent plan changes / get exact file paths, another agent implement changes, another agent review the PR, etc. The context window being small is the point I think. Chaining agents lets you break up the work, and also give different agents different toolsets so they aren't all taking a ton of MCPs / Claude Skills into context at once.
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 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.
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 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?
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...
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
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...
I will empathize with you there. I totally want to understand everything too. I LOVE being elbow deep in code for hours on end, especially late nights, so, much, FUN!!!
It is just now, I don't have to do that to actually build something meaningful, my ability to build is increased by some factor, and it is only increasing.
And coding LLM's have become a great teacher for me, and I learn much faster, for when I do want to dig deeper into the code, I can ask very nuanced questions about what certain code is doing, or how it works and it does a fairly good job of explaining it. Similar to how a real person would if I were in meat space at an office. Which I don't get that opportunity anymore in this remote life.
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'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.
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.
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.
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.
For some things its helpful, like have one agent plan changes / get exact file paths, another agent implement changes, another agent review the PR, etc. The context window being small is the point I think. Chaining agents lets you break up the work, and also give different agents different toolsets so they aren't all taking a ton of MCPs / Claude Skills into context at once.
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 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.
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.
JetBrains should stop building stupid AI shit and fix their IDEs. 2025 versions are bordering on unusable.
Issues I observed, mostly using GoLand:
- 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))
Looks similar to Omnispect
https://omnispect.dev
The litmus test for the utility of this kind of thing is does JetBrains prefer to use Air to develop Air--i.e., is it self-hosting?
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?
Something like Shrimp is useful for at least coordinating different Claude subagents.
Seems like the best competitor to Conductor at the moment. They did a great job.
Finally a step in the right direction. This brings the best of two worlds: the lightweightness of Fleet and agents battle-tested with Junie/IntelliJ.
Congrats to the team. Can’t wait to try it.
Seems this is the product JetBrains mentioned in their sun-setting announcement of the short-lived CodeCanvas product.
https://blog.jetbrains.com/codecanvas/2025/10/jetbrains-is-s...
I've been drifting from jetbrains to zed lately, but this is making it difficult. I can probably do something similar in zed, but I don't know how.
I think it’s just multiple git work trees and multiple zed windows.
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...
It's a preview, isn't it? The pages says win, mac, Linux.
Yeah. Windows, Linux, and Web are listed under "What's Coming"
market research shows that 100% of the people interested in this style of development are mac users
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
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.
I've just spent the day reading and reviewing the absolute slop that comes out of these things :'(
Can't wait for this AI shit to be over so they can get back to their bread & butter...great dev tools.
> their bread & butter...great dev tools.
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.
They have that now. Not as great as cursor tab, but nothing is.
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...
> I remember this same sentiment towards AI when I was growing up, but towards cell phones...
Sure. But the same for NFTs.
We'll see which one this winds up being.
> What we want is to solve problems
speak for yourself, i want to understand everything and be elbow deep in the code
I will empathize with you there. I totally want to understand everything too. I LOVE being elbow deep in code for hours on end, especially late nights, so, much, FUN!!!
It is just now, I don't have to do that to actually build something meaningful, my ability to build is increased by some factor, and it is only increasing.
And coding LLM's have become a great teacher for me, and I learn much faster, for when I do want to dig deeper into the code, I can ask very nuanced questions about what certain code is doing, or how it works and it does a fairly good job of explaining it. Similar to how a real person would if I were in meat space at an office. Which I don't get that opportunity anymore in this remote life.
Capital has other ideas, it wants “problems” “solved” faster and faster.
bookmarking this to laugh at it in 2030
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.