TypeScript Became GitHub's Most Used Language in 2025. Designers Should Read Why

In August 2025, TypeScript became the most used language on GitHub. GitHub's Octoverse 2025 report counted 2,636,006 monthly contributors that month, up 1.05 million in a year, or 66.6%. It passed Python by about 42,000 contributors and JavaScript by a lot more. GitHub calls it the most significant language shift in more than a decade.

That sounds like news for engineers. I think designers should read it more closely than engineers do, because the reason GitHub gives for the shift is about something designers have always cared about: making intent explicit so nobody has to guess.

Why GitHub says it happened

The report gives two causes. The first is boring and real: nearly every major frontend framework now scaffolds new projects in TypeScript by default. If you start a project with the usual tools, you get TypeScript whether you asked for it or not.

The second is the one that matters. GitHub writes that developers are shifting toward typed languages that make agent assisted coding more reliable in production, and that type systems reduce ambiguity and catch LLM errors before production. It cites a 2025 academic study that found 94% of LLM generated compilation errors were type check failures.

Read that last number from the other side. When a model writes code that does not compile, the large majority of the time the type checker is what catches it. Types are the first reviewer of AI written code, and they review every line, every time, for free.

The report also has a less flattering finding next to it. Broken Access Control overtook Injection as the most common CodeQL alert, flagged in more than 151,000 repositories, and GitHub links part of that to AI generated scaffolds that skip critical auth checks. Code that looks correct and is not. The type checker cannot catch a missing permission check, but it shows the same pattern: the cheap part of producing code got cheaper, and the value moved to whatever catches mistakes.

A type is a spec

Here is why I think this is a design story.

When I design a component, the hard part is never the default state. It is the list of states the component can be in: loading, empty, error, partially filled, disabled, too long for its container. A good design file shows all of them. A weak one shows the happy path and leaves the rest to whoever builds it.

In TypeScript, that list can live in the code as a type. A request can be typed as either loading, loaded with data, or failed with an error, and nothing else. Once you write it that way, the compiler refuses any screen that forgets to handle one of the cases. The empty state stops being something a designer has to remember to ask for. It becomes something the code cannot ship without.

That is a design decision written in a format a machine enforces. And it is exactly the format a model reads best. When I ask a coding agent to build a screen against a type that already names every state, it usually builds every state. When I ask it to build a screen against a vague description, it tends to build the happy path and invent the rest.

What this changes for design engineering

I work as a design engineer, which means the same person decides what the product should do and writes the code that does it. I wrote about what that role looks like in Tokyo. The TypeScript shift changes where I spend the design part of that job.

More of the design now happens in the types. The props of a component are its API, and its API is its design. Which variants exist, which combinations are allowed, which ones are impossible. If a button can be primary or secondary, and can be destructive only when it is primary, I can write that rule as a type and nobody, human or model, can build the forbidden combination by accident.

Design tokens get the same treatment. A color token typed as one of a fixed set of names cannot be replaced by a hex value someone pasted in from a screenshot. A spacing value typed against the scale cannot drift to 13 pixels because a model thought it looked nicer.

And the copy goes in too. If every error the product can show is a named case with its message attached, then "something went wrong" stops being a fallback a model reaches for, because there is no case for it.

None of this replaces drawing. I still sketch, and I still look at screens. But the place where my design decisions become binding for the code, and for the models writing a lot of that code, is the type definitions. If they are vague, the output is vague.

What designers who do not code should take from it

You do not need to write TypeScript to use this. You need to design in a way that maps to it.

Name every state, not just the ones that look good in a portfolio. Write down which combinations of variants are allowed and which are not. Decide the full list of errors and what each one says. Give your tokens names and stop specifying raw values in handoff notes.

If you do that, an engineer can turn your file into types in an afternoon, and from then on the models writing code against those types will respect your decisions without being reminded. If you do not, the models will fill the gaps, and they fill gaps with the most average answer they have seen.

Where this leaves us

The same Octoverse report says 80% of new developers on GitHub use Copilot in their first week, and that more than 180 million developers now work on the platform. A lot of the code in the next few years will be written by people working alongside models, and a lot of it will be written by models working with very little supervision.

In that world the most valuable artifact a designer can produce is a precise description of what is allowed. Pictures still matter for showing what it should feel like. But the rules, the states, the combinations, the words, those need to exist somewhere a machine can check them. TypeScript reaching number one is the industry quietly agreeing on where that somewhere is.