When Not to Use It

The loop of this book has a fixed cost and a condition. The cost is writing the task, reading the diff and running the tests, every time. The condition is that someone must be able to judge the result. Where the cost is larger than the work, or the condition fails, the loop is the wrong tool, however good the agent is.

Chapter 5 made that call for a single change. This page makes it for whole areas of a codebase and for situations a team meets again and again, which is where Cragmoor's month of numbers from the previous topics ends: with a written list of where the agent is the default, and where it is not.

Nobody on the team can judge whether the code is right→Established library and an expert reviewer

The team must trace this code at three in the morning→People write it; the agent reviews

Describing the change takes longer than making it→Make the change by hand

The agent has no way to observe its result→Build tests or a reproduction first

The data the task needs may not leave→Work without the agent, or with synthetic data

You are learning the language, library or domain→The agent as tutor, not author

Code You Cannot Review

If nobody on the team can judge whether a piece of code is correct, generating it moves the risk to the one place nobody checks. Review is the condition of the whole loop, and for this code the condition is simply not available. Cryptography, authentication flows and signature verification are the usual cases, because their mistakes are invisible in normal operation: wrong code and right code both pass the happy-path test.

At Cragmoor the case is the webhook that tells the booking service a payment succeeded. Its signature check uses the payment provider's own library, called exactly as the provider documents, and every change to it is reviewed by the one engineer who has read that library. No generated code goes into it. Chapter 12 showed why: the agent reproduces the patterns of public code, including the ones that skip verification.

Code You Must Understand Deeply

Some code the team must be able to trace at three in the morning: the code you are on call for, and the code that encodes the business. After the month of counting, Cragmoor moved the offer and hold logic in waitlist, the code behind the double offer of Chapter 10, into this category. People write it. The agent reviews it, suggests tests, and explains unfamiliar corners, but it is not the author.

The cost is some speed in one module, and the month's numbers put a size on it: that module was the one place where the agent had made the team slower anyway. The return is a team that understands the code that wakes it up. That is a trade worth making deliberately, in a small number of places, and writing down.

Writing it down happens in three places, because three different readers need it. The team policy of Chapter 13 gets a line naming the module, for people. The project instructions file tells the agent that in this module it proposes tests and review comments and does not edit. And the permission settings deny the agent's edits under that directory, because an instruction is read and a denial is enforced, as Chapter 3 put it.

Problems Smaller Than the Prompt

When a change is faster to type than to describe, the loop's fixed cost is the whole cost. A one-line fix whose location you already know. A rename the editor's own refactoring tools do exactly and instantly, which is how Chapter 11 handled renames. A configuration value. Writing the task, waiting for the diff and reading it takes longer than the change, and adds a step where something can go wrong.

The test is simple and worth applying honestly: if writing the task properly would take longer than making the change, make the change. At Cragmoor a properly written task takes about ten minutes, and reading the resulting diff another two or three. A one-line change to a value whose location you know takes under a minute by hand, and nothing about it gets better for passing through the loop. The smaller the task, the more of its total cost is the overhead of the loop.

When the Loop Cannot Close

The loop closes when the agent can run something and observe the result, as Chapter 3 required. Some work offers nothing to observe. A module with no tests and no quick way to write them. Behaviour that only appears in production, under load or with real traffic. A system the agent cannot run at all from where it sits. An agent without feedback is guessing, fluently and confidently, and its guesses look exactly like answers.

Do the groundwork first. For untested code, pin its behaviour with tests as Chapter 11 did for pricing. For production-only behaviour, build a local reproduction. If neither is possible, the change is made by hand by someone who can observe the system, and the agent's role is to help read the code around it.

When the Data Cannot Go

Sometimes the question is not the tool but the context. The team policy of Chapter 13 says no to code a client owns under a contract that forbids sending it to a provider, to incident work that needs production data, and to anything containing real members' personal data. No setting on the agent changes that, because the problem happens when the data enters the session, before any setting applies.

For incidents this matters most, because pressure pushes people towards pasting what they have. Cragmoor's rule is to work the first hour of an incident without the agent and with real data, then bring the agent in with synthetic data once the shape of the problem is known.

When You Are Learning

The first feature in a new language, library or domain is where the skills of the previous topic are built. Using the agent as an author there gets the feature done and skips the learning, which is the result the January 2026 study measured. Use it as a tutor instead: ask for explanations, ask it to quiz you, ask it to review your version.

This boundary is temporary by design. Once you can judge the code in that library, the ordinary loop applies again, and the agent goes back to being an author whose work you can check.

Cragmoor's list, after the month of counting, is short. The agent is the default for tests, fixtures, small fixes with a known location, mechanical changes and first drafts of features outside waitlist. It is a reviewer, not an author, for the offer and hold logic and for the payment signature check. It is not used at all for the first hour of an incident, for client code under the one contract that forbids it, or for a change faster to type than to describe. The list has a review date, like the rest of the policy, because the month's numbers will move.