"I asked Antigravity to write some code and now I have 100+ TypeScript errors." If that sounds familiar, you're not alone. When I first started using Antigravity, I hit this exact wall repeatedly — fix one error, two more appear, and before long you're 30 minutes deep in an AI correction loop that shouldn't exist.
The frustrating part is that the AI isn't doing anything wrong, technically. It's writing valid TypeScript — just not valid for your project. The mismatch between what Antigravity knows and what your codebase expects is the real culprit. And once you understand that, the fix becomes obvious.
Why AI-Generated Code Tends to Break TypeScript
There are three root causes behind most TypeScript errors from AI-generated code.
Missing type definition files. Even if your project has a types/ folder or *.d.ts files, Antigravity won't know about them unless they're in the active context window. Without this, the AI invents type shapes based on guesswork — and those guesses rarely match your actual User, Product, or ApiResponse definitions. The result is a cascade of Property 'xxx' does not exist errors that are frustrating because they feel like the AI should have known better.
Library version mismatches. The JSX type definitions changed between React 18 and 19. App Router types shifted between Next.js 14 and 15. Prisma's typed client API looks different across major versions. The AI's training data is anchored to specific library versions that may not match yours. When they diverge, you get type errors that look cryptic because they'd be correct for a slightly different setup.
Unaware of your tsconfig.json strict settings. With "strict": true enabled, the "loose" code AI tends to generate by default fails immediately. noImplicitAny and strictNullChecks are the biggest culprits. Any time the AI skips a null check, returns a value without a type annotation, or uses an implicit any, you get an error. The AI isn't being careless — it just doesn't know your project is running with strict guards unless you tell it.
Reading Error Codes to Identify Root Causes Fast
Before jumping into fixes, run a quick tally of which TypeScript error codes are appearing most:
# Group errors by TS code to spot the dominant pattern
npx tsc --noEmit 2>&1 | grep "error TS" | grep -oP "TS\d+" | sort | uniq -c | sort -rnOnce you see the codes, patterns emerge that point directly to the root cause.
Property 'xxx' does not exist on type 'yyy' (TS2339) — Context problem. The AI doesn't know your type definitions. Share your types/ directory contents before asking for more code.
Type 'string | undefined' is not assignable to type 'string' (TS2322) — strictNullChecks is on, but the AI skipped null guards. Explicitly telling Antigravity that strict mode is active will prevent this in future generations.
Cannot find module 'xxx' or its corresponding type declarations (TS2307) — Either @types/xxx isn't installed, or the AI hallucinated a package that doesn't exist in your project. Check package.json and run npm install @types/xxx if needed, or correct the import.
Argument of type 'xxx' is not assignable to parameter of type 'yyy' (TS2345) — Often a library version mismatch. Share your package.json dependency list with Antigravity before asking it to write code that uses that library.
Object is possibly 'undefined' (TS2532) — Another strict mode issue. The AI assumed something would always exist, but your config says it might not. Add a conditional check or the optional chaining operator (?.).
Once you can read the error codes as a diagnosis rather than just noise, you'll know exactly which piece of context to provide before asking for a fix.
Front-Loading Context to Prevent Errors Before They Happen
The most effective change you can make is sharing context before asking Antigravity to write code, not after it breaks. I keep a small script that dumps the relevant project context:
# Quick snapshot of the project's TypeScript setup
echo "=== tsconfig.json ===" && cat tsconfig.json
echo "=== Dependencies ===" && cat package.json | grep -A 40 '"dependencies"'
echo "=== Type definition files ===" && find . -name "*.d.ts" -not -path "*/node_modules/*"
echo "=== Custom types ===" && ls types/ 2>/dev/null || echo "(no types/ directory)"Paste this output at the start of any coding session where you're asking Antigravity to generate substantial code. Pair it with a plain-language note: "This project uses TypeScript strict mode with strictNullChecks: true. Please add explicit type annotations to all function parameters and return values, and use unknown instead of any."
In practice, this single habit cuts the error rate dramatically. The AI can write perfectly type-safe code — it just needs to know your constraints explicitly.
Custom Rules for Permanent, Zero-Effort Prevention
Manually pasting context at the start of every session is better than nothing, but it gets tedious. The real fix is a .rules file (or .antigravity/rules.md) with project-specific TypeScript guidelines that Antigravity reads automatically:
# TypeScript Coding Rules
## Type Safety Requirements
- This project uses TypeScript strict mode (`"strict": true` in tsconfig.json)
- Do NOT use `any` — use `unknown` with proper type guards instead
- Do NOT use `\!` non-null assertions — use conditional checks or optional chaining
- Add explicit type annotations to all function parameters and return values
- Do NOT use type assertions (`as SomeType`) unless absolutely necessary
## Where Types Are Defined
- Custom domain types are in the `types/` directory
- API response types are in `types/api.ts` — always use these for fetch responses
- Component props types are defined inline in each component file
- Zod schemas in `schemas/` are the source of truth for runtime shapes
## Library Versions (important for type compatibility)
- React 19 — the `use()` hook is available; `FC` type is still valid
- Next.js 15 with App Router — `params` and `searchParams` are Promises in page components
- Zod 3.x for validation — use `z.infer<typeof Schema>` to derive types
- Prisma 5.x — use the generated client types from `@prisma/client`
## What NOT to Do
- Do not add packages that aren't in package.json
- Do not modify tsconfig.json settings
- Do not create new type definition files in node_modulesOnce this file is in place, Antigravity reads it before generating any code. You stop seeing any-typed variables and missing null checks without having to remind the AI every time. The rules persist across sessions and benefit the whole team if you commit the file.
Recovering When Errors Have Already Piled Up
If you're already looking at a wall of errors, the worst thing you can do is ask Antigravity to "fix all TypeScript errors at once." Without proper context, it will introduce new errors while patching the old ones. Here's a more reliable recovery sequence.
First, get the full picture in one command:
# Files with the most errors — start with these
npx tsc --noEmit 2>&1 | grep "error TS" | sed 's/(.*//' | sort | uniq -c | sort -rn | head -10Then share type context before asking for any fixes. This framing works well:
"I have TypeScript errors in my project. Before making any changes,
please review these type definitions that the entire codebase relies on:
[paste contents of types/api.ts]
[paste contents of types/user.ts]
With that context, please fix only the errors in src/components/UserCard.tsx:
[paste errors for that one file only]"
Work file by file. It feels slower than asking for a bulk fix, but the changes actually stick. You avoid the cascade effect where one correction breaks three other call sites.
If the errors span many files and share the same root cause (usually a missing null check or wrong type import), ask Antigravity to write a fix pattern once, then apply it yourself across the affected files using find-and-replace. This keeps the AI in the "figure out the fix" role and you in the "apply it consistently" role, which plays to each tool's strength.
Zod Integration: The Most Reliable Type Safety Pattern
Pairing Antigravity with Zod is one of the most effective combinations I've found for preventing AI-generated type errors altogether. When API response shapes are defined as Zod schemas, Antigravity treats them as authoritative type sources rather than guessing:
import { z } from "zod";
// Define the schema — this becomes the single source of truth
const UserSchema = z.object({
id: z.string().uuid(),
name: z.string().min(1),
email: z.string().email(),
role: z.enum(["admin", "user", "guest"]),
createdAt: z.string().datetime(),
// Optional fields are explicit — no ambiguity about nullability
avatar: z.string().url().optional(),
});
// Type is inferred automatically — no manual duplication that can drift
type User = z.infer<typeof UserSchema>;
// Validated fetch — type errors surface at the data boundary, not inside business logic
async function fetchUser(id: string): Promise<User> {
const res = await fetch(`/api/users/${id}`);
if (\!res.ok) throw new Error(`HTTP error: ${res.status}`);
const data: unknown = await res.json();
// ZodError thrown here if the shape doesn't match — catches API contract breaks early
return UserSchema.parse(data);
}
// AI-generated code that uses User will know exactly what fields exist
function getUserDisplayName(user: User): string {
// No TS errors because the type is inferred precisely from the schema
return user.name;
}When you share Zod schemas with Antigravity before asking it to write code that handles that data, it reads the schema as the type definition. The z.infer<typeof Schema> pattern eliminates manual type duplication, so there's no risk of the TypeScript type and the runtime validation getting out of sync.
The broader lesson is that TypeScript errors from AI-generated code are almost always a context problem, not an AI capability problem. Antigravity can produce fully type-safe code — it just needs your type definitions, strict settings, and library versions made explicit. Start with the .rules file today, and share your types/ directory in the next session where you're generating substantial code. The improvement is immediate.