I searched “best language for AI.” What came up was Python, R, Julia — one of the rewritten articles even still had a leftover “as of May 2019” buried in the text that nobody bothered to delete.

I read through it and thought: wait, this isn’t the answer I was looking for.

The arrow is pointing the wrong way

What articles like this actually answer is “if you’re building AI, which language should you use?” Python with its deep ML library ecosystem, R for statistics. The arrow points from language to AI. Call this axis 1.

But what I actually want to know right now is the reverse: “what does AI write, when I let it choose?” That’s axis 2 — the arrow pointing the other way.

Having Claude Code write code for me every day, I already know the answer in my gut: TypeScript. Ask it to build something new without specifying a language, and it comes back as TS or JS almost every time. The map you get from googling “best language for AI” simply doesn’t apply to this flipped-arrow world anymore.

So why TS? As it happens, the news sitting in my feed lined up almost too neatly to explain it.

The JS toolchain is quietly being rewritten in Rust

Over the past few weeks, “Rust” kept showing up in my news roundup. Vite 8.0 shipped with Rolldown, a Rust-based bundler, as its default. VoidZero, the company behind it, got acquired by Cloudflare. webpack, Babel, ESLint, Prettier — the JS/TS-based, single-threaded, GC-reliant staples of the toolchain are being replaced with Rust implementations one after another.

The reason is simple: speed. Rust tools run natively with no GC and full multithreading, and they’re 10 to 30 times faster than their predecessors. On top of that, shared Rust-based parser/AST infrastructure like Oxc has matured, which is cutting out the waste of bundlers, transpilers, linters, and formatters each re-parsing the same code independently. Rolldown (Rollup-compatible), Rspack (webpack-compatible), Biome (ESLint+Prettier-compatible) — these are all built as drop-in replacements that don’t break your existing config or setup, which is part of why adoption has been so smooth.

That said, this shift predates the AI boom — it traces back to esbuild’s debut around 2020. The motivation was speed and untangling toolchain fragmentation, not AI directly.

Still, the two fit together well. AI agents run “edit → build → test → lint” dozens of times within a single task. The faster the tools, the cheaper and faster that loop runs. A build that takes tens of seconds translates directly into agent wait time and token spend. And as AI-generated code volume grows, so does the total amount of building and analysis that needs to happen. I suspect that’s exactly why Publickey’s 2026 predictions piece mentioned “AI-agent-first development” and “expanding Rust adoption” in the same breath — the fit is too good to be coincidence.

TS is rock-solid as a language, but its implementation is leaving its mother tongue behind

Inside this Rust wave, TypeScript’s position has become genuinely interesting. As a language, TS is if anything getting stronger — Node, Deno, and Bun are all converging toward running .ts files directly, and there’s no sign of that trend wavering.

Meanwhile, the tools that process TS are going native at a rapid clip. Type transformation is now handled by SWC, esbuild, and Oxc (Rust/Go), and the crown jewel is the type checker itself: tsc. On June 25, 2026, Microsoft shipped an RC of TypeScript 7.0 (Project Corsa). The port target: Go. Compilation is roughly 10x faster, editor startup roughly 8x faster, and memory usage is nearly halved. Google, Notion, Slack, and Vercel have already adopted it externally.

Here’s the part that snags. If you’re chasing raw speed, Rust should be the obvious choice. So why Go?

The answer isn’t “because Go is better” — it’s “because the existing tsc could be ported as-is.” Under the hood, tsc is a massive graph of mutable objects with circular references — ASTs, cross-referencing types, all built on the assumption that a garbage collector is there to clean up after aggressive in-place mutation. Go lets you carry that structure over almost 1:1. Rust’s ownership and borrowing model actively resists circular references and mutable graphs like this, which would have meant a ground-up redesign. Anders Hejlsberg himself confirmed this wasn’t a judgment about language quality but pure pragmatism: he chose Go because it was the fastest path to a 10x-faster codebase.

So tsc’s implementation ended up in Go not because Go was objectively “best,” but because of path dependency — the ability to carry existing assets forward as-is. Being logically correct loses to an accumulated path that already works. And this, it turns out, is a preview of the same shape I’ll return to later: TS winning as a language isn’t about technical optimality either — it’s about owning the web and having a massive training corpus, which is also just path dependency.

“Writing in TS” hasn’t changed, but “the tooling that processes TS” is drifting away from its own mother tongue. TS 7.0 is a live demonstration of that split — the official TypeScript compiler is no longer written in TypeScript. And yet, the list of companies adopting it also confirms, in the same breath, just how solid TS remains as a language.

Why AI reaches for TS isn’t about type “quality”

Back to the main question: why does AI tend to write TS?

The tempting explanation is “because it has types, so AI can verify its own output more easily.” But that needs a correction — better verifiability from types is a property of typed languages in general, not something unique to TS. And TS’s type system is deliberately unsound; if you’re ranking strictly by type rigor, Rust or Haskell wins easily. On type quality alone, TS doesn’t come out on top.

So what’s actually driving it? First, you can’t ignore TS’s lock on the web/npm ecosystem. JavaScript is essentially the only language that runs in a browser — that’s a structural moat with no real substitute. Then there’s the sheer volume of training data. According to GitHub’s Octoverse 2025, as of August 2025 TypeScript overtook both Python and JavaScript to take the top spot in monthly contributors, at 2.636 million — a 66% year-over-year jump, one of the biggest ranking shifts in a decade.

When I tried to double-check one of my own assumptions here, things got twisted. I’d been carrying around an explanation like “types make it well-suited to the generate-loosely-then-tighten-later loop AI agents run.” The actual measurements say the opposite. A benchmark published by mame has Claude Code solve prototyping tasks across 13 languages and compares time and cost. The fastest, cheapest, and most stable were Ruby, Python, and JavaScript — not TypeScript. TS ranked 11th out of 15, taking 1.6x longer than JavaScript and costing 60% more. The overhead of the type system was actually slowing the agent’s iteration loop down, not speeding it up.

The upside of types — catching AI’s mistakes early — does seem to be real. One study found that 94% of compile errors LLMs produce are type-check failures. Static typing functions as a net that stops AI’s sloppiness before it reaches production. But that’s a separate axis from whether an agent can actually write faster and cheaper in practice — and on that axis, the measured cost of types outweighed the benefit.

So “AI writes TS best, technically speaking” isn’t a sufficient explanation for TS’s rise. A GitHub developer advocate calls this the “convenience loop”: developers flock to whatever technology makes AI feel easy to use, which grows the training data for that technology, which makes AI even better at it. TS just happened to catch this loop earliest, and once you’re riding it, the loop keeps spinning regardless of technical merit.

I’d been thinking “TS is what AI writes best, so left unchecked, things gravitate there.” The more accurate version is: “it gravitates there regardless of whether AI writes it best — because the loop it’s riding is simply bigger than the alternatives.” And this is the third face of a shape this piece keeps circling back to. TS winning as a language, tsc’s implementation ending up in Go, AI gravitating toward TS — all three share the same root. Being logically correct loses to an accumulated path that already works.

Path dependency can also be a wall

Everything so far has been examples of path dependency on the “ride it and it accelerates” side — TS’s convenience loop, tsc’s Go port. But path dependency has an opposite face too: the side where an accumulated path leaves you stuck, unable to move.

The clearest example is COBOL in banking. Systems written decades ago are still running at the core of settlement infrastructure today. Technically, it’s about as frozen as software gets, and there must have been people wanting to rewrite it for years. But it doesn’t move.

My first instinct was that COBOL’s immobility is a “people” problem. The engineers who wrote it have retired, or worse. Documentation is gone. Fewer young engineers can even read COBOL anymore. If that’s the whole story, this should be exactly where AI shines — reading mountains of undocumented legacy code and explaining it is precisely the kind of work today’s LLMs are eager to do. And indeed, AWS has a product that scans legacy codebases to surface technical debt — legacy migration support is one of the current front lines of applied AI.

But that alone doesn’t feel like the full picture. Decades of patches have piled up in COBOL settlement systems, and the answer to “why does this one line exist” is sometimes something like “it works around a specific edge case that happened some years back” (a generic example, not a real one). AI can read that logic and explain it — the wall of understanding is genuinely being worn down by AI.

But a different wall remains: proving that the rewritten system behaves identically to the original, down to the last detail. You have to convince regulators and auditors that the new and old systems produce matching results across every transaction pattern that could occur in production. That’s not “read and understand” work — it’s “enumerate everything that could possibly happen and verify it,” a completely different axis from how fast you can read code. AWS’s own writeup on lessons from real-world COBOL modernization points to the same thing: the main causes of failure weren’t a lack of technical skill in the port itself, but the inability to prove functional equivalence against real production data, and organizations underestimating the effort involved.

In other words, the COBOL wall isn’t one wall — it’s two walls stacked on top of each other: a wall of understanding and a wall of proof. AI is chipping away at the former. The latter still only moves at the speed of human trust.

TS’s path dependency was a moat that accelerates the moment you get on it. COBOL’s path dependency is a wall made of a part that’s crumbling and a part that isn’t. Same underlying shape — path beats logic — but which parts AI can change and which it can’t differ completely.

So for now, I’m betting on TS

Back to where this started: “best language for AI.” Articles like that are mapping a world where you use a language to build AI. What I actually wanted was a map of what AI writes when it’s driving — a different axis entirely. Picking a language off the old map doesn’t answer the question I actually have.

Right now, the answer to axis 2 is TS, and what’s propping it up isn’t technical optimality — it’s the sheer size of its convenience loop. Loops that big don’t collapse easily. Betting on TS for now seems like the rational call, regardless of whether it’s the technically optimal choice. Though it’s worth remembering: if all you want is the fastest possible working prototype right now, plain JavaScript or Python will get an agent there faster and cheaper than TS will. If you’re trying to decide what to learn and you’re stuck on language choice, you’re better off looking at what AI agents can actually write well and fast today than trusting whatever stale “best language for AI” article turns up in search.