We sped up bun by 100x

Rather than start with the theory behind the "swarming", we'll share how to code cannon yourself, describe how our zig rewrite of git went, and then dive into some of our theory behind why this works.

$ curl -fsSL https://raw.githubusercontent.com/hdresearch/vers-cli/main/install.sh | sh

After you've installed it, log in.

$ vers login

Now you have a working vers CLI ready to prepare your swarm infrastructure.

Configure environment variables

With the vers CLI you can define environment variables which get injected to all the VMs you create, making authentication for some CLIs a breeze. Here we'll walk through the environment variables we included for this project.

We configured it to have access to only the repos we're interested in code cannoning at for this project. Our rationale being we don't want one or multiple agents to get creative and start integrating other projects that aren't relevant. Once you have that API key then set it like so:

$ vers env set GITHUB_API_KEY github_pat_...

Next, from the vers dashboard click on the API Keys tab and create a new API key. After you've written it down someplace you won't lose it, you can set it to your environment variables (so an agent running in a VM would be able to on its own spawn further agents).

$ vers env set VERS_API_KEY abc123...

Finally, since we've been driving this using Claude, let's set an ANTHROPIC_API_KEY so any coding agent running in a VM works out of the box.

$ vers env set ANTHROPIC_API_KEY sk-ant-...

Write your initial plan

We've shared the plan.md file we used for the zig rewrite of git, you're welcome to copy it and tweak for your project. Once you have it written, simply point your coding agent at it.

$ pi "Read plan.md and let me know when I can quit this session"

The prompt specifies that contributing agents should be spun up in VMs so you can close your laptop and know things are still progressing.

Let it start running

Eventually pi or your coding agent will tell you agents are working and you're good to quit the session. Congrats, you've successfully created a code cannon to work on some problem.

Check where it's at

Regardless of the size of the project, since there may be small features or nits you'd like to include anyways, it's good to check in after agents began working to verify what it is they're working on. If you find yourself glossing over the agent descriptions and more crossing your fingers than walking away knowing your progress, you've likely depended on the agents too much for your goal.

Repeat running and checking in

We found it useful to check in on the swarm similar to checking in with a team during standup but on an admittedly more frequent basis. Rather than provide a prompt to scale up/down the swarm after certain checkpoints, being more hands-on with steering allowed us to also get a clearer understanding of the scope of this project as well.

How we rewrote git in zig

Anthropic took a stab at rewriting the C compiler and Cursor took a stab at rewriting a web browser. It's not that hard for you to do the same and here's how we went about rewriting a big open source project with the help of agents!

Environment

The Vers VMs spawned had the environment variables injected at startup (so running pi with instructions will always work).

ANTHROPIC_API_KEY: For the LLM powering the coding agent

VERS_API_KEY: For further orchestration

GITHUB_API_KEY: A strictly scoped API key for just one repository

The initial plan

Below was literally the one markdown file used for the original agent to spin up a swarm.

The goal is to make a modern version control software like git or jj but written in zig ALL SYSTEMS AND AGENTS MUST use this github -> https://github.com/hdresearch/ziggit.git For each of the below goals, create a VM and run code like the following

while true do
pi -run "GOAL"
end

NOTE - pi is running on the VM itself rather than running on the host machine and then ssh'ing commands. This should be done so we can quit this pi session So agents are just infinitely running since there is always something to improve in a piece of software. Include pi-vers extension so each infinite loop can provision further VMs or agents.

• first person like jj but does not have a jj git subcommand and instead is drop in replaceable with git so ziggit checkout not ziggit git checkout
• feature compatibility with git (copy over test suite from git source)
• can compile to webassembly
• can yield performance improvements to oven-sh/bun codebase by using directly with zig integration instead of libgit2 or git cli Maybe wait for some progress before starting on replacing bun's usage of the git cli (which they use over libgit2 for performance reasons, our suspicion is that a modern solution in zig could be better). Every VM should have the env vars VERS_API_KEY, ANTHROPIC_API_KEY, GITHUB_API_KEY. Also use the hdresearch/bun fork with changes so a real PR can be created pointing at oven-sh/bun BUT DO NOT MAKE THIS PR YOURSELF. Provide instructions for a person to validate the benchmark results with ziggit usage first

We copied over the plan.md used for firebird and the -run argument is not a real argument, the correct one is -p but the top-level agent figures it out anyways.

The produced agent loop

From the markdown plan, our local pi agent created a golden image for the VMs working on the ziggit codebase to use and configured each agent to have different git commit authors so progress would be identifiable.

Every agent additionally got a /root/prompt.txt file with that agent's specific prompt. The agent tasked with covering git's test suite would have that file populated with contents like "You are the CORE agent. Run git's test suite and fix CLI bugs." and the agent tasked with improving certain git index functionality would have that file with contents like "You are the NET-SMART agent. Rewrite idx_writer.zig to be 10x faster.".

Finally, every VM runs the exact same bash loop encompassing the coding agent itself as well as the git cleanups referenced earlier. The below was generated by the top-level pi agent orchestrating these coding processes in VMs for how to define a given agent.

#!/bin/bash set -a; source /etc/environment 2>/dev/null; set +a export HOME=/root export NODE_OPTIONS="--max-old-space-size=256" cd /root/myproject || exit 1 while true; do echo "$(date): === Starting agent run ==="

1. SYNC — save dirty work, pull latest from other agents

git add -A git diff --cached --quiet || git commit -m "auto-save before sync" git fetch origin master git rebase origin/master || { git rebase --abort git reset --hard origin/master # nuclear option on conflicts }

2. BUILD — rebuild the project

zig build # or whatever your build command is

3. RUN PI — the actual agent work

pi --no-session -p "$(cat /root/prompt.txt)"

4. PUSH — commit and push whatever pi did

git add -A git diff --cached --quiet || git commit -m "auto-save after pi run" for attempt in 1 2 3; do git pull --rebase origin master || { git rebase --abort git reset --hard origin/master } git push origin master && break sleep 5 done sleep 10 done

It executes every loop by saving work from the prior loop run, pulling in latest changes, rebuilding the project, running the pi agent, and then repeating the same git operations at the end with also pushing. The agent prompts themselves also mention to use git operations for auditability but these git failguards around the agent itself help ensure the agent loop doesn't get stuck along the way.

Meta note

To reiterate a point at the end of a another section, the sub-agents aren't doing anything differently from if you were to be manually starting new agents with their respective prompts yourself. These shouldn't be doing anything you can't directly understand, whenever we found ourselves starting with an initial research goal (ie understanding a point of integration before beginning new loops) and letting the agent