The Agent Loop I Trust for Production Code

I do not trust a coding agent because it sounds confident. I trust a workflow when every step leaves evidence a human can inspect.

For production code, the loop matters more than the model's fluency.

The thesis

The agent loop I trust separates understanding, planning, implementation, verification, and review into explicit phases.

This is slower than asking for a giant patch. It is faster than debugging a giant patch whose premise was wrong.

The production pattern

The most useful agent sessions I have seen feel less like autocomplete and more like a disciplined pairing session.

The agent searches quickly, summarizes unfamiliar code, proposes a narrow change, writes a first draft, runs checks, and then explains what remains risky. The human keeps deciding what matters.

The least useful sessions skip straight from vague intent to broad mutation. They produce a diff that takes longer to review than it would have taken to write the change by hand.

The model

My default loop has six steps.

Step one: frame the change. I state the behavior, constraints, and files likely in scope. If I cannot do that, I ask the agent to explore before it edits.

Step two: inspect. The agent reads the relevant code and reports the current behavior, call path, and likely change points. I look for evidence, not eloquence.

Step three: plan. The agent proposes a small plan with tests. I reject plans that mix unrelated cleanup with the target change.

Step four: implement. The agent edits only within scope. If it discovers the scope is wrong, it stops and explains why.

Step five: verify. The agent runs the relevant tests or explains why it cannot. For risky work, I add manual checks, contract tests, or review by another owner.

Step six: summarize. The agent gives a terse account of changed behavior, tests run, and residual risk. That summary becomes part of the review context.

The loop in checklist form:

• Frame: What is the intended behavior?
• Inspect: What does the system do today?
• Plan: What minimal change should satisfy the intent?
• Implement: Did the patch stay inside the agreed scope?
• Verify: What evidence supports the change?
• Summarize: What should the reviewer pay attention to?

Where this goes wrong

This loop can be overkill for trivial edits. A typo, small fixture update, or isolated rename does not need six formal steps.

It can also become performative. If the agent writes a plan nobody reads, runs tests nobody trusts, and produces summaries nobody uses, the loop is ceremony.

The value comes from using the phases as control points. The human should have chances to redirect before the work becomes expensive to unwind.

What I do now

I tune the loop to risk.

For low-risk work, I collapse framing and planning into a short instruction, then review the diff.

For medium-risk work, I require exploration before edits and verification after.

For high-risk work, I split the session into separate artifacts: analysis, plan, tests, implementation, and review notes. I may ask a second agent or a human reviewer to attack the result from a different angle.

I also keep write scopes small. The agent should not modify build files, generated artifacts, tests, and production code in one pass unless that is the explicit task.

Risk-adjusting the loop

The loop earns its keep when it changes shape with the risk profile.

For isolated code, the main risk is usually local correctness. The agent can inspect, patch, and run a tight test command in one session. The review focuses on whether the implementation matches the intended behavior and avoids unrelated churn.

For boundary code, the risk is contract drift. APIs, event schemas, permissions, and persisted data need a slower loop. I want the agent to identify callers and consumers before writing, then show evidence that compatibility was preserved or intentionally changed.

For operational code, the risk is recovery. Jobs, queues, deploy scripts, migrations, alerts, and fallback paths need explicit rollback thinking. The agent should not only say the happy path works. It should describe what happens if the change is half-deployed, retried, delayed, or reverted.

For product semantics, the risk is authority. A generated patch can change what a user is allowed to do, what a status means, or when a workflow is considered complete. Those changes require human decision-making before implementation speed matters.

This is the distinction I care about: the agent loop is not a fixed ceremony. It is a control system. As blast radius rises, the loop adds more pauses where a human can inspect evidence and redirect the work.

Closing takeaway

Trust the loop, not the fluency: make every agent step produce evidence that a human can inspect and own.