"The LLM does not carry responsibility — you do."
I asked Claude to fix one bug. It did. Then it "helpfully" renamed a function in an unrelated file, reorganized imports in two others, and added type hints to a config module that had nothing to do with the feature. The PR went from 40 lines to 400.
When I posted this observation on LinkedIn, the response surprised me — roughly 60,000 impressions and 51 comments worth of lived experience: engineers using prompt-level constraints to bound what Claude touches, teams adding scope rules to their CLAUDE.md files, and one senior engineer pointing out that the bigger problem is what scope creep does to your git audit trail.
This is not an isolated complaint. It is a systemic pattern showing up in teams that have started using Claude Code, Cursor, Copilot, and the rest of the agentic family.
The Boy Scout Rule, Broken
A good principle that stopped self-throttling
Robert C. Martin codified a principle in Clean Code that has shaped how senior engineers think for over a decade: always leave the code cleaner than you found it. Drive-by improvements. Small refactors. Better names while you are in the file. The cumulative effect over months keeps codebases alive.
The principle worked because it was bounded by human attention. A senior engineer fixing a bug might rename one function on the way out. They would not rename twelve, because they did not have time to. The boy scout rule self-throttled.
AI does not self-throttle. When you ask Claude to fix a bug, it is in the file. So is the unused import. So is the inconsistent variable name. So is the function that could be a one-liner. None of those took attention. All of them got "improved."
The output is a pull request that is technically a strict improvement on every line touched. It is also, for review purposes, almost useless.
What Scope Creep Actually Costs
The review surface is the obvious cost. Git history is the real one.
The exploding review surface is the cost everyone notices first. Reviewers are signing off on changes they never asked for, in files they did not expect to see, with diffs that do not match the PR description. That is annoying.
The deeper cost is what it does to your git history. When commits scatter unrelated improvements across files, the audit trail breaks. `git blame` is no longer telling you why a line of code exists — it is telling you the line was changed in a commit titled "fix authentication timeout," even though the line lives in a config module with nothing to do with authentication.
Six months later, the commit history will lie
The honest answer is "an AI changed it while doing something else." The recorded answer points to an unrelated feature ticket. Multiply that across hundreds of AI-touched commits and your git history stops being a system of record. That is the real cost — not the review surface, but the institutional memory of the codebase.
What Is Actually Working
Five layers — none of them enough on their own
Explicit prompt constraints
Tell the model what not to touch. The phrasing that came up repeatedly in the comments: "only touch what I specify, flag everything else as suggestions." Negative constraints work when they are clear.
Project-level CLAUDE.md rules
One line, added to every project: "If you notice other code worth refactoring, flag it in a comment. Do not change it in this PR." That single rule cut scope creep noticeably across my projects.
Deterministic guardrails for the mechanical stuff
Formatting, lint rules, import ordering belong in pre-commit hooks, not in prompts. A hook runs unconditionally. An instruction in CLAUDE.md may get quietly skipped once the context window fills up.
Reviewer discipline
The first review question used to be "does this work?" In the AI-assisted era it becomes "is any of this outside the scope of this ticket?" Scope first, correctness second — the model is good enough now to confidently ship correct code that does not belong in this PR.
Separating functional from non-functional changes
If the model generates a useful refactor alongside a bug fix, split them. One PR fixes behavior, one improves structure. Each can be reviewed and tested on its own merits, and each commit tells one story to git blame six months later.
But the Responsibility Has Not Moved
The bar went up, not down
One pushback in the comments deserves direct engagement. A senior engineer wrote, paraphrased: the model does not carry responsibility. You do. He is right — and it is exactly why scope discipline matters more, not less, when you are using AI.
Pre-AI, the bar for engineering judgment was "do you understand what you wrote?" Post-AI, the bar is higher: "do you understand what you accepted?" That second bar is harder. It requires you to read code you did not write, evaluate it against requirements you did set, and reject changes you did not ask for.
Most teams I have spoken to have not caught up to this bar. They are accepting AI output the way they used to accept their own first drafts — assuming the intent matches because the syntax compiles. That assumption was reasonable when you wrote it yourself. It is not reasonable for output from a system that does not share your intent.
AI did not lower the bar on engineering judgment. It raised it. And the failure mode shows up in scope creep first, because scope creep is the most visible signal that the human in the loop did not actually read what they merged.
What to Do This Week
Five changes you can make before your next PR
Change the instructions
- ✓Add one rule to your CLAUDE.md or project prompt: flag refactoring opportunities in a comment, do not change them in this PR
- ✓Move formatting, lint and import order out of prompts and into pre-commit hooks — hooks run, instructions get skimmed
Change the review
- ✓Make "is any of this outside scope?" the first question, ahead of "does this work?"
- ✓Split functional and non-functional changes into separate PRs whenever the model proposes both at once
- ✓Treat every accepted AI commit as a thing you wrote — if you would not own that refactor as your own change, do not merge it
Conclusion
"The boy scout rule was bounded by human attention. Drive-by refactoring at machine scale is not the problem that rule was written to solve."
Scope creep is not just a review problem. It is a git history problem. When commits do not match their stated intent, the codebase loses its institutional memory.
The fix is layered: prompt constraints, project rules, deterministic hooks, reviewer discipline, and PR splitting. None of these alone is enough. Together they work.
This piece grew out of a LinkedIn post and the discussion that followed. The framework above is partly mine and partly drawn from senior engineers who responded with their own field reports.