# Stop Prompting Your Coding Agent. Give It a Loop.

Canonical URL: https://huecki.com/en/blog/stop-prompting-coding-agent-loop-spec/
Markdown URL: https://huecki.com/en/blog/stop-prompting-coding-agent-loop-spec.md
Language: English
Published: 2026-07-02
Updated: 2026-07-02
Author: Dominic Hückmann
Topic: AI Agent Workflows
- Agent topics: Context Engineering, LLM-native Engineering
- Tags: AI Agents, Coding Agents, Agent Skills, Agent Memory, Developer Workflow, Verification
- Audience: developers using coding agents, teams standardizing agent workflows, AI engineering leads
- Concepts: agent-loops, agent-skills, verifier-gates, agent-memory
Thesis: For recurring coding-agent work, the durable artifact should be a loop specification, not another longer prompt.
Content status: field-note

## Summary

The useful upgrade from prompt engineering is not a longer instruction block. It is a reusable loop spec: trigger, goal, allowed tools, verifier, terminal states, and memory rules. That is how repeated coding-agent work becomes operational instead of conversational.

## Description

A practical field note from the July 2026 agent radar: recurring coding-agent work should become loop specs with skills, verifier gates, terminal states, and memory hygiene.

## Body

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

```txt
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.

A useful loop spec says:

```txt
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](https://arxiv.org/abs/2607.00038) 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.

## 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:

```txt
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.

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.

```txt
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.

```txt
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:

```txt
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.

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

```txt
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](https://arxiv.org/abs/2605.23904) 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:

```txt
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.

The practical rule:

```txt
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](https://arxiv.org/abs/2607.01071) 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:

```txt
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:

```txt
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.

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

```txt
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.

```txt
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:

```txt
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.

Then run it three times.

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

Ask:

```txt
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:

```txt
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](https://arxiv.org/abs/2607.00038)
- [SkillOpt: Executive Strategy for Self-Evolving Agent Skills](https://arxiv.org/abs/2605.23904)
- [MemSyco-Bench: Benchmarking Sycophancy in Agent Memory](https://arxiv.org/abs/2607.01071)
- Huecki AI radar, 2026-07-02: `/root/website/content-research/radar/2026-07-02.md`

## FAQ

### What is a loop spec for a coding agent?

A loop spec is a reusable operating card for an agent run: trigger, goal, allowed tools, verifier, stopping rule, terminal states, and memory update rules.

### How is a loop spec different from a prompt?

A prompt asks the model to behave in a certain way. A loop spec defines the repeatable workflow around the model, including what evidence is required before the run can finish.

### What should teams start with?

Choose one recurring painful workflow, define a verifier that cannot be faked in prose, name the terminal states, and add one memory rule for what the agent may carry forward.


## Related

- The harness is the runtime; the loop spec is the reusable operating procedure you hand to it.: agents-dont-need-longer-prompts-they-need-harnesses
- Failed runs provide evidence for improving the reusable skill inside a loop.: failed-agent-runs-should-become-skills
- Loop memory should be tested for update, scope, and false-premise behavior.: agent-memory-tests-measure-wrong-thing

## Source References

- [Stop Hand-Holding Your Coding Agent: Engineering the Loops that Replace Step-by-Step Prompting](https://arxiv.org/abs/2607.00038) (paper)
- [SkillOpt: Executive Strategy for Self-Evolving Agent Skills](https://arxiv.org/abs/2605.23904) (paper)
- [MemSyco-Bench: Benchmarking Sycophancy in Agent Memory](https://arxiv.org/abs/2607.01071) (paper)
- [Huecki AI radar, 2026-07-02](https://huecki.com) (internal-radar)