/ home / posts / How to rewrite a codebase to a new language

August 15, 2026

Contents

Intro

Several weeks ago, the first sign of Bun being rewritten from Zig to Rust was spotted. Starting as just an experiment before showing curious results, we then finally got the highly awaited blog post. In the past, rewriting a codebase was a sign of either a bad design decision made in the beginning, or, a non-productive nerd snipe. Today, the implied cost of engineering hours towards a rewrite is more affordable in tokens.

What we’re doing

Since rewriting a codebase should be doable now, how do we go about a large autonomous refactor? To show by example, we will be rewriting jq in Odin with ChatGPT 5.6 Luna.

What is jq?

jq is a CLI that's both simple and powerful for handling JSON. It supports both elegant querying as well as defining reusable functions.

What is Odin?

Odin is modern general purpose compiled language that has not yet gotten as much buzz as Zig has. There are already Go and Rust implementations of jq hence picking an underappreciated language.

Why we can do this

jq has a language agnostic test suite which matches the same template as Bun.

graph LR; subgraph Verification ["Test suite"] test_suite["Written to validate the app, not code"] end subgraph Application ["Codebase"] application["Written in some language"] end Verification--"Validates"-->Application

In non-technical terms, this is like defining a word in the dictionary without using the word in that sentence. Regardless of the specific language used, the purpose of the verifier (the test suite in the case of Bun or jq) is to give a strict thumbs up or down for some given code being “correct”.

graph LR; subgraph Verification ["Test suite"] test_suite["Written to validate the app, not code"] end subgraph ValidApplication ["Working codebase"] application["Written in some language"] end subgraph InvalidApplication ["Not working codebase"] application2["Written in some language"] end Verification--"Looks good 👍"-->ValidApplication Verification--"Not good 👎"-->InvalidApplication

Note: It doesn’t matter whether or not the codebase was generated or artisanally written by a person, the purpose of the verification is the “good” or “not good”. If you’re on a team with a robust CI/CD, then seeing all green on a pull request is fair grounds for an “LGTM” and approval. Whether you view that as being a good or bad thing, the level of confidence in the result is what matters.

Where to start

Like how you could ask an LLM to prepare a local coding environment (fetching files, installing dependencies), you can ask the LLM to plan a larger codebase refactor before proceeding. Below is my summary of some LLM output on things about Odin that would be useful to know in advance of rewriting a C project.

Preparing the engine

Since we’re going to have a flexible number of agents working in parallel, we will also prompt the initial setup to have multiple files that prevent merge conflicts.

Authentication

For this project, I used Vers VMs which basically give you git operations but for computers. First, create an authenticated Codex snapshot that we can restore for ephemeral agents. Authenticating a VM with Codex is as simple as going through the Device Code flow. After you’ve gotten the computer logged in to Codex, make a commit of that VM, and you’ll now be able to restore as many new VMs from this snapshot with your OpenAI account already signed in!

Aside from the security of delegating work to separate sandboxes or the space saved on my local laptop, Codex seems to have a limit of four parallel worktree agents on a given machine. Orchestrating these cloud computers was what allowed me to work on this in the timeframe I did.

Environment

After this first setup, we need some simple plumbing such as GitHub PAT and preparing the Codex instance to be cloned when handling new prompts. After some basic branch protections, every PR would be reviewed by a short-lived agent (leaning on the point from the Bun blog post where an agent owning the PR would want for their changes to be merged whereas a blank review agent tends to be more unbiased)

graph LR; subgraph Local ["Long lived agent"] LocalAgent["Locally running agent"] end subgraph Implement ["Short lived agent"] ShortLived1["Implementation agent #1"] end subgraph Implement2 ["Short lived agent"] ShortLived2["Implementation agent #2"] end subgraph Review ["Short lived agent"] ShortLived3["Review agent #1"] end Local--"Make change"-->Implement Implement--"Ship feature branch"-->Local Local--"Make change"-->Implement2 Implement2--"Ship feature branch"-->Local Local--"Review"-->Review Review--"Nit or LGTM"-->Local

Author note: GitHub being down at points did cause nuisances and I did migrate some of the review/evaluation to the cloud VMs. The end result of 522 passing tests is still the same.

Going full throttle

“Now rewrite jq into Odin, make no mistakes”

Vibe coding is magical when you can tell a computer to make an app and it does. But, it’s much more useful when you give it the right direction, environment, orchestration, or even input (what are you telling the computer to do?). By lining up each of these in the setup, I’m then able to enter that prompt verbatim and know it should produce a meaningful result.

Results

After a bit more than a week since writing that last sentence in this blog post, I finally got a rewrite of jq into Odin based on their test suite!

https://github.com/yevbar/jq-odin

I reminded ChatGPT at times to get “back on track” or use the cloud VMs instead of the count-limited local worktrees but I didn’t insert myself anywhere relating to the implementation of jq in Odin. As soon as ChatGPT completed the Goal (their version of a loop with Claude), it hid the banner showing the exact amount of time spent but it’s reported to be close to seven days and nine hours.

For the cases strictly covered by the test suite, it gets the job done, however, there’s one caveat with this being a drop-in replacement for jq off the shelf. It strictly covers as much is expected by the test suite, which is only 522 test cases. While this may seem like a lot, test driven development tends to play well with language oriented projects (while I was working on LSD, I had a slew of tests across the stack since there’s a broad surface area for a parser or interpreter).

For functionalities not covered by the test suite but only implemented in the CLI, there’s not a high certainty those capabilities would work in the Odin rewrite as it is. But, knowing agents can recursively improve, it’d likely be a matter of implementation or orchestration to work on this such that the Odin-based jq would eventually have more feature parity.

Conclusions

For gojq and jaq, other implementations of jq in different languages, there was weeks of time in between the start of those projects and their first working releases. While those projects seem to be focused on targeting the jq codebase instead of just the test suite gate, the results here further highlight that agentic coding can dramatically speed up work.

The partial result from the existing test suite alone may contribute to jq’s difficulty on ProgramBench and why there are thousands of “generated behavorial tests”. If you’re wondering whether or not agents can write or rewrite real things, we’re there now. Whether or not agents can complete real things is a different question. It’s less what the team of agents is made of and more a question of what the team of agents is doing, you could have hundreds of “auto-researchers” but it means nothing if they’re as unproductive as a tech company trying out a “flat organization structure”.

Hack the planet!