The framing for AI as a coding assistant has shifted quickly over the past year or two. Early on, it was mostly about autocomplete — a smarter tab-key. Now teams are asking a different question: what does it look like when the agent doesn’t just suggest code, but actually opens a branch, implements a feature, runs the tests, handles review feedback, and merges?
That’s the software factory problem, and it turns out to be an infrastructure problem as much as an AI one.
Four layers, not one
Teams that have gotten this working tend to describe the same four-layer structure, even when they’ve arrived at it independently.
Compute is the most visible layer — where agent sessions actually run. This can be cloud virtual machines, Kubernetes pods (a cluster of containers managed as a group), or physical machines the team already owned. The key variable isn’t the provider but boot time: an agent that has to wait for a container to spin up on every retry is a fundamentally different beast from one that starts instantly on a warm machine.
The dev environment sits one level up: language runtimes, toolchains, credentials, access to internal services. This is where the “pets versus cattle” question — pets are servers you configure by hand and keep running; cattle are identical, disposable instances you spin up on demand — actually bites. A single team can get away with a hand-configured machine. The moment the work involves multiple repositories, internal APIs behind private networks, or dozens of microservices, the dev environment layer needs to be scripted and reproducible. Otherwise the agent can’t reliably run the code it’s about to change.
The harness is what actually drives the agent. There are two kinds. The inner harness is the coding agent itself — a command-line tool or API that turns a prompt into actions (edits, shell commands, file reads). The outer harness is the code teams write around it: the retry loops, the escalation logic, the rules that say “if the pull request still isn’t passing after three rounds of review feedback, page a human.” This outer layer is where most of the interesting engineering happens. It’s also where teams are currently stuck: harnesses for different inner agents are incompatible with each other, so a retry loop written for one tool has to be rewritten from scratch for another. No good universal abstraction exists yet.
The control plane sits above all of this and is, by most accounts, the most underserved layer right now. It’s the dispatcher — the service that receives a notification from GitHub or Slack, decides which agent should handle it, manages budgets and audit logs, tracks session history, and handles scheduling. Most teams end up building this themselves because there’s no off-the-shelf product that covers it well.
The buy-versus-build question
The natural instinct when looking at this stack is to ask which vendor covers it all. Several do: fully managed coding agents that handle everything from the prompt to the merged pull request. The tradeoff is real friction around the dev environment and compute layers — the parts that need to connect to internal services, respect internal security boundaries, and run on infrastructure the team actually controls.
The emerging middle path looks more like composition than wholesale adoption. Rather than committing to a single vendor for the whole stack, the approach worth reaching for is: buy the layers where vendor solutions genuinely work, build the layers where the constraints are too specific. The interfaces between layers then matter more than the choice at any individual layer.
The Model Context Protocol (MCP) — a standard that lets AI tools connect to external systems in a consistent, interchangeable way — is the clearest example so far of an interface that enables this kind of mixing and matching. The equivalent standard for harness lifecycle hooks doesn’t exist yet, which is why the outer harness remains a lot of bespoke code for every team that builds one.
Humans stay in the loop — by design
One thing production pipelines seem to share: targeting full automation is the wrong goal. The practical ceiling is well short of a hundred percent — agents handle the predictable cases autonomously, and humans stay in the loop for anything involving external dependencies, ambiguous requirements, or hard edge cases. The design question isn’t “how do we remove the human?” but “where does the human add value, and how do we route to them cleanly?”
As tooling around harness interoperability and control planes matures, that routing question will get sharper. But the four-layer structure underneath looks durable — less a product of the current tool landscape than a reflection of what the problem actually requires.
Text summarized and optimized using Anthropic’s models and reviewed by a human.