One of the more interesting shifts in AI right now is that we’re moving beyond Prompt Engineering and toward what many are calling Loop Engineering.
Prompt engineering was a very human job. You write a prompt, you read what comes back, you notice where it went wrong, you rewrite the prompt, you try again. You are the feedback loop. Every improvement passes through a person typing. That worked when the model did one thing per call and a human was always there to judge the result. It stops working the moment you want the system to handle a task that takes many steps without someone babysitting each one.
What actually changes
Instead of manually crafting prompts, inspecting outputs and feeding errors back into the model, the focus shifts to building systems that can:
- Plan their own work
- Execute tasks using tools
- Validate results against real-world feedback
- Self-correct when things go wrong
Look at what each of those replaces. Planning its own work means the system breaks the task down instead of you spelling out every step in the prompt. Executing with tools means it goes and does things, runs code, queries an API, reads a file, rather than just describing what should happen. Validating against real-world feedback means it checks its output against something real, a test that passes or fails, a result that matches or doesn’t, rather than you eyeballing the answer. And self-correcting means when the check fails, it tries again on its own, instead of waiting for you to notice and rewrite the prompt.
Put those four together and the human steps out of the inner loop. You’re no longer the thing that spots the error and feeds it back. The system does that part itself.
The bottleneck moved
The bottleneck is no longer how fast humans can write prompts. It’s how effectively we can design autonomous feedback loops.
This is the actual shift, and it changes what skill matters. When a person sat in the loop, the constraint was how quickly that person could iterate. Now the constraint is upstream, in the design. How does the loop know when it’s done? What does it check its work against? What happens when validation fails, does it retry, change approach, or give up. How many times before it stops. Get those decisions right and the system runs itself well. Get them wrong and it either quits too early or spins forever. None of that is prompt wording. It’s the architecture of the loop.
The part nobody budgets for
That said, building these loops is far from free. A single coding or research task can easily consume tens or even hundreds of thousands of tokens as the agent plans, executes, evaluates and retries. Without careful controls, costs can grow much faster than most teams expect.
This is the trap. A loop that self-corrects is a loop that runs the model many times over for one task. Plan, that’s tokens. Execute, more tokens. Evaluate the result, more tokens. Fail, retry, and you pay for the whole cycle again. One task that a human would have done in a single prompt can turn into tens or hundreds of thousands of tokens once the agent is looping. And because it’s automatic, nobody’s watching the meter the way they would if they were typing each prompt by hand.
The autonomy that makes loops useful is the same thing that makes them expensive. A loop with no controls doesn’t just cost more, it can retry its way into a bill nobody signed off on. So the design work isn’t only about making the loop capable. It’s about putting limits on it. Retry caps. Budgets per task. A point where the system stops and asks a human instead of burning another hundred thousand tokens on its own. Building the loop and controlling the loop are the same job.