The Overnight Coding Loop

This recipe builds your first real loop: a system that picks up a queued coding task, lets an agent implement and test it, and leaves a pull request for you to review — while you sleep. It's the canonical loop-engineering example because the work is repetitive, the result is verifiable (tests pass or they don't), and the risky step (merging) stays with you.

info

This content was developed with AI assistance and is regularly reviewed for accuracy.

What You'll Accomplish

• Queue work the agent can pick up on its own
• Run an agent through implement → test → commit on each task
• Verify automatically so the loop knows good from broken
• Bound the loop with budget and failure stop conditions
• Keep the merge as a human checkpoint in the morning

Prerequisites

• A coding agent that can run commands and edit files — e.g. Claude Code (this recipe uses it as the example)
• A git repository with a working test suite and CI
• Comfort with the Anatomy of an Agent Loop and Loop Guardrails & Safety
• 60-90 minutes to set it up and watch the first run

The Recipe

Step 1: Build the task queue

Goal: Give the loop a well-defined list of work it's allowed to do unattended.

Action: Create a queue of small, self-contained tasks. A queue can be as simple as GitHub issues with a specific label (e.g. agent-ready), or a checklist file in the repo. The key is that each task is narrow and has a clear "done."

Good overnight tasks share three traits: small, verifiable, and low-stakes.

✅ Good: "Add input validation to the signup form; cover empty and malformed
         email with tests."
✅ Good: "Increase test coverage of utils/date.ts to 90%."
❌ Bad:  "Redesign the auth system." (too big, hard to verify, high-stakes)

Checkpoint: You have 2-3 labeled tasks that you'd be comfortable handing to a junior developer with no supervision.

Step 2: Write the loop's instructions

Goal: Define exactly what the agent does for each task.

Action: Write a short, explicit set of instructions the loop will give the agent every iteration. Spell out the sequence and the definition of done.

For the next task labeled `agent-ready`:
1. Create a branch named agent/<task-id>.
2. Implement the task described in the issue.
3. Run the full test suite. If anything fails, fix it and re-run.
4. Run the linter and type checker; fix what they flag.
5. Commit with a clear message and open a pull request. Do NOT merge.
6. Write a one-paragraph summary of what you changed and why.

The "Do NOT merge" line matters — it's the human checkpoint, in writing.

Checkpoint: Your instructions name the branch, the work, the checks, and where to stop (a PR, not a merge).

Step 3: Add the evaluation step

Goal: Make sure the loop can tell success from failure on its own.

Action: The loop should only treat a task as "done" when checks pass outside the agent — your real CI, not the agent's say-so. Configure the loop so a task counts as complete only when the tests, linter, and type checker are green in CI on the PR branch.

This is the difference between a loop that helps and one that confidently ships broken code. Never let the agent be the only judge of whether its own tests passed.

Checkpoint: A task is marked complete only when CI is green on its branch — verified by the system, not the agent.

Step 4: Set the stop conditions

Goal: Guarantee the loop ends — on success, on cost, or on repeated failure.

Action: Write the stop conditions before you run anything. For a first loop, keep them tight:

Condition	Example
Success	The agent-ready queue is empty
Budget	Stop after 3 tasks or $5 of usage, whichever comes first
Failure	If a task fails its checks twice, stop and leave it for a human
Escalation	If the agent edits anything outside the task's scope, pause for review

Checkpoint: Every way the loop could run forever now has a brake.

Step 5: Watch it run once, attended

Goal: See the full loop behave before you trust it overnight.

Action: Start the loop while you're watching, with the budget set low. Confirm it picks the right task, branches correctly, runs the checks, opens a PR, and stops at the merge. Read its summary and the diff.

If it does something you didn't expect — touches extra files, marks a flaky test as passing, loops on one task — fix the instructions or the guardrails before letting it run alone.

Checkpoint: You've watched one complete iteration end to end and the PR looks like something you'd accept.

Step 6: Let it run, then review in the morning

Goal: Run the loop unattended and make the merge your morning ritual.

Action: Schedule or trigger the loop. In the morning you'll have one or more PRs, each with passing CI and a summary. Review them like any pull request — the loop did the work, but you decide what ships.

Over time, as you trust it, you can widen the budget, add task types, or auto-merge the lowest-risk changes. Earn that autonomy; don't start with it.

Checkpoint: The loop ran on its own, stopped at its limits, and left reviewable PRs.

Common Pitfalls

• Tasks that are too big. "Overnight" doesn't mean "all night on one giant task." Small, verifiable tasks succeed; vague epics don't.
• Letting the agent grade itself. If the agent reports "tests pass," verify in real CI. Agents sometimes claim checks they never ran.
• No budget cap. A retry-on-failure loop with no cap is how a small bug becomes a large bill.
• Auto-merging on day one. Keep the merge human until the loop has earned trust over many runs.
• No scope guard. Without a check, an agent can wander into unrelated files. Pause the loop if it edits outside the task.

Key Takeaways

• The overnight coding loop works because the tasks are small, the results are verifiable, and merging stays human.
• Queue narrow tasks; instruct implement → test → PR (never merge).
• Verify success in real CI, outside the agent.
• Set success, budget, failure, and escalation stop conditions before the first run.
• Watch one attended run before trusting it unattended, and widen autonomy only as trust grows.

Next Steps

Try The Research & Monitoring Loop for a non-coding loop, or revisit Loop Guardrails & Safety to harden this one before you scale it up.