A scientific discovery can be a work of magic, because it takes imagination to come up with the solution.

— Nicolas Cage, Interview Magazine, conversation with Marilyn Manson (excerpt)

The usual advice is that Rust is a poor fit for a small team in a hurry. Its strict checks slow down the first version, and a small team cannot afford to slow down.

Coding agents changed that trade. When Rust rejects a change, the agent reads the error and tries again. It still needs supervision, but much of the slow part now lands on the agent instead of a senior engineer.

The checks also matter more than they used to. Agents can write code faster than a small team can read it. Human review does not grow with that volume. Automatic checks run on every change, whoever or whatever wrote it.

Agents can carry Rust’s cost. The team keeps its checks.

I lead a small team that builds a backend and an agent harness. The harness is the software around an AI agent. It decides what the agent may do, remembers how far the work got, and handles what happens when a step fails. Both have to serve more customers and more integrations without a bigger team to run them. Rust does not prove that such a system will scale. The last section covers the evidence I would ask for.

Let the tools enforce the rules

Rust will not build code that could use a value that is not there, skip a case in a decision, or share data between threads unsafely. In many languages, those mistakes wait for a reviewer, a test, or a customer to find them.

Spend scarce review time on judgement, not on rules a tool can check.

A tool can check whether a change follows a rule. A person still decides whether it is the right rule for the product. Rust helps with the first job. The second stays with you.

This is my experience, not a measured productivity gain. I would not put a number on it in a budget.

Give each product rule one home

Many products now run in more than one place: on your servers, in the customer’s browser, on a phone. Each version can work differently underneath. They should not disagree about what counts as a successful transaction.

When each version keeps its own copy of that rule, every change becomes a coordination job. Someone must find every copy, update it, and confirm that the answers still match. An agent can write those updates. Your team still carries the risk of missing one.

Rust can run the same code on a server, inside a browser through WebAssembly, and inside a mobile app. You write the rule once. Each platform adds only the thin layer it needs to call it. 1Password’s engineering lead describes the same shape: a headless Rust core that holds all the business logic, wrapped in a thin native interface on each platform.

Fewer copies of a rule leave fewer places for it to drift.

Each platform still needs its own release and its own tests. Sharing the code does not prove that each version behaves correctly. It removes one way for them to disagree.

Other languages can share code across platforms too. The useful question for a leader is how much of the product the team maintains more than once.

Turn repeated review comments into checks

Every engineering team has comments its senior people leave again and again. Some are real design calls. Others are rules that a machine could check.

For example, suppose every part of your product that calls an outside service must report what happened when a call fails. Did the work happen, not happen, or is the result unknown? You can design the code so that a new part will not build until it gives an answer. “We cannot tell” is an allowed answer. Leaving the question out is not.

Now no reviewer has to remember to ask. The requirement travels with the code, including when an agent writes the next change.

A rule the build enforces does not depend on a reviewer’s memory.

Rust suits this well, because the build can require code to handle every possible outcome. It still takes deliberate design. Choosing Rust does not turn company policy into a check on its own. Your team decides which requirements can be enforced, then shapes the software around them.

A passing build is not proof

Automatic checks only answer the questions someone thought to ask.

Picture a product that runs on four platforms. A new feature must accept large responses from a partner service. One platform accepts them. The other three would reject them. Every check passes, because no check asks that question.

A careful review or a targeted test can catch that gap. But “all checks pass” only describes the checks you ran. It does not show that you asked every question that matters.

Ask the team to show that the same customer action gets the expected result on every platform.

The demonstration should include failure. If a partner service stops responding, does each version retry, stop, or ask a person for help, as intended? The language cannot decide that policy. The business has to.

Budget for the expertise

Rust still has a learning cost. Its checks can slow early work. An agent can also spend a long time fighting a design it does not understand. Someone on the team must know Rust well enough to notice and change direction.

Hiring is part of that cost. Plan time to hire or grow engineers who can own the Rust code, and time for review and testing. An agent that produces a first version quickly does not make those costs disappear.

The case is weaker for a small tool that runs in one place and rarely changes. Rewriting a working system needs its own case. My reasons for choosing Rust here do not make every other language choice a mistake.

Four questions before you back it

You should be able to judge a proposal like this without reading Rust. I would ask the technical lead four questions:

Start with one part of the product. Review the result before you widen the commitment. For a backend or a harness, ask to see it under expected load and recovering from interrupted work. Count the effort to run and change it, not only the time it took to write.

Rust puts more of a small team’s rules into the code, where every change must pass them. Proving that the system holds under load, and knowing how to recover when it does not, is still the team’s job.