One Developer, Two Dozen Agents, Zero Alignment: Why we Need Collaborative AI Engineering

What does peak developer productivity look like when one person can run a fleet of coding agents? Maggie Appleton approaches that question as a designer and staff research engineer at GitHub Next, the experimental research team within GitHub. Her opening example is a wall of terminal agents running in parallel on one machine: one developer with two dozen Claudes, apparently doing the implementation work of an entire team.

These interfaces scale an individual’s output. They do not establish agreement among the people responsible for the product. Software development requires communication about what to build and why; adding more parallel production cannot resolve that dependency. Appleton invokes the familiar fallacy of nine women producing a baby in one month: some constraints do not yield to more workers. More output can instead amplify the cost of unresolved decisions.

Appleton describes implementation as rapidly becoming a solved problem: code is getting faster and cheaper to produce, with improving quality. That is the premise of her argument, rather than a claim that every engineering problem has disappeared. As implementation becomes easier, the difficult question shifts from how to build something to whether it should be built. Agreement about the right work becomes the bottleneck.

Choosing a feature still commits the team’s attention to that feature instead of everything else it might do. When production is cheap, opportunity cost becomes more consequential: are we spending effort where it will have the most impact? Alignment has always constrained teams. Agents increase the amount of work a team can produce before discovering that it was heading in the wrong direction.

The coordination tools receiving this growing volume of agent output—GitHub, Slack, Jira, and Linear—were built around an older development rhythm. Appleton reports that people inside GitHub are also exploring what comes after issues and pull requests; the existing artifacts are not assumed to be the final form of software collaboration.

In the slower planning–building–review sequence, implementation created time for alignment. Slack conversations, meetings, issue comments, and draft PRs let teammates contribute expertise, catch mistakes, and redirect work while it was still taking shape. By the time a change reached review and merge, the team had usually seen it develop.

Agent implementation compresses that interval. Because building feels inexpensive, teams may also skip planning. Appleton says generated code takes longer to review, placing more coordination after implementation. She describes the interval from logging an issue to an agent opening a PR as a couple of minutes. These are observations motivating the design, not controlled benchmark results.

Local plan modes remove another opportunity for intervention: an agent can produce a plan that no teammate sees, and its operator may barely read it before proceeding.

The pull request inherits the burden of explaining intent, supplying context, and negotiating scope after the code already exists. Appleton’s missing primitive is a shared place to discuss plans, gather context, and work with agents together.

The consequences fall into two related categories:

• Wasted work: features nobody asked for, changes that do not solve real problems, or completed implementations discarded after critical feedback arrives.
• Coordination debt: cleanup from agents changing the same files, difficult merge conflicts, and developers independently completing the same task.

The work may be locally successful while creating costs elsewhere in the team.

Large queues of PRs compound the problem when reviewers have no context for what they contain. The proposed response is to align before agents start and keep aligning during implementation. Planning and building become a cycle, with context gathering and decision-making in the same environment as development.

Much of the information needed for that cycle is outside the repository:

• Business constraints: available money and the commercial reasons for doing the work.
• Decision authority: who is responsible, who can approve a direction, and the organization’s political dynamics.
• Product understanding: leadership’s vision and designers’ findings from user research.
• Organizational history: what the team has already built and learned.

Code alone cannot tell an agent these things. People need a natural way to contribute them early, without turning every interaction into another layer of process.

Ace, the Agent Collaboration Environment, is GitHub Next’s research prototype for this workflow. At the time of the recording, it was unfinished and approaching a technical preview, with user testing planned to explore how teams would collaborate in it. The demonstration shows that prototype, not a production-release announcement.

Its interface uses familiar patterns: a session list on the left and a multiplayer chat containing both teammates and coding agents. But each session is also backed by a microVM, a sandboxed cloud computer with its own Git branch. Separate sessions isolate changes for parallel tasks; participants within a session share the working environment.

That changes the cost of asking a colleague for help. They can enter the session and inspect the work without stashing local changes, pulling another branch, or managing worktrees. They also see the complete prompting history, which explains how the current output came to exist. The shared artifact includes both the implementation and the conversation that produced it.

A session supports ordinary terminal commands. Appleton installs dependencies and starts the development server:

bun install
bun dev

Opening the port exposes the running project in a browser preview beside the conversation. The demo application is a calmer version of Hacker News, showing top stories from the last three months rather than demanding daily attention.

She asks the agent to change the theme to purple. The preview updates because the environment is running the changed code. The agent also creates a commit with a message, and the resulting diffs remain available for inspection. These familiar coding-agent capabilities establish the working loop before the collaboration features come into play.

Next, with teammates present, she requests additional color themes and selects Opus 4.6. A summary block in the upper-right corner tracks recent changes from any participant. Its purpose is orientation: someone switching among concurrent sessions can recover what has happened without reading every message and action.

Teammates can inspect the proposed changes in the same environment. They can start the development server, view the same preview, run terminal commands, and see shared outputs. Discussion is attached to a common running system rather than to separate local reproductions of it.

The collaborators contribute screenshots, questions, and alternative feature ideas. Nate then asks Ace to add a teal theme. Appleton initiated the session, but Nate can prompt its agent directly. The agent receives the whole conversation as input, so the team can discuss a change first and then invoke @Ace to act on that shared context.

A familiar chat interface also gives designers, product managers, and customer support staff a way to participate while a feature is being built. Appleton’s reason for building a dedicated environment rather than simply using Slack is the need for software-development primitives: terminals, diffs, and the working project itself. In her view, those are outside Slack’s core business. Ace tries to make those capabilities accessible without requiring everyone to collaborate through a terminal.

Once the team likes the theme changes, it creates a pull request directly inside Ace, inspects the PR preview, and follows the link to GitHub. The PR description includes a link back to the Ace session. This preserves a route to the conversation behind the change while allowing only part of a team to adopt Ace; colleagues can continue using their existing tools.

Direct editing remains available. Appleton, whose front-end work often requires correcting an agent’s CSS, opens the project in VS Code. The shared cloud computer supports real-time multiplayer editing. Closing her laptop does not end the session: teammates can keep editing and prompting the agent.

A mobile interface was still under development. The architectural advantage was already clear, however: future phone access could connect to the cloud session without tunneling into a personal computer. Keeping the work available would not require leaving a laptop running or buying a dedicated local machine.

For a more complex change, the team discusses adding variable timeframes to the calm Hacker News app. Appleton asks Ace to draft a plan, then opens it as a shared document. Teammate cursors are visible, and everyone can edit the plan and assess whether it achieves the intended result.

Nate suggests a dropdown instead of a segmented control. Another teammate updates the requirements so the agent will receive that decision. Only after the team is satisfied does Appleton return to chat and ask @Ace to implement it. The demonstrated sequence is a draft, a collaborative requirements change, and an implementation request; it does not show a completed timeframe feature. The important intervention happens while the interface choice is still part of a plan.

Moving planning and discussion into sessions gives Ace more context to summarize. The dashboard demonstration starts with a Monday-morning problem: remembering unfinished work from Friday. Ace surfaces React hooks from an ongoing refactor. From there, Appleton can start a new session or use Pick back up to reopen the session associated with an unmerged PR. Recently completed PRs and issues provide a record of finished work.

Team pulse summarizes coworkers’ activity: Nate has been shipping a lobby channel, while David has been fixing access-token issues. A raw feed of repository issues and PRs remains available alongside the summaries. Appleton illustrates the growing volume of work with coworkers shipping five features a day instead of half of one. This is an illustration of the coordination problem, not a measured productivity result for Ace; the dashboard is a first attempt at proactively supplying the missing social context.

The proposed next step is to use conversations around code as a social information fabric. Agents could surface relevant decisions or invite the original author of a feature into a discussion about extending it. Those are possibilities beyond the demonstrated summaries. They depend on the same foundation: a shared workspace where agents can see how people’s decisions relate to the code, rather than disconnected terminal sessions on individual machines.

The larger opportunity is to reclaim time. Implementation has historically consumed effort that teams wanted to spend on user research, design details, and architectural choices. People shipped work they were not proud of because they lacked the time to explore those questions properly. Coding agents can return some of that time.

Those savings can fund deeper exploration, more research, and more rigorous thinking together before and during implementation. Faster production only improves the product if the team uses its expanded capacity well. Appleton argues that, as software becomes cheaper to produce, quality and craftsmanship become stronger differentiators.

Craft still costs time and energy. Buying that time requires agreement about doing fewer things better. Easy prompting creates its own distractions: unnecessary features are cheap to request, and a team can quickly build the wrong thing. The desired environment helps people reason together about hard problems, get aligned sooner, and put their effort into a few exceptional things.

At the close of the recording, Appleton expected Ace early access within a couple of months at the latest. The displayed QR code led to a signup form requesting a GitHub username for access when available. She pointed viewers to GitHub Next’s research and her own site, with slides and notes expected shortly afterward. Her companion page for this talk provides the accompanying material.