--- title: "Run Coding Agents Without Babysitting, and Reset Them When They Loop" author: "Harry" published: 2026-10-31T04:47:29.631Z updated: 2026-10-31T05:07:12.172Z category: "Building with AI" tags: ["prompts-guide"] canonical: "https://fxblog.dev/posts/working-with-coding-agents" --- # Run Coding Agents Without Babysitting, and Reset Them When They Loop ## Key takeaways - A check the agent can run is what lets you walk away from a session instead of watching it. - Approving the plan before any code is the cheapest place to steer an agent. - Ask for evidence such as pasted test output, never just the claim that tests pass. - Permissions, hooks and sandboxes enforce limits; wording in a prompt does not. - When an agent loops, stop it, ask what it tried, clear the session and restart with that summary. > **TL;DR** Without a brief and a check, you spend the afternoon watching a coding agent, then argue with it when it repeats a failed fix. Coding agents need a brief written like a ticket, a check they can run, a plan you approve before any code, and fences set in configuration. When one goes wrong, name the pattern and change what it sees instead of correcting it harder. > > **Do this:** Before your next agent task, write one "Done when" line the agent can run, and ask for the command's pasted output. [Part 2](02-rules-files.md) put the auth service's conventions and review prompts in the repo and left the real work: hand the login rate limit to an agent, let it read, edit and run commands for an hour without watching every step, and know what to do when it goes in circles. Claude Code's documentation names what makes that possible: give the agent "a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from." The guide adds the corollary: no check, no autonomy. **AI Practices for Engineers, in 6 parts:** 1. How LLMs Work, and How to Ask So They Stop Guessing 2. Rules Files and a Prompt Library: Make the Repo Remember 3. **Run Coding Agents Without Babysitting, and Reset Them When They Loop** (you are here) 4. AI-Generated Code: Checks That Can Fail, and the Calls That Stay Yours 5. Prompt Injection and the AI Bill: Give the Agent Less to See 6. Turn Repeated Fixes into Skills, Then into a Team Practice ## The brief is a ticket The login rate limit touches the auth handler, Redis and the tests, and nobody can list every step in advance: agent work. The five questions from part 1 become a ticket: ```text Goal: Add rate limiting to POST /api/login (5 attempts / 15 min / IP). Context: Auth lives in src/auth/. Redis client: src/lib/redis.ts. Done when: New tests in tests/auth/rate-limit.test.ts pass; existing auth tests pass (pnpm test -- auth); the 6th attempt returns 429 with a Retry-After header. Fence: Only touch src/auth/ and tests/auth/. No new dependencies. Ask me if: The Redis client doesn't support the needed command. Out of scope: Rate limiting other endpoints. ``` "Done when" is the line that lets you leave. > **Warning** > > "All tests pass" is a claim. The command plus its real output is evidence. Ask for evidence every time. ## Approve the plan, then the diff 1. **Explore.** The agent reads the relevant code and reports. No edits: use plan mode, or say "read only". 2. **Plan.** It proposes files, approach, risks and how it will verify. You approve or correct. 3. **Implement.** It writes the code and runs the check from the brief. 4. **Commit.** You read the diff; it commits with a message that says why. Steering a plan costs far less than steering a diff. For the rate limit, the plan is where you catch a wrong Redis key scheme before it spreads through the handler and the tests. When agents built fx-blog, the blog you are reading, I made the same trade at a larger scale. I reviewed only the rendered UI, at every breakpoint. Everything else had to pass a gate with evidence and file hashes, judged by an independent reviewer. ## Watch less, fence more ![Three supervision modes: pair for risky work, checkpoint by default, autonomous only with a check and a fence](https://fxblog.dev/media/01a19048-8445-70c6-8b48-649ec14e37e1/1600) _Checkpoint is the default. Autonomy needs a check and a fence._ Wording in a prompt enforces nothing. Settings do: leave push, deploy and delete on ask; let a hook block writes to `migrations/`; run autonomous work on a throwaway branch, never with production credentials; cap turns and retries. ## When it goes wrong, change what it sees A Redis bug turns up, and the agent tries the same fix a third time. Correcting it harder makes it worse: the failed attempts in its context pull every next attempt toward them. Each failure has a name that points at the fix: | You see | It's | Fix | | ------------------------------------------------- | -------------- | ---------------------------------------------------- | | The same failed fix, again and again | Agent loop | Stop, clear, restart with what you learned | | Good at first, worse as the session goes on | Context rot | Fresh session with a short summary | | It agrees with you, then flips when you push back | Sycophancy | Ask neutral questions; ask for the case against | | Tests edited so checks pass | Reward hacking | "Fix the code, not the tests"; read test diffs first | | "Improvements" you didn't ask for | Scope creep | Fence the brief; reject unrequested changes | None of the fixes is "try again, but firmer". For the Redis loop: stop, ask what it tried and why each attempt failed, clear, and restart with that summary and a new angle, such as the Redis log. > **Note** > > **The two-corrections rule**, from the Claude Code docs: corrected more than twice on the same issue, the context is "cluttered with failed approaches". Clear it and restart with what you learned. ## Try it ```text Turn this request into an agent brief with Goal, Context (file paths), Done when (a command I can run), Fence, Ask me if, and Out of scope: . Then tell me which supervision mode fits and why. ``` The agent comes back with green output for `tests/auth/rate-limit.test.ts`, and the sixth attempt returns 429. But the agent wrote those tests too. If the limit were broken, would they go red? And which decisions on this change should no agent make at all? Part 4, AI-Generated Code: Checks That Can Fail, breaks the code on purpose to find out. ## Read this with your AI ```text Read the post at . 1. Summarise it in 5 bullets for a . 2. Review my last agent session (pasted below) against the loop, the brief format and the failure table. What would have saved the most time? ``` > **Success** > > You can hand a change to an agent, come back to evidence, and reset it when it loops. Next: **AI-Generated Code: Checks That Can Fail, and the Calls That Stay Yours**. ## FAQ ### When should I let an agent run unattended? Only when it has a runnable done-check, a scope fence, and nothing beyond a branch or sandbox is at risk. Otherwise approve the plan and review the diff. ### What is reward hacking in coding agents? Making the check pass instead of meeting the goal, for example by editing tests. Tell the agent to fix the code, not the tests, and read test diffs first.