TypeScript errors break the build in my AI-written project
Why an AI-written app runs in development but fails to build on TypeScript errors, how to find and fix the real error, and why not to turn the check off.
Leer en español →
When an AI-written app runs fine in development but the build fails with TypeScript errors, it's because the production build checks types and the development server doesn't block on them. next build runs a type check by default, and Vite projects usually run tsc before vite build, while Vite's dev server only strips the types and runs the code. Reproduce it locally with npx tsc --noEmit, fix the errors one file at a time starting with the first, and regenerate your database types if they're out of date. Turning the check off makes the build pass and moves the bugs to your users.
This guide explains where these errors come from in AI-written code, how to read them, what the most common ones mean and how to fix them, and how to stop them coming back.
Why does it work in development but fail in the build?
Two different programs are involved. In development, Vite and similar tools convert TypeScript to JavaScript as fast as possible and skip type checking, so a mismatch that would crash only in an edge case never stops the page from loading. The production build is stricter:
- Next.js fails
next buildwhen there are TypeScript errors, unless someone has disabled it. - Vite templates for React and TypeScript use a build script like
tsc -b && vite build, so the type checker runs first and stops the build if it finds errors.
Your hosting provider runs the build script, which is why the failure often shows up first on Vercel or Netlify, long after the code was written.
How do I find the actual error?
In the build log, scroll past the install steps to the first error. TypeScript errors name a file, a line and column, and a code:
src/pages/Invoices.tsx(42,17): error TS2339: Property 'total' does not exist on type 'Invoice'.Then reproduce it on your machine so you aren't waiting for deploys:
- Run
npm run buildto do exactly what the host does. - For a faster loop, run
npx tsc --noEmit(ornpx tsc -bif your project usestsconfigreferences, as Vite templates do). It prints every type error without producing files. - Fix the first error in each file before looking at the rest. One wrong type often causes several errors further down.
If the build passes locally but fails on the host, see the section on case-sensitive imports below, and our guide on reading a Vercel build log.
What do the common errors mean?
| Code | Message (shortened) | What it usually means in AI-written code | Typical fix |
|---|---|---|---|
| TS2339 | Property 'x' does not exist on type 'Y' | The code uses a field the type doesn't have: a renamed column, a field the AI assumed exists | Use the real field name, or update the type if the field is real |
| TS2322 | Type 'X' is not assignable to type 'Y' | A value of the wrong shape, often string where a number or a specific set of values is expected | Convert the value, or fix the type that's too narrow or too wide |
| TS2345 | Argument of type 'X' is not assignable to parameter of type 'Y' | A function was called with the wrong kind of value, often after its signature changed | Update the call, or the function, so they agree |
| TS18048 | 'x' is possibly 'undefined' | Data that may not have loaded yet, or an optional field, is used as if it's always there | Handle the empty case: an early return, a default value, or a loading state |
| TS7006 | Parameter 'x' implicitly has an 'any' type | A callback or function parameter has no type in strict mode | Add the type |
| TS2307 | Cannot find module 'x' or its corresponding type declarations | Wrong import path, a missing package, or missing type definitions | Fix the path, install the package, or install its types |
| TS6133 | 'x' is declared but its value is never read | Leftovers from earlier attempts, when unused-variable checks are on | Remove the unused code |
The first four are the ones AI tools produce most, because the agent edits one file at a time and doesn't always update the types and callers that depend on it.
What if the errors are about database types?
Apps on Supabase often have a generated file describing every table and column. When the agent adds a column through a migration but doesn't regenerate that file, every query that uses the new column fails with TS2339 or TS2322. Regenerate the types from the live schema:
npx supabase login
npx supabase gen types typescript --project-id "$PROJECT_REF" --schema public > database.types.tsWrite the output over the file your project already uses, wherever it lives. The Supabase guide to generating types covers the options. If the errors disappear after this, the code was fine and the types were stale.
Why shouldn't I just switch the check off?
Because the errors are telling you about real bugs. Next.js lets you set typescript.ignoreBuildErrors to true, and its own documentation describes this as dangerously producing production code even when the application has errors: it skips type checking completely. The same goes for scattering // @ts-ignore, as any or setting "strict": false in tsconfig.json. The build turns green and the "possibly undefined" value crashes the page for the first user with an empty account.
If you're blocked on a launch, a temporary bypass with a written list of the errors and a date to fix them is a business decision. Making it permanent is how small bugs pile up into technical debt.
How do I get the AI to fix them without making it worse?
- Give it one error at a time, with the file and line, rather than the whole log.
- Ban the shortcuts in your rules: "Never use
any,@ts-ignoreor@ts-expect-error, and never loosentsconfig.json, to fix a type error. Fix the cause." - Ask it to run the checker after each fix and paste the result.
- Read the diff. If a fix for one error changed ten files or the
tsconfig, stop and ask why.
Why does it pass on my Mac but fail on the server?
The classic cause is letter case. macOS and Windows usually treat Button.tsx and button.tsx as the same file; the Linux machines that run most builds don't. If the agent renamed a file's case, or imports it with different capitalization, the build fails with TS2307 on the host only. Make the import match the file name exactly. A different Node.js version or a package missing from package.json can cause similar host-only failures.
Quick answers
Is npx tsc --noEmit safe to run? Yes. It only checks; it doesn't change files or produce output.
There are 200 errors. Where do I start? Run the checker, fix the first file, run it again. Counts usually drop fast because errors cascade.
Can I avoid this next time? Run the type check on every push in CI and before an agent declares a task done. See tests for AI-generated code for a simple workflow.
Should I switch the project from TypeScript to JavaScript? No. You'd keep the bugs and lose the tool that finds them.
Build still red?
If the error list keeps growing or the fixes keep breaking other screens, the types are usually pointing at a deeper mismatch between the code and the data. Our Cursor project help explains how we approach that, the free health check shows what's visible from outside, and you can send us the build log.
