# Type Error (/academy/type-error)



A type error is a bouncer reading the guest list.

You promised `user.email` is a string. You handed it `undefined`. The [build](/academy/build) dies on your laptop instead of on a judge's phone. That is the whole point of TypeScript in this [stack](/academy/stack).

A **type** is a label on a box: string, number, boolean, this exact shape of user. The compiler checks whether the thing you are pouring matches the label. A type error is that check saying no.

The classics at 2 a.m.:

* `"12" + 1` because an input stayed text
* reading `.id` on `null`
* a function that wanted a Date and got a name

It *feels* like the project exploding. It is the opposite. It is the club catching a fake ID before anyone sits down.

**Read the first red line**

Half of "it won't compile" is this. Fix the shape, not the symptom. The shape lives in a [schema](/academy/schema) — Zod, your [ORM](/academy/orm) models, the type the [API](/academy/api) already published. `as any` is a fake ID. It works until the club burns.

A [test](/academy/test) that expects the right type is a second bouncer. The compiler is the first.

**Agents love to skip the door**

When an [agent](/academy/agent) writes a pile of code and the [CLI](/academy/cli) `bun run build` goes red, do not say "fix it." Paste the *first* type error. The file, the line, the expected vs actual. That is a diagnosis. "Types are broken" is a weather report, and the model will invent a cast.

If the builder gave you TypeScript, use the gift. A red squiggle on your machine is cheaper than a silent `undefined` on stage.

**What this unlocks**

A type error is not your project breaking. It is the labels working. Let them complain early. Spend the complaint budget on the product.