🔬 Entiende qué significa ablación
Ablación es un término tomado de la investigación: tú elimina un componente de un sistema para medir el impacto que tenía. No es limpieza ni opinión: es un experimento. La pregunta que responde la ablación es siempre la misma: ¿qué cambia cuando esto ya no está aquí?
Aplicado a un prompt y a una configuración, el método es literal: se borra todo el prompt del sistema y después se vuelve a agregar cada línea, una por una, para descubrir lo que realmente hace cada una. Así fue como el equipo de Claude Code descubrió que más del 80% de su propio prompt del sistema no hacía nada: el modelo ya resolvía eso por sí solo.
🆕 ¿Nuevo aquí? Tres palabras de este módulo
- Ablación: eliminar intencionalmente una parte del sistema para medir cuánto contribuía.
- Hook: un gancho de automatización de Claude Code: un comando que se ejecuta automáticamente antes o después de una acción (p. ej., ejecutar el formateador cada vez que se guarda un archivo).
- Línea de base (baseline): la medición de referencia: cómo se comporta el sistema sin nada por encima. Es contra ella que comparas todo lo demás.
Qué observar: las dos rutas tienen el mismo número de pasos y la de arriba hasta parece más responsable («leí todo con atención»). Pero fíjate en la última caja de cada línea: solo la de abajo termina en un dato. Revisar el prompt leyéndolo produce una opinión; quitarlo y usarlo produce evidencia. Fíjate también en que el paso en cian — “usarlo de verdad”: es lo único que no ocurre en tu cabeza.
✓ Esto es ablación
- ✓Quitar la instrucción y volver a ejecutar la misma tarea real
- ✓Comparar el resultado con y sin, en la misma tarea
- ✓Concluir que «empataron» y dejarlo eliminado
✗ Esto no es una ablación
- ✗Volver a leer el
CLAUDE.mdy creer que la línea 42 es importante - ✗Pídele al modelo que “revise mi prompt”: también está adivinando
- ✗Reducir todo de una vez y nunca usar la configuración reducida en trabajo real
📅 Marca cuándo borrarla
El consejo de Boris Cherny para quien usa Claude Code —y no construye productos agénticos— es
incómodamente directo: aproximadamente cada seis meses, y sobre todo
cuando se lance un modelo importante, borra el CLAUDE.md, elimina las skills, elimina los hooks y mira qué hace el modelo sin ellos. No es retórica. Es la recomendación literal.
Dos razones respaldan este calendario, y conviene entender ambas porque apuntan en la misma dirección.
📊 Las dos razones, en cifras
- Eres pésimo prediciendo. Ni siquiera el equipo que creó Claude Code acertaba: cuando midieron, más de 80% del prompt del sistema era peso muerto. Si quien escribió el harness se equivocó en un 80%, tu intuición sobre tu propio
CLAUDE.mdno es mejor. - Cada línea cuesta en cada ejecución. Una regla en el
CLAUDE.mdno se lee “cuando sea necesario”. Se incorpora al contexto en 100% de las ejecuciones, incluso en el 95% en que es irrelevante. El costo no está en escribir la línea: está en volver a leerla para siempre. - El desencadenante no es solo el calendario. Un gran lanzamiento de modelo importa más que la fecha: es exactamente ahí cuando desaparecen debilidades antiguas y las correcciones escritas para ellas se convierten en lastre.
💡 "Borrar" aquí es reversible
Borrar no significa destruir. Significa retirar de circulación durante un período de trabajo real, con la versión anterior guardada y recuperable — en git o simplemente cambiándole el nombre al archivo. Si no puedes volver atrás en 30 segundos, no estás haciendo un experimento: estás asumiendo un riesgo. El tema 4 muestra cómo construir esa red.
🔁 Sigue las 4 etapas de la reconstrucción
Borrar es solo la primera mitad. La reconstrucción es lo que determina si la nueva configuración será realmente más pequeña o si solo diferente. Son cuatro etapas, y la cuarta es la única que suelen saltarse, justo por eso la mayoría de las configuraciones vuelve a su tamaño original en dos semanas.
El ciclo, paso a paso
-
1
Borra la configuración
CLAUDE.md, skills, hooks. Fuera de circulación, con la versión anterior guardada. Sin términos medios: recortar «solo las peores» no mide nada, porque sigues confiando en tu predicción sobre cuáles eran las peores. -
2
Úsalo en trabajo real — nunca en una prueba hipotética
El producto real, la base de código real, la tarea que harías hoy de todos modos. Una prueba inventada produce fallas inventadas: terminas devolviendo instrucciones para problemas que nunca tendrías en la práctica.
-
3
Observa en qué va bien y dónde tropieza
Registra ambos lados. Anotar solo los tropiezos sesga la lectura: terminas el experimento convencido de que todo empeoró, cuando el 90 % quedó igual. El acierto sin instrucciones es la evidencia más valiosa que existe.
-
4
Devuelve una instrucción solo después de ver que el fallo se REPITE
Esta es la etapa que importa. Una falla aislada puede ser ruido: contexto deficiente, pedido ambiguo, un día extraño. Solo la repetición de la misma clase de una falla demuestra que existe una brecha estructural, y solo una brecha estructural justifica pagar contexto para siempre.
Qué observar: la flecha cian la línea discontinua es la más ancha del diagrama por un motivo. En la práctica, la mayoría de las observaciones termina en ella: el tropiezo no se repite y simplemente sigues trabajando sin escribir ninguna regla. El recuadro 4, con el brillo, parece el destino del flujo, pero está marcado como «salida poco frecuente». Una configuración que crece cada semana es una configuración en la que nunca se usa ese regreso.
⚙️ Establece tu línea de base
Hay dos mecanismos para ejecutar tu propia ablación. El primero es la flag de prompt del sistema
al iniciar Claude Code: reemplaza el prompt del sistema por lo que quieras, incluso por nada.
El segundo es el variable de entorno CLAUDE_CODE_SIMPLE=1, poco documentada, que elimina todos los prompts del sistema — incluidos los prompts asociados a cada
herramienta. Es la línea de base de ablación que se usa internamente en Anthropic.
Una variable de entorno es un valor que defines en la terminal y que el programa lee al iniciarse; escribirlo delante del comando (VAR=1 comando) vale solo para esa ejecución: nada queda configurado permanentemente. Por eso es el instrumento perfecto para un experimento.
🧪 Copia y ejecuta: la línea de base
Objetivo: abrir una sesión sin ningún prompt de sistema y, luego, una sesión sin tu CLAUDE.md. Ambas son reversibles.
# 1) Linha de base total — remove TODOS os prompts de sistema, # inclusive os das ferramentas. Vale só para esta sessão. CLAUDE_CODE_SIMPLE=1 claude # 2) Alternativa mais segura — mantém o produto normal, # mas tira só a SUA configuração do caminho. mv ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak claude # trabalhe normalmente por alguns dias # 3) Restaurar quando quiser (ou quando o experimento acabar) mv ~/.claude/CLAUDE.md.bak ~/.claude/CLAUDE.md
Cómo verificar: tres señales de que la ablación
realmente está activa: (1) ls ~/.claude/CLAUDE.md devuelve “No such file” durante el experimento;
(2) en la sesión, pide “resume en una frase las reglas que recibiste en este proyecto” — si repite tus reglas
de siempre, algo no se eliminó (revisa el CLAUDE.md del proyecto, además del global);
(3) el comportamiento cambia en algo — si nada cambió, genial: ese ya es el primer resultado del experimento.
Cambia: el camino global por ./CLAUDE.md si lo que quieres ablacionar es la configuración de un proyecto específico.
⚠️ Hazlo con la config bajo git
Antes de mover o borrar cualquier cosa, asegúrate de que ~/.claude/ (o la carpeta .claude/ del proyecto)
esté versionada y con todo commiteado. Un mv mal escrito en un directorio sin git se lleva meses de
skills y hooks sin avisar, y el experimento se convierte en una pérdida.
Regla práctica: si no puedes restaurarlo todo con un comando, no empieces. Las Skills y los hooks también
cuentan, no solo el CLAUDE.md.
💡 El detalle contraintuitivo
Sin los prompts de sistema, el modelo queda ligeramente más inteligente. No es un error de lectura: menos instrucciones, un resultado un poco mejor. El prompt exige atención y parte de él empuja al modelo por caminos que ya no tendría que seguir.
Entonces, ¿por qué los prompts siguen ahí? Porque hacen que Claude Code comportarse como la persona espera
al usar un producto: formato de salida predecible, permisos, tono, uso de herramientas. La conclusión práctica para ti
es buena: si ni siquiera existe el prompt oficial por falta de capacidad, mucho menos tus 300 líneas de CLAUDE.md.
🎯 Retira tus evals en el momento adecuado
Si las instrucciones envejecen rápido, ¿qué perdura? Evals duran más, pero no para siempre. Una eval suele sobrevivir de una a tres generaciones de modelos antes de que el modelo saturarla; en ese punto se descarta y se reemplaza por otra más difícil.
🆕 ¿Nuevo aquí? Evaluación y saturación
- Eval: un caso de prueba para el modelo. Una tarea concreta, con una forma clara de saber si el resultado se aprobó o no. Es la «prueba automatizada» de tu trabajo con el agente: mide la capacidad, no corrige el comportamiento.
- Saturar una eval: el modelo empieza a acertarla siempre. A partir de ahí deja de aportar información: tanto si el modelo es bueno como si es excelente, el resultado es el mismo. Una eval saturada es ruido disfrazado de métrica.
✓ Eval que vale la pena conservar
- ✓Nació de un punto en el que tú realmente observó que el modelo tropiece
- ✓Todavía falla a veces —el resultado varía, así que aún mide algo
- ✓Usa una tarea de tu trabajo real, con un criterio de aprobación escrito de antemano
✗ Eval para retirar
- ✗Pasa el 100% de las veces con tres generaciones de modelos
- ✗Se inventó en teoría («sería bueno probar esto»), sin que hubiera una falla observada detrás
- ✗Poner a prueba una debilidad de un modelo que ya ni usas
📊 La curva de vida de una eval
- Generación 0: ves el fallo en un trabajo real y conviertes el caso en una eval. Falla con frecuencia.
- Generación 1 a 3: la tasa de aciertos sube, pero fluctúa. Es la fase útil: la eval todavía distingue un buen modelo de uno excelente.
- Saturación: aciertos constantes del 100%. La eval ya no distingue nada; mantenerla solo consume tiempo de ejecución y da una falsa sensación de cobertura.
- Jubilación: archívala (no borres el historial: documenta lo que ya fue difícil) y escribe una nueva a partir del tropiezo más reciente que observaste.
💡 Eval no es una instrucción
Confusión común: «si el modelo se equivoca con X, escribo una regla sobre X». Pero la eval y la instrucción resuelven cosas distintas. La eval detecta el problema y cuesta cero contexto: se ejecuta cuando tú la ejecutas. La instrucción intenta corregir el problema y cuesta contexto en cada ejecución. Ante una falla nueva, primero va la eval; la instrucción, solo si la regla de reintroducción del siguiente tema lo autoriza.
📓 Aplica la regla de reintroducción
Una instrucción eliminada no vuelve porque la hayas echado de menos. Vuelve cuando pasa por cuatro condiciones, todas juntas. Si falta alguna, la instrucción sigue fuera, y el trabajo continúa normalmente sin ella.
✓ Las 4 condiciones para devolver
- ✓1. Falla real: ocurrió en un trabajo tuyo, no en una prueba inventada
- ✓2. Repetición: a misma clase de una falla volvió a ocurrir al menos una segunda vez
- ✓3. La instrucción específica resuelve: se puede señalar qué frase habría evitado eso
- ✓4. Forma más breve posible: una línea, no un procedimiento de 12 pasos
✗ Motivos que no cuentan
- ✗“Me siento más seguro con esta regla ahí”
- ✗Se equivocó una vez, en una solicitud que tú mismo redactaste mal
- ✗“Ya que estoy haciendo cambios, aprovecho y restauro las otras tres”
- ✗El fallo era otro y, por asociación, devolviste la regla antigua
📝 Ejercicio: crea tu ablacao-diario.md
Objetivo: registrar una tarea real hecha con la config eliminada. Sin diario, la etapa 4 del ciclo es imposible — no tienes cómo saber si el fallo se repitió.
# Diário de ablação Config ablacionada em: 2026-08-18 O que saiu: CLAUDE.md global · skills X e Y · hook de pre-commit Como restauro: `mv ~/.claude/CLAUDE.md.bak ~/.claude/CLAUDE.md` --- ## Tarefa 1 — <o que você realmente precisava fazer> - **Data:** 2026-08-18 - **Tarefa real:** refatorar o módulo de export do projeto Z - **Acertos (foi bem sem instrução):** - encontrou os arquivos certos sozinho - rodou os testes sem eu pedir - **Tropeços (onde falhou):** - commitou sem eu autorizar - **Classe do tropeço:** permissão / commit não solicitado - **Repetiu?** ainda não (1ª ocorrência) - **Instrução devolvida:** NENHUMA — aguardando repetição
Cómo verificar: el campo “Clase del tropiezo” es lo que hace que el diario funcione. Debe ser lo bastante genérico para que reconozcas la misma falla dentro de una semana en un contexto diferente — “hizo commit sin autorización” es una clase; “hizo commit del archivo utils.ts a las 14h” es una anécdota. Si no puedes nombrar la clase, el tropiezo probablemente fue ruido.
Criterio de salida de este módulo: diario con ≥1 tarea real registrada, con aciertos, tropiezos y «¿se repitió?» completados, y todavía no se devolvió ninguna instrucción. Devolverlo en la primera aparición es el error que todo este módulo existe para evitar.
Borraste el CLAUDE.md y, en la primera tarea real, el modelo hizo commit sin autorización. ¿Qué indica la regla de reintroducción que hay que hacer?
📌 Resumen del Módulo
CLAUDE.md, skills y hooks y observa qué hace el modelo sin ellos.CLAUDE_CODE_SIMPLE=1 es la línea de base — elimina todos los prompts del sistema; sin ellos, el modelo se vuelve ligeramente más inteligente.Próximo módulo:
2.1 — La taxonomía: qué es cada línea. Diez categorías, seis decisiones y las siete preguntas que clasifican cualquier instrucción de tu config.