We were pairing on a Thursday. Nothing dramatic. A junior on my team, maybe eight months in, sharp, the kind who actually reads the code instead of...
For further actions, you may consider blocking this person and/or reporting abuse
you can teach someone the rules, but a lot of judgment comes from knowing what actually broke before.
that’s one reason i like having production history in the review loop. PRI (Production Reliability Index) gives the PR another signal based on things like fragility, churn and past incidents when that data is connected.
yeah, that's a sharp connection — PRI is basically trying to do with data what I spent four years growing in my nervous system the hard way.
the thing that gives me pause, in the best way: fragility and incident history is the closest thing we have to a transmissible scar. I couldn't hand the junior the 2am phone call, but "this file has broken three times in prod and churns every sprint" — that I can put on the screen. it won't give him the flinch, but it points his attention at the exact places mine fires, before he's earned it himself.
where I'd be careful is the same place I'm careful with the AI: a signal that's good enough can quietly replace the judgment instead of training it. if the PR comes back green on PRI and he reads that as "safe," we've just built a more sophisticated version of "tests pass, ship it." the whole point of the flinch is that it keeps looking after every signal clears.
so I'd want PRI as a reason to look harder at a diff, never as a reason to look less. frame it as "history says this neighborhood is dangerous — now you go find how this change breaks," and it's doing exactly what I'm trying to do with him by hand. that's the useful version.
would genuinely like to hear how you're surfacing it in the loop — is it a score on the PR, or does it actually redirect the reviewer's attention to specific lines?
nothing replaces what four years of 2am calls taught your nervous system, and i wouldn't claim a score does. what it can do is hand a small, rough copy of that history to someone who hasn't lived it yet.
to your question at PRI it's a score first, and it shows up in three places.
in the editor, the free VS Code / Cursor plugin shows PRI while you're writing. it's read only, never modifies files, and only needs a sign in, no API key. so the junior sees the score before a PR exists, which is probably the most useful moment for training.
on the PR, the GitHub App reads the changed files and posts a comment with the overall PRI (0–100), plus fragility, governance compliance and code volatility, with the reasoning and evidence behind the verdict. 70 is the ready line. permissions are contents read, PR read/write for the comment, and email read. it never commits or branches, and needs no config file or CI change.
in the agent: there's an MCP server for Claude Code, Claude Desktop, Cursor or any streamable HTTP client, so the agent writing the code can pull the same score. full scans there can take up to 30 minutes. it also runs alongside CodeRabbit over MCP if you already use that for line review.
underneath, PRI rolls up seven sub indices: fragility, drift, governance compliance, runtime signals, code volatility, deployment velocity and escalation. runtime signals and escalation need observability and ticketing data connected, and until then they show "No data" instead of guessing. scores also calibrate to each org over time.
on line level: as far as i know it doesn't mark specific lines yet, i'll check and come back.
your green means safe worry is the right one. the gate is advisory by default, teams decide which policies become blocking, a human can always override, and confidence is capped at 85 so it never claims certainty. a green score without history behind it is a much weaker green.
so i'd frame it the way you did. a red score tells you where to start looking. a green one only means nothing in the available signals flagged it.
this is the most encouraging version of the thing I could've hoped you'd say, and it's because of two design choices that most "add a score" products get wrong.
first — "No data" instead of guessing. that's the whole ballgame for me. the failure mode I'm most afraid of isn't a wrong score, it's a confident score over a blind spot, because that's the exact shape of the bug that cost me the customer: clean, green, sure of itself, wrong. a tool that says "runtime signals: No data" is doing the one thing the model in my post couldn't — admitting where its map runs out. it's leaving the flinch a place to live instead of papering over it. honestly, the "No data" states might be more valuable than the scores, because they're the tool pointing at its own frame edge and saying you're on your own past this line. that's where the seam bugs are.
second — capping confidence at 85 and saying out loud that a green without history behind it is a weaker green. that's you refusing to let the tool be a witness. you built a finder that knows it's a finder. the number of products that would've shipped "92/100, ready to merge" in a reassuring green pill and called it a day... you resisted the thing that makes these tools dangerous, which is that they feel like certification.
the editor-before-the-PR moment is the part I didn't see coming and now think is the real unlock. by the time there's a PR the diff is already writtenached to it — the scar, if it fires, fires late. a red flag while he's typing in the neighborhood is the closest thing I've seen to prefiguring the
flinch: it makes him suspicious of the go standing on it. that's earlier in theloop than I can intervene by hand.
the one thing I'll keep nagging about — and you clearly already feel it — is that advisory-by-default is load-bearing and the pressure will alwaynd walk away. the day a team sets "PRI >70 = auto-merge," you've rebuilt tests-pass-ship-it with a fancier dashboard. the frame you landed on is exactly right: red tells you where to st nothing in the available signals flaggedit — and "available" is doing quiet, honest work in that sentence.
would genuinely like to see the line-level version when it lands. a score tells him which file is a baneighborhood; a pointer to the two linessk — the ack and the persist, not eitherone alone — is the thing that'd actually teach the shape. that's the hard part, and the valuable one. appreciate how carefully you've thought
The ten minutes after "don't ship that" are the part I'd hand the junior, even if the flinch itself can't be handed over. The flinch tells you where to look; proving it is a method, and a method is something he can watch and copy. Your write-path story also already turned into one of the hints you gave him: "what happens if this gets called twice" is a scar packed into a question, and the question works for someone who doesn't have the scar yet. Did the test you wrote to prove it end up in the suite?
You caught the thing I underweighted, and you're right. I wrote the whole post around the part that can't be handed over and skipped past the part that can. The flinch tells you where to look — that's the unteachable half. But the ten minutes after, the actually-proving-it, is a method, and he can watch a method and copy it. More than that: once I've said "don't ship that," the suspicion is already free. He doesn't need to have grown the neck to run the proof — he just needs someone to point. So the division of labor is cleaner than I made it sound: I supply the flinch, he practices the method, and the method is his to keep.
And "what happens if it's called twice" — yeah, that's the move I didn't notice I was making. That's a scar compressed into a question, and the question survives the handoff even though the scar doesn't. A library of those is the closest thing to a transferable flinch that exists. The one caution I'd put on it, because I've watched it happen: a stack of scar-questions calcifies into a checklist, and a checklist does the exact thing the flinch is supposed to defend against — it makes him feel safe the moment the list passes. The questions are training wheels for the neck, not a substitute. The day the bug is shaped like nothing I packed into a question, he's back to needing the thing I can't give him. Which is fine — that's just the next scar, and now he has the method to prove it when it comes.
On your actual question: yes, it went in the suite, and that turned out to be the quiet lesson. A scar written down as a regression test is the flinch given a permanent seat — it fires forever without anyone having to remember the 2am call. That's the same "institutionalize the skeptic" move as everything else I do, just at the smallest scale. But here's the limit that keeps it honest: the test protects us against that bug for good, and does exactly nothing for the one neither of us has met yet. The suite is a graveyard of past flinches. The neck is for the graves we haven't dug. So — the test is in there, and the junior's the one who wrote it, which was the point.
"The suite is a graveyard of past flinches" is the cleanest statement of the limit I've read, and having the junior write that test is the part I'd copy. On the scar-questions hardening into a checklist, one guard that might help: keep each question attached to the incident that produced it rather than as a bare list. "What if it's called twice" sitting next to the bug that taught it stays something he can reason from; on its own it's a box to tick.
That guard is better than anything I put in the post, and I think I know why it works. A bare question — "what if it's called twice?" — only carries the conclusion. The incident next to it carries the shape: the retry that landed wrong, the green logs, the 2am call. And shape is what lets him reason sideways to a bug that isn't literally "called twice" but rhymes with it. Strip the incident and you've thrown away the one part that generalizes, kept the one part that doesn't, and called it a checklist.
It also fixes the calcifying problem almost by accident. A box to tick invites "passed, move on." A question with a scar stapled to it invites "wait, is this situation that situation?" — which is the exact hesitation the flinch is made of. You're not handing him the neck, but you're making him do the motion the neck does, every time he reads one. That's the closest thing to growing it on purpose I've heard.
The way I'd say it now: don't write a list of questions, write a list of tombstones. Each one names the bug that's buried under it. He reads the epitaph, not the rule — and an epitaph makes you ask how someone died, which is the question that keeps you alive. A rule just tells you to wear a seatbelt.
Going to steal this for how I run the next one. Genuinely good thread — thanks for pushing on it.
Which production responsibility would you leave with the junior so a bad decision still has a visible owner?
good question, and it's the one that actually keeps me honest — because it's easy to say "human on the merge button" and quietly mean "senior on the merge button." if the junior never owns anything that can hurt, he never grows the neck. he just watches me have one.
so the thing I leave with him is the merge itself, on his own surface area, with his name on it. not "assist the senior" — own the call. he's the one who clicks it, he's the one in the channel when the canary goes sideways, he's the one who writes the "here's what I missed" after. the author (AI) wrote the code, the skeptic (also him, mostly) tried to break it, but the decision to ship is his and it's attributable to him.
what makes that survivable instead of reckless is the blast radius, not the supervision. I don't shrink his ownership, I shrink the crater. flag it, canary it, one internal cohort — so when he's wrong, and he will be, the owner is clearly him and the cost is clearly a rollback instead of a customer. that's the whole trick: real ownership, fake stakes, for as long as it takes the stakes to stop being fake on their own.
the moment I can't afford to let him own a call is exactly the moment he most needs to have owned twenty smaller ones already. if the first thing he owns is the scary thing, I waited too long.
"We automated the forge" is haunting and true. Making juniors finish "this loses money when ___" is brilliant. Cheap failures on purpose might be the new apprenticeship.
Thanks, Hussein. "Cheap failures on purpose" might really be the shape of it — the old apprenticeship was just expensive failures you survived, and we accidentally automated those away before anyone decided they were optional. The open question I'm sitting with is whether a manufactured 2am — a failure you engineer in daylight, on purpose — can build the same instinct the real one did. I don't know yet. But it's cheaper to find out than the alternative.
solid write-up on ai, thanks for sharing
nice ai breakdown
bookmarking this for the ai bits
solid write-up on ai, thanks for sharing
solid write-up on ai, thanks for sharing
interesting approach