La IA no va a reescribir todo el software, y menos mal
La IA no va a reescribir todo el software que escribimos los humanos, y si lo intentara, el resultado tendría más vulnerabilidades. Lo que está cambiando es más aburrido y vale más: encontrar bugs y demostrar que el código hace lo que dice se está volviendo barato, y esa es la parte de la ingeniería de software que siempre nos saltamos por cara.
Lo digo por un post que Guillermo Rauch publicó en X el 5 de noviembre de 2026. Rauch es fundador y CEO de Vercel y creador de Next.js, el framework con el que está hecho este blog. La traducción es mía:
Todos vamos a aprender en las próximas semanas y meses que la mayor parte del software hecho por humanos era muy lento, tenía muchas vulnerabilidades de seguridad y estaba subespecificado y era incorrecto. La IA lo va a reescribir todo. Muchas veces. Lo va a hacer rápido, eficiente en costos y seguro. [...] Va a probar, verificar formalmente, hacer pruebas de carga, endurecer. Va a convertir cimientos inseguros en memoria en cimientos robustos y optimizados. [...] En muchos sentidos, estamos presenciando el verdadero nacimiento de la ingeniería de software.
La primera mitad la firmo. La segunda, no.
El diagnóstico es correcto: el software humano está lleno de bugs
El software que escribimos tiene problemas, y yo tengo los míos publicados. Hace unos meses construí un plugin comercial de WordPress con 615 aserciones de test en verde, y seis defectos importantes pasaron igual. Cuatro de los seis los introduje yo, en código que había escrito con cuidado. Ninguno producía un error: todos degradaban hacia algo que se veía plausible.
Nadie había escrito qué tenía que pasar en esos casos, así que ningún test lo comprobaba: subespecificado e incorrecto, como dice Rauch.
Lo que la IA ya encuentra, con números
La IA ya encuentra este tipo de fallos en proyectos mucho más serios que el mío. Tres casos documentados:
SQLite. En octubre de 2024, Big Sleep, el agente de Google Project Zero y DeepMind, encontró un stack buffer underflow explotable en SQLite. Después de 150 horas de CPU de fuzzing, el bug seguía sin aparecer. Lo reportaron y se corrigió el mismo día, antes de llegar a una versión publicada. Google lo presentó como el primer ejemplo público de un agente de IA que encuentra un fallo de memoria explotable y desconocido en software real de uso masivo.
AIxCC. En la final del AI Cyber Challenge de DARPA, en agosto de 2025, los sistemas de los finalistas descubrieron 54 vulnerabilidades sintéticas en 63 desafíos y parcharon 43. Además encontraron 18 vulnerabilidades reales, no plantadas, en proyectos open source, con un costo medio de unos 152 dólares por tarea. Los siete sistemas finalistas se liberan como open source.
curl. Este es el que más me gusta, porque tiene las dos caras. En septiembre de 2025, el investigador Joshua Rogers mandó al proyecto decenas de reportes encontrados con herramientas de análisis con IA, y Daniel Stenberg le dijo a The Register que se habían mergeado unos 50 fixes. Su resumen: "herramientas potentes en manos de un humano inteligente son, sin duda, una buena combinación". Cuatro meses después, el mismo proyecto cerró su bug bounty a fines de enero de 2026 para "quitar el incentivo de mandarnos reportes basura y mal investigados, generados por IA o no".
La lección: la misma tecnología le dio a curl 50 fixes y un torrente de basura. Buscar bugs ya lo hace bien; decidir cuáles importan sigue siendo trabajo tuyo, y alguien tiene que leer el reporte antes de mandarlo.
Reescribirlo todo es la parte que no cierra
Acá el post se equivoca, y el dato más claro viene de Google, que lleva años sacando los fallos de memoria de Android.
En su post de septiembre de 2024, el equipo de Android cuenta que las vulnerabilidades de seguridad de memoria pasaron del 76% del total en 2019 al 24% en 2024. Lo lograron escribiendo el código nuevo en lenguajes seguros en memoria, sin reescribir el viejo, y explican por qué:
- Las vulnerabilidades se concentran en el código nuevo.
- El código madura y se vuelve más seguro con el tiempo. Según sus datos, el código de cinco años tiene entre 3,4 y 7,4 veces menos densidad de vulnerabilidades que el código nuevo.
- Por eso el retorno de una reescritura cae a medida que el código envejece.
Su conclusión, textual: "no necesitamos tirar ni reescribir todo nuestro código existente inseguro en memoria". El título de esa sección es "la interoperabilidad es la nueva reescritura".
Ahora junta eso con el post de X. Si la IA "lo reescribe todo, muchas veces", cada reescritura convierte código con años de bugs ya encontrados y corregidos en código nuevo, sin historia. Y el código nuevo es justo donde Google encontró las vulnerabilidades.
Tampoco ayuda que el código que genera la IA no venga seguro por defecto. Veracode probó más de 100 modelos sobre 80 tareas de programación y en el 45% de los casos el código introdujo vulnerabilidades del OWASP Top 10. En Java, la tasa de falla pasó del 70%. Contra cross-site scripting fallaron en el 86% de los casos. Y cuando salga el próximo modelo, conviene recordar que, según Veracode, los modelos más grandes no salieron significativamente mejor que los chicos.
El estudio no compara contra código escrito por personas; lo que muestra es que reescribir con IA, por sí solo, no deja el código seguro.
La lección: si tienes código viejo que funciona, la IA te sirve más auditándolo que reemplazándolo. Reescribir sigue siendo la decisión cara, aunque escribir el código ahora cueste minutos.
Lo que sí cambia: verificar se vuelve barato
De todo lo que promete el post, lo que más me interesa va casi de pasada: "verificar formalmente".
Martin Kleppmann, el autor de Designing Data-Intensive Applications, publicó en diciembre de 2025 una predicción: la IA va a llevar la verificación formal al mainstream. Su argumento empieza por el costo. En 2009, el microkernel seL4 tenía 8.700 líneas de C, y demostrar que era correcto llevó 20 años-persona y 200.000 líneas de pruebas en Isabelle. Por eso casi nadie verifica formalmente: es carísimo.
Si un modelo puede escribir esas pruebas, la ecuación cambia. Y Kleppmann lo dice mejor que yo: en lugar de que un humano revise el código generado por IA, preferiría que la IA le demuestre que el código que generó es correcto. Una prueba que no cierra la rechaza el verificador, así que una alucinación no pasa.
Pero el mismo Kleppmann marca el límite: el problema se mueve a definir bien la especificación, y escribir especificaciones formales todavía requiere experiencia y pensar con cuidado.
Ahí está mi desacuerdo principal con el post. Mis seis bugs eran casos que nadie había especificado, así que no había especificación contra la cual fallar. La IA puede demostrar que tu código cumple lo que escribiste, pero lo que se te olvidó escribir queda fuera de cualquier prueba.
No es el nacimiento de la ingeniería de software
La frase final del post, "el verdadero nacimiento de la ingeniería de software", tiene un problema de fechas. La OTAN organizó sus conferencias de Software Engineering en 1968 y 1969, y Brian Randell, que estuvo en ellas, escribió en 2018 que algunos proyectos grandes todavía sufren problemas "demasiado parecidos" a los que en 1968 abrieron la discusión sobre una "crisis del software".
O sea: el diagnóstico de que el software humano es lento, inseguro y está subespecificado tiene casi 60 años. La ingeniería de software es la respuesta a eso, y siempre tuvo las herramientas: especificar, probar, verificar, revisar. Lo que no tenía era presupuesto para hacerlo en serio, y eso es lo que cambia la IA: le baja el costo a la parte que siempre recortábamos primero.
Entonces, ¿qué hago con esto?
Tres cosas que puedes aplicar desde mañana, sin esperar a que la IA "lo reescriba todo":
- Pon a la IA a buscar bugs en el código que ya tienes, y lee cada reporte antes de abrir un issue. Es lo que hizo Rogers con curl y es lo que separó sus 50 fixes de la basura que cerró el bug bounty.
- Trata el código que genera la IA como código nuevo, porque lo es: con revisión, tests y análisis estático. Para PHP escribí sobre Sloppy, que busca justo las formas que dejan los agentes.
- Gasta tu tiempo en la especificación. Si la IA se encarga cada vez más de escribir y verificar, lo que queda en tus manos es decir qué tiene que pasar, y eso ningún modelo lo puede adivinar por ti.
Sobre el proceso que rodea todo esto, escribí sobre vibe coding vs. agentic engineering. Y si te preocupa más lo que le pasa a tu cabeza que a tu código: ¿Claude te está haciendo más tonto?.
Preguntas frecuentes
¿La IA puede encontrar vulnerabilidades reales en el código?
Sí, y hay casos documentados. Big Sleep, de Google, encontró un fallo de memoria explotable en SQLite en 2024 que el fuzzing no había detectado, y en la final del AI Cyber Challenge de DARPA los sistemas finalistas encontraron 18 vulnerabilidades reales en proyectos open source. En curl se mergearon unos 50 fixes a partir de reportes hechos con herramientas de IA.
¿El código generado por IA es seguro?
No por defecto. En el estudio de Veracode de 2025, sobre más de 100 modelos y 80 tareas, el código generado introdujo vulnerabilidades del OWASP Top 10 en el 45% de los casos, y los modelos más grandes no salieron significativamente mejor. Hay que revisarlo como cualquier código nuevo.
¿Conviene reescribir código legacy con IA?
En general no, si el código funciona. Los datos de Android muestran que las vulnerabilidades se concentran en el código nuevo y que el código de cinco años tiene entre 3,4 y 7,4 veces menos densidad de vulnerabilidades. Google redujo sus fallos de memoria escribiendo el código nuevo en lenguajes seguros, sin reescribir el viejo. La IA rinde más auditando ese código que reemplazándolo.
¿Qué es la verificación formal y por qué importa con IA?
Es demostrar matemáticamente que un programa cumple una especificación, con una prueba que revisa una herramienta como Lean o Isabelle. Hasta ahora era carísima: verificar las 8.700 líneas de seL4 llevó 20 años-persona. Si la IA escribe las pruebas, el costo baja, y una prueba incorrecta la rechaza el verificador. Lo difícil pasa a ser escribir bien la especificación.
¿La IA va a reemplazar la ingeniería de software?
No. Ya en las conferencias de Software Engineering de la OTAN de 1968 se discutía una "crisis del software", y la disciplina lleva desde entonces lidiando con software tarde, caro y con fallas. La IA abarata partes de esa disciplina, como buscar bugs y verificar, pero decidir qué tiene que hacer el software sigue siendo trabajo de alguien.
Fuentes
- Post de Guillermo Rauch en X (el texto que da pie a este artículo)
- From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code (Google Project Zero, el bug de SQLite)
- AI Cyber Challenge marks pivotal inflection point for cyber defense (DARPA, resultados de la final de AIxCC)
- Eliminating Memory Safety Vulnerabilities at the Source (Google Security Blog, los datos de Android)
- AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks (Veracode, GenAI Code Security Report 2025)
- Prediction: AI will make formal verification go mainstream (Martin Kleppmann)
- Curl project, swamped with AI slop, finds not all AI is bad (The Register, los fixes de Joshua Rogers)
- Curl shutters bug bounty program to remove incentive for submitting AI slop (The Register, el cierre del bug bounty)
- Fifty Years of Software Engineering - or - The View from Garmisch (Brian Randell, sobre las conferencias de la OTAN de 1968 y 1969)