// blog/python-or-rust-for-ai-assisted-coding
Python or Rust for AI-Assisted Coding


Python remains a practical default for a large class of software, especially where its libraries already contain the domain knowledge a project needs. But AI-assisted development changes one part of language choice that used to dominate every other consideration: the human cost of writing, debugging, and maintaining systems code. The question is whether the project can benefit enough from Rust's runtime properties to justify choosing it while agents handle more of the implementation work.
Why did Python become the default?
For much of the past decade, Python and TypeScript won new-project decisions because they compressed the path from idea to working software. Their ecosystems were large, their hiring pools were familiar, and a team could assemble a useful product quickly.
The surrounding libraries mattered as much as the language. Python developers could reach for FastAPI, Django, PyTorch, and a long tail of packages. JavaScript teams had React, Next.js, and npm. The usual calculation was straightforward: a language that ran less efficiently could still be the better business choice if it let humans ship much sooner.
Rust, Go, and C++ carried a different bill. They promised performance or stronger safety properties, while demanding fluency in more difficult concepts, more careful build workflows, and longer debugging cycles. A team could promise itself a rewrite later. The rewrite often stayed on the roadmap.
That calculation depended on an assumption: humans would write most of the code. Noah Mitchem's argument is that coding agents are putting pressure on that assumption, particularly for languages with compilers and type systems that give models rapid, structured feedback. His essay is useful because it treats language choice as an engineering constraint rather than a language-war preference.
Why do coding agents change the Rust tradeoff?
An agent working in a typed compiled language can propose code, run the compiler, read the errors, revise the implementation, and repeat. The compiler turns many mistakes into explicit work items: a mismatched type, an invalid borrow, an absent method, or an unhandled interface change.
That loop is especially important for Rust. Rust asks developers to satisfy strict ownership and type rules. For a human under delivery pressure, those rules can turn a small feature into a long evening. For an agent that can repeatedly compile and repair its work, compiler output becomes part of the task environment.
Mitchem quotes CtrlAltDwayne's concise version of the idea: Rust's compiler feedback gives models a tight self-correction loop. That does not make every Rust task easy, but it does change the implementation cost of many well-bounded tasks, particularly when a repository has tests, clear interfaces, and a command an agent can run after each edit.
The source also points to recent systems-language work as evidence that the frontier has shifted:
- Microsoft ported the TypeScript compiler to Go for TypeScript 7.0 beta, which the source describes as roughly 10 times faster than 6.0.
- Nicholas Carlini used 16 parallel Claude agents across nearly 2,000 Claude Code sessions to produce a Rust C compiler, at a reported cost just under $20,000.
- Steve Klabnik used Claude to build Rue, a systems language implemented in roughly 70,000 lines of Rust.
- Andreas Kling ported Ladybird's JavaScript engine from C++ to Rust with Claude Code and Codex, reporting byte-for-byte parity and no regressions across more than 65,000 combined tests.
Those examples come with important caveats. They are unusually capable engineers working on projects with concrete targets and extensive validation. They still show the useful pattern: when an agent has a clear target, a test suite, and a fast verifier, a language's human learning curve becomes less decisive. The underlying examples and figures are collected in Mitchem's source essay.
What makes a language effective for coding agents?
The language itself matters, but the development loop matters more. An agent benefits from a repository that can tell it whether a change worked.
| Project property | What the agent can do with it |
|---|---|
| Fast compilation | Make more repair attempts within a task |
| Strong types | Detect invalid interfaces and data assumptions |
| Useful test suite | Check behavior rather than syntax alone |
| Clear modules | Limit the scope of a change |
| Good documentation | Infer intended behavior before changing code |
Rust and Go fit this model well because they combine strong checks with mature tooling. The claim does not extend equally to every language with a strong type system. Mitchem specifically notes that AI-generated code quality is weaker, for now, in smaller ecosystems such as Zig, Haskell, and Gleam. Training data still shapes what a model can produce and repair reliably.
Before choosing a language because an agent can write it, ask whether the agent can verify its work in that language and repository.
A capable agent with no tests often produces plausible code that has no reliable proof of correctness. A modest agent in a repository with fast tests and compiler checks can make repeated, grounded progress.
When does Python still make more sense?
Python remains the right answer when the value of the project lives in Python's ecosystem, when operational constraints favor it, or when a runtime boundary makes native components awkward.
PyTorch is the clearest example named in the source material. Mitchem cites its position in deep-learning research and observes that model weights do not care what language wraps them. A project built around the Python research stack may gain little from moving its application layer into Rust merely because an agent can generate Rust.
The same applies where the service is mostly orchestration around mature Python libraries. If the main engineering risk is getting a workflow, model integration, data transformation, or research iteration right, Python's existing packages can remain the shortest path to a correct result.
There are also deployment constraints. The source notes that Prisma replaced its Rust query engine with a TypeScript/WASM core, reporting an 85% bundle-size reduction and query performance improvements of up to 3.4 times. It also calls out native Rust binaries as a poor fit for some serverless environments. Performance arguments can reverse when packaging, startup behavior, and target runtime dominate the system.
Use Python when its ecosystem contains the hard-won implementation a project needs, or when the execution environment rewards Python's deployment model. AI assistance does not erase those conditions.
When should an AI-assisted team choose Rust?
Rust earns serious consideration when runtime cost, memory use, predictable latency, binary distribution, concurrency safety, or a native integration is central to the product.
It also becomes more compelling when a team can define a tight agent loop:
1. Give the agent a bounded change with acceptance criteria.
2. Require formatting, compilation, and targeted tests after edits.
3. Review the diff and test output.
4. Expand the task only after the smaller change is proven.
This is different from asking an agent to "build the system in Rust." That prompt hides the architecture, validation plan, interfaces, and failure conditions that let the tool correct itself.
The source's examples are all structured around feedback. Kling had test suites with more than 65,000 combined tests. Carlini's compiler had demanding compatibility targets, including booting Linux 6.9 on x86, ARM, and RISC-V, and compiling software such as QEMU, FFmpeg, SQLite, PostgreSQL, and Redis. Those are meaningful validators. They make a large generated codebase inspectable through behavior.
A new Rust project does not need a benchmark suite of that scale, but it does need tests that state what must remain true. For an API, that may mean request and response contracts. For a parser, it may mean a corpus of valid and invalid inputs. For a migration, it may mean old and new implementations execute against the same fixtures.
Is the ecosystem argument disappearing?
The argument is changing shape rather than disappearing. Much of Python's current performance-sensitive plumbing is already implemented in Rust. Mitchem points to Pydantic's validation core, Polars, Hugging Face tokenizers, and orjson. He also cites the JetBrains 2025 Python survey, where Rust usage for Python binary extensions reportedly rose from 27% to 33% in a year.
Astral is another useful example. Founded by Charlie Marsh in 2022, it produced Ruff, uv, and ty in Rust. The source says those tools reached hundreds of millions of monthly downloads and reports that OpenAI acquired Astral on March 19, 2026, citing an internal estimate that uv saved Codex roughly one million minutes of compute weekly.
The implication is less dramatic than "Python is over." Python users can keep Python at the interface while relying on Rust where it improves the underlying tool. That hybrid model is often the sensible one:
| Layer | Language choice to evaluate |
|---|---|
| Research and model experimentation | Python where the ecosystem is decisive |
| Performance-critical library | Rust where profiling justifies it |
| Command-line tooling | Rust or Go when a standalone binary helps |
| Web product surface | Use the stack whose deployment constraints fit |
| Existing mature service | Change languages only for a measurable reason |
A rewrite needs a reason stronger than agent enthusiasm. Existing systems contain production knowledge that may be absent from tests, including operational workarounds and edge-case behavior. A coding agent makes a port cheaper, but it does not make the unknown parts of a system disappear.
Why do tests and documentation become more valuable?
The source reports that Armin Ronacher ported his Rust library MiniJinja to Go using an agent in a ten-hour run, with three supervised hours and seven unattended hours. His reported direct human time was 45 minutes and API cost was $60.
Ronacher's observation was that the value shifts toward tests and documentation: code can be generated, translated, and refactored more cheaply when its behavior is specified elsewhere. Tests constrain the implementation. Documentation explains the intent behind interfaces and unusual decisions. Together, they let a human review a port based on evidence rather than reading every generated line as if it were handwritten.
That also changes open-source maintenance. Mitchem argues that low-cost ports can make it tempting to fork or reimplement a dependency rather than submit an upstream patch. The risk is obvious: a portable codebase can still fragment its maintenance burden across incompatible versions. Tests and documentation make that decision safer, while a weakly specified dependency becomes easier to copy and harder to trust.
Python is still a strong choice for AI-assisted coding. Rust is now a practical first choice for a wider set of systems than it was when every line had to be authored and debugged manually. Choose between them by looking at the runtime requirements, deployment target, available libraries, and verification loop. If the project cannot test an agent's Rust output, the compiler alone cannot confirm the code behaves correctly.