AI Coding Is Still Single-Player

This is a more specific seam than I usually like to write at, and a longer route through it than I would normally take.

My instinct is usually to stay one level up - closer to the strategic pattern, further from the local mechanics, and quicker to the broader frame. But every so often a concrete workflow reveals the larger shape of a problem more clearly than a higher-level argument can.

AI coding tools do that.

The more I look at them, the less they seem like a niche product category and the more they seem like a very clear instance of a broader failure. We are getting very good at strengthening individual loops of thinking and making. We are still strangely under-equipped for what happens when those loops need to become collective.

Software just makes the mismatch harder to ignore.

The work is already collaborative. Already interdependent. Already full of hidden judgment. Software development has never just been about producing output. It has always depended on what a team believes it is doing, what it thinks is true, what it has decided to value, what it is willing to make explicit, and what it is content to leave tacit.

The tools, though, mostly operate at the level of the individual.

From a distance, they look collaborative enough. Multiple developers use Cursor or similar tools on the same repository. Multiple agents can be pointed at the same codebase, the same tickets, the same architecture, the same problems. It all appears to be happening in one shared space.

But up close, most of it is still single-player.

Each developer sits in a private loop with their assistant. Each assistant accumulates a local model of the task, the likely path forward, the abstractions worth introducing, the defaults worth keeping, the shortcuts worth taking. Each person explores, accepts, rejects, revises, prompts, and steers. And almost all of that reasoning stays local until the end, when the code is pushed, the branch is opened, and the team tries to reconcile the results.

What gets merged is not just code.

It is private judgment, already hardened into code.

That is a different problem.

We tend to talk about AI coding tools as if they are collaborative because more than one person uses them. But shared infrastructure is not shared cognition. A shared repo is not a shared process of thought. A merge request is not collaboration just because it appears after several people have worked in parallel.

What we have built, mostly, are very good single-player tools for a fundamentally multiplayer activity.

The real problem is not parallel code

Parallel code has always existed. Branches have always diverged. Teams have always had to coordinate. None of that is new.

What is new is how much more of the meaningful work now happens inside private, accelerated loops between one human and one machine.

The assistant does not just help write code. It helps shape the thought that becomes code. It suggests naming, decomposition, interfaces, architecture, tests, abstractions, defaults. It does not merely speed up execution. It speeds up local coherence.

And local coherence has a dangerous quality.

From the inside, it feels a lot like team coherence.

If the assistant helps me arrive at a reasonable structure, that structure feels grounded. If it helps you arrive at a different reasonable structure, that one feels grounded too. Both paths can be coherent. Both can be defensible. Both can even be good. But they were produced in parallel, inside private contexts, with very little shared negotiation while the ideas were still fluid.

You can see the shape of the failure almost immediately.

One developer tells their assistant, “let’s keep this simple - no new abstraction.” Another, somewhere else in the same repo, asks for the cleanest reusable pattern and gets a new abstraction that looks perfectly sensible in isolation. Both are being reasonable. Both may even be improving the code. The contradiction only becomes visible when the work is already expensive.

So the deeper issue is not that multiple developers now produce code at the same time. The deeper issue is that multiple developers now produce judgment at the same time.

Judgment about what matters. Judgment about what should remain flexible and what should harden. Judgment about what is merely local and what is becoming a pattern. Judgment about which trade-offs matter most. Judgment about which complexity is justified. Judgment about what now deserves to count as a rule.

Some of that judgment used to leak into shared spaces earlier. Not perfectly. Not elegantly. But earlier. It showed up in rough conversations, design discussions, PR review, architecture meetings, and the half-articulated memory of a team.

Now much more of it happens inside local assistant sessions, and the social system often encounters it only after it has become artifact.

That means collaboration begins later than it should.

Shared code is not shared judgment.

Agents do not solve this. They inherit it.

It is tempting to think this is a temporary stage. Better agent frameworks, better retrieval, better memory, better orchestration, better context windows, better tool use - surely the collaboration problem will smooth itself out.

Some of that will help. It already does.

But agents inherit the same structural problem humans do. They can share tools and still not share a process of alignment. They can retrieve from the same store and still pursue incompatible interpretations of the task. They can be orchestrated and still behave like very well-managed private reasoners.

A multi-agent system is not automatically multiplayer any more than a room full of developers is automatically aligned.

The issue is not whether multiple actors exist. The issue is whether there is any shared substrate where project knowledge can become visible, contestable, ownable, and legitimate before it hardens into action.

Without that, humans drift. Agents drift. And teams end up reconciling outputs rather than forming judgment together.

So the missing layer is not merely better context. It is something closer to a shared social memory for the project - not memory as archive, but memory as live coordination.

That is what I mean by multiplayer.

Multiplayer is not just shared visibility

That would be too weak.

A lot of imagined collaboration layers for AI work are really just improved access. Better retrieval. Better note systems. Better shared context stores. Better ways for everyone to see the same material.

Useful, yes.

But not enough.

Multiplayer should mean something more demanding than shared access.

It should mean that important things discovered, inferred, stated, or negotiated in local work can become shared project knowledge in a governed way. Not dumped into one giant memory bucket. Not silently promoted into truth. Not trapped forever in private assistant sessions. But surfaced, shaped, and made available to the wider project while they are still early enough to matter.

That means the real shift is from private interaction to shared project knowledge.

Not all interaction. Not all knowledge. Not every passing thought.

Just the things that deserve to become social.

In the simplest terms, a multiplayer system would do four things.

It would let important local interactions become candidate shared knowledge instead of disappearing into private sessions. It would turn that knowledge into shared records the team could actually gather around. Those records would need an owner - not necessarily the person who first said the thing, but someone willing to stand behind it. And those records would move through stages, from idea to plan to implementation to rule, as humans and agents gave them enough legitimacy to shape real work.

That is the basic shape.

Everything else is really detail, governance, and interface.

It still starts locally

The first important point is that multiplayer does not abolish local work.

People still begin in their own flow. A developer still opens Cursor. Still asks the assistant to explore a refactor. Still rejects one approach and prefers another. Still explains why a pattern feels wrong. Still says, “let’s not introduce another abstraction here.” Still arrives at bits of reasoning while making the work.

That does not need to change.

The point is not to replace private thought with committee process. The point is to stop pretending that the only options are private thought or merged artifact.

There is a missing middle.

Inside local work, certain things begin to appear that are clearly more than just local execution:

• a durable rationale
• a design preference
• a concern that may affect others
• an implementation direction
• an emerging disagreement
• a likely future rule

Right now, most of those either vanish or show up too late in weaker forms. Maybe they surface indirectly in code. Maybe they get compressed into a commit message. Maybe they survive as a team vibe. Maybe they disappear entirely and come back later as “why did we do it this way again?”

A multiplayer system would give those moments somewhere to go.

Not all of them. Just the ones that deserve to become shared.

That is the first important change.

Local interaction stops being a dead end.

Local interaction is evidence. It is not canon.

This boundary matters enough to say bluntly.

If you turn every IDE session into project memory, you do not get collective intelligence. You get sludge.

Most interaction with an assistant is not durable knowledge. It is exploratory language. It is trying things out. It is local trial and error. It is partial thinking. It is the sort of material that only becomes useful because it is cheap to generate and cheap to discard.

So a multiplayer layer cannot simply ingest everything and call itself aligned.

It needs a membrane.

Something has to happen between private interaction and shared project knowledge.

That something is promotion.

A person or agent notices that a local piece of reasoning might matter beyond the current loop. Maybe it is worth sharing. Maybe it is worth turning into something others can see, assess, and act around.

That move should be active, not automatic.

The assistant might notice the moment and ask. The human might decide to surface it intentionally. But the principle stays the same:

IDE interaction is evidence. It is not automatically canon.

That distinction protects the system in two directions at once. It protects the project from treating raw local reasoning as if it were already legitimate shared reality. And it protects local thought from being prematurely institutionalised simply because it happened to be expressed near a machine.

It also creates a more honest gradient between private and shared. Not everything has to be either ephemeral chatter or official project truth. There can be a stage in between where something is simply being proposed as socially relevant.

A lot of software collaboration breaks not because there is too little information, but because there are too few credible states between “just a thought” and “already decided.”

Promotion is the first real multiplayer mechanic

This is where the system stops being a storage idea and starts becoming a coordination idea.

Something local gets noticed. It may be a pattern. It may be a warning. It may be a rationale that would save someone else an hour next week. It may be an implicit rule that is about to become real whether or not anyone names it.

At that point, the system needs a way of asking:

What should happen to this?

This is why the interaction matters.

The assistant does not need to interrupt constantly. In fact, if it does, the whole thing collapses into bureaucratic nagging. But when it spots something that may matter, it needs a simple way to invite socialisation.

Something like:

1. Keep as idea
2. Share as plan and claim ownership
3. Share as implementation candidate and claim ownership
4. Dismiss

That small move does a surprising amount of work.

It says:

• this may matter beyond you
• it is still your choice whether to surface it
• surfacing it is not the same as turning it into a rule
• if it is going to matter, it needs a clearer social status

Promotion, in other words, is not about storing more. It is about giving important local knowledge a path into collective life.

That is the first genuinely multiplayer mechanic in the whole picture.

Not because it solves everything. Because it creates a bridge between the private loop and the shared world.

Once promoted, it becomes a record

A multiplayer system needs a shared unit. Something the team can gather around before and beyond code.

Call it a record.

A record is not just a note. It is a piece of project knowledge that has crossed out of private interaction and into shared view.

That record might be:

• an idea
• a plan
• an implementation direction
• a rule
• a conflict
• an observation
• a rationale note

The exact taxonomy matters less than the role it plays.

The record becomes the object around which multiplayer happens.

Instead of collaboration beginning only once code exists, the team now has a shared object it can respond to earlier. The question is no longer only “what changed?” but also:

• what is this?
• where did it come from?
• who stands behind it?
• what part of the project does it touch?
• how legitimate is it?
• how far has it hardened?

That is already a meaningful shift. The project starts to reason together not only through diffs, but through the knowledge that shapes diffs.

The codebase stops being the only place where alignment becomes visible.

And the record matters because it gives the social process a place to attach. Teams are often better at reacting to artifacts than to abstractions. A record turns a half-implicit judgment into something visible enough to support, object to, refine, or ignore.

That is how multiplayer starts to feel real rather than aspirational.

Shared knowledge needs an owner

This is where the model stops being a memory system and starts becoming a governance system.

A record should not matter just because it exists. It should not become valuable shared knowledge merely because it was created, observed, or extracted.

If it is going to count, someone has to own it.

Not necessarily the person who first originated it. The origin should absolutely be preserved. That matters for lineage, audit, and plain honesty. But origin is not the same as stewardship.

Ownership means something stronger.

I am willing to stand behind this as shared project knowledge.

That sentence does more work than almost any other sentence in the model.

It means:

• I accept responsibility for this record
• my silence is meaningful
• my participation matters
• I can maintain, defend, revise, or retire it

Without ownership, a shared knowledge layer fills up with things that are vaguely important and nobody is actually responsible for. The organisation “knows” them in the way organisations often know things - diffusely, half-socially, with a lot of shrugging around the edges.

That is not good enough.

So the rule should be simple:

No valuable shared knowledge without an owner willing to claim it.

And ownership should be singular.

Many can participate. One must be accountable.

“Shared ownership” sounds humane, but in practice it often means responsibility has dissolved into atmosphere. If something matters, one person - or one agent, where project policy allows - should be the steward of that record.

That is not authoritarian. It is just how accountability becomes legible.

This also helps separate creation from commitment. A person might originate an idea. Another might notice its importance. A third might be the right person to own it. Those do not have to be the same actor. In fact, they often should not be.

That distinction is useful because it stops the system from confusing “who said it first?” with “who is prepared to stand behind it now?”

Legitimacy comes from the group, not just the owner

Ownership is necessary.

It is not enough.

If ownership alone made a record operational, the shared layer would just become a more formal way of asserting local confidence. That is not multiplayer. That is better-organised single-player.

So once a record has an owner, it enters a collective process.

Humans and agents can weigh in on the record itself.

That is another useful simplification. The vote attaches to the record. Not to some hidden abstraction above it. Not to an overengineered tangle of sub-objects. The record is the thing being judged.

Support. Object. Possibly abstain.

But the unit stays stable.

That matters because the real question is not “do people like this?” It is “is this record legitimate enough to shape the project?”

Those are very different questions.

A team does not need reaction emojis with governance attached. It needs a way of turning private or local judgment into something collectively credible.

That is where weighted voting becomes useful - but only if the weights mean something.

Not all votes should count the same

It is tempting to make a system feel fair by pretending all votes are interchangeable.

In practice, that usually makes it less truthful.

A security concern should not be decided the same way as a naming preference. A person who owns a domain should matter more within that domain than someone glancing from afar. A human should usually outweigh an agent on normative judgment. An agent may still carry meaningful weight on a narrow factual observation where it has direct evidence or operational proximity.

So the right principle is not “everyone gets the same vote.”

The right principle is this:

weight comes from role and proximity to ownership of the knowledge.

That is much better because it ties influence to responsibility.

Who is close to this record? Who bears the cost if it is wrong? Who owns the surrounding context? Who has standing to judge it?

This avoids both bad extremes:

• fake egalitarianism, where every signal is flattened into the same value
• rigid hierarchy, where legitimacy is smuggled in from titles alone

It produces something more useful: contextual authority.

A multiplayer system would not be democratic in the abstract. It would be responsibility-weighted.

Which is closer to how real projects work when they work well.

It also helps solve a subtler problem. Not all disagreement is the same kind of disagreement. Sometimes a vote is objecting to the truth of a record. Sometimes it is objecting to its timing. Sometimes it is objecting to the idea that this should guide implementation yet. Sometimes it is objecting because the owner is wrong for the context.

Keeping the vote attached to the record, while allowing rationale to vary underneath it, preserves clarity without pretending every objection means the same thing.

That is one of the places where the model becomes more human. It recognises that social legitimacy is not one scalar. It is a structured argument that still needs a visible object to gather around.

Records harden in stages

Not because every project is the same, but because most project knowledge hardens in recognisable stages whether we name them or not.

Not all records should become equally actionable at once.

Some things deserve to be seen. Fewer deserve to coordinate work. Fewer still deserve to guide implementation. And only some deserve to constrain future work as rules.

So records need a lifecycle.

The cleanest version I can see is:

Idea -> Plan -> Implementation -> Rule

An Idea is visible, but not yet actionable. It exists in shared view, but nobody should treat it as operative simply because it is there.

A Plan is stronger. It has enough support, enough stewardship, enough seriousness to coordinate around. It matters socially, even if it has not yet crossed the line into something implementation should rely on.

An Implementation record has crossed that line. It is legitimate enough that humans and agents can build against it. It has become operational project knowledge.

A Rule is stronger again. It is no longer just something the project can act on. It is something future work is expected to respect.

This matters because it lets the system distinguish between:

• what is merely visible
• what is worth coordinating around
• what is safe to act on
• what is now expected

That is not bureaucracy. It is a way of making consequence visible.

And it gives the whole model a useful design principle:

friction should increase with consequence.

Ideas should be cheap. Rules should not be.

This is where the system becomes more than note-taking. It starts to model the way project reality actually hardens. Not all social knowledge is equally mature. Not all agreement should have equal operational weight. Not every emerging preference should be allowed to steer agents or other humans immediately.

The lifecycle gives the system a way of saying: this is visible, this is serious, this is actionable, this is binding.

That is a genuinely useful distinction.

The grammar can be shared. The thresholds can be local.

The stages themselves can be universal. The thresholds between them do not need to be.

Different projects will want different tolerances. A high-risk system may want stronger legitimacy before something becomes implementation-significant. A looser experimental environment may allow faster movement. One project may let agent votes contribute heavily to certain kinds of records. Another may keep that weight narrow. An owner may be allowed to tune thresholds within bounded tolerances.

The exact policy matters less here than the broader shape.

The grammar stays stable:

• Idea
• Plan
• Implementation
• Rule

But the constitution can be local.

That makes the system flexible without becoming shapeless.

And it reflects a deeper truth. Teams do not only differ in what they build. They differ in how they decide. A multiplayer system should not erase that. It should make the decision-making substrate explicit enough that the team can recognise itself inside it.

The interface should fit inside the IDE

If this model only works in a separate platform, it will remain more thought experiment than workflow.

So the interaction needs to feel native to where people already work.

That does not require a giant bespoke control surface. In fact, the more this depends on special UI, the weaker it becomes. The core mechanics should degrade cleanly into patterns that work across common IDEs.

The split that seems most plausible is simple:

• numbered menus when the AI spots something that may need a response
• slash commands when the human wants to act intentionally

So the assistant might notice an emerging design preference and say:

1. Keep as idea
2. Share as plan and claim ownership
3. Share as implementation candidate and claim ownership
4. Dismiss

Or the human might proactively issue: `/share` `/claim` `/promote` `/support` `/object` `/status`

That matters because it grounds the whole model in a believable reality. Multiplayer does not need to mean abandoning current tooling. It means introducing a new coordination layer inside it.

And the split itself is elegant.

Numbered menus let the system initiate gently when it detects potential social relevance. Slash commands preserve human initiative. The assistant becomes a spotter. The human remains an operator.

That is the right balance. Too much AI initiative and the system becomes nagging workflow theatre. Too little and the shared layer remains inert, waiting for a kind of discipline most teams do not have time to manufacture on demand.

Agents become participants, not just accelerators

This is where the idea starts to become more than “better memory for coding assistants.”

In the single-player model, agents mostly serve individuals. They help one person move faster. Even in multi-agent configurations, they often behave like a cluster of private specialists rather than participants in a shared project logic.

In a multiplayer model, agents still assist individuals. But they also participate in the shared knowledge layer.

They can:

• suggest that something is worth promotion
• own certain classes of records where project policy allows
• support or object to records
• maintain observations
• align their actions to already legitimised project knowledge
• ask for confirmation when their interpretation sits on the border between observation and overreach

This is a subtle but important change.

The missing thing is not simply more capable agents. It is a shared layer in which agents stop improvising against private context alone and start operating inside a visible, governed field of project knowledge.

That is a very different role.

It makes agents less like private copilots and more like bounded participants in the life of the project.

It also solves something awkward in current agent narratives. We often imagine agents as if capability were the same thing as legitimacy. If an agent can infer something, perhaps it should act on it. If it can plan, perhaps it should decide. But in real collaborative work, ability is not enough. Something also needs standing.

Agents do not merely need more power. They need a place in a shared system of project judgment.

That is the role multiplayer gives them.

Conflict becomes visible sooner

One of the strongest practical arguments for all this is what it does to disagreement.

Today, disagreement usually shows up late:

• in code review
• in merge conflicts
• in architecture arguments after implementation has already happened
• in the slow discovery that the repository now contains multiple incompatible interpretations of the same thing

A multiplayer layer gives disagreement somewhere earlier to appear.

Not only in code, but in records.

Two people may not yet be editing the same file, but they may already be advancing incompatible plans. Two agents may not yet be colliding operationally, but they may already be supporting records that cannot comfortably coexist. A rule may be trying to harden while another record objects to it.

That is valuable because knowledge-level conflict is usually cheaper than artifact-level conflict.

The goal is not to eliminate disagreement. It is to surface disagreement before it hardens into code.

That one move - from merge-time conflict to knowledge-time conflict - may be one of the biggest reasons a multiplayer layer is worth building at all.

And it is also where the idea becomes less abstract. The benefit is not merely philosophical. It is practical. Teams spend an enormous amount of effort unwinding decisions that were effectively made in parallel but never socialised early enough to be corrected cheaply. Multiplayer does not eliminate that entirely.

But it gives the project an earlier warning surface.

That matters.

The codebase stops being the first place collaboration becomes visible

That is probably the deepest shift in the whole idea.

Right now, the codebase is still where a lot of alignment finally shows itself. Or fails to.

That is too late.

The team needs somewhere earlier to become visible to itself. Not as a dashboard of performative alignment. Not as another system of checkboxes. But as a shared field in which ideas, plans, implementation directions, and rules can become legible while they are still in motion.

That is what the multiplayer layer is really doing.

It is not replacing code. It is not replacing conversation. It is not replacing human judgment.

It is giving project judgment somewhere to exist before it becomes expensive.

Which is why the current generation of AI coding tools, for all their brilliance, now feels incomplete.

They have become excellent at strengthening the private loop. They are still weak at creating a shared substrate for how teams actually come to know what they are doing.

And that is the uncomfortable part.

Because software development was never really just about writing code together. It was about slowly making reality together - deciding what counts, what matters, what holds, what is provisional, what is local, what becomes shared.

AI has accelerated the local side of that faster than it has strengthened the shared side.

So we end up in a peculiar condition:

more generation more speed more local intelligence and, in some cases, a thinner collective process right where it matters most.

That is why “single-player versus multiplayer” feels like the right frame to me.

Not because the tools are bad. Because they are good enough now that the missing layer has become easier to see.

We have built very good single-player AI for a multiplayer job.

And sooner or later, the cost of that starts to show.

Game over, player one.