Stop a coding agent when the work crosses an agreed boundary, depends on an unresolved decision, or can no longer be reviewed against the original goal. Pause further changes, inspect the current patch, and decide what can be preserved. Restart only after tightening the assignment and defining an early checkpoint.
Set those conditions before work begins. A visible changed-files boundary and a named person responsible for the stop decision make intervention easier. Elapsed time, a confident progress message, and passing tests leave scope and approval questions unresolved.
Define a boundary that can trigger a pause
List the expected source files, tests, and any permitted fixtures. Identify protected modules and the decisions that require additional review. For a narrow bug fix, the initial budget might allow the affected implementation and its focused test, with any additional path triggering a pause.
Use the repository's shape to choose the boundary. A line-count limit can be a useful secondary signal, but a one-line authorization change may carry more risk than a large fixture. Inspect what changed and why.
Make the stop condition operational: review the changed-file list at a checkpoint, or use an automated check that flags paths outside the agreed set. Assign someone to respond when that signal appears.
Recognize drift through the diff
Consider an assignment to fix a null-coupon crash. The expected patch concerns coupon handling and its tests. During review, the changed-file list also includes session handling, user profiles, invoice code, and eighteen snapshots.
That expansion warrants a stop and explanation. Ask which requirement each additional change serves, what evidence makes it necessary, and whether it changes behavior outside the coupon path. A claim that the shared services are cleaner does not resolve those questions.
Passing tests still need interpretation. They may omit the affected behavior, exercise changed expectations, or cover a different path from the reported crash. Preserve the original acceptance criteria while deciding whether the patch addresses them.
Stop further edits and preserve the review state
Pause the agent's editing work and confirm that associated background tasks will not continue modifying the same files. Record the starting revision, current changed files, available evidence, and the reason for stopping. Keep unrelated work belonging to other contributors intact.
Do this before asking for another cleanup pass. Further edits can make it harder to identify which changes introduced the scope expansion or which test originally reproduced the defect.
Write a short decision note: the boundary crossed, the material risk, the work under consideration for salvage, and the owner of the restart. Keep the explanation tied to inspectable changes.
Salvage only what stands independently
Review potential salvage in small pieces. A useful failing-test reproduction can be retained when it expresses the intended contract and does not depend on the unrelated refactor.
| Part of the attempt | Question before retaining it |
|---|---|
| Reproduction test | Does it expose the original failure on the starting revision for the expected reason? |
| Coupon repair | Can it satisfy the contract without the shared-service changes? |
| Session or invoice edits | Is there a separately authorized requirement and review plan? |
| Snapshot updates | Which intended behavior justifies each changed expectation? |
Keep a clean reproduction separate from the eventual fix so its purpose remains visible. Discard unrelated refactors from the repair attempt. A genuinely useful improvement can become a separately scoped proposal with its own justification.
If the reproduction relies on a rewritten helper or altered fixtures that obscure the original behavior, rebuild it against a clean starting point before using it to judge the next repair.
Restart with a narrower brief
The second assignment should address the reason the first attempt drifted. State the null-input behavior, preserved valid-coupon behavior, editable paths, prohibited changes, required checks, and the condition that sends the task back to its owner.
Ask for a summary before editing and set the first checkpoint at an inspectable artifact: a reproduction proposal, a diagnosis tied to the relevant branch, or a minimal patch. Review the changed-files list at that checkpoint.
If another module truly must change, resolve that dependency explicitly. Expand the scope with an owner and compatibility checks, or split the work. Repeating the same broad assignment leaves the next attempt exposed to the same uncertainty.
Match supervision to the consequences
Choose which work may continue in the background and which needs close steering. Dependency inventory and bounded flaky-test reproduction can be background tasks when their permitted actions and return artifacts are clear.
A duplicate-charge report requires closer supervision while its cause remains uncertain. Set a checkpoint for reviewing the diagnosis and an abort criterion if the explanation cannot be confirmed. Keep investigation permissions limited to the agreed environment and actions.
A speculative rewrite needs a measurable problem before implementation starts. Record it as blocked until someone defines the outcome, scope, and evidence required. A clear queue classification prevents an unscoped redesign from proceeding as routine maintenance.
Close the stopped attempt with an accountable handoff
Explain what was retained, what was discarded, and why. Name the remaining uncertainty and the next decision-maker. Distinguish proposed checks from results available for review, and carry any missing integration proof into the restarted task.
The engineer who called the stop should own that account and the new scope boundary. Before accepting the replacement patch, compare its files and behavior with the revised brief and review its evidence against the original failure.
If the work will be released, assign the release decision, stop conditions, and recovery steps to an owner. A successful restart ends with a patch whose purpose, proof, and remaining risk are clear enough for someone to make that decision.
The Agentic Developer Interview includes cards on stopping scope drift, preserving clean reproductions, restarting with a changed-files budget, and choosing supervision levels and abort criteria for delegated work.