Your AI-built store passed the build. That proves less than you think.

"It builds" is doing a lot of work in most conversations about whether software is finished. It's doing more of it in codebases where an AI wrote a lot of the code, because the failure mode isn't syntax — it's confident code that compiles and is wrong.

Here's ours, on our own site.

The build was lying, politely

We changed some shared code and ran the production build. It said what it always says:

✓ Compiled successfully in 3.4s

Then we ran the typechecker separately, which is a habit rather than a suspicion:

components/HubPage.tsx(51,48): error TS2304: Cannot find name 'site'.
components/HubPage.tsx(51,70): error TS2304: Cannot find name 'site'.

A file was using a variable it never imported. That page would have rendered a 500 in production. The build was completely happy about it.

Why? One line in the config:

typescript: { ignoreBuildErrors: true }

Somebody set that. Probably to unblock a deploy on a Friday, for a reason that was good at the time. It's been silently disarming the typechecker ever since, and the build has been reporting success it has no basis for.

It wasn't the only one

Same week, different codebase — our own commerce platform. The dev server had been running fine for weeks. Then we ran the production build for the first time in a while:

src/api/.../plans/route.ts     const withSteps = []   → never[]
src/api/.../restocks/route.ts  const out = []         → never[]
src/subscribers/order-placed.ts  'item' is possibly 'null'

Three real type errors. The dev server never mentioned them because it transpiles without typechecking — fast, which is the point, and quiet about exactly this. Everything worked in development. The thing we'd have deployed did not build.

We'd been demoing that platform. It couldn't have shipped.

Why this is worse in an AI-heavy codebase

AI-generated code is syntactically excellent. It's plausible. It imports things that sound right, calls methods that ought to exist, and produces a shape that looks exactly like working code — which is precisely the class of bug a typechecker catches and a bundler doesn't.

Meanwhile the pressure that produced ignoreBuildErrors: true is stronger, not weaker, when you're shipping fast with a model writing most of it. The errors are more numerous, less interesting, and easier to wave through. So the check gets disabled at exactly the point it starts earning its keep.

Every static-analysis tool you have is one config line away from being decorative. Nobody removes them. They just get switched off, once, for a reason, by someone who meant to come back.

Check yours this afternoon

1. Run the typechecker directly. npx tsc --noEmit. Don't trust the build to run it — find out whether it does.
2. Grep your config for the escape hatches. ignoreBuildErrors, ignoreDuringBuilds, --no-verify, continue-on-error: true, an eslint-disable at the top of a file. Each one is a check somebody turned off.
3. Run the production build. Not the dev server. They are different programs with different standards, and only one of them is what you deploy.

Two commands. If they're clean, you've lost five minutes. If they're not, you've found out on a Tuesday instead of during a launch — which is the entire difference.

Our own site's build had been reporting success over an ignored typechecker for long enough that nobody remembered. We only found it because a change we made happened to break in exactly the way the disabled check was designed to catch.