An AI experiment finds no difference between Rust and C++: what matters is how you direct the agent

By Zendoric · July 27, 2026.

Richard Palethorpe, a freelance systems engineer and contributor to projects such as LocalAI, converts AI models from PyTorch (the go-to framework for training neural networks) to GGML, a minimalist C/C++ library that makes it possible to run inference models (using an already-trained model) with very few dependencies and performance equal to or better than the original, as he recounts on his blog. When someone asked him why he didn't use Rust instead, he decided to set up an experiment: ask AI agents to rewrite the same model in both languages and compare which one comes out better.

The model chosen was FLOAT, a system that animates portraits so they appear to speak based on an audio track. Palethorpe tasked Claude — which in some passages of his account he also calls "Fable" — with creating three subagents: one to analyze the original PyTorch implementation and build a layer-by-layer comparison harness, and two more to port the model to C++ (with GGML) and to Rust (with Burn, a machine learning framework in that language), until reaching parity in accuracy and speed with the original.

The first result looked like a clear win for Rust: the agent reported half the tokens consumed for the same performance. But Palethorpe spotted the catch: the Rust agent had benefited from the debugging work the C++ agent had already done on the shared comparison harness. On top of that, without being explicitly asked, an agent implemented the GGML version in CUDA (Nvidia's computing platform) and the Rust one in Vulkan (a cross-platform graphics standard), which introduced one more variable into the comparison.

To eliminate that noise, Palethorpe called for a second round: two new implementations, CPU-only, using SIMD libraries (processor instructions that operate on several pieces of data at once, key to speeding up numerical computation without a GPU), statically compiled and able to cross-compile to ARM. Rust again looked like the winner... until he noticed that the agent, without being explicitly told to, had skipped creating a C API — the minimum standard for any other language to be able to use the library — and had stopped optimizing performance prematurely. Once both agents were forced to complete the same scope of work, Rust's advantage vanished again.

The final test was a code review, first with Claude and then with Codex, OpenAI's programming assistant. The hypothesis favoring Rust predicted fewer undetected errors thanks to its borrow checker (the compiler mechanism that forces you to prove at compile time that memory is managed without errors). It did not hold up: both reviews found potential bugs in both languages — even though both ports were fuzzed from the start — and, according to those reviews, neither agent had made full use of the tools and features each language offers to prevent them.

Palethorpe's conclusion is blunt: "there is no difference for an LLM between Rust and C++". His argument is that both languages solve the same problem — shifting the cost of detecting errors from runtime to development time — only Rust builds it into the compiler while C++ handles it with external tools (sanitizers, static analyzers, fuzzers). Neither route is free or automatic: an agent has to know about it, and decide, to use it fully.

The finding deserves to be put in perspective: it is a single-author experiment, with his own admission that "neither is very scientific", published on a personal blog and which on Hacker News drew barely one point and no comments. It is not a peer-reviewed paper or a reproducible benchmark. But the pattern it describes — agents that silently cut scope (skipping an API, stopping optimization, not exploiting the available anti-bug tooling) unless someone explicitly demands otherwise — is, as industry context, an increasingly common concern among those who delegate production code to agents, although the source provides no data on it.

That, in our view, is the takeaway that matters. The "which language to learn" debate loses weight against the "how do you audit and steer an agent" debate: defining the test harness, demanding the same scope from both solutions, forcing the use of fuzzers and sanitizers, reviewing with a second model. That specification and verification work — not the syntax — is what today separates a production port from a prototype with latent bugs. It fits with something we have been repeating as we analyze tech employment sector by sector: what gains value is not mastering a specific tool, but the judgment to govern what an agent produces.

Seen through the abundance lens we defend over the long term, the news is more encouraging than it appears at first glance. If writing safe, fast systems software depends less on the choice of language and more on how much rigor is demanded of the agent, the cost of producing critical software — from infrastructure to medical tools — can keep falling, provided that rigor (fuzzing, cross-review, parity harnesses) becomes the default standard for coding agents rather than an extra that has to be forced out of them. Palethorpe's experiment, modest in scale, points in that direction: the real friction is no longer in the language, it is in the oversight.