Rust for AI Coding: Safety Argument Has Policy

Here is the software liability question that nobody at the AI engineering conference put on a slide: when an LLM writes concurrent TypeScript code with a data race, that code ships to production, and a breach follows, who owns it?

Not in the moral sense. In the legal and regulatory sense. The developer who accepted the pull request? The company that deployed the AI coding agent? The model provider whose system generated the unsafe code? Right now, the answer is genuinely unclear — and that gap is not hypothetical. It is the precise territory that NIST's AI Risk Management Framework and the EU AI Act's provisions on high-risk AI systems are trying, with varying success, to define. The language-choice debate that Daniel Szoke, Rust SDK maintainer at Sentry, pressed at the AI Engineer conference is, underneath its technical surface, a debate about where error responsibility sits in an agentic pipeline. That framing is worth taking seriously on its own terms, separate from whether you find Rust appealing.

Szoke's core argument is structural rather than aesthetic. Python and TypeScript dominate AI-assisted development — GitHub noted TypeScript's rise to the top of its contributor rankings in a late-2024 report, attributing the shift in part to AI-assisted development, though the precise causal weight GitHub assigned to AI versus other factors is worth reading carefully in the original Octoverse data rather than treating as settled. What Szoke contests is the logic that follows from that dominance: because LLMs write Python and TypeScript fluently, those languages are the right substrate for agentic coding. His counter is that fluency is precisely the problem.

"The dynamic and flexible nature of the languages is what makes it easy for the agent — or for the LLM, I should say — to write JavaScript, Python, TypeScript," Szoke said. "But this same flexibility also makes it very easy to make mistakes."

The mechanics of why matter here. TypeScript's any type and Python's optional typing provide a trapdoor through which an LLM can pass a value of the wrong type with no immediate consequence. The consequence arrives later, in production, intermittently, in a context that makes root-cause analysis expensive. Szoke's concurrency example is crisp: 100 threads each incrementing a shared counter by one, where the expected result — 100, assuming no races — will occasionally not materialize because the underlying reference-counted type (Rc<RefCell<i32>>) is not designed for cross-thread access. In TypeScript, this compiles and runs. The defect surfaces statistically, not deterministically. In Rust, the compiler refuses. It names the offending type, explains the Send trait requirement, and points the agent at a thread-safe alternative. The bug never reaches production because it was never allowed to compile.

That is a meaningful property. It is also a bounded one, and Szoke's framing deserves some pressure here. Rust's compiler guarantees memory safety, type safety, and thread safety. It does not guarantee that the code does what you intended it to do. Business logic errors, incorrect API call sequences, flawed algorithms — the compiler is indifferent to all of these. When Szoke says the Rust compiler finds errors that an AI review agent "might not even find," that is true for the class of errors the compiler is designed to catch. It is not a general claim about correctness, and treating it as one would be a mistake — one that enterprise teams evaluating Rust for agentic pipelines should be precise about.

The stronger version of Szoke's argument is this: deterministic enforcement is categorically more reliable than probabilistic error-catching. Tests can only prove incorrectness when they fail. An LLM writing tests after implementation is likely testing implementation details rather than behavior. Code review agents will miss some of what they're supposed to find, some of the time. The compiler misses nothing within its domain, every time. That asymmetry is real, and it matters for any organization trying to construct a defensible software supply chain with AI-generated components.

"LLMs are fallible. They will always be fallible because they're by design non-deterministic systems," Szoke said. The policy implication he left on the table: if your production code is generated by a non-deterministic system and checked by another non-deterministic system, the probability of a defect shipping is not zero — it is a function of how many deterministic constraints you impose between generation and deployment.

This is where the talk's institutional context becomes relevant, and not in a way that discredits the argument but in a way that shapes which parts of the conversation are having. Szoke is a Rust SDK maintainer at Sentry, a company that sells observability infrastructure. Sentry has a direct commercial interest in Rust adoption: more Rust in production means more demand for Rust SDK tooling. Szoke acknowledged this explicitly — the talk ended with a slide advertising three months free on Sentry's business plan. None of that makes the technical argument wrong. But the loudest advocates for Rust in AI pipelines are, by a notable margin, people employed by companies with Rust infrastructure businesses. The engineers writing the most Python in production, the teams managing the TypeScript codebases that process financial transactions or health records, are largely not at these conferences making the countercase. That absence is not evidence that the countercase doesn't exist.

What's also absent from the Szoke framing, and from most of this debate, are the voices of enterprise risk and compliance teams — the people who will actually be deciding language standards for AI-generated code at scale. They are not optimizing for developer experience or LLM fluency. They are reading the EU AI Act's requirements around human oversight of high-risk systems, watching NIST update its Secure Software Development Framework to account for AI-generated code, and calculating what their liability exposure looks like when an AI agent writes the authentication module. For that audience, Szoke's argument that Rust's compiler functions as a deterministic audit layer in an otherwise probabilistic pipeline is not just technically interesting — it is potentially a compliance argument. Framed correctly, memory-safe languages in agentic pipelines could become an enterprise procurement standard, the same way SOC 2 compliance became a checkbox on vendor questionnaires.

The lever, if one exists, is probably not developer preference. Individual engineers do not decide that their company's AI coding agents will target Rust rather than Python. Standards bodies do. Federal procurement guidelines do — and the Biden administration's 2024 memory safety guidance from the Office of the National Cyber Director, which explicitly named Rust as a preferred memory-safe language, already created a template for how language choice can become a regulatory recommendation. Liability insurers do: when cyber insurers start pricing AI-generated code risk and asking whether the pipeline included deterministic safety checks, the answer to that question will move faster than any conference talk.

Szoke offered a sideways reference to Yuval Noah Harari's book Nexus to make a philosophical point about the fundamental otherness of LLM cognition — the argument being that because LLMs think differently from humans, their failure modes are genuinely alien and therefore less predictable than human error. The attribution of the "alien intelligence" framing to Harari specifically should be read with some care, as that framing circulates among multiple writers, but the underlying point stands regardless of its provenance: you cannot rely on human intuitions about where the errors will be. Which, translated to policy, means you cannot rely on human code review alone to catch them.

That is the logic that makes compiler-enforced correctness not just a developer preference but a governance architecture. Whether it becomes one will be decided not in developer communities, but in procurement offices, standards working groups, and the fine print of AI liability insurance policies. The technical argument for Rust in agentic pipelines is Szoke's to make. The policy argument — that language choice in AI-generated software is a risk management question with regulatory consequences — is waiting for someone to make it directly to the people who write the rules.

Samira Barnes covers technology policy and regulation for Buzzrag.