Most prompt engineering content is trivia that stops mattering the next model release. A small number of ideas underneath it are durable, and these are the ones I still use.
Prompt engineering advice ages badly on average, because most of it is really "here is a phrasing quirk of one specific model," and the quirk stops existing the moment that model is replaced. Underneath the trivia, though, there is a small set of ideas that have kept working across every model generation I have used them on, because they are not about phrasing at all — they are about how you structure the information you give the agent and how you design for what happens when it gets something wrong. Those are the ones worth keeping.
The first is scoping context instead of dumping it. The instinct with a model that has a large context window is to hand it everything relevant and let it sort out what matters, and that instinct is wrong more often than it is right. A model reasoning over ten carefully chosen files gives sharper answers than the same model reasoning over the whole repository, because relevance is itself information — handing over everything erases the signal of what actually matters to the task and forces the model to rediscover it. The practical version of this is deciding, before you write the prompt, what the agent actually needs to see rather than what it could see.
The second is designing for loud failure rather than trusting the model to flag its own uncertainty. Left alone, a model under-specified on a task will fill the gap with a plausible guess rather than stopping to ask, because a plausible guess is what its training rewards. The fix is not a cleverer instruction asking it to "say when you are unsure" — that helps a little and cannot be relied on. The fix is structuring the task so a wrong or incomplete answer is visibly wrong: a test that must pass, a schema the output must satisfy, a check that fails loudly rather than a human having to notice a subtly wrong answer three steps later. I would rather build one small verification step than write ten more careful sentences of instruction, because the verification step catches the failure the instruction could not prevent.
The third is stating the negative space, not just the goal. "Write a summary" underspecifies far more than it specifies — length, tone, what to exclude, what counts as done. "Write a summary, and do not include X, and stop at Y" removes an entire category of plausible-but-wrong output before the model ever produces it. This one sounds obvious written down and is the most commonly skipped in practice, because it takes a small amount of extra thought at the moment you are already impatient to just send the prompt.
What ties these together is that none of them are really about "prompting" in the sense people usually mean — clever phrasing, magic words, a specific sentence structure that unlocks better output. They are about information design: what the model sees, what counts as correct, and what happens when it is wrong. That is why they have survived several model generations for me while phrasing tricks have not. Phrasing is a property of one model's training. Information design is a property of the task, and the task does not change just because the model behind it did.
The content that keeps circulating instead — the "magic prompt" screenshots, the "I said please and it worked better" claims — is mostly noise sitting on top of these three ideas, dressed up as a bigger discovery than it is. I do not think that noise is malicious. I think it is just easier to screenshot a clever sentence than to explain why scoping the context, designing for loud failure and stating the negative space are the three things actually doing the work.