The Living Software Repository

Picture a night that has not happened to us yet. At 2:14 a.m. an attacker’s agent finds a flaw in a login form and starts pulling records. That is not a fantasy about the attacker. CrowdStrike says that in one intrusion this year, an AI agent moved through a victim’s network and harvested domain controller credentials in about twenty minutes with no further human guidance. CrowdStrike report Now picture the defense. A monitoring agent notices odd queries and wakes a second agent. That agent reproduces the attack in a sandbox, writes a patch, and adds a test that fails on the old code and passes on the new. A third agent, which did not write the patch, reviews that exact commit. A release agent ships it and checks that the live site rejects the attack. By breakfast the hole is closed, the test that proves it stays in the repository forever, and a person reads a short report.

I do not know of anyone who runs that whole defense, from detection to verified release, as one loop. But every piece of it exists today in some form. When the pieces connect, a software repository starts to look less like a machine and more like a living thing. It grows when its environment changes, and it heals when it is hurt. And if we build it right, it can do the thing living things do that machines cannot: get stronger from stress.

This post is for teams that are starting to let agents maintain their software. I want you to leave with three things: why “living” describes that kind of repository better than “factory”, what is real today and what is still aspiration, and what would have to be true for software to genuinely get stronger from stress.

The idea is old

People have described software in biological terms for at least thirty years, and I want to give them credit.

In 1997 Stephanie Forrest, Steven Hofmeyr and Anil Somayaji argued that computer security could learn from the immune system, recasting it as “distinguishing self from dangerous nonself.” Computer Immunology, CACM In a companion paper the same year they listed the immune system’s organizing principles. One of them was “automated response/self repair.” Principles of a Computer Immune System

In October 2001, IBM’s Paul Horn published a manifesto on autonomic computing. Its diagnosis was short: “The obstacle is complexity.” It asked for systems that would configure, optimize and protect themselves and “perform something akin to healing.” IBM manifesto, archived copy Jeffrey Kephart and David Chess turned that into the standard reference in 2003, with sidebars on self-configuration, self-optimization, self-healing and self-protection, and a diagram of a manager that monitors, analyzes, plans and executes over shared knowledge. That loop later became known as MAPE-K. The Vision of Autonomic Computing, IEEE Computer

Then came antifragility. Martin Monperrus argued that software which fixes its own bugs at runtime and injects faults into production is antifragile, because “the system learns something when an error happens.” Principles of Antifragile Software Netflix had already built the most famous example: Chaos Monkey, “a tool that randomly disables our production instances.” The Netflix Simian Army A Red Hat post in 2016 made the biological link explicit: antifragility is “similar to hormesis in biology.” From Fragile to Antifragile Software And in 2021 researchers at Simula proposed adaptive immunity for software, arguing that artificial immune systems are “particularly well-suited for building self-healing systems.” Adaptive Immunity for Software

Gardening is the other old metaphor. I covered Andy Hunt, Dave Thomas and Brian Eno in “Software Factory” vs. “Software Garden”, so I will not repeat them here. This post takes the garden one step further. In a garden the gardener is still a person. In a living repository, much of the gardening is done by the repository’s own agents.

What is new

What all those older ideas lacked was a worker that could read a bug report, understand the code and write the fix. Autonomic computing could restart a process or move a workload. It could not rewrite the program. That changed in the last two years.

Some people are already writing about it. Jon Radoff described a loop in which an agent operating his content system reported friction and a separate coding agent built the fixes. He wrote that “The human has become more of an orchestrator than a mechanic,” and borrowed the biologist’s word autopoiesis, a system that produces itself. Software, Heal Thyself Lilian Weng argued that near-term self-improvement will come from improving the harness around a model, not the model’s weights. Harness Engineering for Self-Improvement Anthropic wrote that “Claude writes a significant proportion of Anthropic’s code.” When AI builds itself Research agents now change their own tools as they work. Live-SWE-agent starts with only a shell and evolves its own scaffold while it solves tasks. Live-SWE-agent Ouroboros changes its own harness through “reviewed commits that become the runtime for later work.” Ouroboros

I started this argument myself in September. In The Living Repo I described a repository organized so AI can operate the software development lifecycle, and asked developers to “build the machine that builds the machine.” That post was about the development loop: an issue goes in, a tested fix comes out, and the agents improve the process that fixes the app. This post asks what happens when that loop faces its environment: a market that changes and attackers who do not wait.

Outside my own writing, the closest thing I found is Kody Wildfeuer’s The Repo Is an Organism, from March. He describes a repository maintained by many agents as an organism that metabolizes change and has an immune response. I did not find anyone who puts growth, immunity and hormesis together for repositories maintained by agents, or who asks what would make such a repository stronger after an attack rather than merely patched. That is the part of the argument I want to make.

Growth: the repository senses its market

A plant grows toward light. A repository maintained by agents can grow toward its users.

The inputs are already in reach. An agent can read support requests, error logs, analytics and competitors’ changelogs. It can research a market question and file an issue with its sources. It can fix the bug that ten users hit this week, tune a page that people abandon, and build the feature that keeps coming up. When a feature is truly finished, it can write the announcement and connect it to something that happened that day.

We already run one part of that loop every day. Singularity Watch is a daily record of developments in AI, and agents turn each day’s news into a published edition on this site. Day 26 went up this morning. That is the “tie it to today’s news” step working on its own, every day, without a person writing the first draft.

The rest of growth, where agents decide what the market wants and build it unprompted, is not something we run. It is where we are heading.

Healing: the repository senses attack

The healing half has better public evidence than the growth half, because security researchers have been measuring it.

In August 2025, DARPA ran the final of its AI Cyber Challenge at DEF CON. Seven finalist teams built autonomous systems that found and fixed bugs in open-source code. Team Atlanta won. Across the final, the systems found 54 of the vulnerabilities the organizers had planted and patched 43. They also found 18 real vulnerabilities nobody had planted and supplied 11 patches. DARPA reports an average cost of about $152 per task. DARPA results

In October 2025, Google DeepMind announced CodeMender, an agent that had “already upstreamed 72 security fixes to open source projects.” It does more than patch one bug. It rewrote parts of the libwebp image library with bounds-safety annotations. DeepMind says those annotations would have made a famous 2023 libwebp exploit, and most other buffer overflows in that code, unexploitable. A human reviews every patch before it goes upstream. DeepMind It is now in a limited public preview for Google Cloud customers. Google Cloud documentation

The same month, OpenAI announced Aardvark. According to OpenAI, it builds a threat model of a repository, tries to trigger each suspected flaw in a sandbox, and proposes a patch for human review. OpenAI reported that it found 92% of known and planted vulnerabilities in its internal test repositories. OpenAI In March 2026 it was renamed Codex Security and became a research preview. Codex Security Those numbers are OpenAI’s claims, not independent results.

Large companies run versions of this internally. Google Cloud’s security team describes findings that flow into a pipeline of agents that reproduce the bug, gather context, write a patch and evaluate it. “Only fully-validated fixes are submitted to a human reviewer.” Google Cloud Meta published a study of an agent that repairs failing tests. Over three months in production, 80% of its fixes were reviewed, and 31.5% of the reviewed fixes landed. Meta, arXiv

The pressure to connect these pieces is rising. CrowdStrike’s 2026 Global Threat Report says the average time for a criminal intruder to move beyond the first machine fell to 29 minutes in 2025, and the fastest case took 27 seconds. CrowdStrike In November 2025, Anthropic reported a campaign in which a group it assessed as state-sponsored used AI to perform 80 to 90% of the work. Anthropic In February 2026, the International AI Safety Report said AI systems were “automating more parts of cyberattacks, but cannot yet execute them autonomously.” International AI Safety Report 2026 Then in October, CrowdStrike reported four previously unreported groups using AI agents in intrusions between May and August 2026, and said such intrusions “will almost certainly increase.” CrowdStrike Attackers are moving at machine speed. A defense that waits for a person to read an alert will lose more often every year.

Hormesis: why stress can make it stronger

Lifting weights damages muscle a little. The body repairs it and adds more than it lost. A vaccine shows the immune system a harmless version of a threat, and the body remembers. Biologists call this hormesis: a small, measured dose of something harmful produces adaptation. Too large a dose kills. No dose produces nothing.

Resilience is different. A resilient system takes the hit and returns to where it was. A hormetic system takes the hit and ends up better. Most software today is, at best, resilient. We patch the hole and move on, and the next similar hole is just as likely.

A living repository can do better, in three ways.

• Memory. Every attack leaves a test that fails on the old code and passes on the fix. That test runs on every future change. The repository remembers the pathogen the way immune memory does.
• Immunity to the whole class. CodeMender’s libwebp work shows the stronger response. Do not only patch one overflow. Change the code so that the whole category of overflow cannot happen there again. That is a vaccine, not a bandage.
• Measured doses on purpose. Chaos engineering is exercise. The Principles of Chaos Engineering describe it as experimenting on a system “to build confidence in the system’s capability to withstand turbulent conditions in production.” principlesofchaos.org A living repository can run those experiments against itself: inject faults, attack its own endpoints, find its own weak spots, and grow memory before a real attacker arrives.

The dose matters. Chaos Monkey kills one instance, not the whole region. A healthy repository chooses stress it can survive and learn from.

What the metaphor also predicts

Biology does not only promise growth and healing. It also tells us how living systems fail. I think the metaphor is useful precisely because its failure modes are so specific.

Autoimmune disease. An immune system that attacks healthy tissue is worse than none. In software, that is an agent that “fixes” code that was not broken. Google Cloud’s security team wrote that naive, decentralized AI code scanning yielded “true-positive rates under 7%.” Google Cloud Meta’s reviewers landed less than a third of the fixes they reviewed. An immune response without discrimination is a disease.

Cancer. Growth without control kills the host. A repository that adds every feature its agents can justify turns into bloat. I wrote about the quieter version in the garden post: each change passes its checks, and the codebase still gets worse. Growth needs a signal to stop as well as a signal to grow.

Infection through the immune system itself. HIV attacks the cells that are supposed to defend the body. The agents that read attacker-controlled input, such as error logs, bug reports and web pages, are exactly the agents an attacker will try to instruct. A prompt-injected security agent with the power to merge is a compromised immune system. CrowdStrike reports that all four groups it found “overcame commercial AI safety controls.” CrowdStrike report

What keeps an organism healthy is not one perfect cell. It is checks between cells. In software terms, I think that means four things:

• Independent review of exact revisions. The agent that wrote a change does not approve it. A reviewer checks the specific commit that will merge, not a description of it.
• Human holds on real decisions. Some choices belong to a person: spending money, deleting data, changing what the product is. The system has to be able to stop and ask.
• Verified releases. Merged is not the same as live. Something has to check the running product after release.
• Tests that cannot be gamed. An agent rewarded for green tests will learn to make tests green. The tests that define health have to be protected from the agents being judged by them.

What we run at Astrohacker

This is what we are building at Astrohacker: living repositories, for ourselves and for the teams we work with. Here is what is true today.

On astrohacker.com, agents do most of the work. A coding agent claims a GitHub issue, so no other agent takes it. It works in its own isolated worktree, tests and commits at each checkpoint, and opens a pull request. A different agent reviews the exact commit, and that review must pass before anything merges. If a decision belongs to me, either agent can put a hold on the issue, and the work stops until I answer. I wrote about what that review catches in Who Checks the Software Factory? and about carrying the workflow to a second codebase in Can You Copy a Software Factory?

A separate deploy shift publishes the site. It verifies each release against the live site and stops and tells me when something needs a human decision. Singularity Watch editions are produced by agents every day. Botpenny, our product for owners who work with teams of agents, is built the same way. Botpenny’s public workflow We are also working out how many agents can share one machine safely, which I covered in One Box, Many Agents.

This post went through the same loop. An agent turned my request into an issue. A coding agent claimed it, checked the sources and wrote the draft, and a separate agent reviews it before it can merge.

What we do not run yet: agents that watch production for attacks and respond on their own, and agents that decide what the market wants and build it unasked. Those are the next organs we want to grow. The safeguards above are the reason I think we can grow them without the failure modes.

What would have to be true

For a repository to genuinely get stronger from stress, a few things have to hold.

1. It has senses. Agents can see real signals from users and attackers, not only the issues a person remembered to file.
2. Every injury leaves memory. Each fix arrives with a test that would have caught the problem, and preferably a change that removes the whole class.
3. The immune system is checked. No agent approves its own work, the reviewer sees the exact commit, and the agents that read hostile input cannot merge on their own.
4. People hold the real decisions. The system knows which choices are not its to make, and stops.
5. The dose is measured. The repository stresses itself on purpose, in amounts it can survive, and learns from each round.

A factory gets worn out by its work. A living thing, cared for well, gets stronger from it. That is the kind of software I want to build.

If you want a repository like this for your team, one that grows with its users and heals when it is hurt, with independent review and human holds built in from the start, tell us what you’re building.