El martes pasado le pedí a Claude Code que arreglara una sola comprobación de null en una clase de servicio de Laravel. Una línea. Null-coalesce en lugar de un if anidado.
Me devolvió un diff de 214 líneas.
Constantes de clase nuevas. Un método renombrado. Cuatro refactorizaciones no relacionadas en archivos que ni siquiera había abierto. Un comentario en bloque de "ya que estamos aquí" explicando por qué el autor anterior se había equivocado. La comprobación de null quedó enterrada en la línea 138, correcta, rodeada de una reorganización completa de un archivo que había funcionado perfectamente durante once meses.
Ese es el comportamiento que el plugin de Skills de CLAUDE.md de Karpathy está diseñado para detener. Y tras instalarlo en tres proyectos separados —una base de código de agencia en Laravel 13, una build personal en Next.js 15 y el pipeline de contenido que impulsa este blog— estoy listo para contarte qué cambia de verdad, dónde aguantan los guardarraíles y dónde no.
Si has leído mis notas de la primera build sobre el workflow de Claude Routines con Opus 4.7, ya sabes que llevo viviendo dentro de Claude Code a tiempo completo. Este post es la continuación natural: una vez estás en Claude Code todos los días, notas exactamente qué comportamientos te comen las mañanas — y el plugin de Skills de Karpathy apunta a los cuatro peores.
Por qué este repo alcanzó 71.5k estrellas en menos de un mes
El proyecto se llama andrej-karpathy-skills. Mientras escribo esto, está en 71.5k estrellas, 6.5k forks, 28 commits y 8 contribuidores. Es una ratio estrella-a-commit absurda. La mayoría de los repos que suben así son frameworks con 50.000 líneas de código. Este es esencialmente un único archivo CLAUDE.md más un manifiesto de plugin, un directorio de skills, una carpeta de reglas para Cursor y un puñado de ejemplos.
Ese es el producto entero. Un archivo markdown que remodela cómo se comporta Claude Code.
La razón por la que explotó es simple: nombra los cuatro modos de fallo contra los que todo ingeniero en activo ha estado maldiciendo a su asistente de IA durante el último año, y empaqueta la solución como cuatro principios nombrados que Claude respeta de verdad una vez están en la ventana de contexto. Andrej Karpathy no escribió el repo (es de forrestchang), pero los principios están destilados directamente de las observaciones públicas de Karpathy en X sobre las trampas del coding con LLM — la más famosa, su descripción de los asistentes de IA como "un savant becario júnior sobreentusiasta con conocimiento enciclopédico del software, pero que también te suelta mentiras todo el rato, tiene una sobreabundancia de valentía y muestra poco o ningún gusto por el buen código".
Esa sola cita explica todo el repo. El becario es brillante. El becario también es peligroso sin correa.
El plugin de Skills de CLAUDE.md de Karpathy es la correa.
Qué hay realmente en el repo
Antes de la instalación, necesitas saber qué estás metiendo. Este es el layout del directorio en la raíz:
.claude-plugin/
plugin.json
.cursor/
rules/
karpathy-guidelines.mdc
skills/
karpathy-guidelines/
SKILL.md
CLAUDE.md
CURSOR.md
EXAMPLES.md
README.md
README.zh.md
LICENSE
Cuatro mecanismos de entrega, los mismos cuatro principios:
CLAUDE.md— el archivo drop-in para raíces de proyecto de Claude Code.claude-plugin/plugin.json— el manifiesto para el flujo del marketplace de plugins de Claude Codeskills/karpathy-guidelines/SKILL.md— la versión en formato skill, compatible con el ecosistema skills.sh del que hablé a principios de este año.cursor/rules/karpathy-guidelines.mdc— el equivalente de Cursor, añadido en los últimos commits
El manifiesto del plugin es deliberadamente minúsculo. Aquí está tal cual:
{
"name": "andrej-karpathy-skills",
"description": "Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls",
"version": "1.0.0",
"author": {
"name": "forrestchang"
},
"license": "MIT",
"keywords": ["guidelines", "best-practices", "coding", "karpathy"],
"skills": ["./skills/karpathy-guidelines"]
}
Una versión, una referencia a skill, licencia MIT. Sin dependencias. Sin scripts de post-instalación. Sin telemetría. Es el tipo de repo que confío en instalar sin leer cada byte — pero igualmente leí cada byte, y tú deberías hacer lo mismo.
Ahora la parte interesante. Los cuatro principios en sí.
Los cuatro principios, literales del CLAUDE.md
Voy a citarlos exactamente como aparecen en el archivo fuente, porque parafrasearlos les quita filo. La especificidad es el punto.
1. Think Before Coding
"Don't assume. Don't hide confusion. Surface tradeoffs."
- Declara tus suposiciones explícitamente. Si hay incertidumbre, pregunta.
- Si existen múltiples interpretaciones, preséntalas — no elijas en silencio.
- Si hay un enfoque más simple, dilo. Discute cuando esté justificado.
- Si algo no está claro, para. Nombra qué es confuso. Pregunta.
Modo de fallo que esto previene: las suposiciones silenciosas. El peor comportamiento individual en el coding asistido por IA. Pides "un endpoint de exportación de usuarios" y te devuelve una descarga CSV sirviendo cada campo de la base de datos porque el modelo decidió que querías eso. Sin este principio, Claude adivina. Con él, Claude pregunta si la exportación debe estar acotada, qué campos son sensibles y si necesitas JSON o CSV antes de escribir una sola línea.
2. Simplicity First
"Minimum code that solves the problem. Nothing speculative."
- Sin features más allá de lo que se pidió.
- Sin abstracciones para código de un solo uso.
- Sin "flexibilidad" ni "configurabilidad" que no se haya pedido.
- Sin manejo de errores para escenarios imposibles.
- Si escribes 200 líneas y podrían ser 50, reescríbelo.
Modo de fallo que esto previene: el problema del patrón-estrategia-para-un-solo-if. Pides un cálculo de descuento y te devuelve un DiscountStrategyFactory abstracto con reglas de redondeo configurables, un enum de tipos de promoción y una dataclass DiscountContext. El problema real era price * 0.1. Este principio es la razón por la que mis proyectos de prueba bajaron de implementaciones sobrecargadas de 180 líneas a unas de 30, sin perder una sola feature real. Es el mismo patrón de sobreingeniería que señalé en tres de los modelos en mi roundup de herramientas de IA de abril 2026 — casi todo modelo frontera te construirá encantado la catedral cuando pediste una caseta.
3. Surgical Changes
"Touch only what you must. Clean up only your own mess."
- No "mejores" código adyacente, comentarios ni formato.
- No refactorices cosas que no estén rotas.
- Iguala el estilo existente, aunque tú lo harías distinto.
- Si notas código muerto no relacionado, menciónalo — no lo elimines.
- Elimina imports/variables/funciones que TUS cambios dejaron sin usar.
- No elimines código muerto preexistente salvo que se pida.
Modo de fallo que esto previene: la refactorización al paso. El comportamiento exacto que me comió el martes por la mañana. Este es el principio con mayor impacto percibido. Con él activo, el diff de 214 líneas se convierte en uno de 1 línea, y Claude te dice al final "noté que la clase tiene tres imports sin usar de una refactorización de hace dos commits — ¿quieres que lo aborde por separado?" en lugar de simplemente borrarlos.
4. Goal-Driven Execution
"Define success criteria. Loop until verified."
- Transforma las tareas en objetivos verificables
- Para tareas multi-paso, declara un plan breve con pasos y comprobaciones de verificación
- Unos criterios de éxito sólidos te permiten iterar de forma independiente
Modo de fallo que esto previene: el cierre por vibes del "creo que ya está". El propio encuadre de Karpathy sobre esto es la línea más punzante de todo el repo: "Los LLM son excepcionalmente buenos iterando hasta cumplir objetivos específicos… No le digas qué hacer, dale criterios de éxito y míralo ir." Una vez cargado este principio, Claude deja de decir "He añadido rate limiting, avísame si hay algo más" y empieza a decir "Rate limiting añadido. Plan de verificación: (a) curl 10 requests bajo el límite y esperar 200s, (b) curl 11 y esperar un 429 en el último, (c) correr la suite de tests existente. Ejecutando ahora."
Esos cuatro bullets son todo el framework. Todo lo demás en este post es cómo cargarlos, cómo mantenerlos cargados y cómo saber que están funcionando.
Los tres caminos de instalación — y cuál quieres de verdad
El repo trae tres caminos de instalación porque hay tres contextos distintos donde puedes querer estos principios activos. Probé los tres. Cada uno tiene un caso de uso específico, y mezclarlos desperdicia tokens y causa colisiones de reglas.
Camino A — La instalación como plugin de Claude Code
Este es el camino más limpio si quieres las guidelines disponibles en cada sesión de Claude Code de tu máquina, independientes de cualquier proyecto. Dos comandos:
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
Son slash commands que pegas en el propio Claude Code, no en bash. El primero añade el repo como fuente del marketplace de plugins. El segundo instala el plugin, que registra el archivo skills/karpathy-guidelines/SKILL.md como skill disponible. Claude lo auto-cargará cuando la sesión coincida con la descripción de activación del skill.
Dónde aterrizan los archivos realmente: Claude Code guarda los plugins instalados en ~/.claude/plugins/andrej-karpathy-skills/. El manifiesto del skill vive en ~/.claude/plugins/andrej-karpathy-skills/skills/karpathy-guidelines/SKILL.md. Puedes verificarlo con:
ls -la ~/.claude/plugins/andrej-karpathy-skills/
cat ~/.claude/plugins/andrej-karpathy-skills/.claude-plugin/plugin.json
Cuándo usarlo: quieres los principios activos globalmente, en todos los repos, sin tocar archivos de proyecto. Ideal para desarrolladores en solitario en máquinas donde tú eres el único usuario.
Cuándo saltárselo: estás en una base de código de equipo. La carga a nivel de skill es por usuario, así que tus compañeros no tendrán el mismo comportamiento. Para consistencia de equipo, quieres el Camino B.
Camino B — El drop-in (o merge) del CLAUDE.md en la raíz del proyecto
Este es el camino que uso en cada proyecto real de cliente. Las guidelines viven en el repo, se versionan junto al código, y cada compañero que corra Claude Code en ese checkout obtiene el mismo comportamiento automáticamente.
Si el proyecto aún no tiene CLAUDE.md, es un comando:
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
Commit. Listo. La siguiente sesión claude en ese directorio cargará los cuatro principios en el contexto del sistema antes de tu primer mensaje.
Si el proyecto ya tiene un CLAUDE.md — cosa que probablemente ya tiene — no lo sobrescribas. Lo hice una vez en el repo ai-agents-team (el que impulsa este blog) y perdí toda mi configuración de generación de contenido durante unos noventa segundos antes de darme cuenta y recuperarla desde git. No seas como yo.
En su lugar, fusiona. Este es el flujo exacto que uso ahora:
# 1. Fetch the Karpathy principles to a temp file
curl -o .karpathy-skills-temp.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
# 2. Append as a new section to your existing CLAUDE.md
{
echo ""
echo "---"
echo ""
echo "# Coding Behavior (Karpathy Guidelines)"
echo ""
echo "_Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT_"
echo ""
cat .karpathy-skills-temp.md
} >> CLAUDE.md
# 3. Clean up the temp file
rm .karpathy-skills-temp.md
# 4. Verify the result opens cleanly and your original rules are still on top
head -40 CLAUDE.md
tail -60 CLAUDE.md
La regla del orden de secciones importa. Claude trata las reglas más tempranas en CLAUDE.md como de mayor prioridad cuando hay conflictos. Quieres el comportamiento específico del proyecto (tus plantillas de contenido, tus convenciones de Laravel, tus reglas de despliegue) arriba, y los principios de Karpathy como sección general de comportamiento de coding más abajo. Son meta-reglas sobre cómo debe Claude abordar el código — no reglas de dominio sobre qué debe construir Claude — así que pertenecen a la parte de atrás del archivo, no al frente.
Cuándo usarlo: cualquier base de código de equipo, cualquier proyecto que te importe a largo plazo, cualquier repo donde quieras comportamiento del agente bajo control de versiones.
Camino C — La instalación en Cursor
Si estás en Cursor en lugar de Claude Code, el repo trae un archivo .cursor/rules/karpathy-guidelines.mdc que funciona con el sistema de reglas de Cursor. Instala copiando el archivo en tu proyecto:
mkdir -p .cursor/rules
curl -o .cursor/rules/karpathy-guidelines.mdc \
https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/.cursor/rules/karpathy-guidelines.mdc
El motor de reglas de Cursor auto-carga cualquier archivo .mdc en .cursor/rules/ al abrir el proyecto, así que se activa en la siguiente sesión. El contenido son los mismos cuatro principios en el formato de regla de Cursor — un archivo .mdc es simplemente markdown con un bloque corto de frontmatter que declara cuándo debe aplicar la regla.
Cuándo usarlo: estás principalmente en Cursor. Yo sigo corriendo Claude Code para trabajo agéntico, así que instalo ambos — los archivos no chocan porque viven en directorios específicos de cada herramienta.
Cómo verificar que está realmente activo
Instalar es una cosa. Saber que está haciendo algo es otra. Cada sistema de skill/plugin que he usado tiene un problema de "¿eso llegó a cargarse?", y la respuesta nunca es simplemente confiar en el mensaje de instalación.
Esta es mi verificación en tres pasos que corro tras cada instalación:
Paso 1 — Test de read-back. Abre una sesión fresca de Claude Code en el proyecto y pregunta:
"¿Qué principios de comportamiento de coding están cargados ahora mismo en tu contexto? Lístalos con su fuente."
Si la instalación funcionó, Claude listará los cuatro principios de Karpathy por nombre — Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution — y citará el archivo CLAUDE.md o el skill del plugin como fuente. Si lista "buenas prácticas de coding" genéricas sin los nombres de Karpathy, algo va mal: o el archivo no se guardó, o el plugin no se instaló, o estás en un directorio que Claude no considera raíz del proyecto.
Paso 2 — Test de comportamiento. Dale una tarea diseñada específicamente para disparar el viejo mal comportamiento:
"Arregla la comprobación de null en la línea 42 de UserService.php."
Sin las guidelines: diff desbordado, refactor no solicitado, cambios de estilo, la experiencia completa del martes por la mañana. Con las guidelines: Claude debería hacer exactamente lo que pediste, hacer la edición mínima y marcar cualquier otra cosa que haya notado en un mensaje separado en lugar de enviarla.
Paso 3 — Trampa de scope-creep. Esta es la que realmente te lo dice.
"Añade un rate limit al endpoint de login. Ya que estás ahí, añade también request logging."
Sin las guidelines: Claude hace ambas, las presenta como un solo cambio y probablemente mete un refactor del middleware de auth de regalo. Con Goal-Driven Execution activo, Claude debería separar las tareas, declarar criterios de éxito para cada una y — este es el indicador — proponer comprobaciones de verificación para el rate limit específicamente antes de tocar la tarea de logging. Si las colapsa en un único cambio sin verificar, los principios no están cargados correctamente.
He corrido este test de tres pasos en cada instalación. Tarda unos cuatro minutos. Sáltatelo y estás confiando en el autoreporte del modelo sobre si los guardarraíles están arriba, y el autoreporte es exactamente lo que estos principios fueron diseñados para desconfiar.
Fusionar con un setup existente (el caso del mundo real)
Todo lo anterior asume una instalación limpia. El caso más difícil — y el que la mayoría de ingenieros que conozco enfrenta en realidad — es fusionar estos principios en un proyecto que ya tiene un CLAUDE.md opinado con sus propias reglas.
El repo de este blog es un buen ejemplo. El proyecto ai-agents-team tiene un CLAUDE.md de generación de contenido que define las reglas de voz de Aria, configuraciones de marca, convenciones de nombrado de archivos y un stack de restricciones duras ("sin frases de relleno de IA", "mínimo 3.000 palabras", "sin frontmatter YAML en los posts"). Los principios de Karpathy son sobre comportamiento de coding, no sobre comportamiento de contenido, pero quería cargarlos igualmente para cuando el trabajo de Aria desborda hacia código real — cuando le estoy pidiendo al repo que refactorice una definición de agente, actualice un hook o añada un nuevo archivo de skill.
La estructura con la que acabé tras algunas iteraciones:
# CLAUDE.md
<Project-specific identity and purpose goes first>
## Project Overview
...
## Architecture
...
## Hard Constraints
<Domain rules — these are non-negotiable and win any conflict>
...
---
# Coding Behavior (Karpathy Guidelines)
<Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT>
<The four principles verbatim, dropped in as an appendix>
La regla horizontal antes de la sección de comportamiento de coding es deliberada. Le da a Claude una pista estructural visual de que la sección siguiente es una preocupación distinta — meta-reglas sobre cómo escribir código, frente a reglas de dominio sobre qué hace el proyecto. En mis pruebas, Claude respeta esta separación: cuando edito contenido, sigue las reglas de contenido de arriba; cuando edito código, tira de la sección de Karpathy y la aplica.
Tres reglas para fusionar sin romper tu setup existente:
-
Las reglas específicas del proyecto se quedan arriba. Tu voz de marca, tus elecciones de framework, tus convenciones de nombrado de archivos, tu lista de frases prohibidas — son reglas de dominio y tienen que ganar cualquier conflicto. Ponlas por encima de la sección de Karpathy.
-
Mantén la atribución de la fuente. Una línea:
Source: https://github.com/forrestchang/andrej-karpathy-skills — MIT. Está bajo licencia MIT, así que eres libre de meterlo, pero la atribución importa por dos razones: permite al tú del futuro saber de dónde vinieron los principios si alguna vez le parecen mal, y le señala a Claude (que sí lee estas cosas) que esta sección tiene procedencia externa. -
Nunca mezcles el texto literal de los principios con tus reglas de proyecto. Si quieres referenciar Simplicity First dentro de una regla específica del proyecto ("aplica Simplicity First aquí — sin abstracciones especulativas"), está bien. Lo que no está bien es parafrasear los principios en tu propia sección de proyecto y descartar el texto literal. La especificidad del texto original es lo que hace que los principios funcionen, y reescribirlos en tu propio idioma desafila el filo que Claude necesita para reconocerlos.
Esto no reemplaza superpowers, skills ni ninguno de los otros sistemas de comportamiento que ya tengas cargados. Los complementa. Los principios de Karpathy son estrechos — gobiernan cómo se hacen los cambios de código, no qué es el proyecto, no qué herramientas se usan, no cuáles son tus convenciones de dominio. Apilados sobre un CLAUDE.md de proyecto sólido, son una mejora neta. Apilados en lugar de uno, dejan a Claude sin contexto de dominio y odiarás el resultado.
Un ejemplo concreto de mi propio stack: el pipeline de este blog usa el skill de SEO programático de Claude que construí antes para optimización on-page automatizada. Ese skill vive por encima de la sección de Karpathy en mi CLAUDE.md porque es una regla de dominio — define qué se escribe. Los principios de Karpathy quedan debajo porque son meta-reglas — definen cómo se edita el código detrás de ese skill cuando lo refactorizo. Preocupaciones separadas, secciones separadas, sin colisiones.
Mi opinión sin pelos en la lengua — dónde gana esto y dónde no
Te ahorro la versión diplomática. Este es el veredicto directo tras una semana de uso:
Dónde gana — y gana a lo grande: los cuatro modos de fallo exactos que convirtieron el coding asistido por IA de "alucinante" a "frustrante" durante el último año. Suposiciones silenciosas. Sobreingeniería. Refactorizaciones al paso. "Creo que ya está" basado en vibes. Los cuatro son ahora medibles como menos frecuentes en mis sesiones. El incidente del martes por la mañana del null-check de 214 líneas no ha vuelto a ocurrir desde que lo instalé. Mi tamaño medio de diff para tareas pequeñas de bug-fix bajó de forma significativa — el patrón consistente entre los tres proyectos es algo así como un tercio del conteo de líneas para la misma tarea, sin pérdida de corrección.
El principio Goal-Driven Execution es el que va por debajo del radar. Suena como el aburrido de los cuatro, pero es el que más cambia tu workflow. Una vez Claude empieza a declarar criterios de verificación por adelantado, dejas de escribir prompts del tipo "añade validación" y empiezas a escribir prompts del tipo "añade validación para emails vacíos — éxito = pasa el caso de test X". Solo ese cambio me hizo medible y mejor prompter, lo cual es un efecto secundario raro de obtener por instalar el archivo markdown de otra persona.
Dónde es limitado: cuatro principios no son un sustituto del conocimiento del dominio. Claude con las guidelines de Karpathy cargadas sigue sin saber que tu base de código Laravel usa form requests en lugar de validación inline, o que tu proyecto React usa server components por todas partes, o que tu API devuelve snake_case en ese único endpoint por razones de legado. Los principios impiden a Claude empeorar las cosas — no hacen a Claude más listo sobre tu stack específico. Sigues necesitando un CLAUDE.md específico del proyecto. Sigues necesitando skills. Sigues necesitando buenos prompts.
Dónde me molesta activamente: para tareas triviales, los principios añaden fricción. Pedirle a Claude que renombre una variable ahora a veces me devuelve una confirmación de tres líneas sobre el alcance antes de que ocurra el renombrado. Las propias guidelines reconocen esto ("las guidelines sesgan hacia la precaución frente a la velocidad — útil para trabajo no trivial manteniendo el juicio para tareas simples"), pero en la práctica el modelo no siempre distingue. He desarrollado la costumbre personal de añadir "cambio trivial único, no hace falta verificación" a los prompts donde sé que el alcance son dos caracteres. Eso funciona. Pero es un apaño, no un arreglo.
Instálalo si: escribes código real para proyectos reales, trabajas con asistentes de coding de IA a diario y te ha mordido el scope creep, las suposiciones silenciosas o las refactorizaciones al paso en el último mes. La barra de valor aquí es lo suficientemente baja como para que cualquiera que envíe código a producción debería tenerlo ya instalado.
Sáltatelo si: estás usando Claude Code puramente para prototipado desechable, trabajo de spike o vibe-coding donde la velocidad importa más que la disciplina de alcance. Las guidelines se te pondrán en medio. No están diseñadas para el modo que el propio Karpathy describió como "entregarte del todo a las vibes, abrazar las exponenciales y olvidarte de que el código siquiera existe". Están diseñadas para el modo que describió después — aquel en el que eres "lento, defensivo, cuidadoso, paranoico" sobre código que de verdad te importa.
Para el pipeline de este blog y cada proyecto de cliente que estoy enviando actualmente, están dentro. Para experimentación de fin de semana, están fuera. Esa es la división honesta.
Antes y después — el null check revisitado
Déjame cerrar el bucle que abrí al principio de este post.
Volví a correr la tarea del martes por la mañana tras instalar las guidelines. Misma base de código, mismo archivo, misma línea, mismo prompt: "Arregla la comprobación de null en la línea 138 de UserService.php — $user->profile->avatar debe caer a un valor por defecto si el perfil es null."
Antes de las guidelines (representativo de lo que pasó la primera vez):
- diff de 214 líneas
- nueva constante de clase
DEFAULT_AVATAR - método renombrado de
getAvatar()aresolveAvatar()por "claridad" - cuatro arreglos de null-coalesce no relacionados en métodos que no había mencionado
- un comentario en bloque explicando por qué el enfoque del autor original había sido subóptimo
- el arreglo real de la comprobación de null, correcto, en la línea 138, rodeado de todo lo anterior
Después de las guidelines (re-ejecutado en una rama fresca desde el mismo estado de partida):
- diff de 1 línea
$user->profile?->avatar ?? asset('images/default-avatar.png')en la línea 138- un mensaje separado al final: "Noté otros cuatro sitios en este archivo donde se accede a
->profile->sin comprobación de null. Mismo patrón, métodos distintos. ¿Quieres que los aborde en un commit separado, o los dejo?"
Fix de una línea. Afloramiento explícito del problema adyacente. Ningún refactor enviado en silencio. El modelo seguía viendo los problemas adyacentes — esa es la misma inteligencia — pero las guidelines convirtieron la respuesta de "déjame manejarlo todo" a "déjame señalarlo y que tú decidas".
Esa es toda la propuesta de valor en un único antes-y-después. El modelo no se vuelve más tonto. Se vuelve disciplinado.
Hay una razón por la que el repo cruzó las 71k estrellas en menos de un mes. Cada ingeniero en activo tiene su propia versión de esa historia del martes por la mañana, y cada uno de nosotros ha querido una forma de pararlo sin escribir system prompts de 50 líneas intentando explicar, con nuestras palabras, qué significa "no refactorices al paso". Los principios de Karpathy lo hacen en cuatro secciones nombradas, con un texto lo bastante afilado como para que Claude los siga de verdad, por el precio de un solo comando curl. Ese es un trato que aceptaré cada vez.
Ahora la única pregunta que vale la pena hacerse es la que deberías hacerte mientras cierras esta pestaña: ¿cuándo fue la última vez que tu asistente de IA hizo un cambio tres veces más grande de lo que pediste? Si la respuesta es "esta semana", ya sabes qué hacer a continuación.
Preguntas frecuentes
¿Qué es el plugin de Skills de CLAUDE.md de Karpathy?
El plugin de Skills de CLAUDE.md de Karpathy es un único archivo CLAUDE.md (más un manifiesto de plugin, un directorio de skills y una carpeta de reglas para Cursor) que carga cuatro principios de comportamiento de coding en Claude Code, derivados de las observaciones públicas de Andrej Karpathy sobre las trampas del coding con LLM. Está bajo licencia MIT, se publica en github.com/forrestchang/andrej-karpathy-skills y alcanzó 71.5k estrellas solo por el boca a boca.
¿Cuáles son los cuatro principios de Karpathy para Claude Code?
Los cuatro principios son Think Before Coding (aflorar suposiciones, preguntar cuando haya incertidumbre), Simplicity First (el código mínimo que resuelve el problema, sin features especulativas), Surgical Changes (tocar solo lo que debas, sin refactorizaciones al paso) y Goal-Driven Execution (definir criterios de éxito verificables, iterar hasta verificar). Mira el desglose literal de arriba para la lista completa de bullets.
¿Cómo instalo el CLAUDE.md de Karpathy en un proyecto existente?
Ejecuta curl -o .karpathy-skills-temp.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md, luego anéxalo a tu CLAUDE.md existente como una nueva sección "Coding Behavior" al final. Nunca sobrescribas un CLAUDE.md existente — las reglas específicas del proyecto tienen que quedar por encima de la sección de Karpathy para ganar cualquier conflicto. El flujo completo de fusión está documentado arriba.
¿Esto reemplaza los skills o superpowers de Claude Code?
No. Los principios de Karpathy son meta-reglas sobre cómo se hacen los cambios de código — no conocen tu stack, tus convenciones ni tu dominio. Apílalos encima de tu CLAUDE.md de proyecto, tus skills y otros sistemas de comportamiento existentes. Complementan, no reemplazan. Si instalas esto como tu única configuración, Claude será disciplinado pero ciego al dominio.
¿Cómo verifico que los principios de Karpathy están realmente cargados?
Corre una comprobación de tres pasos: (1) pídele a Claude que liste los principios de comportamiento de coding en su contexto y confirma que aparecen los cuatro nombres de Karpathy, (2) dale una pequeña tarea de bug-fix y comprueba que el diff se mantiene quirúrgico, (3) dale una trampa de scope-creep ("arregla X, ya que estás ahí haz también Y") y confirma que separa las tareas con criterios de verificación en lugar de colapsarlas. Si algún paso falla, la instalación no cuajó.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar workflows o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (builds a medida e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones enterprise): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
