Agent-Maintained Software

The pattern at Ramp

At Ramp, an internal bug report once arrived after the system had already filed the fix.¹ That is the proof of the pattern behind it: a codebase continuously maintained by agents rather than only by humans, where agents watch production, decide what deserves attention, reproduce failures end to end in a sandbox, and open root-cause pull requests, with humans reduced to reviewing merges. Ramp's worked example is its self-maintaining Ramp Sheets product. The enabling shift is economic: agents are cheap to run, infinitely patient, and easy to parallelize, which makes exhaustive monitoring feasible at a scale no human team would staff.

The design arrived in three stages. Scheduled auditing came first: a nightly agent sanity-tested features and stress-tested recent pull requests, useful for high-radius issues but blind to narrow, situational bugs, since deciding what in a large codebase actually deserves attention was judged to require a level of intelligence beyond any available model. Monitor-driven maintenance came next: on every merge, an agent reads the diff and generates monitors for the new code, and when one fires, a webhook spins up an agent with the alert context that reproduces, fixes, and reports the issue. This caught forty real bugs in its first week, often within minutes, and scaled to roughly one thousand monitors, one for every seventy-five lines of code, described as a tight mesh over the exact shape of the code.¹ The third stage is triage to kill noise: because auto-generated monitors carry bad thresholds, every alert first receives a scope judgment, either a real fix plus notification or a tuned or deleted monitor, with duplicate suppression achieved by writing the fix link onto the monitor so later agents stand down.

Spotify's route from the opposite direction

Where Ramp built agent maintenance forward from observability, Spotify arrived at the same place backward from migration toil, and reached one of the more aggressive versions of the pattern: most pull requests are auto-merged without a human ever seeing them.² Spotify's prior safety model was component ownership, in which every piece of code was owned by one team that designed, built, and operated it and reviewed every change to it, which let the team be looser about test automation because a human was always in the loop. Automating pull requests broke that assumption, so the required investment was much stronger test automation, strong enough that the software could survive automated changes unattended. That investment is what now lets Spotify run agents against the codebase using the same verification the company already trusted.

Spotify runs this through an internal platform called Honk, built on an agent framework running in Kubernetes with access to real continuous integration builds on both Linux and macOS. A judge model that had once lifted pull request success from roughly twenty to thirty percent up to about eighty percent was later removed once the underlying models and the surrounding harness caught up on their own. The team reports roughly seventy three percent of pull requests as AI-authored and about forty five hundred production deployments a day, with quality metrics held steady while speed rose. The through-line with Ramp's account is the same: the verifier, in this case continuous integration, is the mechanism that replaces human review, and auto-merging forces a team to remove its human safety net first, which is exactly why verification cannot be an afterthought.

The platform statement

Where Ramp and Spotify built agent maintenance inside their own codebases, Guillermo Rauch states it as a platform primitive for everyone else's. His AI Cloud thesis splits the software lifecycle into build, already automated by framework defined infrastructure, and run, where he argues AI extends autonomy into an infrastructure layer that "monitors, optimizes, secures, and repairs itself, without human intervention."³ The claim is that an AI Cloud should not hand a developer problem after problem such as alerts, server errors, and latency spikes, but should hand over solutions: pull requests, recommendations, and automated actions. Two shipping instances at Vercel are the Firewall Agent, which responds to threats and hands operators investigations and mitigation strategies, and the Code Review Agent, which executes every pull request in a sandbox and is described as emulating a dedicated, skeptical colleague. This generalizes the same core idea, sandboxed reproduction and a verifier standing in for a human, into an infrastructure product rather than an internal tool.

The further endpoint: outcome-specified code

Eric Glyman sketches a more radical version of the same idea: code a team does not read at all.⁴ His premise is that it is more fun to write code than to read it, and that lines of code are a liability rather than an asset, something to be reckoned with later. In a large language model world, he argues, a team might instead specify an outcome under given conditions and let a model write the code that drives it. Today that produces something that works but resembles a Rube Goldberg machine underneath. As models improve, a team could rewrite the underlying code every year to push the outcome's accuracy from the low nineties toward one hundred percent, until the code underneath effectively disappears and the system heals itself. His stated limit is that this is not yet appropriate for systems that require four nines of accuracy or uptime, but he believes a growth engineering team working at the edge is probably doing something like it already.

Load-bearing principles

Two principles recur across every account of the pattern. The first is to detect everything but notify selectively: watch every signal, but make every alert that reaches a human actually mean something, since teams learn to ignore noisy monitors exactly as they learn to ignore noisy agents. The second is sandboxed reproduction before any fix: a fix is only pushed once a reproduction test passes, which is the mechanism that makes the fix trustworthy in the first place.