The way we interact with AI, termed "prompting," has fundamentally shifted due to the advent of autonomous agents. Traditional chat-based prompting is becoming obsolete, necessitating a new, multi-layered skill set to effectively leverage AI for complex, long-running tasks.
Mind Map
点击展开
点击探索完整互动思维导图
If you're prompting like it's last
month, you're already too late. And I'm
not just doing that for clickbait. If
you haven't updated how you think about
prompting since January 2026, you're
already behind. Opus 4.6, Gemini 3.1
Pro, and GPT 5.3 codecs have all shipped
in the past few weeks with autonomous
agent capabilities that make the
chatbased prompting most people are
practicing functionally obsolete for
serious work. These models don't just
answer better. They work autonomously
for a long time, for hours, for days
against specs without really checking
in. That changes what good at prompting
means on a fundamental level. And it's
time to revisit how we think about
prompting as a result. Not because
prompting stopped mattering. It actually
matters more than ever, but because the
word prompting is now hiding four
completely different skill sets, and
most people are only practicing one of
them. And the gap between the people who
see all four of them and the people who
don't is already 10x and widening. In
this piece, I'm going to lay out what
those four skills are, why the
distinction matters now, and exactly how
to build the skills you're missing. This
builds on my earlier work on intent
engineering, but it goes way beyond it
to lay out a full framework for how to
think about prompting post February
2026. Intent engineering is just one
layer in a larger stack. This is the
full stack for prompting post February,
post these new autonomous models. First,
what changed? The prompting skill that
mattered since 2024 has been really
conversational. You sit in a chat
window, you type a request, you read the
output, you iterate, you get better at
phrasing things, you provide examples,
you structure instructions. If you're
good at that, and if you've been
following this video series, you
probably are. You've been building real
skills. They work. you're faster than
you were a year ago. But that
fundamental chatbased skill has a
ceiling. And in early 2026, a lot of
people are hitting it because the models
have stopped really being chat partners
and started being workers. Workers that
run for a long time. I'm not kidding
when I say days and sometimes weeks. And
the thing about a worker that runs for a
long time is that everything you relied
on in a conversation, like your ability
to catch mistakes in real time, your
ability to provide missing context
accurately when the model asks, your
ability to course correct when things
drift. All of that must be encoded
before the agent starts. Not during the
course of a conversation, but at the
top. This is a fundamentally different
skill. It's not a harder version of the
same skill. It's actually different.
I've talked before about the importance
of thinking about prompting even in the
chat window as providing the relevant
context for the LLM to provide you an
accurate response. But this goes way
beyond that. If you were giving an agent
a longunning task, which is where most
of AI is going, even if you're not a
coder, then you have to think not about
how do I build for a chat response, but
how do I build for economically real
work that this agent will do and provide
the agent the relevant context for that.
And this shift is happening really
quickly. Between October of 2025 and
January of 2026, in just 3 months, the
longest autonomous cloud code sessions
nearly doubled, and they've doubled
again since then. Agents are running
into the hundreds and thousands in
production systems at major companies.
And this is just from publicly available
information. We have Telus reporting
that they have 13,000 custom AI
solutions internally. We have Zapia
reporting that they have over 800 agents
internally. Look, whenever they release
a press release, you got to assume that
company feels behind and is releasing
something to help them feel better about
themselves. The companies that are
really serious about AI don't feel the
need for press releases and have an
order of magnitude or more agents. So,
this is not about a world that is
coming. This is about a world that has
landed. But this still might not feel
concrete enough for you. So, let me talk
to you about a random Tuesday. Two
people sit down with the same model,
same subscription, same context window.
One of them uses 2025 skills. You type a
request, you get back something that is
80% right. You spend 40 minutes cleaning
it up and you have a good use of AI
because you saved it a lot of time. It
might have saved 50% on your time, might
have saved 60%, maybe higher. Let's make
the gap concrete. Let's say two people
are sitting down with the same model on
a Tuesday morning in February of 2026.
Same subscription, same context window.
The only difference is that one of them
is using 2025 prompting skills and one
of them is using 2026 prompting skills.
So the 2025 person types a request and
they're asking for a PowerPoint deck,
right? They get back something that's
about 80% correct. Maybe there's some
formatting issues. Maybe the font has
some collisions in it. Maybe there's
some styling issues. They spend about 40
minutes cleaning it up, but they're
pretty happy because this deck would
have taken two or three hours. That's a
2025 prompting skull application. it
would have been good in 2025.
Person B sits down with 2026 prompting
skills. They write a structured
specification in 11 minutes. They take
longer to prompt. Then they hand it off
to the same chatbot, but they're
thinking of it and using it as an
autonomous agent. They go to make
coffee. They come back to a completed
PowerPoint that hits every quality bar
defined up front. And they're able to do
this for five other decks before lunch.
In other words, they are now doing a
week's worth of work in a morning
easily. Same model, same Tuesday, 10x
gap. And if you want to replicate this,
you can replicate this experiment
directly in Claude Opus 4.6 in the
co-work model, which is available on
Windows and Mac. And you can see exactly
how this plays out. And this did not
happen because the person with 2026
prompting skills is smarter or because
she's more technical. It's because she's
practicing a different skill than person
one and person one doesn't know that
kind of prompting skill exists. I think
it's worth paying attention to Shopify
CEO Toby Lutkkey here. Unlike most CEOs,
Toby is a technical guy and he does not
just dig into AI from a LinkedIn
perspective. He has a folder of prompts
that he runs against every new model
release and he really deeply thinks
about how new model releases change his
workflow. He uses the term context
engineering because he believes the
fundamental skill that we're all facing
is the ability to state a problem with
enough context in a way that without any
additional pieces of information, the
task becomes plausibly solvable. I think
that's a really elegant way to describe
what person B did in the example I just
showed you. Person B put all of the
information that the model needed to
build a deck in one task very clearly
defined and the model could just go to
work. This isn't about clever prompt
tricks. This isn't about magical words
that an AI can use to produce a better
output. It's about a communication
discipline. Can you state a problem so
completely with so much relevant
surrounding information that a capable
system can solve it without going out
and fetching more context? Can you make
your request as self-contained as
possible? This is a really big deal
because it demands a much higher bar for
communication from us humans than we're
used to. And that's something that Toby
called out when he reflected on the
impact of AI on his own leadership
style. One of the things he mentioned is
that by being forced to provide AI with
complete context, he is now better at
communicating as a CEO. His emails are
tighter, his memos are better, his
decision-making frameworks are stronger,
and Toby has gone farther than most
people thinking about the implications
of context engineering. I think one of
his most provocative assessments is that
a lot of what people in big companies
call politics is actually bad context
engineering for humans. What he suggests
is that essentially good context
engineering would surface disagreements
about assumptions that are never
surfaced explicitly but play out as
politics and grudges in large companies.
And he says that happens because humans
tend to be sloppy communicators who rely
on shared context that doesn't actually
exist. I think that's a really
interesting thesis. I think one of the
implications of getting this February
2026 prompting lesson deeply ingrained
in ourselves is that our communication
humanto human is likely to improve and
our organizations are likely to have
cleaner decisioning and cleaner
communication even between humans as a
result. So I bet you're wondering what
are these four disciplines? What does it
mean when prompting becomes multiple
skills that we need to learn? Well, I
don't want to hide the ball here. Here
is the framework that I would lay out
that describes what prompting should be
in February 2026. And I've built it to
be futurep proof. So we look at the
direction that agents are going, how
they're developing this year. These four
disciplines are going to matter even as
we expect agents to continue to scale.
This represents a significant update on
how I've taught prompting before 2026
because the way we prompted before 2026
was helpful as a foundation. You're not
losing something by having learned it,
but it's not enough as agents get more
capable. And I think we're due for a
reset. So, fundamentally, prompting is
the broad skill of providing input to AI
systems so that they can do useful work.
Prompting has diverged into four
distinct disciplines, but it's not
taught that way. And so, I'm laying this
out for the first time here. Each of
these disciplines is operating at a
different altitude and time horizon. And
you need to understand them all to
prompt well. Just because they're not
often prompted this way, just because
they're not often taught this way,
doesn't mean that good prompters don't
intuitively know this. What I'm taking
is intuitive knowledge that I see in
excellent prompters and boiling it down
into four key disciplines that you can
practice and learn from. And these build
on each other. If you skip one, I'm
presenting them in order. If you skip
one, you're creating the kind of
failures we tend to see at scale in the
enterprise, but you're creating it for
yourself in your own prompting. And I'll
kind of get at what that means and
you'll get the idea. So discipline one
is prompt craft. This is the original
skill. This is the skill I have taught
and many others have taught for the last
year or two. It's synchronous. It's
sessionbased and it's an individual
skill. You you sit in front of a chat
window. You write an instruction. You
evaluate the output. Then you iterate.
The skill here is knowing how to
structure a query. And I've talked a lot
about this in the past. I'll rehash it
briefly here. You must have clear
instructions. You must include relevant
examples and counter examples. You need
to include appropriate guard rails. You
need to include an explicit output
format. And you should be very clear
about how you resolve ambiguity and
conflicts. So the model doesn't have to
make it up on the fly. This is what
anthropics prompt engineering
documentation covers. Open AI talks
about this. Google talks about this.
It's on a thousand blog posts and
LinkedIn courses. Prompt craft has not
become irrelevant. Don't hear that. It's
just become table stakes. It's sort of
the way knowing how to type with 10
fingers was once a professional
differentiator and now it's just table
stakes. It's just assumed. If you can't
write a clear, well ststructured prompt
in 2026, you're the person in 1998 who
couldn't send an email. Is it important
to be able to do it? Yes. Is it going to
differentiate you in the workforce? No,
not really. The key shift is that
promptcraft was the whole game when AI
interactions were synchronous and
sessionbased. You wrote something, you
got something back, and you refined it
in real time. As a human interacting
with that model, you were acting as the
intent layer, as the context layer, and
as the quality layer so that longunning
tasks could get done. You did all the
breaking out of those tasks. That model
of prompting broke the moment agents
started running for hours without
checking in. Discipline 2 we've been
talking about for a few months now. It's
called context engineering. Enthropic
published the foundational piece on this
back in September of 2025, but there's a
lot of other good pieces out there as
well. I've written a fair bit on it. I
define context engineering as the set of
strategies for curating and maintaining
the optimal set of tokens during an LLM
task. And that's not just me defining
that. That's a pretty commonly held
definition. Wang Shane's Harrison Chase
was even bluntter about what context
engineering is during a recent Sequoia
Capital interview when he said
everything is context engineering. It
actually describes everything we've done
at lane chain without knowing the term
existed. So that's actually somewhat
dangerous because context engineering is
only one of four levels and people have
misunderstood it to mean everything. And
one of the things I'm trying to get us
to move toward is a world where we
understand context engineering as a
specific skill where we're providing
relevant tokens to the LLM for
inference. And yes, it is certainly
foundational. It is certainly
significant. It is where the industry's
attention is focused today. It is the
shift from crafting a single instruction
to curating the entire information
environment and agent operates within.
all of the system prompts, all of the
tool definitions, all of the retrieved
documents, all of the message history,
all of the memory systems, the MCP
connections. The prompt you write might
be 200 tokens. The context window it
lands in might be a million. Your 200
tokens are 002% of what the model sees.
The other 99.98%
that's context engineering. This is the
discipline that produces claw.md files,
agent specifications, rag pipeline
design, memory architectures. It's the
discipline that determines whether a
coding agent understands your project's
conventions, whether a research agent
has access to the right documents,
whether a customer service agent can
retrieve relevant account history.
Anthropics engineering team identified
the core challenge precisely. LLM
degrade as you give them more
information. That's correct. They do.
And the point therefore is to include
relevant tokens because the issue is not
that they can't hold the tokens. It's
that retrieval quality does drop as
context grows. The practical implication
is that people who are 10x more
effective with AI than their peers are
not writing 10x better prompts. They're
building 10x better context
infrastructure. Their agents start each
session with the right project files,
the right conventions, the right
constraints already loaded. The prompt
itself can be relatively simple because
the context does the heavy lifting. I
have seen this for myself as I've built
out my own context engineering
scaffolding. And if you're wondering how
to do it for yourself, I'm putting a
guide together with this video over on
the Substack and I think it'll be
helpful. Discipline number three. This
one we don't talk a lot about. I think
is where we're going as these agents
start to do much longer autonomous
running tasks. I wrote about this one at
length in a prior piece. I did a video
on it. I'm going to be brief here. I'm
going to contextualize where it sits in
the stack. Context engineering tells
agents what to know. Intent engineering
tells agents what to want. It's the
practice of encoding organizational
purpose, your goals, your values, your
trade-off hierarchies, your decision
boundaries into infrastructure that
agents can act against. Claro story is
the proof case I talked about. Their AI
agent resolved 2.3 million customer
conversations in the first month, but it
optimized for the wrong thing. It
slashed resolution times, but it didn't
optimize for customer satisfaction. And
as a result, CLA got into big trouble
and had to rehire a bunch of human
agents and is still dealing with the
customer trust aftermath. So, intent
engineering sits above context
engineering the way strategy sits above
tactics. You can have perfect context
and terrible intent alignment. You
cannot have good intent alignment
without good context, though, because
the agent needs information to act on
the intent. So these disciplines again
they're cumulative. Another thing I want
you to notice is that failure as we
progress up this hierarchy is getting
more and more serious. When you as an
individual sit down and you screw up a
prompt, it might waste your morning at
worst. When you as a human being sit
down and screw up context engineering or
intent engineering, you are screwing up
for the entire team, your entire org,
your entire company. The stakes get
higher. And because the stakes get
higher, our attention to detail matters
and the value of the work we do
increases commensurately. What I am
talking about when I talk about context
engineering and intent engineering can
be a full-time role at a big company.
And if it's not, it is a highstakes
human skill that has a lot of
transferable value. Level four is
specification engineering. We're just
starting to talk about this now, even
though the best practitioners are
already doing it. Specification
engineering is the practice of writing
documents across your organization that
autonomous agents can execute against
over extended time horizons without
human intervention. This is a level
above everything I've described because
all of the first three levels focused on
how you prepare work directly for an
agent. Specification engineering is
really about thinking about your entireformational
