Loop engineering: stop prompting AI, design the loop

When I work with Claude Code, the most expensive moment is not always the one where the AI writes code. It is the moment when I have to explain, once again, what it should do next: rerun the tests, inspect the error, fix the file, and check that nothing else broke.

For a long time, I treated every step as a new prompt. Then I started looking at the problem differently: if I know the goal, the available tools, and how to verify the result, why do I still have to write every instruction by hand?

The problem: AI is always waiting for the next prompt

The classic workflow looks like this:

Me → Claude → result → me → new prompt → Claude...

I ask Claude to look for bugs. It finds one. I ask it to fix it. It changes the code. I ask it to rerun the tests. A test fails. I ask it to investigate. And so on.

This works, but it makes the human the engine of every transition. The AI can produce an action; it does not necessarily know which action comes next, or when it can consider the work complete.

The problem is therefore not only prompt quality. It is the absence of a process between two prompts.

Prompt engineering vs loop engineering

Prompt engineering looks for the best possible request. Loop engineering defines the system that will generate the next requests according to the results it gets.

Prompt engineering:
You → Claude → result → you → new prompt

Loop engineering:
You → goal + rules + validations
                 ↓
       Claude → action → test → correction
           ↑                       ↓
           └────── new attempt ────┘

The difference matters. In the first model, you drive Claude step by step. In the second, you design a loop that knows what to check and how to react when the check fails.

The minimal loop

An engineering loop does not need to be complicated. It only needs to answer five questions:

1. What is the goal? An observable success condition.
2. Which actions are allowed? The tools, files, and commands available.
3. How do we verify the result? Tests, lint, build, browser, screenshots, or review.
4. What happens when verification fails? Read the error, choose one cause, make the smallest change, and try again.
5. When does it stop? Success, an iteration limit, or a decision that requires a human.

That gives us the general agent loop:

Gather context
        ↓
Take action
        ↓
Verify the result
        ↓
Retry or finish

The most frequently forgotten part is verification. Without it, we do not have a loop: we have a sequence of AI-generated actions hoping to be right.

A concrete example: hardening a vibe-coded application

Suppose I want to finish an application generated quickly with Lovable, Cursor, or Claude Code. I could write:

Look for bugs.
Fix the form.
Rerun the tests.
Fix the new problem.

It is understandable, but it is not yet an autonomous workflow. I would rather define a loop contract:

Goal:
All tests pass and no ESLint errors remain.

At each cycle:
1. Read the current errors.
2. Select one root cause.
3. Change the minimum necessary code.
4. Run the relevant tests.
5. Check that no regression was introduced.
6. Record the change in PROGRESS.md.
7. Repeat if a validation fails.

Stop:
- tests and lint pass;
- after 15 cycles;
- or when a functional decision requires a human.

The instruction does not only say what to code. It describes the agent’s expected behaviour throughout the work.

What changes for the developer?

The developer does not disappear from the loop. Their role moves.

• Define the goal instead of dictating every gesture.
• Choose acceptance criteria instead of settling for a plausible result.
• Provide the tools that let the AI verify its work.
• Set boundaries and decide what must remain human.
• Keep a record of the work for the next session.

This starts to look like a combination of CI/CD, automated testing, project management, and agent supervision. The deliverable is no longer just code: it is code accompanied by evidence that it meets the success condition.

The loop does not replace judgement

A loop can verify that a test passes. It cannot decide by itself whether the test measures the right behaviour. It can reduce ESLint errors. It does not know whether the feature is still understandable to a user.

In one sentence

Prompt engineering is about asking for a task well. Loop engineering is about building a system that pursues, verifies, and corrects that task until the result can be demonstrated.

In the current Claude Code documentation, this principle appears through /goal, which keeps a session active until a completion condition is satisfied. It is a command, but more importantly, it is a new way of thinking about working with AI.