The Prompt Is Dead. Long Live the Loop.

Every major shift in software changes the unit of engineering.
I believe we're watching it happen again.

Software engineering has always evolved through abstractions.

We rarely notice the transition while we're living through it.
We optimized assembly language right before compilers made hand-tuning irrelevant.
We perfected object hierarchies just before services became the architectural boundary that mattered.
We spent years debating XML while APIs quietly became the interface of modern software.

Each transition looked like incremental improvement until, in hindsight, it was obvious that the abstraction had changed.

I think we're watching the same thing happen with AI.

Today the conversation revolves around prompts, system prompts, and increasingly, skills.

Those are all valuable advances.

But I don't think they're the destination.
I think they're evidence of something much larger.
The abstraction is moving again.

And the clearest sign is a question that's been quietly changing under our feet: we used to ask what should the model do? Now the systems that actually work are organized around a different question — what should happen next? Answering it well turns out to be something humans are bad at and agents are not. Hold onto that; it's where this ends up.

Phase One: Prompt Engineering

The first generation of AI engineering revolved around prompts.

Success meant finding the right wording, examples, and structure to coax better behavior from increasingly capable language models.

The prompt became the application.
As systems became more sophisticated, prompts absorbed more responsibility.

Business rules.
Formatting.
Guardrails.
Reasoning strategies.
Workflows.
Exception handling.

Entire applications slowly collapsed into giant blocks of text.
It worked remarkably well.
Until it became impossible to manage.

Phase Two: Skills

Skills emerged because prompts became too large.

Instead of one massive system prompt, we decomposed behavior into reusable capabilities.

A research skill.
A debugging skill.
A code review skill.
A migration skill.

This is a genuine improvement.
Skills introduce modularity.

Versioning.
Ownership.
Documentation.
Testing.
Reuse.

They solve many of the problems prompt engineering created.
But notice something interesting.

We're still thinking in terms of prompts.
We've simply broken one giant prompt into many smaller ones.

Skills aren't replacing prompts.
They're reorganizing them.

Phase Three: Loop Engineering

The next abstraction is already emerging.

The important question is no longer: "What prompt should I write?"

It's becoming: "How should the system decide what happens next?"

That's a fundamentally different problem.
Every successful autonomous system is built around a loop.

Observe.
Decide.
Act.
Evaluate.
Adjust.
Repeat.

Skills simply become one implementation detail inside that loop.

The progression becomes much clearer when viewed through the lens of abstraction.

Prompts tell a model what to think.
Skills tell it how to perform a task.
Loops decide what happens next.

Each layer builds on the previous one.

Prompts gave us intelligence.
Skills gave us reusable capability.
Loops give us autonomy.

That's why I don't believe skills are the destination.
They're the bridge between prompt engineering and loop engineering.

The prompt is no longer the application.
The loop is.

Ask yourself what actually determines whether an autonomous system succeeds.

It isn't the wording of the prompt.
It's whether the system can repeatedly:

Observe reality.
Decide what to do next.
Execute an action.
Evaluate the outcome.
Adjust its behavior.
Know when to stop.

That's a loop.

Skills simply make one step inside that loop more reliable.

The same way functions never became software architecture, skills won't become agent architecture.
They're building blocks.
The loop becomes the architecture.

Software engineering has always been organized around abstractions.

First it was: Function → Class → Service
Then it became: Service → API → System
Now I believe it's becoming: Loop → Workflow → System

That changes what we teach.
For years we've asked engineers questions like:

Can you write clean code?
Can you design a good API?
Can you structure a maintainable service?

Those skills still matter.
But they're no longer sufficient.
Tomorrow's engineers will need to answer different questions.

Can you design a loop that converges?
Can you define what "done" actually means?
Can you create evidence that the system is improving?
Can you ensure the loop optimizes the right outcome?
Can you recover gracefully when the loop fails?

Those aren't traditional software engineering questions.
They're much closer to systems engineering and control theory.

A Loop, Up Close

Abstractions are easy to nod along to and hard to feel. So here's one running.

When I was building HydraFlow — and by building I mean designing the loop and letting it construct itself — I watched a fix loop fail to converge, and that was the more useful thing to watch. It read a failing test, patched the obvious suspect, ran the suite, and a different test went red. So it patched that. By the fourth iteration it was modifying tests that had been passing when it started, each change dragging the suite further from green.

I didn't write HydraFlow — I specified how its loops should behave and it self-built the rest. That's the whole point. The patches weren't the problem; several were locally reasonable. What was missing was a loop that could recognize it was diverging and refuse to continue. The system's output was fine. The control I'd designed into it wasn't yet. That gap is the work now.

It would have kept going. The only reason it stopped was a stopping condition I'd built into the loop's shape. Left unbounded, it would have happily burned tokens chasing its own tail, because nothing in the loop knew the difference between progress and motion.

That's the part you engineer now. Not the wording. The convergence.

Loops are not new.

Control systems, robotics, cybernetics, distributed systems, and operations engineering have relied on feedback loops for decades.

What is new is where the loop now operates.
Historically, software loops were mostly runtime mechanisms.

Retry logic.
Message processing.
Monitoring.
Autoscaling.
Incident response.

Now the loop is moving into the creation and modification of software itself. I recently gave a talk on this at GOTO: Accelerate in Chicago.

That changes the engineering problem.
We're no longer only designing systems that execute instructions.
We're designing systems that observe outcomes, update behavior, and participate in their own improvement.

Loops Become the New Design Pattern

Just as object-oriented programming gave us reusable design patterns, loop engineering is beginning to develop its own.

Fix loop: detect → patch → test → judge → retry
Research loop: search → summarize → verify → cite → stop
Review loop: inspect → critique → rank risk → suggest fix
Migration loop: transform → compile → compare → approve

These aren't prompts!
They're repeatable control systems.

LLMs make the loop expressive enough to operate at the level of requirements, code, tests, review, migration, documentation, and decision making.

Eventually I expect we'll have libraries of proven loops the same way we have libraries of software patterns today.

Why TDD Never Quite Landed

This perspective also explains something that's bothered me for years.

Most engineers never fully embraced Test Driven Development.
Not because feedback loops were a bad idea.

Because humans are terrible at living inside rigid loops while simultaneously creating something new.
Agents aren't.
That's the loop it spiraled through above, run patiently instead of grudgingly.

An autonomous system doesn't mind generating an evaluation, running it hundreds of times, measuring progress, refining itself, and repeating the cycle until it converges.

The principle behind TDD was never really: "Write tests first."

It was: Make correctness executable.
That idea suddenly becomes practical when the builder isn't human. The discipline we couldn't make ourselves keep is the one agents keep effortlessly — which is exactly why the loop, not the prompt, is the thing worth designing.

The Absorption Gap Is a Loop Gap

This shift is also why so many organizations feel stuck.

The models are capable enough.
The demos are impressive enough.
The opportunity is obvious enough.

And yet transformation still feels slow.
That is the AI absorption gap — and at root, it's a loop gap. Organizations don't fail because the models are too weak. They fail because they lack the loops required to absorb that capability into daily work.

They lack:
Evaluation loops.
Governance loops.
Workflow loops.
Escalation loops.
Feedback loops.

A prompt can generate an answer.
A skill can perform a task.
A loop changes how work gets done.

Capability overhang creates pressure.
Absorption capacity determines who captures it.

Conway's Law Comes for AI

Conway's Law tells us that systems tend to mirror the communication structures of the organizations that build them.

Agentic systems add a new wrinkle.
As organizations adopt autonomous workflows, they will not only ship systems that reflect their org chart.
They will begin reshaping the organization around the loops they operate.

The customer support loop.
The compliance loop.
The migration loop.
The research loop.
The sales qualification loop.
The software delivery loop.

This is where AI stops being a tool adoption problem and becomes an operating model problem.

If a loop is how work gets done, then owning the loop becomes a new form of organizational responsibility.

That means engineering teams will not only own services.
They will own the behavior of autonomous systems over time.

What We Should Actually Teach

Prompt engineering is becoming an implementation detail.

The durable engineering skills are changing.
Tomorrow's engineers need to understand:

Goal decomposition
State management
Context management
Decision loops
Evaluation design
Guardrail design
Recovery strategies
Cost and latency tradeoffs
Human escalation

Those are the equivalent of data structures and algorithms for agentic systems.
Notice what's missing.
Prompt wording. That's because prompts become one implementation detail inside a much larger architecture.

Today's conversation revolves around skills.
How should we write them?
How should we version them?
How should we organize them?

Those are useful questions.
They're also the wrong level of abstraction.

It's like arguing about the perfect class hierarchy in 2005 while service-oriented architectures were quietly emerging.

Skills matter.
But what matters far more is:
Who decides to invoke them?
How are results evaluated?
How does context evolve?
How does the system decide what happens next?
That's loop design!

The Next Engineering Discipline

Every major shift in software changes what engineers optimize.

We optimized functions.
Then classes.
Then services.
Then APIs.

Today we're optimizing prompts and skills because that's where the tooling is.
Tomorrow we'll optimize loops.

The engineers who thrive won't be the ones with the cleverest prompts or the largest library of skills.
They'll be the ones who can design systems that reliably converge toward the right outcome.

Systems that know when to continue.
When to ask for help.
When to stop.

Within three years, I don't think engineering teams will primarily organize their AI work around prompts, chatbots, or isolated copilots.
They'll organize around production loops.

The customer support loop.
The research loop.
The migration loop.
The compliance loop.
The software delivery loop.

Code will still matter.
Services will still matter.
APIs will still matter.

But the primary artifact engineers own will increasingly be the behavior of an autonomous system over time.

Five years from now, "prompt engineer" will sound as dated as "AJAX developer."
Not because prompting disappeared.
Because it became an implementation detail inside a larger engineering discipline.

We won't hire prompt engineers.
We'll hire engineers who can design reliable, self-correcting systems.
In a world of autonomous software, the most important question isn't: "What should the model do?"
It's: "What should happen next?"

That's no longer prompt engineering.
It's loop engineering.
And I believe that's the next software abstraction.

Footnotes

1. Author's Note

This essay builds on a series of essays I've written over the past 18 months exploring agentic systems, including AI Decision Loops, AI Coherence: Meaning for Patterns not Memory, FLUID (Mutable by Design), The AI Absorption Gap, and the HydraFlow experiment, along with conference talks on self-building software and reliable agentic delivery. While each explored a different aspect of autonomous systems, they consistently pointed toward the same conclusion: reliable AI systems are increasingly defined by how they observe, decide, act, evaluate, and adapt over time.

2. Alignment with Industry Trends

The shift is happening now.
Across the industry, the conversation is moving from prompts toward workflows, evaluations, tools, memory, skills, and orchestration.
Different names, same direction.
The bottleneck is no longer just model capability.
It is turning that capability into reliable systems of work.
That requires loops. And control systems.
Not pretty syntax or perfect abstractions.