Mapa del recorrido
🔬 Leer la evolución mediante diffs
Cada línea +/− es una decisión
🗜️ Consolidación
Reducir sin perder comportamiento
🛡️ Seguridad por principio
El principio, nunca el mecanismo
🪜 Prioridad y capas
Quién manda y qué es dinámico
🧠 Destilación: recuperar el cerebro
El corazón del curso — de los logs a la guía ⭐
⚙️ Esfuerzo × garantía estricta
Guía flexible + barreras que no fallan
🏁 Proyecto final
Tu system prompt versionado
Contenido detallado
🔬 Leer la evolución mediante diffs
Cuando un laboratorio cambia de versión, deja un rastro: el diff entre el prompt antiguo y el nuevo. Leer ese rastro es arqueología de decisiones: cada línea añadida, eliminada o renombrada cuenta por qué alguien cambió de opinión. Aquí lees un diff como investigador.
Adición, eliminación, reescritura y cambio de nombre: cada tipo tiene una intención diferente. El primer paso de la lectura es separar qué cambió de cómo cambió.
El lector aficionado solo ve las adiciones y confunde reescritura con cambio de nombre. Distinguir los cuatro tipos permite separar registrar de entender un cambio.
Adición (+) · eliminación (−) · reescritura (≈) · cambio de nombre (~) · caso de estudio Opus 4.8 → Fable 5.
La regla más subestimada: quien solo lee lo que entró lee la mitad del libro. Lo que salió fue asimilado durante el entrenamiento (se convirtió en ruido) o se consolidó en un principio.
La madurez de un prompt se mide por la última vez que se eliminó algo de él. Un prompt que solo crece se está pudriendo por dentro.
Interiorizado = ruido · consolidado = principio · search_first desapareció · quitar también es editar.
Reconstruir el problema que probablemente resuelve el cambio — las armas se convirtieron en principio, las drogas obtuvieron una excepción vital, se empezó a respetar el fin de la conversación.
La motivación inferida es una interpretación tuya, no una declaración del lab. Inferir es válido siempre que no confundas una hipótesis con una verdad declarada.
¿A qué incidente responde esto? · motivación probable · honestidad epistémica · el diff es un registro de problemas vividos.
El cambio más sutil no modifica ninguna palabra del contenido: copyright_compliance → core_copyright_principle. El texto permanece, la etiqueta cambia.
Siempre eliges cómo se ve el modelo obedeciendo — y eso cambia cómo obedece. «Compliance» cumple; «principle» razona ante casos nuevos.
Prohibición vs. principio · compliance vs core_principle · renombra según la intención · el nombre de un valor generaliza.
Cada cambio específico esconde una lección que sirve fuera de contexto. La reescritura de self-harm se convierte en «ejemplo + criterio generador > solo ejemplos».
Si solo guardas el caso, nada se transfiere. La lección se aplica a tu siguiente prompt, como estudiar partidas de ajedrez para aprender los principios.
Caso × lección · principio > lista · evolucionar ≠ crecer · heredar el método sin heredar la mente.
El protocolo completo: para cada cambio, clasifica el tipo, infiere la motivación probable y destila la lección — y revisa el saldo (+56 líneas / −7 bloques).
La misma lente de análisis es la que usas para reducir tu propio prompt después. Leer diffs cierra el ciclo con la consolidación del 3.2.
Clasifica · lee los − · extrae la lección · el saldo (estructura > caracteres).
🗜️ Consolidación: reducir el volumen sin perder el comportamiento
En 3.1 leíste la evolución desde afuera; ahora toca actuar. La ronda de consolidación toma un prompt que no deja de crecer y lo desinfla — fusionando reglas pequeñas en principios — sin perder ni una garantía de comportamiento. La regla de oro: nada se elimina sin motivo y sin prueba.
La entropía del prompt: cada problema se convierte en una regla nueva, ninguna se elimina y el documento acaba siendo un monstruo que nadie se atreve a tocar.
Un prompt inflado diluye la atención del modelo y oculta contradicciones. Reconocer el síntoma es el primer paso para tratarlo.
Entropía del prompt · regla por incidente · atención diluida · nadie se atreve a borrar.
Un ritual programado: cada N reglas que agregues, detente y revisa todo de una vez — fusiona, elimina, reescribe — en vez de seguir acumulando.
Consolidar de manera intencional y periódica es lo que evita el deterioro. Es mantenimiento, no una reparación de emergencia.
Ritual periódico · cada N reglas · refactorizar el prompt · mantenimiento, no pánico.
El filtro aplicado a cada regla: ¿el modelo ya hace esto por sí solo? ¿se puede fusionar en un principio más general? ¿qué prueba fallaría sin ella?
Las tres preguntas convierten la "limpieza por intuición" en una decisión justificable. Cada regla demuestra su valor o se elimina.
¿Ya lo hace por su cuenta? · ¿Se puede fusionar? · ¿Qué prueba falla si falta? · Decisión justificable.
La barrera de consolidación: toda regla lleva el motivo de su existencia y una prueba que fallaría sin ella. Sin ambas cosas, no merece quedarse.
Es lo que te protege de eliminar algo importante por error — y de conservar algo inútil por miedo. La prueba decide, no la intuición.
Porqué documentado · prueba que fallaría · evidencia por regla · pruebas > miedo.
El ejemplo canónico: la evolución de Opus 4.8 → Fable 5 ganó contenido (+56 líneas), pero perdió estructura (−7 bloques). Creció y se desinfló al mismo tiempo.
Es la prueba viva de que «evolucionar ≠ crecer». Un equipo maduro agrega lo que faltaba y elimina lo que el entrenamiento ya incorporó, en el mismo diff.
+56 líneas / −7 bloques · el contenido aumenta, la estructura disminuye · el saldo > el volumen · la madurez es visible.
El contrapunto: consolidar antes de haber visto el comportamiento real es optimización prematura. Sin suficientes casos, fusionas reglas que todavía no entiendes.
Reducir demasiado pronto es tan peligroso como aumentar: puedes generalizar un principio equivocado. Espera a tener datos antes de fusionar.
Optimización prematura · espera los datos · principio equivocado · la madurez tiene su momento.
🛡️ Seguridad por principio, no por mecánica
La lección más delicada de los labs: en seguridad, lo que escribes para proteger también puede enseñar a atacar. La solución es declarar el principio, nunca la mecánica de detección, y darle al modelo un desencadenante de rechazo que pueda reconocer mediante su propio razonamiento.
El caso de Fable 5: la política de seguridad infantil se mantiene en el nivel del principio y del patrón, sin detallar las señales que usa la detección.
Detallar la mecánica de detección en un prompt es dar el mapa para eludirla. El nivel adecuado es el principio, no el procedimiento.
Nivel del principio · no detallar señales · basta con el patrón · el prompt es legible para quien ataca.
El riesgo central de la seguridad: el conocimiento que protege es simétrico al que ataca. Explicar cómo detectar es explicar cómo evadir.
Reconocer la simetría es lo que te hace pensarlo dos veces antes de escribir la mecánica. La defensa y el ataque comparten la misma información.
Simetría del conocimiento · educar = armar · piensa en el lector hostil · información de doble filo.
La regla práctica: escribe el valor de alto nivel («protege X») y deja que el modelo derive cómo aplicarlo, sin enumerar cómo reconocer cada intento.
El principio cubre el caso que la lista no previó y no impone el método. Es más sólido y más seguro a la vez.
Principio > mecánica · alto nivel · derivar la aplicación · no entregues el método.
Un disparador introspectivo: if you find yourself reframing… entonces rechaza. La señal de alerta es que el propio modelo se sorprenda eludiendo la regla.
En lugar de una lista de prohibiciones que se puede eludir, el detonante usa el razonamiento del modelo como sensor: detecta la evasión y se detiene.
Desencadenante introspectivo · el reenmarcado como señal · REFUSE · el razonamiento es el sensor.
El paso siguiente al «no»: mantenerte alerta en los turnos posteriores, porque la solicitud puede volver dividida en partes o reformulada para eludir la negativa.
Una negativa aislada no cierra el riesgo si el modelo «olvida» en el turno siguiente. La precaución debe mantenerse incluso después de la propia negativa.
Atención tras el rechazo · solicitud fragmentada · reformulación a continuación · el riesgo persiste.
La forma del rechazo: una respuesta conversacional y humana, sin volcar listas de políticas ni dar sermones, que preserve la dignidad de la conversación.
Una negativa fría y burocrática aleja al usuario legítimo y no ayuda a nadie. El tono correcto rechaza la solicitud sin castigar a la persona.
Conversacional · sin viñetas · sin sermones · firme y humano.
🪜 Prioridad y capas
Cuando dos instrucciones entran en conflicto, ¿cuál prevalece? ¿Y qué es eso de <system-reminder> que aparece en medio de la conversación? Este módulo separa el comportamiento estable (el prompt) del estado dinámico (la capa inyectada por el harness) — y muestra por qué esta arquitectura escala con el tiempo.
La regla que establece la precedencia entre instrucciones en conflicto: la política central está por encima de system, system por encima del usuario, el usuario por encima de lo predeterminado.
Sin un orden explícito, el conflicto entre instrucciones deja el comportamiento al azar. La jerarquía indica de antemano cuál prevalece.
Precedencia declarada · política central al principio · resolver conflictos · nada al azar.
La cadena, desglosada eslabón por eslabón, con el ejemplo real de precedencia de copyright: desde la seguridad en la cima hasta el comportamiento predeterminado.
Ver la cadena completa muestra dónde encaja cada instrucción de tu prompt y por qué una regla «débil» no derriba una «fuerte».
Eslabón por eslabón · cadena de precedencia de copyright · seguridad innegociable · cada nivel en su lugar.
O <system-reminder>: una capa de contexto inyectada por el harness durante la ejecución: estado del momento, no una regla fija del prompt.
Es como el sistema transmite información dinámica (conversación larga, recordatorio de una regla) sin reescribir el prompt estable. Entenderlo explica muchos comportamientos.
<system-reminder> · inyectado por el harness · estado actual · capa dinámica.
La distinción crucial: el reminder es injected by the harness, not the user — es contexto que orienta, no una instrucción del usuario que deba obedecerse ciegamente.
Tratar el contexto como una orden (o viceversa) rompe la jerarquía. El modelo necesita saber el origen para ponderar correctamente lo que lee.
Contexto ≠ instrucción · el origen importa · no es el usuario quien habla · pondera según la fuente.
La separación de responsabilidades: el prompt guarda el comportamiento que siempre se aplica; el reminder lleva el estado que cambia de turno en turno.
Mezclar ambos infla el prompt con cosas efímeras. Mantener cada capa en su lugar deja el prompt estable y conciso, y el estado actualizado.
Estable vs. dinámico · cada capa en su lugar · no infla el prompt · separación de responsabilidades.
La regla que resuelve el conflicto entre lo que pide el usuario ahora y lo que guardó antes la memoria/auto-memory: prevalece la solicitud actual del usuario.
La memoria que se impone al usuario genera un agente terco, atado a preferencias antiguas. Lo que el usuario informa ahora debe prevalecer sobre lo recordado.
Usuario > memoria · el presente prevalece · sin terquedad · una preferencia antigua no es un obstáculo.
🧠 Destilación: recuperar el cerebro
El corazón del curso. Perdimos los pesos de Fable, pero quedaron los logs. Este módulo te enseña el método para recuperar el «cerebro» de un agente a partir de sus propios registros: encontrar los JSONL, reducir el ruido con un script, perfilar el comportamiento con números y sintetizar una guía de decisión para indicar a un modelo nuevo.
La idea fundacional: no tienes los pesos del modelo, pero sí el rastro de lo que hizo, y el comportamiento de un buen agente está íntegro en esos logs.
Replantea qué significa "recuperar" un modelo: no es volver a entrenarlo, sino destilar el método observable del rastro que dejó.
Sin pesos, con logs · comportamiento observable · destilar ≠ entrenar · el rastro basta.
El paso práctico: localizar los archivos .jsonl de sesión donde queda registrado cada turno del agente: entrada, razonamiento, acción y resultado.
Sin saber dónde vive el registro, no hay materia prima. Encontrar los JSONL es abrir la caja negra del comportamiento.
Archivos .jsonl · sesiones registradas · turno a turno · la materia prima.
La disciplina clave: filtrar y resumir los logs con un script Python; nunca volcar cientos de turnos sin procesar en la ventana de contexto del modelo.
Poner el log sin procesar en el contexto es caro, lento y supera el límite. El script hace el trabajo pesado fuera del modelo y entrega solo la señal.
Script > contexto · procesar fuera del modelo · señal, no ruido · no satures la ventana.
El recorte: entre todos los turnos, aislar solo los del agente cuyo comportamiento quieres destilar — separando el cerebro objetivo del resto del sistema.
Mezclar agentes diferentes confunde los patrones y diluye el perfil. Filtrar según el objetivo es lo que da foco a la destilación.
Segmentación por agente · aislar el objetivo · no mezclar cerebros · centrarse en el perfil.
Cuantificar el perfil a partir de los 429 turnos: 97% con razonamiento, 84% razonando antes de la primera acción, 87% reevaluando, 23% con prueba real.
Los números convierten una impresión en un retrato. Revelan qué prioriza realmente el agente: pensar mucho antes de actuar, reevaluar casi siempre.
429 turnos · 97% razonamiento · 84% antes de la acción · 87% reevalúa · 23% prueba real.
El paso final: convertir el perfil numérico en una guía para decidir —el decision loop destilado— y dirigir la sesión de un modelo nuevo a esa guía.
Es aquí donde el cerebro «vuelve»: el método observado se convierte en una instrucción reutilizable. Heredas la disciplina del agente sin tener sus pesos.
Perfil → guía · el decision loop · señalar el nuevo modelo · el cerebro recuperado.
⚙️ Esfuerzo × garantía estricta
Una guía de comportamiento es solo «mejor esfuerzo» — el modelo intenta seguirla, pero puede fallar. Para lo que debe garantizarse, no lo pides: lo bloqueas. Este módulo separa la disposición (flexible) de las garantías estrictas — densidad de razonamiento mediante effortLevel, hábito determinista mediante hook, y muestra dónde vive cada regla.
La naturaleza de la guía: las instrucciones de comportamiento inclinan al modelo en una dirección, pero no la imponen. Es una disposición, no una garantía.
Confiar en un prompt para algo que siempre debe salir bien es apostar. Conocer el límite de la guía te indica cuándo recurrir a una restricción estricta.
Mejor esfuerzo · disposición ≠ garantía · el prompt inclina · conoce el límite.
La palanca adecuada para «pensar más»: el effortLevel (xhigh/max), que controla la densidad del razonamiento, no el antiguo MAX_THINKING_TOKENS.
Pedir «piensa con cuidado» en el prompt es una intención; subir el effortLevel es una configuración que realmente cambia cuánto razona el modelo.
effortLevel xhigh/max · densidad de razonamiento · configuración, no prompt · ≠ presupuesto de tokens.
La barrera estricta: un hook PostToolUse que activa la prueba automáticamente después de cada edición — el harness la ejecuta, el modelo no la «recuerda».
Lo que debe ocurrir siempre no puede depender de la disposición del modelo. El hook garantiza el hábito de forma determinista.
PostToolUse · el harness lo fuerza · determinista · hábito garantizado.
La decisión sobre dónde ubicarlo: el CLAUDE.md siempre se carga (en cada sesión), mientras que la auto-memory está condicionada por la relevancia: solo se incluye cuando el contexto la requiere.
Poner una regla crítica solo en la auto-memory es arriesgarse a que no aparezca cuando importa. El lugar donde está la regla determina si es confiable.
CLAUDE.md siempre se carga · auto-memory condicionada por la relevancia · dónde > qué · garantizar la presencia.
El alcance adecuado de los output styles: moldean cómo suena el agente y qué papel representa, pero no imponen la disciplina del proceso (probar, reevaluar, verificar).
Esperar disciplina agéntica de un estilo de salida es usar la herramienta equivocada. El tono es el tono; el comportamiento operativo va en otro lugar.
Tono y papel · ≠ disciplina · herramienta adecuada para el fin adecuado · el estilo no verifica.
La síntesis: la guía de disposición da dirección y sentido común; las barreras estrictas (hooks, effortLevel, dónde vive la regla) garantizan lo que no puede fallar. Juntas, forman el sistema.
Solo el prompt es frágil; solo el bloqueo es rígido y ciego. La combinación es lo que produce un agente flexible y confiable a la vez.
La guía orienta + las barreras garantizan · flexible + firme · flexible y confiable · el sistema completo.
🏁 Proyecto final: tu system prompt versionado
El momento de unirlo todo. Tú creas tu propio system prompt —PMV, persona, loop y seguridad—, lo versionas con diffs, escribes el porqué y la prueba de cada regla, redactas tu guía de disposición y la complementas con límites estrictos. El entregable es tuyo: un prompt y una guía versionados, listos para evolucionar como evolucionan los labs.
El armado del prompt final reúne las piezas del curso: el Mínimo Viable, la persona de cuatro ejes, el Loop operativo y los bloques de seguridad.
Es la integración de todo lo que practicaste, sin repetir el error de recargarlo todo. Cada pieza se incluye porque tu caso la necesita, no «por si acaso».
PMV + persona + loop + seguridad · integrar sin inflar · solo lo que el caso requiere · prompt completo.
Trata el prompt como un artefacto versionado: guarda cada versión y compárala con diff, cerrando el ciclo que aprendiste a leer en el 3.1.
Crear versiones hace que la evolución sea visible y reversible. Empiezas a leer tu propio diff y a aplicarte el método que usabas en los labs.
Prompt como código · guardar versiones · diff propio · evolución visible y reversible.
Aplicar la regla de oro del 3.2 a tu prompt: cada regla acompañada de por qué existe y de la prueba que fallaría sin ella.
Es lo que hace que tu prompt sea auditable y se pueda podar en el futuro: tú (u otra persona) sabes por qué está ahí cada línea y cómo verificar si aún sirve.
Porqué por regla · prueba que fallaría · prompt auditable · se puede eliminar después.
Redactar tu guía de comportamiento — tu "Fable Mindset" — destilando el decision loop que quieres que siga el agente, con el espíritu de 3.5.
La guía es la disposición que orienta al agente en los casos que el prompt rígido no contempla. Escribirla es plasmar tu método en un texto reutilizable.
Guía de disposición · tu Fable Mindset · decision loop escrito · método reutilizable.
Aplicar el 3.6 a tu proyecto: combinar la guía flexible con barreras firmes — hooks para el hábito, effortLevel para el razonamiento y la elección de dónde vive cada regla.
Es lo que saca tu prompt del «espero que funcione» y lo lleva al «garantizo lo que hace falta». La combinación cierra la brecha entre intención y ejecución.
Hooks + effortLevel · dónde vive la regla · guía + barreras · la intención se convierte en ejecución.
La autoverificación final: una lista de verificación que confirma que el prompt, la guía, las pruebas y los bloqueos están completos y son coherentes antes de declarar "listo".
Cierra el curso con el mismo rigor que enseña: nada está "listo" por sensación; está listo después de verificar cada punto.
Checklist de entrega · listo mediante verificación · prompt + guía + pruebas + bloqueos · coherencia final.