Módulo 4.2 — El ciclo continuo | Auditoría de Ablación

🔄 Ejecuta el ciclo de 5 pasos

Todo lo que aprendiste en las tres primeras rutas cabe en un ciclo de cinco pasos que se repite. No termina: cada vuelta devuelve una configuración más pequeña que la anterior, y cada modelo nuevo reinicia el ciclo. El objetivo del módulo no es hacer la auditoría una vez — es armar el mecanismo que hace que vuelvas a hacerlo dentro de seis meses, sin depender de las ganas ni de una crisis.

Qué observar: la línea punteada cian es la única arista que cierra el anillo: sin ella, hiciste una limpieza, no instalaste un ciclo. Y fíjate en el resaltado del nodo 4: es ahí donde la mayoría falla, porque devolver una instrucción tras el primer fallo parece cuidado, pero en la práctica es como la configuración vuelve a crecer. Toda la disciplina del curso está en ese cuadro.

Ejecutar `/audit-ablacao` en el alcance elegido

Global, un proyecto o un conjunto de skills. La skill solo diagnostica: lee, clasifica y propone; no edita, no mueve ni elimina. El producto es el informe de 10 secciones.

Reducir el Top 10 según impacto ÷ riesgo — en una sesión aparte

La skill no aplica nada. Aplicar es decisión tuya, en una nueva solicitud, con la config bajo git para poder volver atrás. Primero redundancias y conflictos (riesgo casi cero), después legado y luego microgestión.

Usar en trabajo real durante algunos días

No en una prueba hipotética. Una prueba inventada ejercita lo que imaginas que importa; el trabajo real ejercita lo que de verdad importa, y ahí es donde aparece la falla.

Anota las fallas y devuelve la instrucción solo cuando se repitan

Este es el paso que casi todos se saltan. Anota la falla; solo devuelve una instrucción cuando la misma clase de falla si se repite — y de la forma más breve posible. Un fallo aislado es ruido; un fallo repetido es una señal.

Repetir cada ~6 meses o con cada lanzamiento importante de un modelo

Lo que sobrevivió a la última vuelta puede no sobrevivir a la siguiente: la instrucción que corregía una debilidad real se convierte en peso muerto cuando esa debilidad deja de existir.

💡 Por qué se omite más el paso 4

Porque equivocarse una vez ya parece justificación suficiente. El modelo falla en una tarea, escribes la regla en el momento y acabas de cambiar un error puntual por un costo permanente: esa línea se leerá en el 100% de las ejecuciones futuras, incluso en las que no tienen nada que ver. Anotarlo y esperar a que se repita requiere tres días de paciencia y ahorra años de contexto desperdiciado.

Conceptos clave

Un ciclo, no una limpieza

Volver, no un evento único

Sesión separada

Auditar ≠ aplicar

Trabajo real

Una prueba hipotética no cuenta

Falla repetida

Único detonante para reintroducirlo

🚨 Reconoce los desencadenantes de una nueva auditoría

El calendario de seis meses es el mínimo, no el máximo. Hay señales que indican "audita ahora, no esperes a la fecha" — y casi todas se pueden observar sin esfuerzo: un número que superó un límite, un comportamiento que se volvió impredecible, o una frase que alguien dijo frente a ti. La tabla de abajo vincula cada desencadenante con el alcance que pide: no toda señal exige auditarlo todo.

Activador observado	Alcance que auditar	Por qué
Modelo nuevo lanzado	Todo: global + proyectos + skills	Cada instrucción escrita para corregir la debilidad del modelo anterior se convirtió en candidata a peso muerto.
`CLAUDE.md` superó ~150 líneas	Solo ese archivo	Por encima de eso, casi siempre hay procedimientos disfrazados de reglas globales —material de `MOVE` para skill.
3+ skills compitiendo por el mismo disparador	El conjunto de skills, no el CLAUDE.md	El disparo se volvió una lotería. La solución suele ser `MERGE`, un alcance más acotado o una invocación directa.
"Nadie sabe ya qué protege esta regla"	El bloque que contiene la regla	Una regla que nadie se atreve a borrar es una regla sin dueño. Va a `TEST`, nunca para `KEEP` por miedo.
Le explicaste la misma regla dos veces a otra persona	La regla y sus vecinas	Si necesita una explicación humana para entenderse, está mal escrita o no debería existir.

📌 El desencadenante más subestimado

El último de la tabla. Cuando explicas la misma regla por segunda vez a un colega, falló como texto; y si falla con una persona que puede preguntar de vuelta, falla aún más con el modelo, que no pregunta. Ese detonante no aparece en ninguna métrica; aparece en tu boca. Presta atención.

✓ Volver a auditar ahora

✓Salió un modelo nuevo y tu config sigue siendo la misma que la de dos modelos atrás
✓Has agregado reglas en los últimos meses y nunca has eliminado ninguna
✓Dos reglas de tu config se contradicen y no sabes cuál prevalece

✗ No es un desencadenante de reauditoría

✗Una tarea salió mal hoy: eso requiere un diagnóstico, no una limpieza general
✗Leíste una publicación que decía que "CLAUDE.md grande es malo" — mide el tuyo, no el promedio
✗Ganas de cambiar algo un viernes sin trabajo real para probarlo después

🧪 Desaprende el overengineering

Boris vuelve una y otra vez al mismo tema: trabajar con un modelo se convirtió en ciencia empírica, no teórica. No deduces lo que necesita el modelo a partir de principios: lo pruebas, observas dónde tiene dificultades y ajustas según lo que viste. Esto exige dejar dos cargas atrás: lo que aprendiste sobre el comportamiento de modelos anteriores y las suposiciones de la teoría de la computación sobre lo que «debería» ser difícil.

La tercera exigencia es la más incómoda: seguir dispuesto a volver a probar ideas que fallaron en el pasado, porque el motivo del fallo puede haber desaparecido. Boris describe overengineering como un modo de falla recurrente — y desaprender ese hábito como un recorrido real para builders con experiencia. Cuantos más años de ingeniería tienes, más fuerte es el reflejo de especificarlo todo y más cuesta desmontarlo.

🆕 Dos palabras antes de continuar

Overengineering: ingeniería excesiva —resolver con demasiada estructura, demasiadas reglas y demasiados pasos un problema que requería menos. En la configuración del agente, aparece como una instrucción que guioniza cada etapa en vez de dar un objetivo y un criterio.
Eval: abreviatura de evaluation — un caso de prueba de tu agente: una tarea con un resultado esperado que vuelves a ejecutar con cada versión del modelo para ver si mejoró o empeoró. Los evals también envejecen: retira los que el modelo ya supera siempre.

✗ Mentalidad antigua (teórica)

✗"Esto es difícil para los modelos" — deducción a partir de lo que viste hace dos modelos
✗"Según la teoría, este problema es intratable, así que tengo que descomponerlo a mano"
✗"Ya intenté esto una vez y no funcionó" — archivado para siempre
✗Escribir la regla antes de ver la falla, por precaución
✗Medir la calidad del prompt por su extensión y nivel de detalle

✓ Mentalidad empírica

✓"Veamos" — ejecuta la tarea y observa dónde tropieza realmente el modelo
✓Primero da la tarea completa; divídela solo si la observación lo exige
✓Nueva prueba programada de los fracasos anteriores con cada nueva versión
✓Escribe la regla después desde la segunda aparición de la misma falla
✓Mide la calidad del prompt por el resultado verificado

🎯 El detalle que marca la diferencia: vuelve a probar lo que falló

La lista de "cosas que no funcionan con IA" que llevas en la cabeza se armó con modelos que ya no existen. Cada elemento de esa lista es una hipótesis vencida, no un hecho. Elige un elemento de esa lista con cada modelo nuevo y vuelve a probarlo: es la forma más barata de descubrir nuevas capacidades y la única que no depende de que alguien te avise.

🧭 Calibra lo que aún no está resuelto

Boris ya dijo públicamente que la programación está resuelta —y aclaró algo que suele desaparecer en la cita: resuelta para el tipo de programación que hace, no para todo el mundo. La salvedad te importa por un motivo práctico: en las áreas donde el modelo todavía tiene dificultades, la solución no es escribir una instrucción más larga. Es reforzar la verificación.

Área que todavía es difícil	Cómo se ve esto en la práctica	Verificación que vale la pena
Bases de código de sistemas muy profundas	Un cambio plausible que viola una invariante enterrada en otra capa.	Prueba de integración que ejercita la capa de abajo, no solo la modificada.
Sistemas distribuidos	Funciona en la máquina, falla con concurrencia, orden de mensajes o partición de red.	Ejecutar con carga y fallas inyectadas; comprobar el estado final, no solo el retorno.
Verificación visual detallada	Algo desplazado un píxel pasa por "igual". Opus 5 fue un gran avance en visión y uso de la computadora, pero aún no es perfecto.	Comparación automatizada de imágenes con umbral, captura de referencia y revisión humana al final.

⚠️ Atención: la trampa de esta sección

Leer «aquí todavía es difícil» y responder con tres párrafos más de instrucciones en el CLAUDE.md es exactamente el reflejo que todo el curso intentó desmontar. Una instrucción larga no corrige un límite de capacidad; solo consume contexto mientras el límite sigue ahí. En estas áreas: verificación más sólida, alcance menor y revisión humana en el punto adecuado. Nunca más prosa.

🔭 Calibrar no es rendirse

Esta lista es una instantánea de hoy, y la regla del tema 3 también se aplica aquí: vuelve a probar. La verificación visual, que era un callejón sin salida, se convirtió en un área que avanzó mucho de un modelo a otro. Trata cada elemento como «todavía no», con una fecha de revisión marcada, no como «nunca».

⚙️ Automatiza con routines de una frase (bonus)

Este tema es un bonus: resuelve un problema distinto del resto del curso. Los loops y las routines no tratan de una tarea grande dividida en partes, sino de una tarea repetitiva ejecutada según un cronograma. Un loop es esencialmente un cron job que ejecuta Claude localmente. Una routine es lo mismo en la nube, para que puedas cerrar la laptop.

🆕 Cuatro palabras antes de continuar

Cron job: tarea programada que el sistema ejecuta por sí solo en un horario fijo: «todos los días a las 3 h», «cada hora». Proviene de cron, el planificador clásico de Unix.
Routine: la misma programación, pero ejecutándose en la nube: no depende de que tu computadora esté encendida.
PR (pull request): propuesta de cambio de código abierta en un repositorio, con el diff visible, para que alguien la revise y la apruebe antes de incorporarla. Es como la rutina entrega el trabajo sin aplicar nada por sí sola.
Scaffolding: andamiaje — código temporal que solo existe para sostener algo durante una fase (por ejemplo, el interruptor de un experimento) y se vuelve basura cuando termina esa fase.

Importan dos propiedades: cada ejecución no comparte contexto con la anterior, aunque puede compartir memoria; y la programación puede ser cada cinco minutos, cada hora o diariamente. Anthropic ejecuta hoy entre 20 y 30 routines diarias sobre sus propios productos — y el detalle que lo cambia todo: cada una es un único prompt, a menudo de una frase. El modelo descubre por sí solo los detalles de la implementación.

Qué observar: fíjate en el tamaño de las cajas del medio: es el prompt completo de cada rutina, una frase. Nadie escribió «usa análisis estático y dinámico» en la rutina de código muerto; el modelo eligió esos métodos por sí solo. Y mira la etiqueta de la derecha: la entrega es un PR, no un cambio aplicado. Es la misma disciplina de la skill de auditoría: proponer y dejar la decisión en manos de una persona.

Las cinco routines que ejecuta Anthropic

Limpiar código muerto. Se ejecuta a diario, usa análisis estático y dinámico y abre un PR para eliminar lo que encuentra. Nadie pidió explícitamente estos métodos; el modelo los descubrió por su cuenta.
Publicar los experimentos terminados. Busca experimentos que ya se hayan habilitado para el 100% de los usuarios, elimina el scaffolding del experimento y publica el resultado.
Escribir las pruebas que faltan en áreas del código con poca cobertura.
Borrar pruebas inútiles — incluidos los tests de bajo valor que agregaron modelos antiguos o personas con el tiempo.
Policía de abstracciones. Encuentra abstracciones casi duplicadas que divergieron con el tiempo y las vuelve a unificar en una sola.

El patrón que vale la pena copiar: las routines de mayor impacto son tareas de mantenimiento obvias, repetitivas y fáciles de dejar para después. Auditar tu propia configuración es exactamente ese tipo de tarea.

🧪 Copia y ejecuta: tu reauditación como recordatorio periódico

Objetivo: convertir el paso 5 del ciclo en algo que ocurra sin depender de tu memoria. Hay dos formas: la de una línea, que funciona en cualquier máquina, y la versión routine, para quienes ya usan la programación en la nube.

# --- Opção A: cron job local (roda no seu computador) ---
# abre o editor de agendamentos:
crontab -e

# cola esta linha: dia 1, a cada 6 meses (janeiro e julho), 9h
0 9 1 1,7 * echo "ABLACAO: rodar /audit-ablacao na config global" >> ~/ablacao-lembretes.txt

# --- Opção B: routine (roda na nuvem, notebook fechado) ---
# o prompt inteiro da routine é UMA frase:
"Rode uma auditoria de ablação em ~/.claude/CLAUDE.md e ~/.claude/skills/,
 e me entregue o Top 10 por impacto ÷ risco. Não altere nenhum arquivo."

# --- Opção C: sem nada instalado ---
# evento recorrente semestral no calendário, com este título:
"Ablação: rodar /audit-ablacao + abrir ablacao-diario.md"

Cómo verificar:

1. Ejecuta crontab -l y confirma que la línea aparece en el listado.
2. Cambia temporalmente la programación para dentro de 2 minutos y comprueba que ~/ablacao-lembretes.txt ganó una línea. Después vuelve al semestral.
3. Si usaste la opción B, confirma que la frase de la routine contenga la prohibición explícita de modificar archivos: una auditoría que ya empieza a hacer cambios es una auditoría en la que no confías.

Ahora cámbialo por el tuyo: reemplaza las rutas por <a config que você realmente audita> y el mes por <seus dois meses do ano>. Si tienes más de un proyecto activo, haz una línea por alcance: auditar todo junto se convierte en un informe que nadie lee.

📎 Por qué «una frase» y no un manual

La rutina es la prueba final de la tesis del curso: si un prompt de una frase, sin instrucciones paso a paso, produce PR útiles a diario en una base de código del tamaño de la de Claude Code, tu procedimiento de 12 etapas no estaba garantizando calidad: solo te hacía sentir en control.

📝 Escribe tu política de ablación

Ejercicio final del módulo y del curso: escribir tu política de ablación personal en ≤10 líneas. Debe incluir cuatro cosas: cuándo volver a auditar, qué nunca debes recortar, la regla para reintroducir elementos y dónde se guardan los diarios y las evaluaciones. Menos que eso no es una política; más que eso no se lee.

Y lo hará donde se volverá a leer — como skill o nota separada, con una fecha marcada, no como otro párrafo en el CLAUDE.md. Si pegas la política ahí, acabas de crear la línea zombi número 1 de la próxima auditoría: un texto sobre ablación que se carga en el 100% de las ejecuciones, incluso en las que no tienen nada que ver con auditar la configuración.

⚠️ La ironía que cierra el curso

Terminar ocho módulos sobre no inflar el CLAUDE.md y celebrar añadiéndole diez líneas sería un final perfecto, de comedia. Una política es un procedimiento con un desencadenante conocido, así que es una skill (o una nota con un recordatorio). Ya conoces la regla: lo que siempre es verdad queda en el CLAUDE.md; lo que solo es cierto cuando la tarea es esa se convierte en una skill.

📋 Copia y completa: plantilla de la política (≤10 líneas)

Objetivo: guardar como ~/.claude/skills/politica-ablacao/SKILL.md (o como nota fijada, si prefieres). Completa todo entre < > con tu caso real.

## Política de ablação — <seu nome>

1. Re-auditar: a cada 6 meses (próxima: <DD/MM/AAAA>) e a cada modelo novo.
2. Gatilho extra: CLAUDE.md > 150 linhas, 3+ skills no mesmo gatilho, regra sem dono.
3. Escopo padrão: <global | projeto X | conjunto de skills Y>.
4. Nunca cortar sem teste: identidade, caminhos/fontes de verdade, segurança,
   compliance, contratos de interface, integrações, convenções internas.
5. Reintrodução: só após a MESMA falha repetir 2x em trabalho real,
   e na forma mais curta possível.
6. Aplicar cortes sempre em sessão separada da auditoria, com a config sob git.
7. Diário de falhas: <caminho/ablacao-diario.md>.
8. Evals pessoais: <caminho/evals/> — aposentar as saturadas a cada re-auditoria.
9. Toda remoção aplicada registra: trecho citado + risco + como testar.
10. Toda versão nova precisa ter pelo menos uma verificação objetiva.

Cómo verificar:

1. No queda ninguno < > en el archivo: si quedó algo, la política sigue siendo una plantilla, todavía no es tuya.
2. La línea 1 tiene una fecha concreta, no "dentro de unos meses".
3. El archivo NO está dentro del CLAUDE.md. Ejecuta grep -c "Política de ablação" ~/.claude/CLAUDE.md — debe regresar 0.
4. Los caminos de las líneas 7 y 8 existen de verdad: ls <caminho> responde sin errores.

🎓 Proyecto final del curso

Entregas cuatro elementos, todos sobre tu propia configuración — nada hipotético:

1 · Informe de la skill

Las 10 secciones, guardadas en .md (módulo 3.1)

2 · CLAUDE.md antes/después

Con el diff visible (módulo 3.2)

3 · Tabla A/B/C

≥2 tareas reales × 3 versiones (módulo 4.1)

4 · Política de ablación

≤10 líneas, fuera del CLAUDE.md (este módulo)

Criterios de aprobación

•Los cuatro elementos existen.
•Cada eliminación aplicada tiene fragmento citado + riesgo + cómo probarlo.
•Cada instrucción devuelta tiene fallo repetido registrado — nada de reintroducir por precaución.
•La versión final tiene al menos una verificación objetiva donde antes no había ninguna.

✓ Criterio de salida de este módulo

Política escrita, con la fecha de la próxima reauditoría programada — y puedes decir, al mirar el CLAUDE.md final, por qué sobrevivió cada línea restante. Si hay una línea cuya respuesta es «no sé, siempre estuvo ahí», será la primera de tu próxima auditoría.

Revisión rápida (no bloquea nada): terminaste la auditoría, recortaste el Top 10 y escribiste tu política en 8 líneas. ¿Dónde debería estar?

🏁 Resumen del Módulo y fin del curso

✓

Ciclo de 5 pasos — ejecútalo, elimínalo en una sesión aparte, úsalo en trabajo real, toma nota y restáuralo solo si se repite; repite cada ~6 meses o cuando haya un modelo nuevo.

✓

Activadores de nueva auditoría — modelo nuevo, 150 líneas, 3+ skills con el mismo activador, regla sin responsable, regla que ya explicaste dos veces.

✓

Mentalidad empírica — prueba y observa en vez de deducir; vuelve a probar lo que falló antes; el overengineering es el modo de fallo recurrente del builder experimentado.

✓

Dónde aún no está resuelto — sistemas profundos, distribuidos, verificación visual minuciosa. Respuesta: una verificación más sólida, no una instrucción más larga.

✓

Routines de una frase — 20 a 30 diarias en Anthropic, cada una con un único prompt; tu nueva auditoría podría convertirse en una.

✓

Política de ablación — ≤10 líneas, con una fecha marcada para volver a leerlo: skill o nota, nunca más un párrafo en CLAUDE.md.

Todo el curso, en cuatro líneas

T1Por qué borrar — la configuración envejece: cada instrucción corrige la debilidad de un modelo específico y se convierte en peso muerto cuando esa debilidad desaparece.
T2Cómo diagnosticar — 10 categorías, 6 decisiones, 7 preguntas; y la conversión del micromanagement en objetivo + guardrails + criterio + verificación.
T3Auditar de verdad — la skill que lee, clasifica y propone sin tocar nada; y el Top 10 convertido en recortes seguros, con la skill como unidad para reducir.
T4Probar y mantener — A/B/C en tareas reales para demostrar que no empeoró, y el ciclo continuo para que el sedimento no vuelva.

Los cuatro entregables del proyecto final

1 · Informe

10 secciones, guardadas en .md

2 · Antes/después

CLAUDE.md con diff