Self-Improving AI Agents Will Reduce the Code You Ship
Updated
- Self-Improving Agents
- Tools
- Architecture
I gave an agent one sentence and went to get coffee. Five minutes and fifty-six seconds later a finished brief was in Slack. It pulled the data, ran the statistics, wrote the analysis, and scored its own work. Nothing was wired ahead of time: no pipeline, no deploy, no dependencies installed in advance. You can read every script it wrote and run them yourself. Run it a second time and the second pass starts ahead of the first, because it kept what it learned. Below is the whole run, then why it changes what we ship.
The run, in numbers #
From one message, the agent ran eight data fetches in parallel: prices, news, macro, filings, options, pulling 2,428 rows across 27 tickers. It wrote and executed statistical scripts on the fly to test for cointegration, finding 19 linked pairs. It applied two schema migrations to its database to store the results. It wrote eleven memory records and added twenty edges to a knowledge graph. One model drafted a five-point brief, a second model scored it against a rubric, and the agent posted the result.
Elapsed time: five minutes, fifty-six seconds. No dependencies were pre-installed. The self-critic scored the result 4.4 out of 5, ASML cointegrated with 7 of the 10 other semiconductor names in the run, and the strongest pair, ASML and LRCX, came in at p = 0.0006.
Run it twice. The second pass reads what the first one stored, the nineteen pairs and their p-values, and reasons from there. Each script declares its own dependencies inline and runs with one command. The first run does the discovery from scratch. After that, every run inherits it.
You have built every piece of this #
The run has five parts, all of them familiar.
- Just-in-time code is the build step you script by hand. The agent writes a single-file Python script with its dependencies declared inline, the PEP 723 format your own tools already read, runs it once, and keeps it. You can open the file, read it, run it, and diff it.
- Skills are a shared library, or a team runbook. A skill is a procedure someone wrote down once so it gets reused. The agent pulls one in when the task calls for it, the same way you import a module instead of rewriting it.
- The agent harness is the thing you run every time you open a coding agent. It is the loop that puts a model in the decision seat: it picks the next step, calls tools, runs commands, reads the result, retries what fails, and stops when the work is done. Claude Code and the Codex CLI are harnesses. The same loop, pointed at a reporting task instead of a repository, ran this brief.
- Persistence is your data warehouse, with a search index on top. The work product is rows in Postgres with vector and full-text indexes, queryable, rather than log output you grep later. The graph work is PageRank and community detection, decades-old algorithms.
- Memory and context is a cache that survives restarts, plus a graph you can query. The agent writes structured memory and graph edges, so the next run reads what past runs stored and reasons over it.
None of these parts is new; they are ETL jobs, search backends, and CI checks. What the agent adds is the assembly, in one conversation.
The run needed no deploy #
We deploy software to hold a decision still. You write the logic, freeze it into an artifact, version it, and ship it, and it runs the same way until someone deploys the next version. Git, continuous integration, semantic versioning, the release train, the rollback plan. That apparatus exists because, until now, behavior could not be produced on demand. It had to be written ahead of time and pinned in place, and the deploy is the moment you pin it.
An agent that improves across runs never pins it. The logic gets written when the task arrives, runs once, and is kept only if it earns its place. What persists between runs is the memory and the judgment; the code gets regenerated. So the durable, versioned thing is the experience, and the code is disposable.
Today we version the artifact and throw the reasoning away. The reasoning ends up in a pull-request description nobody reopens, a chat thread, or someone’s head. The agent keeps the reasoning and regenerates the artifact. We have been versioning the wrong layer.
Some software should stay frozen. Anything where being wrong is expensive keeps its artifact: the system of record that moves money, the safety-critical path, anything audited or regulated. There you want the version, the immutability, and the rollback. The long tail is everything else. The internal dashboard, the weekly export, the reconciliation script, the admin panel, the integration shim between two products that each assumed they were the center of the world. Expensive to build, more expensive to maintain, holding almost no judgment, and given a team regardless.
That work gets written per request and thrown away, the way the brief above was. Instead of getting a better framework, it stops getting built.
Most software is JSON with a commute #
A request comes in carrying JSON. You validate it, rename a few fields, look something up in a database, attach the result, maybe call another service that hands back more JSON, reshape that, and send JSON back out. The data went on a short trip, changed clothes twice, and came home. We call this a backend.
Strip the resume language and most line-of-business software is three things: a database, an API in front of it, and a layer of small transformations in the middle. It is CRUD with opinions. The opinions are real, a return is not a refund and a draft is not a published post, but they are thin, and they sit under a large amount of equipment. A migration tool. A serialization library. A validation layer. A retry policy. An object-relational mapper whose job is to turn rows into objects and back, which is to say to undo a problem we created by keeping two representations of the same thing. A queue so the JSON can wait its turn. We staffed all of it.
The agent does not need the rule written ahead of time. The database stays, because state is real and someone has to hold it. What thins out is the middle: the endpoint per shape, the adapter per integration, the transform per report, the service whose entire job is to stand between two other services and translate. Ask for what you want, get the current answer, with the agent remembering last time’s edge cases instead of you encoding them into a validator nobody will reread. The JSON still moves. It just stops needing a staffed terminal at every stop on the route.
Put uncomfortably, a meaningful share of backend engineering has been highly paid people building elaborate, well-tested, observable machinery to move a JSON object three feet to the left. That part does not survive contact with this.
You still own correctness #
The multi-week project collapses into one conversation: scope the work, write the code, define the schema, wire the schedule, produce the result. The agent does the assembly. You supply the intent and judge the output. The statistics can be wrong, the migration can be bad, the brief can overclaim, so the scoring critic and your own review still matter.
Start small. Point an agent at a reporting task you understand cold, the kind of internal tool that has lived on a backlog for a year. Let it write and keep its own scripts. Then check whether its second run beats its first; that is the test.
The companion print-ready PDF carries the full run: the pipeline shape, the cointegration p-value matrix across the semiconductor and mag-7 names, the call/put open-interest ratio across the universe, the just-in-time script the agent wrote, and a 60-day normalized close-price ribbon for NVDA, ASML, TSM, and SMH.
PDF: Self-improving agents field note (7 pages)
Tomorrow’s run starts where this one stopped, and the code it wrote today is already disposable.
Building something similar? Reach out on LinkedIn.
Persistent memory still needs a process for deciding what to keep. ERPAVal’s compound phase puts that decision behind an explicit review step.