Learnings from 100K lines of Rust with AI (2025)(zfhuang99.github.io) |
Learnings from 100K lines of Rust with AI (2025)(zfhuang99.github.io) |
This back and forth will take quite a while, but the resulting implementation plan will be 10x better than the original.
You can automate this by giving Codex a goal, and a skill to call Claude to review the implementation spec until they both agree it's done.
Then, for critical code, have them both implement the spec in a worktree, then BOTH critique each other's implementation.
More often than not, Claude will say to take 2 or 3 pieces from it's design over to Codex, but ship the Codex implementation.
Jokes aside, I agree about having LLMs iterate. Bouncing between GPT and Opus is good in my experience, but even having the same LLM review its own output in a new session started fresh without context will surface a lot of problems.
This process takes a lot of tokens and a lot of time, which is find because I’m reviewing and editing everything myself during that time.
Say what you will with proper reasoning or arguments if you feel compelled, tired reddit-commentary like that helps no one.
By the end you have piecemeal "tickets" for your coding agent, if you have multiple developers you can sync them all up into github, and someone could take some locally, or you can just have Claude work on all of them with subagents. The key feature there is because its all piecemeal the context stays per task.
Then I run a /loop 15m If you're currently working ignore this. Start on the next task in gur if you have not. If you finished all work and cannot pass one gate, work on the next available task.
(Note: gur is my shorthand for GuardRails)
I also added a concept called "gates" so a task cannot complete without an attached gate, gates are arbitrary, they can be reused but when assigned to a task those specific assignments are unique per task. A task is basically anything you want it to be: unit test, try building it, or even seek human confirmation. At least when I was using Beads it did not have "gates" but I'm not sure if it has added anything like it since I stopped using Beads.
Claude will ignore the loop if it's currently working, and when its "out of work" it will review all available tasks.
If anyone's curious its MIT Licensed and on GitHub:
I mean that if you ask codex on gpt 5.5 to submit to a plan reviewer subagent that uses gpt5.5, this is enough to have a very good reviewing and reassessment of the plan.
My hypothesis is that it’s even better than opus.
The reason why submitting the product of one LLM to another to review is that you need a fresh trajectory. The previous context might have “guided” the planer into some bias. Removing the context is enough to break free from that trajectory and start fresh.
Have Claude produce that spec 10 times, use the same prompt and same context. Identical requests, but you'll get 10 unique answers that wil contradict each other with each response seeming extermely confident.
Its scary how confident you people are in these outputs.
There are real decisions to be made when going from a vague prompt to a spec. It's not surprising that an LLM would produce different specs for the same work on different runs. If the prompt already contained answers to all the decision points that come up when writing the spec then the prompt would already be the spec itself.
I know LOC is a silly metric, but ~1300 tests for 130k lines averages out to a test per 100 lines - isn't this awfully low for a highly complex piece of code, even discounting the fact that it's vibecoded? 100 LOC can carry a lot of logic for a single test, even for just happy paths.
If you're building a distributed system and you don't have more tests and testing code than actual code, by an order of magnitude most likely, then you're missing test coverage.
Honestly, despite all the hype around Rust in the community, the fact that AI can't handle lifetimes reliably makes me reluctant to use it. The AI constantly defaults to spamming .clone() or wrapping things in Rc, completely butchering idiomatic Rust and making the output a pain to work with.
On the other hand, it writes higher-level languages better than I do. For those succeeding with it, how exactly are you configuring or prompting the AI to actually write good, idiomatic Rust
This is from 2025 - I would like to see an update now how that system turned out to be after the vibe hype
I also had it implement a wasm geodesic calculator in Rust and it's amazing and in my use case is better than geodesiclib using the same updated algorithm.
I'm a "C-nile" Rust folks love to hate and did my first hacking in C Deep Blue C on Atari 8-bits. But I'm very impressed with these products and with the ability to leverage some features of Rust with them. (e.g. audit every unsafe instance and define its invariants, etc.)
I also agree with the commenter who said these LLMs are today, at the present moment, good at Go. The only language I notice it seems to be really good above and beyond others at is javascript, I assume because there's so much of it.
If it is, and it works well, then to me this is far more meaningful than the fact that AI wrote 130K lines of code.
The interesting thing is that it was manageable solo (in many ways it's _more_ manageable solo+AIs than with coworkers+(their)AIs), and in such a short amount of time.
In the end it is just a lot of unmaintainable code quickly generated by AI.
That's great, non-test code is only ~47k lines of code.
Change the skills, ask the agent to do exactly the same in something else.
I am slowly focusing on agent orchestration tools, which make the actual programming language as relevant as doing SOA with BPEL.
Also it is kind of interesting that there is so much enthusiasm to use Claude and Claw all over the place, yet lack of vision on how much the whole infrastructure will improve.
Even when it finally bursts and we get into another AI Winter, what was already achieved isn't going away.
Original RSL library has 36 KLoC across C++ source and headers files. Rust supposed to be more expressive and concise. Yet, AI generated 130k LoCs. I guess nobody understands how this code works and nobody can tell if it actually works.
It works for humans because when we get a borrow-check failure, we take a step back and think about the global shape of our code and ownership. LLMs path straight to the goal. Problem: code doesn't compile. Solution: more clone()
If you're fine with the generalized form "learned a lesson", then surely "learnings" is fine too. There's no point in trying to police a completely normal and sensible use of language.
Go is much better target, i've observed rails/ruby code is also much easier for AI to spit out.
And Haskell flies with AI
Rust doesn't add anything over Go for LLM coding.
Rust makes no promise of being terser than C++, and RSL does less than this considering the optimization.
Also it's only 45/50k LOC so not so very from the 36k LOC.
What harness and model you've been using? For the last few months, essentially since I did the whole "One Human + One Agent = One Browser From Scratch" experiment, I've almost exclusively been doing cross-platform native desktop development with Rust, currently with my own homegrown toolkit basically written from scratch, all with LLMs, mostly with codex.
But I can't remember a single time the agent got stuck on lifetime errors, that's probably the least common issue in regards with agents + Rust I come across. Much bigger issue is the ever-expanding design and LLMs being unable to build proper abstractions that are actually used practically and reduces the amount of code instead of just adding to the hairball.
The issue I'm trying to overcome now is that each change takes longer and longer to make, unless you're really hardcore about pulling back the design/architecture when the LLM goes overboard. I've only succeeded in having ~10 minute edits in +100K LOC codebases in two of the projects I've done so far, probably because I spent most of the time actually defining and thinking of the design myself instead of outsourcing it to the LLM. But this is the biggest issue I'm hitting over and over with agents right now.
format: glob: ".rs" run: cargo fmt -- --check
lint: glob: ".rs" run: cargo clippy -- -D warnings
tests: run: cargo test
audit: run: cargo audit
+ hooks that shove the lefthook automatically in the ai's face
---
rustfmt.toml:
edition = "2021" newline_style = "Unix" use_small_heuristics = "Max" max_width = 100
I've not done any particular/ special prompting.
But python or typescript are full of errors all the time. I rather fallback to perl than python. Perl has been excellent all along.
This hasn't been true since around gpt-4.5 on the OpenAI side of things. The 5.x models have been pretty much solid on Rust for a while now.
It sets up your repo to ensure agents use a workflow which breaks your user requests down into separate beads, works on them serially, runs a judge agent after every bead is complete to apply code quality rules, and also strict static checks of your code. It's really helpful in extracting long, high-quality turns from the agent. It's what we used to build Offload[1].
0: https://github.com/imbue-ai/rust-bucket : A rusty bucket to carry your slop ;)
This is a problem when language designers are mathematicians and don’t understand typographical nuance and visual weights.
The whole "with AI" kind of reduces my hate for Rust though, and increases the appreciation for how strict the language is, especially when the agents themselves does the whole "do change > see error/warning > adjust code > re-check > repeat" loop themselves, which seems to work better the more strict the language is, as far as I can tell.
The "helpful" error messages from Rust can be a bit deceiving though, as the agents first instinct seems to be to always try what the error message recommends, but sometimes the error is just a symptom of a deeper issue, not the actual root issue.
If you want to give it a fair shot, it does take some time to get used to, coming from something like Python or Ruby. I won't deny that. I've found that using LSP-assissted semantic syntax highlighting helps, for me, on the typographic front.
I don't think typographic design is a key consideration in most languages' designs, though, and I don't think it should be. The main thing I look for is consistent, relatively predictable rules around the syntax, as far as that layer of language choice goes.
(Yes, I know the 'a lifetimes are a bit weird, and that's not something that exist in typescript, but that's also not something you use everyday in Rust either.
What model are you using, and what frameworks are you using?
This is not a hard problem for LLMs to solve.
Rust is nearly the perfect language for LLMs.
It's exceptionally expressive, and it forbids entirely the most common globally complex bugs that LLMs simply do not (and won't for some time) have the context window size to properly reason about.
Dynamically typed languages are a disaster for LLMs because they allow global complexity WRT to implicit type contracts (that they do not and cannot be relied on to withhold).
If you're going to add types, as someone pointed out earlier, why are you even telling an LLM to write Python anyways?
Rust is barely harder to read than Python with types. It's highly expressive.
You have the `&mut` which seems alien, verbose (safe) concurrency, and lifetimes - which - if you're vibe coding... you don't really need to understand that thoroughly.
You want an LLM to write code in a language where "if it complies, it works" - because... let me tell you, if you vibe code in a language where errors are caught at runtime instead of compile time... It will definitely NOT work.
- Garbage collected so no reasoning tokens or dev cycles are wasted on manual memory management. You say if you're vibe coding you can ignore lifetimes, but in response to a post that says AI can't do a good job and constantly uses escape hatches that lose the benefits of Rust (and can easily make it worse, copying data all over the place is terrible for performance).
- Very fast iteration speed due to JIT, a fast compiler and ability to use precompiled libraries. Rust is slow to compile.
- High level code that reads nearly like English.
- Semantically compatible with Java and Java libs, so lots of code in the training set.
- Unit tests are in separate files from sources. Rust intermixes them, bloating the context window with tests that may not be relevant to the current task.
In tsz I have hard gates that disallow doing work in the wrong crate etc.
Maybe I'm using agents wrong, but I'm not sure how you'd end up in that situation in the first place? When I start codex, codex literally only has access to the directory I'm launching it, with no way to navigate, read or edit stuff elsewhere on my disk, as it's wrapped in isolation with copied files into it, with no sync between the host.
Hearing that others seemingly let agents have access to their full computer, I feel like I'm vastly out of date about how development happens nowadays, especially when malware and virus lurks around all the package registries.
My issue is specifically with how the AI uses it. In AI code, .clone() is almost always used as a brute-force escape hatch
The complexities LLMs end up putting themselves in is more about the bigger architecture/design of the program, rather than concrete lines, where things end up so tangled that every change requires 10s of changes across the repository, you know, typical "avoid the hairball" stuff you come across in larger applications...
this. create pre-commit hooks that enforce project conventions, code quality checks, and regression testing. it saves you so much headache
Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).
I mean God help us should a crustacean try to understand the merits of my claim.
“Oh he’s saying something negative about rust…” Downvote!
I think with AI the language should still be readable. Humans need to be able to understand what’s going on!
However, if I link to gestalt theory of psychology; The Elements of Typographical Style by Robert Bringhurst; and The Primer of Visual literacy by Donis Dondis, folks will undoubtedly NOT read it and still downvote because they have been in Rust code and so have naturally become accustomed to its monstrous appearance. :)
Perhaps I should design a language that is typographically sound—something like brainf*ck haha
Fixed.
Anyway, I accept this usage of the word "lesson", so I also accept "learnings". My point was one of hypocrisy, not policing people in how they can use the word "lesson".
Sounds like your work doesn’t need Rust and that’s ok.
But don’t generalize.
Sure if you want to vibe code a TODO app where it's literally just copying and pasting one it's already seen 10,000 times before, it can do it in Python.
We're year 4 into this discussion and camps have only gotten more bifrucated. There's no 1-1 discussion to have about this as of now, at least not before the crash.
Your only hope in such discourse is not trying to convince the other party how wrong they are, but appealing to an as of yet undecided party. Be it with reason, or simply pointing out how absurd some comments sound to the average person.
I don't care about convincing anyone, the ones I reply to or others, but if you take the time to leave a comment, at least make it something to read and think about instead of soundbites like "This is astrology for devs", it's plain boring to read and makes HN worse.
That's fine. Others will care for you.
>it's plain boring to read and makes HN worse.
I chuckled at the joke. Surprising amount of layers to it.
Though I never strove to be a comic nor writer, that kind of terse, compact punch makes me envy those of such literary talent.
If the behavior of the llm is the same as the behavior of reasonable people then the behavior of the llm is reasonable, regardless of how black of a box they generate tokens out of.
Reasonable people will generate divergent specs for the same prompt. Thus it is reasonable for an LLM to generate divergent specs out of the same prompt.
Edit: I use “reasonable” here in the legal sense of the “reasonable person” standard, not to imply any reasoning process.
It really can be useful. It's very different from old world programming.
With moral agency and the ability to learn (even if we presume you are correct, which I don't think you are).
I assure you I've met many devs and "engineers" that reason less than LLMs, and are black boxes, especially in terms of the code they write.
No, they don't.
They are token predictors that use statistical techniques to emit the randomly weighted next most likely token given the previous token list.
The result is a strange mimic of human reasoning, because the tokens it predicts are trained on strings that were produced by humans that were reasoning, but that's not the same thing.
Human cognition is complex and poorly understood, and the nature of the mind is an area of study almost as old as consciousness itself. We don't know exactly how it works, or what its exact relationship to the brain is, but we do know that it is not a simple token predictor.
LLMs, by their very nature are constrained to the concept of language and the relationship between existing words in a corpus. This is a box they can not escape.
Modern neuroscience suggests that the human brain is much more vast than that, and in many ways looks like it is constrained by language, but certainly not limited to it.
As you raise the temperature they will start (pseudo)randomly choosing tokens other than the single most likely token (though that one will still be the most likely to be chosen). It turns out this is almost always better than zero temperature, which has a tendency to get caught in repetitive loops. I imagine all the frontier labs have spent thousands (millions?) of CPU hours tuning the temperature parameters on their models for optimal performance.
> LLMs have a temperature parameter. At zero temperature they are deterministic: they always choose the most likely next token at each step based on what came before and the model weights, and they will always generate the same output given the same input.
"A value proportional to the reciprocal of β is sometimes referred to as the temperature: β = 1/kT, where k is typically 1 or the Boltzmann constant and T is the temperature. A higher temperature results in a more uniform output distribution (i.e. with higher entropy; it is "more random"), while a lower temperature results in a sharper output distribution, with one value dominating."
"Temperature" in the context of softmax does not change a "winning" token, it changes how much probable (in the sense of softmax distribution) winning token will be. If the winning token is "New York", it will be a winner with temperature close to 0 and with temperature of 1e9.
The actual selection of the random token is done separately by using inputs outside of the softmax distribution, for example, by using random number generator. I believe most of LLM configs have a seed for the random number generator.
More than that, generation of code in most programming languages is done with the more guardrails such as beam search guided by schema, syntax and semantics.
A prompt like "write these two files on disk" will very likely make the LLM do some sort of an atomic write/swap operation, unlike the average developer which will just write the two files and maybe later encounter a race condition bug. You can argue the LLM output is overkill, but it will also be more robust on average.
An LLM is isn't deterministic but also isn't iterative without an existing human. You give it the same spec 10 times and it produces 10 results that aren't far off itself but vastly different when you go into the weeds. And not different in a way of improvement. |
What has always mattered is how you decide the specs, not the specs in themselves.
But they didn't ask humans, they asked a machine. We expect our machines to behave in predictable ways.
> If the prompt already contained answers to all the decision points that come up when writing the spec then the prompt would already be the spec itself.
This is one of the best arguments against using LLMs I've seen.
It reduces to the classic argument- at the point where you've described a problem and solution in sufficient detail to be confident in the results, you've invented a programming language.
I expect LLMs to produce randomly varying output. Maybe it's the thousands of hours I spent doing monte carlo simulations for my PhD.
> This is one of the best arguments against using LLMs I've seen.
> It reduces to the classic argument- at the point where you've described a problem and solution in sufficient detail to be confident in the results, you've invented a programming language.
I'm not an LLM true believer, but I use codex for various small tasks and it often (not always) does a thoroughly decent job. Yesterday I gave it a pretty vague request to set up a new Home Assistant dashboard and it handled it just fine--I told it what I wanted to see but it figured out itself which helper variables it would need to set up to realize that vision and wrote all the config for it.
I probably could have done it in 15 minutes if I was familiar with Home Assistant's yaml configuration schema and all, but I'm not so it probably would have taken me closer to an hour. Asking codex took me 30 seconds and it did just fine.
I am skeptical that LLM's are going to kill all white collar jobs or whatever anytime soon. Not being able to truly learn things is an issue. Reality has a surprising amount of detail[1], and while codex does well at things like writing Home Assistant configs and setting up a Minecraft server, where there are thousands of examples online of how to do it, when I've asked it to do some more esoteric things it has sometimes failed spectacularly. I don't think having the LLM keep notes and then read them back (filling up the context window) is a real solution here.
[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
Reasoning is making analogies between logical patterns found in conceptual space, with a direction of time (statements precede conclusions). For example. A => B and B => C. You may now deduce A => C. For something fuzzier, A~D and B~E, you may now deduce that D~=>E. This is the sort of thing that higher layer attention mechanism is capable of doing.
> This is a box they can not escape.
Would you say that Helen Keller was less capable of abstract reasoning because she had more constrained access to sensory input?
Technically if it has that, it'd be singularity no? So basically the premise is they are doing nothing of the sort. Prove any LLM enough and it really does show it has no quarrels contradicting itself or being bossed around. Has no belief / no orientation etc. It's truly mindless but tricks our mind and soul (or whatever) probably.
reasoning is not black and white. It is possible to reason poorly. Most people cannot do basic math proofs, even math majors struggle with the hardest math proofs. Reasoning in humans is also context/token dependent. I just spent one HOUR trying to show my mom (who has mild dementia) how to use amazon fire (push DOWN until your channel shows up, push RIGHT until the channel becomes big) and she could not figure it out. Rewrote the instructions in japanese and she followed the logic relatively smoothly. Ironically, i'm pretty sure her english is better than her japanese, vocabulary wise.
> it's simply nothing like the wetware reasoning to get to the same answer.
but you don't know how wetware reasoning works, so you are incapable of making that proclamation. I'm pretty sure when I do math proofs (I'm not an amazing mathematician) sometimes I have to literally tick my way through each step of the proof, sometimes breaking it down to super-basic substeps, which to me feels awful lot like what an LLM could be doing. For that matter we don't know how LLM reasoning works but my claim is that these LLMs are in principle capable of reasoning due to architecture.
If this doesn't make sense I suggest you look over the architecture of LLMs carefully and try to understand my point.
(BTW I'm not talking about "reasoning models" with "thinking turns", that's just marketing speak, I'm talking about ANY transformer-based model, even the "dumbest UX architecture" completion models)