The best IDE for agentic AI may not be an IDE at all

Steve Yegge asked on X for recommendations on managing 10 to 20 or more coding agents, drawing 600 replies that surfaced tools like Herdr, cmux, Conductor, and the Claude and Codex desktop apps, plus a wave of homemade software. The most notable pattern in the replies, per the piece, is that developers are building custom shortcuts, workspace switchers, and session managers to track what they asked their agents to do rather than to improve the agents themselves. Mark Jaquith uses Herdr with a custom interface to jump to an agent needing attention, Kai Backman built a keyboard shortcut to the next actionable spot, and Jacob Voytko created a workspace switcher grouping tasks within milestones.

Steve Yegge is not the shy and retiring type, so when he wants recommendations on how others are managing 10 to 20 or more coding agents, he posts the question on X https://x.com/Steve Yegge/status/2098436843780153820 . Specifically, he’s looking for an IDE because “I use Emacs, and I wouldn’t wish it on you.” The replies 600 and counting offer plenty of alternatives: Herdr, cmux, Conductor, the Claude and Codex desktop apps, and an impressive assortment of homemade software. For anyone hoping the industry had settled on a sensible way to work with agents, clearly we haven’t. Hence, Yegge’s question. The most interesting data hidden in the replies, however, isn’t which IDE or IDE stand-in developers are using. Rather, it’s what developers have added to these tools to accommodate the technology’s shortcomings. These include shortcuts to find the agent that needs a decision, ways to recover an earlier conversation, and groupings that explain how a task fits into a project. In other words, despite the incredible intelligence we now have to help us write code, developers are still struggling with the simple task of automating their remembrance of what they asked AI to do. We seem to have made it easier to generate work without making it easier to absorb and finish work. Mark Jaquith uses Herdr with a custom interface https://x.com/markjaquith/status/2098478378722476057 to jump to an agent needing his attention. Kai Backman has been working on a keyboard shortcut https://x.com/kaibackman/status/2098476669086372138 to take him to the “next most relevant place to take action.” Jacob Voytko built a workspace switcher https://x.com/jakevoytko/status/2098440211709526195 that groups tasks within milestones and lets him jump to the corresponding tickets and pull requests. He wanted a visual sense of where the work stood, rather than an unstructured list. Another respondent, Basil https://x.com/BasilMakesRagu/status/2098473531529126353 , built a manager that helps him “find the session where we did x.” Of course, developers have always customized their tools. Emacs users alone could supply scads of evidence. But, again, it’s not really about the fact that developers are tweaking their tools, but why . So much of the tweaking is intended to help cohere the developer’s intentions with the work that’s happening in several places at once. They’re not asking for better AI: They’re asking for AI to help them express their humanity, as it were. Consider a developer who asks one agent to fix a bug, another to investigate a performance problem, and a third to update a dependency. While the agents work, she can do something else, which is what makes LLM-driven development so appealing—at least, until the agents return. None of those agents does work that is fully isolated from the rest of the system. Think about it: The bug fix changes behavior someone may depend on. OK … we can address that But wait, now we have the performance investigation offering three options, each with different costs. Hmm. Hold on a minute while I tackle this … except the dependency update isn’t waiting. It passes its tests, but the agent has also rewritten a configuration file. Better check that As this simple example shows, before the developer can move forward on any decision, she first needs to recover what she asked for, what the agent discovered, and what remains uncertain. And, no, adding more agents doesn’t solve the problem. It could instead compound the problem. The agents may have saved hours. Hurray But a list of completed sessions doesn’t tell the developer where to begin. Nor does a green test result answer the question of whether the change belongs in the application. This is why the number of agents running tells us so little, even if it makes us feel cool. I mean, what are those agents doing, anyway? Yegge’s commenters provide some clues. For example, Anton describes using 30 terminal tabs https://x.com/podviaznikov/status/2098483930345119904 with one active agent per project, so as to keep their work from overlapping. Jerry Combs says he generally keeps no more than three conversations going https://x.com/PointBlueTech/status/2098466250972123539 , with agents managing their own subagents as needed. Even those three conversations are difficult enough to follow. Both approaches can make sense. The demands depend on how independently the work can proceed and how much human judgment it requires along the way. A developer with 20 agents may have fewer decisions to make than someone with three. Gergely Orosz recently listed several observations worth considering together https://x.com/GergelyOrosz/status/2098357328504373390 : developers spending less time in IDEs, code reviews becoming theater, and people working more despite AI’s productivity promises. His observations don’t establish that agent tools cause overwork or superficial review. They do make it worth asking whether we’re shifting effort into places our productivity stories neglect. Watching an agent produce a change is satisfying, but spending the afternoon reconstructing why six changes were made is less so. But that work, however unsatisfying, is necessary if those changes are going to be understood and maintained. Some of the plumbing already exists to alleviate these issues. For example, Herdr tracks agents as working, blocked, or idle https://herdr.dev/docs/agents/ and carries those states into its tabs and workspaces; cmux offers notifications and a shortcut https://cmux.com/docs/notifications to the workspace with the most recent unread notification. These are useful starts, but they do highlight just how much remains to be done. After all, the most recent notification may concern the least important task, and an agent asking a question may be perfectly capable of waiting while the developer finishes something else. The next improvement should help developers make those distinctions. A task should retain its original purpose, the relevant decisions, and the evidence supporting its result. When it needs a person, it should explain the decision required and what happens if that decision waits. A summary can help, but it must lead back to the actual changes and test results. Otherwise, we’ve made it easier to approve work without understanding it. Again, the best tools for agentic AI will be the ones that bring the human back into the loop and provide the information necessary to make decisions. I’d like a tool that can tell me a task is ready for review because the requested behavior has been demonstrated, while keeping a separate, less urgent question out of my way. I’d also like it to remember that I rejected an approach yesterday, so I don’t have to discover it again in today’s proposed fix. Whether that tool calls itself an IDE seems secondary. Google introduced Antigravity 2.0 as a standalone agent application https://antigravity.google/blog/introducing-google-antigravity-2 without an IDE, while recommending that developers use it alongside their IDE of choice. In other words, the editor still has a job, even when it is no longer where every task begins. In 2022, I wrote about cloud convenience https://www.infoworld.com/article/2334661/cloud-convenience-and-open-source.html and the tendency to misunderstand what developers want from their tools. They have work to do and want fewer obstacles to doing it. We should apply that same standard to agentic development across the whole task, including the effort of returning to it. Not that we can put all the onus on AI and its tools. Teams have a part to play here. If every task is urgent, the tool has nothing useful to prioritize. If nobody defines what counts as finished, the tool can only report that an agent stopped. Agreeing on those things and limiting the work that needs simultaneous human decisions will do more than adding another status badge. Yegge’s readers are already building pieces of this future, one shortcut and homemade workspace at a time. The vendor opportunity is to make that convenience available without requiring everyone to maintain a side project. Give developers more work they can confidently put behind them and fewer conversations they need to keep alive in their heads.