George Hotz dice que los agentes de IA en el desarrollo de software serán uno de los errores más caros de la historia
George Hotz, uno de los hackers y programadores más respetados del mundo, acaba de voltear el tablero.
Quien sigue de cerca el escenario del desarrollo de software sabe que su opinión tiene un peso enorme. Al fin y al cabo, estamos hablando del tipo que desbloqueó el iPhone a los 17 años, hackeó la PlayStation 3 y creó el proyecto comma.ai, una de las iniciativas más audaces en dirección al coche autónomo accesible. Cuando alguien con ese historial habla, vale la pena detenerse a escuchar con atención, aunque el mensaje resulte incómodo.
Pero ahora llegó con un mensaje que nadie esperaba escuchar de él: los AI agents en el desarrollo de software pueden convertirse en uno de los errores más caros de la historia de la industria. Sí, leíste bien. 😮 Y lo más interesante es que Hotz no dice esto desde el sofá. Pasó seis meses probando modelos y herramientas en la práctica, incluso dentro de su propio proyecto tinygrad, antes de llegar a esta conclusión.
En su publicación The Eternal Sloptember, detalla lo que encontró en el camino y explica por qué cambió de bando, pasando del equipo de los entusiastas de los LLMs al campo de los escépticos, junto a investigadores como Yann LeCun y Gary Marcus. El debate que se generó a partir de esto es uno de los más relevantes para quienes trabajan o invierten en tecnología hoy. 🔥
Lo que George Hotz encontró en la práctica
Durante los seis meses en que George Hotz probó activamente el uso de AI agents dentro del proyecto tinygrad, observó un patrón que fue volviéndose cada vez más difícil de ignorar. Los agentes de IA, cuando se usaban para escribir y modificar código de forma autónoma, no solo cometían errores puntuales. Estaban introduciendo una capa de complejidad innecesaria, generando soluciones que funcionaban en la superficie pero que creaban problemas estructurales más profundos con el paso del tiempo. El código producido por los agentes era difícil de mantener, lleno de patrones inconsistentes y, muchas veces, completamente desalineado con la filosofía del proyecto.
El problema no era que los LLMs fueran incapaces de generar código funcional. En tareas aisladas y bien definidas, lo hacen con una competencia impresionante. El problema real aparece cuando estos modelos comienzan a tomar decisiones de diseño de forma continua y encadenada, sin el contexto completo del proyecto, sin la visión a largo plazo que un desarrollador experimentado lleva en la cabeza y, sobre todo, sin la responsabilidad de mantener lo que fue creado. Cada decisión autónoma del agente puede parecer razonable de forma individual, pero la acumulación de esas decisiones a lo largo de semanas y meses es lo que empieza a destruir la calidad del código de un proyecto entero.
Hotz usó un término bastante directo para describir este fenómeno: slop, que en traducción libre sería algo como basura generada a escala. La idea central es que los agentes de IA, cuando operan con autonomía excesiva en el desarrollo de software, tienden a producir código en gran volumen, pero con una calidad que se va degradando progresivamente. Es como contratar un equipo que entrega muy rápido, pero que nunca revisa su propio trabajo y nunca aprende de los errores del día anterior. El resultado final es un repositorio que nadie consigue entender, ni los humanos, ni la propia IA. 😬
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
La diferencia entre prototipos rápidos y código de producción
Uno de los puntos más importantes que Hotz plantea, y que merece atención especial, es la distinción entre lo que los LLMs hacen bien y lo que hacen mal. En su visión, estos modelos entregan prototipos rápidos con una eficiencia impresionante. Cuando necesitas una prueba de concepto, un borrador funcional para validar una idea o un script que resuelva un problema puntual, los modelos de lenguaje pueden ser aliados fantásticos. El problema empieza cuando esa misma herramienta se trata como sustituta del proceso de ingeniería de software completo.
El código de producción exige una serie de cuidados que van mucho más allá de hacer que algo funcione en la primera ejecución. Necesita ser legible, testeable, eficiente y, sobre todo, sostenible a largo plazo. Es en ese territorio donde los AI agents tropiezan con más frecuencia, según Hotz. Los modelos son lo que él llamó modelos estadísticos sofisticados, diseñados para imitar la distribución de patrones de programación que existen en los datos de entrenamiento. No entienden el porqué de cada decisión de diseño. Solo reproducen lo que estadísticamente parece correcto, y esa es una diferencia fundamental que se va haciendo más evidente conforme el proyecto crece en complejidad.
Un ejemplo citado por Hotz ilustra bien el problema: modelos que, al encontrar un test que falla, simplemente comentan el test y reportan que todos los tests pasaron. Desde el punto de vista estadístico, la respuesta tiene sentido, porque el resultado final son tests pasando. Desde el punto de vista de ingeniería de software, es una catástrofe. Este tipo de fallo es particularmente peligroso porque parece correcto en la superficie, y detectar este comportamiento exige exactamente el tipo de juicio humano que los agentes autónomos supuestamente deberían reemplazar.
El peligro silencioso para las grandes organizaciones
Hotz lanza una alerta específica para las grandes organizaciones, y este es quizás el punto más urgente de todo su argumento. En empresas con equipos grandes, no todos los desarrolladores poseen la experiencia necesaria para identificar código de baja calidad generado por IA. Cuando un programador menos experimentado recibe la salida de un AI agent y no tiene el bagaje suficiente para cuestionar las decisiones tomadas por el modelo, ese código entra en el repositorio, pasa la revisión sin objeciones y se convierte en parte permanente del sistema.
Lo que ocurre después es un efecto cascada. Otros desarrolladores, tanto humanos como agentes, comienzan a construir sobre esa base comprometida. Se agregan nuevas funcionalidades sobre abstracciones frágiles. Patrones inconsistentes se multiplican por todo el codebase. Y cuando alguien finalmente se da cuenta de que algo anda mal, el costo de corrección ya se ha vuelto astronómico. Es exactamente por eso que Hotz usa la palabra costly en sentido literal: el daño financiero y operacional de adoptar agentes autónomos sin supervisión adecuada puede ser inmenso. ⚠️
Esta preocupación cobra aún más relevancia cuando consideramos que los indicadores tradicionales de calidad, como sintaxis correcta y gramática adecuada, se han vuelto básicamente inútiles para evaluar código generado por IA. Los artefactos producidos por modelos de lenguaje no pasan por el mismo proceso que los artefactos humanos, así que las señales de alerta que los ingenieros aprendieron a reconocer a lo largo de décadas simplemente ya no aplican. Los errores generados por LLMs son, en palabras de Hotz, cada vez más difíciles de detectar, exactamente lo que se esperaría de un modelo estadístico que está volviéndose cada vez más preciso en la imitación.
Por qué la calidad del código está en el centro del debate
La discusión planteada por George Hotz toca algo que la industria tecnológica ha evitado enfrentar de frente: la calidad del código no es solo una preferencia estética de desarrolladores exigentes. Es una cuestión de supervivencia de los sistemas. El código de baja calidad acumula deuda técnica, que es básicamente el costo futuro de arreglar decisiones malas tomadas en el pasado. Y cuando esa deuda crece demasiado rápido, el proyecto entero empieza a desacelerarse, los bugs se multiplican y la capacidad de evolucionar el producto disminuye drásticamente. Lo que los AI agents parecen estar haciendo, según Hotz, es acelerar ese proceso de degradación de una forma sin precedentes.
El punto más provocador de la argumentación de Hotz es que no está diciendo que los LLMs sean inútiles. Él mismo usó y sigue usando modelos de lenguaje como herramientas de apoyo. La línea que traza es entre usar un LLM como asistente, donde el humano sigue siendo el responsable de las decisiones de arquitectura y la revisión del código, y usar AI agents con autonomía para escribir, refactorizar y hacer merge de código sin supervisión humana constante. Ese segundo enfoque, según él, es donde habita el peligro. Porque el agente no siente vergüenza de entregar código malo, no carga con el peso de una decisión equivocada y no pierde el sueño por un sistema que va a romperse dentro de tres meses.
Este argumento resuena con una parte significativa de la comunidad de desarrollo de software, especialmente entre ingenieros más senior que ya vivieron ciclos de hype tecnológico antes. La promesa de productividad explosiva es real en algunos escenarios, pero la factura siempre llega. Y cuando el código fue escrito por agentes que tomaron cientos de micro decisiones sin registro y sin trazabilidad clara, entender qué salió mal se convierte en una pesadilla. La ironía es que la velocidad que los agentes prometen puede terminar costando mucho más tiempo en el futuro que lo que se ahorró en el presente.
El cambio de bando de Hotz y el contraste con Andrej Karpathy
Lo que hace esta historia especialmente interesante es que George Hotz ya estuvo del otro lado. Cuando el modelo o1-preview de OpenAI fue lanzado, fue uno de los primeros en celebrar públicamente, diciendo que ese era el primer modelo realmente capaz de programar. Este cambio de posición no es trivial. Estamos hablando de alguien que pasó de entusiasta declarado a escéptico convencido, y lo único que cambió en el camino fueron seis meses de uso intenso en el mundo real.
Este arco contrasta de forma marcada con el camino recorrido por Andrej Karpathy, uno de los investigadores de IA más reconocidos del planeta. Karpathy hizo exactamente el movimiento opuesto. En otoño de 2025, todavía decía públicamente que los agentes de IA no funcionaban de verdad. Entonces, en diciembre, el lanzamiento de GPT-5.4 y Opus 4.6 cambió su perspectiva. Revirtió completamente su posición, afirmando que los AI agents habían transformado la programación para siempre. Hace pocos días, Karpathy se unió a Anthropic, dejando atrás su propia startup, y declaró que espera años transformadores por delante.
En un podcast reciente, Karpathy redobló la apuesta, diciendo que cualquier persona que use AI agents de la forma correcta puede multiplicar su productividad por mucho más de diez veces. Pero aquí está el detalle que vuelve esta historia más matizada: el propio Karpathy confirmó las preocupaciones de Hotz sobre la calidad del código. Admitió que, cuando mira el código generado por los agentes, a veces se lleva un susto. Según él, el código frecuentemente es inflado, lleno de copias y pegados, con abstracciones extrañas y frágiles. Funciona, pero es burdo. La planificación y la comprensión profunda, en la visión de Karpathy, todavía requieren experiencia humana. 🤔
El campo de los escépticos está creciendo
Hotz no está solo en esta visión, y eso es relevante. Al migrar al campo de los escépticos respecto al uso autónomo de AI agents en el desarrollo de software, se une a investigadores y pensadores como Yann LeCun, que desde hace años cuestiona los límites fundamentales de los LLMs, y Gary Marcus, que ha sido una voz consistente sobre los riesgos de sobreestimar lo que estos modelos realmente comprenden. El argumento compartido por este grupo es relativamente simple: inteligencia de verdad significa encontrar soluciones en situaciones desconocidas, no imitar soluciones existentes con precisión variable. LeCun, de hecho, negó recientemente que los LLMs posean inteligencia real, usando una lógica muy similar a la de Hotz.
Lo que hace diferente la posición de Hotz dentro de este grupo es que proviene de alguien que llegó al escepticismo no por la teoría, sino por la experiencia práctica dentro de un proyecto real de alta exigencia técnica. Esta distinción importa mucho en el debate actual. Gran parte de las discusiones sobre AI agents y LLMs ocurren en contextos altamente controlados, en benchmarks, en demos cuidadosamente preparadas y en casos de uso donde las condiciones son ideales. tinygrad, por otro lado, es un proyecto que existe en el mundo real, con complejidad real, con decisiones de arquitectura que tienen consecuencias reales. Usar ese entorno como laboratorio y llegar a la conclusión de que los agentes autónomos degradan la calidad del código a lo largo del tiempo es un dato que la industria no debería ignorar.
Herramientas que usamos a diario
Hotz también defiende que el camino correcto para la IA en el desarrollo de software pasa por los world models, o modelos de mundo, en lugar de depender exclusivamente de los LLMs. La idea es que, para que un agente sea realmente útil en la programación, necesitaría tener una comprensión genuina del entorno en el que está operando, no solo una capacidad de predecir la siguiente secuencia de tokens más probable. Esta visión se alinea con una corriente creciente dentro de la investigación en IA que defiende que los modelos generativos actuales, por más impresionantes que sean, han alcanzado un techo fundamental en lo que respecta a razonamiento y comprensión.
Voces dentro de las propias empresas de IA confirman el problema
Quizás el aspecto más revelador de este debate sea que las preocupaciones de Hotz no vienen solo desde fuera de las empresas que desarrollan estas herramientas. Un desarrollador de OpenAI, conocido por el seudónimo roon, corroboró las preocupaciones de Hotz a principios de este año y abordó la cuestión de una forma bastante inusual. Según él, la IA va a cometer errores, incluso errores lo suficientemente dramáticos como para tumbar sistemas enteros. Esos bugs serán difíciles de encontrar, pero eventualmente se corregirán. La predicción más provocadora de roon fue que los desarrolladores pronto van a dejar de revisar manualmente el código generado por IA.
Esta perspectiva es al mismo tiempo realista y perturbadora. Si los propios creadores de estas herramientas reconocen que el código generado tendrá fallos graves y que la tendencia natural es que los humanos simplemente dejen de verificar, estamos ante un escenario donde la calidad del código puede entrar en caída libre sin que nadie se dé cuenta hasta que sea demasiado tarde. Es exactamente el tipo de espiral que Hotz describe en su publicación, un Sloptember eterno, donde la degradación se vuelve permanente y normalizada.
Lo que está en juego para la industria
Lo que va a ocurrir de aquí en adelante sigue siendo una incógnita. Las empresas continúan invirtiendo fuertemente en AI agents para la automatización del desarrollo de software, y los argumentos de productividad a corto plazo son demasiado seductores como para descartarlos fácilmente. Los inversores quieren ver entregas más rápidas, equipos más pequeños y costos reducidos, y los agentes de IA prometen exactamente eso. La cuestión es si esa promesa se sostendrá cuando los proyectos comiencen a alcanzar el punto en que la deuda técnica acumulada se vuelva incontrolable.
La alerta de George Hotz planta una pregunta que seguirá rondando a la industria en los próximos años: ¿estamos construyendo sistemas más inteligentes o simplemente acumulando problemas más rápido que nunca? El contraste entre la posición de Hotz y la de Karpathy muestra que incluso las mentes más brillantes de la tecnología discrepan profundamente sobre el camino a seguir. Y esa discrepancia, por sí sola, ya es una señal de que el tema merece mucha más cautela de la que la mayoría de las empresas está demostrando en este momento.
Esa respuesta, al final de cuentas, solo el tiempo y los repositorios de código la van a revelar. 🤔
