Prompt engineering, and the part that is really specification
Most prompt engineering is not a set of tricks but the ordinary work of specifying a problem precisely, which is why the techniques keep expiring while the skill of stating clearly what you want, what you have, and how the result will be judged keeps working.
Prompt engineering started as a collection of tricks: phrasings that got better answers, formats that survived, incantations passed between people who had found them by accident.
Why the tricks keep expiring
Every phrasing that reliably improved answers a year ago was a workaround for something the model could not yet do. As models improve, those gaps close and the workaround becomes noise, or occasionally makes things worse. Anything you learned that was specific to a model version has a short shelf life, and treating a collection of them as expertise is how people end up defending habits that stopped helping.
What does not expire
Saying what you actually want. What you already have. What the output will be used for. How you will know whether it is right. Those four are not prompt engineering, they are specification, and they are the same four things that make a brief to a person useful. A model that misunderstands an ambiguous request is usually not failing; it is answering a different question competently.
The single highest-value habit
State how the result will be judged, in the prompt. Not because it makes the model try harder, but because writing it forces you to decide, and half of unclear outputs come from requests where the asker had not settled what good looked like. If you cannot write the acceptance test, the problem is upstream of the prompt.
Where prompting stops and tooling starts
There is a class of failure no phrasing fixes: the model does not have the information. It cannot know your current balance, today's price, or what your codebase does, and asked anyway it will produce something plausible. The fix is not a better prompt, it is giving it a way to look. That boundary is worth recognising early, because time spent rewording a request for information the model does not hold is time entirely wasted.
Why the boundary is easy to miss
A model without the facts does not say so. It produces a confident, well-formatted answer of exactly the shape you asked for, and the only clue is that the numbers are wrong. That is why connecting a model to something real matters more than any phrasing: a source that can contradict it turns an invisible failure into an obvious one.
Live, right now, on this page
| Market | Price | Funding | 24h volume |
|---|---|---|---|
| BTC | $76,845.50 | 0.0013% | $512,540,036 |
| ETH | $2,390.55 | 0.0013% | $284,004,266 |
| SOL | $99.06 | 0.0013% | $77,565,578 |
| HYPE | $81.50 | 0.0007% | $12,355,876 |
Read from a live market as this page rendered, through a public endpoint that needs no key. Read at 2026-09-02 09:22 UTC; accurate as of that time and not afterwards.
Describe something and watch it get built.
Open the builder, or start from a working app and change it.