The Software is Alive!

Here is a scene. It has not happened on this site. Every part of it exists somewhere today.

At 3:12 a.m., a security advisory is published for a library your app uses. A sense agent reads it two minutes later and files an issue: which package, which versions, which of your pages use it, and how to know it is fixed. A code agent claims the issue, makes a branch, bumps the library, and runs the build and the tests. One test fails, because the fix changed a default. The agent adjusts the call, and the tests pass. A separate review agent checks out the exact commit in a clean workspace, runs every check itself, and passes it. The change is a patch-level security fix, and every check is green, so it is inside the bounds you wrote. The deploy agent publishes it, verifies the live site over HTTPS, and records the release.

At 7:30 a.m., you read one paragraph over coffee. It names the advisory, the fix, the reviewer and the release. You do not have to do anything.

That is a system keeping itself well. The software is alive.

What “alive” means

Biologists have described this for a hundred years.

In 1926, the physiologist Walter Cannon proposed a word for how a body keeps itself steady: homeostasis. In his 1929 paper, he wrote that disturbances “are normally kept within narrow limits, because automatic adjustments within the system are brought into action.” Your temperature stays near 37 degrees because something inside you notices and corrects it.

In 1948, Norbert Wiener gave the mechanism a name in Cybernetics: or Control and Communication in the Animal and the Machine. Negative feedback “tends to oppose what the system is already doing.” His example was the thermostat, and he made a point that matters here: “There are, however, feedback chains in which no human element intervenes.”

In 1980, Humberto Maturana and Francisco Varela went further, in Autopoiesis and Cognition. A living system does not only hold itself steady. It makes itself. Its parts “continuously regenerate and realize the network of processes (relations) that produced them.” A cell builds its own proteins.

In October 2001, IBM published a manifesto on autonomic computing, signed by Paul Horn. It was named after the autonomic nervous system, which runs your heartbeat and your breathing without asking you. “It’s as if the autonomic nervous system says to you, Don’t think about it — no need to. I’ve got it all covered.” Among other things, the manifesto said such a system “must perform something akin to healing.” Its diagnosis of the problem was four words: “The obstacle is complexity.”

In 2003, Jeffrey Kephart and David Chess wrote the short version: “The essence of autonomic computing systems is self-management.” They listed four kinds: self-configuration, self-optimization, self-healing and self-protection. And they drew the loop that does it: monitor, analyze, plan and execute, around shared knowledge. People now call it MAPE-K.

So “alive”, for software, has a precise meaning. It senses, holds itself inside limits, repairs damage, defends itself and adapts. And, the hard part, it makes its own parts.

Alive at the surface

Much of this already runs, and it predates large language models.

A Kubernetes cluster is a set of control loops. “Each controller tries to move the current cluster state closer to the desired state.” The docs use Wiener’s example: “The thermostat acts to bring the current state closer to the desired state.” Kubernetes “restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check.”

On May 18, 2009, Amazon launched Auto Scaling, so servers “scale automatically based on actual system load.” Netflix went further and attacked itself on purpose. Chaos Monkey “is responsible for randomly terminating instances in production.” It is a vaccine: small, controlled damage that makes the system build defenses.

Google wrote the operating rules in the SRE book. The goal is to “turn cluster management into something autonomous, as opposed to automated.” And Google bounded change with an error budget: “as long as there is error budget remaining—new releases can be pushed.” When the budget is spent, “releases are temporarily halted.”

All of that is homeostasis. None of it is autopoiesis. A controller can restart a crashing container a thousand times. It cannot fix the bug that makes it crash. The body was alive, but its cells could not make new proteins. Someone had to come in and write them.

The new part: the software rewrites itself

That is what changed. Agents can now write the code.

In August 2025, DARPA announced the results of its AI Cyber Challenge. The finalists’ cyber reasoning systems found 54 of the 63 synthetic vulnerabilities in the final and patched 43. They also found 18 real vulnerabilities in open-source code. “Teams submitted patches in an average of 45 minutes.” Team Atlanta won, and DARPA released four of the seven finalist systems as open source that day.

Meanwhile, agents that repair code have moved into products:

• Google’s Big Sleep found an exploitable bug in SQLite in 2024, and in July 2025 Google said the agent had foiled an attempt to exploit another SQLite bug in the wild.
• Google DeepMind’s CodeMender upstreamed 72 security fixes to open source by October 2025. It has been in preview on Google Cloud since July 21, 2026.
• GitHub’s agentic autofix became generally available on October 15, 2026. Assign it a code scanning alert, and it explores the codebase, writes a fix, reruns CodeQL to confirm the alert is closed, and opens a pull request.
• OpenAI’s Aardvark, announced in October 2025, is now Codex Security, in research preview since March 6, 2026.
• Sentry’s Seer reads an error, finds the root cause and can open a pull request. It has been generally available since June 2025.

Notice one thing they all share. Each one stops at a human. CodeMender’s fixes are “reviewed by human researchers before they’re submitted upstream,” and on Google Cloud, “Developers remain in full control.” GitHub’s agent opens a draft for review. Sentry says “nothing gets merged without your approval.”

So the organs exist. What is missing is the body: the line that connects them, checks the work, ships it and remembers, inside bounds a human wrote once instead of approving every time.

The factory becomes an organism

I have been building that body for months, out of teams of SI agents. I described the factory in Inside the Software Factory That Writes All My Code, the team as one computer in My Computer Is a Team of Super Intelligent Agents, the roles that built this site in When the Car Comes Out Broken, and how much it makes in 492 Useful Commits on a Sunday. Here is the same factory, seen as a body.

• Issues is the brain stem. It turns signals into work with a clear outcome and a check.
• Code is repair. It makes new parts.
• Review is the immune check. It assumes the new part is wrong until the evidence says otherwise.
• Deploy is motor control. It acts on the world and verifies the result.
• The repo is memory: every issue, plan, review and release.

What the body lacks is senses. Today, most work items start with me. I am the eyes and the ears.

Some senses already exist at Astrohacker. In Our First Team of Grok Bots, Max Commits reported on them. An analytics bot reads our web stats every morning, and found bot traffic and a spam referrer in its first two weeks. A Dependencies bot checks our Rust and TypeScript packages every day. It sends patch updates to a coding agent, which opens one pull request. Minor and major updates and security advisories go to me as a report.

The next step is small. Let a sense file an issue into the queue, not a report into my inbox. Then the line does the rest.

Three responses

Immune response: an attack. Last month, Alan Wells posted on X about seven days of defense against an active cyberattack on one of his products, as I recounted in The State of Software Factories in 2026. His team has three people. They survived, he wrote, because they had spent the months before building a software factory. Agents can do much of that response today: read the logs, find the hole, write, test and review the patch. What needs a human is a call that changes the business, like taking a feature offline or telling customers.

A body also remembers infections. This morning, this site learned a rule. I decided that it never uses the browser’s reduced-motion feature, and the issues agent wrote that decision into an issue. A code agent did not just fix it once. It wrote a check that fails the tests if any code adds it back. That is an antibody. The next agent that tries gets rejected by the line, not by me.

Metabolism: the market. Software has adapted to markets for years. Uber’s surge rates are “updated based on the demand in real time.” Stripe retrains the models behind its fraud checks, and as Stripe wrote, “fraud patterns have changed considerably.” But those systems change numbers, not code. They are tuned by rules and models that people built.

The agentic version changes the code. A sense notices that a model provider raised its prices, or that a cheaper one matches it on your evals. It files an issue with the cost and the check, and the line makes the switch. What needs a human is the price you charge and the market you choose. Those are strategy, not maintenance.

Nervous system: the news. At Astrohacker, Singularity Watch already reads AI news every day and publishes a record. Point that sense at your own stack. When Google announced that Jules is winding down on December 31, 2026, a sense could have filed an issue for everyone who depended on it: here is the date, here is the replacement, here is how to test the migration. The line moves the code before the deadline. What needs a human is what you say in public, and what you build because of the news.

Bounds controlled by humans

This is what makes it trustworthy. A living thing without limits is a tumor.

The idea has names. The Congressional Research Service, summarizing the US Defense Department’s policy on autonomous weapons, contrasts “human in the loop” systems with “human on the loop” systems, “in which operators have the ability to monitor and halt” the system. In the loop, you approve every step. On the loop, you watch, and you can stop it.

The labs agree. OpenAI’s Practices for Governing Agentic AI Systems lists approval for risky actions, legibility, automatic monitoring, attributability and interruptibility: “the ability to ‘turn an agent off’.” Anthropic’s framework for agents says “humans should retain control over how their goals are pursued, particularly before high-stakes decisions are made.” Google’s approach to secure agents: “agents must have well-defined human controllers.” And the NIST AI Risk Management Framework asks for mechanisms “to supersede, disengage, or deactivate” AI systems that misbehave.

Here is what those words look like in the repository behind this site. The rules are written in AGENTS.md and the role skills, and one command, rxc.nu, enforces the workflow:

• A scope. Agents work in this repository only. Coding and review agents never deploy. Only I start a release.
• A gate. Every pull request gets an independent review. The reviewer checks out the exact commit and runs the build, the tests and the browser checks itself. A pass applies to that commit only.
• A budget. After three rounds of change requests, the reviewer passes the work or halts it for me. Nothing loops forever.
• An escalation. When an agent needs a decision only I can make, it marks the issue needs-human and takes other work. Only I clear the hold.
• A rollback. Releases go through a journal. A failed deploy redeploys the previous release and verifies it. An unexpected live version stops the line until I look. Rollback happens only on my direction.
• An audit trail. Every commit, claim, verdict and release is recorded in Git and GitHub, and every claim and verdict names the agent that made it. I can read why anything happened.

In CAD for Software, I wrote that the spec, the rules and the checks are the design file. The bounds are part of that file. You do not approve every change. You write which kinds are allowed, and the checks enforce it. Today my bounds are tight: nothing ships without me. The point of the bounds is that I can widen them one category at a time, starting with the safest, as the record earns it.

That is the move from in the loop to on the loop. You stop holding the system’s hand. You watch over it.

The risks, taken seriously

Runaway change. An agent fixes one thing and breaks three, and the next agent fixes those. The answer is a change budget, like Google’s error budget: a limit on changes per day, a limit on review rounds, and a halt when production gets worse.

Fixing symptoms, not causes. An agent can silence a failing test instead of fixing the bug. The answer is an independent reviewer whose job is to reject the work, and a rule I wrote about in the car post: when the output is wrong, fix the factory that made it. In Who Checks the Software Factory?, a reviewer caught a bug that eight green test suites missed, because it changed an input the author never varied.

Poisoned senses. A sense reads the outside world, and the outside world can lie. OWASP lists prompt injection as the top risk for LLM applications: “Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files.” A fake advisory or a planted news story could steer the swarm. The answer is that a sense can file an issue, and nothing more. What it reads is data, not an instruction. It cannot widen a bound, grant a permission or skip a review. Bounds come only from humans, written in the repo.

Accountability. When the software changes itself, who is responsible? The person who set the bounds. OpenAI’s paper puts it plainly: “With the creation of reliable attribution, it could become possible to have reliable accountability.” Every pull request here names the agent that wrote it, the agent that reviewed it and the human who owns them both.

Complexity no one understands. IBM named this in 2001, and an organism that rewrites itself can grow past anyone’s understanding. I do not have a complete answer. I keep the record in plain language: the goal, the plan, the evidence and the result, for every change. I read the record and the product, not the diffs. When the record stops making sense, that is the signal to stop and simplify.

The software is alive

Not conscious, and not out of control. Alive the way a body is alive: it senses, repairs itself, defends itself and adapts, mostly without asking. A human sets the bounds and watches.

The parts are here. Self-healing infrastructure is more than fifteen years old. Agents that write fixes ship in products today. What is new is the line that joins them, and the bounds that make it safe to let it run.

Here is a first step. Pick one sense and one bound. The sense: dependency security advisories, filed as issues. The bound: patch-level updates only, every check green, an independent review, and a verified release with a rollback if it fails. Everything else waits for you. Run that for a month, and read the record. Then widen the bound by one category.

That is how software comes alive. One sense, one bound, one category at a time.