What's with TypeScript?

TypeScript became the most used language on GitHub the same year AI agents started opening pull requests. That's not a coincidence. Here's what types actually do for AI-assisted teams, and how to set up a repo so they do it well.

For a long time, "should we use TypeScript?" was a fair question. Some teams loved it. Others saw it as ceremony that slowed down a perfectly good JavaScript codebase. Both camps shipped real products.

That debate is mostly over, and not because one side won the argument. In August 2025, TypeScript passed Python and JavaScript to become the most used language on GitHub. A year later it's still on top, and GitHub's latest numbers say more than 40% of pull requests now start as an AI agent's first draft.

Those two trends are tied together. This post covers how, where the hype oversells it, and what a TypeScript setup looks like when part of your team is a model.

The short answer

A type checker gives you a fast, deterministic answer to one question: does this change fit with the rest of the code? When people wrote every line, that answer was nice to have. When an agent writes a big share of the diff, it becomes one of the cheapest and most reliable checks you've got.

So if you're building for the web or on Node in 2026: use TypeScript, turn on strict mode, and make tsc part of your agent's definition of done. Just don't confuse "it compiles" with "it works." The rest of this post is the reasoning behind each of those.

What TypeScript is, in one paragraph

TypeScript is JavaScript plus a type system that only exists at build time. You describe the shape of your data, the compiler checks that the code agrees with itself, then the types are erased and plain JavaScript runs. That last bit matters more than people think. At runtime there is no TypeScript. Types are a promise checked before you ship, not a guard standing at the door in production. We'll come back to that.

booking.ts

type Booking = {
  id: string;
  startsAt: Date;
  players: number;
  priceCents: number;
};

function totalFor(booking: Booking, discountPct = 0): number {
  return Math.round(booking.priceCents * (1 - discountPct / 100));
}

totalFor({ id: "b_1", startsAt: new Date(), players: 4, price: 120 });
// error: Object literal may only specify known properties,
// and 'price' does not exist in type 'Booking'.

The mistake gets caught before anything runs. An agent gets the exact same error message you would.

It was already winning before AI

To be fair, TypeScript had momentum long before agents. Editors got real autocomplete, safe renames and go-to-definition across a whole codebase. Refactors stopped being scary. Next.js, Astro, SvelteKit and Angular all scaffold TypeScript by default, so plenty of teams never actively chose it. They just never switched it off.

The classic complaint was the extra typing: writing interfaces, annotating everything, keeping types in sync. That cost hasn't disappeared, but these days it mostly lands on the agent. You get the safety of types without paying for them in keystrokes.

The other old objection, "it adds a build step," is weaker now too. Node.js runs .ts files directly through type stripping, which was marked stable in v24.12 and v25.2. Notice the word stripping, though. Node removes the types without checking them. Which brings us to the real point.

Then the agents showed up

• #1: Most used language on GitHub by contributors, in both 2025 and 2026
• 44.1%: Merged TypeScript PRs with AI involvement over the past year, the highest among large languages
• 94%: Share of compile errors in LLM-generated TypeScript that were type errors, not syntax (2025 study)

GitHub's Octoverse 2026 report, published at the end of October, fills in the picture. TypeScript gained 3.62 million monthly contributors between September 2025 and September 2026, the biggest jump among the top ten languages. Agent-started pull requests went from 17% in March to over 40% by September. And among repositories created this year, TypeScript was the main language in 35% of those showing signs of agent use, versus 24% of those without.

GitHub is careful to call that a correlation, and so should we. Maybe agents nudge people toward TypeScript, maybe TypeScript teams just picked up agents earlier. But the mechanism isn't hard to see once you look at what models actually get wrong.

Why types and language models get along

Most of what models get wrong is type-shaped

In a 2025 study from ETH Zurich and UC Berkeley, researchers had open-weight models of different sizes write TypeScript for standard coding benchmarks, then looked at what broke. On average, about 94% of the compile errors were failed type checks. Only around 6% were syntax errors.

That lines up with what you see day to day. Models are great at syntax. They've read more code than any of us ever will. Where they slip is the stuff that's specific to your codebase: the field someone renamed last sprint, the function that can return null, the enum that got a new member on Tuesday. That's exactly the kind of mistake a type checker exists to catch.

Types are context the model can actually read

Open a JavaScript file and you'll find something like applyDiscount(order, code). An agent has to guess what order looks like, whether code is a string or an object, and what comes back. Maybe it reads three other files to work it out. Maybe it just guesses.

In TypeScript the signature answers all of that, and the answer can't go stale because the compiler enforces it. Your README can't say the same.

Anders Hejlsberg, TypeScript's lead architect, made a related point in an interview with GitHub: models write a language about as well as the amount of it they've seen, which puts newer languages at a real disadvantage. TypeScript gets both halves of that deal. It's typed, and it sits on one of the largest bodies of code models have ever been trained on.

The type checker is a reviewer that never gets tired

Agents work in loops: write something, run something, read the output, fix it. What matters is what "run something" means. Tests are great, but someone has to write them, and they only cover what they cover. tsc --noEmit checks the whole program, every time, the same way, at no extra cost.

Speed used to be the catch. On a large codebase, a full type check could take minutes. Fine before a merge, painful after every edit. TypeScript 7, released in July with the compiler rewritten in Go, changes that math. In the team's own benchmarks, a full build of the VS Code codebase went from about two minutes to about ten seconds. A ten-second check is one an agent can run constantly.

One interesting wrinkle: a paper published this June found that forcing type rules on a model token by token, while it generates, can actually hurt functional correctness compared with letting it write freely and type-checking afterwards. Types work best as feedback, not as a straitjacket. Which happens to be exactly how an agent loop uses them.

Example: let the compiler write the to-do list

Say your app tracks payments and you ask an agent to add a "disputed" state. In plain JavaScript, it searches for "refunded", updates whatever it finds, and hopes it didn't miss a template somewhere. With a discriminated union and an exhaustive switch, the compiler hands it a list.

payment.ts

type PaymentState =
  | { status: "pending" }
  | { status: "paid"; paidAt: Date; amountCents: number }
  | { status: "refunded"; refundedAt: Date; reason: string };

function label(p: PaymentState): string {
  switch (p.status) {
    case "pending":
      return "Waiting for payment";
    case "paid":
      return `Paid ${formatCents(p.amountCents)}`;
    case "refunded":
      return `Refunded: ${p.reason}`;
    default: {
      const unreachable: never = p;
      return unreachable;
    }
  }
}

Now add the new state:

payment.ts

type PaymentState =
  | { status: "pending" }
  | { status: "paid"; paidAt: Date; amountCents: number }
  | { status: "refunded"; refundedAt: Date; reason: string }
  | { status: "disputed"; openedAt: Date };

// error TS2322: Type '{ status: "disputed"; openedAt: Date; }'
// is not assignable to type 'never'.

Every switch with that never check that doesn't handle disputes now fails to compile, and each error points at the exact line. For a person, that's convenient. For an agent, it's the difference between guessing at the scope of a change and being told.

Where TypeScript will lie to you

Types are a strong tool, not a magic one. And a few of their gaps get wider when a model is the one writing the code.

Types disappear at runtime

API responses, webhook payloads, environment variables and, these days, model output: none of it is checked by TypeScript. JSON.parse returns any, which is the compiler's polite way of saying you're on your own. If you call an LLM and cast the response to your type, you've just told a deterministic tool to trust a probabilistic one.

Validate at the edges with a schema library like Zod, Valibot or ArkType, and derive the type from the schema so the two can't drift apart.

suggestion.ts

import { z } from "zod";

const Suggestion = z.object({
  bookingId: z.string(),
  newPriceCents: z.number().int().positive(),
  reason: z.string().max(280),
});

type Suggestion = z.infer<typeof Suggestion>;

const raw: unknown = JSON.parse(modelResponse.text);
const parsed = Suggestion.safeParse(raw);

if (!parsed.success) {
  // Log it, retry, or fall back. Just don't ship it.
  throw new Error(`Invalid suggestion from model: ${parsed.error.message}`);
}

applySuggestion(parsed.data); // a real Suggestion this time, not a hopeful one

Agents will take the shortcut

When tsc complains, the fastest way to a green check is as any, @ts-ignore, or a ! on something that might be undefined. Models find that path, the same way a tired developer at 6 p.m. does. Block it with lint rules (@typescript-eslint/no-explicit-any, ban-ts-comment, no-non-null-assertion) and say it in plain words in your agent instructions. A silenced type error is worse than a reported one, because now it looks like it's fine.

Types check shape, not intent

priceCents: number will happily accept a price in dollars. A well-typed bug is still a bug. Branded types help with the obvious cases, tests cover behavior, and a human still needs to read the logic. TypeScript removes a whole category of review comments. It doesn't remove review.

From our day-to-day

On the product I work on, the UI and the server are both TypeScript and share the types that describe the data going back and forth. That sounds like a small detail until an agent renames a field in an API response, or makes something optional that used to always be there. The server change looks fine on its own. The tests for that endpoint pass. Then the typecheck runs and a couple of components on the frontend light up, because they're still reading the old shape.

It happens more often than you'd think, and it gets caught before anyone opens a browser. For us, the typecheck is one more validation step in the daily delivery flow, sitting next to tests and code review. It's also one of the guardrails that lets us move fast with AI without that speed turning into a blank screen in production.

A TypeScript setup that holds up with agents

strict is the baseline. Recent versions turn it on by default, but spelling it out costs nothing. noUncheckedIndexedAccess makes items[0] possibly undefined, which is true and which models love to forget. erasableSyntaxOnly keeps you to syntax Node can strip, so the same files run with or without a build step.

tsconfig.json

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noFallthroughCasesInSwitch": true,
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "noEmit": true
  }
}

Then write the rules down where the agent will actually read them. Most coding agents pick up an AGENTS.md (or their own equivalent) at the root of the repo:

AGENTS.md

## Definition of done
- `pnpm typecheck`, `pnpm lint` and `pnpm test` all pass.
- Don't add `any`, `@ts-ignore`, `@ts-expect-error` or `as` casts
  to make an error go away. If a type is wrong, fix the type.
  If you can't, stop and explain why.
- Anything coming from outside (API responses, env vars, model output)
  goes through a Zod schema before we use it.

GitHub's data has a fun footnote here: new repositories with an agent configuration file logged about eight times as many commits as those without one. Correlation again, sure. But teams that write the rules down do seem to get more out of their agents.

Upgrading? If you're still on TypeScript 5.x, go through 6.0 first. It's the bridge release that warns about everything 7.0 turns into hard errors. Also know that 7.0 shipped without a programmatic API, so tools that import the compiler as a library (typescript-eslint, custom transformers, the Vue, Svelte, Astro and Angular template checkers) still run on 6.0 for now, side by side with 7.0. The new API arrives in 7.1, which went into beta on October 20.

When TypeScript isn't worth it

• A 40-line script or a one-off Lambda. JSDoc comments plus // @ts-check get you most of the benefit with none of the setup.
• A bit of interactivity on server-rendered pages. That's Alpine.js territory, and we wrote a whole post about it.
• Data science and ML. Still Python's home. Same logic applies, though: type hints plus a checker like Pyright or mypy give agents the same kind of feedback.
• A team that will fight it. "Strict" TypeScript full of any gives you the confidence of types without the safety. Plain JavaScript with good tests is at least honest about what it checks.

A quick checklist

• strict on, plus noUncheckedIndexedAccess.
• tsc --noEmit runs in CI and is part of the agent's definition of done.
• Lint rules block any, @ts-ignore and non-null assertions.
• Every external input, model output included, goes through a schema.
• State is modeled with discriminated unions and exhaustive switches.
• TypeScript 7 for the type check, so it's fast enough to run on every edit (with 6.0 alongside for tools that still need the old API).
• Humans review intent and logic. The compiler handles the rest.

The bigger picture

The odd thing about TypeScript's rise is that the language barely had to change to earn it. Unions, generics, strict null checks: most of what makes it useful to agents has been there for years. What changed is who's writing the code.

When a good part of every diff comes from a model, a deterministic check that runs in seconds is worth a lot more than it used to be. TypeScript just happened to be the most popular language that offers one. That's roughly how we think about agentic delivery at Streaver: agents draft, the compiler and the tests check, and senior engineers own the decisions no type system can make for you.

Bringing AI agents into a TypeScript codebase?

We help teams set up the guardrails, from strict types and schemas to CI and agent instructions, so the code agents write is code you'd actually merge.

Explore agentic workflows