Learnings from 100K lines of Rust with AI (2025)
An engineer claims to have built a multi‑Paxos consensus engine in Rust with heavy AI assistance, prompting debate over whether large, rapidly generated codebases can be trusted. Commenters question the low test density, the explosion from a 36K‑line C++ reference implementation to ~100K+ lines of Rust, and how well LLMs handle Rust’s lifetimes and concurrency without resorting to clones and mutexes everywhere. Others report positive experiences with “vibe coding” in Rust and other languages, arguing that strong type systems and strict compilers make AI‑assisted development more reliable when combined with careful architecture, tooling, and human review.
Lines of code & maintainability
- Many see 100k–130k LOC as a red flag, especially since Azure’s original C++ RSL is ~36k LOC.
- Some argue Rust isn’t necessarily shorter than C++, and non-test Rust code here is only ~45–50k LOC.
- Critics view the result as “AI slop”: large, likely unmaintainable, and possibly not functionally equivalent to RSL.
- Others say the impressive part isn’t LOC but that a single person + agents could build such a system quickly.
Testing & correctness
- ~1,300 tests for 130k LOC (or ~50k non-test LOC) is seen by many as too sparse, especially for distributed systems.
- Several argue that in this domain, test and tooling code should greatly exceed production LOC.
- Skepticism that AI-generated tests actually assert meaningful properties; concern that passing tests may be vacuous.
- Some ask whether the real proof would be long-term successful use in production, which is currently unclear.
AI coding in Rust vs other languages
- Mixed experiences: some report constant lifetime errors and brute-force use of
clone()/Rc/Arc<Mutex<…>>. - Others find Rust excellent for LLMs when using tight feedback loops (
cargo check/test, clippy, formatting hooks). - One camp claims Rust is “nearly perfect” for LLMs due to strong typing and compile-time safety; another prefers Go, Kotlin, JS, or even C/Haskell as easier or more efficient targets.
- Concern that overuse of interior mutability turns safety issues into deadlocks and liveness failures.
Architectures, agents & guardrails
- A recurring problem: LLMs create sprawling, tangled architectures where small changes touch many modules.
- Suggested mitigations: multiple small crates, hard LOC limits per file, strict pre-commit hooks, and repo “guardrails” enforcing project conventions.
- Several tools/workflows are mentioned that orchestrate “beads”/tasks, static checks, and agent-review steps.
Specs, multi-LLM workflows & trust
- Some teams have one model write specs and another critique/implement them, then cross-review implementations.
- Others argue the same model in a fresh context is enough; the key is breaking bias by resetting context.
- A skeptical thread notes LLM outputs vary between runs and can confidently contradict themselves; warns against over-trusting specs or plans without human review.
Debate over LLM “reasoning”
- Long subthread on whether LLMs truly “reason” versus merely predict tokens.
- One side points to apparent reasoning behavior; the other emphasizes lack of cognition and deterministic understanding.
- No consensus; participants agree only that LLMs can be useful even if their internal process is opaque.