Run Coding Agents Without Babysitting, and Reset Them When They Loop

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 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:

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.

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

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:

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.

Try it

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:
<describe the change>. 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

Read the post at <this post's URL or .md link>.
1. Summarise it in 5 bullets for a <your role>.
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?
<paste>