← The Journal

Never trust a self-declared risk level

The riskiest changes are often the ones that look safe. Here is why we stopped letting anything, person or AI, grade its own homework, and judge a change on what it actually does.

When you let anything propose a change, a person or an AI assistant, it will usually offer an opinion about how risky that change is. "Small tweak." "Low risk." The trap is believing it.

We run a change-governance system on our own products. An AI assistant proposes edits, and a set of guardrails decides what ships automatically and what needs a human. Early on, one of those guardrails was only advisory. A shared file, one that loaded on every screen, was marked "sensitive," but a change to it could still be approved with a single click. One day it was. The edit introduced a subtle initialization error, and because the file touched every screen, it took down the whole app. A white screen everywhere, from a change that had been signed off as fine.

The lesson was not "review more carefully." It was structural. Risk cannot be a label the author attaches, because the author, human or model, is the least reliable narrator of their own blast radius. So now risk gets computed on our side, from the actual diff: which files changed, how many lines, whether it reaches auth, payments, data, or anything that loads app-wide. And the gate that holds a risky change back ignores the risk label completely, so nothing can be relabelled around it. A short list of critical paths simply cannot be auto-approved, by anyone, in any environment. That list exists because of the incident, and the reason for it is written in a comment right beside it.

The general version: separate the thing that proposes a change from the thing that judges it, and let the judge look at what the change actually touches, not what it claims. That is the whole difference between a guardrail and a suggestion.