Por qué los tests generados por IA engañan

Cuando le pides a la IA que escriba tests o revise código, obtienes respuestas que parecen profesionales pero fallan de formas muy específicas. Aprender a detectar esos fallos es la base para dejar de confiar ciegamente en la IA y empezar a supervisarla con criterio, algo clave para cualquier desarrollador que use herramientas de generación de código.

El proyecto que usamos durante todo el curso es Payments USC, una API de pagos en Python con FastAPI que además incluye un SDK client en TypeScript. Es un servicio financiero pequeño pero con la complejidad suficiente para lo que buscamos [00:36]. Y aquí viene lo interesante: este repositorio tiene bugs y vulnerabilidades sembrados a propósito para descubrirlos clase a clase [01:09].

Qué pasa cuando le pides tests a la IA con un prompt ingenuo

Imagina que quieres crear los tests del módulo amounts.py, que maneja toda la lógica del dinero: define tipos de cambio, comisiones mínimas por moneda y utilidades para parsear, validar montos, redondear centavos y calcular comisiones totales [01:47].

El prompt ingenuo es el que cualquiera escribiría la primera vez: literalmente "escribe los tests para amounts.py" [02:21]. Unos minutos después, la IA devuelve 40 tests que corren con PyTest y pasan todos [02:36]. Se ve como una suite profesional.

¿Por qué un test que pasa no significa que sea correcto? Porque un test puede documentar el comportamiento actual del código en lugar de verificar la regla de negocio real. Si el código tiene un bug, el test lo valida como si fuera correcto y pasa igual.

Por qué la IA no distingue entre el código y la lógica de negocio

Entre esos 40 tests hay uno con un error inyectado a propósito: dice que el fee es cero cuando el monto es cero [03:20]. El problema es que Cloud no supo diferenciar si debía respetar el código existente o la lógica de negocio real.

Y ahí está la trampa. No puedes identificar ese fallo con solo mirar los tests por encima. Las preguntas que quedan sin respuesta son demoledoras:

• ¿Qué otras cosas asumió mal la IA?
• Si cambias una línea del código, ¿alguno de esos 40 tests lo detecta?
• ¿Cuáles tests sobran y cuáles faltan?

El problema no es que el test pase o no, sino que no tienes un criterio para evaluarlo [04:15].

Qué falla cuando le pides revisar un pull request

Lo mismo ocurre si creas un pull request y solo le dices "revisa este PR". La IA devuelve un párrafo genérico: el código se ve bien, una sugerencia de nombre de variable, un comentario sobre un espacio [04:25].

¿Por qué la IA no detecta los bugs importantes en una revisión de código? Porque sin una rúbrica clara no sabe qué buscar. Si los bugs no aparecen y tú tampoco sabes qué buscar, no notas su ausencia.

Cuáles son los tres modos más comunes en que falla la IA

Estos tres patrones se repiten y conviene reconocerlos [05:03]:

1. Alucina APIs y paquetes. Se inventa funciones que no existen o importa librerías que nadie publicó, y lo hace con tanta seguridad que un atacante podría registrar esa librería falsa. Esto se conoce como Slop Squat.
2. Olvida las autorizaciones. Escribe endpoints que verifican que estás logueado, pero olvidan verificar que tengas permisos para la acción.
3. Te da la razón en lugar de retarte. La IA está diseñada para complacerte: si pides tests, te da tests diseñados para pasar. Pero un buen test existe para intentar romper el código.

Cómo se estructura el trabajo del curso en cuatro bloques

Todo lo que construimos se divide en cuatro bloques prácticos que funcionan como mapa de ruta [05:58]:

1. Generar pruebas tratando la generación de tests como un problema de evaluación, no de escritura.
2. Revisar código construyendo un revisor automático, el LLM as Judge, y calibrándolo.
3. Auditar lo existente soltando la IA sobre código que no conoce para buscar bugs y vulnerabilidades, siempre con escepticismo.
4. Integrar y calibrar convirtiendo el trabajo en una infraestructura real de continuous integration y continuous deployment.

Qué son los evals y por qué son lo mismo que el testing

Debajo de todo hay un concepto fundamental: los evals. En la industria de la IA, los evals son exámenes estandarizados para medir el desempeño de un modelo [06:47].

Y aquí está la revelación: la disciplina de los evals y el testing tradicional son, en esencia, lo mismo con distintos nombres [07:04]:

• Un LLM as Judge equivale a un revisor de PR con IA.
• Un red teaming o ataque dirigido equivale a tests de seguridad o adversariales.
• Un regression eval equivale a la compuerta del continuous integration que no deja entrar basura.

Cómo funciona el archivo failures.md como catálogo de fallos

El primer artefacto del curso es un archivo llamado failures.md, creado en la raíz del proyecto [07:52]. Será tu catálogo de fallos específicos del repo y por módulo.

Se inaugura anotando lo que la IA ignoró o hizo mal al crear los tests. Por ejemplo, la entrada sobre el fee en cero: la IA documentó el comportamiento actual del código, que no devuelve fee cuando el monto es cero, como si fuera el contrato de negocio, sin cuestionar si debería aplicar el fee mínimo [08:32].

El detalle concreto: cuando el amount es 0.03 sí devuelve un fee, pero cuando es cero no devuelve ninguno, tratando ese valor de forma inconsistente [09:04]. Para cerrar, se hace commit con el mensaje "catálogo de fallos inicial" [09:24].

La idea central es dejar de ver la IA como un generador mágico de respuestas y empezar a verla como un motor que necesita supervisión, calibración y criterios claros [09:47]. Pasamos de preguntar qué dice la IA a preguntar cómo sabemos que lo que dice es cierto.

¿Ya te has encontrado con tests que pasan pero esconden un bug? Cuéntame en los comentarios cómo lo detectaste.