Scaling one developer with many agents does not solve the team problems of deciding what to build and why.
2
Agentic development needs shared planning, context, and decision-making before and during implementation.
3
ACE combines multiplayer chat, coding agents, shared cloud computers, collaborative plans, and proactive team summaries in one environment.
Summary
Maggie Appleton argues that agentic software development has focused too heavily on one developer running many coding agents. This makes implementation cheap, but it increases the cost of poor alignment. Teams can duplicate work, create conflicting changes, and discover too late that a feature was the wrong thing to build. Existing tools place most coordination after implementation, inside pull requests, while important context about users, business constraints, product direction, and team decisions remains outside the codebase. Appleton demos ACE, a GitHub Next research prototype. Each session combines a multiplayer conversation with a sandboxed micro VM and its own Git branch. Teammates and agents share prompts, previews, terminal output, plans, and edits. ACE also provides a dashboard that summarizes team activity and helps people resume unfinished work. Appleton's conclusion is that cheap implementation should create more time for research, design, and careful decisions, rather than a larger volume of mediocre software.
Agent fleets scale individual output while leaving team alignment unsolved
Appleton describes the familiar setup as "a wall of terminal-based coding agents" running in parallel on one person's machine. The promise is that one developer with a fleet of agents can do the work of an entire team. She argues that the model assumes software is made by one person, even though software is a team activity where people need to agree on what they are building and why. More individual output cannot fix communication and coordination problems. Once code is cheap and fast to produce, the harder question becomes whether the team should build it at all.
Cheap implementation moves the bottleneck to deciding what deserves to be built
Appleton says writing code is becoming faster, cheaper, and better, so implementation is increasingly a solved problem. The scarce resource is the team's choice of where to spend its effort. She calls opportunity cost the real cost when production is cheap, because choosing one feature means giving up another. Everyone on the team needs to ask whether the work solves the right problem, uses energy well, and can have the most impact. Agents increase the cost of poor alignment because they can turn an unexamined idea into working code within minutes.
Current workflows put alignment after implementation, where feedback costs more
Traditional development had planning, building, and review phases with conversations in Slack, Zoom, issues, and draft pull requests. The slower implementation window gave teammates time to see the work, offer advice, and correct direction. Agent-generated code collapses that window. A developer can go from an issue to an agent-created pull request in a couple of minutes, while the agent's local plan remains invisible to the rest of the team. Review then carries the weight of all the missing alignment, even though pull requests were not designed for that job. Late feedback can mean throwing away the implementation.
The context needed for good decisions lives in people and organizations
Appleton says planning and building now need to form a cycle rather than two separate phases. A shared environment must include planning, context gathering, decisions, and development. Much of the context behind a good product decision is absent from the codebase. It includes business and financial constraints, political dynamics, product vision, user research, and the organization's history. Agents cannot discover those things on their own. The tool must give humans a natural way to share them early, without adding a heavy process.
ACE gives each collaborative work session a shared conversation and isolated cloud computer
ACE, or Agent Collaboration Environment, combines a multiplayer chat with a sandboxed micro VM and its own Git branch. Teammates can talk about work in a session while coding agents participate in the same conversation. Changes remain isolated, so people can work on parallel tasks and switch between sessions without managing local worktrees or stashing changes. Anyone in the session can run terminal commands, see the same preview, and inspect the prompting history that produced the current output. Appleton presents it as an environment that combines familiar collaboration and development features.
Shared sessions let non-developers participate in agent-assisted software work
In the demo, Maggie and her teammates ask the same agent to make changes, including adding a teal theme. The agent can read the entire conversation, so the team can discuss decisions first and then tell it to act. Appleton says this makes coding-agent access available to designers, product managers, and customer support staff as well as developers. The session includes diffs, terminal commands, previews, and a route to create a pull request in GitHub. People outside ACE can still use the pull request, which links back to the session for context.
Collaborative plans let teams change the work before the agent builds it
For a larger feature, the team asks ACE to write a plan for adding variable time frames to the demo app. Everyone can open the plan, see other teammates' cursors, edit it, and suggest changes. Nate proposes a drop-down instead of a segmented control, and Edon updates the requirements so the agent has the revised context. Once the team agrees on the details, someone tells ACE to proceed from the chat. The plan is therefore a shared object that the team can inspect and revise before implementation begins.
Proactive summaries help teams keep up with fast-moving agent work
ACE's dashboard summarizes active sessions, unfinished work, recent pull requests, issues, and what teammates have been doing. Appleton says people may ship five features a day instead of half of one, which makes it difficult to know what coworkers are changing. The dashboard is an early attempt to make agents proactive and provide social context. If agents can access conversations around code, they may help orient someone each morning, notify them about decisions, or bring them into a discussion when a teammate is about to extend a feature they originally built.
"We have an opportunity to not just go faster and build a giant pile of the same crappy software, but instead to make much better software through much more rigorous critical thinking and better alignment in the planning stage."15:11
Who should watch
You are running multiple coding agents on a team and are starting to see duplicate work, merge conflicts, or pull requests nobody understands.
Your product decisions depend on context from designers, product managers, support staff, or business stakeholders that never reaches the coding agent.
You want to explore collaborative agent workflows where planning and implementation happen in the same shared workspace.
