La IA no sabe qué es un defecto
Un modelo encuentra diferencias, no defectos. La distancia entre las dos cosas es criterio, y es exactamente la parte que no se puede delegar.
Giancarlo Renato Palomino Huallpa
Quality Engineer · Lima, Perú
Uso modelos de lenguaje todos los días en trabajo de calidad. No escribo esto desde la desconfianza: lo escribo porque he visto de cerca en qué punto dejan de ayudar, y ese punto llega antes de lo que la gente espera.
La frase que lo resume: un modelo encuentra diferencias; un defecto lo declara una persona. Entre esas dos cosas hay una decisión que casi nunca está escrita en ningún requerimiento, y que es justamente por lo que te contratan.
El espejismo
Lo que hace peligrosa a la IA en testing no es que se equivoque. Es que produce algo que se parece mucho al trabajo terminado.
Pides casos de prueba y recibes treinta, bien redactados, con su precondición y su resultado esperado. Pides que compare dos respuestas y recibe una lista ordenada de diferencias. Pides tests automatizados y te llegan compilando. Todo tiene el aspecto de estar hecho.
El problema aparece cuando alguien pregunta qué riesgo cubre eso. Porque treinta casos correctos pueden dejar fuera el único flujo donde la plata se mueve, y una lista de diferencias impecable puede no contener ni un solo defecto.
Dónde sí compensa, con nombre y apellido
No es una nota en contra. Estos tres usos me ahorran horas reales todas las semanas, y los tres tienen algo en común: el modelo produce material de entrada, no conclusiones.
Dónde entra el modelo y dónde entra la persona
Un requerimiento de cuarenta páginas
Leerlo entero y sacar la lista de campos, tipos y reglas es trabajo mecánico. Ahí el modelo va cinco veces más rápido que yo.
Una lista de escenarios candidatos
Incluidos los aburridos que uno olvida: campo vacío, máximo, cero, negativo, caracteres raros. La cobertura de lo obvio sale barata.
Qué se prueba primero y qué no se prueba
Aquí entro yo. El riesgo no se deduce del texto: se deduce de saber qué se rompió el trimestre pasado y qué mira el negocio el día del cierre.
Un plan que alguien puede defender
Si me preguntan por qué ese orden, hay una respuesta. Esa respuesta nunca la escribió el modelo.
Los otros dos usos que sí valen: comparar dos estructuras grandes y señalar dónde difieren —con XML y JSON de cientos de campos, es puro ahorro de vista— y redactar el primer borrador de un caso o un reporte, que después reescribo.
Dónde delego en un modelo y dónde no
Los cuatro errores que he visto de cerca
Tomar la diferencia por el defecto. Es el más común y el que da nombre a esta nota. Certificando una migración de servicios, el modelo lista cincuenta diferencias entre el servicio legado y el migrado. No son cincuenta defectos: hay cambios acordados, decisiones que alguien tomó sin contarlas y, entre todo eso, los pocos que de verdad rompen algo. Clasificar esas tres categorías exige conocer acuerdos que no están escritos.
Aceptar tests que nunca han fallado. Un test generado que pasa a la primera no prueba nada todavía. Puede estar afirmando sobre un elemento que siempre existe, esperando un texto que nunca cambia, o capturando su propia excepción. La prueba de que una prueba sirve es verla fallar cuando el código está mal, y eso hay que provocarlo a mano.
Pedirle veredictos. «¿Esto está bien?» es la peor pregunta que se le puede hacer a un modelo: va a responder que sí con una seguridad notable, porque su trabajo es sonar coherente, no tener razón. «Lístame las diferencias» sí es una buena pregunta.
Pegar lo que no se puede pegar. Respuestas con datos de clientes reales, credenciales, identificadores internos. Aquí el criterio no es técnico sino de oficio: si no lo pondrías en una diapositiva para gente de fuera, no va a un prompt.
La misma lista, dos lecturas
Lo que devuelve el modelo
Tres diferencias
- fecha en formato distinto
- campo opcional que ahora llega como null
- lista vacía que cambió de forma
Lo que decide la persona
Un defecto y dos avisos
- acordada en diseño: se documenta y se cierra
- nadie la contó: defecto de comunicación
- rompe al consumidor: defecto real
Cómo lo trabajo hoy
Cuatro reglas, y ninguna es teórica: las cuatro salieron de que algo se me pasó.
- El modelo propone, nunca cierra. Ningún resultado suyo entra en un entregable sin que yo lo haya leído línea por línea. Si no tengo tiempo de revisarlo, no tengo tiempo de usarlo.
- Todo test generado se ve fallar antes de aceptarse. Rompo el código a propósito. Si la prueba sigue en verde, la prueba no existe.
- Las preguntas se hacen en forma de tarea, no de juicio. Extraer, comparar, listar, reescribir. Nunca «¿está bien?», «¿es un bug?», «¿puedo liberar?».
- Queda registrado dónde se usó. En el reporte digo qué parte salió de un modelo y qué validé yo. Cuando alguien cuestione un hallazgo dentro de seis meses, esa línea ahorra una discusión larga.
Lo que esto significa para quien empieza
Hay una lectura pesimista de todo esto: si la IA escribe los casos y los tests, ¿para qué hace falta un QA junior?
Yo la veo al revés, y con una condición. La parte mecánica del oficio —escribir el caso número cuarenta, comparar dos respuestas a ojo— se está abaratando rápido. La parte que sube de valor es la que nunca fue automatizable: entender el negocio lo suficiente como para saber qué merece atención.
La condición es incómoda: ese criterio se construye haciendo el trabajo mecánico durante un tiempo. Quien salta directo a pedirle todo a un modelo no está acelerando su aprendizaje, está saltándose la parte donde se aprende a distinguir. Y eso se nota en la primera reunión donde hay que defender una decisión.
En una entrevista nadie te va a pedir que generes treinta casos de prueba. Te van a poner un escenario ambiguo y ver qué priorizas. Ahí no hay prompt que te salve, y por eso sigue siendo el trabajo.