13 de abril, ABMedia informó que Forrest Chang convirtió las quejas de Karpathy sobre Claude al escribir código en un paquete de «4 reglas de CLAUDE.md», con 15.000 estrellas acumuladas en GitHub en ese momento; el 12 de mayo, el número de estrellas de ese repo ya superaba las 126.000, creciendo 8 veces en menos de 1 mes. A raíz de ello, la comunidad comenzó a aparecer con muchos intentos de «versiones ampliadas»; entre ellos, el post «Añadir 8 reglas sobre la base de las 4 para convertirlo en un conjunto completo de 12 reglas», publicado por el ingeniero Mnilax ( @Mnimiy ) el 9 de mayo, obtuvo 5.968 me gusta y es uno de los contenidos de una sola pieza con mayor conversación en la comunidad del Claude Code recientemente.
Repaso de las 4 reglas: Forrest Chang convirtió las quejas de Karpathy en una plantilla ejecutable
Las 4 reglas originales de Forrest Chang (cada una corresponde a un patrón de fallo señalado por Karpathy en enero en X) :
Think Before Coding (primero piensa antes de codificar): no hagas suposiciones implícitas; dilo explícitamente en qué estás asumiendo; abre el debate sobre los trade-off; si no estás seguro, pregunta directamente y no adivines; si hay una forma más simple, opónte a una solución compleja
Simplicity First (primero la simplicidad): escribe el código mínimo que resuelva el problema; no escribas funcionalidades especulativas; no crees capas de abstracción para código de una sola vez; los ingenieros senior dirán que un diseño demasiado complejo debe simplificarse
Surgical Changes (cambios quirúrgicos): cambia solo lo que deba cambiarse, no «mejorar de paso» código adyacente, comentarios ni formato; no refactorices cosas que no están rotas; sigue el estilo existente
Goal-Driven Execution (ejecución guiada por objetivos): define criterios de éxito e itera hasta verificar; no le digas a Claude los pasos, dile «cómo se ve el éxito» para que haga su propio loop
Los documentos oficiales de Anthropic en realidad lo dicen muy claro: CLAUDE.md es un archivo «advisory» (de recomendación), y Claude aproximadamente tiene una probabilidad del 80% de cumplirlo; después de superar las 200 líneas, la tasa de cumplimiento cae de forma drástica, porque las reglas importantes quedan ahogadas por el ruido. La propuesta de Forrest Chang comprime las reglas a 65 líneas, 4 reglas, logrando el «floor» (umbral mínimo).
Las 8 reglas añadidas por Mnilax: completar con nuevos patrones de fallo de la era del agente en 2026/5
La postura de Mnilax: las quejas de Karpathy de enero se centraban en el escenario de «Claude escribiendo código», pero el ecosistema de Claude Code en mayo ya evolucionó hacia escenarios nuevos como la colaboración entre múltiples agentes, encadenamiento de hooks, conflictos en la carga de skills y flujos de trabajo de varios pasos que cruzan sesiones; hace falta añadir reglas. Estas son las 8 reglas que añadió (ordenadas según el texto original) :
Regla 5: usa a Claude solo para tareas que requieran juicio (clasificación, redacción, resumen, extracción) y usa código normal para decisiones deterministas (reintentos de 503, routing, manejo de status code, conversiones deterministas)
Regla 6: el token budget no es una sugerencia—límite de 4.000 tokens por tarea y 30.000 tokens por sesión; cuando te estés acercando al budget, resume y reinicia de forma proactiva, no excedas en silencio
Regla 7: dos patrones de código en conflicto deben «indicar explícitamente cuál elegir» (el más nuevo o el que tenga más pruebas), explicar por qué se eligió, y marcar el otro para limpieza; mezclar ambos patrones es la peor opción
Regla 8: antes de escribir código, primero entiende—lee exports, el caller directo, utilidades compartidas; «aparentemente no relacionado (looks orthogonal)» es la redacción más peligrosa; si no estás seguro, pregunta
Regla 9: las pruebas deben validar «intención», no solo validar «comportamiento»—una prueba válida es la que puede fallar cuando cambia la lógica de negocio; de lo contrario, solo haces que Claude esté seguro, sin protección real
Regla 10: las tareas de varios pasos deben tener checkpoint—después de completar cada paso, resume «qué hiciste, qué verificaste y qué queda»; si no puedes describir el estado de forma clara, no continúes
Regla 11: sigue las convenciones del codebase existente, incluso si no estás de acuerdo—snake_case es snake_case, class component es class component; si no lo apruebas, trátalo como otra discusión y no te desvíes unilateralmente
Regla 12: los fallos deben ser ruidosos—«migration completada» no es válido si te saltaste 30 artículos; «pruebas pasaron» no es válido si saltaste cualquiera; asume exponer de forma proactiva la incertidumbre, no «esconder la incertidumbre»
Mnilax afirma que, probando estas 12 reglas en 30 codebase durante 6 semanas, redujo la tasa de errores del 41% al 3%, y que la tasa de cumplimiento solo bajó ligeramente (78% → 76%). Observación de este medio: estas cifras son resultados de pruebas autoinformados por el autor, no verificados de forma independiente; aun así, el contenido de las 8 reglas en sí es sólido y coincide de forma estrecha con los puntos dolorosos relacionados con los escenarios actuales de uso de múltiples agentes en Claude Code (por ejemplo, la gestión de múltiples sesiones en Agent View, y el Multi-Agent Layer dentro de una arquitectura de seis capas).
Situaciones de aplicación y recomendaciones prácticas
Mnilax también señala con franqueza cuáles enfoques no deberías intentar:
Más de 14 reglas: la tasa de cumplimiento cae al 52% (desde el 76% una caída brusca), y 200 líneas son un límite real
Usar ejemplos en lugar de reglas: el costo en tokens de 3 ejemplos equivale a 10 reglas; Claude tiende a sobreajustar un único ejemplo
Instrucciones abstractas como «Be careful / think hard / really focus»: baja verificabilidad, y la tasa de cumplimiento es solo del 30%
Decirle a Claude «como un ingeniero senior»: un identity prompt no es efectivo para cambios de comportamiento; las reglas basadas en patrones sí lo son
Depender de herramientas específicas: «usar siempre eslint» fallará de forma silenciosa si eslint no está instalado; cambiar a un lenguaje neutral como «alinearse con el estilo existente del codebase» es más apropiado
La forma práctica que recomienda este medio: CLAUDE.md es un «contrato de comportamiento», no una lista de deseos—cada regla debe responder «qué error concreto evita esta regla». Si tu trabajo no implica un pipeline de varios pasos, Rule 10 (checkpoint) no sirve; si tu codebase ya tiene lint para imponer un único estilo, Rule 11 (alinearse con convenciones) es redundante. Después de leer las 12 reglas, conserva la versión que se corresponde con los baches reales que ya has pisado; el resto, puedes eliminarlo.
Los eventos que se pueden seguir a continuación incluyen: si Anthropic oficializa (regulariza) las reglas de CLAUDE.md (por el momento solo es «advisory»), si el repo de Forrest Chang entra en la plantilla recomendada por la oficina, si la comunidad crea versiones personalizadas para dominios específicos (frontend / backend / ingeniería de datos), y si la tasa de cumplimiento cambia después de las actualizaciones de versión del modelo de Claude.
Este artículo: Karpathy CLAUDE.md alcanza 126K estrellas—organización de reglas avanzadas de 12 reglas de la comunidad. Apareció por primera vez en ABMedia de la cadena de noticias.
