Is prompting a lasting skill or a passing phase?

The Short Version

The people who build and study AI systems split on whether writing prompts is a skill worth learning for the long run, and the split mostly disappears once you ask which part of prompting they mean. Amanda Askell at Anthropic treats serious prompts as careful work revised hundreds or thousands of times, and also says that for everyday tasks you should just ask [1]. The Cursor team builds an elaborate prompt system so that their users never have to think about one [2]. Fei-Fei Li calls prompting a skill she wants taught from kindergarten on, and says the best prompter in history would be Socrates [3]. Manolis Kellis sees prompting as something we already do to each other [4]. Aravind Srinivas says prompt engineering won't last, because "a better product should be one that allows you to be more lazy, not less" [5]. The wording tricks are the part most likely to fade. Knowing what you want, saying it clearly and asking a good next question is the part every one of them expects to keep its value.

Table of contents

What They Said

Amanda Askell: prompting as philosophy applied

Askell is a philosopher by training who leads work on Claude's character at Anthropic, and she is the clearest example of someone for whom prompting is a craft [1].

She says philosophy has been surprisingly useful for it because philosophy trains extreme clarity [1]. Her method starts with definitions. If she wants the model to judge whether something is rude or polite, she first works out exactly what counts as each [1]. Then she probes the model repeatedly, looks for edge cases where it misunderstands, and adds instructions or examples to cover them [1]. "Prompting is very iterative," she says, and a serious prompt may be revised hundreds or thousands of times [1].

She is just as clear about when this effort is unnecessary. For everyday tasks, just ask [1]. Heavy prompting matters for squeezing out the top 2 percent of performance, or for prompts that are core to a product [1].

Her practical advice is about attitude more than syntax. Have empathy for the model: read your prompt as if seeing it fresh, with none of the context in your head [1]. When it gets something wrong, ask it why it made the mistake, or what instruction would have prevented it [1]. And ask for what you actually want. She shows that requesting a fully creative, deeply considered poem produces far better work than a plain request for a poem [1].

Her account of system prompts shows both the power and the impermanence of careful wording. A phrase such as "never" in capital letters is not a literal statement of values, she explains. It is a nudge that shifts a behavior from, say, 40 percent of the time to 80 percent [1]. One line in Claude's system prompt removed filler affirmations such as "certainly"; it targeted an artifact of training and was dropped once training fixed the problem [1]. She calls system prompts a cheaper, faster, less robust way of patching issues [1]. So even inside the lab, a prompt is often a temporary fix for something the next model will no longer need.

Anthropic's chief executive Dario Amodei adds two observations from the same company. Models are sensitive to small changes in wording, which he thinks explains much of the recurring complaint that a model has "gotten dumber" [1]. And controlling behavior is hard even for the builders: penalizing verbosity, for example, made models lazy at coding [1]. His advice to newcomers to the field is simply to start playing with the models [1].

The Cursor team: prompts as engineering, hidden from the user

The four founders of Cursor, the AI code editor, hold both positions at once, and are explicit about which applies to whom [2].

Inside the product, prompting is serious engineering. Arvid Lunnemark describes an internal system called Preempt, inspired by the way web pages are built. Prompts are written declaratively, like components with priorities, and a renderer fits them into the model's available context window [2]. The line where your cursor sits gets the highest priority, with priority dropping for lines farther away, and retrieval scores rank code from elsewhere in the codebase [2]. Separating the raw data from how it is rendered also makes prompts easy to debug and to test against old examples [2].

Then the sentence that matters for learners: users, the team says, shouldn't have to do this. They should write naturally while Cursor retrieves the right context [2]. When intent is unclear, the system could ask a clarifying question, show several options, or, as it now does, suggest relevant files to add [2].

Their broader view is that the goal is to carry intent to the machine with less and less effort. Lunnemark describes the aim of the Tab feature as making every action where your intent is already clear happen with a keypress, and says pressing Tab is really injecting intent; programming will become higher- and higher-bandwidth communication with the computer [2]. They do not expect natural language to take over entirely: sometimes it is easier to show an example, or even drag things around, than to explain [2]. A code migration that took two of them five days could someday take ten minutes by showing a few examples [2].

They also describe what remains hard. Real programming involves messy, half-specified instructions [2]. In a discussion of formally verifying code, part of the team pushes back that intent is often hard to specify [2]. One small habit they report works on both audiences: labeling dangerous code with comments on every line helps humans, who forget, and models, which pay more attention [2].

What they think stays human is judgment. Michael Truell says good engineering is made of countless micro-decisions and trade-offs, that "people's taste and creative ideas will be magnified," and the company's manifesto imagines an engineer who will "iterate at the speed of their judgment" [2].

Fei-Fei Li: teach it in school, and call it by its old name

Li, the Stanford computer scientist behind ImageNet, gives the strongest statement that prompting is lasting. Asked how essential the specificity of a prompt is, she says: "Prompting is very important. And that's a skill, right? That is a skill." She continues: "I would love to see our schools, K-12, teaching prompting." [3]

Her quiz explains what she means by the word. "Who is humanity's best prompter?" Her answer: "Socrates, if he were alive." The Socratic method, she says, is prompting and "seeking truth by asking questions," and we should go back to teaching children that [3].

She adds a related lesson from a Stanford undergraduate. Before these tools, when she had a question she would sometimes just ask the smart person next to her. Now she realizes she should not ask lazy questions, since it is so easy to get information first: "AI is forcing me not to be too lazy." [3]

Her reason for wanting everyone to learn is about agency. Her advice to students, teachers, doctors and policymakers alike is to learn what this technology is and how to use it, even without coding, because "By learning, one feels more in control" [3]. She worries about the opposite use, AI and passive technologies stripping young people of agency and motivation, since learning takes time, effort and sometimes pain [3]. She also notes that AI which learns your patterns of writing can already help you become a better communicator [3].

Manolis Kellis: we have always prompted each other

Kellis, an MIT computational biologist, widens the frame until prompting stops looking like a new technical skill at all [4].

Lex Fridman notes that a few prompts can push a language model far from its default. Kellis replies that humans are promptable too, revising an old saying: "show me your friends and I'll tell you who you'll become." [4] He tells students to ask themselves what he would say, since they carry an emulator of him in their heads [4]. He describes a dream in which deep insights about cancer came to him as if from a colleague, knowledge his own neurons produced only under the prompt of being that expert [4]. His favorite prompt, which he says works on his 10-year-old too, is to ask for thinking step by step [4].

He is fascinated that language models seem to separate content, knowledge and form, so that the same science can be delivered as a haiku or in Shakespeare's style [4]. For a user, that is the reason a request can specify the form of an answer separately from its substance.

On the stakes of learning to use the tools, he tells students: "you're not going to be replaced by AI but you're going to be replaced by people who use AI in your job." [4]

Aravind Srinivas: the product should do the work

Srinivas, chief executive of the answer engine Perplexity, argues the opposite of Li in words, and gives his reasons from product design [5].

He takes from Google's Larry Page the rule that "the user is never wrong." His own mother, who is not fluent in English, complained that Perplexity's answers were not relevant. His first instinct was to blame her query, until he realized the product should understand her [5]. He recounts Page's demonstration to the chief executive of the search company Excite, who dismissed Google's better results by saying a better-typed query would have worked on Excite too [5]. From this he concludes that prompt engineering won't last: "a better product should be one that allows you to be more lazy, not less." [5]

He does not think users are already good at this. He sees the biggest obstacle for his company as the fact that "people are not naturally good at asking questions," even though "Curiosity is unbounded in this world" [5]. His answer is to build the help into the product: suggested follow-up questions under every answer, and a search mode that breaks a question into steps for the user [5].

His own history shows where the prompting went. In 2022, building on early models, his team wrote many templates by hand, used dynamic few-shot prompts and caught errors with retries [5]. Perplexity's model is instructed to write like an academic and to say nothing it has not retrieved [5]. The prompt craft exists. It lives with the builder.

He also describes techniques that began as prompts and moved into the models. Chain of thought, forcing a model to produce intermediate reasoning, improves performance; he then describes research in which models are trained on their own generated explanations so that the reasoning is built in [5]. And he still uses a little prompting himself as a user, asking for an explanation at the level of a five-year-old for finance jargon and for equations when reading research [5].

Where They Agree, and Where They Don't

Builders prompt intensively, and none of them denies it. Askell revises prompts hundreds of times, Cursor has a rendering engine for them, and Perplexity ran on hand-written templates [1][2][5]. Where a prompt is part of a product, the work is real and is not going away soon.

Ordinary users should not need tricks. Askell says just ask [1]. Cursor says users should write naturally [2]. Srinivas says the product should let you be lazy [5]. Three of the five say this outright, from inside companies that would benefit if their users were experts.

The lasting part is asking and specifying well. Li's prompting is Socratic questioning [3]. Askell's is clear definition and seeing your request as a stranger would [1]. Srinivas agrees people are poor at asking questions and treats that as the central problem [5]. Cursor says intent is hard to specify and that judgment is what gets magnified [2].

The open disagreement is Li against Srinivas: teach people, or fix the product? Li wants prompting in the curriculum [3]. Srinivas wants the need for it designed away [5]. Each view comes from the speaker's job. Li is an educator worried about agency, and for her a person who can question well stays in control of the tool [3]. Srinivas is building for a mass audience that includes his mother, and for him every demand a product places on the user is a failure of the product [5]. They are less opposed than the words suggest, because they mean different things by prompting. Srinivas is predicting the end of prompt engineering, the business of finding wordings that work. Li is asking schools to teach inquiry. Srinivas's own product, with its suggested next questions, is an attempt to supply by design the habit Li wants taught [3][5].

A real difference remains. Li believes the effort is good for the learner, and that tools which remove effort can remove motivation [3]. Srinivas believes removing effort is the point [5]. A student could reasonably ask whose advice to take, and the sources suggest it depends on whether you are learning or just trying to get an answer.

They differ on how new this is. Kellis and Li both place prompting in old human practice, in friendship and teaching and Socratic dialogue [3][4]. Askell and the Cursor team describe behaviors specific to these systems: nudges that shift a probability, priorities inside a context window, sensitivity to small changes of wording [1][2].

They differ on whether language is the final interface. Li and Askell speak of words [1][3]. Cursor expects examples, gestures and keypresses to carry much of the intent [2].

Why It Works

Why wording matters today. Models respond to small changes in phrasing, and an emphatic instruction changes how often a behavior appears, not whether a rule exists [1]. Models pay more attention to what is flagged repeatedly [2]. Asking for intermediate reasoning improves results [5]. These are the facts that make prompt technique effective now.

Why technique decays. Each of those facts is something builders are working to remove. A system prompt line was deleted when training fixed the underlying habit [1]. Step-by-step reasoning is being trained into models and run automatically by products [5]. The Cursor team notes that a model built for long reasoning is excellent at well-posed problems and less good at grasping rough intent, which shows that models differ in ways a fixed bag of tricks will not track [2]. A technique learned for one model generation is a patch on that generation.

Why clarity does not decay. No model can retrieve what you did not say. Askell's exercise of reading your prompt cold is a way of finding what is in your head and not on the page [1]. Cursor's work on retrieving context automatically narrows that gap, and their own caveat about half-specified instructions shows it does not close [2]. Srinivas's diagnosis that people are not good at asking questions describes a human limit, which better models do not remove [5].

Why the model's structure rewards separate instructions. Kellis's observation that content and form come apart explains why saying who the answer is for and what shape it should take changes the result so reliably [4].

Why the skill transfers. Kellis's examples are the argument: the same prompt, think step by step, works on a child; asking what a mentor would say works on yourself [4]. Li's Socrates makes the same point from the other direction [3]. If prompting is a form of clear questioning, practice with machines improves a general ability.

Why learning it protects agency. Li ties understanding the tool to feeling in control and keeping one's dignity [3]. Kellis ties using it to staying employable [4].

Where It Applies, and Where It Doesn't

Deep prompt craft applies to people who build on models: writing system prompts, designing products, running the same instruction many thousands of times, or pushing for the last few percent of quality [1][2][5]. For them it is engineering, with testing against old examples and structured assembly of context [2].

For a person asking a question or getting help with a task, the sources point to plain language, with the lab that makes the model saying so itself [1][5].

The Socratic version applies to everyone and at every age, in Li's view, and is as much about education as about AI [3].

Prompting does not fix a tool's deeper limits. Srinivas lists the ways an answer engine goes wrong, including a model not smart enough for the query and retrieved material that is thin, stale or irrelevant, and none is cured by the user's wording [5]. Askell calls prompts a less robust way of patching problems [1]. The Cursor team reports that models are strikingly bad at finding bugs when simply asked, because that skill is rare in their training data [2].

It does not replace knowing the subject. Cursor's emphasis on judgment and taste, and Li's point about not handing over your agency, both mean the person still has to evaluate what comes back [2][3].

And the forecast has limits. Srinivas's prediction is a product builder's goal, and his own team's reliance on templates and instructions shows how far the present is from it [5]. Li's proposal is a wish for schools [3]. No one here offers evidence about how fast the tricks will stop mattering.

What To Do With It

1. For everyday use, just ask in plain words. That is Askell's advice, from the person who writes the prompts for the model you are asking [1]. Spend your effort on the question.

2. Before sending anything that matters, read it as a stranger would. Ask what the model would know if this were all it had. Add what is missing [1].

3. Define your terms. If you want something polite, brief or rigorous, say what you mean by that word, as Askell does before she writes a prompt [1].

4. When the answer is wrong, ask why. Ask what instruction would have prevented the mistake, and reuse it [1].

5. Say who the answer is for and what form it should take. Srinivas asks for a five-year-old's explanation or for equations; Kellis notes that models handle form separately from content [4][5].

6. Ask for step-by-step reasoning when a problem is hard, and expect to need it less. It works on models and on ten-year-olds, and newer systems increasingly do it on their own [4][5].

7. Show an example when describing is harder than showing. The Cursor team finds examples often carry intent better than explanation [2].

8. Practice the follow-up question. Li's model is Socrates, and Srinivas's product exists to suggest the next question because people rarely think of it [3][5]. Make the second and third question a habit.

9. If you build with models, treat prompts as code. Give parts of the context priorities, keep data separate from how it is rendered, test against old cases, and expect to iterate many times [1][2].

10. Invest in the durable half. Spend little time memorizing wordings that a model update may make irrelevant, and more on subject knowledge, clear writing and judgment about results, which every one of these speakers expects to matter more [1][2][3][4][5].

Sources

1. Dario Amodei: Anthropic CEO on Claude, AGI, the Future of AI, and Humanity · Lex Fridman Podcast
2. Cursor Team: Future of Programming with AI · Lex Fridman Podcast
3. Dr. Fei-Fei Li on How AI Learns, What It Can't Do, and Keeping Human Agency at the Center · Huberman Lab
4. Manolis Kellis on Evolution, Human Uniqueness and Living Alongside Superintelligent AI · Lex Fridman Podcast
5. Aravind Srinivas: Perplexity CEO on Future of AI, Search & the Internet · Lex Fridman Podcast