1. How this sentence should really be read

One line has been circulating a lot lately:

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

I prefer to read it like this:

You should stop driving coding agents by writing prompts one at a time. You should design loops, and let those loops generate, constrain, inspect, and correct the prompts and tasks the agent needs.

The emphasis is not "stop writing prompts". The prompt is still the core input to an agent's work. What has actually changed is this: the prompt is no longer a sentence a person dashes off on the spot each time, but a workflow artifact that a verifiable loop keeps correcting.

2. The closest example is not an ordinary app but Skill development

If all you are building is a small utility, Loop Engineering can sound abstract. But if you have built an agent Skill, the idea becomes immediate.

A Skill is essentially an encapsulated bundle — prompts, rules, reference material, input and output constraints, execution steps — that lets an agent work steadily on a particular task.

Which is why Skill development shows this sentence most plainly:

A Skill should not be developed as a pile of one-off prompts. Design a loop instead, so that test results, real runtime failures, and human review comments keep feeding back in, continuously correcting the prompts and rules inside the Skill.

3. A made-up example: building a "meeting-notes Skill"

Suppose you want a Skill that helps product managers organize meeting notes. The input is the transcript of a recorded meeting; the output is structured meeting decisions, action items, risks, and open questions.

Your first version may be nothing more than a single prompt:

Please read the meeting transcript and organize it into meeting decisions, action items, owners, and risks.

It looks serviceable on the first run, but a few runs later the problems surface:

• Speculation from the discussion gets written up as formal conclusions.
• Action items with no clear owner are given owners anyway.
• States like "not handling this yet" and "revisit next time" get dropped.
• The output format swings — a table one moment, paragraphs the next.
• Casual chatter from the meeting ends up in the formal minutes.

If you respond by only bolting more instructions onto the prompt — "be more rigorous", "do not invent owners", "output a fixed format" — you are still doing Prompt Engineering.

4. From Prompt Engineering to Loop Engineering

In Skill development, the loop breaks this task into a more stable structure:

meeting-notes-skill/
  SKILL.md
  references/
    extraction-rules.md
    output-schema.md
    review-checklist.md
  tests/
    golden/
      owner-pending-input.txt
      owner-pending-expected.json
      decision-vs-discussion-input.txt
      decision-vs-discussion-expected.json

SKILL.md is more than "please organize the meeting notes". It has to spell out the Skill's goal, its input scope, its output structure, and the behaviour it must not exhibit.

extraction-rules.md defines what may count as a meeting decision, what may only count as an open question, and what must be discarded.

output-schema.md fixes the output structure, for example:

{
  "decisions": [],
  "action_items": [],
  "risks": [],
  "open_questions": [],
  "ignored_content": []
}

tests/golden/ holds the golden test set: typical inputs, expected outputs, and forbidden outputs.

5. How one concrete failure joins the loop

Suppose this sentence appears in one of your test inputs:

Zhang San may be able to pick this up, but nothing is settled yet.

The first version of the Skill answers:

{
  "action_items": [
    {
      "task": "Pick this item up",
      "owner": "Zhang San"
    }
  ]
}

The answer is wrong: the original says "may" and "nothing is settled yet", so the owner is not confirmed.

Had you only patched the prompt on the spot, you might have written:

Do not record an unconfirmed owner as a confirmed owner.

Loop Engineering instead converts this failure into a rule and a test.

New rule

If words of uncertainty — "may", "maybe", "tentative", "not settled yet", "to be confirmed" — appear before or after an owner,
that person must not be recorded as a confirmed owner.
The item may only be written into open_questions or action_items.pending_owner.

New golden test

Input:
"Zhang San may be able to pick this up, but nothing is settled yet."

Expected:
open_questions contains "owner to be confirmed".

Forbidden:
action_items.owner = "Zhang San"

From now on, whenever you change the Skill — prompt, reference rules, or output structure alike — this test must run. If it once again records Zhang San as the confirmed owner, the Skill has regressed.

6. The loop runs on validation feedback, not on prompts

Most people who talk about Loop Engineering talk only about "calling the agent in a loop". A loop without a validator is merely prompting in circles. A loop with a validator is an engineering system.

Validation feedback in Skill development generally comes in three kinds.

1. Golden test set

Pin down the typical inputs and their expected outputs, and run them every time the Skill changes. A case that used to pass and now fails means the change introduced a regression.

2. Deterministic checks

Whatever code can decide should never be left to the prompt. For example:

• Whether the JSON schema is valid.
• Whether required fields are present.
• Whether every output section is complete.
• Whether any forbidden expression appears.
• Whether an open question has been written up as a confirmed conclusion.
• Whether the failure log was written.

3. Real result feedback

New errors found in real meeting material should not stay buried in a chat log. Desensitized, they should join the test set, or turn into a new rule, a schema, or a review checklist item.

Only then does the system genuinely get smarter. Otherwise you are simply re-briefing the agent from scratch every time — that is not developing a Skill.

7. A Skill development loop might look like this

Write the first version of the Skill prompt
-> Prepare the golden test set
-> Run the Skill
-> Check the schema and the fixed rules
-> Review the output by hand
-> Attribute the failure: vague prompt, missing rule, loose schema, weak tests
-> Amend SKILL.md / references / schema / tests
-> Trial run with real material
-> Desensitize the real failure and add it to the regression tests
-> Next round

This is what "designing loops that prompt your agents" means. Not a person reminding the agent afresh each time, but a Skill development loop that keeps improving the prompts the agent will receive next round.

8. The precise meaning of the sentence

So this sentence should not be taken to mean "prompts will not be needed from now on". The more accurate reading is:

You should not build agent capabilities out of one-off prompts. You should design a feedback loop in which tests, reviews, real failures, and runtime results keep refining the prompt, the rules, the schema, and the Skill.

The prompt is the input. The Skill is the packaging. The loop is the mechanism of evolution.

The real watershed is not whether you can write a beautiful prompt; it is whether you can make the system remember its failures and avoid them automatically next round.