Why AST Analysis Catches Breaking Changes That Regex Misses

Most tools that claim to detect breaking API changes use regex under the hood. It seems reasonable — search for the field name, see if it's still there. Simple, fast, works most of the time.

Except when it doesn't. And when it fails, it fails silently.

The regex approach

Imagine you have this TypeScript interface:

export interface UserResponse {
  id: string
  email: string
  emailAddress: string  // legacy field
}

Now you remove email. A regex-based tool searches for the string email in your codebase and finds hundreds of matches — including emailAddress, comments, string literals, and unrelated code.

It either flags everything (noise) or misses the actual usages (false negatives). Neither is useful.

The AST approach

BreakShield CI uses ts-morph to parse a full TypeScript AST. This means it actually understands your code structure.

When it looks for usages of email, it finds:

• Direct access: user.email — 90% confidence
• Destructuring: const { email } = user — 80% confidence
• Type annotation: param: UserResponse — 80% confidence
• Object literal: { email: value } — 65% confidence

It does NOT match emailAddress, comments, or unrelated variables with the same name.

Confidence scoring

Every finding gets a confidence score. Low-confidence noise is filtered automatically. If there's no AST-verified evidence, there's no warning.

This means zero false positives from generic field names like id, name, or status that appear in hundreds of unrelated places.

Why it matters

A tool that cries wolf on every PR is worse than no tool at all. Developers learn to ignore it.

BreakShield CI only warns you when it has proof. Every finding includes the exact file, line number, and code snippet. You can verify it in seconds.