We're working on a large Rust codebase, heavily assisted development with Claude and Codex, and one critical workflow is after you have written a spec, have the other LLM critique it thoroughly.
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.
I take this idea even further: After the LLMs have critiqued each other, I introduce a third critique and review it myself as a human. This third party review is most effective at highlighting problems that the LLMs miss, in my experience.
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.
This is precisely how I used to use Beads before I made GuardRails (I wanted something slightly simpler, but similar with more 'guard rails'). I braindump everything I want to build, I ask Claude to do market level research. I then ask Claude to ask clarifying questions, when I ask Claude to be critical of its conclusions and provide the top options and to justify it. I also question Claude and say its okay to disagree with me, be critical, I just want to understand.
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 strongly believe you don’t need to call another model for that. The same model can do result fine. Just not as part of the same context.
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.
I hate how seriously people take the output of an LLMs or how reliable they think it is.
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.
If you ask 10 different humans to produce the spec with the same information (prompt and context) they will also produce 10 unique answers that will contradict each other and (depending on who you asked) may be just as confident.
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 didn’t claim that LLMs are people or that they reason.
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's an analogy, it didnt fall on its face at all. it's just a comparison to highlight the point being made was nonsensical. example: you're just a next action generator controlled by trillions of cells and subconscious dna-based behavior. a black box.
moral agency and the ability to learn are implicit in the description you quoted. this isn't some special superpower, all animals have the ability to learn, and many have moral agency. these aren't human specific traits
An LLM should not "generate specs", a human should. The LLM can work from the specs. It can never infer meaning from a vague prompt. If so, it will start guessing. Every human that ever did functional specification or information analysis at some point knows this. Or has learned the hard way, something with assumptions and asses ;)
The guessing of a LLM for a vague prompt is better than the one of your average developer.
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.
So what’s most important is knowing those parameters and the ranges of values, not having the final result. A human, after producing a specs, can the provide the mental model of how he created the specs. Where the inflection points are and what the range of valid results.
What has always mattered is how you decide the specs, not the specs in themselves.
>Testing is the first layer of defense. My system now includes 1,300+ tests — from unit tests to minimal integration tests (e.g., proposer + acceptor only), all the way to multi-replica full integration tests with injected failures. See the project status.
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.
Considering the domain being distributed systems, and aiming to implement "a Rust-based multi-Paxos consensus engine that not only implements all the features of Azure’s Replicated State Library (RSL)", I don't think we even have to look so deep into it, it's severely lacking tests.
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.
IIUC only 50k LoC are non-test code, which improves the metric. Whether that's enough tests still depends on the code. If most are getters and setters, the coverage might be ok.
I may have missed it but are those tests written by person or generated? Otherwise how do you know they even test anything (like actually test, not appear to test)
I'm also shifting to an vibe coding workflow, but I have a genuine question: whenever I use AI for Rust, it makes an insane amount of lifetime errors. I have no idea how people are churning out so many lines of code so quickly.
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
> I'm also shifting to an vibe coding workflow, but I have a genuine question: whenever I use AI for Rust, it makes an insane amount of lifetime errors. I have no idea how people are churning out so many lines of code so quickly.
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.
Have you split your 100k loc codebases into smaller crates? If you take a look at eg gitoxide's repo, they've split it in many smaller crates. I think that might help with keeping the scope for the ai small and maybe help with keeping contracts tight and well-defined.
Yes, that absolutely helps (and yes, doing that :) ), I'm going even further and basically hard-enforcing a LOC limit per file too, which helps a lot as well.
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...
The feedback loop is the interesting part, if you use standard software engineering practices (modularise, test/document your interfaces, etc) then I find things like Claude Code do an exceptional job: since they can actually run cargo check/test themselves and can validate the tests too.
I see the complete opposite. The lower level the language, the less babysit the agent. Pure asm is the best, only with very advanced SIMD flags it has problems. C is excellent.
But python or typescript are full of errors all the time. I rather fallback to perl than python. Perl has been excellent all along.
I'm surprised to hear this. I have not had any issues here at all. The AI might clone things but I don't really care/ mind, I can ask it to refactor to make things zero-copy after, which is how I've often written Rust myself. I've never seen it overly wrap things in Rc.
I'm actually vibe coding a game engine right now using a Hexagonal Architecture, and I ran into this exact same issue when trying to synchronize the feedback loop between the viewport and the editor. To be fair, I probably messed up the domain boundaries myself in the first place, but honestly, the AI-generated code wasn't very effective at solving it either
> 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.
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.
> whenever I use AI for Rust, it makes an insane amount of lifetime errors.
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.
It's not nearly the perfect language for LLMs and Rust is dramatically harder to read and reason about than Python with types. Other options work better for nearly all apps. I found Kotlin works well:
- 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.
Write a 250k LOC compiler in Python and then get back to me how well LLMs write in Python...
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.
Yeah, LLMs suck at named lifetimes. The number of times I have seen Claude reach for indices and clones instead of just using proper named lifetimes is too many to count at this point. Not great for high-performance code!
I wrote and maintain this library of skills and workflows called Rust Bucket[0]
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].
I think it's due to the lack of quality instructions on what is good Rust code; AI often literally doesn't know what idiomatic Rust is. It can be good to have a reference where you write the basic rules that you want it to follow (ideal to assume it has no idea why spamming clone is bad and you're speaking to someone who has just watched one of those youtube videos with a dude in black t-shirt speaking very slowly and going over basic programming concepts as if they're breaking you out of the matrix).
> have hard gates that disallow doing work in the wrong crate
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.
tsz is an experiment in giving coding agents full control. On my day job I am a lot more careful. But I've moved on from manually approving every change and instead review the final diff. I noticed manually approving was counterproductive.
Why would the language being typographically ugly matter? Python's pretty, but it hides a lot of functional nuance behind that. Rust is terse, but it's also expressive in its terseness.
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.
If I was forced to write it myself, then I'd agree, I'd use Clojure all day before Rust, because it's such a chore to write, edit and read.
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 I was forced to write it myself, i would love to keep writing ruby. What a wonderful language. I dont write ruby anymore, mostly using golang and python.. but ruby still a joy.
Hardly surprising, you give a strong opinion but you don't actually back that up by any arguments, that stuff tends to be downvoted here. Add some proper reasoning and making it clear why you think as you think, and people will stop downvoting :) Also, stop caring about magic internet points, they don't matter and people downvote random stuff sometimes.
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
I really don't get the complain about Rust's syntax, it's almost identical to TypeScript's and nobody complains about TypeScript Synthax being ugly …
(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.
> So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)
No, the performance impact will depend on `impl Clone` for the underlying type, the hotness of the code path, and how sensitive to those two variables your code's domain is. It may be extremely expensive.
> Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).
There are cases where assuming `clone` is possible allows for significant architectural and API simplifications at the expense of performance. In those cases, de-cloning will be involved and may produce significant changes.
It's almost guaranteed with agents you could do the same job with less than half of 100k lines. I don't know whats impressive in lines of code generated by agent.
It just an anchor. If it were 50k would you say the same down to 25k? And if so how many more times would it apply?
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.
Original RSL library is 36k LoC. And this is C++. Rust should be like 50% smaller, that is, 18k LoC. This library is so big that I bet the author has no idea if it works or not. 1300 test generated by AI say nothing about actual quality.
In the end it is just a lot of unmaintainable code quickly generated by AI.
This is uncharitable, but makes a prediction. I imagine you'd bet the author won't be successfully using this, at MS/Uber or wherever they are, in a year time?
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.
I have Tarpaulin code coverage check and everytime that it drops below the treshold Claude gives up quickly and just lowers the threshold. I don't know how to overcome it. CLAUDE.md neither AGENTS.md help but the LLM always finds its way.
It is described in the "Code Contracts" section of the article: "Code contracts specify preconditions, postconditions, and invariants for critical functions. These contracts are converted into runtime asserts during testing but can be disabled in production builds for performance". The .NET framework article that he links to: https://learn.microsoft.com/en-us/dotnet/framework/debug-tra...
Is this basically what Dijkstra was saying? I've been thinking how his approach was considered impractical, but may eventually become necessary for security/stability reasons the way things are going. (Seems like new zeroday on HN front page every day now.)
Paxos is certainly non-trivial in the sense that tiny changes can break it, but in terms of functionality it is not that big. 50 KLOC just seems like a lot of code to me.
Learnings is irritating to me. The way kids use the word aesthetic is irritating too. I wonder if I might be that old man shaking his fist at the clouds, but I have gotten over begs the question, and literally, so maybe not yet...
A lesson would be a specific learning activity happening at a specific place and time, administered by a person more knowledgeable than you; like a teacher or mentor "giving a lesson".
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.
This is great example of AI slop and a big problem with AI coding.
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.
Rust is about abstractions more than code. You can ask AI to "Optimize/Test/Clarify" but at the end of the day you should be willing to blindly agree to it's output or spend more time reviewing someone else's code.
Yes, but it comes with much better “built-in” guardrails to rein in the autocomplete. Especially if compared to something runtime-surprise-prone-if-lovable like Ruby.
We're working on a large Rust codebase, heavily assisted development with Claude and Codex, and one critical workflow is after you have written a spec, have the other LLM critique it thoroughly.
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.
I take this idea even further: After the LLMs have critiqued each other, I introduce a third critique and review it myself as a human. This third party review is most effective at highlighting problems that the LLMs miss, in my experience.
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.
This is astrology for devs.
This is precisely how I used to use Beads before I made GuardRails (I wanted something slightly simpler, but similar with more 'guard rails'). I braindump everything I want to build, I ask Claude to do market level research. I then ask Claude to ask clarifying questions, when I ask Claude to be critical of its conclusions and provide the top options and to justify it. I also question Claude and say its okay to disagree with me, be critical, I just want to understand.
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:
https://github.com/Giancarlos/guardrails
I strongly believe you don’t need to call another model for that. The same model can do result fine. Just not as part of the same context.
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.
I hate how seriously people take the output of an LLMs or how reliable they think it is.
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.
If you ask 10 different humans to produce the spec with the same information (prompt and context) they will also produce 10 unique answers that will contradict each other and (depending on who you asked) may be just as confident.
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.
LLMs aren't people. They don't reason. They're token generators, a black box. Your analogy falls on its face with any scrutiny.
I didn’t claim that LLMs are people or that they reason.
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's an analogy, it didnt fall on its face at all. it's just a comparison to highlight the point being made was nonsensical. example: you're just a next action generator controlled by trillions of cells and subconscious dna-based behavior. a black box.
> you're just a next action generator controlled by trillions of cells and subconscious dna-based behavior.
With moral agency and the ability to learn (even if we presume you are correct, which I don't think you are).
moral agency and the ability to learn are implicit in the description you quoted. this isn't some special superpower, all animals have the ability to learn, and many have moral agency. these aren't human specific traits
Reductio ad absurdum.
exactly my point lol
LLMs do reason (they just sometimes don't reason well).
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.
They very obviously reason.
An LLM should not "generate specs", a human should. The LLM can work from the specs. It can never infer meaning from a vague prompt. If so, it will start guessing. Every human that ever did functional specification or information analysis at some point knows this. Or has learned the hard way, something with assumptions and asses ;)
The guessing of a LLM for a vague prompt is better than the one of your average developer.
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.
So what’s most important is knowing those parameters and the ranges of values, not having the final result. A human, after producing a specs, can the provide the mental model of how he created the specs. Where the inflection points are and what the range of valid results.
What has always mattered is how you decide the specs, not the specs in themselves.
Imagine making this your entire identity
The return of pair programming.
>Testing is the first layer of defense. My system now includes 1,300+ tests — from unit tests to minimal integration tests (e.g., proposer + acceptor only), all the way to multi-replica full integration tests with injected failures. See the project status.
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.
Considering the domain being distributed systems, and aiming to implement "a Rust-based multi-Paxos consensus engine that not only implements all the features of Azure’s Replicated State Library (RSL)", I don't think we even have to look so deep into it, it's severely lacking tests.
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.
IIUC only 50k LoC are non-test code, which improves the metric. Whether that's enough tests still depends on the code. If most are getters and setters, the coverage might be ok.
I may have missed it but are those tests written by person or generated? Otherwise how do you know they even test anything (like actually test, not appear to test)
I'm also shifting to an vibe coding workflow, but I have a genuine question: whenever I use AI for Rust, it makes an insane amount of lifetime errors. I have no idea how people are churning out so many lines of code so quickly.
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
> I'm also shifting to an vibe coding workflow, but I have a genuine question: whenever I use AI for Rust, it makes an insane amount of lifetime errors. I have no idea how people are churning out so many lines of code so quickly.
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.
Have you split your 100k loc codebases into smaller crates? If you take a look at eg gitoxide's repo, they've split it in many smaller crates. I think that might help with keeping the scope for the ai small and maybe help with keeping contracts tight and well-defined.
Yes, that absolutely helps (and yes, doing that :) ), I'm going even further and basically hard-enforcing a LOC limit per file too, which helps a lot as well.
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...
> basically hard-enforcing a LOC limit per file too, which helps a lot as well
this. create pre-commit hooks that enforce project conventions, code quality checks, and regression testing. it saves you so much headache
A lefthook:
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
use "stage_fixed" to automatically persist the formatting :)
Thank you!
The irony of the machines having no mechanical sympathy is just too good
The feedback loop is the interesting part, if you use standard software engineering practices (modularise, test/document your interfaces, etc) then I find things like Claude Code do an exceptional job: since they can actually run cargo check/test themselves and can validate the tests too.
I see the complete opposite. The lower level the language, the less babysit the agent. Pure asm is the best, only with very advanced SIMD flags it has problems. C is excellent.
But python or typescript are full of errors all the time. I rather fallback to perl than python. Perl has been excellent all along.
I'm surprised to hear this. I have not had any issues here at all. The AI might clone things but I don't really care/ mind, I can ask it to refactor to make things zero-copy after, which is how I've often written Rust myself. I've never seen it overly wrap things in Rc.
I've not done any particular/ special prompting.
What kinds of programs are you writing and with what models? I'm curious if the lifetimes your programs require are trickier than most.
I'm actually vibe coding a game engine right now using a Hexagonal Architecture, and I ran into this exact same issue when trying to synchronize the feedback loop between the viewport and the editor. To be fair, I probably messed up the domain boundaries myself in the first place, but honestly, the AI-generated code wasn't very effective at solving it either
> 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.
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.
> whenever I use AI for Rust, it makes an insane amount of lifetime errors.
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.
It's not nearly the perfect language for LLMs and Rust is dramatically harder to read and reason about than Python with types. Other options work better for nearly all apps. I found Kotlin works well:
- 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.
Then your domain problem you’re trying to solve doesn’t benefit from Rust.
Sounds like your work doesn’t need Rust and that’s ok.
But don’t generalize.
Write a 250k LOC compiler in Python and then get back to me how well LLMs write in Python...
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.
I didn't say it's better to use Python!
This is likely a fully LLM-generated reply.
I’ve been writing almost exclusively Rust with LLMs and rarely ever hit this. I guess maybe the kind of work you are doing?
Yeah, LLMs suck at named lifetimes. The number of times I have seen Claude reach for indices and clones instead of just using proper named lifetimes is too many to count at this point. Not great for high-performance code!
I wrote and maintain this library of skills and workflows called Rust Bucket[0]
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 ;)
1: https://github.com/imbue-ai/offload
rust-bucket is 404, did you make it private?
Thanks for the flag--I guess I must have never made it public.
Fixed.
I think it's due to the lack of quality instructions on what is good Rust code; AI often literally doesn't know what idiomatic Rust is. It can be good to have a reference where you write the basic rules that you want it to follow (ideal to assume it has no idea why spamming clone is bad and you're speaking to someone who has just watched one of those youtube videos with a dude in black t-shirt speaking very slowly and going over basic programming concepts as if they're breaking you out of the matrix).
Lots and lots of guardrails to not allow slop.
In tsz I have hard gates that disallow doing work in the wrong crate etc.
https://github.com/mohsen1/tsz
> have hard gates that disallow doing work in the wrong crate
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.
tsz is an experiment in giving coding agents full control. On my day job I am a lot more careful. But I've moved on from manually approving every change and instead review the final diff. I noticed manually approving was counterproductive.
Right, I'm giving my agents full control too, but not sure why that'd exclude putting them in a sandbox?
Honestly Rust is an UGLY language. For whatever powers it possesses in memory safety, its cryptic symbology is reminiscent of assembly.
This is a problem when language designers are mathematicians and don’t understand typographical nuance and visual weights.
Why would the language being typographically ugly matter? Python's pretty, but it hides a lot of functional nuance behind that. Rust is terse, but it's also expressive in its terseness.
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.
If I was forced to write it myself, then I'd agree, I'd use Clojure all day before Rust, because it's such a chore to write, edit and read.
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 I was forced to write it myself, i would love to keep writing ruby. What a wonderful language. I dont write ruby anymore, mostly using golang and python.. but ruby still a joy.
It’s funny I got downvoted immediately as expected.
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!
Hardly surprising, you give a strong opinion but you don't actually back that up by any arguments, that stuff tends to be downvoted here. Add some proper reasoning and making it clear why you think as you think, and people will stop downvoting :) Also, stop caring about magic internet points, they don't matter and people downvote random stuff sometimes.
You’re right on both counts.
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
I really don't get the complain about Rust's syntax, it's almost identical to TypeScript's and nobody complains about TypeScript Synthax being ugly …
(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.
To me it looks clean and concise
I’m curious why? Also I’m curious how long you have programmed in Rust?
Clone is not "butchering idiomatic Rust", we gotta stop this nonsense
Sorry, should clarify. .clone() itself isn't inherently unidiomatic when used .
My issue is specifically with how the AI uses it. In AI code, .clone() is almost always used as a brute-force escape hatch
Just like for me as an amateur Rust enjoyer then
So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)
Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).
How many of those tests have you actually read yourself if all of them are generated by AI (also when you're sleeping) ?
This is from 2025 - I would like to see an update now how that system turned out to be after the vibe hype
I feel like there's very little blogs that actually follow up on their experiment. It's just dopamine city.
To me, the real question after reading this, is: Is your new implementation of Azure’s RSL now being used?
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.
Contrarian view: Why English will never be a programming language. https://www.slater.dev/2026/05/why-english-will-never-be-a-p...
It's almost guaranteed with agents you could do the same job with less than half of 100k lines. I don't know whats impressive in lines of code generated by agent.
It just an anchor. If it were 50k would you say the same down to 25k? And if so how many more times would it apply?
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.
Original RSL library is 36k LoC. And this is C++. Rust should be like 50% smaller, that is, 18k LoC. This library is so big that I bet the author has no idea if it works or not. 1300 test generated by AI say nothing about actual quality.
In the end it is just a lot of unmaintainable code quickly generated by AI.
This is uncharitable, but makes a prediction. I imagine you'd bet the author won't be successfully using this, at MS/Uber or wherever they are, in a year time?
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.
Has Rust code generally been found shorter than C++ in practice? I don't see an obvious reason for it.
the interesting thing is how fast it becomes unmanagable.
Also that, I suspect that's correlated to how practical is to have multiple people (with their agents) iterating on it.
> It's almost guaranteed with agents you could do the same job with less than half of 100k lines.
That's great, non-test code is only ~47k lines of code.
For a startup with limited funding, building a product is no more a bottleneck. every one doesn't have the same access to funding!
I have Tarpaulin code coverage check and everytime that it drops below the treshold Claude gives up quickly and just lowers the threshold. I don't know how to overcome it. CLAUDE.md neither AGENTS.md help but the LLM always finds its way.
Is the idea of the runtime contracts similar to the idea of runtime validation? Or are they different in some way?
It is described in the "Code Contracts" section of the article: "Code contracts specify preconditions, postconditions, and invariants for critical functions. These contracts are converted into runtime asserts during testing but can be disabled in production builds for performance". The .NET framework article that he links to: https://learn.microsoft.com/en-us/dotnet/framework/debug-tra...
Is this basically what Dijkstra was saying? I've been thinking how his approach was considered impractical, but may eventually become necessary for security/stability reasons the way things are going. (Seems like new zeroday on HN front page every day now.)
Ah, I missed the reference. Thanks a lot!
How are you keeping the requirement, design, and tasks docs in sync as the code evolves? I'm curious if anyone's landed on a good workflow for this.
Paxos is certainly non-trivial in the sense that tiny changes can break it, but in terms of functionality it is not that big. 50 KLOC just seems like a lot of code to me.
Where can we read the code?
Lessons. There's no such thing as learnings.
Learnings is irritating to me. The way kids use the word aesthetic is irritating too. I wonder if I might be that old man shaking his fist at the clouds, but I have gotten over begs the question, and literally, so maybe not yet...
I understand the instinct, but that's a bit too prescriptive for me.
https://en.wiktionary.org/wiki/learnings
A lesson would be a specific learning activity happening at a specific place and time, administered by a person more knowledgeable than you; like a teacher or mentor "giving a lesson".
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.
So when you cause an incident because you did not pay attention and "learn your lesson" who's the mentor?
This is great example of AI slop and a big problem with AI coding.
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.
All unit tests can pass if you don't assert anything. Just have to make sure to read through all 130k lines of code to check.
Rust is about abstractions more than code. You can ask AI to "Optimize/Test/Clarify" but at the end of the day you should be willing to blindly agree to it's output or spend more time reviewing someone else's code.
Rust code generation consumes lot of token
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
Yes, but it comes with much better “built-in” guardrails to rein in the autocomplete. Especially if compared to something runtime-surprise-prone-if-lovable like Ruby.
This is why I suggested Go.
Rust doesn't add anything over Go for LLM coding.