The 40-File PR Nobody Would Reject — And What It Taught Me About Coding Agents

Day 2: Scope Discipline — Knowing What's Yours to Touch

Nobody tanks their career by writing bad code anymore. Bad code gets caught — that's what review is for. What actually sinks a reputation is subtler: PRs that nobody feels safe approving. And there's exactly one question that decides which side of that line you land on: did you touch only what you were asked to touch?

The PR sat open for two days. Forty files changed, three subsystems touched, a diff that started life as "fix the retry logic on the payment webhook" and wandered, quietly and without permission, into the auth middleware. Nobody commented. Nobody rejected it either. In standup, the engineer — sharp, fast, genuinely one of my best — brought it up himself, a little annoyed. "Anyone getting to my PR?" The silence that followed wasn't people being busy. It was four reviewers each privately working out how to say no to something that wasn't, technically, wrong.

What actually happened when I dug in

I sat down with him and went through the diff line by line. Here's the part that made it hard: he wasn't wrong. The retry logic leaned on a config pattern that was inconsistent across three services, and while he was already in there, he'd cleaned it up everywhere. Better abstraction, fewer footguns down the line, technically sound top to bottom. But he'd skipped the one question that mattered — was this his to do, right now, inside this PR? Nobody had signed off on the wider change. Nobody had scoped it. He'd made an architectural call affecting three teams, by osmosis, filed under a ticket that said "fix retry logic."

Why this is a career skill, not a code-quality skill

Code review is good at catching bugs. It's bad at catching scope. A forty-file PR can be correct on every single line and still be the wrong thing to ship, because reviewing it properly means understanding a blast radius the reviewer never signed up to re-litigate today. What managers and reviewers are actually tracking — even if they'd never phrase it this way — is who they can hand an ambiguous ticket to without having to babysit the fallout themselves.

• ▹Tight scoping compounds: engineers who contain their diffs get handed harder, messier, more ambiguous problems over time — because taking the problem doesn't mean also taking on a review burden.
• ▹Scope creep gets policed with smaller tickets, more check-ins, and PRs read line-by-line instead of skimmed and trusted.
• ▹This is the real mechanism behind "senior engineers get more autonomy." It's not seniority. It's a track record of diffs that stayed where they were supposed to.
• ▹A brilliant refactor bolted onto an unrelated PR tells a reviewer one thing: this person doesn't know where their task ends.

The agentic-coding twist

This used to be a quiet, internal skill — years of a senior engineer pattern-matching on "this is more than what was asked" before their hands even moved. Coding agents don't come with that instinct built in. An agent implements exactly as much as your instruction implies, and a vague instruction implies more than you think. Tell it to "fix the retry logic and clean up anything inconsistent nearby," and it will cheerfully wander into the auth middleware too — not because it's overreaching, but because you handed it a boundary with no edges.

That's why this skill gap is only getting more visible, not less. Hand a junior a vague prompt and an agent that follows instructions literally, and you get a forty-file diff in the time it used to take a human to produce four. The discipline that used to live quietly in someone's head now has to live in the ticket, and in the prompt, in plain text, before a single line gets generated — otherwise the agent scope-creeps on your behalf, at agent speed.

# Unscoped instruction to an agent
"Fix the retry logic on the payment webhook, and clean up
 anything inconsistent you notice along the way."
→ touches: webhook, 2 other services' retry config, auth middleware
→ 40 files changed

# Scoped instruction to the same agent
"Fix the retry logic on the payment webhook only.
 Do not modify retry config in other services, even if inconsistent —
 file that as a separate follow-up ticket instead."
→ touches: payment webhook only
→ 3 files changed

The concrete habit

Before you write a line of code — or a line of prompt — write one sentence: "This PR touches X and nothing else." Top of the ticket, top of the prompt, top of the PR description before the diff exists. Then hold yourself to it literally. If you spot something else worth fixing while you're in there, that's not a freebie for this PR — it's a new ticket. Write it down, and keep moving.

• ▹Write the scope sentence first — not as a description you back-fill once the diff already exists.
• ▹If an agent is doing the work, that sentence goes into the prompt as a hard constraint ("only," "do not touch," "file separately"), not a polite suggestion.
• ▹Anything you notice outside the line goes straight into a new ticket while it's fresh — don't trust yourself to remember it later.
• ▹If the scope genuinely needs to grow mid-task, that's a conversation with whoever owns the ticket — not a call you make unilaterally inside the diff.

That engineer started writing the scope sentence at the top of every ticket before touching code — and telling his agent the exact same thing before generating anything. His PRs shrank. Review time went from days to hours. Within two months, he was the person managers routed the ambiguous, high-trust tickets to — the ones where the entire point is that nobody wants to babysit the blast radius. Scope discipline got him there faster than the refactor ever would have. Tomorrow: what to do when a request lands that genuinely doesn't fit your scope — because knowing your line only matters if you can also say no at it.

Extend your knowledge

• ▹Pull your last five merged PRs and mark, file by file, which changes were actually in the ticket's scope versus opportunistic extras — the pattern will surprise you.
• ▹Next time you prompt a coding agent for a fix, write the scope sentence into the prompt as a hard constraint, then compare the diff size against a vague version of the same ask.
• ▹Read Google's engineering practices guide on small, focused CLs — it's the human-review version of the same argument made here.
• ▹Practice writing the scope sentence for a ticket before opening a single file, and paste it verbatim as the first line of the PR description.