The freshest work in your head will crowd out the next answer

On July 29 I spent the morning debugging my own monitoring setup, the thing whose job is to tell me whether background work is still running. It had been dead for ten days and nobody knew, because the signal it kept sending back was green.

That afternoon I changed the subject. I asked the AI assistant I work with what a course on thinking and working with AI should teach, and what it should be called.

What came back was a course spine called "work you can verify," with a full lesson table, every lesson carrying a real worked example. Every one of those examples came from the work we had just finished that morning. The afternoon's request had not contained the word "verify" anywhere.

Part 1A good answer to a different question

Put that course spine on a table and read it cold and it passes everything. The structure is orderly, it runs easy to hard, each lesson has a reason to be where it is, and every example is real. Nothing was made up.

So the problem was not quality. It answered a different question. The ask, stated in the first sentence of the conversation, was a course about how to think alongside AI using tools you actually run, so that people could go build systems of their own. Verification was not in it.

I caught it myself, because I was the one who had set the brief: the spine on the page had not come from the request. It had come from the work we had just finished.

Left alone, the whole course would have been built on a spine I never wanted to teach, and we would have found out when students paid and did not get what they came for.

Part 2Why this is harder to catch than a bug

Earlier the same day I made the same mistake in a smaller way. Chasing a broken script, I named the cause from the line that looked most suspicious. Deleting that line changed nothing. The real cause was somewhere else entirely.

Both times the shape was identical: reach for whatever is nearest and assume it is relevant. In the morning the nearest thing was the line I had just read. In the afternoon it was the work I had just done.

The afternoon version is the more dangerous one, because a bug has a state you can test. Delete the suspect line, run it again, and five seconds later you know you guessed wrong. An answer to the wrong question has no command that turns red. It is clean on every axis you can measure, except the one axis nothing measures: whether it matches what was asked.

It also hides behind a story we tell ourselves. I had been on that topic all morning, so when a new question arrived it felt connected. That feeling of connection is the symptom, not the evidence.

Part 3Prompt engineering is not context engineering

When people say "just ask better," they usually mean working on the latest message: be specific, name the format, give an example. That is prompt engineering, and it genuinely fixes problems caused by a vague instruction.

The instruction above was not vague. What bent the answer was what was already in the room when the instruction arrived. Half a day of monitoring work was still in the same window. The model did not hallucinate; it used the material in front of it, which is what we want it to do in almost every other case.

The dividing line that actually helps:

• Prompt engineering answers: what did I ask this time?
• Context engineering answers: when I asked, what else was in the room, and did it belong there?

Problems that a rewritten instruction fixes are usually the first kind. Problems where more detail in the instruction keeps returning the same answer in a smoother wrapper are usually the second, because the material the model is drawing on has not changed.

So the fix for the second kind is not typing better. It is moving the new topic into a new window, or saying plainly which part of this conversation is not relevant to what comes next.

Part 4Restate the request in the asker's words

What I use now takes about ten seconds and needs no tooling.

1. Write the request as one sentence, in the asker's words, not your summary of it. "They want a course that teaches how to think alongside AI and then go build their own system." If you cannot write it, you have not read the request; you are reading your understanding of it.
2. Put the answer you are about to give next to that sentence and ask plainly whether it answers this, or answers the thing you happen to be better at.
3. Use one self-check: if the spine of your answer draws on the last two hours of work while the question never mentioned that work, that is a signal, not continuity.

The third one carries the most weight because it is checkable without arguing about taste. It does not ask whether the answer is good. It asks where the material came from.

It applies to people too. In a meeting that has spent an hour on one topic, the first answer everyone reaches for when a new question lands tends to be shaped like the last hour, not like the question.

This is where it differs from the verification lessons: no extra command helps, because technically nothing is wrong. The only thing that catches it is comparing the answer to the request word by word, before you build, not after, when you are asking whether the finished thing is right.

If you are working out which decisions an AI can make alone and which need a person first, human in the loop as three tiers is the other half of the same problem: how far you can let go and still steer.