One Developer, Two Dozen Agents, Zero Alignment
This talk is the first public demo of Ace – a new research prototype we’ve been building within the GitHub Next https://githubnext.com<br>team. Ace is a realtime, multiplayer coding agent workspace. It’s like Slack, GitHub, and Claude/Copilot had a baby. You work with agents, but also all your coworkers in the same space, sharing chats, context, and all using the same computers in the cloud to do the work.
At this point, in early 2026, all coding agents are designed as single player experiences. But building software isn’t a single player game. I talk through why we need collaborative AI engineering tools and show how we’re exploring the problem.
Video Recording
Welcome to this talk. One Developer, Two Dozen Agents, Zero Alignment: Why we need collaborative AI engineering
First, a quick intro. I’m Maggie and I’m a staff research engineer at GitHub Next. At least that’s my title, but I’m actually a designer. Or I was, back when that was still a separate thing to engineering.<br>Next is the labs team within GitHub. We work on more experimental, risky bets than the rest of org.<br>Also known as the department of fuck around and find out.<br>Like everyone else, we’re trying to shape new agentic developer tools
This is what many people think peak developer productivity looks like right now - a wall of terminal-based coding agents running in parallel on one person’s machine.<br>Demo video: Collaborator https://x.com/yiliush/status/2035788658574291355?s=20<br>by Yiliu https://yiliu.sh/
I call it this “one man, a two dozen claudes” theory of the future.<br>The pitch here is that one person with a fleet of agents will do the work of an entire team of developers.
The main problem with this dream is it assumes software is made by one person.
All these tools are single player interfaces.
And they focus on scaling up the work of the individual.<br>But there is limited value in scaling up an individual.<br>Because software is not made by one person in a vacuum.<br>It’s a team sport. Everyone building it needs to agree on what they’re building and why<br>Believing individual productivity leads to great software…
…is “nine women make a baby in one month” logic.<br>More individual output doesn’t solve problems that require everyone to communicate and coordinate. It makes them worse.
Implementation is rapidly becoming a solved problem, right?<br>Writing code is now fast, it’s getting cheap, and quality is going up and to the right.<br>The hard question is no longer how to build it. It’s should we build it.<br>Agreeing on what to build is the new bottleneck.<br>Everyone on the team needs to be involved in asking:<br>Are we making the right thing?<br>Are we spending our energy in the right place?<br>How do we have the most impact?<br>When production is cheap, opportunity cost becomes the real cost.<br>You can’t build everything, and whatever you pick comes at the cost of everything else.
Anyone who’s shipped software on a team knows this isn’t a new problem. Alignment has always been a bottleneck.<br>But agents have made the cost of not being aligned as a team much higher.
What makes it worse..
…is our coordination tools are still from another era.<br>GitHub, Slack, Jira, Linear, and the like, as they currently stand, are not designed for the agentic development world.<br>We’re funnelling masses of agentic outputs into platforms built for an outdated way of building software.<br>The PR and the issue are the wrong primitives that can’t handle the speed, shape, and volume of agentic work.<br>I know I work at GitHub so that might sound heretical, but I promise it’s not controversial for me to say it.<br>Very few people internally believe that PRs and issues are ideal primitives for the future of engineering.<br>And there are a lots of us inside the machine exploring what comes next.
So this is how the development process used to look. We had a planning phase, a building phase, a review phase.<br>And we had all these touch points of alignment along the way.<br>It was slow enough that we had time for conversations in Slack, Zoom meetings, comments on issues, and draft PRs to discuss details. Everyone could give their two cents, get advice from experts and seniors across the team, catch mistakes, and course-correct.<br>By the time the code was reviewed and merged, the whole team had seen the work happening and was roughly on the same page.
But that implementation window has collapsed.<br>And because implementation is no longer as expensive and time-consuming…
…we think we don’t need to plan as much.<br>So most of those early touch points disappear.
We know that the review time for generated code has increased.<br>So that creates more touch points for alignment, they’re on the wrong side of the implementation.
The time between logging an issue and an agent opening a PR for it is now only a few minutes.<br>Code is so cheap we don’t properly stop to think before prompting it.
Unhelpfully, most current coding agents have a local plan mode that is unshared with others.<br>So...