TypeScript for AI Applications

What is it?

TypeScript is JavaScript with a type system. For AI applications that means describing chat messages, tool-call payloads, streaming events and your database rows as types or interfaces. The compiler flags mismatches when a field is renamed or optional when you assumed it required.

Why it matters

Model APIs and tool schemas evolve. Without types, typos in choices[0].message.content fail at runtime in production. With types — especially shared types between React and Node — the UI and API stay aligned. Pair types with runtime validation for data from the model or network.

How to do it

1. Model your domain types: ChatMessage, ChatRequest, ChatSuccess, ChatError.
2. Keep vendor-specific response types in an adapter module (TypeScript Types for an API Client).
3. Validate JSON at the trust boundary (HTTP body) before casting.
4. Prefer unknown + narrow over any for model output.
5. Generate or hand-write types for tool arguments you accept from the model.

Example

type Role = "system" | "user" | "assistant";
export type ChatMessage = { role: Role; content: string };

export type ChatRequest = {
  messages: ChatMessage[];
  stream?: boolean;
};

export type ChatSuccess = { text: string; model: string };
export type ChatError = { error: string; code: "unauthorized" | "upstream" | "bad_request" };

The React client imports ChatRequest; the Node route validates the body matches before calling the vendor.

When to use it

Use TypeScript when more than one file talks to the model or when multiple developers touch the client contract. Plain JavaScript remains fine for tiny scripts.

Practical notes

Adopt a single 'types/' folder for message and tool shapes used by both UI and API. Enable 'strict' in 'tsconfig' early; turning it on later is painful. Prefer discriminated unions for model/tool events ('{type:'token'} | {type:'done'} | {type:'error'}') so switch statements stay exhaustive. When a vendor SDK ships its own types, wrap them — do not leak SDK classes into React components. Runtime validation still matters: TypeScript disappears at runtime, and model JSON can violate the types you hoped for. Pair this page with TypeScript Types for an API Client when you implement the actual client module, and with How to Validate JSON for boundary checks. Work through one real request end to end, write down the failure modes you observed, and add a regression test so the next change does not silently drop validation, auth, or logging. Prefer boring, reviewable code over a clever abstraction until the second or third product needs the same pattern. Work through one real request end to end, write down the failure modes you observed, and add a regression test so the next change does not silently drop validation, auth, or logging. Prefer boring, reviewable code over a clever abstraction until the second or third product needs the same pattern.

Common mistakes

• Asserting as ChatSuccess without parsing.
• Typing only the happy path and ignoring error unions.
• Duplicating slightly different message types in UI and server.

Related concepts