Software is writing itself

A few weeks ago I bought one of those $40 smartwatch development kits, an ESP32 board with a square screen about the size of an Apple Watch face, the kind of thing that normally arrives with a weekend attached to it: the datasheet, the toolchain, and the evening you lose working out why the display will not refresh. I skipped all of that. I told Claude what I wanted the watch to do and it wrote the firmware, flashed the board, redesigned the interface, and kept going every time I asked for something else. At one point I aimed a webcam at the watch face so it could see the screen it had just programmed, and after that it caught its own mistakes and fixed them without being told. I never read a line of the code. Not to check it, not to fix it, not once. You do not have to be able to read code for this to work, and that is the whole reason this reaches past the people who write software for a living.

What I was holding by then was less a product than a piece of hardware waiting to be told what it was, and I have been chewing on that ever since.

We talk about AI that writes code as though that were the whole story. That is part of it. What changes your relationship with a computer is not that somebody can generate a program faster than they used to. It is that the program in front of you can be rewritten while you are using it, by you, by saying what you want rather than building it. More settings will not get you there and neither will a chat box in the corner. The software itself has to be able to change.

The gap between what software does and what you want

Today, software arrives finished. Somebody decides what features it should have, where each button goes and what it does, and ships those decisions to you along with everybody else. You can change a setting, pick a theme, and move a panel around, but you cannot add a feature that was never part of the plan. Anyone who has thought “I wish this app would just do this one extra thing” has run into that limit, and it has always ended one of two ways. Either enough other people wanted the same thing that the company eventually built it, or you worked around it for years and stopped noticing you were working around it.

The reason is effort and cost. Saying what you want takes a sentence. Building it takes somebody with the skill and the time to do it, and most of these problems are too specific to your situation or your setup to be worth the cost of fixing. That is the part AI changes. Turning a description into working software is now cheap enough to be worth doing for one person, and that person can do it themselves.

A goal instead of a method

I also run my own AI models on an older M1 Mac, as a hobby. It answers questions, writes code, transcribes audio, and generates images and video, and because it is my own computer the only running cost is electricity. Almost every new model and every new release targets the newer Apple chips, when it targets Apple at all, so what everybody ships is not tuned to the hardware I happen to own. In the past that would have meant waiting for somebody else to do the work and share it with the community, living with it being slow, or learning enough low-level code to do it myself.

Instead I gave an agent a goal: make this model run as fast as it can on this machine. It works as a loop. Make a change, measure it, keep what helps, throw away what does not, and go again. It runs on its own around the clock, while I am asleep and while I am doing something else, and it works on the whole stack, from the server that hosts the model down into parts of the model itself, writing custom kernels and low-level C to tune the thing to my particular hardware. I do not micromanage the work. I tell it what I want to be true at the end.

The wins are narrow rather than general, because speed is not one number. How fast a model starts answering and how fast it keeps going are separate problems with separate fixes, and the work that helps one model often does nothing at all for the next. The engine underneath is DwarfStar, a C inference engine written by Salvatore Sanfilippo, who also wrote Redis and who spends a good deal of his time in public working out what software becomes when writing it stops being the slow part. My best result so far was on GLM 5.2, which ended up serving tokens about four times as fast once it got going, and producing its first answer after a cold start in about two thirds the time. Those numbers describe one model on one machine, which is the point. I may well be the only person who wanted that particular setup to be fast, and it no longer matters whether anybody else ever gets around to supporting it.

None of the individual steps are exotic. The agent forms a theory about why one version is slower than another, changes one thing, runs the benchmark, and reads the number. What makes it work is not cleverness, it is patience. Doing this properly takes dozens or hundreds of small experiments, most of which lead nowhere, and no person is going to sit through that, least of all me. The agent will. It runs the four hundredth experiment with the same care as the first. That is what changed. Not that the models got wise about memory layouts, but that intelligence got cheap enough to spend on a search that would have been absurd two years ago. Point it at a standing goal instead of a single request, keep this as fast as it can be without making the machine unstable, and it will keep going without you.

Software that adds features to itself

This is not only a hobbyist pattern. On August 13, DeepSeek published Harness, an open-source agent runtime, under an MIT license. It collected more than 90,000 GitHub stars in its first day, which tells you how many people were waiting for something like it.

What is different about Harness is that it can replace pieces of itself while it is running, and its architecture exists to make that safe. Its components, the screen you are looking at included, can be pulled out and swapped without stopping the program, and every change is recorded, so one that turns out badly can be rolled back instead of left in your install. The problem it is built to solve is how a program keeps rebuilding itself while you are still using it.

So you tell the software what you want it to do, in ordinary words. Put this on the settings screen. Show me the models this way instead. Remember what I picked last time and start there. It writes that, loads it, and hands the program back to you with the feature in it, running.

People are doing this already. There is a public list of plugins users have written for it, and a good share of them change the interface itself, which is the part software has always asked you to accept as given. The catalog is a habit we brought with us, because catalogs are how we have always found software, and it matters a little less every month now that you can ask for the feature instead of going to look for it. It will not disappear. There is still satisfaction in showing people what you built.

Harness happens to be a tool for writing code, which is where this shows up first, because the people building these systems are the people who most want them, but nothing about the mechanism is particular to code.

We call software personalized today when it recommends different songs or reorders a feed. Underneath, your copy and my copy are the same program. That stops being true once the program can add to itself. My machine will accumulate tools for video work, local models, and hardware experiments. Yours will accumulate tools for accounting, research, or photography. After a year the two installations hold different capabilities, not only different files, and there is no version number that describes either one.

Security teams assumed they knew what the software was

A watch on my desk and a model server in my house are one person taking a risk with their own machine. Inside a company the same capability lands on a security team that has assumed for decades that it knows what the software is. A vendor releases version 4.2. Somebody reviews 4.2. IT approves 4.2 and puts it on the list of programs employees are allowed to install. From there the team knows roughly what that program can reach and what it can do.

None of that survives software that rewrites parts of itself after installation, adds a tool because a task seemed to call for one, or opens a connection to a service nobody approved. An approved list assumes a program is a single thing. Once every install has been shaped by the person using it, the version on the label describes very little, and the copy that was reviewed is not the copy running an hour later. Most of that change is not an attack at all. It is people telling their software what they want it to do, which is the entire point of it, and it still leaves a company unable to say what is running on its own machines.

Then there are the attacks, including a new class aimed at exactly this behavior. Prompt injection is one: text arriving inside a document, a webpage, or a support ticket gets read as an instruction, and the model follows it. Jailbreaking is another. Ryle Goehausen on our engineering team published two measurements this month, on what a system prompt is worth as a security control and on how the 2026 frontier models hold up against attacks you can script. Even the top frontier models, trained specifically to refuse this, give way, and a rule in the system prompt telling the model to ignore such text does not hold. Defenses will get better and the attacks will move, the way they always have.

Injection is an important class of attack and defending against it is real work. It also sits inside a larger set of questions companies are only starting to ask. What is an agent allowed to do at all. Who decides that, and is there a person it is acting for. Does it get to reach every system and every file its account can see. Does it get to write itself a new tool, and does anybody find out. Those have to be answered whether or not somebody is attacking you, because most of what an agent does wrong, it does while following instructions.

Constraints have to come from outside

The answer is not to stop the software from changing. It is to decide what it is allowed to do, and to put that decision somewhere the software cannot rewrite. That is what Gate is for. Anything an agent does, it does by asking a model, so every request leaves by the same path, and Gate sits on that path rather than inside the program making the request. Whatever the software changes about itself, the rules it meets on the way out do not move.

Two kinds of constraint matter here. One is protection from the outside. An instruction hidden in a document gets caught while the request is in transit rather than after the model has acted on it, and credentials and personal data get stripped before they leave. The other is bounds on software that is doing exactly what you asked. Which models it can use, which tools and services it can reach, what it may do before a person signs off, and how much it can spend. Those hold whether the request came from you, from a plugin the agent wrote for itself last week, or from somebody who should not be in the loop at all.

Cost is the part people notice first, and it belongs in the same layer. A loop that runs all night is a loop spending tokens all night. The path that enforces the rules is also the place a request can be made smaller before it goes out, by compressing the prompt and by not sending a model the same context it already has, over and over. That is 20% or more off the bill with nobody changing how they work.

Because everything passes through one place, there is also a record of what was asked and what was allowed, kept outside the software it describes. Nothing that can rewrite itself should be the only witness to what it did.

That is what we meant by an accountability layer when we launched Gate. It holds the rules steady while everything above them changes, which is what lets the software keep adapting without a company losing track of what it is running.

Software becomes personal

I do not think this future turns everyone into a programmer. I think programming becomes less visible. People will still build operating systems, chips, models, and applications. More of the software between those foundations and the person using them will be made at the moment it is needed, by the machine, on request.

You will buy a device and shape what it does by describing it. You will install an application and teach it how your work differs from everybody else’s. You will give a system a goal and let it invent the workflows, the connections, and the small pieces of code needed to reach it. Software stops being a finished object and becomes a starting point.

Once a computer can understand what you want, write the code, test it, look at the result, and try again, the pressure to make software adaptive is enormous, and nothing about the last two years suggests it lets up. Software will write itself. The harder question is what we let it change, and what we hold still while it does.