Stop Prompting Your Coding Agent. Give It a Loop.

The worst way to use a coding agent is also the most common one:

Tell it what to do.
Watch it drift.
Paste corrections.
Ask it to continue.
Repeat until either the code works or your patience runs out.

This feels like collaboration, but mostly it is remote control.

The agent is not really operating a workflow. You are operating the agent.

That does not scale past one developer with one chat window. It also does not survive context resets, new team members, repo-specific traps, or tomorrow’s slightly different version of the same task.

The better artifact is not a longer prompt.

It is a loop.

The Short Version

For recurring coding-agent work, stop writing one-off instructions and start writing small loop specs.

1

recurring workflow

1

verifier that can fail

3+

named terminal states

A useful loop spec says:

When this trigger appears,
pursue this goal,
using these tools,
under these constraints,
until this verifier passes,
or one of these terminal states is reached,
then write only this kind of memory.

That is the shift behind the July 2026 radar signal. The new paper Stop Hand-Holding Your Coding Agent gives the practice a clean name: loop specifications. It defines them as bounded, reusable artifacts with trigger, goal, verification step, stopping rule, and memory.

The important part is not the slogan. The important part is where the burden moves.

Prompting puts the burden on the model’s next response.

Loop design puts the burden on the system around the response.

From chat steering to loop design

the reusable artifact is the workflow, not the correction you typed in chat

1. 01
   Trigger
2. 02
   Goal
3. 03
   Skill
4. 04
   Tools
5. 05
   Verifier
6. 06
   Terminal state
7. 07
   Memory rule

Why Better Prompts Hit a Ceiling

Prompt engineering still matters. The loop-spec paper is right to push back against the lazy version of the argument: loops do not retire prompts. The model still needs clear local instructions.

But a prompt is a weak place to store operational control.

You can tell an agent:

Be careful with migrations.
Run the tests.
Do not touch unrelated files.
Remember what you learned.
Ask if blocked.

That sounds responsible. It is also easy for the run to fake.

The agent can say tests passed without running the right tests. It can “remember” a stale lesson. It can stop because the answer looks complete, not because the workflow has reached a real terminal state. It can avoid asking because the chat context rewards confident forward motion.

A loop spec makes those soft wishes harder and more inspectable.

Prompt habit vs. loop habit

Prompt habit

• Ask the agent to be careful.
• Ask it to run tests.
• Ask it to remember lessons.
• Ask it to continue until done.
• Paste corrections every run.

Loop habit

• Define the risky files and approval boundary.
• Name the verifier command and required evidence.
• Define what memory may be written and when it expires.
• Name pass, blocked, unsafe, and needs-human terminal states.
• Promote repeated corrections into a reusable skill.

The difference is boring in exactly the right way.

You are moving from “please behave” to “this run has an operating contract.”

A Loop Spec You Can Steal

Start with one painful workflow. Do not begin with “make our whole coding process agentic.” Pick something that already repeats:

• dependency upgrades
• small bug reproduction
• broken end-to-end test triage
• SEO pre-publish checks
• API client regeneration
• accessibility pass on a page
• support-ticket reproduction

Then write the loop card.

name: dependency-upgrade-loop

trigger:
  A dependency upgrade PR, Dependabot patch, or package bump request appears.

goal:
  Upgrade the dependency with the smallest reasonable diff while preserving current behavior.

scope:
  Allowed: package files, lockfiles, direct compatibility fixes, tests related to the changed package.
  Not allowed: unrelated refactors, broad formatting churn, opportunistic framework upgrades.

skill:
  Load the repo's dependency-upgrade skill before editing.
  If no skill exists, inspect one prior successful upgrade and create a short run note.

allowed_tools:
  - package manager
  - test runner
  - typechecker
  - local docs or changelog lookup

verifier:
  Required:
    - install succeeds from a clean lockfile state
    - typecheck passes
    - targeted tests pass
    - at least one runtime smoke check passes if the package affects runtime behavior

terminal_states:
  pass:
    Verifier passed and diff stayed inside scope.
  blocked:
    Missing credentials, broken upstream package, or reproducible failure outside the change.
  unsafe:
    Upgrade requires migration, data deletion, permission change, or broad architecture change.
  needs_human:
    Changelog contains behavior change that needs product judgment.

memory_rule:
  Save only verifier-relevant lessons:
    - exact command that caught the issue
    - repo-specific compatibility trap
    - migration note with source link
  Do not save guesses, secrets, private logs, or one-off cache problems.

This is small enough to use. It is also specific enough to evaluate.

The agent does not need to infer what “done” means from vibes. The loop names the goal, scope, verifier, and terminal states before work starts.

The Verifier Is the Center

Weak loops fail because their verifier is just another sentence.

Verify that the change is good.

That is not a verifier. That is a hope with a business-casual jacket.

The loop-spec paper describes verification as a ladder. The practical version for teams is:

Level 0: no verifier
Level 1: agent self-check
Level 2: human-readable checklist
Level 3: executable local check
Level 4: external system check
Level 5: production or held-out regression signal

You do not always need Level 5. A blog draft, design critique, or research note may not have a perfect deterministic judge.

But you should know which level you are using.

Verifier rules

• Prefer executable checks over agent self-review when the task allows it.
• Make the evidence visible: command, output, URL, screenshot, test name, or diff.
• Keep a hard-fail list for actions that invalidate the run regardless of final quality.
• Do not let the same agent that made the claim be the only judge of the claim.

For coding agents, the best verifier is often disappointingly ordinary:

npm run build
npm run typecheck
npm test -- path/to/failing.test.ts
curl the local endpoint
open the page and inspect the rendered state
compare generated output before and after

That is fine. Agent reliability is usually not improved by glamorous evaluation theory first. It is improved by forcing the run to carry proof.

Skills Are the Part That Should Improve

Loop specs and skills fit together.

The loop says how the run proceeds.

The skill says how the agent should perform a reusable kind of work inside that run.

That distinction matters because skills are becoming measurable artifacts. SkillOpt treats an agent skill as external state for a frozen agent: propose bounded edits, score rollouts, and accept only edits that improve held-out validation.

You do not need to reproduce the full optimizer to steal the discipline.

For a normal team, “Skill CI” can be simple:

skill: seo-prepublish-check

eval_cases:
  - page with missing canonical
  - page with stale date
  - page with broken internal link
  - page with missing source reference
  - clean page that should not be changed

score:
  +1 catches real issue
  +1 fixes with minimal diff
  -2 invents issue
  -3 changes unrelated content
  hard fail: claims publish-ready without running required checks

Now skill edits are not just taste. They are candidates that can pass or fail.

Loop and skill improvement

keep the run contract stable while improving the reusable behavior inside it

1. 01
   Run loop
2. 02
   Collect trace
3. 03
   Find failure
4. 04
   Patch skill
5. 05
   Rerun eval cases
6. 06
   Accept or reject

The practical rule:

If a correction is needed once, fix the run.
If the correction is needed three times, patch the skill.
If the skill patch matters, add an eval case.

That keeps the loop from turning into a junk drawer of advice.

Memory Is Not a Trophy Cabinet

The easiest way to ruin a loop is to let it write bad memory.

Agent memory feels helpful because it preserves context. It is also a safety surface. The MemSyco-Bench paper is useful because it asks when retrieved memory should influence a decision, when it should be rejected as evidence, how scope should be respected, and how conflicts with objective evidence should be resolved.

That is exactly the problem with coding-agent loops.

A memory like this can help:

In this repo, generated blog markdown is validated through npm run build.
Do not mark a content edit done until Astro content validation passes.

A memory like this can hurt:

The build is flaky, so ignore build failures.

Maybe it was flaky once. Maybe the agent caused the failure. Maybe the dependency cache was stale. If that memory gets retrieved later, it can make the agent more agreeable to the wrong conclusion.

So every loop needs a memory write rule.

Memory hygiene for loops

Do

• ✓ Save verifier-relevant lessons with the command, file, or source that proved them.
• ✓ Name the scope: repo, project, customer, workflow, or date range.
• ✓ Record what would make the memory stale or wrong.
• ✓ Prefer small operational facts over broad personality claims about the project.

Do not

• × Save guesses because they felt useful during one run.
• × Let stale memory override fresh command output or source evidence.
• × Store secrets, private logs, hidden tests, or customer data.
• × Use memory to excuse skipped verification.

Here is the tiny rule I would put at the bottom of every serious loop spec:

Before saving memory, answer:
1. What exact future task should retrieve this?
2. What evidence proves it?
3. What would make it false or stale?
4. Who or what asserted it?
5. Should it expire?

If those answers are unclear, write a run note instead of durable memory.

This is not bureaucracy. It is how you stop long-term memory from becoming a confidence amplifier for old mistakes.

Terminal States Beat Endless Autonomy

A good loop does not only say how to continue.

It says how to stop.

Bad agent runs often fail in one of two ways:

• they stop too early because the final answer sounds complete;
• they continue too long because “autonomy” becomes permission to churn.

Named terminal states fix both.

pass:
  verifier passed, evidence attached, scope respected

blocked:
  required input missing, external dependency unavailable, or failure reproduced outside agent control

unsafe:
  requested action crosses money, deletion, credentials, public posting, legal, security, or production-data boundary

needs_human:
  tradeoff requires product, design, business, or domain judgment

failed:
  verifier still fails after allowed attempts or diff exceeded scope

This is one of the simplest upgrades a team can make.

It gives the agent permission to stop honestly.

It also makes review easier. A reviewer can ask:

Which terminal state did the loop reach?
What evidence supports that state?
Was another state more appropriate?

That is a better conversation than “did the agent do a good job?”

The Small-Team Starting Point

Do not build a full agent platform first.

Pick one workflow that hurts every week and write a one-page loop spec.

First loop checklist

• One trigger: when should this loop start?
• One goal: what outcome matters?
• One scope boundary: what must the agent avoid?
• One verifier: what external evidence decides success?
• Four terminal states: pass, blocked, unsafe, needs-human.
• One memory rule: what may be preserved for future runs?

Then run it three times.

After each run, do not ask “was the model smart?”

Ask:

Did the trigger fire at the right time?
Was the goal specific enough?
Did the verifier catch the real failure?
Did the terminal state match the evidence?
Did memory help, hurt, or stay irrelevant?
What correction should become a skill eval?

That is the operating discipline.

The Real Recommendation

The July 2026 signal is not that prompts are dead. That is too neat and mostly wrong.

The signal is that serious agent work is moving up a level:

prompt -> context -> harness -> loop

Prompts still matter. Context still matters. Harnesses still matter.

But the reusable unit of work is becoming the loop spec.

That is good news for small teams. You do not need frontier-model access to benefit from it. You need to stop treating every agent run as a fresh conversation and start treating repeated work as an engineered operating procedure.

Write the loop.

Name the verifier.

Patch the skill.

Guard the memory.

Stop when the terminal state says stop.

That is how coding agents become less like interns in a chat window and more like tools you can actually trust with recurring work.

Sources

• Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting
• SkillOpt: Executive Strategy for Self-Evolving Agent Skills
• MemSyco-Bench: Benchmarking Sycophancy in Agent Memory
• Huecki AI radar, 2026-07-02: /root/website/content-research/radar/2026-07-02.md