# Claude Opus 5 makes writing code almost free > Source: > Published: 2026-08-27 16:02:07+00:00 # Claude Opus 5 makes writing code almost free 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. [Next I think we need to talk about how predictable automated scanning →](/en/threads/7905/) [these AI tool field notes](https://tanyan888.com/), with plenty of directly applicable cases.