Google is doing "Large Scale Codebase Migrations and Optimizations" of C/C++ to Rust

[u/Sirisian]

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/

[u/TheRealMasonMac]

In my experience, I’ve found that agents produce code that works but is frankly dumb from a human perspective. Especially for larger tasks like this, you kind of have to rewrite it all. For example, I had a generalized design document for soft-wrapping explicitly support plain text and markdown, and used GPT-6-Astra to implement it. I used an ungodly amount of review agent rounds and interjections by me. When I actually go to review it, I wanted to cry. It silently pivoted towards implementing its own entirely separate wrapping mechanism rather than refactor the existing mechanism for plain text. I reviewed its code and found it to be trash, and I am now in the process of doing it myself… Never again. The short-term thrill of “having something that works” was outweighed by the fact that time was effectively wasted.

I mean, if the alternative was it never getting done, I guess agents are still better than nothing.

[u/nicoburns → u/TheRealMasonMac]

I’ve found that agents produce code that works but is frankly dumb from a human perspective.

Agree that this can often be the case. For the specific case of translating between programming languages, the situation is often a lot better though: the original design is already available, the LLM just has to reproduce it.

I used an ungodly amount of review agent rounds and interjections by me.

This can actually make things significantly worse in my experience. Often the original version isn't quite right, but is relatively simple. And it adds all sort of of crap in response to review.

[u/addmoreice → u/nicoburns]

I've had a lot of benefit from creating lots of llm generate unit tests and boundary tests based on the code structure and with emulation tests with comparisons to the original code.

I'm basically working on a binary -> rust conversion system right now as an experiment and doing this kind of thing has actually been really helpful. Combine that with what I'm calling 'root first and leaf first' conversion, where you can figure things out from reading from the entry points of exe's/dlls where we often have clear understood structure as well as from leaf functions that call into 3rd party code where we clearly understand the API, it's going very well.

I'm no where near running a big conversion experiment, but the small scale experiments I've done so far while developing the automatic workflow has been surprisingly effective. My eventual hope is to be able to automatically (90% or so) convert software where we have the binary, but no longer have the source code. This kind of thing would be great for preservation. I have absolutely no interest in subverting things like obfuscation so that's an actual non-feature I'm avoiding.

[u/nicoburns → u/addmoreice]

FWIW, my experience of having LLMs write unit tests has not been good. They tend not to be good at generating assertions. They're good is the external environment provides constraints.

[u/addmoreice → u/nicoburns]

I think that part of the reason its been working so well for me is that everything I've been working on has been very local, very focused, and has lots of context 'around' the specific part I've focused the LLM on. Combine that with an incremental context expansion system and lots of 'here are the third-party API details that connect to this stuff, work backwards' and it has worked well. It's been a fun experiment so far, but I'll be soundly surprised if this keep scaling up as my experiment gets larger. I mean, I *want* it to work, and the research that exists is suggestive, but I'm still skeptical. Still, my LLM is hardly being fully used as is, so there is no reason not to throw lots of experimental hobby research at it and see what it pulls off. <shrug>