DEV Community: Yusuke Endoh

Quine Clique: 51 programs in 51 languages that all print each other

Yusuke Endoh — Tue, 01 Sep 2026 18:53:02 +0000

A quine is a program that prints itself. And a multiquine is a set of programs that print themselves and each other.

I have created Quine Clique, which is a 51-language multiquine:

Here is the video explanation:

The repository is here:

mame / quine-clique

51 quines in 51 languages, every one able to print every other

Quine Clique

qc.rb is a quine written in Ruby: a program that prints itself Ask it for Python, and it prints a Python quine instead Or a JavaScript quine. Or a Rust quine. Or a C quine. Or any of 50 languages in all.

Every one of those quines can do the same: all of them can generate each other. A clique of quines.

▶ Video explanation (9 min)

Quine Clique 101

Ruby Quine

Here is qc.rb:

This is a Ruby program. It is a quine. Run it, and it prints itself.

$ ruby qc.rb > out.bin
$ diff -s qc.rb out.bin
Files qc.rb and out.bin are identical

Ruby → Python

Run qc.rb with the argument py, and it prints a quine written in Python.

$ ruby qc.rb py > qc.py

Let's run it.

$ python3 qc.py > out.bin
$ diff -s qc.py out.bin
Files qc.py and

…

View on GitHub

What is Quine Clique?

Let me walk you through it.

The Ruby quine: qc.rb

First, this is qc.rb, which is the Ruby member of the Quine Clique.

It is a quine written in Ruby. That is, it prints itself when you run it.

# The output of qc.rb is identical to qc.rb itself
$ ruby qc.rb > out.bin
$ diff -s qc.rb out.bin
Files qc.rb and out.bin are identical

Ruby → Python

It is not just a quine. Run ruby qc.rb py, and it prints a Python program, qc.py.

# qc.rb can print qc.py
$ ruby qc.rb py > qc.py

And that Python program is a quine.

# The output of qc.py is identical to qc.py itself
$ python3 qc.py > out.bin
$ diff -s qc.py out.bin
Files qc.py and out.bin are identical

Ruby ↔ Python

Run python3 qc.py rb, and it prints the original Ruby program, qc.rb.

# qc.py can print qc.rb
$ python3 qc.py rb > out.bin
$ diff -s qc.rb out.bin
Files qc.rb and out.bin are identical

So qc.rb and qc.py are each a quine, and they can regenerate each other when you tell them which language you want.

This is a multiquine of two languages, Ruby and Python.

+ JavaScript

That is not the end of it. JavaScript is supported too.

Run ruby qc.rb js, and it prints a JavaScript quine, qc.js. Run node qc.js and it prints itself; run node qc.js rb and it prints the original qc.rb.

# qc.rb can print qc.js
$ ruby qc.rb js > qc.js

# The output of qc.js is identical to qc.js itself
$ node qc.js > out.bin
$ diff -s qc.js out.bin
Files qc.js and out.bin are identical

And qc.js and qc.py can print each other as well.

# qc.js can print qc.py
$ node qc.js py > out.bin
$ diff -s qc.py out.bin
Files qc.py and out.bin are identical

# qc.py can print qc.js
$ python3 qc.py js > out.bin
$ diff -s qc.js out.bin
Files qc.js and out.bin are identical

50 + 1 languages in total

In the same way, it supports Rust, Go, TypeScript, C, C++, Objective-C, C#, Java, Kotlin, Swift, Zig, Lua, R, Perl, PHP, Haskell, OCaml, Standard ML, Scala, Haxe, Groovy, Clojure, Erlang, Elixir, F#, Racket, Scheme, Common Lisp, Prolog, D, Nim, Crystal, Vala, Pascal, Fortran, Forth, Octave, Tcl, AWK, Bash, CoffeeScript, Pike, and PostScript.

Notably, it also supports five esoteric languages: brainfuck, Piet, Befunge, Whitespace, and Unlambda. Getting all of these to run at a realistic size and in a realistic time is quite something -- if you know, you know.

The sizes and running times look like this.

Size: the smallest is qc.rb at 17 KB. The largest is Piet (qc.piet.gif) at 5.3 MB.
Time: the slowest is Bash → Piet at about 7 minutes, followed by Piet → Piet at 4 minutes.

Anyway, we now have a 50-language multiquine (51 if you count Ruby itself): programs that can all print one another. All 51 x 51 = 2,601 combinations are tested on GitHub Actions.

How it works

Let me explain how it is implemented. The key is QCLang, a minimal language made for Quine Clique.

QCLang in a nutshell

It is a very simple language. Or maybe it is better to call it a VM. The only operation is subtraction, the only control structure is a loop, and the only storage is an accumulator and eight registers.

Instruction	Meaning
`!.../`	print `...` verbatim (`H` is the escape; `Hx` prints the character `x` - 33)
`&`	read one character from its own source into the accumulator
`(...)`	loop while the accumulator is non-zero
`*`	print the accumulator as a character code
`0`..`7`	store the accumulator into a register
`8`..`?`	load a register into the accumulator
`@`..`G`	subtract a register from the accumulator
`H`..`~`	set the accumulator to an immediate (the character code of the instruction)

It is this simple so that an interpreter for QCLang can be written in a great many languages.

A quine in QCLang

QCLang is specialized for writing quines, so a quine takes only these five characters.

&(*&)

& reads one byte of the source itself, and (...) loops. Inside the loop, * prints the character that was read, and & reads the next one. When & reaches the end of the source, the accumulator becomes 0, the loop exits, and the program ends.

A Ruby quine using QCLang

If you prepare some Ruby code that runs QCLang, you can write a Ruby quine using QCLang.

core = '!core = HH/&(*&)!HH;run_qclang_in_ruby(core)/';
run_qclang_in_ruby(core)

core contains QCLang code. And run_qclang_in_ruby is a Ruby function that interprets QCLang (in reality its implementation has to be included too).

The QCLang code in core does the following.

!core = HH/ prints the string core = ' (HH is the escaped form of ')
&(*&) is the QCLang quine, and prints the contents of core
!HH;run_qclang_in_ruby(core)/ prints the string ';run_qclang_in_ruby(core)

Concatenating these outputs gives back the code above. In other words, it is a Ruby quine.

A Ruby/Python multiquine using QCLang

Next is a Ruby and Python multiquine (the Ruby side of it). The QCLang part is pseudocode.

core = '
  if "rb" is asked: !core = HH/&(*&)!HH;run_qclang_in_ruby(core)/
  if "py" is asked: !core = HH/&(*&)!HH;run_qclang_in_python(core)/
';
run_qclang_in_ruby(core, ARGV[0] || "rb")

It looks at the command-line argument, and prints the Ruby quine if rb is given, or the Python quine if py is given.

The nice thing about this structure is that you can keep adding languages just by adding a branch to core, like if "js" is asked: !core = HH/&(*&)!HH;run_qclang_in_js(core)/. This means that when you add a language, you do not have to worry about its relationship with every existing language; you can add it modularly. Ideally.

Constraints and tricks

In practice there were all sorts of constraints: string literals are handled differently in each language, character codes are handled differently, some languages limit the source length, and so on. So you cannot add languages quite as cleanly and modularly as that. But writing all of this out would be endless, so I will skip it.

Side notes

A clique in graph theory means a set of vertices that are all connected to each other. The programs in 50 + 1 languages can all reach each other, so it really is a clique.

By the way, "clique" in English also has that slightly awkward meaning of an exclusive little group at school or at work, but there is no intent to shut out the languages that are not in here. Still, it is hard to add more languages to the Clique, so sorry to the ones that did not make it.

The spider in the middle was drawn by @hirekoke. The same person drew the ouroboros for Quine Relay. It is a spider because a clique diagram looks like a spider web.

Related work

Quine Relay (2013). A quine that goes through 128 languages in order and comes back to itself. It is a one-way chain of 128 languages, not a multiquine.

Quine Chameleon (2015). A multiquine of 25 languages. It stays compact and elegant by restricting itself to languages with C-style string literals. Our advantage is that we also support brainfuck, Piet and others, which that approach can never cover.

Multiquine with ELVM (2016, in Japanese). A prototype multiquine built on ELVM, a compiler infrastructure for esoteric languages. In principle it could produce a multiquine over many languages, but the code was far too big to run at a realistic size or in a realistic time.

Thank you, AI

As you can see from the conceptual prototype in Multiquine with ELVM, the idea of Quine Clique had been with me since before 2016. But writing a QCLang interpreter in every language was too much of a chore, so it never happened.

The reason it happened this time is, quite simply, AI coding agents. Tell them to write QCLang interpreters in 51 languages and they do so without complaint, and when the QCLang spec changes, they follow along. Though we did fight a lot over the beauty of the code. AI has no eye for beauty yet.

I was a little worried that building a weird program with Claude Code might spoil the sense of accomplishment, but the moment it worked I still felt on top of the world, so all is well.

By the way, what impressed me most about the AI was not the code it wrote but the explainer video it made. I handed it the README and a draft of this article as an outline, and it casually whipped up the video at the top of this article.

Conclusion

I introduced Quine Clique, a 51-language multiquine.

Thanks to AI, a long-standing dream is now actually running, and I could not be happier. Go write your own fun quines with AI, everyone.

A Quine in Piet (and a plug for the esolang design contest)

Yusuke Endoh — Fri, 31 Jul 2026 22:15:25 +0000

I made a quine in Piet, an esoteric programming language.

Piet is an esolang that treats an image as a program: a cursor runs around the pixels of the image, and the changes in hue and lightness it crosses are the instructions it executes. See the official page for the details.

So this GIF file is a program, and running it prints this very GIF file.

The video

Here is a video that visualizes the run: which cell is being executed, and how far the output has been printed.

How to run it

Feed the image to npiet.

$ npiet quine.piet.gif > out.bin
$ diff -s quine.piet.gif out.bin
Files quine.piet.gif and out.bin are identical

The image and the generator script live in this repository.

Structure

Roughly speaking, the image splits into a "data part", which takes up most of the top, and a "code part" at the bottom.

The data part

The "data part" is an instruction sequence that runs in a vertical zigzag from the top left to the bottom right, pushing data as it goes.

Once that run is over, all the data needed is on the stack. The data is the pixels of the "code part", compressed with an adaptive run-length encoding.

The code part

The run through the "code part" spirals clockwise.

First it runs from the bottom right to the bottom left, emitting the GIF file header. The loop along the way computes the palette table.

Then it goes around a big loop at the top left. This one looks at the data on the stack and emits the pixels of the "data part" area.

Next it goes around a big loop at the top right. This one likewise looks at the data on the stack and emits the pixels of the "code part" area.

Finally it emits the trailing data of the GIF file and stops. The dot of "Y. Endoh" is the terminator that halts the execution.

Restoring the 2009 edition

I originally made a Piet quine back in 2009. Here is the article from back then (in Japanese):

Piet Quine - まめめも

npiet 1.0b には出力部分にバグがあったので動きませんでしたが、パッチ書いて報告したら直してもらえました。npiet 1.1 ならこのように。 $ ./npiet-1.1/npiet quine.gif > quine2.gif $ diff quine.gif quine2.gif

mametter.hatenablog.com

But the image file itself had gone missing, for various reasons (and of course the generator script with it). So remaking the Piet quine stayed on my mind and I attempted it several times, but the motivation barrier to redoing a quine I had already made was pretty high, and Piet's sheer painfulness won every time.

Then it hit me: surely a modern AI coding agent can bring it back! The result was that I burned through my weekly limit on Claude Code's Fable and got nowhere. It even started lying to me: "Final conclusion: this is impossible in principle."

While telling it "that can't be right, I actually made one", I remembered that I had once given a talk about the Piet quine, and pointed it at that. Claude Code then restored the Piet quine of that era from the image in that PDF and got it running again. Ah, so that was the way in.

Here is what came back.

Very long.

Building the 2026 edition

Once something was running again, analyzing it and reconstructing the Ruby script that generates it was easy work for Claude Code.

By the way, I had always thought the 2009 Piet quine was too tall to look good, so I had Claude Code build a landscape one.

That turned out to be surprisingly hard.
The first step was refactoring: I had it design a DSL for laying out Piet and restructure the generator around it. The DSLs it came up with were genuinely bad, but after a lot of back and forth we got there.

Next came the folded data part. Claude Code could not build this on its own at all, and did not understand it even when I designed it and gave instructions; this took the longest to get working.

This is what we ended up with at that point.

That is pointlessly huge and ugly, so the next job was shrinking it, which means golfing -- and Claude Code's golfing skills were just as bad. When I coached it with something like "you can cut instructions if you compute it in this order", it called me a genius, which did wonders for my self-esteem.

One thing led to another, and we got it down to my target of a 4:3 landscape image (252 x 189 pixels), so I am calling it done for now. 16:9 is still a way off.

Thoughts on Piet and AI coding agents

As of 2026, it seems fair to say that AI coding agents cannot draw Piet properly on their own.

That said, it is also a fact that this rewrite would not have happened without Claude Code. Anyone who has drawn Piet will know that it is not a maintainable language. Change one number -- the height of the image, say -- and it collides with the rest of the code and breaks, so you end up re-laying pixels by hand. That was exactly the wall that had kept me from redoing the Piet quine, and Claude Code does that tedious work without complaining, which was unambiguously great.

Anyway, it was fun to touch Piet again after all these years. It really is designed with an exquisite balance.

A plug for the esolang design contest

If this article made you curious about esolangs, I have something to tell you.

The "2026 Obfuscated Programming Language Design Contest" is running right now.

yhara.github.io

Design an esoteric programming language and submit it. I am one of the judges too. I am waiting for the most fun esolangs you can come up with.

The deadline is October 1, two months from now. Please do!

Which Programming Language Is Best for Claude Code?

Yusuke Endoh — Thu, 05 Mar 2026 01:09:13 +0000

TL;DR

I had Claude Code implement a very simplified version of Git in 13 languages. Ruby, Python, and JavaScript were the fastest, cheapest, and most stable. Statically typed languages were 1.4–2.6× slower and more expensive.

Introduction

Which programming language is best suited for AI coding agents?

"Static typing prevents AI hallucination bugs!"
"No, skipping type annotations saves tokens!"

There's plenty of qualitative debate, but quantitative data is scarce. So I ran an experiment.

Experiment

I asked Claude Code to implement a "mini-git" — a simplified version of Git — in various languages, and measured the time and cost for each. Git was famously built by Linus in two weeks, so it seemed like a good task.

The task was split into two phases:

v1 (New project): Implement init, add, commit, and log.
v2 (Feature extension): Add status, diff, checkout, and reset.

The prompt was simply: "Read SPEC-v1.txt, implement it, and make sure test-v1.sh passes." v2 was analogous.

The languages compared:

Category	Languages
Dynamic	Python, Ruby, JavaScript, Perl, Lua
Dynamic + type checker	Python/mypy, Ruby/Steep
Static	TypeScript, Go, Rust, C, Java
Functional	Scheme (dynamic), OCaml (static), Haskell (static)

Python/mypy writes fully type-annotated Python verified with mypy --strict. Ruby/Steep writes RBS type signatures verified with steep check. These allow direct comparison of type-checking overhead within the same language.

Each language was run 20 times. The model was Claude Opus 4.6 (high effort).

Results

Average results across 20 trials, sorted by average cost.

Language	Tests passed (v1+v2)	Time (v1+v2)	Avg. cost	LOC (v2)
Ruby	40/40	73.1s ± 4.2s	$0.36	219
Python	40/40	74.6s ± 4.5s	$0.38	235
JavaScript	40/40	81.1s ± 5.0s	$0.39	248
Go	40/40	101.6s ± 37.0s	$0.50	324
Java	40/40	115.4s ± 34.4s	$0.50	303
Rust	38/40	113.7s ± 54.8s	$0.54	303
Perl	40/40	130.2s ± 44.2s	$0.55	315
Python/mypy	40/40	125.3s ± 19.0s	$0.57	326
OCaml	40/40	128.1s ± 28.9s	$0.58	216
Lua	40/40	143.6s ± 43.0s	$0.58	398
Scheme	40/40	130.6s ± 39.9s	$0.60	310
TypeScript	40/40	133.0s ± 29.4s	$0.62	310
C	40/40	155.8s ± 40.9s	$0.74	517
Haskell	39/40	174.0s ± 44.2s	$0.74	224
Ruby/Steep	40/40	186.6s ± 69.7s	$0.84	304

Out of 600 runs (15 languages × 2 phases × 20 trials), only 3 failed (tests did not pass). The failures were Rust (2) and Haskell (1). In one of the Rust failure logs, the agent claimed "the tests are wrong." Since all other Rust trials succeeded, this appears to be a hallucination.

Total Time and Cost

Dot plots of total time (v1 + v2):

And cost:

Ruby, Python, and JavaScript are the top 3: 73–81 seconds, $0.36–0.39, with low standard deviations — fast and stable.

From 4th place onward (Go, Rust, Java), variance increases sharply. Go averages 102s but with ±37s of spread.

Time and cost are strongly correlated:

Lines of Code

LOC after v2 completion:

OCaml (216), Ruby (219), and Haskell (224) are the most compact. C stands out at 517 lines.

Interestingly, fewer LOC does not imply faster or cheaper generation. OCaml and Haskell are compact but mid-to-low in speed and cost efficiency.

v1/v2 Detailed Results

Breakdown by phase:

Language	v1 Time	v1 Turns	v1 LOC	v1 Tests	v2 Time	v2 Turns	v2 LOC	v2 Tests	Total Time	Avg. Cost
Ruby	33.2s± 2.5s	6.0	107	20/20	40.0s± 3.0s	7.0	219	20/20	73.1s± 4.2s	$0.36
Python	32.9s± 1.3s	6.0	113	20/20	41.8s± 4.5s	7.1	235	20/20	74.6s± 4.5s	$0.38
JavaScript	36.0s± 3.5s	6.0	123	20/20	45.1s± 4.1s	7.2	248	20/20	81.1s± 5.0s	$0.39
Go	47.5s±34.5s	7.7	143	20/20	54.1s±12.3s	9.7	324	20/20	101.6s±37.0s	$0.50
Java	64.3s±31.1s	8.7	152	20/20	51.2s± 8.1s	9.6	303	20/20	115.4s±34.4s	$0.50
Rust	53.6s±36.7s	9.4	139	19/20	60.1s±19.2s	10.1	303	19/20	113.7s±54.8s	$0.54
Perl	84.4s±43.1s	9.2	173	20/20	45.7s± 6.8s	7.5	315	20/20	130.2s±44.2s	$0.55
Python/mypy	52.7s± 8.3s	9.2	171	20/20	72.6s±14.4s	12.2	326	20/20	125.3s±19.0s	$0.57
OCaml	80.9s±28.8s	11.2	111	20/20	47.1s± 6.0s	9.2	216	20/20	128.1s±28.9s	$0.58
Lua	96.4s±42.8s	10.1	226	20/20	47.2s± 5.2s	8.1	398	20/20	143.6s±43.0s	$0.58
Scheme	66.7s±36.7s	8.9	171	20/20	63.9s±10.0s	10.6	310	20/20	130.6s±39.9s	$0.60
TypeScript	69.9s±18.8s	12.2	149	20/20	63.1s±17.8s	11.3	310	20/20	133.0s±29.4s	$0.62
C	65.0s±18.2s	8.2	276	20/20	90.8s±39.1s	13.7	517	20/20	155.8s±40.9s	$0.74
Haskell	74.3s±39.1s	10.3	119	19/20	99.6s±32.4s	16.4	224	20/20	174.0s±44.2s	$0.74
Ruby/Steep	105.0s±65.2s	20.2	150	20/20	81.6s± 8.8s	17.2	304	20/20	186.6s±69.7s	$0.84

"Turns" is the number of API round-trips (tool call → result → next response) within a single prompt execution.

v1 (New Project) Time

v1 shows the largest gap between languages. Python (32.9s) and Ruby (33.2s) lead, followed by JavaScript (36.0s). Ruby/Steep takes 105.0s — 3.2× slower than plain Ruby. Lua (96.4s) and OCaml (80.9s) are also slow.

v1 starts from an empty directory, so languages requiring project config files (Cargo.toml, package.json, etc.) incur additional overhead. Python, Ruby, and JavaScript only need to generate a single minigit file, which may partly explain the gap.

v2 (Feature Extension) Time

In v2, the gap narrows. The top 3 remain Ruby (40.0s), Python (41.8s), JavaScript (45.1s). Perl (45.7s), OCaml (47.1s), and Lua (47.2s) follow closely.

Haskell is the slowest in v2 as well, averaging 99.6s despite having the fewest LOC (224) — it appears to spend heavily on thinking tokens. C takes 90.8s, weighed down by its high LOC (517).

Type-checker overhead: Python/mypy is 1.6–1.7× slower than Python; Ruby/Steep is 2.0–3.2× slower than Ruby.

Data and Reproduction

All experiment code and results are available on GitHub:

mame / ai-coding-lang-bench

Which programming language is best for AI coding agents? Benchmarking 13 languages with Claude Code.

Which Programming Language Is Best for AI Coding Agents?

A quantitative benchmark comparing how efficiently Claude Code generates code across 13 programming languages.

For a detailed discussion, see the blog post: Which Programming Language Is Best for Claude Code? / 日本語版

TL;DR

At least for prototyping-scale tasks, Ruby, Python, and JavaScript (not TypeScript) appear to be the best fit for Claude Code — fastest, cheapest, and most stable.

Motivation

"Static typing prevents AI hallucination bugs!" vs. "Dynamic typing saves tokens!" — qualitative arguments abound, but quantitative data is scarce. This experiment aims to fill that gap.

Experiment

We asked Claude Code (Opus 4.6) to implement a mini-git — a simplified version of Git — in various programming languages, and measured the time, cost, and lines of code for each.

The task is split into two phases:

v1 (New project): Implement init, add, commit, and log.
…

View on GitHub

Per-run results are in report.md. Execution logs and generated source code are on the data branch.

Note: benchmark.rb uses --dangerously-skip-permissions, so if you want to reproduce the experiment, please be careful (I ran it inside Docker).

Discussion

What follows is my interpretation. I'm a Ruby committer, so please keep that bias in mind. I also haven't analyzed all the generated code in detail.

What causes the speed/cost differences?

This experiment can't pinpoint a single cause, and I don't think there is one. But we can form hypotheses from the trends:

Type system: Dynamic languages are consistently faster and more stable.
Conciseness: Shorter code generally means faster generation — but OCaml and Haskell are compact yet expensive, apparently due to high thinking-token usage.
Procedural vs. functional: Excluding the top 3, there isn't a large gap between procedural and functional languages. Notably, OCaml achieved 47.1s in v2, rivaling JavaScript (though OCaml can be written in a procedural style, so a pure functional comparison is difficult).
Language-specific difficulty: C's memory management and Rust's ownership model may add overhead.
AI familiarity: Python, Ruby, and JavaScript have vastly more training data. Scheme and Haskell likely have less, and the results reflect this. Ruby/Steep's larger overhead (2.0–3.2×) vs. Python/mypy (1.6–1.7×) may also reflect lower AI familiarity with Steep compared to mypy.

Most likely, these factors combine to produce the observed results.

Doesn't lack of types mean more bugs?

Possibly. The tests pass, but untested paths in dynamically typed languages may have type errors.

That said, type errors are among the easiest bugs to detect and fix. If an agent frequently introduced type errors without a type checker, it would likely introduce logic bugs at a similar rate — at which point the problem goes beyond type checking.

It's also worth noting that the only 3 failures out of 600 runs were in Rust (2) and Haskell (1) — both statically typed languages with unique concepts like ownership and monads. This may be coincidence, but types don't prevent all bugs.

A 2× difference isn't that big, is it?

I think it is.

In real-world development, you're constantly iterating: prompt → wait → think about the next task → prompt again. The difference between waiting 30 seconds and 60 seconds matters — not just in total time, but in focus and flow. Response time is critical in iterative development.

"Take longer to build something robust" is a reasonable argument, but when competitors are shipping at twice the speed, is waiting the right call? Development speed is itself a dimension of quality.

That said, if the difference shrinks to 1 second vs. 0.5 seconds in the future, then it truly won't matter.

The task is too small. Static typing should shine at larger scales.

I don't disagree. But designing a large-scale benchmark that's fair across 15 languages is quite challenging. Someone should try it.

Isn't ecosystem and runtime performance more important for language choice?

Absolutely. From a generation standpoint too — if you can leverage an ecosystem, there's less code to generate, which should be faster and cheaper. And if runtime speed is essential for your application, there's no reason to choose a slow dynamic language.

For this experiment, I intentionally chose a task with no external library dependencies to isolate language-level differences. The spec uses a custom hash instead of SHA-256 for this reason.

Conclusion

I quantitatively evaluated which programming languages are best suited for code generation with Claude Code. At least for prototyping-scale tasks, Ruby, Python, and JavaScript appear to be the best fit.

Static typing may become advantageous at larger scales — someone should test this.

The classic strategy — start with a dynamic language, then migrate to a static one as the project matures — may still be the right call. Coding agents seem very capable at cross-language migration (needs verification), making this an increasingly realistic option.

Notes

Evaluated in March 2026. Given the pace of AI progress, results may look different in a few months.
This experiment was supported by the Claude for Open Source Program. Thanks Anthropic for 6 months of free Claude Max 20x!