We've been arguing for years that Rust should be a central language in enterprise organisations. I wrote our first post on it back in 2019 (Ferris the pair programmer, for those who remember), and by 2020 we were building WebAssembly and wasmCloud work in Rust. In 2023 we keynoted Rust Nation UK, open-sourced Crux, and joined the Rust Foundation, whose write-up said I'd been championing the language for the last four years. That felt about right. Every year since, we've come back to the same argument with more evidence.
We recommend it to clients, repeatedly. It's still a battle. The objections haven't changed in a decade: nobody here knows Rust, we don't want another language to maintain, our people can't read it. For a long time those were fair points, and I wouldn't have argued with anyone making them.
But the conversation has shifted. In many of our client engagements now, the question is how to capture agent-assisted engineering properly, and I'd argue that to do that, Rust is more critical than ever. It's stopped being a technology choice and has become a precondition for effectively embedding agent-assisted engineering practices.
A quick reminder of what Rust is
Rust is a systems language designed for correctness. Its own strapline is "empowering everyone to build reliable and efficient software", and it means it. The ownership model and the borrow checker mean whole classes of bugs (e.g. use-after-free, data races, nulls where you didn't expect them) can't be expressed at all, so they're caught at compile time rather than in production. The type system makes you handle every case. There's no garbage collector, so it runs as fast as C or C++ without the crashes. And most people using Rust would agree that "if it compiles, it works", more often than not. It also pulls problems from the future: the bug that would've woken you at two on a Saturday morning is a compile error now.
For an enterprise, that adds up to fewer incidents, cheaper changes and software that still works years later. Google's Android team has the numbers: memory-safety bugs there are down from three quarters of all vulnerabilities in 2019 to under a fifth, and their Rust changes are rolled back about four times less often than their C++ ones. In my experience, large Rust codebases stay workable in a way that object-oriented ones don't. They don't go brittle. That's one of many reasons why we recommend it, and it's why the strictness (that sometimes puts people off) is the point rather than the price.
Rust must become the agent-assisted engineering language choice
An agent is creative and non-deterministic: point it in the right direction, and it'll happily produce something plausible (which covers an awful lot of ground). What you need against that is something rigid that pushes back. You can't have high confidence that the agent has done the right thing unless you know it can't have done the wrong thing. Rust is that pushback, and it comes built in.
The compiler refuses bad code on everything, and (this is the bit people miss) its error messages are unusually good. For an agent iterating in a loop, those messages are absolute gold dust! Microsoft Research tested exactly this loop. They dug through the history of the hundred most-used Rust crates, found 182 commits that didn't compile (real mistakes by real maintainers, later fixed by hand), and set a model on them with nothing but the compiler's error messages to guide it. It got about three-quarters of them building again, and the fixes held up when the researchers checked them. That was GPT-4, in 2023. Type inference stops at function boundaries, so every signature is a complete contract, and the agent can reason locally (deliberately, says the Rust Book). No spooky action at a distance.
And the learning curve, the thing that has put humans off for a decade, doesn't exist for an agent. It predicts tokens, and it's been trained on a great deal of Rust. The human cares… the agent doesn't. The agent maintains it too, and the codebase does more of the work than you'd expect, because the patterns, the tests and the quality bar are all in there, so every new feature, every new platform and every version bump starts pointed the right way. Crux adds a second layer of confidence: the app’s behaviour in a pure Rust core (the ports and adapters pattern, or hexagonal architecture, or whatever we want to call it), thin native shells on top, and tests that run in seconds.
I should be straight about the benchmarks. In my opinion, agents were poor at Rust until about a year ago. Then the change happened. With the latest models, agent-written Rust code fully meets the quality bar. The agent’s code is now correct, idiomatic, and often better than an experienced Rust engineer would write.
Here it is working
We're trying this out at home first: an HR and expenses application for Red Badger, built as an experiment to see whether we can replace some of the SaaS we pay for with software we own. It's a draft, not yet in production, but it's an end-to-end example of everything above.
We're designing and building it exactly as we would for a client, to the same standard: spec, design and plan agreed before anything gets built, the same event-sourced Crux architecture we'd propose to you, and every change landing as a small pull request that we read and approve.
Around 100,000 lines of Rust (built part-time over a couple of months), and not a line of it written or edited by hand. I've yet to touch the code myself. I asked for an Android version most recently, and had a working first screen six hours later, because the behaviour already lived in the Crux core. Six hours! Around 500 tests on the core, all green and clippy-clean. That's an order of magnitude faster than by hand.
Most of it is even better for having been machine-written than it otherwise would have been.
I asked to add VAT to receipt scanning and it worked out that a receipt can carry several rates, built the table for them, and added HMRC's check-digit validation for the VAT number without being asked. I'd have potentially missed that, or taken much longer to capture it in my design requirements.
This proven success changes everything, yet changes nothing: if a world-class team had built this over two years it'd look like this, and there's none of the slop you'd expect at that speed, because the compiler won't let it through. Whether it earns its place against the SaaS it's meant to replace is the next test, and I'll write that up too.
Our big bet
I am absolutely convinced that Rust should and will become the language of choice for agent-assisted engineering. The foundations are already there. The irony is that by the time it does, nobody will know it's Rust, because they won't need to.
If you're working out what agent-assisted delivery should look like in your organisation, let's talk!
Interested in how Red Badger applies hypothesis-driven validation inside complex enterprises? Get in touch.