Cómo validar código generado por IA: checklist práctico antes de mergear
El código generado por LLMs puede parecer impecable a primera vista. Compila, pasa el linter, tiene nombres descriptivos. Y aun así rompe producción tres días después.
El problema no es la IA — es que la mayoría de los flujos de revisión no están calibrados para el tipo de errores que cometen los LLMs. Este checklist cierra esa brecha. No es teoría: es lo que hay que verificar antes de aprobar un PR con código generado.
1. Tests pasando — y tests con sentido
Lo primero es obvio: los tests tienen que pasar. Pero hay una capa más importante: ¿los tests que pasan realmente cubren el comportamiento crítico?
Los LLMs tienen tendencia a generar tests que validan el happy path y nada más. O peor: a escribir tests que "pasan" porque están mal escritos (aserciones vacías, mocks que no verifican lo que deberían).
Qué verificar:
- ¿Hay tests para los edge cases del negocio, no solo para el flujo feliz?
- ¿Las aserciones verifican el valor real o solo que algo no lanzó excepción?
- ¿Los mocks están configurados correctamente o simplemente "no explotan"?
Si los tests parecen superficiales, es una señal de alerta — no de que el código esté bien.
2. Edge cases pensados
El LLM genera código para el caso que describiste. No necesariamente para los casos que no describiste.
Antes de mergear, pensá activamente en los límites:
- ¿Qué pasa con inputs vacíos, nulos o de longitud cero?
- ¿Qué pasa con valores extremos (números muy grandes, strings muy largos)?
- ¿Qué pasa si una dependencia externa falla o devuelve un formato inesperado?
- ¿Qué pasa con concurrencia si el código puede ejecutarse en paralelo?
No alcanza con que el código "se vea robusto". Hay que pensar explícitamente en los casos límite y verificar que estén manejados.
3. Coherencia con el resto del repo
El LLM no conoce tu codebase. Genera código correcto en abstracto, pero puede ser inconsistente con las convenciones, patrones y abstracciones que ya existen.
Qué verificar:
- ¿Usa las mismas abstracciones que el resto del código (repositorios, servicios, helpers)?
- ¿Sigue las convenciones de naming del proyecto?
- ¿Duplica lógica que ya existe en otro lugar?
- ¿Introduce una dependencia nueva que ya tenías resuelta de otra forma?
Un PR que funciona pero es incoherente con el repo es deuda técnica desde el día uno.
4. Seguridad: los tres que más matan
Los LLMs pueden introducir vulnerabilidades de seguridad sin ninguna advertencia. No porque sean descuidados — sino porque optimizan para código que funciona, no para código que resiste ataques.
Los tres más comunes en código generado:
SQL injection: si el código construye queries con interpolación de strings en lugar de parámetros preparados. El LLM a veces lo hace cuando el ORM no está en el contexto o cuando el prompt describe la query directamente.
XSS (Cross-Site Scripting): si el código renderiza contenido de usuario en el DOM sin sanitizar, o usa innerHTML donde debería usar textContent.
Secrets en código: el LLM puede hardcodear valores de ejemplo que parecen placeholders pero en realidad son tokens reales que copiaste en el prompt. Revisá el diff buscando strings que parezcan claves, tokens o contraseñas.
En cualquiera de estos casos: no mergear hasta corregir.
5. Performance plausible
El LLM puede generar código correcto que es algorítmicamente ineficiente. No siempre importa, pero en paths críticos sí.
Qué verificar:
- ¿Hay bucles O(n²) donde el volumen de datos haría eso inaceptable?
- ¿Hay llamadas a base de datos o APIs dentro de un loop que deberían ser una sola llamada en lote?
- ¿Se están cargando estructuras de datos grandes completas cuando solo se necesita una parte?
No hace falta micro-optimizar todo. Pero sí identificar si hay algo que va a explotar con datos reales.
6. Manejo de errores explícito
El código generado por LLMs tiende a manejar el happy path muy bien y a dejar el manejo de errores vago o incompleto.
Señales de alerta:
catch (e) {}vacío o con solo unconsole.log.- Errores que se silencian en lugar de propagarse o manejarse.
- Falta de validación en los inputs antes de procesarlos.
- Ausencia de timeouts en llamadas a servicios externos.
Un error silenciado en producción puede tardar días en detectarse. Verificá que cada punto de fallo tenga una respuesta explícita.
El checklist resumido
Antes de aprobar cualquier PR con código generado por IA:
- Tests pasando — y con aserciones reales sobre comportamiento
- Edge cases pensados: nulos, vacíos, extremos, concurrencia
- Coherente con las abstracciones y convenciones del repo
- Sin SQL injection, XSS, ni secrets hardcodeados
- Performance aceptable para el volumen real de datos
- Manejo de errores explícito en todos los puntos de falla
Una nota sobre la confianza
Este checklist no existe porque la IA sea mala generando código. Existe porque el flujo de revisión para código humano no siempre captura los errores específicos que cometen los LLMs.
Con el tiempo, vas a desarrollar un ojo para los patrones de error más comunes en el código generado por tu modelo favorito. Hasta entonces, el checklist es la red de seguridad que hace que el proceso sea repetible y confiable.