Language Choice for Agents

For two decades the implicit cost function on language choice was minutes-of-human-time-per-feature, and Python/TS dominated it. As of 2026 the human's role has shifted from writing code to architecting and reviewing what agents wrote, so the cost function changed shape. Agent throughput — tokens spent, retries needed, correctness on first or second pass — is the dominant term now, and it ranks languages differently than human throughput did. See if-ai-writes-your-code-why-use-python for the empirical case.

What changed

Three primitives matter to an agent's throughput on a language:

1. Compile-and-check latency. Short loops let the model self-correct from error messages. A pedantic compiler at sub-second latency is a continuously-running reward signal.
2. Type-system informativeness. Errors that locate the bug precisely beat errors that say "TypeError on line 42." Structural and nominative types both reduce the search space when the model is choosing between candidate fixes.
3. Training-corpus volume. The model needs to have seen the language enough to produce idiomatic code. Below some threshold the corpus argument dominates everything else.

Rust scores high on all three. Go scores high on (1) and (3), medium on (2). C++ scores high on (3) but the compile-and-check loop is too long and error messages are too noisy. Python and JS score high on (3) but low on (1) and (2) — the agent has to run the program (or a test suite) to learn whether its output was wrong, instead of getting the answer from a type-checker in milliseconds. Zig, Haskell, and Gleam score high on (1) and (2) and low on (3); they're stuck on the wrong side of the training-data curve.

The languages humans found hardest are the ones agents find easiest, and for related reasons: pedantic compilers, fast iteration, strong types. Those features were paid for in human ramp time and are paid for in agent compute. Compute got cheap.

What this implies for new projects

The traditional "use Python or TS for a new project" advice rested on three claims, all of which weakened in 2025–2026:

• "The ecosystem solves 90% of the problem already." True, but the ecosystem is increasingly a thin Python/TS wrapper over Rust internals. pydantic-core, polars, orjson, tokenizers, ruff, uv, ty, Rolldown — Rust under the hood. When agents can write the lower layer directly the wrapper becomes overhead. See port-not-patch-contribution.
• "Hiring is easier." True, but hiring a team to write the code is no longer the dominant cost when the team's job is to architect and review. The architect-and-reviewer role draws from a different pool than the "ships Python features fast" pool.
• "You ship faster." Specifically, you used to ship faster because the human bottleneck dominated. With agents handling the line-level work, the runtime-cost advantage of a faster language compounds every day the service runs in production, while the ergonomic advantage matters less per quarter.

The remaining counter-cases are real and worth enumerating: serverless deployments where Rust binaries are hostile, ML research where PyTorch's gravity is overwhelming, products with very small surface areas where TS/WASM still beats native Rust (Prisma's reversal of its query engine is the canonical example).

What this does NOT imply

The frame is sensitive to who's reading it. A few collapses worth resisting:

• "Therefore everyone should start in Rust." The thesis is about the cost function changing, not about every project being well-served by Rust today. Mitchem himself flags that for some workloads the old answer is still the right answer.
• "Therefore agents have replaced engineering judgment." The architect-and-review job still requires reading code, understanding the architecture, and making engineering tradeoffs — see skill-atrophy-supervision-paradox for the live debate about whether agent use erodes the skills that role depends on.
• "Therefore Python is dying." PyTorch still owns ML research and probably will for a while. Python is still optimal for a wide class of internal tooling, ad-hoc analysis, and glue. The argument is about defaults for new long-running services, not about deleting Python from the world.

How this sits against contrary views

The strongest counter-arguments live elsewhere in the wiki:

• no-silver-bullet-llms — Bennett's case that the essential-vs-accidental complexity ceiling caps the productivity gains, no matter how good agents get. The big-artifact ports Mitchem cites are exactly the work surfaces Brooks would predict are most amenable to LLM gains; they may not generalize.
• simonw-zig-anti-ai — Zig's deliberate refusal to accept LLM contributions, which closes off the very mechanism that closes Zig's quality gap.
• ai-great-leap-forward — what happens to the median shop when the agent default becomes a mandate. The artifacts Mitchem cites are by skilled engineers (Hejlsberg, Carlini, Klabnik, Kling); the corporate version is fabricated metrics.
• peril-of-laziness-lost — Cantrill on why LLMs lack the human virtue of laziness; unchecked generation produces bloat. The agent-language case implicitly bets that compiler feedback substitutes for the laziness instinct, which is unproven.

Open questions

• Whether the "tight compile loop = agent advantage" effect survives once agents start producing code at volumes where the test suite becomes the bottleneck, not the compiler.
• Whether ecosystem maturity catches up — Rust's libraries are good for systems work, less mature for high-level domains (web frameworks, data science) where Python still dominates.
• Whether the per-language cost-of-port (Ronacher's $60 MiniJinja port) collapses far enough that "language choice" becomes a runtime tuning parameter rather than an upstream commitment.
• Whether the training-data asymmetry (Rust/Go strong, Zig/Haskell weak) is stable or transient. Synthetic-data approaches could close the gap; corporate retreat from less-popular languages could widen it.

The thesis is most testable on the boring question: in two years, what fraction of new greenfield services at small-to-medium shops are written in Rust or Go rather than Python or TS? Mitchem is betting the answer crosses 50%. The skepticism cluster bets that supervisor-bottleneck and code-quality friction keep the number low.