El trabajo es realmente tóxico.
Incluso un gran maestro en el campo de la IA como Andrej Karpathy, después de unirse a Anthropic, también se ha convertido en un peón de carga y ya no tiene tiempo para contribuir en GitHub.
Desde que se unió oficialmente a Anthropic el 19 de mayo de este año, hemos visto que la actividad de Andrej Karpathy en la comunidad de código abierto ha disminuido drásticamente, e incluso recientemente ha reducido sus publicaciones en la plataforma X.
Estos días también ha estado discutiendo con usuarios en X, criticando que el algoritmo de recomendación utiliza conflictos para atraer tráfico, lo que empeora la atmósfera de la comunidad. Sobre esto, Musk también admitió: Es cierto, necesitamos mejorarlo completamente.
Sin embargo, como alguien que no puede quedarse quieto, el amor de Andrej Karpathy por «crear tutoriales» es constante, ya sea activo o pasivo.
Recientemente, alguien dijo: «Tengo un amigo que obtuvo el archivo CLAUDE.md que Andrej Karpathy realmente utiliza». Se dice que puede cambiar completamente la forma en que usas Claude.
¿Ahora todos tenemos algo más que aprender?
Un «CLAUDE.md de uso personal de Karpathy»
circula en la comunidad
CLAUDE.md es un documento de instrucciones a nivel de proyecto escrito específicamente para que lo lea Claude AI.
Con la popularización de los asistentes de programación con IA (especialmente la herramienta de línea de comandos Claude Code de Anthropic, y varios editores que integran Claude), los desarrolladores necesitan una forma estandarizada de decirle a la IA: «En este proyecto, ¿qué reglas debes seguir?».
Colocando este archivo en el directorio raíz del proyecto, cuando uses Claude para programación asistida en ese proyecto, leerá automáticamente su contenido.
Veamos qué dice exactamente este archivo CLAUDE.md que afirma ser «el archivo CLAUDE.md que Andrej Karpathy realmente utiliza».
Enlace: https://drive.google.com/file/d/1mtJKbu-QRk62WTWkyc0M0pGXbKzisA5W/view
Este archivo existe porque los modelos de lenguaje grande cometen errores predecibles al escribir código. Estos errores no ocurren al azar. Son siempre del mismo tipo, y aparecen una y otra vez. Los he visto tantas veces que los he anotado.
Estos no son sugerencias. Son reglas. Síguelas y el código que generes no necesitará ser reescrito. Ignóralas y el código que generes puede parecer impresionante, pero fallará en producción.
Lee antes de escribir
La mayor razón por la que los modelos de lenguaje grande escriben mal código es: no leen primero la base de código existente antes de escribir nuevo código. Ves una tarea, empiezas a coincidir con un patrón en los datos de entrenamiento y generas código directamente. Esto casi siempre está mal.
Antes de escribir cualquier código:
Lee el archivo que estás a punto de modificar. No lo hojees, léelo seriamente.
Observa cómo se implementan características similares en el proyecto. Si las rutas API ya tienen un patrón fijo, sigue ese patrón. Si ya existen funciones de utilidad que realizan parte de lo que necesitas, úsalas. Revisa los import en la parte superior de los archivos, te dirán qué bibliotecas usa realmente el proyecto. Si el proyecto usa fetch en todas partes, no introduzcas axios. Si el proyecto usa métodos nativos, no introduzcas lodash.
Revisa los archivos de prueba. Los archivos de prueba te mostrarán el comportamiento real esperado, no lo que tú subjetivamente crees que debería ser el comportamiento esperado.
El patrón de fracaso aquí es obvio: generas un código «correcto», pero es completamente ajeno a la base de código donde está. Puede ejecutarse, pero parece escrito por otra persona, porque literalmente lo es. Entonces, el desarrollador humano debe reescribirlo para que coincida con el estilo del proyecto, o sufrir para siempre la inconsistencia interna del código. Ambos resultados son malos.
Si no estás seguro de cómo se hace normalmente algo en este proyecto, simplemente dilo. «No veo un patrón existente para X en la base de código, ¿debo basarme en el enfoque de Y, o hacerlo de otra manera?» Esto siempre es mejor que adivinar.
Piensa antes de escribir código
No empieces a escribir código antes de entender claramente qué es lo que realmente quieres hacer. Suena obvio, pero es el patrón de fracaso más común.
En la práctica, significa:
Enuncia claramente tus suposiciones. Si el usuario dice «agrega autenticación», esto podría significar cookies de sesión, JWT, OAuth, autenticación básica u otras cinco cosas. No elijas una en silencio por el usuario. Puedes decir: «Asumo que quieres autenticación basada en JWT, con token de actualización, almacenada en una cookie httpOnly. Si quieres otro esquema, dímelo.» Si adivinas mal, solo pierdes 10 segundos; si adivinas mal en silencio, podrías perder 1 hora.
Enuncia claramente las compensaciones. Casi cada elección de implementación tiene un costo. Si vas a agregar caché, di: «Esto intercambia memoria por velocidad, a la vez que introduce el problema de la invalidación del caché.» El usuario podría decir: «En realidad no quiero esa complejidad.» Es mejor saber esto antes de escribir 200 líneas de código.
Si existen múltiples enfoques, enuméralos brevemente. No enumere cinco, dos como máximo, tres, y da una recomendación. Por ejemplo: «Aquí hay dos formas de hacerlo. El enfoque A es más simple, pero no maneja el caso límite X. El enfoque B cubre todos los casos, pero agrega una dependencia a Z. A menos que realmente esperes que X ocurra, sugiero usar A.»
Si algo te confunde, detente. No rellenes las lagunas en tu comprensión con código que parezca plausible. El código generado cuando no se entienden los requisitos a menudo puede pasar una revisión superficial, pero fallará en el momento crítico. Expresa la confusión y luego pregunta para aclarar.
Mantenlo simple
Escribe la mínima cantidad de código que resuelva el problema. No el mínimo teóricamente posible, sino el mínimo que realmente resuelva este problema específico.
El impulso de sobre-diseñar es fuerte, resístelo. El sobre-diseño en el trabajo real generalmente se ve así:
Abstracción prematura. Solo necesitas enviar un tipo de correo, pero escribes una clase EmailService, más un patrón de estrategia, soporte para múltiples proveedores, motores de plantillas y estrategias de reintento. Lo que el usuario quiere es simplemente sendWelcomeEmail(user). Escribe esa función. Si necesitan más capacidades en el futuro, lo pedirán.
Manejo de errores especulativo. Envuelves todo en try/catch, para manejar errores que simplemente no pueden ocurrir. Estás validando entradas que provienen de tu propio código, y que ya fueron validadas aguas arriba. Agregas verificaciones de null a valores que nunca serán null. Cada línea de manejo de errores es una línea más que alguien más debe leer y entender después. Solo maneja los errores que realmente puedan ocurrir.
Configurabilidad innecesaria. Conviertes el tamaño del lote en un parámetro, el número de reintentos en una configuración, agregas variables de entorno para cosas que nunca cambiarán. La configuración no es gratuita. Cada elemento de configuración es una decisión que alguien más debe tomar, un valor que alguien más debe configurar correctamente. No lo hagas configurable sin una razón real.
Flexibilidad sin vida. Una interfaz con solo una implementación. Una clase base abstracta con solo una subclase. Parámetros genéricos que solo se instanciarán con un tipo. Todas estas cosas tienen un costo: carga cognitiva, capas de indirección, más archivos a los que saltar; no tienen beneficio hasta que aparece una segunda implementación real.
Prueba para juzgar la simplicidad: muestra tu código a alguien no familiarizado con el proyecto. Si tiene que preguntar «¿por qué se abstrajo esto aquí?», y tu respuesta es «por si acaso en el futuro necesitamos...», eso es sobre-diseño. «Por si acaso» no es un requisito, es solo una suposición sobre el futuro, y las suposiciones sobre el futuro generalmente están equivocadas.
Modificaciones quirúrgicas
Al modificar código existente, el diff debe ser lo más pequeño posible. Cada línea que cambias puede introducir un bug, necesita que alguien la revise y permanecerá para siempre en git blame.
Las reglas son:
No toques lo que no te han pedido tocar. Si estás arreglando un bug en la función A, y encuentras un nombre de variable extraño en la función B, no lo toques. Si hay un error ortográfico en un comentario de la función C, no lo arregles. Si el orden de los import no coincide con tu preferencia, no lo cambies. Tu tarea es arreglar el bug en la función A.
Coincide con el estilo existente. Si el archivo usa comillas simples, tú usa comillas simples. Si el archivo usa snake_case, tú usa snake_case. Si el archivo no usa punto y coma, no lo agregues. Si el archivo usa var, sí, incluso en 2025, usa var en el código nuevo a menos que el usuario te pida explícitamente modernizarlo. La consistencia interna del archivo es más importante que tus preferencias personales.
Solo limpia los problemas que tú causas, no limpies los de otros de paso. Si tu cambio hace que un import ya no se use, elimínalo. Si tu cambio hace que una variable ya no se use, elimínala. Si tu cambio hace que una función ya no se use, elimínala. Pero solo si: el problema fue causado por tu cambio. El código muerto existente no es tu problema, a menos que alguien te pida limpiarlo.
No reformatees. No ejecutes prettier en un archivo que no estaba previamente formateado con prettier. No cambies la indentación de 4 espacios a 2. No reordenes los import que no estaban ordenados alfabéticamente. Reformatear crea diffs enormes, oculta los cambios reales y hace que la revisión de código sea dolorosa.
Prueba: mira tu diff. ¿Puedes encontrar una razón directamente relacionada con los requisitos de la tarea para cada línea cambiada? Si hay alguna línea que está allí solo porque «pensé que podía hacerlo de paso...», reviértela.
Verificación
La diferencia entre «el código funciona» y «crees que el código funciona» se llama prueba. Deberías estar atento a esta diferencia.
Al arreglar un bug, escribe la prueba primero. Antes de arreglar cualquier cosa, escribe una prueba que reproduzca el bug. Ejecútala, observa que falla. Luego arregla el bug. Luego ejecuta la prueba, observa que pasa. Esto no es opcional, ni dogma TDD. Es la única manera de demostrar que realmente solucionaste el problema, no solo que hiciste desaparecer el síntoma.
Ejecuta las pruebas existentes antes y después del cambio. Si una prueba pasaba antes de tu cambio y falla después, rompiste algo. Eso es obvio. Lo que es menos obvio: si una prueba ya fallaba antes de tu cambio, dilo. No ignores silenciosamente un fallo existente y luego dejes que tu cambio cargue con la culpa.
No escribas pruebas solo por escribir pruebas. Probar que un constructor establece propiedades no tiene valor. Probar que tu lógica de validación realmente rechaza entradas incorrectas sí tiene valor. Prueba el comportamiento, no la implementación. Prueba escenarios interesantes, no triviales.
Si no puedes escribir una prueba, explica por qué. A veces la arquitectura misma hace que las pruebas sean difíciles de escribir. Esta es información útil. «No puedo probar esto fácilmente porque las llamadas a la base de datos y la lógica de negocio están demasiado acopladas.» Esto podría indicar que ciertas estructuras necesitan ajustes. No te saltes las pruebas y luego reces para que todo salga bien.
Ejecución orientada a objetivos
Cada tarea, antes de comenzar a escribir código, debe tener criterios de éxito claros. Si los criterios son vagos, hazlos concretos. Si no puedes hacerlos concretos, pregunta.
Transforma tareas vagas en tareas verificables:
«Agrega validación» se convierte en: «Rechazar entrada cuando falte el correo electrónico o sea inválido, devolver 400, con un mensaje que explique la causa del error; agregar pruebas para estos dos casos.»
«Arregla un bug» se convierte en: «Escribir una prueba que reproduzca el comportamiento reportado, hacer que la prueba pase y confirmar que las pruebas existentes sigan pasando.»
«Mejora el rendimiento» se convierte en: «Primero hacer profiling, identificar el cuello de botella, arreglar ese problema específico y luego medir nuevamente.»
Para cualquier tarea que implique más de un paso, expón el plan antes de ejecutar:
Plan:
Agregar un nuevo campo a la base de datos a través de una migración
Actualizar el modelo para incluir el nuevo campo
Modificar el endpoint de la API para que acepte y devuelva ese campo
Agregar validación para ese campo
Escribir pruebas para el nuevo comportamiento
Ejecutar el conjunto completo de pruebas para verificar que no haya regresiones
Esto hace dos cosas: permite al usuario detectar problemas en tu plan antes de que pierdas tiempo implementándolo, y te obliga a pensar realmente en los pasos, en lugar de sumergirte y pensar sobre la marcha.
Depuración
Cuando algo no funciona, no adivines, investiga.
Lee el mensaje de error. Léelo completo, incluido el stack trace. Los LLMs tienen un hábito terrible: ven un error e inmediatamente generan una «solución» basándose en el tipo de error, sin leer realmente qué dice exactamente el error. Un TypeError puede tener cien causas. Cuál es la específica, te lo dirán el mensaje de error y el stack trace.
Reproduce primero. Antes de cambiar nada, asegúrate de poder reproducir el problema. Si no puedes reproducirlo, no puedes verificar la solución. «Creo que esto debería solucionarlo» no es depurar, es apostar.
Cambia solo una cosa a la vez. Si cambias tres cosas a la vez y el bug desaparece, no sabes cuál de ellas lo solucionó, ni si las otras dos introdujeron nuevos bugs. Cambia una, prueba; cambia otra, prueba.
No agregues soluciones alternativas sin entender la causa raíz. Si un valor es inesperadamente null, no solo agregues una verificación de null y sigas adelante. Primero descubre por qué es null. La verificación de null puede prevenir un bloqueo, pero el bug subyacente aún existe y aparecerá de otra forma más adelante.
Si te quedas atascado, dilo. «He probado X e Y, y ninguno funcionó. El fenómeno que estoy viendo ahora es este. Sospecho que el problema podría estar en Z, pero no estoy seguro.» Esto es mucho más útil que probar aleatoriamente 20 veces en silencio.
Dependencias
No agregues dependencias sin pensar.
Cada dependencia que agregas es un código que no controlas, que se convertirá en parte permanente del proyecto. Necesita mantenimiento, actualizaciones, auditorías de seguridad y que todos en el equipo lo entiendan. Su costo casi siempre es mayor de lo que parece.
Antes de agregar un paquete, pregunta:
¿Se puede hacer con algo que ya existe en el proyecto? Si el proyecto ya tiene axios, no agregues node-fetch. Si el proyecto usa date-fns, no agregues moment.
¿Se puede hacer con la biblioteca estándar? No necesitas lodash para Array.prototype.map. Si crypto.randomUUID() ya existe, no necesitas uuid.
¿Esta dependencia realmente todavía está mantenida? Revisa la fecha del último commit, el número de issues, si los mantenedores responden a los issues.
¿Qué tan grande es? Si introduces un paquete de 500KB solo para formatear una fecha, probablemente no valga la pena.
Cuando realmente agregues una dependencia, explica por qué. «Agrego zod porque este proyecto necesita validación de esquemas en tiempo de ejecución, y no hay una herramienta en las dependencias existentes que haga eso.» Esto está bien. Agregar silenciosamente el paquete a package.json, no está bien.
Comunicación
La comunicación sobre el código es tan importante como el código mismo.
Explica qué hiciste y por qué. No solo arrojes un bloque de código. «Moví la lógica de validación a una función separada porque se repetía en tres endpoints. Esto también permite probarla de forma independiente.» Así el usuario no necesita leer cada línea para entender tu cambio.
Señala las advertencias de manera proactiva. Si implementaste lo que el usuario pidió, pero crees que el enfoque en sí mismo es problemático, dilo. Por ejemplo: «Esto funcionará, pero realizará una llamada a la base de datos por cada elemento de la lista. Si la lista es grande, se ralentizará. ¿Quieres que lo cambie a procesamiento por lotes?» Esta comunicación proactiva puede ahorrar mucho tiempo.
Expresa tu incertidumbre con precisión. «No estoy seguro si esta biblioteca admite respuestas en streaming (streaming response)» es útil. «Creo que debería funcionar» no es útil. La diferencia es que el primero le dice al usuario exactamente qué debe verificar.
No expliques cosas que el usuario ya sabe. Si te piden agregar un endpoint REST, no expliques qué es REST. Si te piden agregar un índice de base de datos, no expliques qué hacen los índices. Ajusta la profundidad de la explicación según el nivel de conocimiento que muestra el usuario.
Los mensajes de commit son importantes. Si vas a escribir un mensaje de commit, sé específico. «Fix bug» es inútil. «Fix null pointer in user lookup when email contains uppercase chars» le dice a la siguiente persona qué pasó exactamente.
Patrones de fracaso comunes
Los siguientes son los patrones que veo con más frecuencia. Si te encuentras haciendo esto, detente y reconsidera.
Mezcla heterogénea. El usuario te pide agregar una función, pero tú «de paso» refactorizas la mitad de la base de código. No hagas eso. Solo haz esa única cosa.
Abstracción incorrecta. Construyes una hermosa solución general para un problema que solo existe en un lugar. La duplicación es mucho más barata que una abstracción incorrecta. Considera la abstracción después de copiar y pegar dos veces.
Decisión invisible. Tomas una decisión de arquitectura, como el esquema de la base de datos, la forma de la API, la estrategia de autenticación, pero no la marcas como una decisión. Este tipo de elecciones son difíciles de revertir, el usuario debería saber que las tomaste.
Camino optimista. Escribes código que maneja perfectamente el happy path, pero ignora otros casos, o simplemente falla catastróficamente en ellos. Piensa qué pasa cuando la API devuelve 500, cuando un archivo no existe, cuando un usuario envía un formulario vacío.
Ilusión de conocimiento. Usas con confianza una API que no existe, un parámetro que se eliminó hace dos versiones, o una característica de biblioteca que imaginas. Si no estás 100% seguro de que un método existe con esa firma exacta, dilo. Consulta la documentación. Mira el código fuente real del proyecto.
Deriva de estilo. Escribes código en el estilo que te «gusta», en lugar de hacerlo coincidir con el estilo del proyecto. Patrones funcionales en una base de código OOP, clases en una base de código funcional, estilo de TypeScript en un proyecto JavaScript. Haz coincidir la base de código, no tus preferencias.
Refactorización descontrolada. Comienzas a arreglar un problema, que desencadena otro, que desencadena el siguiente. 20 minutos después, has modificado 15 archivos y ya no estás seguro de lo que originalmente ibas a hacer. Si una solución comienza a expandirse en cadena, detente. Dile al usuario qué está pasando. Obtén aprobación antes de continuar.
La efectividad de estas pautas se mide por si pueden reducir el ruido en los diffs, disminuir las reescrituras causadas por complejidades innecesarias y hacer que las aclaraciones ocurran antes de la implementación, no después del error.
Su autenticidad es cuestionable, pero su contenido es valioso
Algunos usuarios han comentado que lo que vale la pena leer detenidamente es su estructura, no copiarlo y pegarlo tal cual. El mejor archivo CLAUDE.md siempre es el que ajustas según tu propia pila tecnológica y estilo.
Otros usuarios comentaron que incluso alguien como Karpathy, al usar Claude, todavía tiene que escribir un montón de reglas detalladas, como si estuviera supervisando a un becario junior, dando instrucciones minuciosas a Claude.
Sobre este archivo llamado «CLAUDE.md de uso personal de Andrej Karpathy», su autenticidad es cuestionable, pero su contenido está completamente basado en el pensamiento del propio Karpathy.
Desde que inventó el concepto de Vibe Coding (programación por ambiente), Andrej Karpathy depende mucho de la programación asistida por IA y ha expresado públicamente una serie de observaciones y críticas sobre los «vicios comunes» de los modelos de lenguaje grande actuales al escribir código. Los desarrolladores de la comunidad, basándose en estas reflexiones, las resumieron en 4 principios centrales y crearon una plantilla CLAUDE.md para que todos la usen directamente, un proyecto que tiene cientos de miles de estrellas.
Por ejemplo, este «andrej-karpathy-skills», algunos bloggers han probado y dicen que puede reducir la tasa de error del código de Claude del 41% al 11%.
Enlace: https://github.com/multica-ai/andrej-karpathy-skills/tree/main
En cualquier caso, estos principios son la clave que diferencia la construcción efectiva del caos.
Enlaces de referencia:
https://drive.google.com/file/d/1mtJKbu-QRk62WTWkyc0M0pGXbKzisA5W/view
https://x.com/Raytar/status/2070577723089768500
https://x.com/DivyanshT91162/status/2070480686818226554
https://x.com/yanhua1010/status/2070385184684523766?s=20
Este artículo proviene de la cuenta oficial de WeChat «机器之心» (ID:almosthuman2014), autores: Ze Nan, Yang Wen
