The Most Important Signal in Plain Sight
Pay attention to what the people who built these tools actually do with them. Not what they say in marketing copy. What they describe in talks, interviews, and technical posts about their own practice.
Several engineers and researchers behind Claude Code, OpenClaw, and similar tools have talked publicly about how they use their own products. The pattern is consistent. None of them describe carefully crafting prompts. None of them talk about prompt engineering as a skill they practice. What they describe is writing loops.
That gap between what the tools teach and what the builders do is worth taking seriously. It suggests that the layer most people are optimizing , the prompt , is not the layer that matters most.
Prompts Versus Loops: The Real Distinction
A prompt is a one-time instruction. You write it, the model responds, the interaction is over. Most people's mental model of AI usage is built around this pattern. Even "advanced" prompt engineering is still essentially about crafting better single instructions , more context, better formatting, clearer constraints.
A loop is different in kind, not just in degree. It is a repeating structure where the model's output in step N becomes the input to step N+1. The task is encoded in the structure itself. The model does not need to be told what to do on each step because the loop already handles that routing. The model handles the intelligence within whatever step it is currently on.
That distinction , task structure lives in the loop, intelligence lives in the model , is the operational form of something Andrej Karpathy has described in different terms. He talks about treating the model as a reasoning engine you set up for a task, not a search engine you query with keywords. Loops are how you actually implement that setup. They are the code form of the philosophy.
What Replaces the Prompt
Instead of a long system prompt explaining everything the model needs to know, builders who work this way write a for-loop with a schema. The model sees one step at a time. The schema constrains what the output can look like. The loop provides continuity between steps by managing state explicitly in code rather than relying on the model to remember the goal.
The prompts inside each step are short. Often a single sentence. The context comes from the loop state, not from elaborate instructions. The model does not need to be reminded of the overall objective at each step because the structure encodes the objective. The model's job at each step is narrow and clear.
This is what "not prompting anymore" actually means. It is not that there are no instructions. It is that the instructions are architectural , written in code, not in English prose. The few words the model sees at each step are almost incidental. The structure is doing the heavy lifting that a complex system prompt would otherwise need to do.
This also means the prompt's wording matters less. A slightly awkward phrasing inside a well-structured loop produces good results. A perfectly worded prompt in an ad-hoc single call is only as good as that one call. The structure is more durable than the wording.
Why This Matters for What You Learn
There is a large and growing market for prompt engineering education. Courses, frameworks, and guides on how to write better instructions, how to construct chains of thought, how to craft few-shot examples. Some of this is useful. None of it is where the experienced builders focus their attention.
If the people closest to these tools have moved past prompts to loops, that tells you something about where the real skill layer is. Prompt engineering optimizes a layer that the best practitioners have largely automated away. The use is in the loop architecture , how you structure the task, how you define the schema, how you handle failures, how you manage state between steps.
None of that is covered in a prompt engineering course. Most of it looks like software engineering with a model call in the middle, because that is what it is. The curriculum has not caught up with the practice. People are studying one layer while the builders are working on another.
Simpler Prompts in Better Structures
The practical takeaway is not "stop writing prompts." It is that the question changes. Instead of asking "how do I prompt this better?" you ask "how do I structure the loop so the model does not need sophisticated prompting?"
Those are very different optimization problems. The first one has you reading prompt engineering guides and testing variations. The second one has you thinking about input formats, output schemas, failure handling, and state management. The second problem produces systems that work reliably because the reliability comes from the structure, which does not drift the way language does.
Simple prompts inside good structures consistently beat complex prompts in ad-hoc calls. Not because simple is always better, but because the structure is doing the work the prompt was trying to do , and doing it more predictably. A schema enforces output format every time. A prompt that asks nicely for a certain format gets it most of the time. That gap matters at scale.
There is also a maintenance argument. When a loop breaks, you read the log and fix the specific step that failed. When a complex prompt stops working after a model update, you do not always know why. The prompt's behavior is implicit; the loop's behavior is explicit. Explicit systems are easier to maintain.
What to Actually Practice
If you want to build the way the builders build, the practice shifts. Stop spending hours refining system prompts for tasks that run in a loop anyway. Start building loops for simple tasks and learning what the structure needs to contain for the model to handle each step without additional guidance.
Pick one task you currently do with a single prompt. Write a loop for it: define the input format, break the task into steps, write a schema for each step's output, add a stop condition when something does not validate. Run it. The first version will probably be worse than your prompt. The tenth version will be more reliable and easier to debug than any prompt you have ever written.
The builders who work this way are not smarter than the people still writing prompts. They asked a different question earlier: not "what should I tell the model?" but "how should I structure the task so the model knows what to do at each step?" That question points at the loop. The loop is where the work actually lives. Everything else is commentary.
The Longer-Term Implication
There is a second-order effect to this shift that is easy to miss. As models get better, the intelligence-per-call improves. A well-structured loop benefits from that improvement automatically , each step gets smarter without any changes to the scaffolding. A carefully crafted prompt that depends on specific model behaviors can break when the model changes, because the behaviors you were prompting around may no longer exist in the new version.
This is already visible in practice. Teams that built prompt-heavy systems on earlier Claude versions have had to revise those prompts after each model update. Teams that built loop-based systems have had those same loops perform better with each model update, often without any changes at all. The structure is stable; the model improves inside it.
The builders who understood this early are ahead in a compounding way. Their systems improve each time Anthropic ships a better model. Their maintenance burden goes down over time, not up. The investment in loop architecture pays dividends that prompt investment does not. That is the deeper reason the builders stopped prompting. Not because prompts do not work. Because loops work better and keep working better.
The prompt is a thin layer.
The loop is the system.
Learn to build the system.