Is Prompt Engineering Still Worth Learning in 2026?

I typed a version of this question into a search bar myself about six months ago, half expecting a straight answer and getting a shouting match instead. IEEE Spectrum says the discipline is dead. Forbes runs one piece in January saying it isn't the most valuable AI skill, then another in June insisting reports of its death are premature. dev.to has a whole post walking through what replaced it, written like an obituary with footnotes.

Here's the honest read after going through the actual research, the job data, and what the people arguing both sides are actually claiming: they're not disagreeing about the facts. They're using the same word, "prompt engineering," to mean two different things, and the answer changes completely depending on which one you mean.

What does "prompt engineering is dead" actually mean?

It means one narrow, specific thing died: the 2023-era practice of hunting for a magic phrase that squeezes a few extra points of accuracy out of a model. Add "take a deep breath and think step by step." Offer the model a fake $200 tip. Tell it to pretend it's a world-class expert. Those tricks worked, for a while, because early models were inconsistent enough that phrasing mattered more than it should have.

They don't work the same way anymore, mostly because model builders trained the tricks directly into the defaults. A model that's been reinforcement-tuned against the "think step by step" pattern doesn't need you to ask for it. A trick that gets trained into the model's default behavior stops being a trick and starts being table stakes. That's not a controversial claim. It's the one thing every article in this debate agrees on, whether the headline says "dead" or "not dead."

What people disagree about is what to call everything that's left: writing a clear instruction, giving a model the right supporting information, chaining several AI calls into a working system, checking whether the output is actually correct. Some writers keep calling all of that "prompt engineering," just evolved. Others insist it deserves a new name because it's a genuinely different job. Both camps are describing the same underlying work.

Why are IEEE Spectrum, dev.to, and Forbes all writing this in 2026?

Because the debate never actually resolved, it just kept getting new evidence thrown at it every few months, which is exactly the kind of unresolved, search-driven question that keeps generating fresh headlines. IEEE Spectrum's piece, reported by Dina Genkina, first ran in 2024 and still gets cited constantly in 2026 arguments because its core finding held up: researchers at VMware and Intel Labs found that automated tools which let a model generate and test its own prompts consistently beat prompts written by hand.

VMware's Rick Battle ran the experiment that's quoted most often. His team tested open-source models against dozens of prompt variations and found the automated search process turned up combinations no human would have guessed. He described the moment plainly: "I literally could not believe some of the stuff that it generated." He was even more direct about what hand-crafting a prompt had started to feel like by comparison: "You're just sitting there trying to figure out what special magic combination of words will give you the best possible performance." Read the full IEEE Spectrum piece here.

Not every researcher in that same article agreed the job was finished. Tim Cramer at Red Hat pushed back on the framing, telling Spectrum: "I think there are going to be prompt engineers for quite some time, and data scientists." Two years and one debate cycle later, both predictions turned out partly right. The trial-and-error version of the job Battle described is largely gone. The broader role Cramer meant, someone responsible for getting reliable behavior out of a model, absolutely still exists, it's just rarely called "prompt engineer" on a business card anymore.

How did we get from "2023's hottest job" to this debate? A timeline

None of this happened overnight, and the dates matter more than any single headline. Here's the actual sequence, pulled from the sources cited throughout this piece.

Lay the dates out like that and the pattern gets obvious. Nothing died in a single announcement. The title spiked fast, cooled off almost as fast, and the argument over what to call what's left has been running for two straight years without resolving, because both camps keep finding new evidence for a nuanced position that doesn't fit a one-word headline.

Does the research actually back up "prompt engineering is dead"?

Partly, and the strongest evidence isn't even about phrasing. It's about structure. Andrew Ng's team at DeepLearning.AI ran a widely cited comparison on the HumanEval coding benchmark: GPT-3.5 answering in a single pass scored 48.1 percent. GPT-4, a genuinely more capable model, answering in a single pass scored 67.0 percent. Then they wrapped GPT-3.5, the weaker, cheaper model, in a simple agentic loop that let it draft an answer, check its own work, and revise. That loop pushed GPT-3.5's score up to 95.1 percent, according to DeepLearning.AI's own writeup.

A cheaper model wrapped in a feedback loop beat a smarter model asked once. Sit with that comparison for a second, because it's the whole argument in one data point. The gain from GPT-3.5 to GPT-4, upgrading the model itself, was 18.9 percentage points. The gain from adding a checked, iterative loop on top of the weaker model was 47 percentage points, more than double. That's not a case for better phrasing. It's a case for better structure: draft, check, revise, repeat. That structure is what most of 2026's "context engineering" and "loop engineering" writing is actually describing, just with a newer name.

None of that research says wording doesn't matter at all. A vague, ambiguous instruction still produces vague, ambiguous output, loop or no loop. What it shows is that wording was never the biggest lever available, and spending your energy hunting for magic phrasing was always a smaller bet than spending it on building a system that checks and improves its own output.

Does an automatic prompt optimizer like DSPy prove the same point at scale?

Rick Battle's VMware experiment, the one where an automated tool out-produced hand-written prompts, wasn't a one-off lab curiosity. It's now a whole open-source framework that engineering teams actually use.

Researchers at Stanford, led by Omar Khattab, published a paper in October 2023 called "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines." DSPy treats a prompt the way a compiler treats source code: something a machine optimizes against a metric, not something a person hand-tunes by feel. Instead of writing a prompt string and tweaking its wording, a developer writes a typed program describing what the task needs, and DSPy's compiler searches for and assembles the actual prompt text and few-shot examples that score best on real evaluation data, according to the paper on arXiv.

The paper's own benchmark numbers back up Battle's VMware finding almost exactly. On GPT-3.5, DSPy-compiled prompts outperformed standard few-shot prompting by more than 25 percent and beat prompts written by human experts by 5 to 46 percent, depending on the task. On the smaller, cheaper Llama2-13b-chat model, compiled prompts beat few-shot baselines by 65 percent and expert-written demonstrations by 16 to 40 percent.

That last result matters more than it looks. A smaller, weaker, cheaper model with a compiled prompt closed most of the gap to a model with a hand-crafted expert prompt, the same shape of result Andrew Ng's team found when they wrapped GPT-3.5 in a feedback loop and watched it out-score a single-pass GPT-4. Structure keeps beating cleverness, on two separate research teams' benchmarks, a year apart.

DSPy isn't a lab toy that stayed in a paper. As of this writing it's a live open-source project with roughly 36,000 stars on GitHub, describing itself as "the framework for programming, rather than prompting, language models." That's a small, telling detail. The team that built the tool that helped kill hand-crafted prompting didn't call it a prompt-writing tool. They called it a programming framework, because that's what the job actually became.

Is the prompt engineer job title actually disappearing?

The title, mostly. The salary and the demand for the underlying skill, not really. Indeed's own salary data page for "prompt engineer" still shows an average salary of $115,914 a year, based on salaries pulled from job postings over the past 36 months, current as of Indeed's July 2026 update. That's not a dead job market. It's a real, six-figure-average role that companies are still actively posting and filling.

What's changed is where the skill lives. Fewer companies post a standalone junior role called "prompt engineer" the way they did in 2023, when the title was novel enough to justify its own line item. More companies now fold the same expectation, write clear, effective instructions for an AI system, into roles titled AI engineer, workflow architect, applied AI specialist, or simply "software engineer" with an AI-fluency requirement baked into the job description. The skill got absorbed into adjacent roles rather than eliminated outright, which is a genuinely different outcome than "nobody needs this anymore."

That absorption pattern isn't unique to prompt engineering. Our piece on whether AI will replace junior developers in 2026 found the same shape happening one level up the stack: AI hasn't eliminated junior developer jobs as a category, it's eliminated the specific low-judgment tasks, boilerplate code, routine bug fixes, that used to justify hiring a junior in the first place. Prompt engineering went through the identical process a year or two earlier. The narrow, mechanical version of the task got automated first. The judgment layer around it, is this output actually right, does this system behave reliably, stuck around and got more valuable, not less.

What do Sam Altman and the actual hiring numbers say about where this goes?

The Indeed salary page cited above shows a real, six-figure-average job. But a salary page only shows what existing postings pay, it doesn't show whether new postings are still showing up at the same rate, and that's where the picture gets more interesting.

Indeed's own internal search data, reported by Salesforce Ben, shows the title's whole rise and fall in three numbers. Searches for prompt engineering roles sat at about 2 per million in January 2023, a rounding error. By April 2023 they'd rocketed to 144 per million, a jump of roughly 70x in three months, as "prompt engineer" became the first breakout job title of the generative AI boom, according to Salesforce Ben's reporting. By mid-2025, Fortune reported the same search volume had settled into a plateau of roughly 20 to 30 per million, per Indeed VP of AI Hannah Calhoon, well above zero but nowhere near the 2023 peak, according to Fortune's coverage.

Even at the very top of the hype cycle, the title was rarer than the headlines suggested. A 2023 McKinsey survey, cited in that same Salesforce Ben piece, found that only 7 percent of organizations already using AI had actually hired a dedicated prompt engineer. The job was always more talked-about than hired-for.

The people closest to the hiring data aren't hedging about where this goes. Indeed economist Allison Shrivastava put it plainly to Fortune: "Prompt engineering as a skill is still definitely a good thing to have, but it's not an entire title." OpenAI CEO Sam Altman went further in that same reporting, predicting flatly: "I don't think we'll be doing prompt engineering in five years." Microsoft's Jared Spataro, Chief Marketing Officer of AI at Work, told Salesforce Ben a similar story from the enterprise buyer's side: "Two years ago, everybody said, 'Oh, I think Prompt Engineer is going to be the hot job'... [but] you don't have to have the perfect prompt anymore." Nationwide CTO Jim Fowler framed where the skill actually landed: "Whether you're in finance, HR or legal, we see this becoming a capability within a job title, not a job title to itself."

A Microsoft-commissioned survey backs up that read from the buyer's side too. Prompt engineer ranked second-to-last among new roles companies said they were considering adding over the next 12 to 18 months, per the same Salesforce Ben report.

None of the four people quoted above work for a company that benefits from prompt engineering looking dead. An OpenAI CEO, an Indeed economist, and two enterprise buyers of AI talent all have reasons to talk the skill up if they honestly could. They're not doing that. That's a stronger signal than any single salary number.

What replaced prompt engineering, exactly?

Ask three different sources and you'll get three different names for roughly the same shift, which is part of why this debate feels louder than it needs to be. Andrej Karpathy, formerly of Tesla and OpenAI, made the most widely cited case for a new term in a 2025 post on X. He argued for "context engineering" specifically because "prompt" undersells what the job actually involves: "context engineering is the delicate art and science of filling the context window with just the right information for the next step." He listed what that actually covers: "task descriptions and explanations, few shot examples, RAG, related (possibly multimodal) data, tools, state and history, compacting." Read the full post on X.

Gartner picked up a similar argument from the enterprise side. Its 2025 research told AI leaders to prioritize context over prompts, building context-aware architectures and integrating dynamic data rather than tuning individual instructions, framing context engineering as the discipline organizations need to invest in as prompt-level tuning stops paying off, according to Gartner's own published research.

The dev.to writer Gabriel Anhaia lays out a more granular breakdown of the same shift, describing five things that absorbed the old prompt-engineering job: structured output (schemas instead of parsing free text), tool calling (letting the model invoke real functions instead of just describing what to do), context engineering (what Karpathy named), evaluation frameworks (measuring whether a change actually helped), and self-correcting agent loops (the same draft-check-revise pattern behind Andrew Ng's benchmark jump). His framing of a 2026 "prompt engineer" is blunt: they now design schemas, tool APIs, context pipelines, and evaluation suites, not clever sentences. Read the full dev.to breakdown here.

Notice what all three terms share. Every single one assumes you can still write a clear, specific instruction as a baseline. None of them describe a world where phrasing doesn't matter, they describe a world where phrasing is the smallest part of a bigger job. That's the detail lost in every "prompt engineering is dead" headline that doesn't also mention what took its place.

Do reasoning models like o1, o3, and Claude's extended thinking make prompting matter even less?

There's one more piece of evidence worth adding to this debate, and it's the one that should settle any lingering doubt about whether the single most famous prompt-engineering trick of the 2023 era still works: "let's think step by step."

Reasoning models, OpenAI's o1 and o3, DeepSeek's R1, and Claude's extended thinking mode, work differently from the chat models the original prompt-engineering playbook was written for. Instead of producing an answer directly, they generate an internal reasoning process before responding, deliberating through the problem the way a person might work through scratch paper before writing a final answer. That internal deliberation makes a specific class of 2023-era prompt tricks not just unnecessary, but actively counterproductive.

OpenAI says so directly, in its own developer documentation. "Avoid chain-of-thought prompts: Since these models perform reasoning internally, prompting them to 'think step by step' or 'explain your reasoning' is unnecessary," according to OpenAI's reasoning best practices guide. The same guidance goes further than just calling the trick unnecessary: explicit chain-of-thought prompting on a reasoning model can actively degrade its output, adding noise on top of deliberation the model is already doing without being asked.

That's a genuinely notable reversal. "Think step by step" wasn't a fringe trick, it was arguably the single most cited prompt-engineering technique of 2022 and 2023, the one example every listicle and LinkedIn post reached for first. OpenAI's own guidance for its newest models amounts to: stop doing that, it can now make things worse.

What replaces it isn't nothing, though, and this is the detail that matters most for the "prompt engineering is dead" debate. OpenAI's guidance for reasoning models still asks for real structure: keep instructions simple and direct, start with a zero-shot request before reaching for few-shot examples (reasoning models often do fine without demonstrations), use delimiters like markdown, XML tags, or section headers to separate distinct parts of a request, and state constraints and success criteria explicitly rather than trusting the model to infer them. How much a model reasons gets set through an API parameter now, OpenAI's reasoning_effort, Claude's extended-thinking budget tokens, not through a magic phrase typed into the prompt itself.

So the honest answer is: reasoning models kill off one more specific 2023-era trick, on top of everything IEEE Spectrum's research already killed off. But they don't kill off structure, clarity, or explicit constraints. If anything, they raise the bar for those, because the one lever you used to have, asking the model to reason more, is now a setting instead of a sentence, which means the sentence you do write has to do more real work with less filler.

What do the people arguing it's NOT dead actually say?

They're not disputing the research above, they're disputing the conclusion people draw from it. Forbes contributor Dan Fitzpatrick made the case most directly in a June 2026 piece titled, pointedly, "Prompt Engineering Is Not Dead." His argument isn't that trick phrases still work, he cites the same Andrew Ng benchmark data covered above to make the opposite point everyone else does. His argument is that the underlying skill the term originally pointed at, clear communication with an AI system, never went anywhere, only the label and the scope changed. He frames the real shift as moving from optimizing single phrases to designing comprehensive systems, not abandoning the skill that started the whole conversation. Read Fitzpatrick's full piece here.

Bernard Marr, also writing for Forbes, takes a related but distinct angle in a January 2026 piece. He agrees prompt engineering isn't the most valuable AI skill anymore, but his reasoning centers on what enterprise AI actually looks like now, not on whether phrasing still matters. He writes: "prompt engineering, crafting natural language instructions that tell AI what to do, is no longer the most critical skill" because "enterprise AI is agentic," made of "autonomous workflows that chain tasks together, make decisions through interaction with external systems." His conclusion pushes past even context engineering, arguing the real differentiator in 2026 is leadership and judgment: "the real test for humans working alongside AI will no longer be writing the best and cleverest prompts, but learning to guide agentic systems with judgment, human values and accountability." Read Marr's full piece here.

Line those two Forbes pieces up against the "it's dead" camp and the actual disagreement gets narrow fast. Nobody in this debate argues you should go back to hunting for a magic phrase. Nobody argues clear instructions stopped mattering. The fight is entirely about labeling: is the current skill a continuation of prompt engineering, evolved, or a genuinely separate discipline that deserves its own name. That's a naming argument, not a substance argument, and it's worth knowing that before you spend more time worrying about which side is "right."

So, is prompt engineering still worth learning in 2026?

Yes, if you define it the way the skill actually works today, and no, if you define it the way it worked in 2023. That's not a dodge, it's the actual shape of the answer once you separate the two meanings this whole debate keeps blurring together.

Don't spend time memorizing trick phrases, magic incantations, or persona prompts. That specific investment has a genuinely low return in 2026, because model defaults already absorbed most of what those tricks used to buy you, exactly the pattern Rick Battle's VMware research demonstrated back when the shift started. Nobody hires anyone in 2026 to type one clever sentence into a chat box. If that's what you picture when you hear "prompt engineering," you're right to think it's not worth learning, because it was never going to remain a durable skill on its own.

Do spend time on the skills every source in this piece agrees still matter, whatever name they use for the umbrella term: giving an AI system the right context instead of a vague request, structuring a multi-step task instead of hoping one message solves it, and checking output critically instead of accepting it on first read. Those three things show up in Karpathy's context engineering, Gartner's enterprise guidance, Fitzpatrick's "it's not dead" argument, and Marr's judgment-focused pivot alike. The people saying prompt engineering is dead and the people saying it still matters are describing the same underlying skill with two different names.

If you're managing a team rather than doing the AI-assisted work yourself, the calculation shifts again. You don't need to become fluent in writing prompts. You need to get good at recognizing whether the tools your team adopted actually hand the model good context and check its output, or whether they're quietly asking people to type magic phrases into a box and hope. That's a judgment skill, not a phrasing skill, and it's the one Bernard Marr's Forbes piece argues matters most for anyone managing AI-assisted work rather than doing it directly.

What does context engineering actually look like next to old-style prompt engineering? A worked example

All of this stays abstract until you see the two approaches side by side on the same task. Here's an illustrative example, not a benchmark or a claim of hands-on testing, just a plain comparison of what changes between the two approaches.

Say the task is: fix a bug where a web app's date picker shows the wrong month near the end of a month in certain timezones.

The 2023-style prompt leans entirely on phrasing:

"You are a world-class senior software engineer with 20 years of experience in JavaScript and timezone handling. Think step by step and be extremely thorough. This is very important, take your time. Fix the date picker bug."

Notice what's missing: the actual code, the specific timezone range, a description of what "wrong month" looks like, and any way to check whether the fix worked. The prompt spends its entire budget on tone and persona, and its entire hope on a phrase, "think step by step," that (per the previous section) is no help at all on a reasoning model, and was never a reliable fix for a missing-information problem on any model.

The context-engineered version spends its effort somewhere else entirely:

"Here's the DatePicker component and the failing test case (pasted below). The bug: for users in UTC-8 through UTC-11, selecting the last day of a month sometimes displays the following month's name. Expected behavior: the displayed month should always match the selected date in the user's local timezone, per this test file (pasted below). Constraints: don't change the component's public props, and don't add a new date library, we already use date-fns elsewhere in this codebase. After you draft a fix, check it against the three edge cases in the test file yourself and flag any you're not confident pass before I run them."

The second prompt doesn't sound more impressive. It doesn't use a single trick phrase. What it does is remove the guesswork: the model has the actual component, the actual failing behavior, the actual constraint that rules out a whole category of lazy fixes (swap in a new library), and an explicit instruction to check its own work before handing it back, the same draft-check-revise structure behind the 48.1-to-95.1-percent jump in Andrew Ng's benchmark data covered earlier in this piece.

Neither prompt above uses a magic phrase, and that's the point. The difference between them isn't wordsmithing, it's whether the model was given what it actually needed to do the job right the first time. That's the whole distance between 2023's prompt engineering and 2026's context engineering, in two paragraphs instead of two years of debate.

What are the most common mistakes people make once they start "context engineering"?

Context engineering is genuinely better than trick-phrasing, but it's not automatically foolproof, and treating "give the model more information" as a rule with no limits creates its own new failure mode. Four mistakes show up constantly once people move past prompt phrasing.

Mistake 1: assuming more context is automatically better context. Chroma Research tested 18 frontier models, including Claude Opus 4, GPT-4.1, o3, and Gemini 2.5 Pro, in a 2025 study called "Context Rot." The researchers found that "models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows," a pattern that showed up across every model tested, according to Chroma's own published research. Even a single irrelevant distractor in the context measurably hurt performance relative to a clean, focused prompt, and the effect got worse as the input got longer. Dumping an entire codebase, an entire policy document, or an entire chat history into a prompt "just in case" isn't harmless. It's an active tax on the model's attention.

Mistake 2: burying the important part in the middle of a long context. Stanford researchers found a related effect back in 2023, in a paper simply titled "Lost in the Middle." Models reliably pay closer attention to information at the very start or very end of a long context, and reliably lose track of information buried in the middle, "even for explicitly long-context models," according to the paper itself. If the one constraint that matters most for your task is buried on page 40 of 60 in the context you handed over, don't assume the model weighted it the way you did. Put the critical constraint near the start, and repeat it near the end.

Mistake 3: never checking whether a context or prompt change actually helped. This is the mistake dev.to's Gabriel Anhaia's breakdown, cited earlier, calls out directly: evaluation frameworks are one of the five things that replaced hand-tuned prompting, precisely because "it felt better" isn't a metric. Without a real before-and-after comparison on a fixed set of test cases, you can't tell a genuine improvement from a lucky run.

Mistake 4: treating structured output as a replacement for a clear goal, rather than a container for one. Asking for JSON, a schema, or a numbered format fixes how an answer is shaped. It doesn't fix what the answer needs to contain. A perfectly formatted JSON object built around a vague, underspecified task is still a vague, underspecified answer, just easier to parse.

Every mistake on that list is a context-engineering mistake, not a prompt-phrasing one. That's worth sitting with, because it means the "prompt engineering is dead" debate didn't retire the possibility of getting your request to an AI system wrong. It just moved where the mistakes happen.

What should you actually learn instead of, or alongside, prompt phrasing?

Three things, in order of how much they'll actually change your results. First, learn to give a model the right context before you ask for anything: the relevant background, a couple of examples of what good output looks like, and any hard constraints, instead of a bare request and a hope it reads your mind. This is the exact skill Karpathy renamed and Gartner told enterprises to invest in, and it consistently outperforms clever phrasing because it addresses the actual bottleneck, missing information, rather than a cosmetic one, word choice. Just remember the caveat from the mistakes above: curate that context, don't maximize it.

Second, learn to structure multi-step work instead of expecting one message to do everything. A single prompt asking for a finished, correct, complex output is betting everything on one roll. Breaking that same request into a draft step, a check step, and a revise step is what took GPT-3.5 from 48.1 percent to 95.1 percent on that HumanEval benchmark, without touching the model itself, and it's the same structure DSPy's compiler and Andrew Ng's agentic loop both landed on independently. You don't need to build a formal multi-agent system to use this idea. Even manually asking a model to review its own answer before you accept it captures most of the benefit.

Third, and most overlooked, learn to check AI output instead of trusting it by default. This is the skill this site's piece on whether AI is making you worse at your job covers in more depth: research across medicine, coding, and knowledge work keeps finding that skill erosion happens specifically where trust replaces scrutiny, not simply where a tool gets used. The same discipline applies directly here. An AI-assisted output you never verify is exactly as risky whether you call the process prompt engineering, context engineering, or anything else. It's also exactly the failure mode covered in our vibe coding security checklist, where AI-generated code that looks finished but was never checked is the single most common source of real vulnerabilities, exposed secrets, missing access control, that ship straight to production.

None of these three skills require a course with "prompt engineering" in the title. Most of them are things you can start practicing on your very next AI interaction, today, for free.

Does any of this change if you're not a software engineer, like a video editor?

Less than the headlines suggest, and the reason is worth understanding rather than just taking on faith. Most of this debate happened inside software engineering because that's where prompt engineering as a job title first showed up, wiring raw prompts into API calls, chaining outputs, building agents. If your work is video editing or color grading in DaVinci Resolve, you were probably never going to be hired as a "prompt engineer" in the first place, so the job title collapsing doesn't touch you directly.

What does touch you is the same underlying shift. DaVinci Resolve 21's AI tools, IntelliSearch, IntelliScript, Magic Mask, mostly take structured input rather than open-ended prompts. You describe a shot in plain language for IntelliSearch, or feed a script into IntelliScript, and the tool does the rest. There's very little "prompt engineering" to do there in the trick-phrasing sense, because Blackmagic designed the interface around specific inputs rather than open chat, the same evolution described throughout this piece, just built directly into the product instead of left to the user.

The skill that does transfer, regardless of your field, is specificity. Whether you're asking a coding model to fix a bug or asking IntelliSearch to find "the shot where the lead actor looks up at the sky right before the storm," a vague request gets a vague result and a specific one doesn't. That's not prompt engineering in the 2023 sense. It's just clear communication, the same thing every source in this debate, on both sides of the "dead or not" argument, agrees still matters.

An AI tutor built for editors handles this differently than a general chatbot does, and it's worth understanding why if you're weighing whether to learn prompting at all before diving into Resolve's AI features. TryUncle watches your project inside the Edit, Color, and Fusion pages and points at the actual control you need, live, rather than requiring you to phrase a request precisely enough for a chat window to understand. That's context engineering done by the tool itself instead of left to you: TryUncle already has the context, your project, your timeline, the page you're on, so there's no prompt to write in the first place for most of what it does. Compare that to a general chatbot, where you'd have to describe your project in words before it could help at all, and you're doing the context-gathering step by hand every single time. That design sidesteps the prompting question almost entirely for the specific job of learning Resolve. It's a paid macOS app currently in founder pricing, so check tryuncle.com's current pricing page for the current rate rather than assuming a number that might have changed by the time you read this.

What should you do this week?

Pick one AI tool you already use regularly, ChatGPT, Claude, a coding assistant, an AI feature inside your editing software, and change one habit instead of trying to overhaul how you work with AI overall. Before your next request, spend thirty seconds gathering the actual context the model needs: the relevant file, the constraint, an example of the output you want. That single habit does more for your results than any list of magic phrases would have in 2023.

Then add a second habit on top of it. Before you accept the model's answer, ask it, or ask yourself, to check the work once before you build on it. That's the entire mechanism behind the 48.1-to-95.1-percent jump in the benchmark data above, drafted, checked, revised, and it costs you a few extra seconds per task, not a new job title or a certification.

If you manage people rather than doing the AI-assisted work yourself, your version of this week's habit looks different. Instead of gathering context for your own prompt, ask the person on your team who does this daily to walk you through what context they hand the model and how they check its output. If the honest answer is "I just ask and hope," that's a coaching conversation worth having regardless of what you call the underlying skill.

Skip the courses and certificates that promise to make you a "certified prompt engineer" through a list of clever phrases. That specific promise was accurate in 2023 and is mostly outdated now, for the exact reasons the research in this piece documents. If you want structured practice instead, look for material that teaches context structuring, multi-step workflows, and output evaluation, the actual skills every source in this debate agrees still matter, regardless of which side of the "is it dead" argument they're arguing.

So, still worth learning?

Learn the skill, skip the anxiety about the label. Every piece of evidence in this post, VMware's automated prompt research, Stanford's DSPy compiler, Andrew Ng's benchmark jump, Karpathy's context engineering argument, Gartner's enterprise guidance, OpenAI's own reasoning-model guidance, Chroma's context rot findings, and both Forbes pieces arguing opposite headlines, agrees on the same underlying point once you strip the terminology away: clear communication with an AI system, backed by good, curated context and followed by real checking, is more valuable in 2026 than it's ever been. What died was a narrow, trick-based version of that skill that never had much shelf life to begin with, and the hiring data backs that up as clearly as the research does.

If you're deciding where to spend your next hour of learning, spend it on context, structure, and verification, not on hunting for a clever phrase. The job title "prompt engineer" may or may not survive the next debate cycle. The skill underneath it isn't going anywhere, and it's already showing up, quietly renamed, in almost every AI-adjacent role worth having.