One Developer, Two Dozen Agents, Zero Alignment

Justy This is Exploring Next, episode 312. If code is getting cheap fast, the expensive mistake is building the wrong thing together.

Cody My skeptical read, Justy, is that this nails a real pain and still might be too optimistic about behavior change. The article is basically saying solo coding agents scale output, not agreement. I think that's true. But turning collaboration into yet another live workspace can also create more noise, not less.

Justy I buy the problem statement though. Real teams are already dealing with this. Somebody prompts an agent, a PR shows up in minutes, and everyone else is reacting at the end when the shape is already baked in.

Cody Yeah. Ace's concrete claim is interesting: a session is shared chat plus a cloud microVM on its own git branch, with terminal access, preview, agent history, diffs, and commits. That's a better primitive than stuffing coordination into issues and PRs.

Justy Also more honest about how software actually gets made. Product, design, support, engineering, all that context lives outside the repo. If the agent only sees code, it can move fast in a bad direction.

Cody Where I push back is whether teams want shared prompting history and shared machines all the time. In practice, people do private exploration before they want an audience, and shared sessions need norms fast or they become multiplayer oversteer.

Justy Maybe, but the early user is probably a small product team already deep in Copilot or Claude workflows, where merge conflicts and duplicated agent work are becoming normal. For them, seeing the same preview and terminal could remove friction.

Cody That's fair. The architecture solves a few ugly things elegantly: no local worktree wrangling, no "works on my machine," and the session summary helps with orientation in parallel agent work.

Justy The adoption barrier is obvious though. Teams already have Slack, GitHub, Linear, whatever else. Ace is asking them to move the center of gravity, not just add a plugin.

Cody And there are trade-offs. A microVM per session gives isolation, but also cost, permissions, secrets, and artifact sprawl. The hard part isn't one shared sandbox feeling magical. It's making dozens governable.

Justy [chuckles] Product reality, right there. If I'm a manager buying this story, I need to know whether it reduces review load or just relocates it upstream into more chat.

Cody Exactly. I do like the article's core critique of the current stack. PRs and issues were built for a slower loop. If an agent can go from prompt to branch in a few minutes, review at the very end is too late for alignment.

Justy So my verdict is this is a strong prototype for teams that already feel coordination debt from agents. Not broad product-market fit yet, but very believable as a next-step workspace.

Cody Mine is slightly harsher. Strong idea, unproven habit. The session primitive is better than the current patchwork, but I don't yet know if people want to think in shared agent rooms instead of repos, chats, and tickets. [laughs] That's a big retraining ask.

Justy Build Next, I'd try a weekend version of this as a solo builder with a friend. Spin up a GitHub Codespace or any cloud dev box, keep one branch per task, log every agent prompt in a shared markdown file, and review the transcript before opening a PR.

Cody Or wire up OpenCode or Aider with a simple session folder: transcript.txt, decisions.md, preview link, and a tiny script that runs git checkout -b session-name plus bun install and bun dev. Then test one thing. Do you catch bad directions earlier when the prompt history is shared?

Justy That's the episode. We're in my kitchen, Cody's running on travel coffee, and we'll see you next time on Exploring Next.