The Future of Software Factories Is Multiplayer<br>Skip to main contentAnant Jain<br>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...