//Los 4 principios de Karpathy
Los principios de Karpathy (y del sentido común) para desarrollar con IA
El desarrollo con IA presenta retos que Andrej Karpathy ha condensado en cuatro principios para guiar (o arreglar) el proceso de generación de código con LLMs.|No importa cuando leas esto, Andrej Karpathy es el hombre del momento en cuanto a desarrollo con IA. Bien sea porque acuñó el término Vibe Coding, como porque ha fichado por la madre de de todas las Ias (Anthropic), o por lo que nos trae a este artículo: sus cuatro principios para guiar (o arreglar) el proceso de generación de código con LLMs.
Y es que el bueno de Karpathy no es un cualquiera. Con una bio digna de película, ha sido cofundador de OpenAI, director de IA en Tesla y como decía, reciente fichaje del equipo de Claude Code. Iguálamelo. Así que no es de extrañar que cuando él habla sobre generación de código con LLMs, todos escuchemos.
El problema con los modelos generativos
Los modelos de lenguaje son geniales para generar código (el texto más formal posible). Pero ni con eso son perfectos; especialmente trabajando en grandes proyectos con tareas no triviales. Y Karpathy nos ha descubierto cuatro patrones de fallo que nos pueden entorpecer el proceso de generación de código con LLMs.
Los principales problemas que nos encontramos son:
- Suposiciones nunca verificadas
- Sobre-dimensionamiento de código y abstracciones
- Cambios colaterales no solicitados
- La ausencia de criterios de éxito
La solución con las reglas de agentes
Afortunadamente, Forrest Chang (al cesar lo que es del cesar) condensó la solución en cuatro sencillas reglas que podemos aplicar a cualquier proyecto. Estas reglas debería formar parte de cualquier fichero de instrucciones generales, tanto que uses un CLAUDE.md particular como un más recomendableAGENTS.md genérico.
1. Piensa antes de trabajar
Originalmente dedicado al trabajo de programación, pero la regla se puede aplicar a cualquier tarea. El objetivo es prevenir suposiciones erróneas que se entremezclan en la solución y desvían el tiro cuanto más lejos llegan.
Para ello, debemos obligar a los agentes a clarificar lo que sea incierto. En lugar de permitirles inventar, deben preguntar hasta completar el contexto de la tarea.
2. Simplicidad ante todo
Esto podría ser una nueva versión del viejo Keep it Simple; pero más necesario que nunca. Los modelos están entrenados con una gran variedad de código, en muchos casos de productos refactorizados tras años de evolución. Además han leído mil libros sobre arquitectura de software, patrones de diseño y abstracciones. Así que, lo normal es que elijan soluciones innecesariamente complejas antes de tiempo.
Esta regla debe forzarles a elegir la implementación mínima viable. Evitando la sobre-ingeniería y el por si acaso. Fomentando el también tradicional mantra You Aren’t Gonna Need It (YAGNI).
3. Haz cambios quirúrgicos
Muy relacionado con lo anterior, pero más centrado en la codificación propiamente dicha. Sabemos que los modelos completan textos que tengan viabilidad probabilística. Pero en muchos casos es más de lo que se pediría. Desde comentarios superfluos a refactorizaciones cuando no toca. Y el problema no es suyo; es tuyo. Porque un diff gigante es muy probable que sea aceptado sin la oportuna revisión.
La solución es pedirles que no cambien nada que no sea imprescindible. Ya habrá tiempo (y tareas específicas) para limpiar, abstraer y mejorar el código. Empezar siempre reduciendo el radio de alcance de los daños.
4. Trabaja siguiendo un objetivo
Los agentes modernos son capaces de iterar y realizar tareas largas. Si no tienen claro el objetivo final, pueden perderse o por el contrario, dejar cosas a medias. Pero, no es solo culpa suya.
Nosotros debemos superar la etapa de la supervisión detallada y el micro-management y darles criterios de éxito. De esta forma el agente sabrá cuándo parar y cuándo continuar iterando en busca de la solución.
Conclusión
Estas reglas puede escribirse en el fichero de instrucciones generales de agentes, o incluirse en comandos específicos de codificación y skills de escritura de código.
Tampoco descartaría que de aquí a poco vengan incrustadas de fábrica en las herramientas de desarrollo. (Sobre todo, y antes que nadie, el propio Andrej lo hará en Claude Code). Pero lo principal es que nos ilustran sobre cómo trabajan los modelos y cómo podemos mejorar nuestro proceso de desarrollo.
Por mi parte, las he incluido en la plantilla de instrucciones generales de AIDDbot, de forma que todos los proyectos inicializados con sus skills ya las tienen en cuenta.
Aquí tienes un extracto por si quieres un copy/paste rápido:
## Principles
- **Think before working** : Reason about the problem and ask the user for clarification if needed.
- **Simplicity first** : Avoid complex, clever, or over-engineered solutions (KISS/YAGNI).
- **Surgical changes** : Make the minimum changes necessary to solve the problem.
- **Goal-driven execution** : Keep working until the solution meets the validation criteria.
El resto está entreverado en el catálogo de skills de AIDDbot.