Managing Coding Agents at Scale Requires Better Visibility, Autonomy, and Review

Ido Salomon’s central question is not whether coding agents can do useful work. They can produce everything from “cat memes to B2B SaaS apps,” he says. It is why that capability has not made people “unstoppable”—why users cannot simply spin up an army of agents and put it to work.

Salomon’s answer is that the user becomes the constraint. Running many agents is not just a matter of opening more terminals. Each one has to be steered, directed and reviewed. “Each one of these agents requires you to steer them, direct them, review them,” he says. “And when it’s at scale, especially, it’s just exhausting.”

A post shown during the talk depicts multiple monitors running agent processes. Salomon uses that image to contrast the apparent promise of scale with the attention it takes to manage agents. His analogy for what might help comes from strategy games: in Warcraft or The Sims, a player watches multiple units, works out what they are doing and decides where attention is needed. Salomon argues that supervising agents may draw on skills people already use when coordinating activity in games. AgentCraft takes that comparison literally, turning agent orchestration into a strategy-game-like interface.

AgentCraft’s design addresses that strain through three ideas: making work visible, delegating more of it to autonomous processes, and letting people collaborate around agents. Salomon presents those ideas as ways to raise the ceiling for users who want to coordinate more work. He also argues that a detailed strategy-game interface will not suit everyone, and shows an early, simpler concept intended to lower the barrier to entry.

Ido Salomon represents coding agents as units on a map. Salomon says those units can stand for Claude Code, Open Interpreter or other agents the user has available. The system can detect agents on a device, or users can launch new ones from within AgentCraft. Users can prompt agents through a side panel, including by voice. The map also includes functions such as plugins and skills, alongside an integrated terminal and Git, so users can do their work from within the interface.

The first problem Salomon tackles is visibility: knowing which agents are working, what they are doing and which ones need attention. A side panel lists agents and their tasks, recent activity and status. One example shows an agent awaiting input on a README task, with its context usage and last active time also displayed. The point is to make it possible to see quickly which agents are waiting and which are still working.

Salomon also projects the file system onto the map. Files appear as runes, so users can see which agent is working in a directory or accessing a particular file, and inspect what it did and when. He says the system can use that activity to create lineages and heat maps, making areas of active work easier to spot.

Visibility is paired with a way to act on what it reveals. Pressing the space bar takes the user to the nearest item requiring attention. From there, the user can answer a question, approve a plan or move to the next issue. The navigation borrows from real-time strategy games and Civilization, where a player can jump between points of interest instead of searching the whole map.

But Salomon says visibility does not remove the burden of supervision. It lets a user see what agents are doing and find a point that needs attention; it does not make the number of decisions manageable. Inspecting files and tools at that level of detail remains exhausting. Nor can he hold twenty tasks in mind or easily decide what to do next in a large coding project. Seeing the work is one part of the problem; keeping every task moving is another.

Ido Salomon describes one response to the difficulty of deciding what to work on: have agents inspect a codebase and suggest tasks. He calls these tasks “quests.” A user can accept a proposed piece of work rather than having to formulate it from scratch. In the demo, one quest proposes adding validation for environment variables and incoming API payloads.

But delegating task discovery can create another management burden if each accepted task needs to be babysat. Salomon’s next step is to give an agent a broader goal and let it break the work down. An orchestrator can divide a feature into tasks and run them in an isolated local container. He describes this as a way to let the agent carry out the work without the user supervising every step as it happens.

He also describes loops that can work in the background. For example, a user could ask an agent to scan Twitter for ideas to build or inspect GitHub and generate possible features. Salomon presents these as ways to reduce how much direction the user must provide up front.

That autonomy does not remove the need for human attention; it changes where the pressure falls. Rather than continually steering each step, the user must assess the work agents have produced. Salomon says that reviewing even five tasks at once can be difficult, so AgentCraft includes a review kit that gathers changes for inspection. Users can look at changed files individually or review task summaries and acceptance criteria. They can also examine visual evidence, such as videos or images of what changed, and run several implementations in parallel to choose the one they prefer.

In the demo, the review kit presents a completed-task checklist, a summary of changes and acceptance criteria. Salomon’s goal is to make the work easier to assess without requiring users to inspect every detail in the same way. Review remains necessary; the kit changes what is gathered for review and how the user can examine it.

Ido Salomon says visibility and autonomy do not answer who should be doing the managing. Working alone with agents can feel lonely; in a team, the person overseeing a task may not be the right person to review it. His third element is collaboration: other people can join the work.

AgentCraft’s shared rooms—also called halls or war rooms—let other people join a workspace. Salomon describes the setup as hosted locally, with tunnels that allow others to connect. In his example, a product designer joins and works on a design task while an engineer can see that work on the map and continue from it. He describes approving the designer’s access before she begins.

A colleague can pick up or fork work while another person continues their own task. Salomon says this means the team is not bound to Git as the only way to share work, though Git remains available. A notice board and chat show what each person and agent is doing; he says agents in the room can also be aware of one another and collaborate more closely. He demonstrates taking on a design task and following up with an implementation while the designer continues working.

Salomon also shows the interface on a mobile device and mentions Telegram as another possible way to interact. The shared room is his proposed way for teammates to see one another’s activity and take part in work alongside agents, rather than leaving one person to oversee everything alone.

Ido Salomon says AgentCraft has helped power users do more, but he was especially interested in feedback from people who had not previously used agents or productivity tools. He recounts hearing that users’ children liked the interface and used it to orchestrate agents. One user, he says, described having flunked out of college because of a StarCraft addiction and finding the tool a good fit. Other feedback came from people who played games such as Age of Empires and Civilization, including a nontechnical user who wanted to deploy agents.

For Salomon, these responses point to a design possibility: familiar game conventions may help some people approach agent use. But the detailed map that helps one user coordinate work may feel complicated or daunting to another, especially if that person does not want to manage files and directories.

His experimental concept, provisionally called Loopers, explores a different tradeoff. Rather than showing exactly which files an agent is working on, it centers on projects a person returns to. The interaction is closer to “I prompt, I get the result.” Users could inspect how the agent worked if they wanted, but would not need to follow its underlying activity to use the tool. The demo shows projects, task progress and a request for approval in a simplified, mobile-game-style interface.

Salomon says the simpler concept is a very early draft, and that the design will not feel intuitive to everyone. What seems easy to one person may be difficult to another; he is exploring how the experience might be customized around what different users need in order to understand and use agent tools. He estimates that perhaps 90% of people need a lower-friction way into an “agentic future.”

AgentCraft is available to install; Loopers remains experimental, and Salomon asks interested users to say what they are looking for. In his framing, the detailed map and the project-focused interface are different ways of meeting users where they are: one makes more of the underlying activity visible, while the other asks users to engage with less of that detail.