Start With One Measurable Target
Your first loop should be small enough that you can tell whether it worked without arguing. Do not start with “make this code better.” Start with “make this test pass,” “reduce this benchmark below 200 ms,” or “fix every lint error in this folder.” A coding agent can read files, edit them, and run commands, but it still needs a finish line. The loop is the pattern that says: try a change, check the result, use the feedback, try again.
Think of the loop in four parts. The trigger is what starts it, usually you typing a goal in the terminal or IDE. Execution is the agent’s work: inspect files, edit code, run commands. Verification is the proof: tests pass, benchmark improves, or a reviewer says the result matches the spec. Output or memory is what the agent records so the next pass does not repeat the same failed idea.
For a first run, choose deterministic verification. Unit tests, type checks, lint checks, and timing benchmarks are better than “does this feel clean?” Subjective review can work later, but it needs a clear rubric. A simple pass/fail check teaches you the shape of agent work faster because every iteration produces evidence.
Give The Agent Tools And Context
Once the target is measurable, make sure the agent has the tools it needs. A tool is any action outside plain text: reading files, editing files, running `npm test`, searching the repo, opening logs, or calling an API. Without tools, you are still chatting. With tools, the agent can compare its guess against the actual codebase.
Context is the information the agent can see while working. That includes your request, the files it opens, command output, test failures, and any notes you provide. Agents have limited working memory, so good loops keep context focused. Point the agent at the relevant folder, the failing command, and the expected behavior. Avoid dumping the whole project story unless it affects the check.
A useful first prompt is: “Run the failing test, inspect the related code, make the smallest fix, rerun the test, and repeat until it passes or you are blocked. After each failed attempt, record what changed and what the error says.” This tells the agent what to do, how to verify, and how to avoid spinning.
Run The Loop Like A Lab Notebook
The loop should not be a blur of edits. After each iteration, the agent needs a short memory trail: command run, result, hypothesis, change made, next check. Markdown is enough. The point is not ceremony; it is to stop the agent from rediscovering the same failure three times and burning tokens on redundant work.
For example, a benchmark loop might follow this rhythm: run `npm run bench`, identify the slowest function, change one implementation detail, rerun the same benchmark, compare numbers, keep the change only if it improves the target. If the runtime gets worse, revert that idea or move on. The verification step controls the loop, not the agent’s confidence.
Expect two common failure modes. First, the agent may optimize for the check while breaking behavior the check does not cover. Add a broader test command before declaring victory. Second, the agent may keep iterating when the goal is underspecified or unreachable. Set a budget: maximum attempts, maximum time, or “stop and explain after three different failed approaches.” A loop is useful because it persists, not because it runs forever.
Add Sub-Agents Only After The Basic Loop Works
Sub-agents are smaller agent workers handed a focused task by the main agent. One might inspect tests, another might review a patch against a spec, and another might search for similar code patterns. They are useful when the work naturally separates, but they add cost and coordination. For your first loop, use one agent unless the task has a clear split.
A reviewer sub-agent is the safest early use. The main agent writes the fix, then a reviewer checks it against a narrow rubric: “Does this satisfy the failing test without changing public behavior?” or “Does this match `spec.md`? Return pass or fail with reasons.” This turns a fuzzy quality judgment into a repeatable gate. It is still less reliable than tests, but it is better than asking for general approval.
MCP, or Model Context Protocol, fits here when the agent needs controlled access to outside systems. An MCP server can expose tools for GitHub, issue trackers, databases, monitoring tools, or documents. You do not need MCP for your first local test loop. Use it when the verification source lives outside the repo, such as checking open production errors, reading pull request comments, or comparing analytics after a change.
Know When To Stop
A good loop stops for one of three reasons: the check passes, the budget is reached, or the agent is blocked and can explain why. That stop condition is the difference between a loop and wandering. If the test passes, ask for a concise summary of the files changed and the command that proved it. If the budget is reached, ask what was tried and what evidence remains.
As you gain confidence, you can move from manual triggers to scheduled or event-based triggers: run a documentation sync every night, check new pull requests for test failures, or scan monitoring tools for unresolved high-priority errors. The structure stays the same. Trigger, execution, verification, memory.
The central habit is simple: never ask an agent merely to improve something when you can ask it to improve something until a check says it is done. Your first verification loop should feel almost boring. That is the point. Boring loops are inspectable, repeatable, and much easier to trust.
Key takeaways
- Start with a small goal that has objective proof, such as a passing test or benchmark threshold.
- A loop has four parts: trigger, execution, verification, and output or memory.
- Give the agent focused context and the exact command that proves success.
- Record each failed attempt so the agent does not repeat the same idea.
- Use sub-agents later for narrow review tasks, not as a substitute for clear tests.
- Stop the loop when the check passes, the budget is reached, or the agent can explain a real blocker.