There is a LinkedIn video from March 19 that shows Nate Sesti, the founder of Continue.dev, running 30 AI coding agents at the same time using an Xbox controller and Wispr Flow, which is a voice dictation tool that lets him issue commands without ever touching a keyboard, and what makes this interesting is not the novelty of using a game controller to write software but the fact that his team records their daily standups, feeds those full transcripts into their agent system, and the agents just start working on whatever was discussed without anyone having to file a ticket or manually assign anything. Sesti says he did a two-week challenge where he refused to open his code editor, and he has not opened it since.
This is not a demo or a conference talk experiment, this is how his company actually ships software every day, and while the conversation around this kind of workflow has been getting louder in Y Combinator communities and among indie developers who are pushing the limits of tools like Claude Code, the reality is that enterprise software development has barely registered any of this yet. That gap between what the bleeding edge is doing and what corporate engineering teams consider normal is real, but given the numbers in Anthropic’s 2026 Agentic Coding Trends Report and the venture capital that keeps flowing into this space, that gap is probably not going to last very long.
The evolution that brought us to this point happened faster than most of the industry expected and it is worth walking through because each wave created the conditions for the next one. The first wave was the AI sidebar, tools like GitHub Copilot and Codeium that bolted a chat panel to the side of your code editor and offered autocomplete suggestions, basically a smarter version of predictive text for programmers that was useful enough to keep around but limited enough that you could ignore it when it got something wrong and keep moving. The second wave was when developers started realizing the AI assistant was actually more useful than the editor itself, which is when products like Cursor and Windsurf expanded the AI interface until it basically replaced the traditional development environment, and you were still writing code but the AI was doing more and more of the actual composition.
The third wave was Claude Code and similar terminal-based agents that took the editor out of the equation entirely, where you describe what you want in plain English and the agent writes the code, runs it, hits errors, fixes them, and delivers working output back to you without you ever touching a line of code yourself. One agent handling one task is totally manageable even for teams that are still getting comfortable with AI writing production code, but the problems start when developers do what developers always do with a tool that works, which is scale it, two agents then four then eight then sixteen running in parallel across the same codebase using git worktrees for isolation, each one modifying files on its own timeline, and somewhere around that threshold the bottleneck stops being the code and starts being the developer’s ability to keep track of what all those agents are actually doing.
This is where the current tooling starts to break down and where a handful of developers and companies are trying to build what comes next. Factory.ai is building what they call “agent-native software development,” which is a platform that lets teams script and run AI agents at scale across their entire development pipeline. Steve Yegge, whose commentary on developer tools has shaped how the industry thinks for basically two decades, built a system called Gas Town that orchestrates 20 to 30 parallel agents alongside something called Beads, which is a memory and issue tracking layer designed specifically for AI agents rather than human developers. 1Code out of the YC Winter 2026 batch wraps terminal agents like Claude Code in a desktop interface with parallel worktrees, real-time change tracking, and background execution, and all of this infrastructure is being built in public and in real time right now.
Sesti’s contribution at Continue is particularly worth paying attention to because it goes after the quality problem instead of the scale problem. His team writes what they call check files, which are plain text documents stored right next to the codebase in version control, and each file contains instructions telling an AI agent what to look for when reviewing a batch of code changes. Things like catching AI-generated filler that reads like it was written by a machine, validating that database changes will not break existing data, confirming the interface works on mobile screens, flagging duplicated logic, basically whatever the team has decided actually matters for quality. Those checks run automatically every time someone submits code changes for review and they show up as pass/fail indicators that block the submission from being accepted until every issue is resolved, and if everything passes the checks produce no output at all.
That silent-by-default approach is what separates it from the code review bots that have popped up everywhere over the past two years, which are tools that generate a wall of generic feedback on every single submission whether anyone asked for it or not. Continue’s system only talks when it catches the specific thing someone told it to catch, and over time a team builds up a library of these checks that starts functioning as a kind of institutional memory, the team’s standards and lessons learned encoded as AI-readable prompts, tracked in version control the same way the code itself is, and enforced automatically on every contribution. For anyone who has ever worked on a team where critical knowledge lived in one person’s head and disappeared when they left, that alone is a pretty significant development, and it also has obvious implications for the security of automated development pipelines where the tools developers trust to guard their code have themselves become attack targets.
But checks solve quality at the level of individual code submissions and the larger question that nobody has a solid answer for yet is who actually manages the factory when everything is running at once.
When a team has a dozen or more agents operating in parallel with an orchestrator keeping them from writing conflicting code, something still needs to decide when to stop and take a snapshot of the current state so that humans can meaningfully evaluate where things are before the agents keep iterating. Something needs to recognize that a subset of agents have been producing circular output, rewriting the same file and hitting the same error and making zero forward progress, and kill those tasks before they burn compute and create problems downstream for everything else. Something needs to decide which work is ready to ship, which needs another pass, and which threads should just be abandoned entirely, and Sesti himself describes traditional issue tracking as feeling more like a blocker than a helper in this environment, which tells you that even the basic interfaces between humans and these systems are straining under a workflow they were never designed for.
Right now all of those judgment calls fall on the individual developer, who is making them manually while also trying to do the work that prompted them to spin up agents in the first place, and that is the bottleneck. Not the agents, not the orchestrator, not the code quality gates, but the human being trying to be the foreman of a factory that has no foreman role built into it.
Manufacturing figured this out over a century ago. You do not run a factory floor by adding more machines and hoping quality stays consistent, you put a foreman on the floor, someone whose entire job is not building the product but watching the production line, recognizing when output quality starts drifting before it turns into a batch of defective product, and making the call to stop the line when something is off. The foreman does not replace the workers or the machines, the foreman is the judgment layer that makes sure the factory actually produces something worth shipping, and anyone who has spent time in operations or logistics or industrial management recognizes this role immediately. It is the missing piece in the software factory and nobody has built it yet.
The orchestrators handle coordination. The check systems handle quality gates on individual outputs. But the layer above both of those, the one that watches the entire operation in real time and makes the calls about what to continue, what to checkpoint, what to iterate on, and what to shut down, that layer does not exist in any production-ready form right now. The companies building the current generation of tools know this, and the question is whether the solution comes from within the existing ecosystem or from someone who recognizes that managing a factory is a fundamentally different discipline than building one.
Enterprise has not touched any of this yet which means the terminology is still settling and the tooling is still raw, but the pattern is unmistakable and it is moving from the fringes toward mainstream development faster than the infrastructure can keep up. The piece that is missing is not more agents or better orchestration or smarter quality checks, it is judgment applied at the level of the operation itself.
The factory is running. The foreman position is open.
Next in this series: how markdown check files are becoming the quality control layer for AI-generated code, and what that means for teams that have never version-controlled their standards before.