Future Debug Cost

Future Debug Cost is the number Firetrail puts on every pull request: a score from 0 to 100 estimating how much debugging pain this change is likely to cause after it merges. A PR that scores 8 is probably going to be uneventful. A PR that scores 75 has several of the patterns that — in most codebases, most of the time — come back as bug reports, confused maintainers, and painful rollbacks.

Let's be upfront about what this number is: an invented metric. Nobody can measure the future. What Firetrail can do is recognize the structural patterns that make changes expensive to live with — mixed concerns, untested logic, config with a wide blast radius, code that's hard to read — and add them up into a number that points your attention in the right direction. The test of a metric like this isn't whether it's "true"; it's whether it points somewhere useful. (The Business Impact page checks that against your own history: did the PRs Firetrail scored high actually turn out to be the ones that caused bugs?)

The bands

The score maps to four color-coded bands:

The score is capped at 100, and several patterns at once can add up past it, so a 100 means "many drivers fired", not "the worst change possible". That's why the number is always shown with how many drivers fired next to it. It is also why the score can be Critical while every reviewer on the team is only lukewarm: each reviewer grades one angle, and their verdicts are never added together. The score is the sum.

How the score is built

The score isn't a gut feeling from an AI — it's assembled point by point, and every point is traceable.

Here's the mechanism. A set of classifiers — independent checks, each looking for one specific pattern — reads the PR's diff. Each one reports what it found, how serious it is, and how confident it is. Then the scorer adds up the findings into risk drivers: line items with a label and a point value.

A real breakdown looks something like this:

62 — High

• +15 · Multiple unrelated intents in one PR
• +14 · Complex meaningful logic change
• +12 · No tests cover the changed behavior
• +11 · Global configuration changed
• +10 · Refactor mixed with behavior changes

Two rules keep the number honest:

• Low-confidence findings don't count. If a check isn't sure about what it saw, its finding is still shown on the PR — but it contributes zero points. The score is built only from findings Firetrail would stand behind.
• Trivial changes get discounted. One check, Triviality, exists purely to subtract points: a rename touching 40 files looks scary by size, but if it's behaviorally trivial, the discount reflects that. Big ≠ risky.

Only built-in classifiers move the score. Custom classifiers — the checks you write yourself — show their findings alongside, but never change the number. That keeps a "62" meaning the same thing on every project.

The breakdown is the product

Honestly, the score exists mostly to get your attention. The breakdown — that itemized list of drivers — is the useful part, because every line is actionable:

• "+15 Multiple intents" → could this be two PRs?
• "+12 No tests cover the changed behavior" → what would a test for this look like?
• "+11 Global config change" → who should sanity-check the deploy config?

If you only ever read one thing Firetrail produces, read the breakdown.

What to do at each band

• Low — merge with a normal review. No ceremony needed.
• Moderate — skim the breakdown; usually there's one driver worth a question in review.
• High — read the breakdown before the code. It tells you where the risk is concentrated, so you review the right files with the right question in mind.
• Critical — treat the breakdown as a conversation starter with the author. Often the right move is splitting the PR, adding tests to the risky part, or planning the rollback path before merging.

What the score will never do

The score never blocks a merge, fails your CI, or overrules your judgment. Firetrail's default posture is advice: it directs attention and starts conversations. If your team decides it wants hard rules, those are built separately — on specific, objective facts rather than the overall score — in Merge Checks.