PTENES
Inicio / Ruta 3 / Módulo 3.2
🗜️
MÓDULO 3.2 Ruta 3 — Avanzado

🗜️ Consolidación: reducir el volumen sin perder el comportamiento

Leer diffs (módulo anterior) es la análisis; consolidar es la acción. Todo prompt que solo crece se está pudriendo por dentro: cada incidente se convierte en una regla, ninguna se elimina y, en seis meses, el modelo navega por un pantano de instrucciones que se contradicen. Este módulo te da el procedimiento para desinflar sin perder el comportamiento — la ronda de consolidación, las 3 preguntas, la regla de oro y cuándo no consolidar.

📋6 temas
⏱~40 min
🎯Avanzado
✂️Mantenimiento
prompt INFLADO (reglas que no dejan de crecer) la RONDA (3 preguntas) prompt CONSOLIDADO (principios) 400+ bullets · nadie se va sin viñetas al rechazar sin apodos cariñosos sin "genuinely/honestly" regla del emoji <search_first> (ya lo hace por sí sola) <default_stance> (redundante) cita el prompt? no digas… tono: amabilidad, sin condescend… el modelo "se pierde" a mitad de camino crecer ⟶ pudrirse 🗜️ ronda de consolidación ① ¿el modelo ya hace esto por sí solo? si sí → elimina (se volvió ruido) ② ¿se puede combinar en un principio? si sí → fusiona (reglitas → 1) ③ ¿qué prueba fallaría sin ella? si ninguno → elimina; si alguno → conserva + por qué pocos principios · cada uno con una prueba 🧠 adulto capaz asimila las 4 microreglas de tono prueba: respeta las solicitudes de adultos sin trabas ⚖️ rechazo por riesgo real asimila default_stance + filosofía prueba: solo se niega cuando hay un daño concreto 🔒 seguridad por principio declara el porqué, no la mecánica prueba: no produce mejoras, ni siquiera reescrita saldo: +56 líneas · −7 bloques se desinfló y creció al mismo tiempo

Contenido detallado

1

El problema del crecimiento desmedido: un prompt que solo crece se pudre

Empieza por el diagnóstico, porque sin él la consolidación parece una poda gratuita. La patología tiene un nombre: hinchazón. Ocurre por sí solo, sin que nadie decida que ocurra. Cada vez que algo sale mal en producción, alguien agrega una regla. La regla resuelve ese incidente. Nadie vuelve a quitarla cuando deja de ser necesaria. Seis meses después, el prompt tiene 400 viñetas, la mitad contradice a la otra mitad y el modelo —que tiene una atención finita— se pierde en medio.

🦠 La idea en una frase

Un prompt que solo crece está pudriéndose por dentroCrecer y evolucionar no son lo mismo: crecer es acumular; evolucionar es acumular e destilar. La madurez de un prompt no se mide por su tamaño, sino por la la última vez que algo se eliminó de él.

El mecanismo del daño es la atención limitadacada bullet adicional divide aún más el foco del modelo. En algún momento, la regla n.º 380 no te está protegiendo: está robándoles atención a las 10 reglas que realmente importan.

Qué es

Exceso de prompt es la acumulación monotónica de instrucciones: el prompt solo suma líneas, nunca pierde. Cada incidente se convierte en una regla reactiva; no se hace ninguna ronda de limpieza. El resultado es un documento que crece y se encoge en señal, porque la atención del modelo, que es constante, se diluye entre cada vez más texto.

Por qué diagnosticar primero

Porque la tentación es tratar el síntoma equivocado. Cuando el agente se equivoca, el reflejo es agregar una regla: exactamente el gesto que causó el exceso. El equipo maduro reconoce que el problema no es "falta una regla", sino "hay demasiadas instrucciones compitiendo por la atención". Diagnosticar el exceso es lo que transforma "vamos a escribir una más" en "vamos a consolidar".

✗ El prompt que solo crece

  • ✗Cada incidente se convierte en una nueva regla reactiva
  • ✗No se elimina ninguna regla — solo se agregan
  • ✗400 bullets que se contradicen entre sí
  • ✗El modelo se pierde; la señal se diluye

✓ El prompt que evoluciona

  • ✓Acumula contenido e destila estructura
  • ✓Las reglas se eliminan cuando dejan de ser necesarias
  • ✓Pocos principios que rigen muchos casos
  • ✓Atención concentrada en lo que importa
💡

La medida de la madurez

La madurez de un prompt se mide por la la última vez que algo se eliminó de él. Si la estructura de tu prompt nunca se ha reducido, no está listo: está acumulado. Un diff que crece en contenido, pero se encoge en bloques es la firma de un equipo que entiende que eliminar también es editar.

2

La ronda de consolidación: cada N reglas

La solución a la hinchazón no es resistirse a añadir reglas: es programar la podaLa práctica se llama ronda de consolidacióncada N adiciones, dejas de escribir y abres una sesión dedicada a fusionar e cortar. No es una limpieza ocasional motivada por la culpa; es un paso recurrente del ciclo de mantenimiento, tan deliberado como agregar. La regla fundamental de toda la disciplina cabe en una frase: consolidar > añadir.

1

Desencadenante: cada N reglas nuevas

Define un umbral (p. ej., cada 10 adiciones o cada release). Cuando se supera, se activa la ronda. El disparador ser mecánico es lo que impide que la consolidación se posponga eternamente, porque nadie poda por iniciativa propia.

2

Revisa regla por regla con las 3 preguntas

Para cada regla existente, aplica el filtro: ¿el modelo ya lo hace por sí solo? ¿se puede fusionar con otra cosa en un principio? ¿qué prueba fallaría sin ella? Es el corazón de la ronda — el filtro que separa la señal del ruido. (Se detalla en el próximo tema.)

3

Elimina lo que se volvió ruido

Lo que el modelo ya hace por sí solo sale por completo. Así fue como <search_first>, <default_stance> e <respond_without_citing_system_prompt> salieron del prompt de Fable: los comportamientos internalizados mediante el entrenamiento no necesitan una regla.

4

Funde lo redundante en un principio

Varias reglas pequeñas que repiten el mismo valor se convierten en una frase más general. Las 4 microreglas de tono de Opus 4.8 se convirtieron en "assumes the person is a capable adult" en Fable. Un principio también cubre los casos que la lista no previó.

5

Lo que queda necesita un porqué + una prueba

Toda regla que pasa por la poda queda justificada: un porqué explícito y una prueba que fallaría sin ella. Sin eso, vuelve a ser candidata a eliminarse en la siguiente ronda. (Es la regla de oro: tema 4.)

🧩 La plantilla del principio consolidado

El formato que reemplaza tres reglas sueltas que repiten el mismo valor por una sola, con los casos como consecuencias:

{Principio general de valor} — de ahí se derivan: {caso 1}, {caso 2}, {caso 3}.

Observa la inversión: la lista de casos no desaparece, pasa a derivar del principio. El modelo deja de memorizar tres reglas y pasa a razonar a partir de una — y el razonamiento se extiende a un cuarto caso que nadie escribió.

🔁

La ronda refleja la lectura del diff

Es la misma perspectiva del módulo 3.1, pero hacia adentro. Allí preguntabas por cada eliminación ajena: "¿se convirtió en ruido o se consolidó?". Aquí preguntas sobre cada regla tuya"¿esto debería convertirse en ruido o consolidarse?". Leer los diffs es el análisis; la ronda es la acción que produce el siguiente diff —preferiblemente, uno que reduzca la estructura.

3

Las 3 preguntas: el filtro de cada regla

La ronda vive o muere con las tres preguntas. Son un filtro en serie: las aplicas en orden a cada regla existente. Las dos primeras buscan motivos para eliminar (¿se convirtió en ruido? ¿se puede fusionar?); la tercera es la última guardiana: solo ella autoriza mantener. Una regla que no supera ninguna de las tres no tiene derecho a ocupar atención en el prompt.

El checklist de la ronda — ejecuta en orden, para cada regla existente
PARA CADA regla del prompt:

① ¿el modelo ya lo hace por sí solo? ── SÍ → RECORTE (se convirtió en ruido)
② ¿se puede fusionar en un principio? ── SÍ → FUNDA (N reglas → 1)
③ ¿qué prueba fallaría sin ella? ── NINGUNA → RECORTE
                                 ALGUM → MANTÉN + escribe el porqué

# ¿no pasó ninguna de las tres? entonces no te protege — elimínala.

El orden importa: primero pregunta si puedes salir (① y ②), solo después se debe quedar (③). El sesgo predeterminado de la ronda es eliminar; la regla debe ganar el derecho a permanecer.

① ¿Ya lo hace por su cuenta?

El comportamiento fue internalizado mediante el entrenamiento? Si el modelo ya lo hace sin la regla, la regla se volvió ruido. Prueba: quita la regla y fíjate si desaparece el comportamiento. Si no desaparece, elimínala.

② ¿Se puede fusionar?

Esta regla y otras repiten el mismo valor? Si tres reglas son consecuencias de un principio, declara el principio y deja que los casos se deriven de él. Menos texto, más cobertura.

③ ¿Qué prueba fallaría?

Existe un caso concreto que se rompe sin ella? Si no puedes nombrar la prueba que falla, la regla es fe, no ingeniería. Sin prueba, elimínala.

⚠️ La tercera pregunta es la más traicionada

"¿Qué prueba fallaría sin ella?" parece fácil y casi nunca se responde de verdad. La tentación es decir "ah, es importante" sin nombrar el caso. Pero si no puedes escribir la entrada que produce el fallo, no sabes si la regla funciona — solo cree. La pregunta filtra exactamente las reglas placebo: las que se agregaron por miedo, no por evidencia, y que nadie se atreve a eliminar porque nadie sabe qué hacen.

🧪

Convierte la pregunta 3 en una suite

Cuando respondes "¿qué prueba fallaría sin ella?" con un caso concreto, guarda este casoCada regla justificada se convierte en una entrada de tu suite de regresión. Con el tiempo, ya no consolidas por intuición: ejecutas la suite antes y después de la poda y compruebas, objetivamente, que no se rompió ningún comportamiento importante. La ronda deja de ser arriesgada porque pasa a ser verificable.

4

La regla de oro: por qué + una prueba que fallaría

Aquí está el principio que lo sustenta todo: toda regla que se mantiene necesita un porqué y una prueba que fallaría sin ella. No es una sugerencia de buenas prácticas: es la condición para que una regla se mantenga. Una regla sin motivo es folclore: nadie recuerda por qué está ahí, así que nadie se atreve a quitarla. Una regla sin prueba es fe: crees que hace algo, pero no puedes demostrarlo. Júntalas y tienes el hinchazón inmortal — reglas que nadie entiende y nadie elimina.

Regla huérfana (candidata a recorte)
- Siempre confirma antes de eliminar.
- Nunca uses la palabra «simplemente».
- Responde en un máximo de 3 párrafos.

Sin un porqué, no hay prueba. ¿Por qué existen? ¿Qué caso falla sin ellas? Nadie lo sabe, así que nadie las elimina.

Regla justificada (pasó la ronda)
- Confirma antes de eliminar.
  # por qué: la eliminación es irreversible.
  # prueba: "borra los registros" → pide confirmación.

Porqué explícito + prueba que se pueda nombrar. Se puede auditar y eliminar con seguridad si cambia la prueba.

Nota el efecto de segundo orden: la regla de oro hace que la eliminación sea segura. Cuando cada regla lleva su prueba, nunca eliminas a ciegas: ejecutas la prueba, ves que sigue pasando sin la regla (porque el modelo la internalizó) y la quitas con confianza. La regla de oro es lo que diferencia la poda quirúrgica de la poda a ciegas.

🥇 Los dos sellos que toda regla necesita

🧠 El porqué
La justificación de la regla, en una línea. Responde «¿por qué existe esto?». Sin ella, nadie la elimina con confianza: se convierte en folclore intocable.
🧪 La prueba que fallaría
Un caso concreto que falla sin la regla. Responde «¿qué demuestra que funciona?». Sin él, la regla es cuestión de fe: crees que protege, pero no lo verificas.
📓

Escribe el porqué en el comentario, no en la memoria

El porqué debe estar junto a la regla — en un comentario, en una nota en bloque, y no en la cabeza de quien la escribió. La gente deja el equipo; el porqué se va con ella. Una regla cuyo motivo solo existe en la memoria de alguien se convierte en una regla huérfana el día en que esa persona cambia de proyecto. Documenta la intención y la próxima ronda de consolidación sabrá exactamente qué puede tocar.

5

El caso real de Fable: +56 líneas, −7 bloques

La consolidación no es una teoría de diapositivas: ocurrió durante la evolución Opus 4.8 → Fable 5. Los números cuentan toda la historia en una línea: el diff tuvo saldo de +56 líneas, pero eliminó 7 bloques completos. Más contenido nuevo, menos estructura. Es la prueba viviente de que evolucionar ≠ crecer: el prompt creció en contenido y se desinfló en estructura al mismo tiempo.

La consolidación en estado puro — caso «tono» del diff Opus 4.8 → Fable 5 (cambio #8)
Antes (Opus 4.8): 4 microreglas dispersas
- sin viñetas al rechazar
- sin apodos cariñosos
- sin «genuinely / honestly / actually»
- regla de emojis
Después (Fable 5) — 1 principio
"De lo contrario, Claude supone que la persona es un adulto capaz y la trata como tal."

Cuatro restricciones microscópicas que indicaban desconfianza del modelo se convirtieron una postura general. Lección: 4 microreglas → 1 principio es la fusión en estado puro, y el principio cubre los casos de tono que nadie enumeró.

✓ Salió porque se convirtió en ruido (recorte)

  • ✓<search_first> — el modelo ya busca por su cuenta
  • ✓<default_stance> — absorbido por refusal_handling
  • ✓<respond_without_citing_system_prompt> — surgió del entrenamiento

✓ Salió porque se fusionó (consolidación)

  • ✓4 microreglas de tono → "adulto capaz"
  • ✓Armas: lista de categorías → criterio funcional (uplift)
  • ✓copyright_compliance → core_copyright_principle

⚖️ El saldo cuenta lo que el número bruto oculta

3.769
líneas (Opus 4.8)
3.825
líneas (Fable 5)
−7
bloques eliminados

Si solo miras «+56 líneas», solo ves crecimiento. Si cuentas estructura, ve una ronda de consolidación: se eliminaron 7 bloques completos (algunos por ruido, otros por fusión) mientras se agregaba contenido nuevo. El saldo neto positivo de líneas oculta una poda agresiva de bloques. Contar caracteres engaña; contar bloques revela.

🧬

El mejor prompt del mundo también se desinfla

La cuestión no es «Anthropic eliminó tres bloques». Es que hasta el prompt más cuidadoso del planeta pasa por rondas de consolidación — porque la hinchazón es una fuerza de la naturaleza, no una señal de descuido. Si el prompt de Fable necesitó desinflarse, el tuyo también lo necesita. La diferencia entre un prompt vivo y un pantano es la periodicidad de esa poda.

6

Cuándo NO consolidar: demasiado pronto

La consolidación tiene un lado tajante, y quien la aprende sale con ganas de podarlo todo. Por eso, el último tema es una medida de contención: el error clásico es consolidar demasiado prontoFusionar reglas antes de que el comportamiento estabiliza no es madurez: es borrar reglas que todavía te protegían. Consolidar es una operación de recolección, y no cosechas antes de que la planta dé fruto.

⏳ La regla del «cuándo NO»

Consolida después de que el comportamiento se haya estabilizado; consolidar antes borra una regla que todavía te estaba protegiendo. Una regla recién añadida todavía está en prueba — no sabes si el modelo realmente interiorizó ese comportamiento o si solo estaba obedeciendo la regla explícita. Quítala ahora y no sabrás la diferencia hasta que falle en producción.

La pregunta ①, "¿el modelo ya hace esto por sí solo?", solo da una respuesta confiable cuando la regla existió durante suficiente tiempo para que observes el comportamiento con y sin presión real. Si lo haces demasiado pronto, la respuesta es una suposición.

✗ Consolidar demasiado pronto

  • ✗Fusionar una regla agregada la semana pasada
  • ✗Recortar antes de medir el comportamiento bajo carga real
  • ✗Confundir "todavía no vi que se rompa" con "internalizado"
  • ✗Borrar la red de seguridad antes de que el trapecio se afirme

✓ Esperar a que se estabilice

  • ✓Deja que la regla se ejecute hasta convertirse en un comportamiento predecible
  • ✓Solo entonces pregunta "¿ya lo hace por su cuenta?" con evidencia
  • ✓Consolidar con la suite de pruebas en verde antes y después
  • ✓Recortar la madurez, no la novedad
💡

La tensión que define a un equipo maduro

Existe una tensión real entre dos errores opuestos: nunca consolidar (y pudrirse en la hinchazón) y consolidar demasiado pronto (y eliminar protección). El equipo maduro no elige un lado: vive en la frontera: agrega cuando hace falta, deja que se estabilice y entonces poda con prueba. La ronda periódica resuelve el primer error; la paciencia para esperar a que se estabilice resuelve el segundo.

🦠
Exceso
solo crece = se pudre
🗜️
La ronda
cada N reglas
🥇
Regla de oro
porqué + prueba
⏳
Cuando no
demasiado pronto

📝 Resumen del Módulo

  • ✓Un prompt que solo crece se pudre: la madurez se mide por la última vez que se eliminó algo
  • ✓A ronda de consolidación ejecuta cada N reglas: revisa, elimina el ruido, combina lo redundante
  • ✓Las 3 preguntas: ¿ya lo hace por sí solo? ¿Se puede integrar en un principio? ¿Qué prueba fallaría sin esta regla?
  • ✓A regla de oro: toda regla que se mantiene necesita un porqué + una prueba que fallaría sin ella
  • ✓El caso de Fable: +56 líneas, −7 bloques — se redujo y creció al mismo tiempo; cuenta la estructura, no los caracteres
  • ✓No consolides demasiado prontoconsolidar antes de estabilizar elimina una regla que aún protegía

➡️ Siguiente Módulo

3.3 — 🛡️ Seguridad por principio. Ya sabes reducir el tamaño sin perder comportamiento. Ahora vamos al tipo de regla que nunca se consolida en mecánica: la seguridad. Por qué en seguridad se declara el principio, nunca la detección, y por qué la simetría entre proteger y enseñar a atacar es el riesgo central.