When Developers Tamed Ten Code Ninjas

Steve Yegge, who has never met a subtle tweet he could resist, recently asked X how people wrangle ten, twenty, or more coding agents without losing their minds. The replies piled up faster than a build cache after a dependency update: Herdr, cmux, Conductor, Claude, Codex, and a menagerie of homemade contraptions. The real gem was not which interface won, but the tiny life rafts developers had built: shortcuts to find the agent waiting on a human, ways to recover an old conversation, and grouping systems that turn chaos into a legible project. AI may write code now, but remembering what we asked it to do still resembles herding caffeinated ferrets.\nThis is the strange bargain of agentic development: generating work has become frictionless, while absorbing work remains a swamp. A developer tells one agent to fix a bug, another to investigate a performance dip, and a third to update a dependency. While they potter, she pours coffee, answers email, and pretends this is productivity. Then the agents return. The bug fix changes behavior someone else assumed was stable. The performance agent offers three clever options, each with its own trade-off. The dependency update passes tests and, cheerfully, rewrites a configuration file. Before she can decide anything, she must retrace: what was asked, what was discovered, and which uncertainties are still lurking.\nThat last part is deeply relatable. I once asked an assistant to “clean up” a small script. What returned was a tasteful pile of changes, a new utility function, and one mysterious comment that said “refactor later,” as if my future self were a mythical librarian. The code worked, sure, but the explanation was thinner than the original bug fix. I did not feel smarter. I felt like a detective who had inherited a crime scene.\nGergely Orosz recently noticed developers spending less time in IDEs, code reviews turning into ceremonial nods, and productivity promises arriving with extra hours attached. That does not prove agent tools cause overwork, but it hints that effort is migrating to places we do not photograph for productivity decks. Watching an agent produce code is satisfying. Reconstructing why six changes appeared is like being handed six wrapped gifts and no names.\nThe answer may not be more autonomous agents, but tools that learn to wait. They should keep a task’s purpose, decisions, and evidence attached, not just a green test light. They should distinguish “needs a human now” from “can wait until Tuesday.” A summary helps only if it leads back to real changes. In 2022, I argued developers want fewer obstacles between intention and finished work. The same is true now. Whether the editor is still where every task begins matters less than whether it helps us close a task and walk away with confidence.\nSo the best tool may not be the one that runs the most agents. It is the one that remembers enough, asks clearly, and then lets a human do the rarest possible thing in software: understand it.