# Why Rust Is the Best Language for Vibe Coding > Vibe coding is only as safe as the thing checking the output. Rust ships the strictest checker in mainstream use, which makes it a surprisingly good fit for AI-written code. By Alexandr Bykov, OxiSoft. Published 15 September 2026. Canonical: https://oxisoft.io/blog/rust-for-vibe-coding/ Vibe coding is the practice of describing what you want, letting the model write it, and shipping without reading every line. People have strong feelings about this. Most of the arguments miss the actual risk. The risk is not that the model writes bad code. Good engineers write bad code too. The risk is that nobody checks. When a human writes a function, a second human usually reads it. When a model writes forty functions in an afternoon, the reading does not happen, and the only thing standing between you and production is whatever your tools catch automatically. So the real question is not "should I let AI write this." It is "what is checking the output, and how much does it actually catch." That reframing is what makes Rust interesting, because Rust has the strictest automatic checker in mainstream use, and the model has to satisfy it before you ever see the code. ## The compiler is a reviewer that never gets bored A type system is a set of claims about your program that a machine can verify. Weak type systems verify very little, so most mistakes survive until runtime, which usually means until a customer finds them. Rust verifies a lot, and it refuses to build until every claim holds. This changes what "the model finished" means. In a permissive language, finished means the text looks plausible. In Rust, finished means the code satisfied thousands of mechanical checks about memory, ownership, lifetimes, null values and error paths. That is not a proof of correctness, and anyone selling it as one is overselling. But it eliminates entire families of bug that AI code is otherwise prone to, and it does so before the code reaches review. ## Errors that cannot be quietly ignored Rust has no exceptions and no null. A function that can fail returns a `Result`, and a value that might be absent is an `Option`. You cannot use either without first dealing with the failure case. Not "should not." Cannot. The program does not compile. This matters more for generated code than for handwritten code. The single most common shortcut in AI output is the forgotten unhappy path: the network call with no timeout branch, the parse with no malformed-input case, the file read that assumes the file is there. In most languages that code compiles, passes a casual glance, and fails in production at 2am. In Rust the same shortcut is a build error with a message naming the exact case that was skipped. There is a related trick with `match`. If you add a new variant to a type, every place that handles that type stops compiling until the new case is handled. When a model refactors a data structure across thirty files, the compiler produces the complete list of everything that must change. No grep, no guesswork, no forgotten call site three modules away. ## The feedback loop is the real advantage Rust has unusually good error messages. They name the problem, point at the exact span, explain the rule that was broken and frequently print the corrected code. Those messages were written for confused humans. It turns out they work just as well for a model. An agent loop of write, build, read the error, fix, build again converges in Rust in a way it does not in languages that fail at runtime with a stack trace and no suggestion. Each iteration is verified by the compiler rather than by hope, so the loop tightens toward working code instead of drifting. This is the point people miss when they call Rust hard. It is hard to hold in a human head, because the rules are numerous and the borrow checker has opinions. A model does not experience that as difficulty. It experiences it as an unusually detailed specification with an automatic grader attached. ## Concurrency bugs that never happen Data races are the worst class of bug to find by review. They are timing dependent, they do not reproduce reliably, and reading the code rarely reveals them. They are also exactly what you would expect AI-written concurrent code to produce. Rust rejects them at compile time. The rules that make the borrow checker annoying are the same rules that make it impossible to share mutable state across threads without synchronisation. A whole category of bug that normally requires senior review simply cannot be expressed. For software where a race means corrupted user data rather than a slow page, that guarantee is worth the compile times on its own. ## Memory behaviour you can predict Rust manages memory through ownership rules checked at compile time, with no garbage collector at runtime. Very few production languages do this. Most either collect garbage, which is fine until a pause lands at the wrong moment, or hand you manual memory management and trust you not to make a mistake, which is how we got several decades of security advisories. For generated code this matters twice. The output has no hidden runtime cost to discover later, and the mistakes that manual memory management invites, the use-after-free and the double free, are compile errors rather than vulnerabilities. ## One toolchain, no configuration argument `cargo build`, `cargo test`, `cargo clippy`, `cargo fmt`. Same four commands in every Rust project on earth. Formatting is settled, linting is built in, the test runner ships with the language, and examples inside documentation are compiled and run as part of the test suite. This sounds like a small thing. For automated workflows it is not. An agent that must first discover which of five test runners a project uses, and which of three formatters, will waste most of its attention on archaeology. In Rust the verify step is identical everywhere, which means the loop can be entirely mechanical. One more mechanical guarantee worth knowing: a single line at the top of a crate, `#![forbid(unsafe_code)]`, makes it a compile error for anything in that crate to use `unsafe`. You can prove the model never reached for the escape hatch, rather than trusting that it did not. ## Where this falls apart Three honest caveats, because an article that only lists advantages is an advertisement. Compile times are slow. The tight loop that makes Rust good for agents is also the loop you wait on, and on a large project you will wait. The ecosystem is smaller than the mainstream scripting languages, so models have seen less Rust than they have seen of the popular web stacks. For common work this is no longer a problem. For an obscure crate it still is, and the output gets noticeably more confident and more wrong. And none of this makes the code correct. Rust verifies memory safety, type safety and exhaustive handling. It has nothing to say about whether you built the right feature, whether the business logic makes sense, or whether the thing is pleasant to use. A program can be entirely free of undefined behaviour and still be completely wrong. ## The actual argument Vibe coding is not reckless because a machine wrote the code. It is reckless when nothing verifies the code before it ships. Rust moves a large share of that verification from human attention, which is scarce and unreliable at volume, to the compiler, which is neither. You still review the design. You still decide what to build. You just stop spending review budget on whether a pointer is valid. That is the same reason we [pick boring, strict tools on purpose](/blog/why-we-use-go-flutter-rust/), and it fits how we already [work with AI day to day](/blog/ai-driven-development-with-claude-code/): let the machine handle the parts a machine can prove, and spend the human hours on the parts it cannot.