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

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

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.

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

Jake Lundberg

@jakelundberg.dev

27 June

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?