🔍 Cómo diagnosticar
¿Cómo revisar línea por línea y decir qué se queda, qué se elimina y qué hay que probar? Esta ruta te da la taxonomía — 10 categorías, 6 decisiones, 7 preguntas — y el cambio que más mejora la calidad: cambiar la receta por criterios y verificación.
Qué observar: el flujo no tiene dos salidas ("se queda" / "sale"): tiene seis. La caja resaltada no es la decisión: son las 7 preguntas, porque la pregunta decide, no el gusto. Y la salida marcada en cian es TEST: cuando no puedes responder «¿qué se rompe si desaparece?», el destino de la línea es la prueba de ablación, nunca KEEP por comodidad: KEEP sin respuesta es solo miedo disfrazado de criterio.
Mapa de la ruta
Contenido detallado
🔍 La taxonomía: qué es cada línea
Clasifica cada instrucción en una categoría y una decisión, basándote en 7 preguntas. Si tienes dudas, TEST: nunca KEEP por comodidad.
Cada instrucción de tu config cae en una de diez categorías: CONTEXTO, GUARDRAIL, CRITERIO DE CALIDAD, VERIFICACIÓN, INTEGRACIÓN/HERRAMIENTA, PROCEDIMIENTO REPETIBLE, MICROGESTIÓN, REDUNDANCIA, LEGADO/OBSOLETA y AMBIGUA/NO COMPROBADA. «El deploy es vía git» es CONTEXTO; «nunca hagas force push en main» es GUARDRAIL; «piensa paso a paso» es MICROGESTIÓN.
Sin nombre, todas las líneas parecen igual de importantes y terminas defendiéndolas todas. La categoría es lo que separa lo que el modelo no hay forma de saberlo (contexto, integraciones) que ya hace mejor por su cuenta (microgestión). Es el paso que permite debatir la auditoría con otra persona.
La categoría describe lo que hace la línea é, no qué hacer con ella. Las últimas cuatro (microgestión, redundancia, legado, ambigüedad) son las sospechosas naturales; las primeras seis aportan valor. Una línea puede tener dos categorías: eso ya es señal de que hay que dividirla en dos.
Después de la categoría viene la decisión. KEEP = se queda como está. SIMPLIFY = se queda, pero con la mitad de palabras. MOVE = está en el lugar equivocado (una regla de un proyecto en la configuración global, o viceversa). MERGE = dos líneas dicen lo mismo. TEST = no lo sabes, así que compruébalo mediante ablación. REMOVE = sabes que es peso muerto.
La auditoría falla cuando solo hay dos botones, «se queda» y «se va»: entonces todo se convierte en «se queda». Seis salidas permiten actuar con honestidad: la mayoría de las líneas no necesita desaparecer; necesita acortarse, cambiar de archivo o fusionarse con la de al lado.
Si tienes dudas, TEST — nunca KEEP. Una auditoría sin ninguna línea en TEST casi siempre significa que el autor está protegiendo su propia config. TEST no borra nada: solo programa la prueba.
¿Qué evita o garantiza esta línea? ¿El modelo actual todavía la necesita? Dice lo que debe ocurrir o dirige cómo ¿el modelo piensa? ¿Está duplicada en otro lugar? ¿Limita la autonomía sin motivo? ¿Hay una forma más corta? ¿Qué se rompe si desaparece?
Convierten una opinión («creo que esto ayuda») en un registro auditable. La más discriminante es la tercera: instrucción que dice qué suele sobrevivir; la instrucción que dirige cómo pensar es la que envejeció junto con el modelo antiguo.
Anota siempre la pregunta que decidiste y la respuesta a «¿qué se rompe si desaparece?». Si la respuesta es «no sé», la decisión ya está tomada: TEST. Ese par —pregunta + consecuencia— es lo que la Trilha 4 usará como hipótesis de la prueba A/B/C.
Identidad del proyecto, rutas y fuentes de verdad, branding, seguridad, compliance, contratos de interfaz, integraciones y convenciones internas. Nada de eso está en los pesos del modelo: no puede adivinar que tu deploy se hace por git, que la key está en tal `.env` o que la cuenta de destino del commit cambia según el repositorio.
La ablación se convierte en un desastre cuando alguien corta por entusiasmo. Esta lista es el freno: son las líneas cuya ausencia no degrada la calidad poco a poco; la rompe de una vez y, a veces, en producción.
Prueba rápida: si la información es específica de tu mundo y no se puede deducir del repositorio, es KEEP (como máximo SIMPLIFY). "No cortar" no significa "no acortar": el contexto verdadero también cabe en una línea.
La función objetivo de la auditoría es maximizar calidad + autonomía + verificabilidad ÷ complejidad. El recuento de líneas aparece solo en el denominador, y nunca por sí solo.
Quien solo persigue el denominador produce una configuración impecable y peor: elimina la verificación (que era barata y valiosa) junto con la microgestión. Una auditoría puede terminar legítimamente con la configuración mayor, si lo que se agregó fue un criterio de salida verificable.
Agregar una verificación aumenta el numerador. Quitar el paso a paso reduce el denominador e aumenta la autonomía. Son los dos movimientos de mayor rendimiento, y por eso existe el módulo 2.2.
Patrones que aparecen en casi toda configuración madura: regla duplicada entre `CLAUDE.md` y skills, skill demasiado grande, exceso de ejemplos, formato rígido sin motivo, excepciones acumuladas («excepto cuando…», tres veces), contradicciones entre archivos, contexto global que solo sirve para dos tareas — y, lo más costoso de todo, verificaciones faltantes.
Son atajos de lectura: en vez de volver a leer todo con la misma atención, revisas la configuración buscando estas cinco o seis señales y encuentras rápido las candidatas. La duplicación y las contradicciones son las que más sabotean en silencio: el modelo elige una de las dos versiones y nunca sabes cuál.
La señal más costosa es la que no está ahí. Las excepciones acumuladas son fósiles de un modelo antiguo; una contradicción es un bug silencioso; la falta de verificación es la instrucción que faltaba para que todo lo demás funcionara sin niñera.
🎯 Del micromanagement al criterio y la verificación
Deja de guionizar «haz A y después B». Escribe el objetivo, los guardrails, los criterios de salida y una forma real para que el modelo compruebe su propio trabajo.
Decirle al modelo cada paso del camino en vez de decirle adónde llegar. «Abre el archivo, busca la función, edita la línea 12, ejecuta el build, después…»: un itinerario que solo describe un el camino que habrías seguido.
Es el modo de fallo número uno y, curiosamente, es más frecuente entre quienes tienen años de experiencia en ingeniería, porque especificar bien siempre fue una virtud. Con los modelos antiguos, el guion ayudaba; con los actuales, bloquea la mejor ruta que el modelo encontraría por sí solo.
El nivel adecuado de instrucciones es el que le darías a un colega competente que acaba de incorporarse: contexto y criterio, no un paso a paso. Si tu instrucción no resistiría un «¿por qué?», es un guion.
Cambiar «haz A, luego B y luego C» por "Produce X. Respeta Y. El resultado debe alcanzar Z. Verifica usando W. Elige la estrategia." La misma intención, otra forma: lo que era una secuencia se convierte en objetivo más restricción más prueba.
Es la reescritura que suele acortar la instrucción y mejorar el resultado al mismo tiempo, porque devuelve al modelo la elección del camino, pero no la del estándar. Tú sigues teniendo el control de lo que importa: la Y y la Z.
Si al convertir no puedes escribir la Z ("el resultado debe alcanzar…"), el problema nunca fue el prompt: todavía no definiste lo que quieres. Y sin la W, la instrucción vuelve a depender de que revises cada resultado.
Objetivo (qué producir) · Contexto (qué no infiere el modelo) · Guardrails (qué nunca hacer) · Criterios de calidad (cuándo está bien) · Verificación (cómo comprobar) · Autonomía (qué puede decidir por su cuenta y cuándo detenerse para preguntar).
Completar los seis campos deja al descubierto el vacío en el momento. Casi todas las instrucciones malas que tienes hoy son fuertes en Objetivo, excesivas en pasos a seguir y vacía en Verificación y Autonomía —los dos campos que determinan si vas a tener que estar cerca.
Cada campo se corresponde directamente con la taxonomía del módulo 2.1: Contexto = CONTEXTO, Guardrails = GUARDRAIL, Criterios = CRITERIO DE CALIDAD, Verificación = VERIFICACIÓN. Lo que no encaja en ninguno de los seis campos probablemente sea microgestión.
Darle al modelo una forma real de comprobar su propio trabajo. El ejemplo de Cherny: reescribir una app Electron en Swift, ejecutar la original en una VM, tomar capturas de pantalla de ambas y compararlas píxel por píxel, sin parar hasta que coincidieran. Producir → observar → comparar → parar.
Un prompt breve con verificación supera por mucho a un prompt enorme sin verificación. Sin el paso de comparación, el modelo no tiene forma de saber que se equivocó, y tú terminas verificando manualmente para siempre.
Una buena verificación es ejecutable por un tercero: un comando, una prueba, una comparación, una verificación de archivo. «Revisa con cuidado» no es una verificación: es cruzar los dedos. Y toda verificación necesita una condición de parada explícita.
Darle al modelo una tarea un poco más difícil de lo que parece cómodo y guardar una lista de las solicitudes que fallaron para volver a ejecutarla con cada modelo nuevo.
La mayoría de las instrucciones defensivas de tu config existe por un fallo que hoy ya no ocurre. Sin volver a probarlas, nunca lo descubrirás y seguirás pagando complejidad por un problema resuelto hace dos modelos.
Esto es ciencia empírica, no teórica: no existe un truco secreto, existe una tarea difícil → una forma de verificar → observar dónde se atasca → corregir aquello → repetir. La lista de fracasos anteriores es tu benchmark personal, y es la que alimenta el ciclo de la Ruta 4.
Elige la instrucción más «receta paso a paso» de tu configuración o de una skill tuya y escribe dos versiones junto a la original: (a) 50% más corta, manteniendo la intención; (b) mínima, con la plantilla de 6 campos y un paso de verificación objetivo.
Leer sobre la conversión no cambia nada; hacerlo una vez sí. Las dos versiones lado a lado revelan cuánto del texto original era el proceso y cuánto eran los criterios; normalmente, la respuesta sorprende.
Criterio de salida del ejercicio: la versión mínima tiene una verificación que otra persona podría ejecutar sin preguntarte nada. Si te necesita para explicarlo, aún no es una verificación. Guarda las tres versiones: se convierten en los brazos A/B/C de la prueba de ablación.