The question everyone keeps asking wrong

Over the past six months, I've been asked some version of the same question dozens of times: "How do I write a better prompt?" Product managers, founders, friends who run newsletters, even my mother. I always tried to give a thoughtful answer, but something never sat right. Eventually I figured out the problem: the question itself is too narrow. It's like asking "what should I say to the waiter to get a good meal?" You can teach someone better ordering technique, but what actually determines dinner quality is which restaurant they walked into.

This is the first in a series where I want to unpack a handful of new concepts that kept coming up in my AI engineering work over the past year. Not a glossary, but a walk through actual usage scenarios — why these concepts got invented, and how they relate to each other.

Today: the two most foundational ones. Prompt, and Context Engineering.

Prompt: a very unusual kind of talking

The word "prompt" sounds unremarkable. But it conceals something genuinely novel: this may be the first time in the history of software engineering that an API's input and output are both non-deterministic.

In traditional programming, a SQL query with the same input produces the same output. A function with the same arguments returns the same result. Prompts don't work this way. Ask ChatGPT to "write me an email" and you'll get something different every time. More subtly, a small change in phrasing — adding "use a formal tone" — can completely alter the result.

So what is a prompt, really? It's an API call written in natural language. Technically, it's the messages field inside an HTTP request body. In that sense it's no different from a SQL statement sent to a database. But in practice, it feels exactly like a conversation between two people.

This duality is precisely why the concept needed its own name.

I used to compare prompting to ordering food: the clearer you are, the more likely you'll get what you want. That analogy works for beginners, but it hides something important. Ordering only requires knowing what you want. Writing a good prompt often requires doing four things simultaneously: assigning a role ("you are a senior editor"), describing a task ("revise this paragraph"), setting constraints ("keep the original tone, under 500 words"), and providing examples ("something in this style").

Role, task, constraints, examples. Together, these form an engineering discipline. That's why "Prompt Engineering" became a field of its own, rather than just "learning to talk to AI."

The turning point: good prompts aren't enough

Up to this point, it might sound like mastering prompts is all you need. I thought so too, for a while.

The turning point came when I started using Claude Code on real projects. I once crafted an extremely detailed prompt — clear requirements, reference examples, explicit constraints. The output was still mediocre. After a long debugging session, I found the issue: the model was missing the project's tech stack, didn't know our framework, had no sense of existing code style, and was completely blind to the business context.

My prompt was fine. The problem was that the AI had seen too little before it started answering.

Think of it this way. You walk into a fine French restaurant and tell the waiter: "Your best steak, medium-well, with a red wine pairing." Clear, specific, even sophisticated. But if this waiter is on their first day, doesn't know what the kitchen has in stock, hasn't seen the wine list, and doesn't know you had an allergic reaction to shellfish last time — your eloquence won't save the meal.

What determines service quality isn't just what you say. It's how much the waiter already knows before you open your mouth.

Context Engineering: furnishing the room AI walks into

This brings us to the second concept: Context Engineering.

If a prompt is "what you say to AI," then context is "the room AI walks into." Context Engineering is the discipline of furnishing that room before AI starts working.

Staying with the restaurant analogy: before you say a word, a well-run restaurant has already done extensive prep. The type of restaurant determines the base menu (that's the System Prompt). Your membership profile records your preferences and allergies (that's Memory). Today's inventory and specials have been synced to the waiter (that's retrieved documents). Whether you're in a private room for a business dinner or at a family table — the waiter is aware of that scene (that's session state).

For the technically inclined, the mapping is clean:

The shift from Prompt Engineering to Context Engineering moves the central question: from "how do I say this clearly" to "what should AI see, and in what order."

This looks like a simple expansion of scope. It's actually a qualitative change. Language models have finite context windows. Even the most advanced models today handle a few hundred thousand tokens. Faced with all the code and documentation of a real project, if it doesn't fit, it doesn't fit. You have to make choices: what goes in, what gets cut, and how you order what remains.

This reminded me of search engines. Google's problem is: billions of web pages exist, a user types a query, you can only return the top ten results — how do you choose which ten? Context Engineering faces a structurally identical problem: millions of tokens of potentially relevant information, but a window of only a few hundred thousand. What makes the cut?

What you can do today

On the practical side, there are things you can improve at both levels right now.

At the prompt level, keep the four elements in mind: role, task, constraints, examples. You don't need all four every time, but having the framework helps. Often when AI underperforms, it's not because the model is inadequate — it's because you forgot to specify what role it should play or what boundaries to respect.

At the context level, pay attention to the capabilities your tools already offer. Claude Code's CLAUDE.md file is a textbook System Prompt entry point — you can write your project's tech stack, code conventions, and business rules there, and the AI reads it on every startup. Memory features in various AI assistants are essentially long-term context maintenance. RAG (Retrieval-Augmented Generation) dynamically injects relevant documents into each conversation.

The logic behind all these tools is the same: they help you furnish the room AI is about to walk into.

An unresolved question

One thing I haven't figured out yet.

The core challenge of Context Engineering is information triage. But triage requires judgment, and judgment itself — can that be delegated to AI too? In other words, letting AI decide what it needs to see. If you follow that thread to its conclusion, does the boundary between Prompt and Context dissolve entirely?

I'll save that question for later in the series. The next piece covers Agents and Agentic Workflows, and by then, "who decides what AI sees" becomes an even more pressing question.