Andrej Karpathy: hay dos tipos de programadores: los que programan con IA y los que se quedan atrás

Andrej Karpathy sabe de lo que habla. Exdirector de IA de Tesla, investigador pionero de OpenAI, creador del legendario curso de visión por computadora de Stanford: lleva más de una década escribiendo código y desplegando sistemas de IA en producción. Cuando dice que su flujo de trabajo de desarrollo acaba de experimentar la mayor transformación en 20 años, merece la pena prestar atención.

Su argumento central: herramientas como Deep Code no son un simple autocompletado glamuroso. Son un multiplicador de capacidad. En el mismo tiempo que solías invertir, puedes producir diez veces más. Y lo que es más importante, puedes abordar proyectos que antes te parecían totalmente inalcanzables. La IA sigue equivocándose: sobre-diseña, hace suposiciones incorrectas y no se opone cuando debería hacerlo; pero la ganancia neta es innegable. Cuanto antes te adaptes, mayor será tu ventaja.

Durante las últimas semanas he estado escribiendo mucho código con Claude Code. Esto es lo que he aprendido.

Flujo de trabajo de codificación

La última oleada de mejoras en la codificación con LLM dio la vuelta a mi flujo de trabajo. En noviembre, aproximadamente el 80% era escritura manual con autocompletado del IDE y el 20% era agente. Para diciembre se había invertido: 80% código escrito por el agente, 20% yo limpiando.

Ahora sobre todo me dedico a hablar el código a la existencia. Describo lo que quiero en inglés corriente y lo veo materializarse. Esto hiere un poco el ego de programador, siendo sincero. Pero la capacidad de operar a lo largo de todo un repositorio a la vez —refactorizando, creando esqueletos, cableando piezas— es demasiado buena para dejarla pasar. Especialmente una vez que le pillas el ritmo: ajustas la configuración, te haces una idea de qué acierta y en qué se estrella.

Este es el cambio más profundo que he experimentado en mi flujo de trabajo de desarrollo en aproximadamente 20 años escribiendo código. Y sucedió en cuestión de semanas. Supongo que una parte significativa de ingenieros (dos dígitos en porcentaje) ya están pasando por lo mismo. ¿El público general? Quizá un porcentaje de un solo dígito tiene idea de que esto está ocurriendo.

IDEs / Enjambres de agentes / La inevitabilidad de los errores

Dos narrativas están circulando: "los IDE están muertos" y "enjambres de agentes autónomos se encargarán de todo." Creo que ambas están exageradas en este momento.

Los modelos siguen cometiendo errores. Si de verdad te importa el proyecto, vigila. Tengo un IDE completo abierto en una ventana lateral y lo observo con lupa.

Los errores ahora son diferentes. No son errores de sintaxis. Son más insidiosos: errores conceptuales, del tipo que cometería un desarrollador júnior acelerado. El modelo rellena silenciosamente suposiciones por ti, se equivoca en ellas, nunca las doble-comprueba y construye sobre esa premisa defectuosa hasta el final.

Tampoco gestiona bien su propia incertidumbre. No se detiene y pregunta "oye, ¿quieres A o B aquí?" No señala incoherencias. Rara vez disiente. Tiene demasiadas ganas de complacer. Hacerle primero un plan y luego ejecutar según ese plan ayuda muchísimo. Sinceramente creo que hay una necesidad real de un modo de planificación ligero e integrado.

También le encanta el sobre-diseño. Capas de abstracción por todas partes. Código que se siente inflado. Y casi nunca limpia el código muerto que genera.

Lo he visto escupir una implementación mil líneas desmesurada —lenta, frágil, llena de rodeos innecesarios—. Entonces pregunto: "¿Podemos hacerlo de una forma más sencilla?" e inmediatamente responde "¡Ah, claro!" y condensa todo en cien líneas.

A veces elimina o reescribe comentarios y código que no tenían nada que ver con la tarea, simplemente porque no los comprendía o no le gustaban. He llegado a poner notas en mi CLAUDE.md diciéndole que no lo haga y aun así sigue ocurriendo. Pero a pesar de todo eso, la mejora neta es enorme. De verdad no puedo imaginar volver atrás.

Cada uno encuentra su propio flujo. El mío: un par de sesiones de Claude Code en Ghostty a la izquierda, el IDE a la derecha para leer código y hacer ediciones quirúrgicas.

Tenacidad

Ver a un agente machacar un problema es, siendo sincero, fascinante. No se cansa. No se desanima. Un humano habría dicho "da igual, mañana lo intento de nuevo" una hora antes. Simplemente... sigue adelante.

A veces lo ves luchar lo que parece una eternidad. Entonces, a los 30 minutos, finalmente lo resuelve. En ese momento tienes esa sensación real de "vaya, esto tiene vibraciones de AGI."

Te das cuenta: la resistencia mental y física es un cuello de botella fundamental para sacar adelante el trabajo. Los LLM acaban de volar ese techo.

Aceleraciones

Es difícil poner un número a cuánto más rápido te hacen los LLM. Definitivamente soy más rápido en las cosas que ya hacía. Pero el cambio mayor es que ahora hago cosas que antes no habría intentado en absoluto.

Dos razones:

1. Montones de tareas pequeñas que antes "no merecían la pena" ahora son trivialmente fáciles.
2. Repositorios que habría evitado —porque me faltaba el conocimiento o la habilidad— de repente se me antojan abordables.

Así que sí, es aceleración. Pero es algo más que eso: es expansión. El abanico de cosas que soy capaz de hacer ha crecido.

Apalancamiento

Una de las cosas más potentes de los LLM: son realmente buenos iterando en bucle hasta alcanzar un objetivo que has definido. Muchos de esos momentos con "sabor a AGI" provienen exactamente de esto.

La clave: no microgestiones. Dile qué aspecto tiene el éxito y deja que él encuentre el camino.

Puedes hacer que escriba primero los tests y luego obligarle a pasarlos. Conectarlo a un navegador vía MCP y dejar que itere. Escribir un algoritmo sencillo y obviamente correcto y decirle "ahora optimiza rendimiento manteniendo exactamente los mismos resultados."

El salto mental es de imperativo a declarativo. En lugar de "haz A, luego B, luego C", dices "así es como debería ser el resultado." El agente itera por su cuenta unas cuantas rondas y obtienes una capa extra de apalancamiento gratis.

Diversión

No lo esperaba, pero programar se ha puesto de hecho más divertido. Todo el trabajo tedioso de rellenar huecos lo absorbe el agente. Lo que queda son las partes creativas.

También me quedo atascado mucho menos. Atascarse es horrible. Ahora casi siempre hay un camino de "colaborar con él y al menos avanzar algo", lo cual hace más fácil simplemente empezar.

Dicho esto, he conocido gente que siente lo contrario: la programación con LLM los hace menos felices.

A largo plazo, creo que esto divide a los ingenieros en dos bandos: la gente que ama el acto de escribir código y la gente que ama ver las cosas construidas.

Atrofia

Ya lo siento: mi capacidad de escribir código desde cero se está desvaneciendo lentamente. En el cerebro, "generación" (escribir código) y "discriminación" (leer y revisar código) son dos habilidades distintas. Escribir código exige memorizar muchísima sintaxis granular. Leer código se trata de comprender lógica y estructura. Así que, aunque tu músculo generador se debilite, puedes seguir revisando código con eficacia: detectar qué no cuadra, encontrar los bugs.

Slopacalipsis

Me estoy preparando: 2026 podría ser el año de la gran explosión de contenido basura.

GitHub, Substack, arXiv, YouTube, Reddit: todas las plataformas de contenido digital van a inundarse de material generado por IA. Veremos una ola de teatro de productividad con IA, demos vistosas que parecen espectaculares pero no resisten el análisis. Esparcidos por ahí habrá también ganancias de productividad reales y tangibles. Pero tendrás que buscarlas.

Preguntas

¿Cómo será el ingeniero 10x en adelante? ¿Se ampliará aún más la brecha entre los ingenieros medios y los de élite? Mi suposición: mucho más amplia.

¿Empezarán los generalistas a superar a los especialistas? Los LLM son excepcionalmente buenos rellenando detalles (el micro) pero más débiles en el pensamiento panorámico y la estrategia a largo plazo (el macro). Esa inclinación favorece a quien ve todo el tablero.

¿Cómo se sentirá programar con LLM dentro de cinco años? ¿StarCraft? ¿Factorio? ¿Interpretar una pieza musical?

¿Cuánta parte de la sociedad tiene realmente como cuello de botella el trabajo basado en conocimiento digital?

Conclusión: ¿hacia dónde nos encaminamos?

Las capacidades de los agentes con LLM —en particular Claude Code— cruzaron un umbral de coherencia general alrededor de diciembre de 2025. Eso desencadenó una transición de fase en la ingeniería de software. La forma en que se hacen las cosas cambió en un orden de magnitud, prácticamente de la noche a la mañana.

Ahora mismo da la sensación de que la inteligencia ha corrido por delante de todo lo que la rodea. La integración de herramientas no ha alcanzado ese ritmo. Los equipos necesitan nuevos flujos de trabajo y patrones de colaboración. La industria aún está digiriendo lo que acaba de ocurrir.

2026 va a ser intenso. Todos están afanándose por absorber e interiorizar esta nueva capacidad. La ventana está abierta ahora mismo. Los que lo resuelvan antes tendrán una ventaja enorme.