El estándar para aprobar trabajo hecho por IA

El ahorro que no aparece

La promesa era simple: la IA escribe más rápido, el equipo entrega más. El equipo de DORA (Google Cloud) analizó en marzo de 2026 lo que pasa en la práctica y le puso nombre: el impuesto de verificación. El tiempo que la IA ahorra al escribir se vuelve a gastar en auditar y verificar lo que generó.

Y no se reparte parejo. Quien escribe con IA va más rápido; quien revisa recibe más cambios, más largos y escritos por algo que no puede explicar sus decisiones. La carga se mueve a quien revisa, y en muchos equipos esa persona es QA.

Dos respuestas malas

Aprobar todo lo que pase el CI. Un pipeline verde no dice que los tests prueben algo. La IA es buena escribiendo tests que pasan, y un test que pasa sin validar nada es peor que no tenerlo: da confianza falsa.

Revisar todo a mano, línea por línea. Funciona una semana. Después el volumen gana, la revisión se vuelve superficial y el equipo termina en la primera respuesta sin admitirlo.

La respuesta de líder: bajar el impuesto con diseño

El impuesto no se elimina, se abarata:

• Cambios chicos. Un PR de 40 líneas se revisa en minutos; uno de 900, nunca de verdad.
• Evidencia en el PR. El trace de la corrida, la captura, el riesgo que cubre. Quien revisa no debería tener que reconstruir el contexto.
• Checks que fallan fuerte. Lint, tipos y una suite de humo que bloquean el merge sin discusión.
• Una firma con nombre. Todo lo generado con IA entra con el nombre de quien lo revisó.

Los 7 chequeos

Para cualquier test escrito o modificado con IA, antes del merge:

1. Rómpelo a propósito. Cambia el valor que el test dice proteger. Tiene que ponerse rojo.
2. Lee las aserciones, no el nombre. "Valida el pago" tiene que revisar monto, estado y comprobante.
3. Busca cada selector en la app real. La IA inventa identificadores que suenan perfectos y no existen.
4. Revisa los datos. Un RUT con K, un monto con decimales y un nombre con ñ encuentran bugs que "1234" nunca encuentra.
5. Caza las esperas fijas. Un tiempo de espera inventado hace que pase hoy y falle mañana.
6. Pide el riesgo en una frase. Si nadie puede decir qué bug evitaría el test, no entra.
7. Si se auto-reparó, lee el diff. Un selector o un valor esperado que cambió solo puede estar tapando un bug real.

El primero es el más poderoso: es mutation testing hecho a mano. En la prueba final de la Sesión 2 del laboratorio, la suite del candidato se corrige exactamente así: contra versiones de la tienda con errores introducidos a propósito.

El caso del "healer"

Playwright trae desde la versión 1.56 un agente llamado healer, que repara los tests que fallan. Es útil, y es justo el escenario del chequeo 7. Si el botón de pago desapareció y el healer apuntó el selector a otro elemento, la suite queda verde con el checkout roto.

La regla para el equipo: ninguna reparación automática entra sin que una persona lea el diff y entienda por qué falló el test original.

Lo que mides

Si el estándar funciona, dos cosas cambian en un mes: baja el tiempo promedio de revisión por PR (porque llegan más chicos y con evidencia) y no suben los defectos que escapan a producción. Si sube la velocidad y suben los defectos, el impuesto se está pagando con calidad.