There’s a compelling vision making the rounds: the self-driving codebase. Agents that wake up on events — a new CVE, a failed CI run, a Slack message — write code, run tests, open PRs, and loop. No human in sight until review time.

A recent piece from Ona lays it out clearly. Background agents need three things: isolated compute, event routing, and a governance layer. The developer moves from “in the loop” to “on the loop” — reviewing output and calibrating behavior rather than writing every line.

It’s a real vision. But we think it misses something important about why developers build software in the first place.

Software is an expression of taste

The best codebases aren’t just functional. They reflect thousands of small decisions: what to abstract, what to leave concrete. What to build, what to deliberately leave out. Where to be clever and where to be boring. These decisions aren’t mechanical — they’re taste.

Taste is why two teams solving the same problem produce wildly different architectures. It’s why some codebases are a pleasure to work in and others technically work but feel like they’re fighting you. It’s the difference between software that’s correct and software that’s good.

Agents are powerful. They can generate code, run tests, iterate on failures, and produce working solutions at speed no human can match. But working code was never the hard part. The hard part is deciding what the code should be in the first place — and that’s a question of taste, not capability.

The self-driving codebase removes the driver

Fully autonomous agents optimizing for ticket closure, test passage, and PR throughput will produce software that passes every check and satisfies no one. They’ll add the abstraction layer you didn’t need. They’ll solve the edge case you’d rather leave unsupported. They’ll make the codebase more “correct” in ways that make it worse.

This isn’t a problem that better models solve. It’s not a skill gap. It’s the absence of someone who cares about what the software feels like to use and maintain.

The self-driving codebase treats developer involvement as overhead to eliminate. We think it’s the whole point.

Agents that live in your codebase

Instead of agents that run autonomously on your codebase, picture agents that live inside it — persistent environments where the agent has your full project context and stays there across sessions. Ready to act, but acting on your direction.

The codebase becomes self-acting: it has the capacity to change itself. But you choose what changes, and why. The agent brings speed and breadth. You bring judgment about what’s worth building.

This isn’t a compromise on the way to full autonomy. It’s the better model. A great developer with agents in their codebase will produce better software than autonomous agents with a human reviewer, because taste gets expressed in the making, not in the review.

Pattern 1: the architecture that’s winning

The Ona article identifies two patterns for agent infrastructure, and the distinction matters.

Pattern 1: Agent has the dev environment. A VM with your codebase, test suite, databases, and internal network access. The agent operates inside the full development context. Stripe, Ramp, and Spotify all converged here independently — because it’s the closest to how a human developer actually works.

Pattern 2: Sandbox as tool. The agent runs elsewhere. When it needs to execute code, it calls a remote sandbox via API. The sandbox runs the snippet and returns the result. The agent can execute code, but it can’t fully develop.

Pattern 2 is what most agent products ship today. The agent lobs code at a stateless container that can’t browse your filesystem, run your test suite, or iterate with real context.

Pattern 1 is what agents need to be genuine collaborators — not remote code generators, but participants in the codebase with the same context you have. And when the agent has that full context, your taste as a developer gets amplified rather than bypassed.

Multiple agents, one codebase, one driver

One agent inside your codebase is an assistant. Multiple agents inside the same codebase is a team you direct.

When three agents share the same persistent filesystem, you can draft with one, challenge the approach with another, and refactor with a third. Same files, same state, different perspectives. You’re not managing agents — you’re making decisions about your software, with agents executing at speed.

This is where taste scales. Instead of choosing between your judgment and agent speed, you get both. You decide the architecture. You decide what stays and what gets cut. The agents generate, iterate, and explore the solution space — but the codebase reflects your decisions about what good looks like.

What the infrastructure needs to look like

The Ona article gets the infrastructure requirements right. Agents need:

Real isolation — VMs, not containers. Full root access, full Linux. An agent that can’t install a dependency or modify a system config is working with one hand behind its back.
Persistence — The environment survives between sessions. Agent history, file changes, installed packages — all still there when you come back.
Compute on demand — Environments that sleep when idle and wake instantly. You shouldn’t pay for a VM that’s waiting for your next idea.

This is the layer that makes “agents living in codebases” practical. Not a laptop running hot. Not a container that resets every run. A persistent, isolated workspace that agents and developers share.

The self-driving codebase optimizes for output. The self-acting codebase optimizes for quality — because there’s a human with taste at the center, making the calls that make software good.

Agents are ready. Models are capable. But the best software will still come from developers who care about what they’re building — now with agents that live in the codebase and move when they say move.