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 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 being seeming extermely confident sounding.
Its scary how confident you people are in these outputs.
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
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.
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...
But python or typescript are full of errors all the time. I rather fallback to perl than python. Perl has been excellent all along.
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.
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.
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.
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 ;)
Fixed.
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
Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).
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.
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!
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.
This is from 2025 - I would like to see an update now how that system turned out to be after the vibe hype
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.
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.
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