More engineering leaders are asking me some version of this question: one part of our system needs Rust, we can’t find Rust developers, and our engineers already work with AI coding agents every day. Do we still need to hire Rust developers?
My short answer: for most backend work, no. You need senior engineers who understand what the system must do, AI agents that write the Rust, and a process that checks every change. Deep Rust expertise still matters in a few specific cases, and for some products Rust is the wrong choice altogether.
A caveat first. The public success stories so far, Anthropic’s Bun runtime and GitHub’s Copilot runtime, were both ported to Rust mostly by agents, and both come from companies that sell those agents. Outside them, few teams have results to show, ours included.
Why this question is coming up now
First, AI coding agents such as Claude Code and Codex now write a large share of the first drafts. The engineer’s job is moving from typing code to specifying, reviewing and testing it.
Second, the case for Rust got stronger. It performs on par with C and C++, uses little memory, and in safe code blocks whole classes of memory bugs before the code runs. Microsoft found that about 70% of the vulnerabilities it assigns a CVE number each year are memory safety bugs. When Google moved new Android code to memory safe languages, that share fell from 76% in 2019 to 24% in 2024.
The obstacle was always people. Rust takes longer to learn than Java, C# or JavaScript, and experienced Rust developers are hard to find. If AI writes most of the code, does the engineer still need to know Rust deeply?
Can AI write production Rust?
Yes, on one condition: someone qualified checks it.
Rust’s strict compiler suits agents well. Code that could cause memory errors or data races usually won’t build, so the agent gets an error and fixes it before a person ever sees the change. Python and JavaScript are memory safe too, but they rely on a garbage collector at runtime, which costs speed and memory. Rust gets the same safety at compile time, with no runtime cost.
In my experience, Rust from an agent often compiles on the first try, and a clean build feels like proof that the code is right. It isn’t. When Canonical funded research into translating AppArmor from C to Rust with language models, the hard problem was proving the new code behaved like the old.
What the compiler catches, and what it misses
The compiler removes one class of bugs almost entirely. Everything that depends on what the software is supposed to do still needs tests and people.
| Problem | Caught by the Rust compiler? | How to catch it |
|---|---|---|
| Use-after-free, dangling references | Yes, in safe code | Compiler |
| Data races between threads | Yes, in safe code | Compiler |
| Type mismatches | Yes | Compiler |
| Ignored errors | Partly: an unused Result warns, but let _ = silences it | Warnings as errors in CI |
| Wrong business logic | No | Tests written from the spec, senior review |
| Missed edge cases in requirements | No | Acceptance criteria in the spec, review |
| Panics from unwrap(), expect() and indexing | No | Clippy lints that are off by default, tests |
| Integer overflow | Debug builds panic; release builds wrap unless you enable overflow checks | Checked arithmetic, tests |
| Deadlocks and race conditions | No | Design review, load tests |
| Risky dependencies the agent adds | No | cargo audit and cargo deny in CI |
| Memory bugs inside unsafe blocks | No | Keep unsafe rare, review every block by hand, run Miri |
| Slow code (extra copies, allocations) | No | Benchmarks against agreed targets |
Speed is usually the reason to choose Rust, so make it measurable: benchmark each critical path against an agreed target, and treat a miss like a failing test.
Who reviews the code if nobody on the team is a Rust specialist?
A senior engineer who understands what the system must do.
A strong engineer reviews AI-generated Rust like any other code: does it match the spec, handle the edge cases, hold up under load and stay maintainable? Few of those questions depend on Rust syntax.
Rust-specific problems will still come up: lifetimes the agent can’t untangle, async code that blocks a thread, a dependency with a questionable unsafe block. A senior engineer solves the first few with the agent and the documentation. After three to five of these, they can handle most Rust problems in service code.
Put the structure in place before the agent writes anything. Each task gets a written spec with acceptance criteria and a short plan that an engineer approves. Every change goes through strict lints and automated tests, code where speed matters gets benchmarks, and a senior engineer signs off on every merge. Agents never approve their own output.
A starting point for Cargo.toml:
[lints.rust]
unsafe_code = "forbid"
[lints.clippy]
unwrap_used = "deny"
expect_used = "deny"
[profile.release]
overflow-checks = trueThe build fails if anyone, human or agent, writes unsafe code.
Blocks shortcuts that crash the program at runtime.
Number overflows stop the program instead of silently producing wrong values.
- The build fails if anyone, human or agent, writes unsafe code.
- Blocks shortcuts that crash the program at runtime.
- Number overflows stop the program instead of silently producing wrong values.
In Claude Code, put these rules in the project’s CLAUDE.md so the agent runs cargo clippy and cargo test before it hands over a change.
When you still need a Rust specialist
Some work needs deep Rust experience on the team, as a hire or an advisor:
- Code that relies heavily on unsafe Rust: custom data structures, bindings to C libraries, low-level drivers.
- Embedded and firmware code with tight memory limits and no standard library.
- The last 10% of performance: custom allocators, lock-free structures, tuning the async runtime.
- Libraries other teams build on, where a poor API decision is expensive to undo.
Even then, one specialist reviewing the hard parts is usually enough. The rest of the team can work the way described above.
Rust vs Go for backend services
Go is the most common alternative for new backend services, so the comparison comes up often. Go is simple, compiles fast, and its garbage collector is fine for most APIs.
Rust earns its place when tail latency has to stay flat under heavy allocation, when memory per instance drives your cloud bill, or when you need the strongest safety guarantees. Typical examples are payment processing, real-time data pipelines and services that run on thousands of instances.
With agents writing the code, the choice comes down to what your product needs at runtime.
When Rust isn’t worth it, even with AI
Cheaper Rust is still the wrong tool for some products. I’d pick something else when:
- The product is mostly forms, CRUD screens and integrations. Python, TypeScript or Go will ship faster, and speed won’t be your bottleneck.
- You’re still looking for product-market fit. Prototypes change every week, and Rust’s strictness slows that down even with agents.
- Nobody can judge whether the generated code is right. AI moves the work from writing to reviewing. Someone still has to do the reviewing.
- A key dependency has no mature Rust equivalent, and wrapping it would cost more than the performance gain.
A simple test: name the number Rust should improve, such as latency, memory, cloud cost or crash rate. If you can’t, you probably don’t need Rust yet.
How to test the idea on one component
Don’t rewrite a system to find out whether this works. Pick one component and run a pilot.
1Choose a component that is slow or expensive to run, with clear inputs and outputs.
2Record the baseline: latency, memory use, infrastructure cost, error rate.
3Write the spec and the acceptance tests before any code is generated.
4Have AI agents build the Rust version against that spec, with a senior engineer reviewing every change.
5Run both versions side by side on real traffic or recorded data.
6Compare the numbers, plus the hours your team spent on review.
A pilot like this usually takes a few weeks. If the numbers don’t move, you’ve learned that cheaply. If they do, you have a pattern you can repeat on the next component.
The short version
If Rust’s speed and safety would move a number your business tracks, the shortage of Rust developers matters less than it did two years ago. My bet is that a senior team with agents and strict checks can build and run it. Test that bet on one component before you commit.
