I kept a prompt swipe file longer than I want to admit.
It had the usual artifacts: personas, careful preambles, little phrases that seemed to make the model behave better. "Act as a senior engineer." "Think step by step." "Be exhaustive." At the time it felt like craft. I had found the secret handshake.
Now the file mostly embarrasses me.
Not because prompting stopped mattering. Because most of what I called prompting was a workaround for weaker models, and the workaround aged badly. The more interesting thing is what replaced it. The work did not vanish. It moved.
The old unit was the prompt.
The new unit is the loop.
That is why the recent "loop engineering" language lands. It names something a lot of us were already doing badly: trying to fix agent behavior by polishing one more sentence, when the real failure was outside the sentence entirely.
The part that actually died
Prompt engineering as incantation is dead enough that we should stop pretending otherwise.
If a model needs to be flattered into competence, you have a weak model or the wrong task. If the difference between success and failure is whether you wrote "take a deep breath," you are not engineering. You are shaking the vending machine and giving the shake a methodology name.
Reasoning models made this obvious. The scaffolding we used to hand-build — decomposition, self-checking, intermediate reasoning — moved inside the model. Some older tricks are now neutral. Some make outputs worse. The private dialect of prompt-maxxing became a tax.
This is the part Team Prompt-Is-Dead gets right. The swipe-file era is over. Delete the magic phrases. Stop collecting charms.
But that does not mean the work got easier. It means the embarrassing part got removed, leaving the harder part exposed.
The mistake I kept making
Here is the mistake I made with agents: I tried to repair loop failures with prompt edits.
An agent would keep going after the task was obviously done, so I added another sentence: "Stop when complete."
It would take one risky step too many, so I added: "Be careful."
It would call a tool, get a weird result, and improvise past it, so I added: "Verify your work."
Those sentences are not useless. They are just weak controls. They are the software equivalent of writing "please do not crash" in a comment above unsafe code.
The real fixes were boring and structural:
a stop condition the agent could not negotiate with,
a check after the tool call,
a narrower permission boundary,
a retry limit,
an escalation path when the result looked wrong,
a log that let me reconstruct what happened without trusting the agent's summary.
None of that is a better prompt. All of it changes what the prompt means.
That is the shift. Prompt discipline survives, but it stops being about phrasing and starts being about the system around the phrasing.
A prompt is a brief; a loop is an operating model
A prompt was never a spell. It was always a brief.
A good brief says: here is the goal, here is the context, here are the constraints, here is what done looks like, here is what not to do, and here is when to come back because the brief is insufficient.
That skill still matters. It may matter more than before. A capable model will happily do the wrong thing with more polish than a weak model. Ambiguity does not disappear when the model improves; it just gets executed more confidently.
But agents add a second layer.
A loop says: here is when to ask the model, here is what context to give it, here are the tools it may use, here is how to observe the result, here is how to validate the result, here is when to retry, here is when to refuse, here is when to stop.
The brief tells the model what you intend.
The loop decides whether the model's actions are allowed to count as progress.
That distinction matters because most production failures are not caused by one badly worded sentence. They are caused by a sentence being treated as a control system.
The three modes I use now
I do not use the same discipline everywhere anymore. That was another source of self-inflicted ceremony.
For throwaway chat, I am lazy on purpose. I ask in one or two direct sentences. No persona. No preamble. No fake formality. If the answer is wrong, I correct it or move on. Over-engineering a disposable question is its own kind of cargo cult.
For reusable work, I write the brief. Anything I expect to run again gets intent, context, constraints, examples of success, examples of failure, and an owner. At that point the prompt is not a chat message. It is a small spec.
For agentic work, I design the loop. The prompt is only one node. The loop needs a tool policy, memory boundary, validation step, retry rule, refusal path, stop condition, and audit trail. If those are missing, I do not have an agent. I have a confident intern with shell access.
That last sentence is the one I wish more teams would say out loud.
The industry keeps debating whether people are good at prompting. The more urgent question is whether their systems know what to do after the prompt fails.
Five checks before I trust the loop
When I look at an agent workflow now, I do not start by reading the prompt. I start with the failure surfaces.
What can the agent see? Context engineering is not stuffing more text into the window. It is deciding what gets retrieved, what gets excluded, what is stale, and what the model is forbidden to infer.
What can the agent touch? Tool access is part of the prompt whether you admit it or not. A broad permission boundary turns every ambiguity into blast radius.
What checks the step? "The model will review its own work" is not a control. A schema, a test, an assertion, a diff, a human checkpoint, or a cheap evaluator is a control.
What happens on the second failure? One retry is often useful. Infinite retries are just a model turning uncertainty into compute spend. The loop needs a stuck state.
What does refusal look like? A useful agent must be able to say no, not enough context, out of bounds, unsafe, or needs human review. If refusal is not first-class, the agent will improvise confidence.
Notice what is missing from that list: clever wording.
Wording still matters. It just no longer deserves to be the center of the architecture.
The uncomfortable career part
This is also why "prompt engineer" was a strange job title and "prompt discipline" is still a valuable skill.
The dead version was knowing a model's secret handshake.
The living version is knowing how to brief a capable executor and build the conditions under which the executor's work can be trusted.
That is closer to management, product, QA, security, and systems design than to copywriting. It is older than LLMs. Good teams have always needed people who can say what they want, define what done means, spot ambiguity before it ships, and create a feedback loop that turns work into evidence.
The model made that skill more visible because the model will not rescue you from vagueness. It will scale it.
Where I land now
I would not tell a team to hire for prompt engineering.
I would tell them to hire for loop discipline.
Can this person write a clean brief? Can they choose the context? Can they design the check? Can they name the blast radius? Can they define when the agent should stop? Can they look at a failure and know whether the fix belongs in the prompt, the retrieval layer, the tool boundary, the validator, or the product requirement?
That is the job.
Sometimes the fix is a sentence. Often it is not.
The prompt is where intent enters the system. The loop is where intent is forced to survive contact with reality.
Stop polishing prompts. Design the loop.
Next time: if the brief lives in the loop, the obvious next question is whether you can ever teach the model for good — whether knowledge belongs in the weights, in retrieval, or in the system around both.