Fix TypeScript Errors With AI Without Casting to any

To fix TypeScript errors with AI, count and group the errors by code first, then hand the model one group at a time with three hard rules: no any, no type assertions to silence a message, and no @ts-ignore. Re-run the compiler after each group and confirm the total went down.

The failure mode is easy to picture. You turn on strict mode, get 214 errors, paste them all into a chat, and an hour later the build is green. Then you open the diff and find forty new as any casts. The errors went away because the checks were switched off, not because the code got safer.

Fix TypeScript errors in order: count and group them first

Run the compiler without emitting files, then tally by error code.

npx tsc --noEmit --pretty false > tsc.log
grep -o 'TS[0-9]\+' tsc.log | sort | uniq -c | sort -rn

You will usually see three or four codes account for most of the output. Write the starting total down. It is your scoreboard for the rest of the job.

Four codes cover a large share of what strict mode turns up:

Step 2: Sort each group into two bins

For every group, ask one question: is the code wrong, or is the type wrong?

The TypeScript documentation for the strict flag gives a clean example. With strictNullChecks on, users.find(...) can return undefined, so reading .age on the result is an error. Here the code is wrong, because at runtime it can crash. The fix is a branch that handles the missing user, not a cast that hides it.

Compare a type that is merely out of date: an API response gained a field, the interface did not. Here the type is wrong. The fix is to update the interface, ideally from the real response.

Sorting first matters because the model cannot tell which bin an error belongs to. It sees a red line and makes it go away by the shortest route, and the shortest route is almost always a cast.

Step 3: Give the model one group and tight rules

Fix the TypeScript errors listed below. Only these errors, only these files.

Hard rules:
- No `any`, explicit or implicit.
- No `as` assertions to silence an error. An `as const` is fine.
- No `@ts-ignore` or `@ts-expect-error`.
- No changes to tsconfig.json.
- If an error is a real bug (a value can be null or undefined at runtime),
  add the check or the handling. Do not change the type to hide it.
- If you cannot fix an error without breaking one of these rules, stop
  and list it with a one-line reason. Do not guess.

Errors (group TS2339, 31 errors):
<paste only this group>

The last rule is the one that earns its place. A model with no permission to give up will break a rule instead. Give it an exit and you get a short list of the cases that need a person, which is where you want to spend your attention anyway.

Step 4: Verify the number, then read the diff for cheating

After each group, re-run the compiler and compare to your scoreboard. Then search the diff for the three escape hatches.

git diff -U0 | grep -nE '(: any\b|as any|@ts-ignore|@ts-expect-error|as unknown as)'

Any match is a rule violation to send back. as unknown as Foo deserves special suspicion, because it is the double cast that turns the type checker off for one expression.

Then run your tests. A type fix that changes behavior, for example turning a crash into a silent return, should be visible in a test. If you have none for that code path, writing tests with AI first gives you something to lean on, and prompting AI to fix a failing test covers the loop for when one does fail.

Things that go wrong

• Fixing from the bottom of the log. An error early in a file often causes several later ones. Fix the first error per file, re-run, and the count drops by more than you expect.

• Letting the model edit tsconfig. Loosening strict is the fastest route to zero errors and the worst outcome. Keep it in the rules.

• Fixing too much at once. A 600-line diff cannot be reviewed. Commit after each group so any one of them can be reverted alone.

• Trusting generated types for external data. A type is a claim about runtime data. If the data comes from an API or a form, check it at the boundary instead of only declaring its shape.

If an agent is doing the editing, apply the habits from using Git with an AI coding agent safely so every group lands as its own commit. The wider AI coding tools guide helps you choose between assistants and agents for this kind of sweep.

If you are earlier in the process and still converting files, see converting JavaScript to TypeScript with AI in safe batches.

FAQ

Can AI fix all my TypeScript errors?

It can fix many of them, especially missing annotations and out-of-date interfaces. Errors that point at real runtime bugs need a decision about behavior, and that decision should be yours.

Is it okay to use any to get past an error?

As a temporary marker, sometimes. As the fix, no. It removes the checking for everything that touches the value. Use unknown and narrow it if the type is truly not known.

What does strict mode turn on?

According to the TypeScript docs, it enables a family of checks including noImplicitAny, strictNullChecks, strictFunctionTypes and strictPropertyInitialization, among others. The docs also warn that newer TypeScript versions may add checks under the flag.

Why do I get new errors after upgrading TypeScript?

The strict family can gain checks between releases. Group the new errors by code and work through them the same way.