# From Prompt Engineering to Loop Engineering


For the past few years, developers have been learning how to **talk to AI better**.

Write a better prompt.

Give better context.

Add constraints.

Ask for reasoning.

Provide examples.

Refine the prompt when the answer isn't good enough.

That worked.

But something more interesting is starting to happen.

The next step may not be learning how to write a better prompt.

It may be learning how to build a system where **you don't have to write the next prompt at all**.

Boris Cherny, who leads Claude Code at Anthropic, described his workflow this way:

> “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

That sounds like a small change in workflow.

It isn't.

It represents a shift in **where the human sits in the AI system**.

Instead of being the person continuously operating the model, you become the person designing the system that operates the model.

![](https://cdn.hashnode.com/uploads/covers/675f26f6c120efae1392a044/47003674-b4b8-4b7b-b910-c3ad6adbe2a7.jpg align="center")

And that raises a much bigger question:

**What happens when the AI isn't just answering our instructions, but is continuously deciding what to do next?**

## The Prompt Was Never the Whole System

Consider a developer debugging a production issue.

The traditional workflow might look like this:

```text
Developer
   ↓
"Find why checkout is failing"
   ↓
AI investigates
   ↓
Developer reads response
   ↓
"Check the payment service logs"
   ↓
AI investigates
   ↓
Developer reads response
   ↓
"Try reproducing it"
   ↓
AI investigates
   ↓
Developer decides what happens next
```

Notice something important.

The AI is doing a lot of the work.

But **the developer is still the control loop**.

Every time the AI finishes one step, the human interprets the result and decides what should happen next.

The human is effectively writing:

```text
prompt → response → prompt → response → prompt
```

The model isn't necessarily the bottleneck.

**The human's attention is.**

Loop engineering changes that relationship.

Instead of manually deciding every next action:

```text
Goal
 ↓
Agent
 ↓
Observation
 ↓
Next action
 ↓
Agent
 ↓
Observation
 ↓
Next action
```

The system itself manages the iteration.

Your role moves from:

**“Tell the AI what to do.”**

to:

**“Design the conditions under which the AI should continue working.”**

That is a very different job.

* * *

# So What Exactly Is a Loop?

At its simplest, an AI loop looks like this:

```text
Goal
 ↓
Plan
 ↓
Act
 ↓
Observe
 ↓
Evaluate
 ↓
Decide what happens next
 ↓
Repeat
```

Suppose you give an agent the goal:

> Reduce the response time of this API without changing its external behavior.

A single prompt might produce a few suggestions.

A loop can do much more:

```text
Inspect application
      ↓
Identify slow endpoint
      ↓
Profile database queries
      ↓
Propose optimization
      ↓
Implement change
      ↓
Run benchmark
      ↓
Did latency improve?
    ↙       ↘
   No       Yes
   ↓         ↓
Try again   Run regression tests
               ↓
           Are tests passing?
             ↙      ↘
            No      Yes
            ↓         ↓
         Fix it     Finish
```

The agent isn't simply generating text.

It is participating in a **feedback system**.

The result of one action becomes the input for the next action.

That feedback is what makes the loop powerful.

![](https://cdn.hashnode.com/uploads/covers/675f26f6c120efae1392a044/17798ab4-e328-422e-a1da-cc8176fbbc29.png align="center")

* * *

# The Real Innovation Isn't “AI That Prompts Itself”

The phrase “AI prompts itself” sounds almost magical.

But that's not really what's happening.

The underlying system is still engineered by humans.

Someone has to decide:

*   What goal are we pursuing?
    
*   What tools can the agent access?
    
*   What information can it see?
    
*   What counts as success?
    
*   What happens after failure?
    
*   How many attempts are allowed?
    
*   When should it stop?
    
*   When should a human intervene?
    

The intelligence isn't simply inside the model.

It is distributed across the **model + tools + memory + feedback + verification + control logic**.

That's why loop engineering is an engineering problem.

The model is one component.

The loop is the system.

* * *

# Prompt Engineering vs Loop Engineering

The difference becomes clearer when you put them side by side.

| Prompt Engineering | Loop Engineering |
| --- | --- |
| Optimize the instruction | Optimize the workflow |
| Focus on one interaction | Focus on repeated interactions |
| Human chooses the next prompt | System determines the next action |
| Output is the main result | Progress toward a goal is the result |
| Context is supplied per interaction | State can persist across iterations |
| Human often evaluates the response | Automated checks can evaluate progress |
| One model interaction | Potentially many model/tool interactions |

![](https://cdn.hashnode.com/uploads/covers/675f26f6c120efae1392a044/06c78e37-109f-49ea-b2fc-2bb109f03687.png align="center")

Prompt engineering asks:

> **How do I get a better answer?**

Loop engineering asks:

> **How do I build a system that keeps getting closer to the right outcome?**

That is a much larger question.

* * *

# The Most Important Part of a Loop Is Not the Loop

Here's the part that is easy to miss.

Writing:

```python
while not done:
    ask_ai()
```

isn't particularly impressive.

The difficult part is defining `done`.

Imagine asking an agent to:

> “Improve the security of this application.”

When should it stop?

After changing one dependency?

After adding authentication?

After passing unit tests?

After a security scanner reports no critical issues?

After a human reviews the changes?

There is no obvious stopping point.

Now compare that with:

> “Upgrade the dependency, run the complete test suite, run the security scanner, and stop only when all tests pass and no high-severity vulnerabilities remain.”

Suddenly the loop has a measurable target.

This is one of the biggest changes in agentic engineering:

**The quality of the stopping condition becomes as important as the quality of the prompt.**

* * *

# Verification Becomes the New Superpower

AI can generate an answer very quickly.

The harder question is:

**How do we know it is correct?**

A good loop therefore needs a feedback signal.

For software, that might be:

```text
Unit tests
Integration tests
Type checking
Linting
Build status
Benchmarks
Security scanners
API responses
```

For research:

```text
Source validation
Data consistency
Reproducibility
Independent review
```

For data pipelines:

```text
Schema validation
Row counts
Null checks
Quality thresholds
```

The pattern is always similar:

```text
Agent does something
       ↓
System measures result
       ↓
Result becomes feedback
       ↓
Agent decides next action
```

This is why verification may become one of the most important skills in agentic engineering.

Generating something is increasingly easy.

**Knowing when it is actually good enough is much harder.**

* * *

# The Maker Shouldn't Always Be the Judge

There's another interesting architectural pattern here.

Imagine asking one AI agent to:

1.  Write the code.
    
2.  Review its own code.
    
3.  Decide whether its review is correct.
    
4.  Declare itself finished.
    

You have created a closed feedback loop.

That can work.

But it can also reinforce the same mistake.

A more robust architecture separates responsibilities:

```text
              ┌───────────────┐
              │   Objective   │
              └───────┬───────┘
                      ↓
              ┌───────────────┐
              │  Builder AI   │
              └───────┬───────┘
                      ↓
                 Implementation
                      ↓
              ┌───────────────┐
              │  Reviewer AI  │
              └───────┬───────┘
                      ↓
                 Verification
                  ↙       ↘
               Failed    Passed
                 ↓          ↓
             Iterate      Finish
```

The first agent is optimized for **doing**.

The second is optimized for **checking**.

This maker-checker architecture becomes particularly valuable when the system is operating without constant human supervision.

* * *

# Memory Changes Everything

A normal chatbot conversation is temporary.

A long-running agent needs something different.

Imagine an AI working on a large application over several days.

It needs to remember:

```text
What has already been changed?

Which approach failed?

Which tests are still failing?

Which assumptions were made?

What should be attempted next?
```

That information shouldn't depend entirely on a single conversation window.

It can live in:

*   repository files
    
*   issue trackers
    
*   databases
    
*   task boards
    
*   structured state files
    
*   agent-generated reports
    

The important idea is:

**The agent can be temporary. The project's memory cannot be.**

⭐This is what allows a loop to stop today and continue tomorrow without starting from zero.

The source you provided similarly identifies persistent state as a fundamental component of long-running loops.

* * *

# Multiple Agents Change the Architecture Again

Once you can run one agent autonomously, the natural next question is:

**Why stop at one?**

You might have:

```text
Research Agent
       ↓
Planning Agent
       ↓
Implementation Agent
       ↓
Testing Agent
       ↓
Security Agent
       ↓
Documentation Agent
```

Each agent has a different responsibility.

This resembles a software team.

But unlike a traditional team, these workers can potentially run in parallel, communicate through shared state, and operate continuously.

The challenge then changes.

It is no longer:

> “How do I make one AI smarter?”

It becomes:

> **“How do I coordinate multiple AI workers without creating chaos?”**

That is an orchestration problem.

And orchestration introduces its own costs:

*   more model calls
    
*   more context
    
*   more tokens
    
*   more opportunities for conflicting decisions
    
*   more difficult debugging
    
*   more complex failure modes
    

More agents do not automatically mean a better system.

* * *

# The Loop Can Become a Software Factory

Now take all of these components and connect them.

Imagine a company has a backlog of small engineering tasks.

Every evening:

```text
New issues
    ↓
Agent analyzes them
    ↓
Classifies priority
    ↓
Selects suitable tasks
    ↓
Creates isolated workspace
    ↓
Implementation agent works
    ↓
Testing agent verifies
    ↓
Security checks run
    ↓
Pull request created
    ↓
Human reviews important changes
```

The human isn't manually prompting every agent.

The human designed the factory.

This is the deeper meaning behind loop engineering.

The unit of automation is no longer:

**one prompt → one response**

It becomes:

**goal → repeated actions → feedback → verification → completion**

* * *

# But There Is a Darker Side to This

This is also where the conversation around AI self-improvement becomes interesting.

Anthropic's own recent discussion on **recursive self-improvement** describes a progression in which humans delegate increasingly large parts of AI development to AI systems themselves. Anthropic says this trend is accelerating its work, while also explicitly stating that it has **not reached fully autonomous recursive self-improvement** and that such an outcome is not inevitable. ([Anthropic](https://www.anthropic.com/institute/recursive-self-improvement?curius=2071&utm_source=chatgpt.com))

That's an important distinction.

A coding agent fixing its own generated code is one thing.

An AI system contributing to the development of increasingly capable AI systems is another.

And a system capable of independently designing and developing its own successor would be another level entirely.

These should not be treated as the same phenomenon.

But they are connected by one architectural idea:

**⭐ feedback loops.**

* * *

# From “Fix My Code” to “Figure Out What to Build”

There is an interesting progression happening.

Early AI coding assistants were essentially:

> “Complete this line.”

Then:

> “Implement this function.”

Then:

> “Build this feature.”

Then:

> “Investigate this bug and fix it.”

Now we're moving toward:

> “Figure out why this system is underperforming, investigate possible causes, test solutions, and continue until the measurable objective is satisfied.”

The human instruction becomes less specific.

The AI receives more responsibility for determining the path.

Anthropic's own discussion describes a similar progression—from executing a task specified by a human, toward systems that can investigate open-ended problems and eventually help determine which problems are worth working on. ([Anthropic](https://www.anthropic.com/institute/recursive-self-improvement?curius=2071&utm_source=chatgpt.com))

That is a significant change in abstraction.

* * *

# And This Is Why “Self-Improvement” Gets Complicated

Suppose an agent has this loop:

```text
Build
 ↓
Test
 ↓
Learn from failure
 ↓
Modify
 ↓
Test again
```

That's already a primitive form of iterative improvement.

Now imagine the system isn't improving a piece of application code.

Imagine it is improving:

```text
its tools
its instructions
its evaluation process
its workflows
its ability to solve problems
```

Now the loop is operating at a higher level.

And eventually you can ask:

> What happens if the thing being improved is the system responsible for doing the improving?

That's where the idea of **recursive self-improvement** enters.

But this is precisely where careful language matters.

Anthropic's current position is not that this has already happened. Its published analysis says the capability could arrive sooner than institutions are prepared for, while acknowledging that fully autonomous recursive self-improvement has not been reached. ([Anthropic](https://www.anthropic.com/institute/recursive-self-improvement?curius=2071&utm_source=chatgpt.com))

So the interesting question isn't:

**“Has AI become fully self-improving?”**

The more useful question is:

**“How much of the development loop can AI already participate in?”**

That question can actually be measured.

* * *

# The Developer's Job Is Moving Up the Stack

This may be the biggest consequence of all.

Consider three generations:

### Generation 1 — Code

```text
Human → writes code
```

### Generation 2 — Prompt

```text
Human → prompts AI → AI writes code
```

### Generation 3 — Loop

```text
Human
  ↓
defines goal + constraints + verification
  ↓
Loop
  ↓
AI → tools → tests → feedback
  ↖______________________↙
```

The human has moved further away from the individual line of code.

But that doesn't mean the human has become irrelevant.

The human now has to understand:

**What should the system optimize for?**

**What should it never do?**

**How should success be measured?**

**Where should autonomy stop?**

Those are harder questions than writing a prompt.

* * *

# The New Bottleneck May Be Judgment

AI can already generate enormous amounts of code.

But software isn't valuable because there is a lot of code.

⭐It is valuable because the code solves the **right problem**.

That means human judgment becomes extremely important at the higher levels:

```text
Which problem matters?
        ↓
What does success look like?
        ↓
What constraints matter?
        ↓
What risks are unacceptable?
        ↓
How should the agent be evaluated?
```

If you automate the wrong objective, you don't get the right result faster.

You get the **wrong result faster**.

That may be the central danger of autonomous loops.

* * *

# The Most Dangerous Loop Is the One You Don't Understand

Imagine a loop that runs perfectly.

Every night it:

*   reads issues
    
*   modifies code
    
*   runs tests
    
*   creates pull requests
    
*   updates documentation
    

After six months, the system has changed thousands of files.

But nobody really understands why certain decisions were made.

The system is productive.

It is also becoming opaque.

That's where **comprehension debt** becomes important.

The more work agents perform on your behalf, the greater the gap can become between:

```text
What the system contains
```

and

```text
What you actually understand
```

A productive engineer therefore cannot simply ask:

> “Did the AI finish?”

They also need to ask:

> **“Do I understand what it changed, and do I trust the evidence that says it works?”**

* * *

# So Should Developers Stop Prompting?

No.

That's not really the lesson.

If you need a quick explanation:

```text
Prompt it.
```

If you need a small code transformation:

```text
Prompt it.
```

If you need a brainstorming session:

```text
Prompt it.
```

But if you repeatedly perform the same multi-step workflow:

```text
Investigate
→ modify
→ test
→ inspect
→ retry
→ verify
```

then you should start asking:

> **Why am I manually operating this workflow every time?**

That's where a loop becomes useful.

* * *

# The Future Skill May Be Loop Design

Prompt engineering taught us to communicate with models.

Context engineering taught us to control what models see.

Agent engineering taught us to give models tools and goals.

Loop engineering pushes one level further:

**⭐Design the feedback system in which the agent operates.**

That means thinking about:

```text
Goal
 ↓
Context
 ↓
Tools
 ↓
Actions
 ↓
Observations
 ↓
Verification
 ↓
Memory
 ↓
Next action
```

And most importantly:

```text
              ┌───────────────┐
              │     GOAL      │
              └───────┬───────┘
                      ↓
              ┌───────────────┐
              │     AGENT     │
              └───────┬───────┘
                      ↓
                 Take action
                      ↓
              Observe outcome
                      ↓
              Verify result
                 ↙       ↘
             Failed     Passed
               ↓           ↓
           Try again      Stop
               │
               └──────→ AGENT
```

That diagram is the heart of the idea.

**The agent isn't the loop.**

⭐The **feedback system around the agent** is the loop.

* * *

# Build Loops. But Don't Abandon Engineering.

There is a temptation to look at autonomous agents and think:

> “Great. I can finally stop thinking.”

It is almost the opposite.

The less frequently you interact with the agent, the more carefully you need to design the system around it.

You need better:

*   specifications
    
*   tests
    
*   observability
    
*   state management
    
*   permissions
    
*   verification
    
*   failure handling
    
*   human checkpoints
    

Automation doesn't eliminate engineering.

**⭐It moves engineering to a higher level.**

And that may be the real meaning behind Boris Cherny's statement.

The future isn't necessarily:

> Humans stop writing code.

It may be:

> Humans stop manually directing every step of the coding process.

⭐Instead, developers increasingly define goals, constraints, feedback mechanisms, and stopping conditions—and let AI systems navigate the path between them.

That's a profound change.

Because once the AI can decide what to ask next, **the prompt is no longer the center of the system.**

The loop is.

And the engineer's most important question may no longer be:

> **“What should I prompt the AI?”**

It may become:

> **“What kind of system should I build so the AI knows what to do next—and how will I know when it is right?”**

That is where the next phase of AI engineering begins. :::

*   **The Next AI Skill Isn't Prompt Engineering. It's Loop Engineering.**