🎯 Por qué decir "no hagas X" funciona
🧠 Imagínalo así: le das una misión a un pasante talentoso y solo le dices qué hacer, nunca qué no hacer. Sin límites explícitos, llena los vacíos a su manera, y «a su manera» puede incluir refactorizar, agregar pruebas y crear validaciones que nadie pidió. El prompting negativo es la lista de límites que estableces antes de empezar.
Un LLM funciona haciendo predicciones, un token a la vez, cuál es la continuación más probable del texto hasta ahora. Eso significa que no se detiene exactamente donde la tarea «termina»: continúa hasta que cree que la respuesta está completa según su propio criterio. En effort cuanto más alto, más generoso es este criterio de "completo": el modelo reúne más contexto y delibera más tiempo antes de responder.
Esto no es un fallo, sino un efecto secundario de ser capaz y cuidadoso. Fable 5, especialmente en tareas rutinarias con effort alto, puede decidir que la «respuesta completa» para corregir un bug incluye limpiar el código circundante, agregar un refactor o crear una capa de validación para un caso que nunca va a ocurrir. Nada de eso se pidió, pero tampoco se prohibió.
Las instrucciones negativas resuelven esto de raíz: en lugar de dejar que el modelo adivine dónde detenerse, le dices explícitamente «no hagas X». Esto elimina la ambigüedad que, de manera predeterminada, resolvería en la dirección de «más completo», y te devuelve el control del alcance.
📊 Dato técnico (documentación oficial sobre el esfuerzo)
"Effort is a behavioral signal, not a strict token budget. At lower effort levels, Claude will still think on sufficiently difficult problems, but it will think less than it would at higher effort levels for the same problem." — cuanto mayor sea el esfuerzo, más espacio tiene el modelo para "ir más allá"; y es precisamente ese espacio el que el negative prompting debe contener.
Lectura del diagrama: la misma solicitud, con un nivel de esfuerzo alto, puede generar tres extras no solicitados (izquierda) o mantenerse dentro del alcance pedido si se especifica explícitamente qué no debe incluir (derecha).
En una frase: el modelo predice el siguiente token hasta que cree que «terminó»; el prompting negativo define desde fuera dónde debe estar ese «terminó».
🚫 El prompt oficial anti-tidying
🧠 Imagínalo así: esto no es teoría de un video, es un párrafo extraído de la propia documentación oficial de Anthropic para Fable 5. Pégalo directamente en tu CLAUDE.md o system prompt.
La documentación oficial "Prompting Claude Fable 5" describe exactamente el mecanismo del tema anterior, con las palabras de la propia Anthropic:
"On routine work at higher effort, Claude Fable 5 can gather context and deliberate beyond what the task needs… To prevent unrequested tidying or refactoring at higher effort:"
Y a continuación, el bloque que la documentación recomienda pegar en el system prompt o en el CLAUDE.md. Y el negative prompting oficial contra el "orden" (tidying) y los refactors no solicitados:
Don't add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper. Don't design for hypothetical future requirements: do the simplest thing that works well. Avoid premature abstraction and half-finished implementations. Don't add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
No agregues funcionalidades, no refactorices ni introduzcas abstracciones más allá de lo que exige la tarea. Una corrección de errores no necesita una limpieza alrededor, y una operación puntual por lo general no necesita una función auxiliar. No diseñes para requisitos hipotéticos futuros: haz lo más sencillo que funcione bien. Evita la abstracción prematura y las implementaciones a medias. No agregues manejo de errores, fallbacks ni validaciones para situaciones que no pueden ocurrir. Confía en las garantías internas del código y del framework. Valida solo en los límites del sistema (entrada del usuario, APIs externas). No uses feature flags ni atajos de compatibilidad retroactiva cuando puedes simplemente cambiar el código.
✗ Sin el prompt
- ✗La corrección del bug viene acompañada de «limpieza» alrededor
- ✗Aparecen funciones auxiliares para un solo uso
- ✗Validación para casos que nunca ocurren
- ✗Feature flag para algo que podía cambiarse sin más
✓ Con el prompt
- ✓Diff mínimo, solo lo necesario para el bug
- ✓Sin abstracciones para «requisitos futuros»
- ✓Validación solo en los límites reales del sistema
- ✓Cambia el código directamente, sin shim de compatibilidad
En una frase: el prompt oficial de Anthropic contra el tidying evita directamente en la fuente los refactors, las abstracciones y las validaciones que no se pidieron.
🌀 Cuando Fable 5 "va más allá" por sí solo
🧠 Imagínalo así: no es solo una refactorización de código. El mismo instinto de «ser útil más allá de lo solicitado» aparece en acciones fuera del código, como redactar un correo que nadie pidió o crear una red de seguridad por cuenta propia.
Dos ejemplos concretos ilustran bien el patrón. Ninguno de los dos es malicioso — ambos parten de una buena intención (ser cuidadoso, ser útil) que simplemente excedió el alcance de lo que se pidió:
Redactar un correo que nadie pidió
Pediste investigar un problema con un proveedor
Al terminar la investigación, el modelo decide que el siguiente paso «lógico» es comunicarse con el proveedor y ya deja listo un borrador de correo, sin que nadie se lo haya pedido. ¿Es útil? Tal vez. ¿Se lo pidieron? No.
Crear un rama de respaldo defensivo
Pediste refactorizar un módulo directamente en la rama principal
Antes de empezar, el modelo crea una rama adicional «solo por seguridad», sin avisar y sin que se le haya indicado hacerlo. De nuevo: buena intención (no perder trabajo), pero una acción que cambia el estado del repositorio sin autorización explícita.
El patrón común: en ambos casos, el modelo decidió por su cuenta que una acción relacionada «formaba parte» de la tarea. Eso es precisamente lo que resuelven los dos prompts oficiales de esta clase: el anti-tidying (tema 2) recorta el exceso dentro del código, y el prompt de límites (tema 4) recorta el exceso fuera del alcance solicitado, incluidas las acciones que cambian el estado.
En una frase: buena intención + alcance indefinido = acción relacionada no solicitada; la solución es definir el alcance por escrito.
🧱 El prompt oficial de límites (boundaries)
🧠 Imagínalo así: hay una diferencia enorme entre "pensar en voz alta" con un colega y "pedirle que ejecute algo". El prompt de límites enseña al modelo a reconocer esa diferencia y a no confundir ambas cosas.
Esta es una técnica extra que no estaba en el video, pero aparece en la documentación oficial de Anthropic: límites explícitos (boundaries). Resuelve el mismo problema del tema 3, pero para el caso más serio: acciones que cambian el estado del sistema (eliminar, reiniciar, editar la configuración) sin confirmación.
When the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one. Before running a command that changes system state (restarts, deletes, config edits), check that the evidence actually supports it.
Quando o usuario esta descrevendo um problema, fazendo uma pergunta ou pensando em voz alta em vez de pedir uma mudanca, o entregavel e a sua avaliacao. Reporte os achados e pare. Nao aplique uma correcao ate que peçam uma. Antes de rodar um comando que muda o estado do sistema (reiniciar, deletar, editar configuracao), confira se a evidencia realmente sustenta essa acao.
⚠️ Sin este límite
Sin el prompt de límites, «creo que esta configuración está mal» puede interpretarse como «corrige esta configuración», y el modelo aplica el cambio antes de que confirmes que eso era lo que querías. En comandos que reinician servicios, eliminan datos o editan configuraciones, esa confusión cuesta caro.
En una frase: describir un problema no es pedir una corrección; el prompt de límites hace que el modelo respete esa diferencia.
⚖️ Cuándo SÍ debe actuar sin preguntar
🧠 Imagínalo así: los límites no son sinónimo de parálisis. Un buen colega sabe distinguir entre "esto lo resuelvo por mi cuenta" y "esto tengo que confirmarlo antes". Fable 5 necesita el mismo criterio, expresado explícitamente.
El prompt de límites del tema 4 resuelve el caso «describiendo x pidiendo». Pero falta el otro lado de la moneda: una vez que él ya tiene ¿información suficiente para actuar, cuándo debe detenerse de todos modos para preguntar y cuándo simplemente debe seguir adelante? La documentación oficial de Anthropic (en la técnica contra la planificación excesiva, profundizada en el módulo 1.4) establece el criterio:
"Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise."
Traducido a un criterio práctico: destructivo o irreversible (eliminar, sobrescribir, force push), cambio real de alcance (el pedido original era X, y el siguiente paso obvio sería Y — algo más grande o diferente) o información que solo tú tienes (una decisión de negocio, una preferencia personal) son los tres motivos legítimos para pausar. Fuera de eso, es trabajo rutinario, y el trabajo rutinario se hace, no se pregunta.
Lectura del diagrama: pausa solo cuando la acción sea destructiva, irreversible o cambie el alcance real; durante el resto del proceso, el modelo comprueba la evidencia y actúa.
✗ Pausa y pregunta
- ✗Eliminar una tabla, hacer un force push, sobrescribir un archivo
- ✗"Que «Corregir el error» se convierta en «reescribir el módulo»
- ✗Decisión que solo tú puedes tomar (precio, plazo)
✓ Actúa directamente
- ✓Ejecutar las pruebas, dar formato y corregir el bug reportado
- ✓Investigar e informar los hallazgos sin aplicar cambios
- ✓Seguir una convención ya establecida en el proyecto
En una frase: solo pausa por una acción destructiva, irreversible o un cambio real de alcance; lo demás es rutina y se hace directamente.
🎓 La analogía del video: trátalo como a un pasante
🧠 Imagínalo así: esta es la analogía que se usa en el video (no es una cita oficial de Anthropic, sino una forma de organizar el razonamiento): escribe el prompt como si se lo explicaras a un pasante en su primer día.
Un pasante en su primer día no tiene el criterio que un colega sénior ya construyó. No sabe por instinto que "corregir este bug" no significa "reescribir todo el módulo", ni que "investigar este problema" significa "enviar ya el correo al cliente". Por eso, con un nuevo pasante, dices explícitamente qué no hacer, no porque sea malo, sino porque todavía no tiene suficiente contexto para adivinar correctamente.
Y ese es exactamente el papel del prompting negativo y de los límites explícitos en esta lección: sustituyen el criterio que el modelo aún no ha demostrado tener en tu contexto específico. No se trata de que Fable 5 sea «tonta», sino de que no sabe, si no se lo dices, dónde están los límites de tu proyecto.
La parte interesante es cómo esto evoluciona. Con un pasante al que ya viste trabajar durante meses, relajas las instrucciones explícitas: ya interiorizó el estándar. Aquí pasa lo mismo: a medida que acumulas sesiones con Fable 5 en el mismo proyecto (y registras lo que funcionó, tema del módulo extra 1.7 sobre memoria), necesitas repetir menos instrucciones negativas explícitas cada vez. La confianza se construye con un historial, no se da por sentada desde el principio.
🆕 Pasante nuevo
- •Instrucciones negativas explícitas y detalladas
- •Límites escritos con todas las letras, sin dar nada por sentado
- •Revisión de cada diff antes de confiar
🤝 Colega de confianza
- •Instrucciones más cortas, solo lo que cambió
- •Límites ya registrados en CLAUDE.md/memoria
- •Más autonomía en el trabajo rutinario
En una frase: escríbele al modelo como al pasante de hoy, pero relaja las instrucciones a medida que crece el historial de confianza.
🧾 Resumen del Módulo
Próximo módulo:
1.4 — Déjalo actuar + demuestra que terminó: cómo evitar la planificación excesiva y verificar la evidencia antes de informar el progreso.