Self-evolving software

Let’s imagine there is an agent whose identity is to be the software, a CLI tool or any other form of it. If you ask it to do something and the feature does not exist, it builds it, verifies it and tests it according to the project standards. It can fix itself if it runs into a bug, it can clean up its own code, and if another system it relies on changes, it modifies its internal logic to adapt.

How is it different from my coding agent building something on the fly? The maintenance, code standards, workflows and procedures can be different in each codebase. And the tool’s own agent cares about this specific tool, and when somebody cares, it shows. Building the tool on the fly also distracts my coding agent from the task it is trying to do. Its attention should be solely on the actual task, and if it needs a tool feature, it just requests it from the tool’s agent. That way the tool takes complexity off the agent or the human that uses it. This is how humans operate, btw.

It just builds itself. It knows its own purpose, its existing features, past failures, its identity to be this thing. It learns from the usage and can optimize its code.

So, this was an idea, let’s see if it works.

I always wanted to give agents an easier time using other websites, with an interface they understand and like, which is a CLI (text/JSON only). So what if a CLI interface for your website could build itself? Let’s start with something we all know, X (Twitter).

After putting those ideas together we have a CLI tool that reads X from your own signed-in account. It started with no commands at all. You ask for what you need in plain words, agents build the command, and from then on it is plain code, no model and no tokens. x-cli on GitHub

$ x request "posts matching a search, newest first"
request R-0001 filed

$ x request:status R-0001 --wait
R-0001 · building (check) · posts:search
  ✓ intake   3m
  ✓ explore  8m
  ✓ spec     34s
  ✓ write    1m
  ▸ check    9m · review 2 · checker (gpt-6.1-sol)
R-0001: done

$ x posts:search --query "from:NASA" --limit 1
NASA @NASA · 2026-10-16 19:42
The aircraft lineup just keeps getting bigger. ✈️ MAX POWER, a new aerospace expo...
  142 replies · 209 reposts · 1525 likes · 355.3K views

The first call files a request, agents build posts:search, and the next call just runs it.

It all happens async. You can see the requests in progress, all running in parallel, each one follows its internal workflow, and when it is done it is merged back. All built on agentswf, which I wrote about in Deterministic workflows for coding agents.

After using x-cli for a while, it feels a bit slow at adding new features, but this is because you don’t see everything that is going on internally. And most likely another agent will be requesting those features, and it has lots of patience.

avoiding slop

Ok, it works. But how do you keep it from turning into a huge mess full of contradictions? With a proper process for adding features, where code review and analyzing requirements happen every time, not maybe. Real creators think about their creations day and night and keep cleaning them up. Agents write code once and move on, but give them instructions on how to keep things together and they do a better job.

Here is how x-cli builds a new op (what it calls a command). Intake decides if it should be built at all, explore looks at how X serves the data in a real browser, spec writes what done looks like, then the op is written and its examples are run. A model from another vendor reviews it on the live site, and it keeps revising as long as each round gets further. If it gets stuck, a stronger model takes over, and only then is a person asked. Then it is merged, as one commit.

Repairs go the same way, which matters a lot for a website-to-CLI tool, because websites change all the time. When an op fails and it is the op’s fault (not a sign-out or a rate limit), it saves what it saw (screenshot, page snapshot, network calls, recent history) and files a repair request on its own. The calling agent gets a request id, waits for the fix, and the call just runs again.

All of it is tunable: make it faster, add more checks, swap the model for each step. This is what engineers should focus on more, “building the thing that builds the thing”. Is it perfect? No, it is just a start, and I will be writing more about workflow optimization.

I can imagine templates for different types of apps (like website-to-CLI) that you just adapt to your needs, instead of building from scratch. With a clear structure and a defined workflow for adding features, the agent repeats existing patterns, and that takes fewer tokens.

a new category

x-cli is just one example. The same idea can be extended, so the software learns from the usage, optimizes its own code, and does the other things I imagined at the start.

Take apps someone builds from scratch with a few prompts. Some of them work, but testing and polishing them takes time, and when starting one was that easy, it is unlikely anyone stays motivated to keep tweaking it. What if people just used the app, and the improvements came naturally?

This can be a new category of software, one that evolves on its own around what its users actually need. Like a baby that is born with all the capabilities to grow into an adult within the current culture and family.