El aviso de Andrej Karpathy que sacude a los programadores

Andrej Karpathy, antiguo responsable de inteligencia artificial en Tesla y cofundador de OpenAI, ha reconocido que el ritmo de los avances en IA puede hacer que incluso un programador experimentado sienta que se está quedando atrás. Su advertencia apunta a un cambio concreto: los modelos ya no se limitan a sugerir una línea de código, sino que pueden intervenir en tareas amplias de desarrollo, y eso desplaza parte del trabajo hacia definir objetivos, aportar contexto y comprobar resultados.

El mensaje no equivale a anunciar la desaparición de los programadores. Señala que está cambiando el reparto de tareas dentro del oficio: la IA puede producir código y ejecutar procesos, pero sigue haciendo falta criterio humano para decidir qué debe construirse, detectar errores y asumir la responsabilidad del resultado. La inquietud de Karpathy importa porque procede de alguien que ha trabajado tanto en modelos de IA como en sistemas de conducción automatizada, dos terrenos donde la calidad no se mide solo por generar una respuesta convincente.

Por qué pesa la advertencia de Karpathy

Karpathy conoce de primera mano la evolución de la IA desde varios frentes. Formó parte del equipo fundador de OpenAI y dirigió el área de inteligencia artificial de Tesla, donde trabajó con equipos vinculados a Autopilot y a la conducción autónoma. También se ha dedicado a explicar conceptos técnicos a un público amplio. Su trayectoria no convierte cada pronóstico suyo en una certeza, pero ayuda a entender por qué su reconocimiento de sentirse rezagado llamó la atención: no habla desde fuera del sector ni desde una observación superficial.

Su diagnóstico se refiere, sobre todo, a la velocidad con que mejoran las herramientas de programación. Durante años, la automatización del código se asociaba a completar instrucciones, sugerir funciones o señalar errores. Ahora ciertos sistemas pueden recibir una tarea, examinar archivos relacionados, proponer modificaciones y ejecutar pruebas. Esa ampliación del alcance cambia la experiencia cotidiana del desarrollador, que deja de trabajar únicamente frente a un editor y pasa a coordinar un proceso en el que el modelo participa de principio a fin.

El aviso tampoco significa que Karpathy considere inútil el conocimiento técnico tradicional. Al contrario, comprender cómo se organiza un programa y por qué una solución puede fallar ayuda a dar instrucciones precisas y a juzgar lo que devuelve un modelo. La sensación de quedarse atrás describe la presión de aprender un flujo de trabajo que evoluciona con rapidez; no demuestra que los fundamentos de la programación hayan perdido valor. La novedad está en cómo se aplican esos fundamentos, no en que hayan dejado de importar.

Del autocompletado a coordinar agentes

Un asistente de código suele responder a una petición concreta o completar una tarea dentro de un fragmento limitado. Un agente puede tener más iniciativa: inspeccionar partes de un proyecto, llamar a herramientas, proponer cambios y ejecutar comprobaciones, si se le han concedido esos permisos. La diferencia práctica es importante. En el primer caso, el programador recibe una sugerencia; en el segundo, puede delegar una secuencia de acciones y revisar después lo que se ha hecho. El cambio desplaza el centro del trabajo hacia la supervisión y la coordinación.

Eso no convierte automáticamente una instrucción general en una buena solución. Para que un sistema trabaje con utilidad necesita saber qué se quiere conseguir, qué elementos del proyecto puede modificar y qué restricciones debe respetar. Una petición imprecisa puede generar una respuesta que parezca razonable, pero que ignore una decisión previa o altere una parte del programa que debía permanecer intacta. Es parecido a encargar una reparación sin explicar qué pieza no se debe tocar: la velocidad no compensa un objetivo mal definido.

Por eso gana importancia el contexto. El programador tiene que señalar la función de cada componente, las condiciones que el cambio debe cumplir y los casos que podrían romperse. También debe evaluar si conviene dejar que un agente modifique archivos o ejecute herramientas, en lugar de limitarse a pedir una explicación. No hay una única forma de hacerlo ni un flujo universal que sirva para todos los proyectos. Lo que se consolida es una nueva capa de decisiones alrededor del código: qué delegar, con qué límites y cómo comprobarlo.

El código generado todavía necesita pruebas

Que un modelo produzca una solución completa no demuestra que esa solución funcione en todas las circunstancias. Puede resolver el ejemplo más evidente y pasar por alto una condición poco frecuente, una dependencia o una expectativa que no estaba bien descrita. El código también puede ser legible y, aun así, introducir un fallo. Por eso el criterio decisivo no es cuánto texto genera la IA, sino si el cambio supera pruebas que representen los usos reales del programa.

La revisión humana también cambia de foco. En vez de corregir cada línea como si se hubiera escrito a mano, puede resultar más útil comprobar si la modificación respeta el diseño del sistema, si altera el comportamiento esperado y si contempla situaciones límite. Las pruebas automáticas ayudan a detectar regresiones, pero no responden por sí solas a todas las preguntas: un programa puede superar una batería de tests y seguir resolviendo mal la necesidad para la que se creó. La validación técnica y la revisión del propósito son tareas distintas.

Hay además un asunto menos visible: el acceso. Si un agente puede consultar documentación, modificar archivos o ejecutar herramientas, el equipo debe decidir qué permisos necesita y cuáles no. Cuanta más capacidad de acción se le concede, más importante es delimitar su alcance y mantener una revisión adecuada. Esto no exige tratar cada uso como una amenaza, pero sí evitar la idea de que una salida fluida es una garantía. Delegar trabajo no traslada la responsabilidad de decidir si el resultado es seguro y correcto.

¿La IA va a sustituir a quienes programan?

La advertencia de Karpathy no permite concluir que los programadores vayan a desaparecer. Las herramientas pueden automatizar partes de una tarea, pero el desarrollo de software incluye comprender necesidades, negociar prioridades, decidir cómo encajan las piezas y responder cuando algo falla. Un modelo puede proponer una implementación; no siempre sabe qué coste tiene mantenerla dentro de un producto concreto ni qué compromiso debe prevalecer cuando dos requisitos chocan. Esas decisiones dependen del contexto del equipo y del sistema.

Sí puede cambiar la cantidad y la clase de trabajo que se espera de cada persona. Si una herramienta resuelve con rapidez tareas repetitivas o prepara una primera versión, el equipo puede dedicar más tiempo a revisar, integrar y concretar el producto. También puede aumentar la presión para entregar más en el mismo plazo. Pero el material de referencia no permite establecer cuántos empleos desaparecerán, qué profesiones se verán afectadas primero ni cuánto mejorará la productividad de una empresa determinada. Las predicciones generales no sustituyen a los resultados medidos en cada organización.

La desigualdad de experiencia tampoco desaparece por usar el mismo modelo. Una persona con conocimientos sólidos puede detectar antes una solución frágil o una suposición equivocada. Quien empieza puede avanzar más rápido en algunas tareas, pero también tiene menos recursos para reconocer errores difíciles de ver. Eso no convierte la IA en una herramienta reservada a expertos: significa que la revisión mejora cuando quien la hace entiende el problema. La capacidad de producir código y la capacidad de juzgarlo no son intercambiables.

Qué habilidades ganan valor en el nuevo flujo

La primera habilidad es explicar bien el problema. Una instrucción útil no consiste necesariamente en escribir un texto largo, sino en definir el resultado esperado, las limitaciones relevantes y las condiciones que permitirían comprobarlo. Esa claridad ya era importante al trabajar con otros programadores; ahora también determina cuánto puede aportar un modelo. Describir ejemplos y excepciones reduce el espacio para interpretaciones equivocadas, aunque no las elimine. Especificar con precisión se convierte en parte del trabajo técnico.

También cuenta conocer la estructura del proyecto y sus dependencias. Si el agente propone cambiar una interfaz, una base de datos o una función compartida, alguien debe reconocer qué otras partes pueden verse afectadas. Los conceptos habituales de programación —diseño, pruebas, seguridad y mantenimiento— siguen sirviendo para hacer esa evaluación. En algunos casos, la herramienta acelera el primer borrador; en otros, ahorra tiempo al explorar alternativas. El beneficio depende de que el equipo pueda detectar cuándo una propuesta simplifica demasiado el problema.

Otra capacidad central es saber verificar. Eso puede implicar ejecutar pruebas existentes, crear comprobaciones para un caso nuevo o pedir una explicación de las decisiones tomadas antes de integrar un cambio. No basta con confiar en una respuesta porque suene técnica o incluya mucho código. El desarrollador necesita separar lo que el sistema afirma de lo que realmente ha demostrado. En ese sentido, la IA puede hacer más valiosa la experiencia: cuanto más código se genera con rapidez, más importa distinguir lo correcto de lo solo plausible.

De Tesla y OpenAI a una nueva etapa en Anthropic

La trayectoria de Karpathy conecta ámbitos que a menudo se comentan por separado. En Tesla estuvo vinculado a sistemas de visión por ordenador y conducción asistida; en OpenAI participó en el desarrollo de inteligencia artificial de propósito más amplio. Después de dejar Tesla en 2022, volvió a OpenAI y se marchó en 2024 para impulsar Eureka Labs, un proyecto relacionado con la educación y la IA. Ese recorrido ayuda a explicar por qué sus observaciones sobre programación se leen tanto como una reflexión sobre herramientas como sobre la adaptación de quienes trabajan con ellas.

El 19 de mayo de 2026 anunció su incorporación a Anthropic, la compañía que desarrolla Claude. La información disponible indica que se sumaría al equipo de preentrenamiento, la fase en la que un modelo adquiere capacidades generales antes de ajustarse para usos más concretos. También se planteó que Claude pudiera servir para acelerar la investigación sobre el propio preentrenamiento. Es un ejemplo de una idea que atraviesa la industria: usar modelos para ayudar a desarrollar modelos más capaces, aunque eso no elimine la necesidad de evaluar cuidadosamente qué mejora se obtiene y a qué coste.

Su nuevo puesto aporta contexto a la advertencia, pero no la convierte en una instrucción para que todos los programadores adopten las mismas herramientas. Las empresas tienen distintos requisitos, y un experimento personal no equivale a un sistema desplegado en un entorno con datos sensibles o servicios críticos. La utilidad de la IA depende de la tarea, de la calidad del código existente y de las condiciones de uso. El cambio tecnológico no avanza de forma idéntica en todos los equipos, aunque la capacidad de generar y modificar software ya esté alterando el oficio.

La velocidad no reemplaza el criterio

La señal de Karpathy es menos una predicción cerrada que una descripción de la presión actual: las herramientas avanzan y los profesionales tienen que averiguar cómo incorporarlas sin confundir rapidez con calidad. Su confesión de sentirse rezagado puede leerse como una llamada a observar el cambio, pero no como prueba de que los conocimientos acumulados hayan quedado obsoletos. La programación conserva su dimensión de diseño, comprobación y responsabilidad, incluso cuando parte del código la produce una máquina.

El equilibrio dependerá de cómo se use cada sistema. Cuando la tarea está bien delimitada y el resultado puede verificarse, la generación asistida puede ahorrar pasos. Cuando el objetivo es ambiguo, las consecuencias de un error son importantes o falta una forma fiable de comprobar el trabajo, delegar más puede añadir riesgo en vez de reducirlo. Esa diferencia impide tratar la IA como una solución universal y obliga a mirar más allá de las demostraciones llamativas. El criterio para medir su valor está en el resultado y sus garantías, no en la impresión de que todo ocurre más deprisa.

El programador que emerja de esta transición no será simplemente quien escriba más instrucciones a un modelo. Tendrá que entender el sistema, saber formular un problema y comprobar que la solución se sostiene cuando sale del ejemplo ideal. La advertencia de Karpathy apunta precisamente a esa combinación: adaptarse sin abandonar los fundamentos que permiten juzgar lo que la tecnología hace. La herramienta puede ampliar la capacidad de construir software; decidir qué merece construirse seguirá siendo una tarea humana.