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 description. Agents would write up a plan and turn that intent 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 now realize that that was an incomplete solution.
The deeper problem was making software development multiplayer in a world where code itself was becoming cheap. What we need to build is a system that turns shared intent into continuous, governed execution.
The idea was too early #
Although I wanted to, I did not end up turning Wallie into a startup in early 2025.
Part of the reason was technical: the coding agents were not ready. The models available at the time (Sonnet 3.5) could do impressive things. They made auto-complete work incredibly well, could build a demo (Lovable/Bolt took off around this time), implement a contained feature, or produce a surprisingly good first pass at a pull request.
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.
But the more important reason was strategic. Linear seemed like the natural company to build something like it, and there's no other product 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?
Starting that May, I moved on to other things. But Wallie became one of those ideas that never really leaves. I kept experimenting with ideas from it at my new day job at Coinbase 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.
The December 2025 inflection point #
Claude Opus 4.5, released on November 24, was followed by OpenAI’s 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 pull request without falling apart.
During the holiday break and into early 2026, like many other builders, I started building side projects almost compulsively. Some were useful, while others started as a joke. But they all 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 the era of "agentic engineering".
I was writing almost no 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 not anticipated or had misunderstood.
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. So, as the 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 treated Linear as the system of record and added an execution layer underneath it, making it the control plane.
The Symphony "software factory" became the issue processor.
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 project tracking tool 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 like Conductor/Codex and starting another worktree session. The project in Linear became the durable object, making individual runs / sessions disposable.
Agent sessions start, fail, restart, or disappear. The state of the work remains stored in a Linear issue comment titled “Symphony workpad.”
Instead of mentally reconstructing what several tmux windows or sessions 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 last quarter. Over the last few months, I have used it to build shippable products while devoting only part of my attention to them. My contribution shifted toward product direction, decomposition, review, and course correction, with zero actual coding work.
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, and engineers usually operate several agents in parallel.
But several agents working for one person is still not multiplayer.
It is parallel single-player.
The single user remains the center of the system, carrying context and credentials between sessions until every decision and review obligation eventually returns to this one person.
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 "ticket to PR" agent is treated as a last-mile implementation worker.
But when implementation becomes cheap, everything upstream of implementation becomes the bottleneck.
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 which decision.
Specialization remains as a system of judgment rights: clarity about whose approval a decision needs to make the best use of the team’s domain expertise (and taste).
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 data migration should still require an experienced engineer to approve the rollout.
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. Linear already excels at all this.
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 additionally 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 large-scale migration involving an authentication system 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, it, redirect it, or reassign the work without taking possession of someone else’s laptop.
A cloud version of Symphony isn't enough. Multiplayer also requires policies, approvals, 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, taste, or accountability.
The goal is to direct 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 work.
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. (Yes, with the right guardrails, you can merge PRs without reviews!)
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. Code is only an intermediate output and should now be relegated to an “afterthought” that exists because it has to.
That requires making the development environment legible to agents and encoding the boundaries that keep high-throughput execution coherent. OpenAI’s agent-first engineering experiment found that repositories needed structured knowledge, explicit architectural rules, mechanical enforcement, and feedback loops early, before the product became large.
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 team's shared 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, connect technical choices to product outcomes, and course-correct when intent and execution diverge.
Someone must notice that the project is elegantly solving the wrong problem.
Some engineers will continue writing code directly (i.e., in a TUI on fast mode) because it is the fastest way to explore a hard idea or because the agents cannot yet handle a particular domain autonomously.
At the same time, product managers, designers, analysts, and domain experts will be able to participate more directly in the building of shipped 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 codify what they know into a system that can act on their behalf, while they continue to discover what works and what doesn't for their problem space.
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 half-baked.
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 next product to be built 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.