For two years we taught developers how to write prompts.
We created template libraries. We shared hacks on Twitter. We designed frameworks like CRISPE, Chain-of-Thought, and ReAct. Entire courses, consulting firms, and job positions emerged around prompt engineering.
But something interesting is starting to happen.
The teams building the most advanced agents on the market — Anthropic among them — suggest that the era of manually written prompts could be coming to an end.
Not because prompts stop mattering.
But because more and more agents are starting to generate, refine, and correct them by themselves.
Boris Cherny, one of the leaders behind Claude Code, recently described this transition as the shift from prompt engineering to loop engineering.
The idea is simple.
The developer stops writing detailed step-by-step instructions.
And starts designing the system that produces those instructions automatically.
That change seems subtle.
It’s not.
It’s probably one of the most important architectural shifts we’ll see in AI-assisted engineering over the coming years.
The limits of prompt engineering
The first generation of LLM applications was built around a simple premise:
A human writes a prompt.
The model responds.
End of story.
Even the most sophisticated systems still functioned essentially the same way:
User → Prompt → Model → Response
The problem appears when you try to scale autonomy.
An agent that must:
- explore a large repository,
- execute tools,
- plan multi-hour tasks,
- fix errors,
- validate results,
- adapt to unexpected changes,
can’t rely solely on an initial prompt written by a human.
The reason is obvious.
We humans don’t know in advance all the situations that will appear during execution.
A sufficiently autonomous agent needs to constantly reinterpret its objectives.
It needs to create new instructions for itself.
Agents are already self-prompting
In fact, this is already happening.
When you use tools like Claude Code, Codex, OpenCode, or Gemini CLI, the prompt you write is rarely the prompt that actually reaches the model.
Your original instruction usually goes through multiple layers:
User
↓
Initial prompt
↓
System prompt
↓
Persistent memory
↓
Retrieved context
↓
Available tools
↓
Specialized subagents
↓
Dynamically generated internal prompts
↓
Model
Most of these instructions are never seen by the user.
For example:
- An agent can automatically rephrase an ambiguous task.
- It can generate an intermediate execution plan.
- It can create subtasks for specialized subagents.
- It can summarize old context.
- It can generate verification prompts.
- It can ask another model to critique its own response.
All of that are prompts.
They just weren’t written by a human.
From prompt to loop
This brings us to the central concept.
The new object of design is no longer the prompt.
It becomes the loop.
A typical agentic loop might look like this:
Human objective
↓
Planning
↓
Execution
↓
Observation of result
↓
Evaluation
↓
Reflection
↓
Plan adjustment
↓
New execution
Each iteration produces new instructions.
Each observation modifies future behavior.
Each failure generates corrective prompts.
The important thing is no longer writing the perfect instruction.
It’s designing the mechanism by which the system learns to produce better instructions with each cycle.
A concrete example
Let’s imagine a classic workflow:
“Migrate this service from Express to Fastify.”
In a traditional prompt engineering paradigm, we’d try to describe everything from the start:
Migrate the entire project.
Preserve compatibility.
Update tests.
Don't break endpoints.
Use TypeScript.
Generate documentation.
The result is usually inconsistent.
Because the actual task contains hundreds of emerging decisions.
In a loop-based system:
Iteration 1
The agent:
- inspects the code,
- estimates complexity,
- identifies risks.
Generates internally:
First identify custom middleware and critical dependencies.
Iteration 2
It finds incompatibilities.
Generates:
Create specialized subagent to review authentication.
Iteration 3
Tests fail.
Generates:
Review semantic differences between Express middleware and Fastify hooks.
Iteration 4
The system detects regressions.
Generates:
Request critical review on backward compatibility.
The human never wrote any of those prompts.
They designed the loop.
The role of the developer changes
This has profound consequences for AI Builders.
The work stops consisting mainly of:
- optimizing wording,
- experimenting with phrasing,
- adjusting temperature,
- testing small prompt changes.
It starts consisting of designing:
Objectives
What does success mean?
Constraints
What things can the agent never do?
Tools
What capabilities does it have available?
Memory
What should it remember between iterations?
Evaluation
How does it know if it’s making progress?
Policies
When should it stop?
Escalation
When should it ask for human help?
This shift brings agent development much closer to systems engineering than to creative writing.
Architecture starts to matter more than the model
In this new world, two teams using exactly the same model can obtain radically different results.
The difference will be in:
- the quality of the loops,
- the evaluation mechanisms,
- observability,
- recovery policies,
- memory,
- available tools.
This helps explain why the market is moving toward the concept of harness.
The model becomes an interchangeable piece.
The loop becomes the product.
New emerging patterns
Reasonably stable patterns are already starting to appear.
Plan → Execute → Reflect
The agent plans, executes, analyzes results, and adjusts.
Critic Loops
A second agent evaluates the first one’s output.
Self-Refinement
The agent itself reviews and improves its work before delivering it.
Multi-Agent Delegation
Specialized agents receive specific subtasks.
Adaptive Context
The system dynamically decides what information to load.
Escalation Loops
When uncertainty exceeds a certain threshold, a human intervenes.
These patterns will likely become the new basic abstractions in agentic engineering.
What teams should do today
You don’t need to wait for AGI to prepare.
Some practical recommendations:
1. Design workflows, not isolated prompts
Think in terms of states, transitions, and feedback.
2. Separate intention from execution
The human defines objectives.
The system decides implementation.
3. Invest in observability
You need to understand what internal prompts the system generates.
4. Measure complete loops
Don’t evaluate individual responses.
Evaluate complete tasks.
5. Define explicit policies
Every loop needs clear boundaries.
6. Design mechanisms for human intervention
Total autonomy is still the exception.
The future of prompt engineering
Will prompt engineering disappear?
Probably not.
But its level of abstraction will change.
Explicit prompts will continue to exist.
They’ll just stop being the center of the system.
The way nobody programs in assembly to build web applications today, probably in a few years few teams will spend their time manually optimizing individual prompts.
They’ll design loops.
They’ll design evaluators.
They’ll design policies.
They’ll design systems capable of generating their own instructions.And that represents an important transition.
Because it means the dominant discipline stops looking like writing.
And it starts to look, once again, like engineering.
By Grego — yoDEV