TypeScript Won. Here's What That Actually Bought Us.

The 'should we use TypeScript?' debate is over. The interesting question is what all those types are quietly enabling now.

Nobody seriously argues about adopting TypeScript anymore. New frontend projects default to it; the holdouts are legacy codebases and the occasional throwaway script. The debate is over, TypeScript won.

But "won" is the boring part. The interesting part is what types turned out to be good for — which is more, and different, than the original pitch of "catch typos before runtime."

Types are the cheapest documentation you'll never have to update

A function signature is documentation that can't go stale, because the compiler fails the build the moment it lies.

function scheduleReminder(
  userId: string,
  at: Date,
  channel: "email" | "push" | "sms",
): Promise<ReminderId>;

You already know almost everything about calling this without reading a single comment: what it needs, what it returns, that channel is one of exactly three strings. A comment claiming the same things could rot the next time someone adds a "slack" channel and forgets to update it. The type can't — adding "slack" to the union forces every call site to be reconsidered.

Types make refactoring a mechanical activity instead of an act of courage

In a large untyped codebase, renaming a widely-used field is genuinely scary — you're grepping strings and praying. In a typed one, you change the type and the compiler hands you the complete to-do list of everything that broke. Refactoring stops being "risky" and becomes "tedious but safe," which is exactly the trade you want. Whole categories of "we can't touch that, it's too entangled" simply dissolve.

The payoff nobody planned: types are the contract AI codegen needs

Here's the part that wasn't in the original sales pitch. The more machine-readable your boundaries are, the more reliably an AI assistant can operate inside them.

Ask a model to "add a field to this object" in untyped JavaScript and it's guessing at shape from usage. Ask it in TypeScript and the type is the spec — it knows precisely what's allowed, and its mistakes surface as compile errors instead of 2am production incidents. Types turn "generate plausible code" into "generate code that provably fits."

This flips an old objection on its head. People used to say types slowed them down. In an AI-assisted workflow, types speed you up, because they're the guardrail that lets you accept generated code with confidence instead of auditing every line by hand.

A few habits that compound

If types are this leverage-rich, it's worth writing them with intent rather than appeasing the compiler:

• Prefer unions over booleans + optionals. status: "loading" | "error" | "ready" beats three independent boolean flags that can contradict each other.
• Name your domain types. type Cents = number documents intent at every use site and lets you tighten it later.
• Avoid any; reach for unknown and narrow. any is a hole in exactly the safety net you're paying for.
• Let inference work. You don't need to annotate everything — annotate the boundaries (function signatures, exported APIs) and let the rest flow.

The takeaway

TypeScript's real win wasn't catching typos. It was turning your codebase into something with explicit, enforced contracts — and contracts turn out to be exactly what fearless refactoring, reliable tooling, and trustworthy AI assistance all quietly depend on.

We adopted types to prevent a class of bugs. We're keeping them because they're the substrate everything else now builds on. Worth investing in writing them well.