An AI Review Bot Almost Made Me Redesign the Wrong System

Day 9: The Feedback You Get Is Usually Wrong — Learn to Translate It

Someone hands you a piece of feedback and it's actually two things stapled together: something real they felt, and a theory about what caused it. Act on the sentence as written and you'll fix the wrong problem — carefully, confidently, and completely.

The PR process that wasn't broken

A report told me flatly: "the PR process is broken — it's slowing us down." I took it at face value. Spent the weekend redesigning our review pipeline — fewer required approvals, looser CI gates, a plan to cut merge time in half. Before I shipped any of it, I asked one question: slow how, exactly? Turned out the process wasn't the problem. We'd just switched on an AI review bot that auto-commented on every PR before a human ever looked at it — nitpicks, style flags, the usual noise. My report didn't feel slowed down. They felt watched. They didn't have a clean way to say "I feel surveilled by a bot leaving comments on my code before a colleague even sees it," so what came out was "the process is broken." I almost rebuilt the wrong system.

The trap: 'be open to feedback' isn't the skill

Every career guide tells you to be open to feedback. Fine — but openness isn't the bottleneck for most people past mid-level. They already show up to 1:1s and ask for it. The real bottleneck: being maximally open to a wrong diagnosis just means you fix the wrong thing faster, and with more conviction. Openness without translation is a force multiplier on other people's misdiagnoses, not a filter for them.

Two more: same pattern, different rooms

• ▹From a report: 'Sprint planning is a waste of time, we should cut it.' Diagnosis: the ceremony itself is worthless. What I found once I dug in: their estimates kept getting silently overridden by the AI-assisted velocity forecast the PM trusted more than the team's own numbers. They weren't unheard about planning — they were unheard, period. Planning just happened to be where it surfaced.
• ▹From a code review comment: 'This abstraction is unnecessary, just inline it.' Diagnosis: bad design. What was actually going on: the reviewer had no idea the extension point existed so an agent could safely generate new handlers into it later. From where they sat, the layer added nothing but indirection. The code wasn't wrong — the intent was just invisible to them.

The move: split the sentence before you act on either half

Every piece of feedback is two claims glued together. Pull them apart before you act on either one:

• ▹Symptom — what they actually observed or felt. 'I feel micromanaged.' 'My estimates get overridden.' 'I don't see why this exists.' This part is almost always accurate — it's their direct experience.
• ▹Diagnosis — what they think caused it. 'The process is broken.' 'Planning is a waste of time.' 'This abstraction is unnecessary.' This part is a guess, made with less visibility into the system than you have, and it's the part most likely to be wrong.

Your job is to accept the symptom as data and treat the diagnosis as a hypothesis — one input, not the verdict. You might still end up changing the process. But you decide that after you've found the real symptom, not because the first sentence told you to.

Check the split out loud

You don't need a framework in the room — you need one sentence that tests the symptom without arguing about the diagnosis. Something like: 'So when the bot comments before I do, you feel watched — did I get that part right?' Notice what it isn't doing: it isn't saying 'the process actually isn't broken.' You're not debating their conclusion yet. You're just confirming you extracted the right feeling before you touch the cause. Say yes, and you've isolated the real target. Say 'no, it's more that—' and you just got a better symptom for free, for the price of one clarifying line.

Why this gets sharper as you get more senior

Move up — EM, staff, founder — and feedback volume climbs while its formedness drops. Everyone below you is reporting symptoms from systems they only partially see, and that gap is widening fast on AI-native teams. When agents draft PRs, run migrations, and generate the first pass of review comments, the causal chain from 'something felt off' to 'here's what caused it' gets longer and blurrier for the person feeling it. They notice the friction — slower merges, comments that feel arbitrary, trust eroding — but they can't tell whether the cause is your process, a model's behavior, a bot's tone, or an unrelated teammate's change. They'll hand you their best guess anyway, stated as fact. The senior move isn't to trust the guess or wave it off — it's to extract the felt experience underneath it, every single time, because that part stays true even when the theory doesn't.

Tomorrow flips this around: how to give feedback well. Translation is the receiving half of the skill — tomorrow is the giving half, and the fix turns out to be the same one, run backward: report symptoms, not diagnoses, and let the other person do their own translation.

Extend your knowledge

• ▹Next 1:1: write down the exact feedback sentence you get, then physically underline the felt part and the causal-claim part separately — before you respond.
• ▹Practice the checkback line verbatim in your next code review disagreement — confirm the reviewer's frustration before you debate their proposed fix.
• ▹Marshall Rosenberg's Nonviolent Communication has good language for separating 'what happened' from 'what it means.' Read it as a companion to this split, not a replacement.
• ▹Tomorrow: Day 10 covers giving feedback well — the same symptom/diagnosis split, run in reverse.