The better Claude Code gets, the easier it becomes for developers to lose one basic thing: knowing what just happened.

Thariq shared a prompt on X from Suzanne, someone inside the Anthropic orbit. On the surface, it asks Claude to act as an effective teacher. In practice, it points at one of the most underrated control problems in agentic coding: the work can be delegated to an agent, but understanding cannot be outsourced with it.

The core of the prompt is not “please explain this.” It asks Claude to keep a running checklist during the session and continuously verify that the human understands three things: why the problem existed, why the solution was designed this way, and what the change will affect.

Mogu murmur:

The interesting part is not the writing style. It is the posture. A lot of people use AI agents like food delivery: “Bring it to the door, thanks.” Suzanne’s prompt is more like asking the chef to cook while explaining the heat, the ingredients, and what would break if the recipe changed. The first version gets dinner. The second version makes the human better. (⁠￣⁠▽⁠￣⁠)

Staying in the loop is not staring at logs

Many people think “stay in the loop” means watching Claude’s terminal output: what files changed, which tests ran, what diff appeared. That is useful, but it is the lowest level of synchronization.

The real problem appears after an agent runs for half an hour, touches many places, fixes three surprise errors, and ends with one dangerous sentence: “done.” That sentence feels like closure. Often, it is where understanding starts leaking.

Suzanne’s prompt raises the target from “know what the agent did” to “reconstruct why the agent did it.” These are not the same.

Knowing what happened is a commit log. Knowing why it happened is control.

The prompt verifies three layers of understanding

The checklist Suzanne asks Claude to maintain has three layers.

The first layer is the problem: what the problem is, why it existed, and what branches or alternative explanations were in play. This matters because the most common debugging disaster is not fixing the wrong code. It is believing the wrong story about the problem from the start.

The second layer is the solution: what changed, why this design was chosen, and what tradeoffs and edge cases exist. Code that runs is not the same as architecture that holds.

The third layer is broader context: why this matters and what the change will affect. Without this layer, the developer only knows that the current bug is gone, not what product behavior, operations, tests, or future work has been touched.

This is a useful post-agent verification rule: do not only ask whether the tests passed. Ask whether the human caught up.

Mogu 's hot take:

The scary part of agentic coding is not only that AI can be wrong. It is that AI can be right while the human has no idea why. Then, the next time it is wrong, the operator may press approve with the same confidence. It is like having a great driver in the passenger seat who never explains the turns. Sit there long enough, and the human forgets to watch the road.

Teach-back beats summary

The most valuable line in the prompt asks Claude to make the human restate their understanding first, then fill in the gaps.

That is much stronger than a summary. A summary is the agent packaging the session for the human. Teach-back makes the human rebuild the understanding. One is meeting notes. The other is being asked to explain what the meeting decided.

In a coding session, teach-back catches common holes:

  • knowing the symptom but not the root cause
  • knowing the fix but not the tradeoff
  • knowing the happy path but not the failure mode
  • knowing that this run passed but not how to recognize the same pattern next time

If those holes stay open, the more work the agent completes, the more the human becomes an external acceptance tester for their own project.

The quiz is not school. It is an anti-fake-understanding device

The prompt also asks Claude to use open-ended or multiple-choice questions, and to show code or use a debugger when necessary. That can sound like tutoring theater, but inside an agent workflow it makes sense.

“Looks understood” is a very deceptive state. Agent explanations are usually smooth, and smoothness is easy to confuse with understanding. The real test is whether the same bug would still be recognizable if it showed up in a slightly different shape.

That is why this prompt is not just prompt engineering. It is workflow design. It turns Claude from a contractor into a contractor, coach, and verifier.

Of course, the full version should not run for every tiny change. Small edits only need a quick check. Architecture changes, debugging sessions, and multi-file refactors deserve the full loop. The point is not to make work slower. It is to avoid moving so fast that the human falls out of the loop.

How gu-log readers can use this

This prompt is most useful in three situations.

First: after an agent finishes a complicated task. Do not accept only “done.” Ask for problem, solution, edge cases, and impact. Then ask the operator to restate the high-level understanding.

Second: when a debugging session changes direction. Whenever the agent changes its hypothesis, it should explain why the old hypothesis failed, why the new one is plausible, and which branches remain unproven.

Third: before PR review. The agent should not only list changed files. It should explain the design tradeoffs and risks. File lists can come later. First, the human needs the high-level shape.

Used this way, Claude is not forcing the human back into every line of code. It is putting the human back into the decision seat.

Conclusion

This prompt traveled because it names a very ordinary fear: as agents get stronger, humans can slowly become project managers who only nod along.

A mature agent workflow is not just about making AI do more. It is about making the human lose less: less context, less judgment, less ability to recognize the same problem next time.

Claude can drive. The steering wheel should not become decoration.