The Future of Software Factories Is Multiplayer

In January 2025, I had an idea I was convinced someone would eventually build.

I called it Wallie: an issue tracker with coding agents as the workers.

A team would begin with a project brief. Planning would turn that brief into a set of issues. The issues would form a dependency graph. Once the team approved the plan, the system would identify the work that was ready, assign it to coding agents, and move through the graph one issue at a time.

The agents would implement features, run tests, open pull requests, respond to review feedback, and update the project as they went. The team could open one place and watch the software come into existence.

At the time, I thought the product was an issue tracker with agents attached.

Eighteen months later, I think that was the wrong abstraction.

The issue tracker already existed. What was missing was a system that could turn shared intent into continuous, governed execution.

The deeper problem was making software development multiplayer in a world where code itself was becoming cheap.

The idea was right too early

Although I wanted to, I did not end up turning Wallie into a startup in early 2025.

Part of the reason was strategic. Linear seemed like the natural company to build something like it, and there's no other team with greater taste in my opinion. Why recreate the entire project-management layer when they already owned the place where software teams planned and tracked their work?

But the more important reason was technical: the coding agents were not ready.

The models available at the time (Sonnet 3.5) could do impressive things. They could build a demo, implement a contained feature, or produce a surprisingly good first pass at a pull request.

What they could not reliably do was stay coherent across the life of a real project.

The first few changes often felt magical. Somewhere around the tenth pull request, reality returned. Long-term context degraded, abstractions drifted, and a fix in one part of the product quietly broke another. The agent would solve the local problem while slowly making the global system worse.

You could use the tools, but you had to supervise them closely. Claude Code had just launched, but required multiple turns to get a pull request ready. The interaction still resembled pair programming with a fast but a very junior collaborator.

The control plane I wanted was clear; the coding agents could not yet run it dependably.

Looking back, I feel better in acknowledging that the idea was architecturally right and temporally wrong.

Starting that May, I moved on to other things. But Wallie became one of those ideas that never really leaves. I kept experimenting with pieces of it at my day job and on nights and weekends on my personal projects. For most of 2025, every new model release produced the same answer: “not quite.” By the end of the year, I was getting different results.

When the demos became projects

Claude Opus 4.5, released on November 24, was the inflection point for me. OpenAI followed with GPT-5.2-Codex on December 18. Both releases emphasized longer-running, more reliable agentic coding work.

For the first time, I could ask an agent to take a meaningful feature from a plan to a pull request and have a reasonable expectation that it would preserve context, use the repository correctly, run the relevant tests, recover from failures, and finish the job.

A project could make it past the fifteenth change without falling apart.

During the holiday break and into early 2026, I started building side projects almost compulsively. Some were useful, while others existed only because I was curious. They survived beyond the prototype.

“Vibe coding” had previously felt like a way to explore an idea. Now it was becoming a way to produce actual software. We were at the dawn of "agentic engineering".

The agents still needed supervision, though the nature of that supervision had changed.

I was writing less code. I was spending more time deciding what should exist, breaking it into coherent pieces, sequencing those pieces, inspecting the results, and redirecting the project when the implementation exposed something I had misunderstood.

Attention had become the scarce resource.

Decades ago, Fred Brooks distinguished between the accidental difficulty of expressing software and the essential difficulty of specifying, designing, and validating the conceptual system itself. His argument was that syntax and representation were not the hardest parts of building software; the hard parts were deciding precisely what the system should do and maintaining its conceptual integrity as it grew.

Coding agents now handle much of the accidental work. Increasingly, they can help with the essential work too.

As implementation becomes cheaper, the essential questions become more visible:

What are we actually trying to build?

Which decisions can be made locally, and which affect the entire system?

How do we know that the result is correct?

Who has the judgment to make a particular tradeoff?

How do several people and several agents change the same product without destroying its coherence?

The bottleneck did not disappear. It just moved up the stack.

The issue tracker is the control plane

In the spring of 2026, I came across OpenAI’s Symphony and had the peculiar experience of recognizing the system I had wanted to build.

Symphony is intentionally small. It continuously reads work from an issue tracker (Linear in its initial specification), creates an isolated workspace for each eligible issue, and runs a coding-agent session inside that workspace. The team’s execution policy lives in a versioned WORKFLOW.md, while the orchestrator handles dispatch, concurrency, retries, reconciliation, and observability.

Symphony’s key design choice was reusing the issue tracker.

Linear already represented the issues, comments, blockers, statuses, and dependencies.

Symphony treated the issue tracker as the system of record and added an execution layer underneath it.

The project-management system became a control plane.

The "software factory" became an issue processor.

That distinction connected the dots for me.

I had originally imagined that I needed to build a new Linear for agents. Symphony suggested that the more useful move was to build around the Linear that teams already used.

I built my own local version and connected it to seven or eight side projects. The experience was different from opening a coding tool and starting another private session. The project in Linear became the durable object. Agent sessions became disposable.

Agent sessions could start, fail, restart, or disappear. The state of the work remained visible in the issue graph.

I could step away and return later. Instead of mentally reconstructing what several tmux windows had been doing, I could look at the Linear project and see what was complete, what was under review, what was blocked, and what had become ready.

I eventually brought aspects of this into my work at Coinbase. Over the last few months, I have used it to build products while devoting only part of my attention to them. My contribution shifted toward product direction, decomposition, review, and course correction, with zero direct coding.

This experience has given me a conviction that it's time for teams to organize software development differently.

Parallel is not multiplayer

Symphony solved an important problem, but it also exposed the next one.

Most coding-agent experiences are still organized around one person handing one task to one agent session.

The agent might run locally or in the cloud. One user might operate several agents in parallel.

But several agents working for one person is still not multiplayer.

It is parallel single-player.

The user remains the center of the system, carrying context and credentials between sessions until every decision and review obligation eventually returns to them.

Real software development has never worked that way.

Software is a team sport. Product managers, designers, engineers, security specialists, data scientists, legal teams, and domain experts all contribute different forms of judgment. The product is shaped through proposals, disagreements, reviews, experiments, quality gates, customer feedback, and tradeoffs.

Current agent tools usually enter after much of that work has happened. Someone has already decided what should be built, compressed the context into a task, and handed it to the machine.

The agent is treated as a last-mile implementation worker.

But when implementation becomes cheap, everything upstream of implementation becomes the system.

Much of the current debate asks whether AI will replace software engineers or turn each engineer into a “100x engineer.” Both framings preserve the individual as the fundamental unit of software development.

I think the more interesting question is:

What would a 100x software team look like?

AI makes functional boundaries more permeable. A product manager can create a working prototype. An engineer can explore product strategy. A designer can inspect and modify the implementation directly.

Crossing those boundaries does not make expertise interchangeable.

Some people still have exceptional product judgment. Others can see architectural failure modes before anyone else. Some understand reliability, security, design, or a particular customer domain at a depth the rest of the team does not.

Rigid handoffs should fade, while teams still need a way to identify whose judgment matters for a decision.

Specialization remains as a system of judgment rights: clarity about whose approval a decision needs.

Anyone might draft the product definition or propose an architecture. The team can still require product approval before large-scale execution or security approval for a sensitive trust boundary. A high-risk deployment may require an experienced operator to approve the rollout plan.

As the work becomes more fluid, accountability needs to stay explicit.

What a multiplayer software factory looks like

A multiplayer software factory begins with the team and its shared project.

The issue becomes a durable coordination object

An issue should carry the intent, context, dependencies, decisions, evidence, discussion, and current state of a unit of work. Humans and agents should operate on the same object.

A dependency should act as an executable constraint. When the prerequisite becomes valid, the next piece of work becomes eligible for execution.

A status transition should represent a contract. It might certify that product direction is approved or that an implementation meets its acceptance criteria. Other transitions can record a passed security analysis, request human judgment, or confirm that a rollout has produced enough evidence to continue.

Automation should operate at the transition between trusted states, a level above individual lines of code or pull requests.

Workflows become programmable

Different teams (and different projects within the same team) need different workflows.

A small internal tool might move from definition to implementation to deployment with almost no manual approval.

A change to authentication or a critical financial system might require explicit product, architecture, security, reliability, and rollout gates.

A user-interface experiment might emphasize design review and measured customer behavior rather than a long architectural process.

The workflow should be a programmable state machine. It should define the possible stages, what evidence each stage requires, who or what may approve a transition, and what happens when validation fails.

Programmable workflows still need loops. An implementation can return to planning. An experiment can invalidate the original product definition. A review can create new issues and change the dependency graph.

Symphony’s WORKFLOW.md is an important step in this direction. It turns the previously implicit sequence of claiming an issue, implementing it, validating it, attaching evidence, and moving it to review into a versioned contract that agents can follow.

The multiplayer extension is to add organizational semantics: who may propose, who must approve, which evidence is required, which policies apply, and when an exception is allowed.

Execution moves into a shared environment

A local Symphony worker is useful for an individual. A team needs an execution environment that is shared, persistent, and governed.

Each issue can run inside an ephemeral sandbox containing the correct repository, build tools, dependencies, and test environment. It can receive narrowly scoped access to the services, browser sessions, tool connectors, and credentials required for that task.

The system should know which agents are running, what they can access, what they have changed, how much they have spent, and why they are blocked. A teammate should be able to inspect a run, pause it, redirect it, or reassign the work without taking possession of someone else’s laptop.

The cloud version of Symphony provides the worker. Multiplayer also requires shared identity, visibility, policy, and history.

Evidence becomes the output

A pull request alone is insufficient proof that a task is complete.

A finished unit of work might include test results, screenshots, evaluation scores, migration checks, and a walkthrough of the resulting behavior.

The appropriate evidence depends on the risk and purpose of the change.

Machines can handle much of the deterministic validation. Agents can review routine implementation details and iterate on one another’s feedback. Humans can focus on places where judgment, taste, accountability, or irreversible risk matters.

Reviewing every generated line will not scale. Eliminating review entirely would ignore decisions that depend on human judgment or accountability.

The goal is to move human attention to the layer where it has the most leverage.

The system schedules human attention

Today, people spend a surprising amount of time polling work: checking whether an agent finished, reconstructing a failed session, looking for a blocked pull request, asking who needs to review something, or discovering that two tasks have been waiting on each other for a day.

A software factory should route attention as deliberately as it routes computation.

When an agent encounters an ambiguous product decision, the issue should go to someone with the relevant product context.

A change that crosses a security boundary should request security judgment.

When an agent repeatedly fails, the system should surface the missing capability rather than silently burning more tokens.

A low-risk change that has passed all of its automated checks should continue without waiting for a person whose judgment is unnecessary.

Human attention is the resource the factory should optimize. Pull-request volume, lines of code, and agent concurrency are secondary measures.

A factory can produce garbage faster

The phrase “software factory” has always been loaded.

The industrial dream is not new. In 1968, M. D. McIlroy argued for mass-produced software components: reusable families of software that could be assembled rather than repeatedly built from scratch.

Later versions of the factory metaphor emphasized standard processes, reusable assets, predictable quality, and economies of scale.

Software teams often do not know precisely what they are building when they begin. Building the product is part of discovering what it should be, so a modern software factory needs more than an assembly line with agents placed where programmers used to sit.

A factory will optimize whatever it is asked to measure.

Set the target to pull requests or closed tickets and it will produce those outputs. Give it the wrong specification and it will implement the wrong thing more quickly and at much greater scale.

Cheap code can create review debt, architectural entropy, operational risk, and a larger attack surface. Faster execution magnifies good judgment, but it also magnifies bad judgment.

The factory must therefore optimize for validated outcomes and learning. Emitted code is only an intermediate measure.

That requires making the development environment legible to agents and encoding the boundaries that keep high-throughput execution coherent. OpenAI’s own agent-first engineering experiment found that repositories needed structured knowledge, explicit architectural rules, mechanical enforcement, and feedback loops early, before the product became large.

Earlier factory ideas attempted to make human implementation predictable. The modern version should make coordination and feedback reliable while allowing implementation to be abundant. The better metaphor is a control system.

What happens to the engineer?

When people hear that I, as an engineering manager leading a sizable team, am building products while doing little of the direct coding, they often jump to a conclusion about the disappearance of software engineers.

My experience points to engineering work expanding upward and outward.

Someone still has to design the environment in which agents operate: define interfaces, make the repository understandable, encode architectural constraints, build evaluations, decide what correctness means, and connect technical choices to product outcomes.

Someone must notice that the project is elegantly solving the wrong problem.

Some engineers will continue writing code directly because it is the fastest way to explore a hard idea or because the agents cannot yet handle a particular domain.

Direct implementation will become one form of engineering contribution among several.

At the same time, product managers, designers, analysts, and domain experts will be able to participate more directly in the construction of software. The boundary between describing a system and producing a working version of it will continue to shrink.

Specialties remain, and expertise can travel more easily.

An engineer’s architectural insight can become an invariant enforced across every agent run. A designer can turn taste into a reusable evaluation, while security knowledge becomes a required gate and customer understanding becomes executable acceptance criteria.

The best teams will turn what they know into a system that can act.

Back to Wallie

I first worked on Wallie during the break between Brex and Coinbase.

At the time, I thought I was trying to build a better issue tracker: something like Linear, designed around coding agents rather than human assignees.

I now think that vision was too small.

Linear can remain the backing store. A Symphony-like system can provide the execution layer. Cloud sandboxes can make the workers persistent and available to the entire team.

The real product is the multiplayer layer that joins them: the place where a team defines how its work moves from idea to production.

Anyone can propose, and the right specialists can approve. Agents can execute continuously while dependencies determine what becomes ready and evidence determines what advances. Every participant can see the same state of the world.

In that sense, Wallie grows beyond a cloud version of Symphony into an operating system for a software team.

The future of software development is a team that can encode how it works, route judgment to the right people, and let agents translate its decisions into running software—continuously, visibly, and within boundaries the team controls.

When code is scarce, we optimize the editor.

When code becomes cheap, we have to optimize judgment, coordination, and feedback.

That is the software factory worth building.