Matt and Scott both recently shipped PRs and got reviewer feedback that didn't match what they thought the team had agreed on — either asking for far more scope than intended, or pushing back on an incremental approach in favor of the "ideal" final solution.

The classic example: you make one focused change in an old codebase, and a reviewer points to an unrelated eslint-disable comment five lines above your diff and asks you to "fix it properly." Suddenly your tight PR is fighting a battle you didn't sign up for.

Scott frames the core tension: most of the team agrees with incremental PRs in principle, but in practice a reviewer can blindside you by insisting the PR get all the way to the ideal end-state. The skill is selling the increment — showing the path from "value shipped today" to "ideal solution later" so reviewers buy into the staging, not just the destination.

Scott's concrete example: he was building end-to-end smoke tests where the ideal version was blocked by another team. He had to plead his case, point to follow-up tickets, and frame the smoke tests as immediate value on the way to the real thing.

Dillon notes he doesn't hit this much — his team has jelled, they tell each other up front "you're not going to like this, let's talk in person." Scott contrasts that with newer teams or strong-opinioned teammates where trust hasn't been built and standups go in one ear, out the other.

The group converges on communicate, communicate, communicate. Matt argues for creating a clear through-line — an issue or doc that breaks the work into steps so a reviewer landing on PR #3 can click back to the plan. It doesn't have to be a senior-staff-signoff design doc; even a one-pager or a markdown plan from Claude counts. Matt also pitches "shift left" on reviews: get eyes on the plan before the PR, not at PR time.

Dillon introduces the PRD framing — product requirements doc owned by PMs, separate from an engineering design doc. When you don't have a dedicated PM, you have to own that artifact yourself, and teams sometimes forget.

Matt's open question: how do you stop blocking nitpick comments from dominating? Scott's stance is firm — nitpicks should not block PRs. Unless there's a real architectural problem or a literal bug, call it out, approve anyway, and let the author decide whether to address it now or as a follow-up. Code review is a two-way conversation, not a one-way directive, regardless of seniority.

Dillon's tactics: mark nitpicks as out-of-scope with a follow-up ticket, or just take the conversation to Slack/in-person to break through faster than async GitHub threads.

A frustrating wrinkle Matt raises: their SOX-required approval process dismisses approvals on any new push, so even fixing a non-blocking comment forces a re-review cycle — actively discouraging the fast-follow behavior everyone says they want.

The underlying message: assume good intent, trust your fellow engineers, and recognize that increasingly you may be reviewing a Claude-generated PR anyway.