> I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go. After the initial translation, I ran multiple passes of adversarial review, asking different models to analyze the code for mistakes and bad patterns.
> The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand. We’ve verified that every AST produced by the Rust parser is identical to the C++ one, and all bytecode generated by the Rust compiler is identical to the C++ compiler’s output. Zero regressions across the board
This is the way. Coding assistants are also really great at porting from one language to the other, especially if you have existing tests.
> Coding assistants are also really great at porting from one language to the other
I had a broken, one-off Perl script, a relic from the days when everyone thought Drupal was the future (long time ago). It was originally designed to migrate a site from an unmaintained internal CMS to Drupal. The CMS was ancient and it only ran in a VM for "look what we built a million years ago" purposes (I even had written permission from my ex-employer to keep that thing).
Just for a laugh, I fed this mess of undeclared dependencies and missing logic into Claude and told it to port the whole thing to Rust. It spent 80 minutes researching Drupal and coding, then "one-shotted" a functional import tool. Not only did it mirror the original design and module structure, but it also implemented several custom plugins based on hints it found in my old code comments.
It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
The Epilogue: That site has since been ported to WordPress, then ProcessWire, then rebuilt as a Node.js app. Word on the street is that some poor souls are currently trying to port it to Next.js.
> 10/10 - would generate tens of thousands of lines of useless code again.
Me too! A couple days ago I gave claude the JMAP spec and asked it to write a JMAP based webmail client in rust from scratch. And it did! It burned a mountain of tokens, and its got more than a few bugs. But now I've got my very own email client, powered by the stalwart email server. The rust code compiles into a 2mb wasm bundle that does everything client side. Its somehow insanely fast. Honestly, its the fastest email client I've ever used by far. Everything feels instant.
I don't need my own email client, but I have one now. So unnecessary, and yet strangely fun.
Its quite a testament to JMAP that you can feed the RFC into claude and get a janky client out. I wonder what semi-useless junk I should get it to make next? I bet it wouldn't do as good a job with IMAP, but maybe if I let it use an IMAP library someone's already made? Might be worth a try!
Same here. I had Claude write me a web based RSS feed reader in Rust. It has some minor glitches I still need to iron out, but it works great, is fast as can be, and is easy on the eyes.
Haha glad to see someone else did something like this. A couple weeks ago I asked Claude to recommend a service that would allow me to easily view a local .xml file as an RSS feed. It instead built a .html RSS viewer.
Re "is fast as can be": in my experience generating C/Zig code via Codex, agent generated code is usually several multiples slower than hand optimized code.
I am an upstream developer on the Rust Project (lang, library, cargo, others), and obviously a big fan of Rust. This kind of advocacy doesn't help us, and in fact makes our jobs harder, because for some people this kind of advocacy is their main experience of people they assume are representative of Rust. Please take it down a notch.
I think Rust is the best available language for many kinds of problems. Not yet all, but we're always improving it to try to work for more people. It gets better over time. I'd certainly never call it, or almost any other software, "defect free".
And I'd never call it "the final language"; we're building it to last the test of time, and we hope things like the edition system mean that the successor to Rust is a future version of Rust, but things can always change, and we're not the only source of great ideas.
If you genuinely care about Rust, please adjust your advocacy of Rust to avoid hurting Rust and generating negative perceptions of Rust.
Oh my, there's a new language called Rust? Didn't they know there already is one? The old one is so popular that I can't imagine the nicely readable one to gain any traction whatsoever (even if the old one is an assault on the senses).
It's honest. If we can serialize our ideas to any language for durability, Rust is the way to go.
It's not the best tool for the job for a lot of things, but if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust.
If you get any language outputs "for free", Rust is the way to go.
I've been using Claude to go ridiculously fast in Rust recently. In the pre-LLM years I wrote a lot of Rust, but it definitely was a slow to author language. Claude helps me produce it as fast as I can think. I spend most of my time reviewing the code and making small fixes and refactors. It's great.
While Rust is excellent, you must acknowledge that Rust has issues with compilation time. It also has a steep learning curve (especially around lifetimes.) It's much too early to say Rust is the "final" language, especially since AI is driving a huge shift in thinking right now.
I used to think that I would never write C code again, but when I decided recently to build something that would run on ESP32 chips, I realized there wasn't any good reason for me to use Rust yet. ESP-IDF is built on C and I can write C code just fine. C compiles quickly, it's a very simple language on the surface, and as long as you minimize the use of dynamic memory allocation and other pitfalls, it's reliable.
If you're programming for ESP, then embassy is the way to go in most cases. You don't need to learn much about lifetimes in most of the application code. Steep learning curve people refer it is "thing blow up at compile time vs runtime." It's easy to write JS or C that passes all tests and compiles and then wonderful blows up when you start using it. It just forces you to learn things you need to know at IMO right now.
My biggest problem with rust right now is enormous target/ dirs.
> My biggest problem with rust right now is enormous target/ dirs.
We're working on that and it should get better soonish. We're working on shared caches, as well as pruning of old cached builds of dependencies that are unlikely to be reused in a future build.
I would say it's overall the best existing language, probably due to learning from past mistakes. On the whole it wins via the pro/con sum. But ... Still loads of room for improvement! Far from a perfect lang; just edges out the existing alternatives by a bit.
Sometimes I forget programming languages aren't a religion, and then I see someone post stuff like this. Programming languages really do inspire some of us to feel differently.
I'd say that it's taking much needed steps to achieve perfection but many more steps are there ahead. The next language closer to perfection would definitely have a much gentler introduction curve, among other things.
When you do fully value-oriented programming in Rust (i.e. no interior mutability involved) that's essentially functional programming. There's mutable, ephemeral data involved, but it's always confined to a single well-defined context and never escapes from it. You can even have most of your code base be sans-IO, which is the exact same pattern you'd use in Haskell.
Isn’t Rust a pretty good functional language? It has most of the features that enable safe, correct code without being anal about immutability and laziness that make performance difficult to predict.
Also curious why would one be proud of having an LLM rewrite something that there is already a library for. I personally feel that proud LLM users boasting sounds as if they are on amphetamines.
> a relic from the days when everyone thought Drupal was the future (long time ago).
Drupal is the future. I never really used it properly, but if you fully buy into Drupal, it can do most everything without programming, and you can write plugins (extensions? whatever they're called...) to do the few things that do need programming.
> The Epilogue: That site has since been ported to WordPress, then ProcessWire, then rebuilt as a Node.js app. Word on the street is that some poor souls are currently trying to port it to Next.js.
This is the problem! Fickle halfwits mindlessly buying into whatever "next big thing" is currently fashionable. They shoulda just learned Drupal...
I'm not sure if you're serious or not, but while I never liked Drupal (even used to hate it once upon a time), I always liked the pragmatism surrounding it, reaching to the point of saving php code into the mysql database and executing from there.
> reaching to the point of saving php code into the mysql database and executing from there.
Wordpress loves to shove php objects into the database (been a good long while since I used it, don't remember the mechanism, it'd be the equivalent of `pickle` in python, only readable by php).
Not sure if they've improved it since I last dealt with it about 15 years ago, but at the time there was no way to have a full separated staging and production environment, lots of the data stored in the database that way had hardcoded domain names built into it. We needed to have a staging and production kind of set-up, so we ended up having to write a PHP script that would dump the staging database, fix every reference, and push it to production. Fun times.
> It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
This is the biggest bottleneck at this point. I'm looking forward to RAM production increasing, and getting to a point where every high-end PC (workstation & gaming) has a dedicated NPU next to the GPU. You'll be able to do this kind of stuff as much as you want, using any local model you want. Run a ralph loop continuously for 72 hours? No problem.
The climate change alarms have been sounding for decades and yet vehicles keep getting bigger. Even in formerly "doing it right" countries like Japan. Turns out humans will always choose vanity and status symbols over facts. Oh well
One person's waste is another's value. Do you have any idea how "wasteful" tik tok or any other streaming platform is? I'll grant that AI is driving unprecedented data center development but it's far from the root cause, or even a leading clause, of our climate issues. I always find it strange that this is the first response so many have to AI, when it poses other more imminent existential threats IMO.
A lot of code is "useless" only in the sense that no one wants to buy it and it will never find its way into an end user product. On the other hand, that same code might have enormous value for education, research, planning, exploration, simulation, testing, and so on. Being able to generate reams of "useless" code is a highly desirable future.
At least you (hopefully) get hours of entertainment from firing up an AAA game. Whereas generating vast amounts of code that you're never going to use has… some novelty value, I suppose. Luckily the novelty is going to wear off soon, I can't really see many people getting their daily happiness boost from making code machine say brrrrt straight to /dev/null. Even generating smut is a vastly more understandable (and vastly more commonplace, even now) use case for running genAI every day for hours.
> It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
Pardon me, and, yes, I know we're on HN, but I guess you're... rich? I imagine a single run like this probably burns through tens or hundreds of dollars. For a joke, basically.
I guess I understand why some people really like AI :-)
Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
All of them are moving into the direction of "less human involved and agents do more", while what I really want is better tooling for me to work closer with AI and be better at reviewing/steering it, and be more involved. I don't want "Fire one prompt and get somewhat working code", I want a UX tailored for long sessions with back and forth, letting me leverage my skills, rather than agents trying to emulate what I already can do myself.
It was said a long time ago about computing in general, but more fitting than ever, "Augmenting the human intellect" is what we should aim for, not replacing the human intellect. IA ("Intelligence amplification") rather than AI.
But I'm guessing the target market for such tools would be much smaller, basically would require you to already understand software development, and know what you want, while all AI companies seem to target non-developers wanting to build software now. It's no-code all over again essentially.
Is it any surprise that the cocaine cartels really want you to buy more cocaine, so they don't focus on its usefulness in pain relief and they refine it and cut it with the cheapest substances that will work rather than medical-grade reagents?
It's surprising that the ones who are producing the cocaine, don't try to find the best use of the cocaine, yes. But then these are VC-fueled businesses, then it all goes out the window, unfortunately. Otherwise they'd actually focus on usefulness, not just "usage" or whatever KPI they go by and share with their investors.
"All of them are moving into the direction of "less human involved and agents do more", while what I really want is better tooling for me to work closer with AI and be better at reviewing/steering it, and be more involved."
I want less ambitious LLM powered tools than what's being offered. For example, I'd love a tool that can analyse whether comments have been kept up to date with the code they refer to. I don't want it to change anything I just want it to tell me of any problems. A linter basically. I imagine LLMs would be a good foundation for this.
Any terminal tool like Claude Code or Codex (I assume OpenCode too, but I haven't tried) can do it, by using as a prompt pretty much exactly what you wrote, and if it still wants to edit, just don't approve the tool calls.
One problem I've noticed is that both claude models and gpt-codex variants make absolutely deranged tool calls (like `cat <<'EOF' >> foo...EOF` pattern to create a file, or sed to read a couple lines), so it's sometimes hard to see what is it even trying to do.
I’m glad I’m not the only one who’s noticed these seemingly arbitrary calls to write files using the cat command instead of the native file edit capabilities of the agent.
Of course there are tools focusing on this. It takes a little getting used to how prevalent it is. My editor now can anticipate the next three lines of code I intend to write complete with what values I want to feed to the function I was about to invoke. It all shows up in an autocomplete annotation for me. I just type the first two or three characters and press tab to get everything exactly how I was about to type it in--including an accurate comment worded exactly in my voice.
Is that what you mean by IA?
For example, I type "for" and my editor guesses I want to iterate over the list that is the second argument of the function for which I am currently building the body. So it offers to complete the rest of the loop condition for me. Not only did it anticipate that I am writing a for loop. It figures out what I want to iterate over, and perhaps even that I want to enumerate the iteration so I have the index and the value. Imagine if I had written a comment to explain my intent for the function before I started writing the function body. How much better could it augment my intellect?
I think this could be a decent interface with one addition, a way to comment on the completion being suggested. You could ask it for a different completion or to extend the completion, do something different, do a specific thing, whatever. An active way to "explain my intent" with the AI (besides leaving comments hinting at what you want) in addition to the passive completion system.
To be honest, I'm not quite sure what the ideal UX looks like yet. The AI assisted autocomplete is too little, but the idea of saying "Build X for purpose Y" is too high-level. Maintaining Markdown documents that the AI implements, also feels too high-level, but letting the human fully drive the implementation probably again too low-level.
I'm guessing the direction I'd prefer, would be tooling built to accept and be driven by humans, but allowed to be extended/corrected by AI, or something like that, maybe.
Maybe a slight contradiction, and very wish-washy/hand-wavey, but I haven't personally quite figured out what I think would be best yet either, what the right level actually is, so probably the best I could say right now :) Sorry!
The Markdown documents can be at any level. Just keep asking the AI to break each individual step in the plan down into substeps, then ask it to implement after you review. It's great for the opposite flow too - reverse engineering from working legacy code into mid-level and high-level designs, then proposing good refactors.
>Agree, and it's also such a shame that none of the AI companies actually focus on that way of using AI.
This is because, regardless of the current state of things, the endgame which will justify all the upfront investment is autonomous, self-improving, self-maintaining systems.
Agents are a "self-driving car for the mind". I don't enjoy or dislike driving, but lots of Americans love to drive. In the future they will lament their driving skills' decline.
We as the general population have consistently lost lots of skills from just 200 years back. Most likely we will not miss them (though coding used to be my hobby).
Though if apocalypse happens and all of our built tech goes away, we are in for a serious survival issu.
Yeah, Douglas Engelbart was also a huge believer in that, and I think from various stuff I've read from him and the Augmentation Research Center put me on this track of really agreeing with it.
"Bicycle for the mind", as always when it involves Jobs, sounds more fitting for the masses though, so thanks for sharing that :)
I am learning rust myself and one of the things I definetly didn't want to do was let Claude write all the code. But I needed guidance.
I decided to create a Claude skill called "teach". When I enable it, Claude never writes any code. It just gives me hints - progressively more detailed if I am stuck. Then it reviews what I write.
I am finding it very satisfying to work this way - Rust in particular is a language where there's little space to "wing it". Most language features are interlaced with each other and having an LLM supporting me helps a lot. "Let's not declare a type for this right now, we would have to deal with several lifetime issues, let's add a note to the plan and revisit this later".
FYI: Claude has output styles, one of them is called `learning`. Instead of writing the code itself, it will add `TODO(human)` and comments to explain how to. Also adds `Insights` explaining concepts to you in its output.
This link also has a comparison to Skills further down.
I had a bash spaghetti code script that I wrote a few years ago to handle TLS certificates(generate CSRs, bundle up trust chains, match keys to certs, etc). It was fragile, slow, extremely dependent on specific versions of OpenSSL, etc.
I used Claude to rewrite it in golang and extend its features. Now I have tests, automatic AIA chain walking, support for all the DER and JKS formats, and it’s fast. My bash script could spend a few minutes churning through a folder with certs and keys, my golang version does a few thousand in a second.
So I basically built a limited version of OpenSSL with better ergonomics and a lot of magic under the hood because you don’t have to specify input formats at all. I wasn’t constrained by things like backwards compatibility and interface stability, which let me make something much nicer to use.
I even was able to build a wasm version so it can run in the browser. All this from someone that is not a great coder. Don’t worry, I’m explicitly not rolling my own crypto.
It's how most of us are actually going to end up using AI agents for the foreseeable future, perhaps with increasing degrees of abstraction as we move to a teams-of-agents model.
The industry hasn't come up with a simple meme-format term to explain this workflow pattern yet, so people aren't excited about it. But don't worry, we'll surely have a bullshit term for it soon, and managers everywhere will be excited. In the meantime, we can just continue doing work with these new tools.
This is an opportunity to select some stupid words that you would like to hear repeated a million times. The process is like patiently nurturing a well-contained thing, so how about "egg coding"?
I havent quite dealt with "teams of agents" yet outside of Claude Code itself spawning subagents, but I have some ideas as to how to achieve it in a meaningful way without giving a developer 10 claude code licenses, I think the real approach that makes more sense to me is to still have humans in the loop, but have their respective agents sync together and divide work towards one goal, but being able to determine which tasks are left to be worked one and tested. I do think for the foreseeable future you will need human validation for AI.
I'm not sure there's going to be a term, because there's no difference from normal, good quality engineering. You iterate on design, validate results, prioritise execution. It's just that you hand over the writing code part. It's as boring as it gets.
Sure, but they're going to be stuck writing software for yesterday's problems. As our tools become more powerful, we're going to unlock new problems and expectations that would be impossible or impractical to solve with yesterday's tooling.
Thinking people who disagree with you hate you or hate the thing you like is a recipe for disaster. It's much better to not love or hate things like this, and instead just observe and come to useful, outcome-based conclusions.
They also attract grifters, frauds, conmen, snake oil peddlers, and every stripe of bullshit artist. I'm someone you probably would view as a hater, but I truly don't hate LLMs. I hate the lies. Projects like this are interesting, I wish there was a lot more of this and a lot less of the "trust me bro" stuff.
Look at any HN thread that has a project that uses AI in any way, shape or form. People quickly remark that it is slop, without even reviewing the code. If that's not blind hatred of AI, I don't know what is.
There's a huge distinction between Vibe Coding, and actual software engineers using AI tooling effectively. I vibe code for fun sometimes too, nothing wrong with it, helps me figure out how the model behaves in some instances, and to push the limits of what I understand.
Vibe Coding is like porn for programmers. It probably isn't good for you, and you'd probably be better off actually doing the thing yourself, but it feels good and satisfies our desires for instant gratification
Well, take for example, I have ideas I've had for years but no time for because by now the requirements are insane. I want to build a backend that could survive nuclear fallout type stuff. I braindump to Claude, watch it churn out my vision for the last 12 years, its insane.
There's other things too though: my ADD and my impostor syndrome don't matter to Claude, Claude just takes it all in, so as I keep brain dumping, it keeps chugging along. I don't have to worry a bout "can I really do this?" it just does it and I can focus on "what can I do to make it better" essentially.
For me it's beyond "porn coding" its basically fulfilling my vision that's been locked away for years but I've had no time to sit down and do it fully. I can tell Claude to do something, my kid comes up and asks me to go draw with them and I can actually just walk away and look at the output and refine.
I never said it doesn't have use cases (much like porn a lot of the arguments against are just fear mongering) just that it isn't as good as the real thing. I myself like yapping to an LLM about ideas to see how feasible they actually are before taking a crack at it
> People quickly remark that it is slop, without even reviewing the code.
I absolutely hate how "slop" has lost its meaning.
"AI slop" was supposed to mean poor-quality content that's obviously AI-generated. But the anti-AI crowd has co-opted it to mean any AI-generated content, regardless of quality. EDIT: Or even the quantity of AI. Expedition 33 had a ton of critical acclaim and ended up winning tons of awards, yet once it was discovered that AI was used to generate some placeholder art, of which NONE of it was actually used in the final product, some people started labeling the game as AI slop. It's utterly ridiculous.
So now, we can't have conversations about AI slop without starting off with making sure everyone is on the same page on what the term even means.
EDIT: "Vibe coding" is suffering a similar fate. If I use AI to write some code, and I examine the code to make sure it doesn't have any obvious bugs or security issues, is that still vibe coding?
We keep seeing this pattern over and over as well. Despite LLM companies' almost tangible desperation to show that they can replace software engineers, the real value comes from domain experts using the tools to enhance what they're already good at.
I haven’t done a ton of porting. And when I did, it was more like a reimplementation.
> We’ve verified that every AST produced by the Rust parser is identical to the C++ one, and all bytecode generated by the Rust compiler is identical to the C++ compiler’s output.
Is this a conventional goal? It seems like quite an achievement.
My company helps companies do migrations using LLM agents and rigid validations, and it is not a surprising goal. Of course most projects are not as clean as a compiler is in terms of their inputs and outputs, but our pitch to customers is that we aim to do bug-for-bug compatible migrations.
Porting a project from PHP7 to PHP8, you'd want the exact same SQL statements to be sent to the server for your test suite, or at least be able to explain the differences. Porting AngularJS to Vue, you'd want the same backend requests, etc..
It’s a very good way of getting LLMs to work autonomously for a long time; give it a spec and a complete test suite, shut the door; and ask it to call you when all the tests pass.
I had a script in another language. It was node, took up >200MB of RAM that I wanted back. "claude, rewrite this in rust". 192MB of memory returned to me.
This is sad to see. Node was originally one of the memory efficient options – it’s roots are solving the c10k problem. Mind sharing what libraries/frameworks you were using?
This is the way. This exact workflow is my sweet spot.
In my coding agent std::slop I've optimized for this workflow
https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode... basically the idea is that you are the 'maintainer' and you get bisect safe, git patches that you review (or ask a code reviewer skill or another agent to review). Any change re-rolls the whole stack. Git already supports such a flow and I added it to the agent. A simple markdown skill does not work because it 'forgets'. A 'github' based PR flow felt too externally dependent. This workflow is enforced by a 'patcher' skill, and once that's active, tools do not work unless they follow the enforced flow.
I think a lot of people are going to feel comfortable using agents this way rather than going full blast. I do all my development this way.
I am having immense success with the latest models developing a personal project that I open sourced and then got burned off by.I can't write anymore by hands but I do enjoy writing prompts with my voice.I have been shipping the best code the project has ever seen.The revolution is real.
Coding assistants are great at pattern matching and pattern following. This is why it’s a good idea to point them at any examples or demos that come with the libraries you want to use, too.
How does he solve the Fruit of the Poison Tree problem? For all he know, his LLMs included a bunch copyrighted or patented code throughout the codebase. How is he going to convince serious people that this port is not just a transformation of an _asset_ into a _liability_?
And you might say that this is a hypothetical problem, one that is not practically occurring. Well, we had a similar problem like this in the recent past, that LLMs are close to _making actual_. When it comes to software patents, they were considered a _hypothetical_ problem (i.e. nobody is going to bother suing you unless you were so big that violating a patent was a near certainty). We were instructed (at pretty much all jobs), to never read patents, so that we cannot incriminate ourselves in the discovery process.
That is going to change soon (within a year). I have friend, whom I won't name, who is working on a project, using LLMs, to discover whether software (open source and proprietary) is likely to be violating a software patent from a patent database. And it is designed to be used, not by programmers, but by law firms, patent attorneys, etc. Even though it is not marketed this way, it is essentially a target acquisition system for use by patent trolls. It is hard for me to tell if this means that we will have to keep ignoring patents for that plausible deniability, or if this means that we will have to become hyper informed about all patents. I suppose, we can just subscribe to the patent-agent, and hope that it guides the other coding agents into avoiding the insertion of potentially infringing code.
(I also have a friend who built a system in 2020 that could translate between C++ and Python, and guarantee equivalent results, and code that looks human-written. This was a very impressive achievement, especially because of how it guarantees the equivalence (it did not require machine-learning nor GPUs, just CPUs and some classic algorithms from the 80s). The friend informs me that they are very disheartened to see that now any toddler with a credit card can mindlessly do something similar, invalidating around a decade of unpublished research. They tell me that it will remain unpublished, and if they could go back in time, they would spend that decade extracting as much surplus from society as possible, by hook or by crook (apparently they had the means and the opportunity, but lacked the motive); we should all learn from my friend's mistake. The only people who succeed are, sadly, perversely, those who brazenly and shamelessly steal -- and make no mistake, the AI companies are built on theft. When millionaires do it, they become billionaires -- when Aaron Swartz does it, he is sentenced to federal prison. I'm not quite a pessimist yet, but it really is saddening to watch my friend go from a passionate optimist to a cold nihilist.).
This is the way. Coding assistants are also really great at porting from one language to the other, especially if you have existing tests.