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? 🧵

27/6/26, 3:02 pm0 reposts0 likes

Jake Lundberg

@jakelundberg.dev

27 June

Option 1: name/path matching plus an optional config file teams fill in. Dead simple, ships now, zero data.

Jake Lundberg

@jakelundberg.dev

27 June

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.

Jake Lundberg

@jakelundberg.dev

27 June

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).

Jake Lundberg

@jakelundberg.dev

27 June

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.