AI code review for TypeScript
TypeScript removes many runtime surprises, but reviews still matter at generics boundaries, unsafe casts, and the gap between compile-time types and JSON at the wire. CodeCritic reads your diff and calls out issues tests and `tsc` alone often skip.
Review focus
TypeScript-specific risks we emphasize
Green `tsc` does not mean the change is safe to ship. We prioritize places types lie, readability collapses, and runtime validation is missing.
- Structural typing traps: excess property checks, incompatible-but-assignable interfaces, and widened unions after refactors.
- Escape hatches: `as` casts, non-null assertions, and `any` imported through third-party `.d.ts` files on hot paths.
- Generics and conditional types that compile but obscure intent for the next maintainer.
- Runtime validation gaps: Zod/io-ts missing at API edges, or DTO types that never get checked on ingress.
- Strictness islands: `strictNullChecks` off in legacy folders while new code assumes null safety.
- Build pipeline drift: `paths` aliases that work in IDE but break in production bundles or test runners.
Type coverage is not security coverage. Keep integration tests on auth, payments, and data migration paths your types cannot model.
Stacks
Common TypeScript codebases we see
Node backends
Express/Fastify handlers with hand-rolled DTOs, Prisma models, and shared types duplicated across packages.
Front-end apps
Props drilling vs context, discriminated unions for UI state, and fetch wrappers typed too loosely at the boundary.
Monorepos
Project references, package exports maps, and duplicate type versions that compile until a consumer upgrades.
Workflow
Review TypeScript changes end to end
- 1
Submit the real diff
Paste the changed `.ts`/`.tsx` files or run a review on a GitHub PR. Include related types if the diff references symbols from another file.
- 2
Check findings against `tsc`
If the compiler already failed, fix that first. CodeCritic targets logic and design issues that type checking does not encode.
- 3
Validate runtime contracts
For API changes, confirm parsers or schema validators match the new types - automated review will flag common mismatches.
- 4
Roll out to the team
Move to shared workspaces and GitHub automation when leads agree the signal is worth standardizing.
Practice
Getting useful TypeScript feedback
When types live in a separate `types.ts`, include them in the review payload if the diff only shows imports - otherwise feedback may guess wrong shapes.
Prefer small PRs that either change types or behavior, not both in one unreadable wall of red.
Document intentional `any` with a one-line comment; reviewers (human and AI) treat unexplained escapes as defects.
Use the GitHub path when your source of truth is already the PR; comments land where engineers negotiate merge.
Combine with code owners on sensitive packages: AI highlights risk, humans decide acceptance for regulated modules.
See limitations and data handling on the trust page before rolling out to repos with customer data.
Details: Integrations, Limitations, Pricing.
TypeScript merge checklist
- Boundary types: Every external input (HTTP, queue, file) has a runtime check or parser, not only an interface.
- Public API surface: Exported types match what consumers actually need - avoid leaking internal union members.
- Nullability: Re-read optional chains added for convenience; they often hide empty-string vs null bugs.
- Tests: Add or extend tests when the diff changes control flow, not only type annotations.
FAQ
TypeScript code review FAQ
Run AI review on your TypeScript
Paste a module or connect GitHub - start free, upgrade when the org needs higher limits.