AI-generated code: what TypeScript can check

In August 2025, TypeScript became the most-used language on GitHub by monthly contributors. That metric does not represent the entire industry, but it confirms a shift already visible across product teams: typed JavaScript is now part of the standard web development toolkit.

TypeScript covers the browser, React and Next.js, Node.js APIs, workers, and much of the surrounding tooling. A team can use one language from the frontend to the server. That convenience stops at runtime boundaries: a TypeScript interface does not validate JSON received from an API, a database, or an LLM.

A model generates plausible code. It may invent a property, miss a branch in a union, or call a function using an outdated signature. The compiler cannot tell whether a feature is useful, but it can compare the diff with the contracts that exist in the repository.

Code agents are generally familiar with common TypeScript APIs and patterns. That makes a first pass faster, but it does not guarantee a match with the installed version or local conventions. Diagnostics from the type checker bring the agent back to the codebase it is actually changing.

The type checker answers a narrow question: is this code compatible with the declared contracts? It cannot validate the product requirement, but its answer is fast and repeatable.

A good task for an agent has one clear goal. It states the expected behaviour, the relevant files, and the constraints that must remain intact. The first diff can then be checked with the repository’s own commands instead of relying on an abstract description of the project.

Errors from tsc --noEmit give the agent a concrete correction list. Once the automated checks pass, review can focus on everything they do not cover: intended behaviour, readability, operational risk, and whether the tests are meaningful.

type Job =
    | { status: 'queued' }
    | { status: 'done'; url: string }
    | { status: 'failed'; message: string }

function assertNever(value: never): never {
    throw new Error(`Unhandled job: ${JSON.stringify(value)}`)
}

function jobLabel(job: Job): string {
    switch (job.status) {
        case 'queued': return 'Queued'
        case 'done': return job.url
        case 'failed': return job.message
        default: return assertNever(job)
    }
}

If the first diff omits the failed branch, assertNever(job) no longer compiles: job can still contain that state. The diagnostic tells the agent which case to handle. A person must then check that the displayed message and interface behaviour fit the product. This check assumes incoming data has already been validated at runtime.

The same issue arises when an agent changes a feature that calls a model. Data received from an API, database or LLM needs runtime validation. Types alone do not perform that check.

Libraries used for these features have their own contracts. Vercel’s AI SDK provides structured output and schema-validated tools; TanStack AI includes typed tools and streaming. Capabilities depend on versions, providers and models. The TanStack AI beta status described in the sources also matters when choosing and maintaining the integration.

1. 01

   Validate external data

   Zod, Valibot, or JSON Schema can reject a malformed call. Domain checks, such as access to a resource or a valid date range, still need explicit service logic.

2. 02

   Keep each tool contract narrow

   A tool with a few well-named parameters and a documented result is easier to call, test, and evolve than a generic function that exposes an entire service.

3. 03

   Review the resulting behaviour

   A diff can compile while choosing the wrong API, swallowing an error, or adding an unnecessary dependency. Review should cover those decisions, not just code shape.

The same schema can drive a tool call and its handler when both describe the exact same contract. API, domain, and persistence models should not be collapsed into one shape just to avoid a little mapping code.

With strict mode enabled, the compiler can catch a missing property, an unhandled undefined value or an incompatible response. It cannot tell whether a business rule is correct, whether a user is allowed to act or whether a query returns the right data. Those concerns still require runtime checks, focused tests and careful review.