TL;DR
- A prompt is the ask. Context is the ground it stands on: who this is for, what good looks like, the real material, and what to leave alone.
- When the AI gives you generic or wrong output, the reflex is to write a cleverer prompt. Usually the prompt was fine and the context was thin.
- More context is not better context. Dump everything in and the model loses the thread. Curation is the actual skill, and the boundary (what to ignore) is the load-bearing half.
- Write the context down once, in a small set of files next to the code, and every future task starts from ground instead of a guess. Stale context is worse than none, so treat it like a dependency you keep current.
This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real products, receipts included. New guides land there first.
A few weeks ago an AI i built into an app asked a real user to name a beach-party plan. First thirty seconds in the product. The app can technically make a plan called that, so it wasn't a hallucination exactly, it was worse: a real feature dragged to the front because the model had nothing better to go on. i had handed it a one-line description of the app and told it to get the user to a concrete first action. A one-line description is an invitation to guess. So it guessed, confidently, in front of someone i was trying to keep.
That was the moment context engineering stopped being a phrase i skimmed past and became a bug with a name. And here is the part that should get a senior dev's attention: the failure looked exactly like AI code that compiles clean and still ships a bug. Confident, plausible, wrong. The fix was never a better prompt.
a prompt is the ask, context is the ground
The prompt is what you want. "Write the migration." "Refactor this service." "Draft the onboarding." Short, and you already know how to write one. Context is everything the model needs to answer that well and doesn't have unless you give it: which service owns this, which files are generated and off-limits, what the system actually does and who is on the other side of it. The prompt points at a target. Context is whether the model can see the target or is throwing in the dark.
Most bad AI output is not a bad prompt. It is a fine prompt fired into an empty room. The model fills the empty room with the most statistically average thing, and average is exactly what makes you close the tab and call it overhyped.
the four things you are actually feeding it
When people say "context," they mean four different things stacked together. It helps to see them apart.
A prompt is the arrow. These four are the ground it lands on.
The goal. Not the task, the outcome. "Turn these contracts into a tracker" is a task. "so i can see at a glance which renewals are risky this quarter" is the goal. Give the model the why and it makes better calls on the hundred small things you didn't specify.
The ground truth. The real material, not a description of it. This is the one people skip. Don't tell the AI "our style is terse and functional," paste two modules that already read that way. Examples beat adjectives every time. A model shown three real things you like will out-perform any paragraph describing them.
The constraints. What good looks like and what to never do. The format. The interface it has to satisfy. The generated files it must not edit. Constraints are not the AI's handcuffs, they are how it knows it succeeded instead of guessing at your taste.
The boundary. What to leave out and what not to touch. This is the half nobody talks about, and it is coming next, because it is the one that separates people who are good at this from people who just paste more.
more context is not better context
Here is the counter-move, and it is the part everyone gets wrong.
Once you learn that thin context causes bad output, the obvious next step is to feed it everything. The whole repo. The entire history. Every doc, in case it helps. It feels thorough. It is the exact opposite of thorough.
A model has a working memory, and past a point, adding more doesn't inform it, it distracts it. The signal you actually needed gets buried under fifty files of nearly-relevant noise, and the answer gets vaguer, not sharper. i have watched a model give a worse answer to the same question after i "helpfully" pasted three more files. The good lines were in there. It just couldn't find them anymore.
So context engineering is not "add context until it works." It is "give it exactly what this task needs, and nothing that competes with that." Curation, not accumulation. Telling the model what to ignore is as load-bearing as telling it what to read. This is the same discipline as scoping a service token: you grant the access the job needs, not everything you own, because blast radius is real whether the risk is a leaked secret or a distracted model.
The test i use now is embarrassingly simple. Before i paste something in, i ask: does the model need this to answer, or am i adding it to feel safe? The second kind is the noise.
how to actually do it
You don't need a framework. You need four sentences before the task, roughly in this order.
- State the goal, not just the task. One line on the outcome you're actually after. "so that..." is the most useful phrase in the whole practice.
- Show, don't describe. Paste two or three real examples of what good looks like. A before, an after, a module you'd be happy to merge. This single move fixes most "it sounds generic" complaints.
- Name the constraints and the anti-goals. The format, the interface, the hard limits, and the one or two things it must never do. Short bullets are fine.
- Draw the boundary. Say what to use and what to ignore. "Only this package." "Don't touch the generated types." "The old implementation is background, not a template."
That's it. Four sentences turns a coin flip into something you'd actually ship.
write it down once
The last move is what makes this compound instead of repeat. The first time you assemble the context for a recurring job, don't throw it away. Put it in the repo, next to the code it describes. Next time, you point the AI at the folder and add one line for today's task. A five-minute setup becomes a five-second one, and the output stays consistent because the ground under it stopped moving.
On a real project this is not one file, it is a few, and the names are becoming a standard any agent already reads. PROJECT.md for what the thing is and why. CONTEXT.md for what you are working on right now. CLAUDE.md and AGENTS.md for the rules and conventions you want followed. README.md for the human who lands cold. And progress.md, the memory file from episode 02, for what happened last.
the context lives in the repo, not in your head. any AI you point at the folder reads it and knows where it is.
If episode 02 sounds like it is happening again, that is because it is. A memory folder is context that persists across sessions. A context file is the same instinct pointed at a single repo.
where this breaks
Two ways, both worth knowing.
Stale context is worse than no context. A context file that still describes last quarter's architecture will make the AI confidently wrong, and confidently wrong is the expensive kind. When the thing changes, change the file. It is a living note, not a monument, and it belongs in code review like anything else that drifts.
And context is not a substitute for the check. Grounding the model dramatically raises the floor, it does not remove your job of reading the diff before you trust it. A non-engineer has no compiler and no test suite to catch a confident lie, but neither does your prose. The review step is the job that does not get automated away, and it is its own episode later in this series.
The punchline is small and annoying and true: most of the time the AI wasn't wrong because it is dumb. It was wrong because it was guessing, and it was guessing because you didn't tell it the thing you assumed was obvious. Context engineering is just the discipline of saying the obvious thing out loud, once, and then reusing it.
I put together a context starter pack: the four-line context you write before a task, the set of files that give any AI your whole project's context (PROJECT, CONTEXT, CLAUDE, AGENTS, README, and the progress.md memory file from episode 02, each explained), and the one prompt that sets them up for you. It goes out through the newsletter first.
Written by Malik at Code Meet AI. This is episode 04 of Using AI, properly. Episode 02 was give the AI a memory, episode 03 was put the AI on the work around work. New guides land there first.
i'm Malik, i've been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. Next up: how to make the AI check its own work, before you do.
Top comments (0)