Python still owns the models. TypeScript ate the application layer. Here’s why — and what it means for what you build next.

Table Of Contents

• The framing nobody puts on the cover
• The data: TypeScript’s 2025 inflection
• Why TypeScript, specifically — the technical case
  • 1. Types are a verification layer for LLM-generated code
  • 2. Zod schemas map cleanly to LLM structured outputs and tool calling
  • 3. Async/await is the right concurrency model for LLM workloads
  • 4. Edge deployment: V8 wins where CPython can’t follow
  • 5. One language, one type system, one stack
• How it compares to adjacent languages
  • Python
  • Plain JavaScript
  • Go
  • Rust
  • Java / Kotlin
• The honest synthesis

The framing nobody puts on the cover

If you read tech headlines in late 2025 and early 2026, you’ve probably seen the claim that TypeScript “overtook Python” or “won AI.” The first half is true on GitHub. The second is sloppy.

There are two distinct AI worlds, and they look almost nothing alike:

1. The model layer — training, fine-tuning, research, evaluation, data engineering. Tensors, GPUs, gradient updates.
2. The application layer — agents, RAG, copilots, chat UIs, tool-using assistants, AI-powered SaaS. HTTP, streaming, schemas, state.

Python is unchallenged in the model layer and will remain so for the foreseeable future. CUDA bindings, decades of scientific computing in C/C++/Fortran wrapped in Python, and the entrenchment of PyTorch, JAX, and Hugging Face are not going anywhere.

But the model layer is small. Most engineers building anything “AI” in 2026 are not training models — they’re calling them. They’re composing prompts, parsing structured outputs, orchestrating agents, plugging models into product surfaces, and shipping the result to users. That’s the application layer, and that’s where TypeScript has quietly become the default.

This post explains why, with the numbers, the language comparisons, and the technical reasons it played out this way.

The data: TypeScript’s 2025 inflection

The most striking single data point comes from GitHub’s 2025 Octoverse report:

• TypeScript grew 66% year-over-year and became the most-used language on GitHub, overtaking both JavaScript and Python — the biggest language movement in more than a decade.
• Python still leads in AI/ML project creation. TypeScript leads in overall activity.
• AI-generated Bash projects grew 206% YoY, which is its own fascinating story about agents making historically painful languages tolerable.

In the LLM application ecosystem specifically, the npm numbers are telling:

The Vercel AI SDK alone surpassed 20 million monthly downloads by late 2025, with Thomson Reuters citing it as the foundation for rebuilding CoCounsel — their AI product now serving 1,300 accounting firms — with a team of three engineers in two months.

And the Model Context Protocol, Anthropic’s open standard for connecting models to tools introduced in November 2024, surpassed 97 million monthly SDK downloads and 81,000+ GitHub stars by March 2026. Critically: the MCP specification itself is defined in TypeScript (schema.ts is the source of truth), and the TypeScript SDK (npm package @modelcontextprotocol/sdk, repo modelcontextprotocol/typescript-sdk) is the reference implementation with 12,400+ stars. The Python SDK exists; the TypeScript SDK is canonical.

When a protocol designed by an AI lab to be the “USB-C of AI” picks TypeScript as its reference language, that’s a signal worth taking seriously.

Why TypeScript, specifically — the technical case

Five reasons, in roughly the order they matter.

1. Types are a verification layer for LLM-generated code

This is the deepest reason and it’s underappreciated outside the GitHub Next interview circuit. Idan Gazit, who leads GitHub’s long-range R&D team, has been blunt about it: when a model generates code for you, you need a fast way to know whether it’s correct, and explicit types give you that safety net.

The feedback loop looks like this:

LLM generates code → tsc / type-checker runs → errors surface immediately
                                              → model self-corrects
                                              → loop closes in seconds

Python lets you write def handle(x): return x.foo() and find out at runtime, in production, that x was a dict and not the object you imagined. TypeScript catches it at type-check time, before the code ever runs. For human developers, this is a productivity argument. For AI agents writing code at machine speed, it’s a correctness argument — agents iterate against the compiler the way humans iterate against the debugger, and TypeScript’s compile-and-check loop is one of the tightest in widespread use.

There’s a feedback loop at the ecosystem level too: AI tools work better with TypeScript → more TypeScript gets written → more TypeScript ends up in training data → models get even better at TypeScript. GitHub Next calls this the “convenience loop,” and it’s a plausible driver of the 66% surge.

2. Zod schemas map cleanly to LLM structured outputs and tool calling

Modern LLM application code is dominated by two patterns:

• Structured outputs: forcing the model to return JSON matching a schema.
• Tool calling: defining functions the model can invoke, with typed parameters and return values.

Both require a way to express a schema, validate inputs and outputs against it, and propagate types end-to-end. In TypeScript, the de facto answer is Zod (or Valibot, or ArkType), and the integration is almost suspiciously clean:

const tool = {
  name: "search_orders",
  parameters: z.object({
    customer_id: z.string(),
    after: z.date().optional(),
  }),
};
// Schema → JSON Schema → sent to model → response validated → typed result

The same Zod schema generates the JSON Schema sent to the model, validates the parsed response, and gives you a fully typed object in your editor. Python’s Pydantic gets you most of the way there, but you lose the language-level integration into your frontend, your API contract, and your build tools.

3. Async/await is the right concurrency model for LLM workloads

LLM applications are not CPU-bound. They’re I/O-bound: waiting on a model API, waiting on a vector DB, waiting on a tool call, waiting on a downstream service. The hot loop is usually “fan out 50 concurrent requests, wait for them all, reduce.”

Node.js’s event loop and TypeScript’s Promise.all / Promise.allSettled handle this natively without worker pools or GIL workarounds. Multi-agent systems that need to run dozens of tool calls in parallel scale gracefully on a single Node process. Engineers who’ve migrated agent orchestration from Python to TypeScript routinely report being able to scale to hundreds of concurrent tasks without the threading/GIL contortions Python requires.

Python has improved here — asyncio, trio, anyio are all real — but the language was retrofitted with async, and you can feel it. TypeScript was retrofitted too (callbacks → promises → async/await), but Node’s I/O-first design means the retrofit landed in fertile ground.

4. Edge deployment: V8 wins where CPython can’t follow

This is the deployment-level case, and it’s almost the whole story for AI startups: you cannot deploy CPython to Cloudflare Workers, Vercel Edge Functions, or Deno Deploy. These edge runtimes are V8-based, they cold-start in milliseconds, they run close to users, and they are where modern AI products are deployed because LLM latency is brutal and every round trip matters.

When Portkey (an AI gateway / observability product) explained their language choice, they cited TypeScript compiling to JavaScript “perfectly suited for Cloudflare Workers’ V8 engine,” excellent async support, and compile-time error catching. Python on the edge means Pyodide running in WASM — viable for some use cases, an order of magnitude heavier than native V8 for most.

This is structural. Even if you love Python, you cannot ship CPython to the runtimes where AI applications increasingly live, and the Pyodide path is heavyweight.

5. One language, one type system, one stack

The killer feature isn’t any single one of the above — it’s that TypeScript lets you write the React frontend, the Next.js API routes, the agent orchestration, the MCP server, the background worker, and the shared types between all of them in a single language. A User type defined once is enforced end-to-end. A tool schema defined once is the schema your UI uses to render a form, your API uses to validate input, and your agent uses to call the function.

For a small AI team — and most are small — this collapses an enormous amount of glue code, context switching, and bug surface. Python plus TypeScript can do the same job, but the seams show.

How it compares to adjacent languages

Python

Wins where it has always won: ML libraries, scientific computing, research notebooks, data engineering. The PyTorch / Hugging Face / NumPy / pandas stack is not replicable in any other language, and the AI labs themselves write their training code in Python. If you’re doing anything below the inference API line — training, fine-tuning, distillation, evaluation harnesses, dataset curation — Python isn’t just the right answer, it’s effectively the only one.

Loses where it has always lost: type safety (mypy is a bolt-on, not a guarantee), edge deployment, end-to-end stack unification, and increasingly the LLM-glue layer where its dynamic typing fights AI-generated code.

Plain JavaScript

Same runtime, same npm ecosystem, same edge story. But without types, you lose the verification layer that’s most of TypeScript’s reason for existing in AI work. LLM tool schemas, structured outputs, and agent state machines are exactly the kind of code where “this field is sometimes a string and sometimes undefined” produces production fires. JavaScript-without-types is a viable choice; it’s just strictly dominated by TypeScript for AI applications, which is why almost no serious AI SDK is shipping vanilla JS first anymore.

Go

Strong contender. Excellent concurrency model (goroutines and channels make multi-agent orchestration genuinely elegant), great deployment story, and Microsoft just rewrote the TypeScript compiler itself in Go for a ~10x speedup. Go is winning some of the AI infrastructure layer — proxies, gateways, orchestration daemons.

What Go loses: ecosystem. The AI SDK landscape (Vercel AI SDK, LangChain.js, the MCP TypeScript SDK, Mastra, hundreds of npm integrations) is on npm, not in Go modules. And Go’s verbosity, while a feature for some code, fights against the rapid-iteration style of LLM glue work. You write twice as much code to do the same thing, and most of it is error handling boilerplate.

Rust

The case for Rust in AI has improved dramatically as agents have gotten better at writing it — strong types, a strict compiler, and instantaneous feedback are exactly what AI-assisted coding wants. Several inference engines (candle, mistral.rs, burn) and infrastructure tools are Rust-native.

But Rust for the application layer is overkill. You don’t need zero-cost abstractions to call an LLM and parse JSON. The libraries don’t exist at the same depth, the developer pool is smaller, and the iteration speed for product code doesn’t justify the borrow-checker tax. Rust wins inference and systems; TypeScript wins the product layer above it.

Java / Kotlin

Strong in enterprise AI (Spring AI, LangChain4j) but trailing the open-source ecosystem badly. If you’re a Java shop doing AI, you’ll get there. If you’re starting fresh, you almost certainly won’t pick it.

The honest synthesis

The right architecture for a serious AI product in 2026 is almost always polyglot:

┌────────────────────────────────────────────┐
│  TypeScript                                │
│  - Frontend (React/Next.js)                │
│  - API + edge functions                    │
│  - Agent orchestration (AI SDK, Mastra)    │
│  - MCP servers and clients                 │
│  - Shared types end-to-end                 │
└──────────────────┬─────────────────────────┘
                   │  HTTP / gRPC / queues
┌──────────────────┴─────────────────────────┐
│  Python                                    │
│  - Model training / fine-tuning            │
│  - Data pipelines, ETL                     │
│  - Evaluation harnesses                    │
│  - Anything CUDA-adjacent                  │
└────────────────────────────────────────────┘

If you only have time to learn one for AI work, the honest answer depends on what you’re trying to do. Building products that use AI: TypeScript, by a wide margin. Building the AI itself: Python, also by a wide margin.

The headline “TypeScript is the language of AI” is wrong as stated. The accurate version is more interesting:

TypeScript didn’t displace Python in AI. AI’s explosive growth created an enormous new application layer above the models — and TypeScript turned out to be uniquely well-suited to it.

The model layer is small, deep, and Python-shaped. The application layer is vast, broad, and TypeScript-shaped. Most of the work is now in the second category. That’s why GitHub’s chart tilted, why the SDK downloads moved, why MCP was specced in TypeScript, and why a typed superset of JavaScript ended up at the center of one of computing’s most quantitative revolutions.

It’s a strange outcome. It’s also, on reflection, the right one.