ALIVE — Living Technology

Someone builds a useful application. They test it, release it, and it works. For most of the history of software, that is the moment we would call development finished. The application goes on running, but its improvement is something organised around it: a user reports a problem, a developer investigates, a fix is written, a new version is released. Between those moments the software does nothing to help itself. It sits there and waits.

I have come to think that assumption is worth challenging. Why should an application not know when one of its operations has failed? Why should it not notice that it has become slower, or that users keep correcting the same mistake? Why should it not investigate a reported defect, try out a newly available technique, or propose a better version of itself?

Some of this is old. Software has had monitoring, automated tests, recovery and continuous deployment for a long time, and AI invented none of them. What is new is that increasingly capable AI can connect those pieces — observing, interpreting, researching, experimenting, implementing and evaluating — into one flexible, continuing process. Every earlier chapter of this book handed one of those abilities to the person building software. This chapter asks what happens when the software itself is given some of them.

I call the idea Living Technology: software designed not only to be built with intelligence, but to have intelligence involved in its continuing operation, maintenance and development. I mean “living” as a description of how the software is run and kept, not as a claim about biology, consciousness or artificial organisms. And it is an ambition, not a description of software that already exists. The project I have been building towards it, ALIVE, tests one part of that ambition. I will be precise about which part.

Give the product a pulse

The first capability is the simplest: the software should be able to tell how it is doing.

That means watching meaningful signals. How often do operations fail? How long do responses take? Which workflows break, and which dependencies are unavailable? Do users keep correcting the same output? Are there tasks the system repeatedly fails to complete? Is a measure of quality drifting downwards? None of these requires the software to be aware of anything in a human sense. They are signals about its operational health, and a well-built system can not only collect them but explain what they show and where each piece of evidence came from.

Most applications today have some of this, and many have very little. Usually it was added after something went badly wrong. I would rather it were there from the start — a pulse you can take at any time.

A machine that can investigate itself

Once software can tell that something is wrong, the next step is for it to help find out why.

When an operation fails, an intelligent component can read the logs, try to reproduce the failure, identify a likely cause and propose a repair. In a bounded environment, a tested, low-risk correction might one day be applied automatically under an agreed policy; anything more consequential would go to a person for approval. The important change is that diagnosing and correcting software need not always begin with a human programmer opening the source — which is Chapter 15’s argument, turned on the software’s own maintenance.

The same machinery can look beyond faults. A feature may work but be slow. An answer may be right but cost more than it should. A workflow may have been overtaken by a better tool. Users may keep struggling at one point in the interface. A system that can notice those things can propose experiments to address them without waiting for a bug report.

And it can look outward. The AI Frontier Scout from Chapter 17 watches developments for a person. The same idea, built into an application, can watch for new methods, libraries or models relevant to the application’s own purpose, compare them with what it currently uses, and propose a small trial when something looks promising — under the permissions Chapter 20 insisted on, so that a discovery never becomes a licence to install or deploy.

Put together, the cycle looks like this: observe, understand, research, propose, experiment, evaluate — and then keep the change or revert it. It is the book’s loop again, but run by the product rather than around it.

Building ALIVE

ALIVE — Adaptive Living Intelligence — is my attempt to build towards this. Its repository opens with the question that drives it: what if an AI could use the results of yesterday’s work to make better decisions tomorrow?

I wanted it because most AI work evaporates. A conversation ends, and the prompts, decisions, failures, evaluations and useful corrections become hard to find, let alone reuse. Even when a model produces a good result, there is often no reliable record of what it saw, what it did, or whether the result actually helped. ALIVE is a persistent, local-first environment for doing real work with AI that keeps that record: a live model, approved project sources, repeatable workflows, human decisions and retained history in one place.

What it can do is documented, capability by capability, with the level of evidence for each. Persistent workspaces that survive sessions and restarts are established in live use. Conversational research over approved project material, with retained receipts for every model call, has been demonstrated with real calls. Live and pinned project sources are implemented and tested. Chapter and documentation workflows — reviewing work, proposing improvements, retaining the full proposed text and independent assessments — have run live. Versioned runbooks have been exercised end to end on a real journey. Other parts are less mature, and the project says so: model-assisted selection of capabilities is not yet qualified, a newer grouped code-review path has passed tests but not a live acceptance run, and the indexing of real project history is implemented and tested offline but not yet confirmed on real data.

One property matters more than it might seem. In these workflows ALIVE is read-only towards your project’s files. It prepares and retains proposed changes; it does not silently apply them. That is a deliberate boundary, and it tells you something important: ALIVE today is not self-repairing software. It does not monitor and rewrite its own code. What it investigates is a narrower and, I think, more fundamental piece of Living Technology — whether experience can make the next piece of work better.

What the product learns from yesterday

This is where honesty matters most, because it is where it would be easiest to claim too much.

ALIVE retains the results of its work and their evaluations. It can retrieve relevant past experience and supply it to a later task. That has been demonstrated with real model calls. But retaining a result is not learning, retrieving it is not improvement, and supplying it to a later model call does not by itself prove that the next result is better. That sentence is close to how the project’s own documentation puts it, and I hold to it.

The evidence so far is instructive precisely because it is mixed. In one demonstration, a second proposal for improving a document was given the earlier findings explicitly and scored twenty-six out of thirty against twenty for the first, under that evaluator’s rubric. That shows feedback-assisted revision working. It does not show learning from experience, because the experience was handed over by hand. In a later controlled comparison, experience was retrieved and supplied automatically to a live request — and the measured outcome was a tie. No quality advantage.

The most recent work, LEARN-01, builds a policy for deciding when a past lesson should be applied at all. It requires the lesson to be supported by exact quotations from current, approved evidence; it treats selecting no lesson as normal; and it lets a lesson’s standing fall when it is contradicted, so that a measured loss can push a lesson from “unproven” to “rejected”. Those transitions are tested offline, and the mechanism has made one authorised live call. The controlled trial that would show whether applying lessons this way actually improves results is prepared and has not been run.

So, plainly: ALIVE has demonstrated that experience can be kept, found and supplied, under strict controls. It has not yet demonstrated that this makes the work consistently better. That is not a failure of the project. It is the project telling the truth about where it stands — and, I think, a fair picture of where this whole idea stands. The destination is ambitious. The evidence is still being gathered. Both are worth saying out loud.

Living does not mean unstable

The obvious objection to everything in this chapter is that software which keeps changing will stop being reliable. The objection is right to be raised, and the risks are real. A self-modifying system can introduce regressions. It can optimise for the wrong measure and get worse at what people actually need. It can mistake an apparent improvement for a real one. It can keep changing things users wanted left alone. It can grow more expensive, or send information to services that should never have seen it.

The answer is a distinction: continuous improvement does not require continuous uncontrolled change.

A living product keeps a stable working version while it investigates new possibilities. Candidate changes are evaluated against that version, not in isolation. Experiments that do not hold up are rejected; changes that cause regressions are reversed. The product keeps a history of what was tried, what worked and why. Different kinds of change carry different permissions — a cosmetic adjustment is not a data migration — and nothing consequential happens without the authority Chapter 05 required. Above all, a properly governed system can look at every proposal it has generated and decide to change nothing, because none was supported by evidence. ALIVE’s lesson policy makes exactly that choice normal.

None of this guarantees that a system improves for ever. Nothing does. What it does is make sustained, evidence-based improvement possible without sacrificing the usefulness the product already has. Motion is not the goal. Demonstrated improvement is.

Why wouldn’t you build this?

Here is the argument I find hardest to resist.

Imagine a new application with no way to notice that it is getting slower. If watching its own performance is affordable, why leave it blind? Imagine one that records its failures but cannot help investigate them. Why not let it analyse its own evidence? Imagine one that keeps making the same mistake. Why not find out whether a past correction can be kept and applied? Imagine software built around an AI model that will, inevitably, be overtaken. Why not give it a way to discover, test and adopt a better one?

Not every application needs this. A small, stable tool may be perfect as it is. A safety-critical system may need change to be rare, slow and heavily reviewed, and continual adaptation would be the wrong design. My claim is not that every product must improve itself. It is that the range of products for which this is worth doing is widening fast. If we can build technology that helps maintain and improve itself, that capability deserves to be considered from the beginning — not added after everything has started breaking.

Try Machine Coding — Give Your Application a Pulse

You do not need to rebuild ALIVE to start. Take the arcade game from Chapter 13 or the scout from Chapter 17, and give it its first small capacity to watch and improve itself. Neither application has been built for this book, so this exercise is proposed and reports no results; run it on whatever you have built.

Understand its health.

I want this application to help me understand whether it’s working properly. Identify a few meaningful signs of its health — failed operations, responsiveness, the behaviour users actually depend on — and suggest a simple way to watch them.

Record problems.

Add a simple way to record failures and recurring problems, with enough detail to investigate them later. Don’t collect personal data or secrets you don’t need.

Investigate.

Pick a known problem, or create a safe simulated failure. Investigate it, explain the likely cause and propose a fix. Don’t change the published version.

Test the repair.

Make a candidate fix, test the behaviour it affects, and compare it with the current working version. Tell me what the evidence establishes and what it doesn’t.

Look beyond faults.

Now look at the application and suggest one worthwhile improvement that isn’t a bug fix. Explain why it might help, and propose a small experiment that would show whether it does.

Keep the history.

Record the problem, the proposed fix, the experiment, the outcome and my decision. Keep the working version safe. I want this application to build up a history that future work can use.

That is not autonomous self-improvement, and it is not meant to be. It is the first step: maintenance, investigation and improvement beginning to become capabilities of the product rather than chores performed on it from outside.

The technology grows with you

I want to build software that does not simply sit there waiting for me. Software that knows when something has gone wrong, investigates it, proposes a fix, notices when it is getting worse, finds technology that could make it better, tries those possibilities out, keeps what works and lets go of what does not — and remembers enough of all that to make tomorrow’s work better than yesterday’s.

It may still need me. It will need my direction, my judgement, my standards and my understanding of what it is for. But the machinery itself can increasingly help to sustain and improve what we have made. That changes what we should aspire to build. We are no longer limited to producing software and then maintaining it from the outside; we can begin to build the capacity for maintenance and improvement into the software itself. It can grow as its tools grow, and develop as our understanding develops.

The software is no longer merely something we have built. It is something we can keep building with.

That is my ambition, and ALIVE is how I am pursuing it. It need not be yours. The last chapter is about that.