Primero los tests: la red de seguridad con IA

El test en el prompt: sí funciona

Aquí hay una medición limpia. Un artículo de congreso de 2024 comparó tres situaciones: solo el enunciado; el enunciado más unos tests dados; y lo mismo con una vuelta de reparación alimentada por los tests fallidos. Dos modelos, dos conjuntos de tareas ya establecidos, más 1.100 problemas de competición.

La ganancia es inequívoca, y cuanto más flojo es el modelo, mayor resulta.

Pero hay dos límites que los propios autores dejan escritos.

El primero: más tests no siempre es mejor. A medida que crece el número de tests dados, «en ciertos casos se rompe código que antes era correcto». La causa es la información que se pierde en un contexto largo. Existe un óptimo, y a partir de ahí empeora.

El segundo importa más: la solución que pasaba los tests dados fallaba a menudo en los tests ocultos. Es decir, el modelo optimiza para el test que le has dado, no para la corrección. No es un defecto, es la naturaleza de la tarea — pero hay que saberlo.

El test que el agent se escribe a sí mismo: no funciona

Esta parte baja los humos, y muestra justo lo contrario de lo que esperarías.

Una medición de 2026 examinó seis modelos sobre el mismo conjunto de 500 tareas sacadas de repos reales. Dos extremos:

• Un modelo se escribió un test en el 83 % de las tareas. Su tasa de resolución: 74,4 %.
• Otro lo hizo en el 0,6 %. Su tasa de resolución: 71,8 %.

2,6 puntos porcentuales de diferencia — mientras uno testea casi siempre y el otro casi nunca. Y cuando por prompt se prohibió escribir tests a los modelos que más testeaban, el resultado apenas se movió: un desplazamiento neto de unas diez tareas sobre quinientas.

La explicación es la verdadera lección del artículo: los «tests» que escribe el agent en su mayoría no son comprobaciones, sino instrumentos de observación. Según la medición, las líneas que imprimen un valor superan de forma sistemática a las aserciones. Esto es depuración por pantalla disfrazada de test.

La diferencia, por tanto, no está en si hay test o no. Está en quién dice cuál es el resultado correcto. Si el modelo escribe el test de su propio código, está comprobando su propia interpretación.

Cuando el test desvía al modelo: el test que consolida el fallo

Aquí está el mecanismo más importante, y es el que da título a este post.

Un estudio de 2026 miró qué pasa cuando el código existente, con su fallo dentro, está en el prompt y le pides un test. El resultado: el modelo escribe la aserción sobre el comportamiento defectuoso en lugar de delatarlo. El código defectuoso «orienta al modelo hacia tests que confirman el comportamiento erróneo, no hacia su descubrimiento».

Y el efecto es doble: no solo sube el número de tests desorientados, sino que baja la generación de tests eficaces, los que encuentran fallos.

Los autores midieron también la solución: no metas el código en el prompt, sino la especificación — lo que debería hacer. Eso «reduce sustancialmente los tests desorientados y aumenta de forma significativa los eficaces».

Por eso «primero el test» no es una moda de estilo. Es la única manera conocida de que el test generado no consolide el fallo ya existente: si el código todavía no está, el modelo no tiene nada que copiar.

Un matiz, por honestidad: ese mismo estudio también constató que la mayoría de los tests generados contra el código defectuoso, y que pasan en él, pasan también en la versión corregida — o sea, muchos tests sencillamente no fijan ningún comportamiento. La literatura anterior sobrestimó esto.

¿Cómo de tupida es la red?

Conviene saber dónde está el límite del test como red de seguridad — y para eso hay datos duros de un entorno académico.

Un artículo de congreso de 2026 revisó a mano 77 parches, salidos de tres agents, sobre el conjunto de tareas mejor curado del sector. Los resultados:

• El 7,8 % de los parches contaba como «correcto» pese a fallar en la batería de tests de los desarrolladores.
• El 29,6 % de los parches «probablemente buenos» producía un comportamiento distinto del arreglo real.
• En conjunto, las tasas de resolución publicadas están infladas en 6,4 puntos porcentuales absolutos.

El motivo es sencillo: el baremo solo usa los ficheros de test que modificó el pull request original — el resto de la funcionalidad se queda sin comprobar.

Si esto pasa en un conjunto académico montado con cuidado, en tu propio repo no será mejor. El test solo mide lo que mide.

¿Cuándo significa algo la cobertura?

También hay medición reciente: once modelos, trece configuraciones, 8.268 baterías de tests generadas, 101.123 casos de test únicos.

La conclusión en una frase: la utilidad de la cobertura y del mutation score depende muchísimo de la situación.

• Si se puede suponer que el código está bien — situación de regresión, donde el test conserva el comportamiento existente —, entonces estas métricas dan una señal con sentido, sobre todo al comparar modelos.
• Si el código puede estar defectuoso y justo quieres encontrar el fallo, entonces ya no son señales fiables.

Esto encaja exactamente con lo anterior. El test generado sirve de buena red de regresión. Para detectar fallos, no.

La buena noticia: no son flaky

Un miedo frecuente al que la medición responde de forma tranquilizadora. En un estudio sobre sistemas de bases de datos industriales y de código abierto se generaron tests nuevos para más de 5.000 ficheros de test, y la proporción de tests de comportamiento inestable («flaky») se movió entre el 0,00 % y el 0,29 %.

La causa principal, donde apareció: el test se apoyaba en un orden que no está garantizado — en 72 de 115 casos, es decir, el 63 %.

El problema no es, pues, que los tests generados fallen de forma poco fiable. Es que de forma muy fiable no atrapan nada.

El embudo: 18 de cada 100 tests generados

Hay una referencia industrial para esto, con proporciones publicadas. Del sistema automatizado de reparación de tests de una gran empresa de redes sociales:

Caso de test generado:                     100
Compila:                      100 × 0,75 =  75
Se ejecuta de forma fiable:   100 × 0,57 =  57
Aumenta la cobertura:         100 × 0,25 =  25   <- solo esto sirve
Un ingeniero lo acepta:        25 × 0,73 = ~18

(Cálculo propio a partir de las proporciones publicadas.)

Dieciocho tests de cada cien. Y eso lo produjo un sistema que ejecutaba todos los tests generados, varias veces, y solo dejaba pasar los que aumentaban la cobertura.

Este es el mensaje clave frente al consejo de «genera tests»: generar sale barato, el filtro es el trabajo.

Por qué vale tanto un test que falla

Hay un estudio de 2024 sobre cuánto vale que el modelo corrija su propio código a partir de los errores. La respuesta: corregida por el coste de cómputo, la ganancia es «modesta, varía mucho de un conjunto de datos a otro y a veces no existe en absoluto».

El cuello de botella, sin embargo, no es la capacidad de reparar, sino el diagnóstico. Cuando era un modelo más potente el que daba la retroalimentación, el resultado mejoraba de forma notable. Y los autores añaden: incluso los mejores modelos quedan muy lejos de lo que se consigue depurando a mano.

De ahí sale la regla práctica más importante: el nombre y el mensaje de un test que falla son retroalimentación externa, no salida del propio modelo. Justo lo que desbloquea el cuello de botella. Por eso vale más un buen test que falla que diez vueltas de «inténtalo otra vez».

La receta: una puerta en cuatro niveles

1. EN EL NIVEL DEL PROMPT
   No "escribe un test para esta función", sino:
   "escribe una función validateEmail. Ejemplos: [email protected]
    verdadero, invalid falso, [email protected] falso. Después de
    implementarla, ejecuta los tests."
   -> el ejemplo ES la especificación. El código NO va en el prompt.

2. EN EL NIVEL DE LA SESIÓN
   Un objetivo fijo que algo comprueba después de cada vuelta.
   "Enséñame la salida de los tests" - no que ya está listo.

3. UNA PUERTA DETERMINISTA
   Un script que bloquea el final de la vuelta hasta que esté verde.
   Lo único de la lista que obliga en vez de sugerir.

4. UNA SEGUNDA OPINIÓN
   Un revisor aparte, con contexto FRESCO. Quien lo escribió
   está sesgado a favor de su propio código.

Y EL PATRÓN DE DOS MODELOS que el fabricante recomienda para TDD:
   uno escribe el test, el otro el código que lo pasa.

Una pregunta abierta que conviene decir en voz alta

Lo hemos buscado, y no hemos encontrado ninguna medición sobre si la cobertura de tests que ya tiene un repo mejora el resultado del agent en ese mismo repo.

Lo que sí hay: el test puesto en el prompt mejora; el test escrito por el agent no; la batería del baremo es demasiado estrecha. La relación entre la cobertura como propiedad del repo y la tasa de éxito del agent es, de momento, una suposición sin medición. Lógica, creíble — pero no demostrada.

Malentendidos típicos

• «Genero tests y ya tengo la red.» De cien quedan dieciocho utilizables incluso en un proceso industrial rigurosamente filtrado.
• «Si el agent se escribe tests, es buena señal.» Según la medición apenas cambia el resultado, y lo que escribe es sobre todo impresión por pantalla, no aserción.
• «Los tests están en verde, luego el código está bien.» En una medición académica, el 7,8 % de los parches contaba como correcto pese a fallar en la batería de los desarrolladores.
• «Le paso el código defectuoso y que escriba un test.» Así lo que vas a fijar es justo el comportamiento erróneo. Dale la especificación, no el código.
• «Los tests generados fallan de forma poco fiable.» Su flakiness quedó por debajo del 0,3 %. El problema es el contrario: de forma muy fiable no atrapan nada.

Lo que conviene llevarse

El test vale algo cuando eres tú quien dice qué es lo correcto — el ejemplo puesto en el prompt mejora entre un 7 y un 30 %, el test propio del agent prácticamente nada. Y si el código ya existe, el test generado tiende a fijar el fallo que hay en vez de encontrarlo. De ahí el orden: primero el test que falla, después el arreglo. Generar sale barato — filtrar es el trabajo.

Cómo encargar el primer trabajo lo recorre el post tu primera tarea con un coding agent , paso a paso; y la revisión del código terminado la detalla el post revisar código escrito por IA , con su checklist.