The Phrase That Made Me Rethink Everything
A few months ago I kept seeing the term "context engineering" pop up everywhere — on Twitter, in AI newsletters, in Hacker News threads. And my first reaction was honestly eye-roll territory. I thought: great, another buzzword to replace the buzzword we already had.
But then I actually sat with it for a while. And I realized it wasn't just rebranding. It described something real that had quietly shifted in how the best AI practitioners were working — something I'd been doing myself without having a name for it.
So let me break down what actually changed, why it matters, and what it means for how you should be thinking about your AI workflows right now.
What Prompt Engineering Actually Was
When I first started using ChatGPT seriously, "prompt engineering" felt like a superpower. The idea was simple: if you could just find the magic words, the AI would do incredible things. Write it like a chef. Give it five examples. Add "think step by step" at the end. The whole discipline was about crafting the one message you send.
And that framing made sense — early on, the model's context window was small, interactions were mostly one-shot, and the input really was just: user types something, AI responds. The message itself was the whole game.
Here's roughly what that era looked like:
# The whole "system" was just this:
User: "Act as a senior Python developer with 10 years of experience.
Think step by step. Your output should be clean, commented code.
Write me a function that parses CSV files."
# That was it. The prompt was the product.The limitation? You were still only controlling one slice of the interaction. Everything else — what the model knew, what files it could see, what prior conversation existed — was either absent or completely out of your hands.
What Changed: Models Got Bigger Windows (and More Inputs)
Here's what actually shifted the game: context windows exploded in size, and models gained the ability to read files, search the web, call APIs, use memory, and run tools. Suddenly the "input" to the model wasn't just your one message. It was a whole ecosystem of information.
Think about what Claude or GPT-4 can see in a single interaction now:
- A system prompt you set up in advance
- Your entire conversation history
- Files you've uploaded
- Results from tool calls (like web searches or code execution)
- Retrieved documents from a RAG pipeline
- Memory from previous sessions
- Instructions from a CLAUDE.md file or custom instructions
That's not a prompt anymore. That's a whole information environment. And the quality of the AI's output depends on how well that entire environment is designed — not just how clever your individual message was.
The Core Shift
Prompt engineering asks: "What's the best way to phrase this message?" Context engineering asks: "What's the best information environment to put the model in so it can do its job?" One is about wording. The other is about architecture.
Context Engineering: A Working Definition
Context engineering is the practice of intentionally designing everything a model can see during an interaction — not just the user message, but the system prompt, the retrieved documents, the tool outputs, the conversation history, and anything else that lands in the context window.
The person who coined the term (or at least popularized it) in its current form was Andrej Karpathy, who described it as "the delicate art of filling the context window with just the right information." I love that framing. Delicate. Because it really is — too much information and you overwhelm the model or dilute the signal. Too little and it hallucinates or makes dumb mistakes because it's missing key facts.
Here's what a context-engineered setup might look like compared to a raw prompt:
# System prompt (set once, always present):
You are a backend Python developer working on a FastAPI codebase.
Follow our internal style guide: type hints required, docstrings mandatory.
Never use global variables. Prefer dependency injection.
# Retrieved context (injected automatically by RAG):
[Relevant excerpt from codebase: existing auth middleware, 847 tokens]
[Relevant excerpt from style guide: error handling patterns, 312 tokens]
# Conversation history (managed and trimmed):
[Last 3 turns of conversation, summarized to save tokens]
# User message (finally, the actual ask):
User: "Add rate limiting to the /login endpoint."
# Short message, huge context. That's context engineering.Notice the user message is tiny. It doesn't need to explain the whole project, the coding style, or the existing patterns — because all of that is already in the context. The message is just the delta: the new thing you want done today.
Why This Changes How You Build
When I internalized this shift, it changed the questions I ask before starting an AI-assisted task. Instead of "how should I phrase this prompt?" I now ask:
- What does the model need to know to do this well? (and how do I get that into the context)
- What should it never do? (and where do I put those guardrails)
- What information is redundant or noisy? (and how do I keep it out)
- How will context grow over a long session? (and do I have a plan for that)
That last one trips people up constantly. If you're using an agent that does 20 tool calls in a row, the context window fills up fast. Managing that — deciding what to summarize, what to drop, what to keep verbatim — is a skill in itself. It's why features like Claude Code's auto-compact exist.
Practical Exercise
Next time you start an AI task, before typing anything, write down: "What three things does the model need to know to do this well?" Then figure out how to get each one into the context — whether through a system prompt, an uploaded file, or explicit setup in your message.
Prompt Engineering Isn't Dead — It's Nested Inside
I want to be clear about something: prompt engineering didn't go away. The craft of writing clear, specific, well-structured instructions still matters enormously. A bad system prompt will tank your results no matter how good your context architecture is.
Think of it like this. Prompt engineering is still a skill — it's just now one layer of a bigger practice. Context engineering is the outer shell. Inside that shell, you still need to write good prompts. You need clear instructions, good examples, explicit constraints. All that stuff still applies.
What changed is that the prompt is no longer the whole product. It's one component in a larger system you're designing.
For beginners, this is actually good news. You don't have to master every trick and hack of prompt phrasing to get great results. If you design the context well — give the model the right documents, set up a solid system prompt, manage the conversation history thoughtfully — your individual messages can be pretty simple and direct. Plain English works fine when the environment is set up right.
Three Habits That Make You a Better Context Engineer
After thinking about this a lot and experimenting with it in my own work, here are the three habits that have made the biggest difference for me:
1. Write a project brief before any major AI session. Before I start a long coding session or a writing project with AI, I write 3-5 sentences describing the project, the constraints, and the desired style. Then I paste that at the start of every conversation or into my system prompt. This single habit improved my results more than any prompt trick I've ever learned.
2. Treat your system prompt like a constitution. Your system prompt is the highest-authority document in the context. It sets the rules everything else operates under. Don't treat it as an afterthought — write it carefully, save it, version it. A great system prompt that you reuse is worth more than a hundred clever one-off prompts.
3. Audit your context before you blame the model. When I get a bad output now, my first question isn't "why did the AI fail?" It's "what was in the context when it failed?" Usually the answer is: the model was missing something important, or it was drowning in irrelevant information. Fix the context first, then see if the problem persists.
# Paste this at the start of every new AI session:
Project: [Name]
Stack: [Technologies]
Goal today: [Specific task]
Constraints: [What to avoid, style rules, etc.]
Context you need: [Attach files, paste relevant code]The Bottom Line
Prompt engineering was about finding the right words. Context engineering is about building the right environment. The field moved this way because models got more powerful, windows got bigger, and the inputs got more complex. One clever sentence can't keep up with that — but a thoughtfully designed context can.
If you take one thing from this: stop thinking about what to say to the AI, and start thinking about what the AI needs to see. Build that environment first. Then say whatever you need to say inside it. Your results will improve in ways that feel almost unfair compared to what you were getting before.
It's a different mindset, but once it clicks, you won't go back.
More tutorials in this category, or explore the full field guide.