Prompt Engineering Was the Beginning, Not the Skill
It got named as a discipline when the prompt was the entire interface. It's now one input among several — and if better prompts have stopped helping, five specific things are usually why.
Prompt engineering got named as a discipline early, because for a while it was most of what you could control. With a model, a text box, and no tools, the prompt was the entire interface.
Agent systems changed the ratio. The prompt is still there and still matters, and it's now a small fraction of what determines whether the thing works — which is confusing for people who learned the earlier version and are finding that better prompts have stopped helping.
What prompts still do well
Establish role and scope, including what's out of scope.
State standing constraints that require judgment and can't be expressed as code.
Define output requirements where the model has genuine latitude.
Say what to do under ambiguity or failure — the most underused prompt section, and the one that most changes behavior.
Supply domain vocabulary the model can't know.
That's a real list and it's roughly a page of text.
What prompts can't do, that people keep asking them to
Enforce anything. A prompt is advice weighed against everything else in context. "Always format dates as ISO" is a request; a formatter is a guarantee. ⚠️ The clearest sign a team is stuck in prompt-first thinking is a system prompt full of "always" and "never" statements for things that are mechanically enforceable.
Supply missing information. If the deciding fact isn't in the array, no instruction makes the model use it. This is the most common wasted effort in agent work — repeated prompt edits aimed at a context problem.
Fix tool descriptions. Instructions in the system prompt about when to use which tool are in the wrong place. They apply on every turn, including when the tool isn't offered, and they drift out of sync when the tool changes.
Overcome bad result formatting. A tool returning an ambiguous empty array will be misread regardless of prompt.
Substitute for verification. "Be accurate" does nothing. A check does.
The reordering
If prompts are one of several inputs, the effort ranking changes:
- Tool design — descriptions, granularity, result shapes, error semantics.
- Verification — the oracle, the checks, the eval set.
- Context assembly — what's in the array, where, how stable.
- Loop semantics — termination, budgets, partial results, escalation.
- Prompt.
→ A pattern people notice when they do this: the prompt gets shorter. A significant share of a long system prompt is usually compensating for a weak tool surface or an assembly problem, and it becomes unnecessary once those are fixed.
What transfers from prompt engineering
The skill wasn't wasted. What carries over:
Precision about instructions. Knowing that "handle errors appropriately" means nothing and "on a 429, wait and retry once; on a 404, report the ID as not found" means something. That precision now goes into tool descriptions and error strings.
Anticipating misreading. Predicting how an instruction could be taken wrongly is the same skill applied to schemas and tool descriptions.
Iterative testing. The habit of changing one thing and measuring. This is the transferable core, and it's what turns into eval discipline.
Understanding what models find hard. Long instruction lists, implicit constraints, tasks requiring noticing something is absent. That intuition is more valuable now, applied to design rather than to wording.
✅ The practical test
If you're changing the prompt repeatedly and behavior isn't improving, stop and ask which of these is true:
- The information isn't in the array → context problem.
- The tool description is ambiguous → tool problem.
- The result shape is misleading → tool problem.
- There's no check → verification problem.
- The rule is mechanically enforceable → put it in code.
Most stuck prompt-tuning sessions are one of those five, and the prompt is the wrong lever for all of them.
The takeaway
Prompt engineering was named when the prompt was the whole interface, and it's now one input among several. Use it for role, standing constraints, output requirements, ambiguity handling, and vocabulary — about a page. Everything else belongs in tools, context, checks, or code. The precision and testing habits transfer; the instinct to fix problems by rewording does not.