IA generativa en software: rápida, brillante… y peligrosamente engañosa si no la testeás bien

La IA generativa está de moda. Todos la usan, todos la muestran en demos, todos dicen que “aceleró el desarrollo un 300%”. A los infumables criptobros ahora se le sumaron los AIBros y...todo está lleno de bros. Eso ya está, es así y no hay vuelta que darle.

Perfecto. Ahora hablemos de lo que no aparece en esas presentaciones: calidad, riesgo y testing.

Porque sí, la IA puede escribir código, pruebas, documentación y hasta decisiones de arquitectura.

Y justamente ahí está el problema.

La IA simplifica cosas que ya son complejas.

Y cuando no entendés la complejidad, lo que viene después suele romperse.

El verdadero riesgo de usar IA en ingeniería (spoiler: no es la IA)

El problema no es que la IA “se equivoque”.

El problema es que falla de forma convincente.

Te da código que:

• compila

• pasa tests básicos

• “parece” correcto

…hasta que llega producción, carga real, usuarios reales y escenarios que nadie pensó.

Desde testing, esto cambia completamente el juego. Ya no alcanza con verificar que “funcione”. Hay que entender qué está asumiendo el modelo y qué quedó afuera. Es como tener a un tipo que es muy bueno escondiendo las cagadas que se manda con el código para entregar trabajo. Te das cuenta tarde y es un perno debuguear. Sobre todo...porque lo que fue un "confío en lo que me generó y vamo' pa' producción" ahora es un "tengo que hacer ingeniería inversa de cientos, miles de líneas de código para entender por qué hizo lo que hizo.

Yo he visto de primera mano a la IA delirar de lo lindo teniendo todos los datos y todo "en teoría bien" para funcionar como se esperaba. ¿Por qué deliraba? Bueno...medio que un misterio, una caja de pandora. ¿Imagínate llevar eso a Producción?

Problema 1: diseño opaco y decisiones que nadie sabe explicar

Hoy muchos equipos usan IA para:

• traducir requisitos de negocio a código

• generar historias de usuario

• crear diagramas y documentación

• estandarizar arquitectura

Todo muy lindo… hasta que nadie puede responder esta pregunta:

¿Por qué el sistema se comporta así?

Cuando la IA toma demasiadas decisiones juntas, perdés:

• trazabilidad

• contexto

• explicabilidad

Y sin eso, el testing se vuelve reactivo y tardío.

Mi postura

Si usás IA para diseñar:

• modularizá

• limitá el alcance

• hacé verificable cada salida

Cuanto más grande y mágica es la solución, más difícil es testearla.

Y ojo con algo clave:

el testing con usuarios reales no va al final. Si recién probás con personas en UAT, ya llegaste tarde.

Problema 2: sistemas multiagente que se rompen en silencio

Multiagente suena increíble en los diagramas.

En la práctica, introduce problemas muy poco glamorosos:

• desincronización

• errores que se propagan

• outputs inconsistentes

• costos de tokens que se van de control (AWS se relame viendo tu billetera llorar)

• bugs imposibles de reproducir

Un agente se equivoca → otro lo toma como verdad → el sistema entero se contamina.

Y después alguien dice: “pero la IA respondió algo razonable”.

Sí, razonable no es correcto.

Desde testing, esto implica otra cosa

Ya no alcanza con validar respuestas.

Hay que testear:

• flujo entre agentes

• manejo de fallos

• degradación bajo carga

• comportamiento cuando falta contexto

Por eso, cuando empecé a trabajar con validadores específicos para chatbots y LLMs, me vi en la obligación de crear True Lies Chatbot Validator: porque los asserts clásicos no alcanzan para sistemas probabilísticos.

Problema 3: código generado rápido… pero ¿correcto?

La IA escribe código a una velocidad absurda.

El problema es que nadie te garantiza que ese código sea bueno.

Los números son claros:

• cuanto más complejo el prompt, peor el resultado

• los juniors confían más de lo que deberían

• los errores no siempre son obvios

El código pasa… hasta que no pasa.

Qué cambia en la revisión de código

La revisión ya no es solo “¿esto compila?”

Ahora es:

• ¿entiendo lo que hace?

• ¿es mantenible?

• ¿está simplificando algo que no debería?

• ¿qué pasa bajo estrés?

El humano en el loop no es opcional.

Es el nuevo estándar.

Y ojo...no tengo dudas que en un futuro (quizás no tan lejano), este loop de "especificaciones a código, código a Pull Request, Revisión de PRs agéntica, despliegues con agentes y testing" puede que sea hecho 99% por IAs, pero...de momento no y tenemos que parar a pensar si realmente queremos eso. Como dijo Ian Malcolm en Jurassic Park:

Sus científicos developers/testers estaban tan preocupados por si podían o no, que no se detuvieron a pensar si debían hacerlo.

Problema 4: cuando la IA genera código demasiado simple… o demasiado complejo

Dos extremos igual de peligrosos:

1. Código inflado, largo, con deuda técnica invisible

2. Código “limpio” que falla cuando la realidad aparece

La IA es mala lidiando con lo desconocido.

Y el mundo real está lleno de casos que nadie documentó.

Si tus tests solo cubren el happy path, la IA te va a mentir… educadamente.

Entonces, ¿qué hacemos con todo esto?

No, no se trata de “no usar IA”.

Se trata de usarla con criterio técnico y mentalidad de tester.

Para mí, los equipos que la van a usar bien son los que:

• testean temprano

• definen límites claros

• miden calidad, no hype

• entienden que la IA no reemplaza responsabilidad humana

Y sobre todo, los que entienden que testear sistemas con IA es una disciplina nueva, no un checkbox más.

Si querés meterte en serio en este tema:

• armé una librería como True Lies Chatbot Validator porque los asserts clásicos no alcanzan. Si pasás por PyPi y le dan un poco de amor (y GitHub), ¡te agradezco mil!

• y un curso como AI a fondo para Testers porque nadie nos enseñó a testear modelos probabilísticos, pero ahora yo tomé esa posta después de años aplicando esto en trabajos reales, clientes reales y proyectos que cambiaron (quiero creer), Nueva Zelanda para bien.