← Taku Uechi

Why AI Makes TypeScript More Useful

By Taku Uechi

I've used TypeScript for years mainly because it makes larger Javascript applications easier to maintain. That hasn't really changed, but what has changed is that AI is now writing a much larger percentage of the code.

The more I use AI coding tools, the more I think TypeScript becomes even more valuable because it gives AI more context about what the application is actually supposed to do. Javascript is flexible, which is obviously one of the reasons people like it, but flexibility also means ambiguity. A developer who has worked on an application for three years can usually fill in a lot of those blanks mentally. An AI agent doesn't necessarily have that institutional knowledge unless it can find it somewhere in the codebase.

Types Give AI More Context

Take something simple like this:

function updateRegistration(data: any) {  
  // ...
}

A developer familiar with the application might already know what data is supposed to contain. Maybe it looks something like this:

{
  teamId: string;
  divisionId: string;
  status: string;
  players: Player[];
}

AI doesn't automatically know that. It has to inspect the function, search where it's being called, look at other objects that seem related and then infer what the shape probably is.

Now compare that with:

interface RegistrationUpdate {  
  teamId: string;
  divisionId: string;
  status: RegistrationStatus;
  players: Player[];
}

function updateRegistration(data: RegistrationUpdate) {  
  // ...
}

There is a lot less to guess. It gets even better with unions:

type RegistrationStatus =  
  | "pending"
  | "accepted"
  | "waitlisted"
  | "cancelled";

If an AI agent is adding a registration workflow, it now has a very obvious list of valid states. Without that type it might search through the repository, find "inactive", "removed", "cancelled" and "dropped" in various pieces of old code and decide that one of those is probably the right value.

That is exactly the kind of mistake AI can make pretty easily. The code might look completely reasonable, the naming might fit the application, but the assumption itself is wrong.

any was always dangerous, but I think it's a little more expensive now because AI doesn't have all the knowledge that developers slowly accumulate while working on a system. Types move some of that knowledge out of people's heads and put it directly into the code.

AI Also Makes Strong Typing Cheaper

One of the complaints about TypeScript over the years has always been that it creates extra work. You have to create interfaces, DTOs, enums, generics and sometimes spend way too much time convincing TypeScript that something you already know is valid is actually valid.

That still happens. The difference is that AI is pretty good at doing a lot of the boring part now.

If I have an API response like this:

{
  "id": "123",
  "name": "Tigers",
  "division": {
    "id": "456",
    "name": "Mens Open"
  }
}

I can have an AI coding tool generate the TypeScript type or Zod schema basically immediately. The same thing applies to a lot of mechanical transformations:

API response  
→ TypeScript type
→ Zod schema
→ test fixture

The cost of creating decent type coverage has gone down quite a bit.

At the same time, AI is also increasing the amount of code we can produce. If one engineer can now create significantly more code in the same amount of time, I think guardrails become more important, not less.

An AI can write a lot of bad Javascript very quickly. At least with TypeScript, the compiler gets a vote.

That's one of the reasons I think the tradeoff has shifted. We have less excuse for leaving something vaguely typed because a lot of the repetitive work can now be generated, while the downside of incorrect generated code is actually becoming larger because we're producing more of it.

Sharing Models and Business Logic Across the Stack

One thing I've always liked about using TypeScript on both the frontend and backend is being able to share models. This becomes even more useful with AI because it gives the agent fewer representations of the same thing to reconcile.

For example:

export interface RegistrationTeam {  
  id: string;
  name: string;
  divisionId: string;
  status: RegistrationStatus;
  players: Player[];
}

That type can potentially be shared by:

React application  
admin application  
Node API  
background workers  
tests

Instead of having one object shape on the frontend, another on the backend and maybe a slightly different version in some worker or admin application, there is one shared definition.

The same thing applies to business logic. For example:

export function canRegister(  
  division: Division,
  team: RegistrationTeam
) {
  return (
    team.players.length >= division.minPlayers &&
    team.players.length <= division.maxPlayers
  );
}

The frontend can use that function to determine whether a registration is valid before submission, and the backend can use the same function before actually saving anything. The backend should still be the source of truth, but there isn't much reason to independently implement the same rule twice.

In the AI era I think this is even more valuable because there is one obvious place for the agent to find the rule.

Instead of:

frontend implementation  
backend implementation  
admin implementation

you have:

shared registration logic

The less duplicated business logic there is, the less chance the AI has to update one copy while forgetting another.

This lines up really well with monorepos too. If the frontend, API, workers and shared libraries all live in the same repository and share TypeScript packages, an AI agent has a much better chance of understanding how a change actually moves through the system.

One Language Can Cover a Lot More of the Application

Javascript started in the browser, but TypeScript can cover a pretty large percentage of a modern application now.

You can use it for:

React  
Next.js  
Node.js  
React Native  
Electron  
Cloudflare Workers  
serverless functions  
background jobs  
build scripts  
tests

Obviously that doesn't mean everything should be written in TypeScript. There are plenty of good reasons to use Python, Go, Rust, Java or whatever else makes sense for a particular problem.

But for a normal SaaS application, using one language across a large percentage of the stack has some pretty obvious advantages. A developer can move from a React component to an API endpoint to a background worker to a shared library without constantly switching languages and ecosystems.

React component  
→ API endpoint
→ job worker
→ shared library

AI gets a similar benefit. If the agent already understands the TypeScript types, conventions and patterns being used in one part of the application, a lot of that context transfers naturally into another part.

It isn't jumping from TypeScript on the frontend to Java on the backend and then Python for a worker while also trying to figure out how three different implementations map back to the same business domain.

That alone isn't a reason to rewrite an existing system, but if I'm starting a new application today and TypeScript is already a good fit for the workload, AI being able to operate across more of the stack with the same language is another advantage.

The Compiler Becomes Part of the AI Feedback Loop

I think this might be the biggest advantage.

AI can write some code and immediately find out whether its assumptions were structurally wrong.

The loop looks something like:

AI writes code  
    ↓
tsc  
    ↓
compiler errors  
    ↓
AI fixes code  
    ↓
tsc again

That feedback loop is really useful.

For example, AI might generate:

registration.playerCount

when the actual model is:

registration.players.length

In Javascript, you might not notice the mistake until that particular code path runs. TypeScript can immediately return something like:

Property 'playerCount' does not exist on type 'RegistrationTeam'

Now the AI has deterministic feedback instead of having to guess whether its implementation was correct.

I think this is important because LLMs are probabilistic. They can generate something that looks correct, follows the naming conventions of the application and is still completely wrong.

The compiler doesn't really care how convincing the code looks. Either the property exists or it doesn't.

Obviously this doesn't mean TypeScript proves your application is correct. You can write completely wrong business logic that compiles perfectly:

function calculateRefund(payment: number) {  
  return payment * 2;
}

TypeScript has no problem with that. Tests still matter, runtime validation still matters and code review still matters.

But TypeScript eliminates a pretty large category of structural mistakes before the tests even run, and I think that becomes especially valuable when the code is being generated by AI.

TypeScript Also Helps Centralize Context

I've been thinking a lot lately about how important context is for AI coding tools, and this is part of why I've become more interested in monorepos.

If your frontend, API, workers and shared libraries all live together, the AI has a better chance of understanding the application as one system instead of a bunch of isolated repositories.

TypeScript adds another layer to that.

The monorepo gives the AI more code.

TypeScript gives the AI more information about that code.

A repository might contain thousands of functions and objects, but types start describing how those pieces are related.

Something like:

interface Payment {  
  registrationId: string;
  userId: string;
  amount: number;
  status: PaymentStatus;
}

already tells the AI that payments are related to registrations and users.

Then a function signature like:

function refundPayment(  
  payment: Payment,
  registration: Registration
): RefundResult

describes another relationship.

You start building a kind of graph of the application just through the type system. Humans get value out of this too, but I think it's especially useful for AI because the agent doesn't have years of experience with the application and doesn't know all of the relationships by memory.

The more of the architecture and business domain we can make explicit, the less the AI has to infer.

Why I Think TypeScript Is More Valuable Now

TypeScript was already useful before AI. It made Javascript safer, made refactoring easier and helped larger teams understand how data moved through an application.

I think AI increases the value of those same features.

AI makes code significantly cheaper to generate, but that doesn't necessarily make correctness cheaper. If anything, I think it makes correctness and context more valuable because there is simply more code being produced.

Types give AI more information about what the application expects, the compiler gives it an immediate feedback loop, and using TypeScript across more of the stack makes it easier to share models and business logic instead of duplicating them.

The interesting part to me is that TypeScript may be becoming more important for a reason that wasn't really part of the original pitch.

It isn't just making Javascript easier for developers to understand. It's also making the application easier for AI to understand.

Comments powered by Disqus