GitHub's ACE Tool Tackles AI Development's

The race to build with AI coding agents has produced a curious contradiction: tools that promise to multiply individual developer productivity while systematically dismantling the coordination mechanisms that make software development work.

Maggie Appleton, a staff researcher-engineer at GitHub Next, presented what she calls "the one man two dozen claudes theory of the future"—a wall of terminal-based coding agents running in parallel on a single developer's machine. The vision is seductive: one person with a fleet of agents doing the work of an entire development team. The problem, as Appleton argues, is that this vision "assumes that software is made by one person."

It's not, and the infrastructure of modern software development reflects that reality. Except now it doesn't.

The Collapsed Timeline

Traditional development workflow had three distinct phases: planning, building, and review. Each phase included natural alignment checkpoints—Slack conversations, Zoom meetings, comments on draft pull requests. The process was slow enough that teams could course-correct before implementation consumed significant resources.

AI agents have collapsed the implementation window from weeks to minutes. An agent can go from logged issue to open pull request in the time it takes to refill your coffee. This speed eliminates most early-stage alignment touchpoints. Teams no longer plan extensively because implementation feels cheap. But the review burden has increased—someone still needs to understand what the agent built and whether it should ship.

As Appleton notes: "When production is cheap, opportunity cost becomes the real cost. You can't build everything and whatever you pick comes at the cost of everything else."

The result is what she characterizes as wasted work: features nobody requested, critical feedback arriving after implementation is complete, merge conflicts from agents touching the same files, duplicate work from developers both racing to finish the same task, and mounting stacks of pull requests that nobody has context for.

The tools haven't caught up. GitHub pull requests and issues were designed for a different development cadence. Slack wasn't built to be a software development environment. Linear and Jira track work but don't provide shared context for agent-human collaboration. These platforms are, in Appleton's assessment, "funneling masses of agentic outputs into platforms that were built for an outdated way of building software."

She works at GitHub, which makes the criticism notable. But she's clear this isn't controversial internally: "There are very few people internally who believe that the PR and the issue are the future of software development."

ACE: GitHub's Research Answer

GitHub Next's response is ACE (Agent Collaboration Environment), a research prototype entering technical preview. Appleton describes it as looking "a bit like Slack, GitHub, Copilot, and a bunch of cloud computers had a baby."

The technical architecture centers on sessions—multiplayer chat channels backed by microVMs (sandboxed cloud computers on isolated git branches). Multiple developers can work in the same session, seeing each other's prompts to the agent, sharing terminal outputs, viewing the same live preview. No "doesn't work on my machine" issues because everyone is working on the same machine.

The interface deliberately lowers the barrier for non-engineers. Designers, product managers, customer support staff can all participate in the same conversation where features get built. They can see agent-generated code in real time, provide feedback, and direct the agent themselves without touching a terminal.

Crucially, planning and implementation happen in the same space. When a team needs to plan a complex feature, they collaboratively edit a planning document within ACE, seeing each other's cursors in real time. Once the plan is finalized, they direct the agent to implement it—with full context of the discussion that produced the plan.

ACE's dashboard attempts proactive alignment. It summarizes what teammates have shipped recently, reminds developers of unfinished work from Friday afternoon, and provides a "team pulse" of recent activity. The system has access to the full conversation history around code, creating what Appleton calls "a social information fabric" that agents can use to notify developers about relevant decisions or pull them into discussions about features they originally built.

The Unaddressed Questions

Appleton's diagnosis feels accurate, but ACE's solution raises implementation questions the demo doesn't fully address.

First, the cognitive load problem. If agents are shipping five features per developer per day instead of half a feature, how does a dashboard summary prevent information overload? The volume problem doesn't disappear just because the interface improves. Teams might trade coordination chaos for notification fatigue.

Second, the context accessibility issue cuts both ways. Having all conversations available to agents creates value for alignment. It also creates a complete record of every half-formed thought, political tension, and strategic pivot. The social dynamics of knowing everything is preserved and searchable could change how teams communicate—potentially making them more guarded at exactly the moment when Appleton argues they need to share context more freely.

Third, the backward compatibility question. ACE generates pull requests that flow back into GitHub's existing infrastructure. But if PRs and issues are inadequate for agent-driven development, how does straddling both systems solve the coordination problem? Teams using ACE still need to interact with teams that aren't. The transition path isn't clear.

Fourth, the quality argument. Appleton contends that reclaimed implementation time should fund better planning, more user research, deeper architectural thinking. But nothing in ACE's design enforces that reallocation of time. The tool makes better alignment possible; it doesn't make it inevitable. Teams could just as easily use ACE to ship mediocre features faster together.

The Broader Policy Context

ACE exists in a regulatory vacuum that won't last. The European Union's AI Act includes provisions around transparency and human oversight of AI systems. If coding agents qualify as high-risk AI systems under certain applications, requirements for human review and decision-making could formalize some of what ACE does informally.

Similarly, questions about liability for agent-generated code remain unsettled. If an agent introduces a security vulnerability that gets missed in review, who bears responsibility? The developer who prompted it? The team that approved the PR? The company that deployed the agent? Clear audit trails and collaborative oversight—things ACE provides—could become compliance requirements rather than productivity features.

Appleton frames the tool as addressing a development workflow problem. But it's also building infrastructure for a policy environment that doesn't exist yet. The granular records of who prompted what, who reviewed what, and who approved what might matter more for legal compliance than for team alignment.

What Gets Optimized

Appleton's closing argument is normative, not technical: "Our agentic tools should help us do higher quality work, get aligned faster, and build a few exceptional things rather than a thousand crappy ones."

Whether that's what actually happens depends on incentives ACE can't control. If markets reward velocity over quality, teams will optimize for velocity regardless of tooling. If organizational cultures prize individual heroics over collective craftsmanship, collaboration features won't change behavior.

The interesting question isn't whether ACE solves the technical problem of shared context and real-time collaboration. It appears to. The question is whether solving that technical problem addresses the underlying dynamic: that fast, cheap implementation changes what gets built and why, and most organizations haven't figured out how to govern that change yet.

ACE provides infrastructure for better alignment. It doesn't provide the alignment itself. That still requires humans to decide what matters and what doesn't—just faster than before.

Samira Okonkwo-Barnes covers technology policy and regulation for Buzzrag.