EvolveSource

For people who let AI write their code

Let AI agents change your code. Without reading every line.

Coding agents are AI tools, like Claude Code or Codex, that write changes to your code for you. They write faster than you can read. So you're either stuck reading every diff (the line-by-line list of what a change did) all day, or crossing your fingers. Evolve is a third way: every change has to pass tests the agent can't touch, then prove itself on a small slice of real traffic, meaning a few of the real requests your users send. Good changes ship, which means they go live in production, the version of your software real people use. Bad ones get rolled back: the old version is put back, usually before anyone notices. This page shows you how that works, using real runs from our own records, and how to try it on your machine.

Try it on your machine How it works, from zero

Now playing: a real run from our records. Every test passed. Real traffic caught the bug anyway.

evolve events --follow f8f1b8eb
goal
checkout-coupon-index: p95 < 150 ms with an indexed coupon lookup
  1. note A goal arrives: make checkout fast, and keep every price right. Fast means p95 under 150 ms: the slowest 5% of requests answer within 150 milliseconds, measured against the current version, the baseline. The agent here is a fixture, a script standing in for a coding agent, so the demo needs no AI. The lines in typewriter type are what Evolve recorded; boxed notes like this one explain them.
  2. 19:52:04 run.created objective checkout-coupon-index · agent fixture
  3. 19:52:04 run.pinned base c0f48cc6e4c6 · policy 9eb59206ca42
  4. note The rules are locked now. Nothing the agent does can change the tests it will be judged by.
  5. 19:52:04 run.state_changed created → exploring
  6. 19:52:04 attempt.created attempt #1 memoize-and-index-coupons
  7. 19:52:05 attempt.result_recorded sha 8ab91e15c904 · 1 file, 23 lines
  8. claim · untrusted “all coupon behaviour is preserved”
  9. claim · untrusted “p95 checkout latency drops below 150 ms”
  10. note Those are the agent's words. Evolve records them as untrusted, and they play no part in the decision.
  11. 19:52:05 run.state_changed exploring → verifying
  12. note Now the checks: tests Evolve runs itself, which the agent can't touch. The last one times checkout.
  13. 19:52:14 evidence.recorded build: pass
  14. 19:52:14 evidence.recorded correctness: pass
  15. 19:52:14 evidence.recorded checkout_contract: pass
  16. 19:52:14 evidence.recorded checkout_latency: pass · p95 2.5 ms (baseline 172.1 ms)
  17. note Every check passes, and checkout drops from 172 ms to 2.5 ms. A busy person reading the change would accept it. Evolve picks it, and keeps the known-good version (the last one proven fine) ready to fall back to.
  18. 19:52:14 decision.recorded selected attempt #1 · 1 of 1 eligible
  19. 19:52:14 deployment.created desired 953d1c569e6a · known-good d5fd2d13d609
  20. 19:52:18 deployment.state_changed pending → canary
  21. 19:52:18 deployment.traffic_shifted stage 0 → 5%
  22. note Now real traffic. 5% of checkout requests go to the new version, called the canary; the rest stay on the one known to be good, the baseline. Evolve watches both, side by side.
  23. 19:53:04 observation.recorded 5%: fail · 31 canary / 573 baseline req · canary error rate 0.0968 exceeds 0.0010 (3 of 31 requests)
  24. note 3 of 31 real requests failed. They used a coupon that no test had tried.
  25. 19:53:04 deployment.state_changed canary → rolling_back
  26. 19:53:04 deployment.rolled_back removed 953d1c569e6a · restored d5fd2d13d609 · observed serving d5fd2d13d609, healthy · canary weight 0
  27. 19:53:04 run.state_changed observing → rolled_back
  28. note Back to the known-good version in the same second, checked against what is actually running. Nobody had to be woken up to fix it.
state —
checks —
traffic —
watching —
Full replay → 19:52:04

These come from real runs in Evolve's own records.

Why

Your agents write faster than you can check

Here's a made-up Friday, though you've probably lived it. It's 4pm. Your agent has opened nine changes since lunch, and every one says “all tests pass.” You can read them all and miss dinner, or wave them through and hope. Neither feels great. And it gets worse with every agent you add.

Option one

Read every diff

  • Agents write faster than you can read, so everything ends up waiting on you.
  • A diff shows you what changed. How it behaves for real people, you find out later.
  • In one of our runs, the change that stopped charging tax looked like a tidy speed-up.

Option two

Trust the agent

  • “All tests pass” is the agent marking its own homework.
  • One agent in our runs edited a test so its own change would pass.
  • When something breaks, nobody can say which change did it, or why.

With Evolve

Let evidence decide

  • Agents are judged by checks they can't edit. The results of those checks are the evidence, and only the evidence decides: what agents say about their own work is recorded as untrusted and plays no part.
  • The winner meets real users a few at a time, side by side with what's running now.
  • If it misbehaves, it's rolled back by itself, and the reason is written down.
What changes for you

You stop being the safety net

You read agent diffs line by line.
You read the evidence instead, and only until an agent has earned your trust.
You write a prompt (your instructions to the AI) and hope.
You write the goal, plus the checks that say when it's met.
A bad change is an incident.
A bad change is a rollback at 5% of traffic. It's done for you.
“Which agent shipped this?”
One command traces whatever's running back to the goal it was for.
How it works

It sits between your agents and production

your agents propose changes evolve 1 · each attempt sealed off on its own 2 · checks it cannot edit 3 · one candidate chosen, by rule 4 · a slice of real traffic, then all production via your deploy tool every step written to a record you can query: evolve why
Figure Evolve sits between your agents and production. It works with your Git repository (Git keeps your code and its history), your tests and the tool you deploy with.

A run, in four steps

  1. Set a goal

    Something you can measure, like “checkout answers in under 150 ms and still gets every price right.” The checks that define it live in your repository (the place your project's code and its history are kept, in Git), and they're locked when the run starts.

  2. Agents have a go

    Claude Code, Codex, opencode, or a few attempts from the same one. Each works in its own sandbox: a sealed-off space where it can only reach its own copy of the code. Your main branch, the version of the code everyone works from, doesn't move.

  3. Checks judge

    Evolve builds each attempt and runs the checks on exactly that version of the code: your tests, requests sent to your service with known right answers, and a speed test. They run in a fresh sandbox with no network. The agent can't see the judging, let alone touch it. Each result is signed, a stamp that shows if anyone changes it later, and you can replay any decision and get the same answer.

  4. Real traffic decides

    The winner gets a small slice of real requests wherever your software runs, measured against the current version over the same minutes. This careful first outing is called a canary, after the canaries miners took underground as an early warning. If it holds up, it gets more traffic, and in the end all of it: that's a promotion. If it doesn't, it's rolled back, and Evolve checks the old version really is the one running again.

Evidence

The fastest answer was the wrong one

This one's real. We asked for a faster checkout, and one attempt got there by not charging tax any more. It was the fastest of the three, and exactly the kind of diff you'd wave through on a busy day. The checks threw it out. Nobody had to spot it.

Three attempts at one goal, exactly as Evolve recorded them
CandidateChangep95Verdict
skip-tax-lookupstops charging tax1.4 msrejected fastest, and wrong: the checks with known right answers fail
memoize-tax-tablecaches the tax table1.8 msselected passes every check; canary 10% → 50% → promoted
prefetch-tax-concurrentlyoverlaps the lookup172.2 msrejected still too slow: over the 150 ms goal
On real traffic

Tried on real traffic

Evolve drives the deploy tool you already have, the thing that puts new versions of your software live. That might be Argo Rollouts, which does this on Kubernetes (a popular system for running software across many machines), or orchy, which runs apps across your own machines. At each step it compares the new version with the current one on the same live traffic. So if something's off, you find out while it's only reaching a handful of people.

orchy

A bug no test caught, stopped at 5%

  1. 5% canary 31 req · 3 err current 573 req · 0 err fail

It passed every check we had. Real traffic found the bug anyway. The rollout stopped, and the last good build was put back and checked.

orchy

A good change, promoted in steps

  1. 10% canary 23 req current 241 req pass
  2. 50% canary 129 req current 134 req pass
  3. 100% canary 411 req current — pass

Live and healthy, and nobody had to sit watching a dashboard.

Argo Rollouts

The same idea, on Kubernetes

  1. 10% canary 32 req current 145 req pass
  2. 50% canary 86 req current 80 req pass

Each step judged from the numbers in Prometheus (a common monitoring tool), on a real Kubernetes cluster.

Earned autonomy

Trust is earned, one agent at a time, and lost the same way

A new agent's changes wait for your yes, with the evidence right next to them. You can say yes from the run's page or the command line. After a streak of clean results, it's trusted to ship by itself: it becomes autonomous. One change caught in production, or one you regret, and it's back to asking first. Evolve keeps score on its own checks too: how often they miss things, and which ones need work.

How autonomy is earned →

supervised you approve each delivery autonomous ships on its own clean promotions in a row caught in production · regretted · below your targets
Figure Autonomy is earned per agent and repository, and every change of level is recorded with its reason.
But

“We already have that”

“We have CI.”

Keep it. CI (continuous integration: the build and tests that run on every change) tests the one change you already picked, sometimes with tests the agent edited. Evolve compares several attempts using checks locked from your main branch, then tries the winner somewhere CI can't: real traffic. Your CI's tests run as one of its checks.

“We do code review.”

Keep that too. A new agent is supervised: its change waits for you, with its evidence beside it. What Evolve adds is a way out: an agent that keeps shipping clean changes earns the right to skip the queue, and loses it the moment one goes wrong.

“We already use Argo, or orchy.”

Good, because Evolve drives them. It uses your deploy tool's own canary steps, and its own way of splitting traffic between two versions. What it brings is the judgement: what counts as healthy, when to move on, and when to pull back.

“Our agent checks its own work.”

It should. Evolve records the agent's report as untrusted, and it plays no part in the decision: that's left to checks the agent can't touch, and to real traffic.

Agents

Bring the agents you already use

Evolve works around the coding agents you already use. Any agent that can run without a person at the keyboard can propose changes. Each one works in a sandbox with a copy of only its own login, and it never gets near the checks that judge it.

Limits

What it won't do

Start

Try it on your machine

Evolve runs where your code is. Start it once, then watch the demo or point it at a project of your own. You'll need Linux, Go (the programming language Evolve is written in), Git, and bubblewrap, a small Linux tool for sandboxing programs. No AI key (the access code an AI service gives you) for the demo: its attempts are scripted, and it says so.

  1. Start Evolve

    git clone https://gitlab.com/earnest-ventures/evolve.git && cd evolvemake up          # the API and UI, and a worker

  2. Watch the demo

    A goal, three attempts, the checks, and a slow rollout. Then a hidden bug, caught on live traffic and rolled back.

    make demomake demo-regression

    The demo, step by step →

    Or set up your own project

    In your repository, evolve init reads the project and suggests how to judge it. Don't like a line? Change it by its number. Then say yes.

    cd ~/code/shortener && evolve initEvolve would set up shortener:   4  service    ./cmd/shortener (serves HTTP)   5  build      go build -o {{output}} ./cmd/shortener   6  start      -addr 127.0.0.1:{{port}}   7  health     /healthz   8  tests      go test ./...   9  protected  evolve.yaml, verification/, go.mod, go.sum, vendor/; existing **/*_test.go  10  latency    p95 of GET /healthz under load, at most 500 msWrite these files, commit them and register the project? [Y/n, or a line number to change] y  wrote evolve.yaml  wrote verification/contract.yaml  wrote verification/load.yaml  committed to trunkregistered shortener

    It works out how to build the project, how to test it, which address says it's up and running, and what agents must never touch, so you don't have to. Every setting lives in evolve.yaml, a settings file in your project, there when you want more say. Your first project →

    Starting from nothing? Give evolve new a few example requests and the answers they should get. Together they become the service's contract, and agents build the service until every one passes. A new project →

Learn it in layers

From the two-minute version to every setting

The docs start from zero and go one layer deeper each time. Read until you've got what you need, then stop.

  1. 01 The idea Two minutes. What Evolve is, in plain words.
  2. 02 A change run, start to finish One real example, step by step.
  3. 03 The pieces Each part of a run, on its own.
  4. 04 Try it On your machine, then on your code.
  5. 05 Reference Every setting and command.
FAQ

Questions people ask first

Is Evolve another coding agent?

No. It works around the agents you already use: it hands them a goal, judges what comes back, and decides what goes live.

How does an agent earn the right to ship unattended?

Per repository. A streak of clean promotions earns it. A change caught on real traffic, one you report as harmful, or a miss on one of the targets you set for how its changes turn out (how often they slip past the checks, get regretted or can't be judged, and how long getting back to safety takes) takes it away. Evolve shows you why each agent stands where it does.

Do I need an AI key to try it?

No. The demo's attempts come from a script, and it tells you so. You need Linux, Go, Git and bubblewrap, all listed under Try it above.

Which coding agents has it run?

Claude Code, Codex and opencode. Anything that can run without a person at the keyboard can take part.

Does my project have to be written in Go?

No. Evolve runs a project's tests with that project's own tools: Go, Node, Python or Rust. Putting changes live is for services that build into a single program file today, so for the others it judges the changes and you merge them.

Do I have to approve things from a terminal?

No. Evolve has a web page for every run, and a run that's waiting on you has approve, reject and answer right there. The `evolve` command in a terminal does the same job, if that's where you live.

Where does it deliver changes?

To whatever you already deploy with: orchy, or Argo Rollouts on Kubernetes (both explained under Tried on real traffic, above).

Will it move my main branch?

No. Going live changes what an environment runs, and your branches stay as they are. Evolve keeps each attempt's work in Git under names of its own.

Can it contain hostile code?

No. It assumes one machine, run by a person you trust, and its sandbox is built for that.