Prompting is not programming. Orchestration is.

Every team's first month with AI is prompt worship. A better prompt produces a visibly better demo, so tuning prompts feels like engineering progress. It is not. A prompt has no error handling, no state, no memory of past failures, no way to escalate. You are tuning a single call to a stochastic function and mistaking the tuning for architecture.

The ceiling arrives fast. Past a modest threshold, clever wording buys marginal gains, and the next model release moves the ceiling anyway. I have watched teams polish prompts for months that a plain verify-and-retry loop beat in a week.

For fifty years the unit of engineering was the function: deterministic input to deterministic output, composable, unit-testable. The agent loop keeps the rigor and changes the shape. A loop plans, acts through tools, observes results, decides whether to retry, escalate, or proceed, and persists state across steps — sometimes across days.

Every consequential design decision now lives in the loop, not the prompt. Which tools does the agent get, and under which permissions? Where are the human checkpoints? What is the retry policy, and what triggers escalation? What state survives a restart? What gets logged so the trajectory can be read later? These are architecture questions. They have wrong answers, and the wrong answers reach production.

The disciplines that made software reliable do not disappear. They re-aim. Testing becomes evals: golden tasks, failure taxonomies, statistical acceptance thresholds instead of assertions. Error handling becomes recovery policy: not catching exceptions, but deciding what an agent does with a wrong answer it believes. Code review becomes trajectory review: reading the transcript of what the agent did and why. Observability becomes the craft of making agent decisions legible after the fact.

This is good news for engineers. The profession transfers almost one to one; only the object changed. The people at risk are not programmers. They are prompt collectors.

The strongest counterargument: models absorb the loop. Each generation plans better, self-corrects better, and needs less scaffolding — so orchestration is just prompt engineering with extra steps, obsolete on the same schedule. Half of this is true. Models do absorb the generic loop: decomposition, retry, self-critique. Build elaborate scaffolding for those and you are writing code with an expiration date.

What models cannot absorb is your loop: your tools, your permission boundaries, your human checkpoints, your definition of done. That context lives outside every foundation model by construction. The loop gets thinner every year; it does not disappear. And the team that owns the loop owns the evals — which is where an enterprise's trust in the system actually lives.