Probably, and I found out the embarrassing way: by discovering that half of mine had been doing nothing for months.
I had a document I was quietly proud of.
It was a prompt library. Years of accumulated technique, organized by use case, refined over hundreds of hours. Role framing at the top of every one. Chain-of-thought instructions. Few-shot examples. Careful formatting rules. The kind of thing that took a long time to build and that I referenced constantly.
A few weeks ago I ran an experiment I had been avoiding. I took eight of my most-used prompts and stripped them down to the bare instruction. No role framing. No step-by-step scaffolding. No examples. Just the task, plainly stated.
Six of the eight produced output that was indistinguishable from the full version. Two produced output that was better.
Here is the direct answer to the question in the title. Yes, your prompt library is probably out of date, and the reason is that most widely-taught prompt technique was developed for models that needed help the current models do not need. Andrew Ng made essentially this point in a recent Batch letter, noting that how we prompt in 2026 looks nothing like how we prompted in 2022. The specific test is simple: strip a prompt to its bare instruction, run both versions on the same real task, and compare. If the output is the same, everything you removed was ritual.
What follows is what I found underneath that, and it turned out to be a bigger problem than stale prompts.
Key Takeaways
- Much of the prompt technique in wide circulation was developed for earlier model generations and persists as habit rather than because it still improves output.
- The test for whether a prompt technique still earns its place is empirical, not theoretical: strip it out, run both versions on real work, and compare against a written standard.
- Andrew Ng’s recent Batch letter observes that prompting practice in 2026 has diverged substantially from the norms formed when ChatGPT launched in 2022.
- The same publication notes that coding agents accelerate different categories of software work at very different rates, which means blanket productivity claims obscure a wide spread.
- The deeper shift is that the unit of work moved from the prompt to the workflow, and a library of prompts is the wrong artifact to be maintaining.
I Was Maintaining A Museum
I want to be honest about why this took me so long to notice, because I think the reason is common.
Prompt technique had become identity. Knowing how to prompt well was a differentiator I had earned, and I had taught it. When something is both a skill you invested in and a thing you are known for, you stop testing it. Not deliberately. You just never get around to running the experiment that might tell you the skill has depreciated.
There was also a comfortable logic protecting the habit. Adding role framing and structure never seemed to hurt. Output came back good, and the prompt had scaffolding in it, so the scaffolding must have been contributing. That is not evidence. That is the same reasoning that keeps a lucky shirt in rotation.
And there was cost I was not counting. Every prompt with three paragraphs of preamble is three paragraphs I have to maintain, three paragraphs a team member has to read, and three paragraphs that make the prompt harder to modify. I was carrying maintenance weight for technique that had quietly stopped doing anything.
The uncomfortable part came after the test. Once I accepted that half my library was ceremony, I had to ask what the other half was actually for. And the answer was worse than I expected.
The prompts that still mattered were not doing prompting work. They were doing specification work. They encoded what I meant by good output, what constraints applied, what to do in ambiguous cases, and what never to do. That is not a prompt. That is a spec. I had been writing specifications and filing them as prompts, which meant they lived in a document nobody could execute, versioned by nothing, attached to no workflow.
I had built a museum of instructions when what my business needed was a set of running systems.
But what if the reason your AI output feels inconsistent has nothing to do with your prompt wording, and everything to do with the fact that a prompt was never the right container for what you were trying to preserve?
The Ground Moved And Most Of Us Did Not
Once I started looking, this pattern turned out to be well-documented by people who study it more rigorously than I do.
Ng named the drift directly. His recent Batch letter addresses how the ways we prompt in 2026 are very different from 2022 when ChatGPT came out. That is a mild sentence carrying a sharp implication. If practice has changed that much, then a large body of widely circulated advice describes a world that no longer exists, and the people repeating it are not lying. They are quoting a manual for a previous version.
The gains are wildly uneven, which nobody’s averages tell you. The Batch separately covered how coding agents accelerate different types of software work to different degrees. That is worth sitting with. When someone reports a large productivity number, they are reporting an average across categories with enormous variance. Some work gets dramatically faster. Some work gets marginally faster once you count review. Some work gets slower. Averages hide all of it, which is how people end up feeling like they are failing at something everyone else has figured out.
The tooling moved from prompts to workflows. This is the signal I find most persuasive, because vendors build for where the work actually is. Anthropic’s August releases included inference hooks that inspect prompts and tool calls before they reach the model, self-hosted environments for Claude Code, cross-session messaging, new sandbox controls, and the removal of the subagent spawn cap. Not one of those is about phrasing. Every one is about orchestration, governance, and persistence. Meanwhile Cowork expanded to mobile and web with background work and scheduled tasks, which is a statement that the work is expected to run while you are not there.
And the failure data points the same way. MIT found 95 percent of enterprise generative AI pilots produced no measurable return, with failures tracing to systems that did not retain feedback, adapt to context, or integrate with workflow. Nowhere in that diagnosis does prompt quality appear. The failures were structural.
Four signals, one conclusion. The conventional narrative says getting good with AI means getting good at prompting. The evidence says prompting was the entry-level skill of an earlier era, and the skill that pays now is designing work that runs.
Stop Collecting Prompts, Start Building Specs
What I did after that test was not glamorous, and it took longer than I expected.
I deleted most of the library. Then I took the handful of prompts that survived and rewrote them as something else.
Instead of a block of text I paste into a chat window, each one became a short specification with four parts. What goes in, including the context I had been supplying automatically without noticing. What constraints apply, including the ones I had never written down because they felt obvious. What acceptable output looks like, written concretely enough that someone other than me could judge it. And what happens when the input is ambiguous or missing, which is the part that separates something that works from something that works when I am watching.
That fourth part was the revelation. Every one of my old prompts assumed I would be there to notice when something was off. Writing down what to do without me was the difference between a technique and a system.
Two other things changed how I work.
The first was moving context out of the prompt entirely. Most of what made my long prompts long was business context I was retyping constantly: who we serve, what we sell, how we talk, what we will not do. That belongs in one document, attached once, rather than smeared across forty prompts where it drifts out of sync. When I consolidated it, my prompts got dramatically shorter and my output got more consistent, which is the opposite of what I expected.
The second was breaking single large prompts into inspectable steps. I used to have one prompt that did research, then analysis, then drafting. When the output was wrong I had no idea which stage failed. Splitting it into three steps I could look at between let me find problems in seconds that used to take twenty minutes of squinting.
I want to be fair to prompt technique, because I am not arguing it is worthless. Clear instructions still beat vague ones. Explicit constraints still matter, especially with smaller and cheaper models, which fill in fewer gaps than frontier models do. What has changed is that the technique is no longer where the leverage is. It is table stakes, and the leverage moved upstream into how the work is structured and downstream into how it is verified.
Practical Steps
1. Run the strip test on five prompts this week. Take your five most-used prompts. Remove everything except the core instruction. Run both versions on the same real task. Compare against a written standard, not a feeling. Expect to be a little annoyed by the results.
2. Write down what good output means before you evaluate anything. This is the step that makes the whole exercise honest. Without a written standard, you will unconsciously favor the version you spent more effort on. Five specific criteria is enough.
3. Pull your business context into one document. Everything you retype into prompts about your business, your customers, your voice, and your boundaries goes in one place. Attach it rather than repeat it. Update it in one place when it changes.
4. Convert your best surviving prompt into a spec. Inputs, constraints, definition of acceptable output, and what to do when information is missing. If you can only do one thing from this list, do this one.
5. Split a long prompt into inspectable steps. Take your most complex prompt and break it where you would naturally want to look at intermediate output. You are trading a small amount of convenience for a large amount of diagnostic ability.
6. Audit your prompt library for actual use. Anything you have not run in ninety days is a candidate for deletion. A library you do not use is not an asset, it is a filing obligation.
7. Change what you teach your team. If you are training people on AI, teach task decomposition, verification, and knowing when to escalate to a human. Those skills will still be worth something in three years. Specific phrasing tricks will not.
Frequently Asked Questions
Is prompt engineering dead?
No, but its scope has narrowed considerably. Clear instructions and explicit constraints still improve output, particularly with smaller or cheaper models that infer less. What has faded is the elaborate scaffolding built for earlier model generations. Treat prompting as a baseline competency rather than the main skill.
How do I know if a specific prompt technique still helps?
Test it. Run the same real task with and without the technique, score both against a written standard, and repeat across several inputs so you are not judging on a single lucky run. If output quality is indistinguishable, the technique is habit.
Should I delete my whole prompt library?
Not blindly. Run the strip test first, then keep the prompts that encode genuine business knowledge, constraints, or quality standards. Convert those into specifications with inputs, constraints, acceptance criteria, and ambiguity handling. Delete the rest without ceremony.
What replaces a prompt library?
A context document plus a set of documented workflows. The context document holds everything about your business you were retyping. The workflows define sequence, checkpoints, quality checks, and escalation. Together they do what a prompt library was pretending to do.
Does this mean the time I spent learning to prompt was wasted?
No, and I would push back on that framing. Learning to give precise instructions and define acceptable output is exactly the skill that transfers to workflow design. What expired was the specific technique, not the underlying discipline of thinking clearly about what you actually want.
The Close
Six of eight. That is the number I keep thinking about.
Six prompts I had refined over years, and stripping them to the bare instruction changed nothing. Not because the work I put in was foolish at the time, but because the ground moved under a habit I had stopped examining. I was still solving a problem that had been solved for me quietly, in a release note I skimmed, in a model update I did not think much about.
I think that is the real lesson, and it is not about prompts at all. In a field moving this fast, the most expensive thing you own is a skill you have stopped testing. Not a wrong belief, which you would notice. A belief that used to be right, which you would not.
So here is the question I would ask you to sit with, because it is the one that cost me the most. What are you still doing carefully, and well, that nobody needs done anymore?
Test the thing you are proudest of first. That is where the stale stuff hides.
About the author
Jonathan Mast is the founder of White Beard Strategies and writes about what actually happens when entrepreneurs put AI to work, including the parts that do not flatter him. He deleted most of a prompt library he spent years building and considers it one of the more useful weeks he has had. He is still finding things he was doing out of habit.
Sources referenced: The Batch by DeepLearning.AI, Andrew Ng’s letters on prompting practice and coding agent productivity; Anthropic August 2026 release notes; MIT GenAI Divide research on enterprise pilot outcomes.