An inspector for the prompt
Juan builds an internal tool to debug Severo's brain: a bench where he picks a level, topic, and exercise type, runs the adventure-mode conversation, and sees the composite prompt broken out and color-coded by its parts (system, conversation, user knowledge, topic, vocabulary). When an exercise drifts (a physical-appearance topic ending on a restaurant menu), he can trace exactly which sub-prompt caused it. Plus a batch button to generate ten exercises at once and compare them, so he can audit the prompt without waiting for ten users to report back. The insight: an LLM's prompt is many mini-prompts stacked, and you can't fix drift you can't see.
// trace: where this idea came from
- ↳ video diary @ 4:48 (el prompt de Severo son muchos mini-prompts)
- ↳ video diary @ 5:35 (el botón batch, diez ejercicios de una vez)
- ↳ Entry 229-1: The lemma is the unit (el backend cuyos prompts aquí se inspeccionan)
The backend grew a debugger. Juan builds a bench where he selects a CEFR level, a sphere, a topic, and an exercise type, then runs the adventure-mode conversation exactly as the app would, watching the state rotate as the hidden instruction re-injects a new topic every five to ten turns ▸ 2:53. The point is the panel beside it: the prompt sent to Gemini, broken into its parts and color-coded, because Severo’s prompt “está compuesto por muchos mini prompts”, the system prompt, the conversation, the user’s known vocabulary, the topic, all stacked into one call ▸ 4:48.
The reason it exists is drift. An exercise seeded with “my physical appearance” wandered off into water, coffee, restaurant menus ▸ 4:33, and without the inspector he could only see the wrong answer, not the reason. With it, he can ask how Severo arrived there, tracing the bad output back to whichever sub-prompt let it slip ▸ 5:09, and read the raw API response underneath.
no puedes arreglar una deriva que no ves →
The batch button is the multiplier: generate ten exercises at once and compare them side by side ▸ 5:35, so he doesn’t have to wait for ten users to install the app and report which exercises made sense ▸ 5:47. It’s the fast-feedback thesis applied to prompt engineering: instead of shipping and waiting, he manufactures ten reactions in a second and reads them himself. The missing piece he names is closing the loop, letting the bench rewrite the prompt and push it to the backend in place ▸ 6:09. A prompt you can’t inspect is a black box you can only shake; break it into labeled parts and the drift finally has an address…
// continued in
no entry has continued this idea yet: the arc is still open