A coding agent can fix a bug and still leave you to chase the tests, review comments, and final result. Give it a clear place to stop: a deliverable, a check that can reveal whether the fix worked, and a report of anything it could not verify. Then one request can cover the full job you meant to assign.
In I was using Fable wrong, this is how I fixed it, developer Theo shows coding agents working through bugs, pull requests, and staging checks. He says where he wants the agent to stop. Sometimes that means an open PR. Sometimes it means a PR with checks green. He asks for a merge only when that is the result he wants.
01Name the result
“Fix the preview image” names a problem. It leaves the result open. Say whether you want a local patch, a draft PR, or a PR ready for your review. Give the agent the failing thread, screenshot, or error that lets it find the problem.
Theo’s preview-image request included a thread ID, the failed behavior, and a request for one PR that addressed the causes. When another contributor’s PR appeared, he asked the agent to compare the two approaches and continue with the stronger one. The requested result remained one fix in one PR.
“Every prompt should have a pretty clear place where it stops when it's done.”
Theo - t3gg, “I was using Fable wrong, this is how I fixed it” · 27:0502Choose a check that can catch it
Name the evidence that would show the problem is fixed. Anthropic’s Claude Code guidance recommends giving the agent a check it can run and asking it to show the result. A passing build checks that the project builds. It cannot prove that a preview image renders or that a query returns the right rows.
Theo’s staging example makes the gap concrete. The agent could see crashes, latency, and health signals after a query-engine change. It could not detect wrong query results with those signals alone. A comparison against known results was needed before treating staging as a meaningful check.
| Result you want | Check the agent can show |
|---|---|
| Preview image renders | Reproduce the failing thread, then show the image in the same view after the fix |
| Query results stay correct | Compare known queries against expected results or the old engine |
| PR is ready for review | Show test output, CI status, and the state of new review findings |
If the agent lacks access to a browser, test data, or CI, ask it to name the missing check. A confident summary cannot replace the evidence.
03Let the agent choose a route
A long task may uncover two plausible fixes, a failing test, or a review comment. Tell the agent which choices it can make and when it should return to you. Anthropic’s Fable 5.1 prompting guidance recommends completing reversible work already covered by the request and reporting any part that remains blocked.
This original prompt sets the job and its stopping point:
Investigate why the preview image fails in the attached thread. Use its ID, screenshot, and tool results to find the cause. Fix the issue in this repository and open one draft PR.
Reproduce the failure before editing. Run the relevant tests and check the preview in a browser after the fix. If two fixes are plausible, choose the smaller one that passes those checks and explain the choice. Monitor the PR until CI finishes and address review findings that you can confirm from the code. Keep unrelated fixes out of this PR.
Stop with the draft PR ready for my review. Show the failed and working behavior, the test and CI results, and any check you could not run. Ask me before merging, deploying, or changing production settings.
The prompt ends at a draft PR and reserves merging for you. Delegate to your agent in stages covers when to grant broader access. Guardrails for hours-long agent runs covers checks and fresh review when the run lasts much longer.
04Review the evidence
When the agent stops, compare its report with the check output. CI can pass while the original bug still occurs. If the check does not cover that behavior, the work remains unverified.
Keep unrelated fixes separate. Theo’s PR-monitoring skill tells the agent to verify review comments before changing code and to leave unrelated fixes for later. Trim the instructions your model outgrew helps keep lasting project rules separate from task-specific instructions like this stop point.