DEV Community

Vojta Holeš
Vojta Holeš

Posted on

You Shouldn't Need a Production Incident to Find Breaking API Changes

You open Slack on Monday morning. There's a thread with 43 replies. Someone merged a PR on Friday. A field got removed from an API response. Three services are broken. Customers are affected. Nobody caught it in review.

It didn't have to happen.

The Problem Nobody Talks About
Code review catches logic bugs, style issues, missing tests. But it almost never catches API contract violations.

A required field disappears from a response type
A parameter type changes from string to number
An endpoint gets deleted
A new required field appears in a request body
These are invisible in a diff. The TypeScript compiler won't warn you. Your tests pass because they mock the old contract. ESLint doesn't care.

And then production cares. A lot.

What If Your CI Caught It First?
I built BreakShield CI — a GitHub App that analyzes every PR for breaking API changes.

Not with an LLM. Not with vibes. With AST analysis.

It parses your TypeScript code, diffs the abstract syntax tree between base and head, and flags exactly what changed, where it's used, and how dangerous it is.

What It Detects
Change type Example
Removed field UserResponse.email deleted
Changed type id: number → id: string
Removed endpoint GET /api/users/:id gone
Added required field New organizationId required in request
Changed return type Function returns Promise instead of Promise
Removed interface PaymentMethod type deleted entirely
Every finding comes with:

Confidence score (80%+ = AST-verified, no guessing)
Consumer search — which files in your repo actually use that field
Risk level — CRITICAL / HIGH / MEDIUM / LOW / SAFE
Before/after — what it was, what it is now
AI Auto-Fix. In the PR.
Detection is only half the story. You also need a fix.

BreakShield CI now supports AI-generated fixes — directly from your PR.

Type /fix as a comment in your PR. BreakShield:

Reads the affected file
Sends it to your AI provider with context about what broke
Generates the fix
Opens a new PR with the corrected code
You review. You merge. Done.

Supported Providers
Provider Models Free tier?
Google Gemini 3.5 Flash, 2.5 Pro, 2.5 Flash ✅
OpenAI GPT-5.5, GPT-5.4, GPT-5.4 mini ✅
Anthropic Claude Opus 4.8, Sonnet 4.6, Haiku 4.5

Groq GPT-OSS 120B, Llama 3.3 70B, Qwen3 32B ✅
Perplexity Sonar Deep Research, Sonar Pro ✅
BYOK — bring your own key. You pick the provider and model in settings.

How It Works Under the Hood
No magic. No "AI-powered detection." Here's what actually happens:

PR opened/updated

GitHub webhook fires

Fetch changed files (base vs head)

Parse both versions with ts-morph (TypeScript AST)

Diff exported interfaces, types, functions, endpoints

For each breaking change → search repo for consumers

Calculate risk score → post PR comment + check run
The detection is deterministic. Same code → same result. Every time.

AI is only involved when you explicitly ask for a fix.

What the PR Comment Looks Like
When BreakShield finds something, you get a comment like this:

🟠 HIGH — 1 breaking change · 3 files with verified usages

UserResponse.name
Change removed field
File

user.ts
Confidence 92% · AST-verified
Before name: string
💡 Auto-fix available — comment /fix src/types/user.ts to generate a fix PR.

Zero Config Setup
Install the GitHub App: github.com/apps/breakshield-ci
Open a PR with API changes
BreakShield analyzes automatically
That's it. No YAML. No config files. No CI pipeline changes.

For AI auto-fix, go to the dashboard and add your API key: → breakshield-ci.vercel.app

Why Not Just Use TypeScript?
TypeScript catches type errors within a project. It doesn't catch:

Removing a field that external services depend on
Changing a response type that a mobile app consumes
Deleting an endpoint that 12 microservices call
TypeScript sees your repo. BreakShield sees your API contract.

Why Not an LLM for Detection?
LLMs hallucinate. They miss things. They have different results on different runs.

AST analysis is:

Deterministic — same input, same output
Fast — 500ms-2s per PR, not 30s
Precise — 92-95% confidence, not "probably breaking"
Explainable — exact file, line, usage type
LLMs are great for generating fixes. Terrible for detection where precision matters.

Try It
→ Install: github.com/apps/breakshield-ci → Dashboard: breakshield-ci.vercel.app

Open a PR. Remove a field from an interface. Watch it get caught.

Then type /fix and watch it get fixed.

Top comments (0)