Dos brazos robóticos sobre una mesa: uno levanta una torre de bloques con símbolos de código y el otro la inspecciona con una lupa y señala una grieta en uno de los bloques.

Pruebas adversariales: cómo comprobar el código que escribe la IA

pruebas adversariales, revisión adversarial, pruebas basadas en propiedades, fuzzing, código generado por ia, big sleep, bun rust, sqlite

Pruebas adversariales: cómo comprobar el código que escribe la IA

Fecha: 2026-11-07 16:39:11
Autor: Alex Rubio

Cada vez más código lo escriben asistentes de inteligencia artificial y, con frecuencia, es la misma IA la que redacta también las pruebas automáticas que deben comprobarlo. Ese doble papel tiene un riesgo evidente: si el modelo no prevé un caso poco habitual al programar, lo más probable es que tampoco lo pruebe. Para reducir ese riesgo están ganando peso las pruebas adversariales, un conjunto de técnicas cuyo objetivo no es confirmar que un programa funciona, sino intentar demostrar que falla.

Dos casos recientes ilustran su utilidad. En mayo de 2026, el equipo de Bun, un entorno para ejecutar JavaScript que pertenece a Anthropic, integró una reescritura completa de su código hecha con Claude en la que cada cambio pasó por dos revisores adversariales. Antes, a finales de 2024, Big Sleep, un agente de IA de Google , encontró en la base de datos SQLite un fallo que, según Google , ni su servicio de pruebas OSS-Fuzz ni las pruebas del propio proyecto habían detectado.

Qué son las pruebas adversariales y por qué importan ahora

Una prueba automática, o test, es un pequeño programa que comprueba otro. El ejemplo más sencillo sería: «si sumo 2 y 2, el resultado debe ser 4». El problema aparece cuando quien escribe el código y quien escribe las pruebas comparte los mismos puntos ciegos. Es parecido a corregir tu propio examen: si no sabías una respuesta, tampoco detectarás el error al revisarlo.

Por eso, las pruebas adversariales cambian el enfoque. En lugar de comprobar que todo va bien, alguien, o algo, recibe el encargo de romper el código. No es una categoría formal ni una invención reciente, sino una forma de agrupar técnicas conocidas. Lo novedoso es que ahora se aplican con agentes de IA, es decir, modelos que no solo responden preguntas, sino que ejecutan tareas: escriben código, lo prueban y lo corrigen.

Revisión adversarial

Consiste en lanzar un segundo agente con instrucciones distintas para que revise el trabajo del primero buscando errores a propósito. Se parece a pedir a un compañero que lea tu contrato buscando cláusulas que puedan perjudicarte, en vez de preguntarle si está bien.

Pruebas basadas en propiedades

En lugar de comprobar ejemplos uno a uno, se fija una regla general que siempre debe cumplirse, como «ordenar una lista ya ordenada no la cambia» o «si cifro y descifro un texto, recupero el original». Según la documentación de Hypothesis, una de las herramientas más usadas en Python, la herramienta genera entradas al azar, incluidos casos límite, y si encuentra una que rompe la regla, ofrece el ejemplo más simple posible que la reproduce.

Fuzzing

El fuzzing consiste en enviar a un programa grandes cantidades de datos aleatorios o mal formados para ver si se cuelga o se comporta de forma anómala. Sería como probar una cerradura con miles de llaves deformadas para ver si alguna la abre o la bloquea. Para hacerlo hace falta un arnés, el pequeño programa que conecta la herramienta de fuzzing con el software que se prueba.

El caso de Bun: dos revisores para cada cambio

Bun estaba escrito en Zig, un lenguaje de bajo nivel, y su equipo decidió trasladarlo a Rust, otro lenguaje que revisa la seguridad de la memoria al compilar. Según el blog oficial de Bun, Claude tradujo 1.448 archivos y el trabajo se organizó con un agente que implementaba y otros que hacían de revisores adversariales. Cada línea pasó por dos revisores distintos, también Claude, y hubo una ronda de correcciones antes de cada commit, que es cada cambio guardado en el historial del código.

De acuerdo con ese mismo blog, los revisores tenían instrucciones de rechazar los comentarios explicativos sospechosamente largos que el modelo añadía para justificar soluciones provisionales. Además, el proceso empezó con solo tres archivos antes de ampliarse al resto, y tras la fusión se hicieron 11 rondas de revisión de seguridad. Según Developers Digest, que cita el artículo técnico de Bun, se tradujeron 535.496 líneas de Zig en 11 días; otras publicaciones ofrecen cifras distintas.

Sin embargo, el resultado no ha estado exento de críticas. Según Developers Digest, el código contiene alrededor de 13.000 bloques unsafe, zonas de Rust donde se desactivan sus protecciones de memoria, que suponen en torno al 4 % del total. Heise informó también de que se modificaron algunas pruebas antiguas para que la versión en Rust las superara. Según The Register, su creador, Jarred Sumner, afirma que el nuevo código supera las pruebas en todas las plataformas, corrige algunas fugas de memoria y reduce el programa entre 3 y 8 MB.

El caso de SQLite: lo que las pruebas habituales no vieron

Big Sleep es un proyecto conjunto de Google Project Zero y Google DeepMind. El 1 de noviembre de 2024, Project Zero anunció que había encontrado en SQLite un fallo de memoria explotable de tipo stack buffer underflow, en el que el programa accede a una zona de memoria anterior a la que le corresponde. Según BigDATAwire y Dark Reading, el error estaba en una versión de desarrollo y se corrigió el mismo día en que se comunicó, antes de llegar a ninguna versión publicada.

Lo relevante es por qué nadie lo había visto antes. Según Project Zero, el arnés de OSS-Fuzz no tenía activada la extensión afectada, llamada generate_series, y el arnés alternativo usaba una versión antigua de la función. Es decir, esa parte del código no se estaba probando. Aun así, Big Sleep no es una herramienta de fuzzing: según SecurityWeek y SC World, hizo un análisis de variantes, que consiste en partir de un fallo ya corregido y buscar otros parecidos en código reciente.

Posteriormente, en julio de 2025, Google afirmó en su blog que Big Sleep, combinado con su inteligencia de amenazas, había localizado una vulnerabilidad crítica de SQLite, registrada como CVE-2025-6965, que solo conocían los atacantes, y que se adelantó a su explotación. Según The Hacker News, afecta a las versiones anteriores a la 3.50.2.

Pruebas adversariales: lo que se dice y lo que dicen los datos

Afirmación que circula	Veredicto	Explicación
Si la misma IA escribe el código y los tests, todos pasarán y no demostrarán nada.	Exagerado	El riesgo de puntos ciegos compartidos es razonable, pero esas pruebas siguen sirviendo, por ejemplo, para detectar que algo que funcionaba se ha roto. No hemos encontrado ningún estudio que mida este efecto: es un análisis, no un dato.
Las pruebas adversariales son un tipo de test nuevo.	Exagerado	Agrupan técnicas anteriores. Hypothesis sitúa el origen de las pruebas basadas en propiedades en QuickCheck, una herramienta del lenguaje Haskell. Lo nuevo es su uso con agentes de IA.
Bun pasó más de 500.000 líneas de Zig a Rust y Claude escribió la mayor parte.	Cierto	El blog de Bun habla de 1.448 archivos traducidos por Claude; Developers Digest cifra el código de partida en 535.496 líneas.
Cada commit de Bun pasó por dos revisiones adversariales del mismo modelo.	Cierto	Lo confirma el blog oficial de Bun. Según Remio, cada revisor tenía sus propias reglas y su propio contexto de trabajo.
Anthropic probó las pruebas basadas en propiedades con IA y más de la mitad de los fallos eran reales.	Incompleto	El artículo científico Agentic Property-Based Testing analizó 100 paquetes de Python: el 56 % de los informes eran fallos válidos, pero solo el 32 % merecía comunicarse a los responsables y el 44 % no eran fallos reales.
Una IA de Google encontró con fuzzing un fallo en SQLite.	Incompleto	Big Sleep usó análisis de variantes, no fuzzing. Lo cierto es que el fuzzing existente no detectó el fallo porque su arnés no cubría esa parte del código.
Las pruebas tradicionales han dejado de ser útiles.	Falso	Siguen siendo necesarias. Los casos de Bun y SQLite apuntan a que deben complementarse con pruebas que busquen fallos activamente.

Conviene añadir un matiz sobre el estudio de pruebas basadas en propiedades. Según Neovintage, el trabajo revisó 984 informes y fue realizado por Anthropic junto a la Universidad Northeastern; no hemos podido confirmar esa afiliación en el propio artículo. Entre los fallos hallados figura uno en la función numpy.random.wald, que a veces devolvía valores negativos y ya está corregido.

Qué significa para ti

Si usas asistentes de IA para programar, o encargas proyectos a quien los usa, el mensaje práctico es que «los tests pasan» no equivale a «el código es correcto». Estas medidas ayudan a reducir el riesgo:

Separa los papeles: pide a un segundo agente, o a una sesión nueva con instrucciones distintas, que busque fallos en el código en lugar de validarlo. Si puedes, añade una revisión humana.
Vigila los cambios en las pruebas: si la IA modifica tests existentes para que el código los supere, revisa por qué.
Define reglas, no solo ejemplos: en funciones críticas, como cálculos de precios o cifrado, las pruebas basadas en propiedades detectan casos que no se te habrían ocurrido.
Comprueba qué cubren tus herramientas: el caso de SQLite muestra que una parte del código sin cubrir por el arnés queda sin probar.
Contrasta los informes de la IA: en el estudio citado, el 44 % de los avisos no eran fallos reales.
Actualiza tus dependencias: si tus aplicaciones usan SQLite, asegúrate de tener la versión 3.50.2 o posterior.

En resumen

Las pruebas adversariales reúnen técnicas como la revisión por un segundo agente, las pruebas basadas en propiedades y el fuzzing, con un objetivo común: buscar fallos en lugar de confirmar que todo funciona. No son nuevas, pero cobran relevancia ahora que la IA escribe tanto código como pruebas. El caso de Bun muestra cómo se integran en un proyecto grande, con resultados positivos y críticas; el de SQLite, que las pruebas habituales pueden dejar zonas sin revisar; y el estudio sobre pruebas basadas en propiedades, que los hallazgos de la IA también requieren revisión humana.