Self-improving software
An inside the app, requests that point at the exact element, a queue, a flag, a cloud VM that opens the pull request, and a person who says fixed or not quite. What runs today, and where this is going.
Created November 5, 2026 · Updated November 5, 20266 min read8 chaptersBy Chris Johnston
01 · THE LOOP
People use the software. The software gets the note. The next version answers it.
Self-improving software, the way we mean it: the person using the app asks for a change where they see the problem. The request carries the exact element. An does the work on its own machine and opens a pull request. A person merges it, and the person checking says whether it landed.
This is not software deciding what it should become. That idea has its own name, recursive self-improvement. Here, people point and people decide. The do the part in between.
Part of this runs in production today and part does not. Each section below says which. The stack under it: the app on Vercel, the data on Neon, the code on GitHub, the machines on Beam Cloud, the model through OpenRouter.
02 · THE
Inside the app. Inside your role.
The rule: the in the app gets what your role gets, and nothing more. Your Everything App has one permission check. The menu, the route guards, the server actions and the tools all go through it. As an , it can read and draft. It can never approve or change settings, and a send or a delete waits for a person.
Today the check sits at the door. The chat checks your role before it takes the question. Then the reads with its own token, and that token reads the same rows for anyone asking. So we open the cloud worker's chat only to roles that could already read all of it.
Where this is going: the runs as the signed-in person, row by row. A contractor's sees that contractor's jobs. That is in the spec. It is not live in our own app yet.
03 · THE ASK
Anyone on the team can file it.
Owners, admins and staff can all file a request. Type it in the chat, or press Talk and say it. What you ask lands on the Board with the answer beside it. In a call, the sorts what you asked for: a change, a feature, a project, content, or a question.
That matters more than it sounds. The person who hits the problem is rarely the person who can open a ticket, and the detail is gone by the time someone asks them about it. Filing has to take less effort than working around the problem.
04 · THE PICKER
Point at the box. Point at the field.
"The button on the pricing page looks off" costs a round of questions. So signed-in team members get a round button at the bottom right of our live site. Tap it, then tap the parts of the page you mean: a div, an image, an input. Press the up arrow on a hovered element to take the box around it. Paste a screenshot if it helps. Write one line.
The save carries the page, the viewport, the device, the build, and each element's selector, text and position. An can find that element in the code without asking. The panel also lists what is already open on that page, so nobody reports the same thing twice.
Where this is going: today the picker and the chat are two doors. The picker lives on the site, the chat in the admin. The spec merges them: with the chat open, click any row, card or field and it becomes part of your message.
A request that points at the element does not need a meeting.
05 · THE QUEUE
Every request, in one place, with its history.
Each piece of feedback becomes an item on one list: Needs you, Open, Done. One record can hold many items, and every version stays on file. We built it after one note box kept getting overwritten, and the story of what had landed went with it.
An can read the list through a read-only tool. Today, work starts when a person tells an to take it. Nothing leaves the queue by itself.
06 · THE FLAG
Run it now, or let the team look first.
Where this is going. This part is not built. A flag decides how a request leaves the queue.
Flag on: the job starts when the request lands. That suits a typo or a label. Flag off: the team reads the queue together, groups what belongs together, and runs it at the click of a button. That suits anything that touches money, permissions or how people work.
Neither setting skips the merge. The flag decides when the work starts. It does not decide what goes live.
07 · THE MACHINE
A VM wakes, does the work, opens the pull request.
This part is real, started by hand. Our worker sleeps on Beam Cloud. In one test the VM was stopped, one message woke it, and 79 seconds later a pull request was open: one file, two lines, checks green. The full setup is in How we use Beam Cloud.
It is not ready to take the queue alone, and we know why. Its first real build, 17 files, came back with red checks, and the worker could not see them or update its own pull request. That build also shared a box with another test, and a second caller could have wiped its folder. A reel test on a different VM stalled when the gateway under the died.
So the queue needs three things before a flag can start jobs: one machine per job, a worker that can read its own checks, and enough on the box to test what it builds.
08 · THE VERDICT
Fixed, or not quite. Only a person says which.
This is what makes it a loop, and it is live. An can make one move on an item: open to shipped, with a note on what changed and which version holds it. Then a person presses Fixed or Not quite. have no way to press either.
Not quite does not reopen the old item. It starts a new one that follows it, so you can see how many tries an ask has taken. That count tells you where the instructions are weak.
One gap against the video: the goal is that whoever asked gives the verdict. Today it is anyone whose role holds that right, which in our team is usually the person who asked.
