Claude Opus 5 makes writing code almost free

I was working on a simple task yesterday—just a quick one-line fix for a date parser that was choking on a specific timezone suffix. I asked the agent to update the format string, and twenty seconds later, it reported the job was done. I opened the diff expecting a single line change. Instead, I found eleven files modified. It had rewritten the parser, renamed a helper function three modules away, tidied up an import block I didn't touch, and even added a caching layer nobody asked for. Sure, every test was green (actually, there were 11 more tests now), but I was staring at four hundred lines of code I had to audit at 6 PM.

This is the new bottleneck in the AI workflow. We've moved from the "difficulty of writing" to the "difficulty of reviewing." Anthropic actually admits this in their documentation; they call this scope blowout "expected behavior." They note that Opus 5 can expand the scope of a task, applying its own judgment to what the task should be rather than what you actually asked for.

If you want to stop these eleven-file surprises from hitting your main branch, you need a defense-in-depth strategy. You can't just rely on a second LLM to "check the work"—that often just results in a loop of two models agreeing with each other's mistakes. Instead, you need three specific layers of control.

Layer 1: Steering (The Scope Constraint)

The most common mistake I see in prompt engineering is people adding instructions like verify your work before finishing to their CLAUDE.md or system prompts. Don't do this. Anthropic is very clear: Opus 5 already verifies its work. Adding explicit verification instructions actually causes "over-verification," which wastes tokens and provides zero benefit because the model is just confirming that it successfully completed the (overly broad) task it set for itself.

Instead of telling it to "check its work," you need to constrain its scope. You have to give it permission to be smart, but strict boundaries on where that smartness can be applied. A better way to steer the agent is to use a prompt structure like this:

Deliver what was asked, at the scope intended. Make routine judgment
calls yourself, and check in only when different readings of the request
would lead to materially different work. If the request seems mistaken or
a better approach exists, stop and ask for clarification.

By focusing on "scope intended" rather than "verify accuracy," you are addressing the root cause of the bloat.

Layer 2: The Human Review

This is where we sit. Since the model is optimized to finish the job, it will always try to be helpful. Your job in the review phase isn't just to check if the code works (the tests do that), but to check if the code belongs. When you see a diff, your first question shouldn't be "Does this pass?" it should be "Why did this touch a file I didn't mention?"

Layer 3: Deterministic Enforcement

If you are running an LLM agent in a CI/CD pipeline or a local development environment, the most robust way to prevent scope creep is to use a hard gate. This means using tools that allow you to restrict the agent's write access to specific directories or file patterns. If you ask for a fix in /src/parsers/, and the agent tries to touch /src/utils/, the environment should physically refuse the write operation.

Implementing these layers—steering the prompt, performing a scope-focused review, and using file-system level enforcement—is the only way to turn these agents from "helpful but chaotic" into reliable members of your engineering team.