Prólogo: la cinta de chocolates

Hay una escena de I Love Lucy (1952) que todo el mundo reconoce aunque no haya visto la serie. Lucy y Ethel entran a trabajar en una fábrica de chocolates; su tarea es envolver cada bombón que pasa por la cinta transportadora. Al principio la cinta va lento y envuelven con calma. Después alguien acelera la cinta. Las dos empiezan a meterse bombones en la boca, en el sombrero, en el escote — cualquier cosa con tal de que la supervisora no vea uno sin envolver. La supervisora entra, mira la cinta vacía y grita: «¡Más rápido!».

Durante los primeros meses de trabajar con agentes de código, el Tech Lead fue Lucy. La cinta era el diff. Y cuando el agente pasó de producir decenas de líneas por sesión a producir módulos enteros en una tarde, el revisor hizo exactamente lo que hace Lucy: aprobar sin mirar, con la esperanza de que nadie notara la diferencia. Este paper es sobre qué hacer cuando la cinta ya no se puede frenar.

El cuello de botella cambió de lugar

La revisión de código nunca fue tan buena detectando defectos como creíamos. Cuando Bacchelli y Bird (2013) estudiaron la revisión moderna en Microsoft, encontraron que encontrar defectos era la motivación número uno declarada por los desarrolladores, pero que los resultados reales «se centran menos en los defectos de lo esperado»: lo que la revisión aporta de verdad es transferencia de conocimiento y conciencia de equipo. La revisión importa — McIntosh et al. (2016) muestran que los componentes con poca participación de revisores acumulan más defectos después del lanzamiento —, pero importa por la participación, no por la lectura línea a línea.

Y esa lectura tiene un límite físico. Las recomendaciones clásicas de la industria, basadas en un estudio con Cisco, dicen que una sesión de revisión no debería superar las 200 a 400 líneas ni los 60 a 90 minutos, y que por encima de unas 500 líneas por hora la densidad de defectos detectados cae significativamente (SmartBear, s. f.). Un agente bien dirigido produce esas 400 líneas, con sus pruebas y su documentación, en el tiempo que toma hacerse un café. El revisor no está leyendo con menos atención: está leyendo a una velocidad a la que la atención no encuentra nada.

Los datos de la industria lo confirman desde varios ángulos. El reporte DORA de 2024 encontró que a mayor adopción de IA, la estabilidad de entrega bajaba un 7,2 % y el throughput un 1,5 %, con un 39 % de los encuestados declarando poca o ninguna confianza en el código generado (Harvey y DeBellis, 2024). Un año después, con unas 5.000 respuestas, el 90 % ya usaba IA en el trabajo y la adopción se asociaba positivamente con el throughput, pero seguía asociada negativamente con la estabilidad: la IA es «un amplificador» de las fortalezas y las disfunciones de cada equipo, y los beneficios aparecen en equipos con bucles de retroalimentación rápidos (Harvey y DeBellis, 2025). En la encuesta de Stack Overflow de 2025, el 46 % de los desarrolladores desconfía de la precisión de la salida de la IA, la frustración principal son las soluciones «casi correctas, pero no del todo» (66 %) y un 45 % dice que depurar código de IA consume más tiempo (Stack Overflow, 2025).

El estudio más incómodo es el de METR. En un experimento controlado con 16 desarrolladores experimentados y 246 tareas reales en repositorios maduros, quienes usaron IA tardaron un 19 % más — aunque esperaban ir un 24 % más rápido y, después del estudio, seguían creyendo haber ido un 20 % más rápido (Becker et al., 2025). Buena parte del tiempo extra se fue en revisar y corregir lo que la IA producía. Y GitClear, analizando 211 millones de líneas modificadas entre 2020 y 2024, encontró que el código copiado y pegado subió del 8,3 % al 12,3 % y superó por primera vez al código refactorizado (GitClear, 2025): la IA genera volumen que nadie alcanza a leer ni a limpiar.

La conclusión no es que la IA produzca peor código. Es que el control de calidad que elegimos no escala con lo que la IA produce. Cuando un control no escala, hay dos opciones: frenar la cinta o cambiar el control.

El reemplazo: la IA escribe las pruebas y se pone a prueba

El control que sí escala ya existe y está bien documentado: que el mismo agente que escribe el código escriba las pruebas, las ejecute y corrija hasta que pasen. No es una idea del laboratorio; es cómo se mide hoy el progreso de estos sistemas. SWE-bench, el benchmark de referencia, toma 2.294 problemas reales de repositorios públicos y declara resuelto un problema no cuando un humano aprueba el parche, sino cuando pasan las pruebas que el proyecto original escribió para él (Jimenez et al., 2024). Los agentes que mejor rinden en ese benchmark funcionan ejecutando código y pruebas como parte de su propio bucle (Yang et al., 2024), y hasta la variante más simple — localizar, reparar, validar — debe su fiabilidad a la fase de validación, donde genera y ejecuta pruebas para elegir el parche (Xia et al., 2024).

Los propios fabricantes lo dicen sin rodeos. En su guía sobre agentes, Anthropic explica que las soluciones de código «son verificables mediante pruebas automatizadas» y que los agentes «pueden iterar usando los resultados de las pruebas como retroalimentación» (Schluntz y Zhang, 2024). Y la documentación de Claude Code es casi literal con la tesis de este paper: si el agente no tiene nada que ejecutar que le diga si el trabajo está realmente terminado, «parece terminado» es todo lo que tiene — «en la práctica, eso te convierte a ti en la suite de pruebas». La recomendación es exigir evidencia: el comando que corrió y su salida, o la captura de pantalla; «todas las pruebas pasan», por sí solo, «dice muy poco» (Anthropic, s. f.).

La generación de pruebas con modelos de lenguaje ya tiene resultados industriales. En Meta, TestGen-LLM mejoró el 11,5 % de las clases sobre las que se aplicó y el 73 % de sus recomendaciones fue aceptado por los ingenieros para producción (Alshahwan et al., 2024). TestPilot, sobre 25 paquetes de JavaScript, alcanzó una cobertura mediana de sentencias del 70 % frente al 51 % de la mejor técnica tradicional — y cuando una prueba falla, le pasa el error al modelo y la repara (Schäfer et al., 2024). CodaMosa combina búsqueda evolutiva con el modelo para escapar de las mesetas de cobertura donde las herramientas clásicas se estancan (Lemieux et al., 2023), y CoverUp inyecta la información de cobertura en el diálogo con el modelo para llegar a una cobertura mediana del 80 % por módulo (Pizzorno y Berger, 2025). Una revisión de 102 estudios muestra que la preparación de casos de prueba y la reparación de programas son ya las tareas dominantes de los modelos de lenguaje en pruebas de software (Wang et al., 2024).

Lo que cambia para el Tech Lead es el objeto de su atención. Ya no lee el diff: lee el informe de evidencia. Qué se probó, contra qué datos, qué se dejó fuera y por qué. Las preguntas del diálogo cognitivo siguen siendo las mismas; cambió la escala a la que se hacen.

Anécdota: lo que encontró sondear, no leer

Una noche, mientras el dueño de un sistema de gestión dormía, el agente construyó una pantalla para importar ventas desde una plataforma externa pegando el detalle del pedido. Escribió el analizador de texto y, en vez de leerlo para buscar errores, lo sondeó con entradas raras. Encontró cuatro defectos propios, y los cuatro producían datos incorrectos con la línea marcada como completa: un producto sin precio se robaba el del siguiente; un monto escrito como «$1.990,00» se leía como $199.000, cien veces más; una línea con un número suelto se tomaba como precio; y la cola de la boleta entraba como tres productos fantasma. Un visto bueno verde sobre un dato falso — peor que fallar. Ninguno de los cuatro se habría visto leyendo el código, porque el código era razonable para las entradas que su autor tenía en mente. Los encontró ejecutarlo contra las entradas que no tenía en mente. Terminó con 26 pruebas, incluido el pegado literal de la venta real que motivó la pantalla, que da exactamente el total de la boleta.

Las pruebas corren donde el producto vive

Una prueba unitaria sobre una función pura es evidencia barata. La evidencia que importa es la que corre contra el entorno real: la base de datos con su esquema de verdad, el servidor web con su reverse proxy, el navegador con sus rarezas. Por eso la segunda pieza del reemplazo es que el agente levante el entorno. Herramientas como Testcontainers existen justamente para eso: instancias desechables y livianas de bases de datos, colas de mensajes y navegadores en contenedores, creadas para una prueba y destruidas al terminar (Testcontainers, s. f.). En el laboratorio, la base de pruebas de la tienda en línea se crea como copia de la base demo con un comando del propio motor, y las pruebas de pagos, reservas y transferencias corren contra ella — no contra una base armada desde el modelo, que ya nos engañó una vez (ver el caso 5).

Lo mismo vale para la interfaz. Una prueba de extremo a extremo que abre el navegador, hace clic donde haría clic una persona y lee lo que aparece en pantalla es evidencia de otra categoría que una prueba que llama a la API. Y trae sus propias lecciones: al verificar la demostración de un panel de administración construido con un framework de componentes del lado del servidor, descubrimos que los clics automatizados a veces no llegaban al servidor justo después de cargar, y que un cuadro de confirmación nativo congelaba la pestaña entera. No eran errores del producto; eran rarezas del entorno que una prueba seria tiene que conocer. El agente las aprendió, las anotó y las sortea — y la verificación de la demo quedó como un flujo que repite, no como una tarde de clics de una persona.

Anécdota: el dispositivo que no estaba en la mesa

En una plataforma de monitoreo GPS, el servidor recibe tramas binarias de rastreadores físicos por TCP, en protocolos distintos según el fabricante. El agente escribió los analizadores de protocolo y sus pruebas con tramas de ejemplo tomadas de la documentación oficial. Las pruebas pasaban. En terreno, los rastreadores instalados sin el cable de contacto nunca reportaban el encendido del motor: la trama traía el campo, pero vacío, y la documentación daba por sentado que estaría. La plataforma terminó infiriendo el encendido por el movimiento. La lección no fue que las pruebas sobraran: fue que el entorno simulado tiene que alimentarse de datos capturados de la realidad, no solo de especificaciones. La regla que quedó: las pruebas de cada protocolo incluyen tramas reales capturadas de dispositivos instalados, y cuando algo no cuadra, la causa puede estar en el hardware o en el terreno antes que en el código.

Un teléfono virtual que el agente opera

El caso que más sorprende a quien recién llega es el de las aplicaciones móviles. Parece el territorio donde el humano con el teléfono en la mano es insustituible. No lo es. El emulador de Android simula dispositivos en el computador para probar una aplicación «en una variedad de dispositivos y niveles de API sin necesidad de tener cada dispositivo físico» (Google, 2026), y la investigación reciente muestra agentes de lenguaje que lo operan como lo haría un tester humano. GPTDroid formula la prueba de interfaz como un diálogo de preguntas y respuestas con el modelo, que decide qué tocar según la función de cada pantalla; sobre 93 aplicaciones de Google Play superó en un 32 % la cobertura del mejor sistema anterior y encontró 53 errores nuevos, 35 de ellos confirmados y corregidos por los desarrolladores (Liu et al., 2024). DroidAgent va un paso más allá: es un agente autónomo que se fija sus propias tareas realistas dentro de la aplicación, las ejecuta en el emulador y evalúa si las logró (Yoon et al., 2024).

En la práctica del laboratorio, el flujo es el mismo que con un contenedor: el agente crea el dispositivo virtual, instala la compilación, la abre, navega las pantallas, toma capturas y lee la jerarquía de la interfaz para comprobar lo que aparece. Cuando algo falla, adjunta la captura y el registro al informe de evidencia. El Tech Lead mira una secuencia de capturas con lo que el agente vio y lo que esperaba ver. Ese informe es mucho más fácil de juzgar que trescientas líneas de código de interfaz — y mucho más honesto.

Los contras: a merced de la IA

Hay que decirlo sin adornos: con este marco quedas a merced de lo que hace la inteligencia artificial. Si las pruebas que escribió tienen el mismo punto ciego que el código — y lo tendrán a veces, porque las escribió la misma mente —, nadie lo verá hasta producción. La literatura sobre confianza en la automatización lleva décadas describiendo este terreno. Lee y See (2004) muestran que la automatización falla cuando las personas no confían en ella «de forma apropiada»: ni demasiado ni demasiado poco. Parasuraman y Riley (1997) distinguen el mal uso (confianza excesiva) del desuso (rechazar la automatización, típicamente por falsas alarmas). Revisar línea por línea el código de un agente es desuso de la automatización de pruebas; aceptar «todo en verde» sin preguntar es mal uso. El marco vive en el medio, y el medio se sostiene con tres prácticas.

• Evidencia que dice lo que no cubre. El informe de cada cambio lista qué quedó fuera y por qué. Una suite que no puede fallar no es una suite; y una prueba que se salta en silencio cuando falta la base de datos es, exactamente, lo que nos pasó durante semanas con la tienda en línea: cientos de pruebas «en verde» que nunca tocaron un pago.
• Revisión adversarial automatizada. Después de un trabajo grande, se lanzan agentes cuya única tarea es encontrar defectos, y después otros cuya única tarea es refutar cada hallazgo. La noche de la pantalla de importación, de 28 hallazgos sobrevivieron 9, y el más grave era un script que habría puesto en cero la cantidad de las ventas históricas importadas desde la plataforma anterior — filas del registro contable. Ningún humano lo habría leído; lo encontró un proceso cuyo trabajo era imaginar los casos que el autor no imaginó. Y cuando el agente corrige una prueba, hay una forma de comprobar que la prueba sirve: romper el código a propósito y confirmar que la prueba lo nota.
• Un número demasiado bueno es un bug. En otro proyecto del laboratorio, un motor de simulación reportó durante semanas un resultado espectacular. Cuando se contrastó con un caso conocido, el mismo motor le dio a una referencia real una puntuación pésima: el número alto nunca fue un logro, era un mensaje de error. Un optimizador maximiza la función que le diste; si la función tiene un hueco, el resultado se ve espectacular precisamente porque está mal. Antes de celebrar una métrica, se contrasta con un caso que debe dar un valor sabido.

Y hay una cuarta práctica que no es de pruebas sino de infraestructura: aceptar que a veces el punto ciego llegará a producción, y haber preparado antes la red que lo convierte en un incidente de minutos. De eso trata la segunda parte de esta serie.

Rompiendo paradigmas que dábamos por sentados

Lucy no era mala envolviendo bombones. La cinta iba demasiado rápido para un control diseñado para otra velocidad. El revisor humano de código tampoco se volvió peor; la cinta cambió. Lo que proponemos no es dejar de controlar — es cambiar el control por uno que escala: la IA escribe las pruebas, levanta el entorno, se pone a prueba a sí misma y entrega la evidencia; el humano define qué significa funcionar, exige esa evidencia y la lee con desconfianza sana.

Esto rompe varios paradigmas a los que estábamos acostumbrados. Que entender el código era condición para confiar en él. Que la revisión por pares era el último filtro. Que un tester con el teléfono en la mano era insustituible. Y rompe, sobre todo, uno más profundo: que el desarrollador era la persona que escribía y leía código. Si ya no es eso, ¿qué es? De eso trata la tercera parte.

Lo que no cambió es lo que decíamos en mayo: preguntar lo obvio sigue siendo la habilidad más valiosa. Solo que ahora la pregunta obvia es «¿cuántas pruebas corrieron de verdad?».