The brilliant intern with no memory
In one line
The single most useful analogy for working with a model — someone who has read everything, remembers nothing between conversations, and sounds equally sure either way.
The situation
You have been handed a new colleague. They have read, roughly, the entire public internet, and they write well in forty languages. They also have no memory of yesterday, have never seen your codebase or your customers, cannot look anything up unless you hand it to them, and will answer every question in the same confident tone whether or not they know.
That is a fair description of a language model at time, and it is worth holding onto because every engineering pattern in this site is something you would do instinctively when delegating to that person.
What you would do without being told#
You would brief them precisely. Not "handle support", but "here is the tone, here are three good replies, here is what you must never promise". That briefing is the prompt, and because the intern forgets it the moment the conversation ends, you re-send it every single time. The finite space you have for it is the .
You would hand them the documents. They cannot open your wiki. If the answer depends on the refund policy, the policy has to be on the desk in front of them, today's version. That habit is retrieval — and its failure mode is handing over the wrong document and getting a beautifully written answer from it.
You would check the output before it went out. Not because they are bad at the job, but because confidence and correctness are uncorrelated in this colleague. When they are unsure they do not say so; they produce something plausible. That is , and it is not malice or a bug — it is what "always answer fluently" looks like when the knowledge runs out.
You would not give them your credentials. They can draft the refund; they should not be able to issue it. Anything irreversible goes through you, or through a rule you wrote. That rule, living in code rather than in the briefing, is a — and it is the only part of the arrangement whose behaviour you can actually guarantee.
Where the analogy earns its keep#
The analogy predicts the surprising things. Why does a long conversation get worse? Because the briefing is being crowded off the desk by the transcript. Why does telling the model "our timeout is 30 seconds" not stick? Because there is no yesterday. Why does a retrieved document containing "ignore your instructions" cause trouble? Because the intern cannot tell which sheet of paper on the desk came from you.
It also predicts the fixes. A better briefing, the right documents, a check on the output, and the keys kept in your pocket. Nothing in the rest of this site contradicts that list; it mostly makes each item precise.
Questions to ask
- What is on the desk for this request, and what is missing from it?
- What have I asked for that I would never let a new hire do unsupervised?
- If this answer is wrong, how would anyone know?
- What am I re-explaining every time that should be written down once?
Mindset
Treat the model as a capable colleague with a specific disability — no memory, no lookup, no sense of its own uncertainty — and design around the disability rather than being surprised by it. The engineering is the accommodation.
Goes deeper in
Phase 2 · 6 min
Training vs inference
Training is a write path you will almost certainly never run; inference is a stateless read path, and conflating the two is the source of most bad architecture decisions here.
Phase 3 · 6 min
Context engineering
Deciding what occupies a finite window, in what order, on every call — and it is mostly a discipline of leaving things out.
Phase 4 · 7 min
Agents & tool use
A loop where the model picks a tool and your code decides whether to run it, and every interesting problem is in the loop rather than in the model.
Got the shape of it?
Examples do not count toward phase progress — that stays on the topics. This is just so the list remembers what you have seen.