Your AI Pair Programmer Is Playing Single-Player

written by Stefan Christoph

- 8 minutes read
TL;DR: I run what looks like a small team of agents — a backlog of delegated tasks, subagents for research and drafting, a whole operating model for handing work to machines. It feels collaborative. Maggie Appleton’s argument made me realize it isn’t: nearly every AI coding tool today, including my elaborate setup, is still fundamentally single-player. One human, their context, their agents, their session. Software is a team sport, and we’ve built AI assistance as if it were solitaire. My thesis: that gap, not model quality alone, is the next real frontier.

The uncomfortable realization

I’ve spent a good chunk of the last year building what I’d have called a “team” of agents. There’s a delegation backlog. There are subagents that go off and research or draft while I do something else. I’ve written about managing agents like you’d manage a team [2]: assigning work, reviewing output, keeping judgment in the loop.

Then I watched Maggie Appleton, a researcher and designer working on collaborative developer tools, make a single observation [1] that reframed the whole thing: nearly every mainstream AI coding tool is a single-player interface. And on the tools I actually use, she’s right. My “team” of agents is still one human (me) orchestrating a private fleet, in my session, against my context, on my machine. The moment a second human enters, they can’t inherit the private conversational and execution state my session built up. My agents don’t know what my colleague’s agents tried. Our assistants share no common model of the work: the task history, the approaches already ruled out, the decisions and open questions. Repositories, specs, and pull requests carry some of that; the live agent state carries none of it. We’re two people playing solitaire next to each other and calling it collaboration.

Software was always a team sport

This is the part the tooling forgot. Most production software in an organization isn’t produced by a lone genius and their copilot (plenty of solo software exists; that’s just not the case this is about). It’s produced by teams who share context that mostly lives outside the code: why a weird workaround exists, what the customer actually meant, which past decision this constraint traces back to, who to ask about the payments module. The code is the deliverable; that shared context is the asset that lets the team keep producing it.

Today’s AI coding tools are exceptional at helping one developer move faster through their slice. They mostly can’t see the team layer:

  • My agent has my chat history, my open files, my prompts. It has none of yours.
  • When you and I touch the same system a week apart, our assistants don’t hand off. Each starts cold.
  • The “why” (the tribal knowledge a senior engineer carries) is exactly what the single-player tool can’t see, because it was never one person’s to give.

We optimized the individual and left the team layer to Slack threads and tribal memory, same as before. One explanation for why measured task-level speedups often stay modest rather than transformational [3]: making each solitaire player faster doesn’t remove the team’s coordination bottlenecks.

What multiplayer would actually mean

“Collaborative AI engineering,” in Appleton’s framing, isn’t a shared chat window bolted onto an IDE. It’s assistance that operates on a shared model of the work, not a private per-user one:

  • Shared context, not shared screen. The agents reason over a team-level understanding of the codebase and its history (decisions, constraints, the “why”) that persists across people and sessions.
  • Handoff as a first-class action. When I finish a task and you pick it up, the context comes with it: what my agent already tried, what it ruled out, what’s still open. Today that handoff is a paragraph I type into a PR description, if I’m disciplined.
  • The team’s judgment in the loop, not just mine. Review stops being one human checking one human’s agent, and becomes a shared surface where the team’s collective judgment shapes what the agents do.

None of that is a bigger model. It’s a different unit of account: the team, not the individual.

AWS’s answer: a process, and a tool to run it

The single-player problem is really two problems wearing one coat: a process problem (how does a team collaborate around AI at all?) and a tooling problem (what do they build in?). AWS has a candidate answer to each — and it’s worth being precise about what they are, and what they aren’t.

The process answer is AI-DLC, the AI-Driven Development Life Cycle, a methodology from a fellow AWS Solutions Architect that reframes AI as “a central collaborator and teammate,” not an autocomplete.[4] It runs on two dimensions: AI-powered execution with human oversight (the AI plans, asks clarifying questions, and defers the critical calls to people) and Dynamic Team Collaboration (“teams unite in collaborative spaces for real-time problem solving”). Its rituals are unapologetically multiplayer: Mob Elaboration and Mob Construction, where the whole team validates the AI’s plan together, across phases (Inception → Construction → Operations) that persist context back to the repo. Sprints become “bolts”; epics become “units of work.” That is a real answer to “software is a team sport,” at the level of process. (It’s an AWS-authored methodology, not an official Amazon mandate. Treat it as a strong proposal, not canon.)

One tool to run it on is Kiro. Its shift from “AI coding” to agentic engineering makes the spec the unit of work — requirements → design → tasks, versioned in the repo — and pushes the team’s knowledge into steering files that, in Kiro’s own words, “scale tribal knowledge across the organization."[5][6] That is the “the why lives outside the code” problem, answered by turning the why into a shared, versioned artifact. For the repository-centered parts of AI-DLC, Kiro is a natural way to implement them on AWS.[7]

So the shape is clean, even though neither is an official mandate: AI-DLC is the process, Kiro is the tool. The methodology tells a team how to structure collaboration around AI; the IDE gives them shared, versioned specs and steering to anchor it. One boundary to keep honest: those are shared artifacts, durable files in the repo, not the live, synchronized agent state from earlier in this post. Kiro shares the specs and the steering; it does not, by itself, share one developer’s running session, what their agent already tried, or its in-flight state.

And here’s the honest part, straight from AWS’s own materials: the collaborative-AI-DLC methodology page describes its own local-file implementation as “single-user by default” (local files “don’t support simultaneous editing”) and notes session-to-session context loss (“each AI session starts with a blank context window; teams re-explain architecture decisions at every iteration”).[5] The methodology imagines the mob; that file-based implementation is still catching up to it. The gap in one line: the process answer is further along than the file-based tooling that would make it effortless.

Why this is the honest frontier

It would be easy to read this as “so we’re not there yet, wait for the next release.” I don’t think it’s a release. It’s not mainly a model-quality problem; it’s a coordination problem. Stronger models can help — summarizing, reconciling two agents’ views, flagging conflicts — but the ownership, synchronization, and provenance of shared context won’t be solved by more parameters alone. The reason so many tools are single-player isn’t that vendors haven’t noticed teams exist. It’s that single-player is tractable and multiplayer is genuinely hard: whose context wins, how you merge two agents’ understanding, how you keep a shared model current without it becoming a stale wiki nobody trusts.

That’s also why it’s the interesting frontier rather than a footnote. My thesis: the individual-level gains are mostly harvested, while the team-layer gains are still largely unclaimed. And that’s where the “team sport” actually happens.

I’ll say the quiet part: my own agent operating model is a sophisticated version of the same mistake. It’s a very good single-player rig. Making it multiplayer (so the next person on my team inherits what my agents know instead of starting cold) is a problem I haven’t solved, and I’m not sure anyone has.

So I’ll put the question to you: on your team, where does the shared context actually live today, and what would it take for your AI tools to read from that instead of from one developer’s private session?

Sources

Stefan Christoph

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

🎬 Also available as a blog walkthrough video on YouTube

❤️ Created with the support of AI (Kiro)

📝 Last updated: August 17, 2026 — Editorial polish for readability and voice