From Prompter to Loop Designer

Start With a Simple Picture

Imagine you have a very fast junior assistant. Right now, the way most people use one looks like this: you ask for something, you wait, you read what it did, you spot a mistake, you ask again. You are holding the assistant's hand the whole time. Every single step needs you.

Loop engineering is the idea that you stop being the hand-holder. Instead, you build a little system - a loop - that finds the work on its own, hands it to the assistant, checks whether the result is actually good, writes down what happened, and decides what to do next. You set it up once, and from then on the system does the prompting, not you.

An Everyday Analogy: The Dishwasher

Washing dishes by hand is like prompting an agent by hand. You stand at the sink, you do one plate, then the next, then the next. You are involved in every plate. It works - but your hands are full the entire time.

A dishwasher is a loop. You load it, you choose a setting, you press start, and you walk away. The machine does the repetitive work and tells you when it's done. You didn't get rid of yourself - you still load it, you still check a glass came out clean - but you stopped doing the boring middle part by hand.

What People at the Frontier Are Saying

This isn't a hypothetical. The people building these tools have already changed how they work:

The claim they're all making: the leverage point moved. For two years, the win came from writing the best prompt. Now the win comes from designing the best system around the agent.

What Is an "Agent", Really?

Before loops, get this one idea straight. When Anthropic measured Claude on real software bugs (the SWE-bench test), they were careful to explain that an "agent" is not just the AI model. It's the model plus the scaffolding around it:

AGENT = AI model  +  scaffolding

Scaffolding is the boring plumbing:
  • the prompt that gets sent in
  • the tools the model can use (run a command, edit a file)
  • the bit that reads the model's output and takes the next action
  • the loop that feeds the last result back in as the next input

In their test, the model followed a tiny, repeated loop on its own: explore the code → write a script to reproduce the bug → run it → edit the code → run again → check it's fixed. The same model scored far higher just because the scaffolding around it was well designed.

Prompting vs. Looping - Side by Side

PROMPTING (you are the engine)
  You: "Fix the failing login test."
  Agent: makes a change.
  You: read it, run tests, spot a problem.
  You: "No, the token expiry is still wrong."
  Agent: tries again.
  ...you repeat this until it's right or you give up.

LOOPING (the system is the engine)
  A schedule wakes up every morning.
  → It scans for failing tests by itself.
  → It hands each one to the agent to fix.
  → It RUNS the tests to check (no human needed).
  → It writes "fixed 3, stuck on 2" to a memory file.
  → It opens a pull request and pings you only for the hard 2.
  You: review the finished work over coffee.

Notice what changed: in the second version you didn't type a single prompt during the work. You designed when it runs, what it looks for, how it checks itself, and where it writes things down. That design is the job now.

How Engineers Use This to Build Better Software

This isn't about replacing engineers - it's about moving boring, repeatable work off their plate so they can focus on the hard, interesting parts. Real examples teams run as loops today:

The Honest Caveat (Read This Twice)

Some people online say loops mean "software engineering is dead" or quote huge productivity numbers like "8× more code shipped." Be skeptical. Anthropic itself said that 8× figure is "almost certainly an overstatement." Loops are powerful, but they are not magic, and they are not for everyone or every task.

Hands-On: Spot the Loops Around You