Stop describing tasks. Start describing frustrations.
Prompt engineering was a bridge. You are already standing on the other side of it.
Prompt engineering is dead.
I know how that sounds. For two years it was the skill everyone was teaching, selling, and putting on resumes. I am telling you it is over, and I am going to show you the two practices that replaced it.
I have been in technology for twenty years. I currently lead multiple programs developing AI models at Google. The way I work with AI stopped looking like prompting about six months ago, and once I name what changed, you will not be able to unsee it in your own usage.
For years, a good prompt was you planning the AI’s thinking for it. Role, task, constraints, examples, the careful chain-of-thought scaffolding. That entire craft existed because the model could not plan its own reasoning, so you had to do it for the machine.
The current generation of models plans its own reasoning. The scaffolding you spent two years getting good at is now built into the foundation you are standing on.
This is not my opinion. Andrew Ng put numbers on it at Sequoia’s AI Ascent conference. His team ran the HumanEval coding benchmark. GPT-3.5 with a single prompt scored 48 percent. GPT-4 with a single prompt scored 67 percent. The same GPT-3.5, wrapped in an iterative workflow instead of a clever prompt, scored 95 percent. His conclusion was that the improvement from one model generation to the next is dwarfed by changing how the AI works rather than which AI you use.
A 2026 survey of IT and data leaders found that 82 percent now agree prompt engineering alone is no longer sufficient for real work.
You have been taught to talk to AI like a programmer. Now you talk to it like an orchestrator. Programmers write specs. Orchestrators describe what they want and let the system find the path.
That sentence is the whole shift. Everything below is how you actually do it.
1 - Stop describing tasks. Start describing frustrations.
Here is the problem with a prompt.
When you write one, you are describing a version of reality you have already sorted out in your head. You decided what the problem is. You decided what the solution should look like. You decided which tools you think you need. What the AI receives is your conclusion, not your problem. It is limited to your point of view, so it never gets the real one.
A frustration is the opposite. When you vent a frustration, you hand the AI the raw material instead of your pre-sorted answer. That is where the actual problem usually lives.
Let me give you the moment this became obvious to me.
Three weekends ago I was trying to get Claude to produce a weekly intelligence briefing for my newsletter. It should have taken an hour. I spent all of Saturday afternoon rewriting the prompt instead. Role prompts. Task prompts. Examples. Chain-of-thought setups. I had prompt version nine open next to version one, trying to work out why every brief it generated kept missing what I cared about.
Sunday morning I gave up on the prompt. I opened a fresh chat and just told Claude what was bothering me. Something close to: “I’m trying to get a weekly briefing out of this thing, every prompt I write gives me something that misses what I actually care about, and I can’t figure out why.”
Before it answered, it asked me three questions I had not thought to put in the prompt. Who was this briefing for. What counts as signal versus noise. What I was going to do with the information once I had it.
Those were the exact questions I had been writing prompts to avoid. The model wanted them. When I answered, the briefing it produced in a single pass was better than anything I had engineered over two days.
The reason my prompts had grown so complicated was that I kept trying to preload the answer so the machine would not have to think. The machine can think now. That is the entire reason describing frustrations works where describing tasks does not.
2 - The Friction Dump.
Here is the practice, named so you can actually use it.
Next time you open Claude, skip the prompt. Talk into it the way you would vent to a coworker over lunch. Plain, unsorted, honest about what is actually annoying you.
Things like:
“Every Monday morning I waste an hour figuring out what I should actually care about this week.”
“I dread the 3pm meeting because I never feel prepared and my boss can tell.”
“I have three tools that are supposed to save me time and none of them talk to each other.”
I call this a Friction Dump. It is closer to a briefing than a prompt. The model pulls the real problem out of the mess, works out how much thinking it needs to apply, and engages with what is actually there to solve instead of the cleaned-up version you would have typed.
Then add one line at the end. Type: “Ask me the questions you need to actually help me solve this.” Hit enter.
The questions it asks back are not the ones you would have thought to put in a prompt. They are sharper. Usually because they are the ones you were quietly avoiding.
I ran this last week on my client prep workflow. I had been trying to prompt my way to a better prep document for six months. When I let the model interview me instead, its fourth question stopped me cold.
“What’s the one thing about this client you’re hoping doesn’t come up in the meeting?”
I had never written that into a prompt. I never would have. The prep document I got after answering it was different from anything I had produced in those six months of prompt engineering.
That is practice one. It is a conversation. Practice two is what you do with the conversations that work.
3 - Hand off the work that repeats.
The first practice is how you talk to AI. The second is where you actually start orchestrating.
You hand off the work that repeats.
Pick one workflow. Get it running every morning. Just one. The library approach, where people collect a thousand prompts and end up using four of them, is part of what kept everyone stuck. An orchestrator does not maintain a library of instructions. They put the work somewhere it runs.
The one I built first, and the one I recommend you start with, I call the Living Brief.
It is not a news summary. It is not a morning roundup. It is a briefing that already knows what you are working on this quarter, the decisions you have open right now, and what changed in the last forty-eight hours that affects either one.
Last Tuesday it caught something I would have missed entirely. Two creators I follow in the AI space had both repositioned their channels in the same week. It was not news. Nothing was trending. The brief flagged it because it knew I care about positioning shifts in that specific niche. That was twenty minutes I did not have to spend to notice a thing I needed to notice.
The point is not the information. The point is what it removes from your morning. You stop scanning five different sources. You stop asking yourself what you should be paying attention to today, because the brief already made that call for you. You open it, you read it, you know where to put your attention.
One workflow that runs every day beats a hundred prompts saved in a file.
4 - How to know if you built it right.
Run it for a week.
If you find yourself still checking the sources it was supposed to replace, the brief is not specific enough yet. That is not a failure. That is the iteration loop.
Go back and tell the AI what it missed. Let it interview you again about what counts as signal for you specifically. You iterate on the brief itself, not on the instructions that build it. This is the orchestrator’s version of debugging. You are not rewriting a spec. You are refining a working system by telling it where it was wrong.
(This is also why the Friction Dump and the Living Brief are the same skill wearing two different clothes. One is the conversation. The other is the conversation, made to run on a schedule.)
5 - The starter prompt.
I am not going to make you reverse-engineer this.
Below this newsletter I have included the exact starter message I paste in to build a Living Brief from scratch. It is built on the Friction Dump method, which means it does not try to preload the answer. It opens the conversation, tells the model what the brief is for, and instructs it to interview you before it builds anything.
Paste it into a fresh chat. Answer the questions it asks you. You will have your first brief running before the end of the day.
The starter prompt is the asset. The skill is what happens after you stop treating it as a template to perfect and start treating it as a conversation to have.
The work, from here.
AI learned to plan its own reasoning. That single change is what turned prompt engineering from a skill into a bridge. Everyone who taught it and sold it for the last two years was not wrong. They were teaching you how to cross something. You are on the other side of it now.
What you describe, what the AI asks back, and what the two of you build between you. From here, that is the work. There is no perfect template. There is no perfect prompt. Every interaction is becoming specific and authentic to you, which means the people who win are not the ones with the best saved prompts. They are the ones who can describe what is actually wrong and let the system find the path.
Do not try to program the answer. Orchestrate it. Let it think, and let it tailor the result to you.
Try this tomorrow morning. Open a fresh chat, vent your biggest frustration from this week, then ask it to interview you. Before lunch you will have your first brief.
See you in the next one,
Guney
ASSET: THE LIVING BRIEF STARTER PROMPT
(Paste this into a fresh Claude chat. Answer what it asks. Do not pre-sort your answers.)
I want to build a daily briefing I'll actually use, and I want you to
interview me before you build anything.
Here's my frustration, unsorted:
Every morning I lose time figuring out what I should be paying attention
to. I check too many sources, I'm never sure I've seen what actually
matters, and I keep worrying I missed something important while I was
looking at something that wasn't. I don't want a news summary or a
generic roundup. I want a briefing that already knows what I'm working
on and tells me only what changed that affects it.
Before you build this, interview me. Ask me the questions you need to
actually make this useful, one or two at a time, and wait for my answers.
At minimum I expect you to need to know:
- What I'm actively working on this quarter
- The specific decisions I have open right now
- What counts as signal for me, and what is noise I want filtered out
- What sources or domains I currently watch
- What I want to DO with the brief once I read it each morning
Ask anything else you need. Push on the answers that are vague. When you
have enough, produce the first version of the brief, then tell me exactly
what to paste back to you each day to regenerate it.
After I run it for a week, I'll come back and tell you what it missed.
We'll refine the brief itself, not rewrite these instructions.