Post

Last week I showed my risk filter flagging a dark-theme CSS change as touching auth, billing, and secrets. Wrong, for a dumb reason...it decides what's "sensitive" by matching file paths against sensitive-sounding names. So how should it actually know? 🧵

Option 2: CODEOWNERS, reusing the ownership signals already in the repo. Option 3: incident history, learning which parts of the codebase actually caused problems, whatever they're named. Most accurate by far.

0 reposts0 likes

My call for v1 is the simple one: name matching + optional config, CODEOWNERS close behind, incident history later. And I'm nervous about it. It leans on people naming files conventionally (they don't) and filling out a config (they might not).

The version that fixes this needs real incident data. But I won't have that data until people use the thing. That's the bind...the simple version is what I can launch, but the good version only exists on the far side of people using the simple one.

So I made the call...ship simple anyway, treat its mistakes as the data. The bet, on purpose, is that it's useful enough while it's sometimes wrong to earn its way to better. "Wait until it's good" quietly becomes "never shipped." When has shipping rough to learn paid off for you?