Rewriting Prime Agent in Rust

TL;DR Highlight

An agent swarm ported its own TypeScript to Rust, cutting time-to-input about 14x.

Who Should Read

A backend or platform developer who wants to automate large code migrations with coding agents or multi-agent setups

Core Mechanics

2,000+ agents rewrote it in two weeks
- Prime Agent rewrote itself from TypeScript to Rust.
- It ran across 10,000+ Prime Sandboxes and used over 200B tokens from Prime Inference's GLM-5.3 endpoint.
Humans only built the verification
- They built four parity checks: TUI, harness, protocol and feature.
- Each check gave agents an objective way to measure progress and catch regressions before merge.
Four agents handled every task
- The Planner writes the spec and verifier, and the Implementer writes Rust in a dedicated worktree.
- The Reviewer attacks the PR using a different model and context, and the Verifier runs checks in a fresh sandbox.
- Generation and verification are separate because an agent that writes code is biased when judging it.
Hillclimbing ran three days with no numeric target
- They built a benchmark harness and told agents to improve speed and resources without breaking parity.
- A fixed threshold tends to become a stopping point, so they left it out.

Community Reactions

Questions about the four-agent pipeline
- One commenter wanted to know how the Planner → Implementer → Reviewer → Verifier flow was actually implemented.
- Another asked how it could apply to greenfield coding rather than language copies or performance work.
Token cost transparency
- A commenter said a 200B total token number does not help gauge cost.
- They wanted a split into input (cache hit), input (cache miss) and output.
Single binary advantage
- One commenter said Rust rewrites get criticism, but a single copyable binary helps a lot when working with sandboxes.
Question on Prime Agent's edge
- A commenter asked whether it can do anything that regular harnesses with a memory plugin cannot.

How to Apply

Add a differential test to one CLI today
- Pick a CLI you plan to port or refactor and write a script that diffs old and new outputs on the same inputs.
- Give that diff to the agent as its pass criterion.
Separate writer and reviewer agents
- Run the code-writing agent and the review agent on different models and contexts.
- Tell the reviewer prompt explicitly to look for reasons the change is wrong.
Drop numeric targets from perf loops
- Profile first to build a backlog of hypotheses, then benchmark before and after in alternating order on the same environment.
- Set the goal as continued improvement without breaking parity, not a number.

Try It

copy & run

# Paste into Claude Code or ChatGPT (simplified version of the article's reviewer agent)

You are an adversarial code reviewer. Find reasons the change below is wrong. Do not trust the implementer's explanation, look only at the code.

[Original behavior spec]
{{original behavior description or tests}}

[Change diff]
{{PR diff}}

Check the following:
1. Does any behavior differ from the original?
2. Does output differ where it should be identical?
3. Is there a regression on the model-facing interface?

List problems by severity, or answer pass with reasons if there are none.

Next step: run this prompt on a different model from the one that wrote the code and compare the results.

Terminology

ParityA check that the new version gives the same results as the old one for the same inputs. It is like checking a translation against the original.

HillclimbingKeeping only changes that raise the benchmark score and stacking them step by step. It is like climbing a hill one step at a time.

Differential testRunning two implementations on the same input and comparing the outputs side by side. It is like typing the same formula into two calculators.

RSSThe physical memory a process actually occupies. It is like the number of books you have open on your desk.

Finite State MachineA model that describes a workflow with fixed states and transition rules. It is like a traffic light where the current state decides the next step.