Dan Luu on Agentic Coding: Keep the Loop Bounded
A coding-agent repair loop is easier to review when the task, retry limit and acceptance test are explicit before edits begin. The exercise below turns that idea into one small debugging trial; it is our proposed method, not a benchmark or a claim that Dan Luu prescribes these exact steps.
Dan Luu's notes on agentic coding discuss testing, workflow differences and ways of directing agent work. His appendix also explains the agentic process around writing the post. Read the original for his observations. Our earlier variants over-compressed that discussion into a single claim about unbounded loops and included an irrelevant geography digression; neither is needed to teach this exercise.
What should the agent repair?
Choose a small failure whose expected behavior you can explain independently of the agent. For example, a date parser accepts an invalid day or a React hook test does not advance its fake timer correctly. Use synthetic data and a clean branch. Avoid a migration or authorization redesign for the first trial because uncertainty about product behavior would obscure the result.
Run the focused test before editing and save its failure. Read the implementation and test together. If the test itself is wrong, record why its expectation conflicts with the intended behavior before changing it. A green run obtained by weakening an assertion is not evidence of a repair.
How do you limit the loop?
Give the agent a short task note that names the files it may edit, the expected behavior and the command that checks it. Allow one revision after a failed check, then require a diagnosis if the same failure persists. That retry limit is a choice for this learning exercise, not a universal rule for all development work.
Task: repair the named failure without changing the public contract.
Before editing: state the failing behavior and the smallest relevant file set.
Verification: run the agreed focused test before and after the patch.
Retry budget: one revision after a failed check.
Stop if: scope must expand, behavior is unclear, or the same failure persists.
Handoff: changed files, exact commands, results and unresolved assumptions.
Keep durable test commands and architecture constraints in the repository instructions your agent reads. Put this task's retry budget in the task prompt. For Cursor, a scoped .mdc rule can remind the agent of the review requirements. Codex users can keep durable expectations in AGENTS.md. Neither file is an access-control mechanism.
Configure actual execution permissions separately. If the task needs external issue context, expose only the required read operation. A debugging prompt does not justify granting database writes or publishing access.
What makes the result acceptable?
Review the diff before reading the agent's explanation. Check that the patch repairs the demonstrated failure and does not broaden the API, delete relevant assertions or introduce unrelated refactoring. Re-run the test outside the agent session. If the implementation changed, check that the new regression test would catch the original behavior.
Use this small rubric to compare the run with its starting contract:
| Check | Acceptable evidence | Reason to reject or investigate |
|---|---|---|
| Scope | Every changed file is needed for the named repair | Unexplained edits outside the agreed area |
| Behavior | The failure is reproduced and the intended result is explicit | The agent redefines success after editing |
| Verification | The exact command and outcome are recorded | A summary says tests passed without evidence |
| Retry limit | The agent stops or diagnoses at the agreed limit | Repeated edits hide the same unresolved failure |
| Handoff | A reviewer can assess the patch from the diff and receipt | Acceptance depends on trusting a long chat |
What should you keep after the trial?
Save the starting failure, final diff, verification command and the reason for each revision. Record one boundary the agent respected or missed. If the exercise exposed a durable repository convention, add that small rule near the affected code; do not copy the whole conversation into permanent instructions.
A successful trial establishes that one task was reviewable under these conditions. It does not prove that the same retry budget or permission setup will work for an architectural change. For a larger task, first define smaller checkpoints and the evidence needed at each one.
Updated 21 September 2026: Consolidated the Codex variant and separated our bounded-loop exercise from claims about Dan Luu’s observations.
Where does your team stand?
Each team member completes the proficiency matrix individually. You receive a PDF with the team baseline and a recommended next step.
Assess your team