El código generado por IA también necesita pasar una revisión de producción
Un asistente de IA genera en minutos un endpoint para actualizar el perfil de un usuario, una consulta para filtrar datos o un consumidor de eventos para una cola. El cambio compila, las pruebas locales pasan y el diff parece razonable. Sin embargo, al llegar a producción puede aparecer un problema menos visible: el endpoint permite modificar recursos ajenos, una excepción expone información interna, una dependencia incorpora riesgo operativo o el servicio deja de emitir las métricas necesarias para investigar un incidente.
La IA puede acelerar la creación y modificación de código, pero no asume la responsabilidad técnica del cambio. Esa responsabilidad sigue siendo del desarrollador, del revisor y del equipo que opera el sistema. La revisión de producción del código generado por IA no consiste en desconfiar de toda sugerencia: consiste en aplicar controles explícitos para comprobar que el cambio funciona dentro de los límites funcionales, de seguridad y operativos del sistema.
Esta guía propone un enfoque práctico para revisar código generado o modificado con IA antes de integrarlo en una rama principal o desplegarlo en producción.
La velocidad de generación no valida el cambio
Un modelo puede producir código sintácticamente correcto y coherente con una instrucción, pero normalmente no conoce todos los acuerdos implícitos de un repositorio: reglas de autorización, convenciones de errores, requisitos regulatorios, límites de rendimiento, contratos entre servicios, estrategia de observabilidad o comportamiento ante fallos parciales.
El problema no es exclusivo de la IA. Un cambio escrito manualmente también puede introducir regresiones. La diferencia es que la generación rápida reduce la fricción para producir más código y, por tanto, puede hacer que el equipo acepte cambios que no ha comprendido completamente.
Conviene separar dos preguntas que a menudo se confunden:
- ¿El código hace lo que parece hacer? Es una validación funcional y técnica del fragmento.
- ¿El cambio es seguro y operable en este sistema? Requiere conocer el dominio, la arquitectura, los datos y la operación de producción.
Un asistente puede proponer una implementación de paginación para una API, pero no sabe por defecto si el sistema necesita paginación por cursor para evitar inconsistencias, si ciertos campos son sensibles, si existe un límite de consumo de base de datos o si la respuesta forma parte de un contrato público. La revisión humana debe cubrir ese contexto.
Revisar primero los supuestos y el alcance funcional
Antes de analizar detalles de estilo o sintaxis, conviene identificar qué supuestos introdujo el código. La IA suele completar ambigüedades con decisiones plausibles, pero plausibilidad no equivale a una decisión válida para el producto.
Preguntas para validar el comportamiento
- ¿Cuál es el requisito exacto y qué casos de uso cubre el cambio?
- ¿Qué ocurre con entradas vacías, nulas, duplicadas, incompletas o fuera de rango?
- ¿Se preservan las reglas de negocio existentes?
- ¿El cambio modifica un contrato de API, un esquema de evento o una estructura persistida?
- ¿Existen efectos secundarios, como enviar notificaciones, facturar, publicar eventos o invalidar cachés?
- ¿La operación debe ser idempotente ante reintentos?
La idempotencia merece especial atención en APIs y arquitecturas event-driven. Una implementación puede parecer correcta en una ejecución única y fallar cuando un cliente reintenta una petición por timeout o cuando un consumidor recibe el mismo mensaje más de una vez.
Por ejemplo, si un endpoint crea una orden y publica un evento, no basta con revisar que ambas operaciones se ejecuten. Hay que entender qué sucede si la orden se guarda, pero la publicación falla; o si el cliente repite la solicitud mientras no ha recibido respuesta. Dependiendo de la arquitectura, puede ser necesario usar claves de idempotencia, una estrategia transaccional adecuada o un patrón como transactional outbox. No son requisitos universales, pero sí decisiones que no deberían quedar implícitas en código generado.
Seguridad: comprobar autorización, datos y límites de confianza
La seguridad no se resuelve porque el código use un framework conocido o porque incluya una validación superficial. El revisor debe identificar los límites de confianza: dónde entra información controlada por usuarios, otros servicios, proveedores externos o mensajes de una cola, y qué decisiones sensibles se toman a partir de ella.
Autenticación no es autorización
Un error frecuente es validar que existe un usuario autenticado, pero no verificar si puede operar sobre el recurso solicitado. El siguiente ejemplo ilustra un patrón incompleto en un endpoint de actualización:
async updateProject(projectId, userId, input) {
const project = await this.projectRepository.findById(projectId);
if (!project) {
throw new NotFoundException('Proyecto no encontrado');
}
return this.projectRepository.update(projectId, input);
}El método recibe el identificador del usuario, pero no lo utiliza para verificar propiedad, pertenencia a una organización o permisos. El código puede funcionar en pruebas básicas y, aun así, permitir una escalada horizontal de privilegios si un usuario cambia el identificador del proyecto en la solicitud.
La corrección concreta depende del modelo de autorización del sistema. Puede requerir comparar el propietario, consultar membresías, evaluar roles o aplicar una política centralizada. Lo importante es revisar explícitamente la regla de acceso, no asumir que la autenticación ya la cubre.
Lista de comprobación de seguridad
- Validar y normalizar datos de entrada en el límite de la aplicación.
- Aplicar autorización sobre el recurso y la acción, no solo sobre la identidad del usuario.
- Evitar construir consultas, comandos de sistema, rutas de archivos o expresiones dinámicas a partir de entradas no confiables.
- Confirmar que secretos, tokens, datos personales y credenciales no se escriben en logs, respuestas o mensajes de error.
- Revisar límites de tamaño, paginación, rate limiting y costos potenciales de operaciones expuestas.
- Verificar que la serialización de respuestas no incluya campos internos o sensibles.
También es importante revisar las sugerencias de nuevas dependencias. Añadir una biblioteca para resolver un problema pequeño puede ampliar la superficie de mantenimiento, incorporar código no necesario o generar conflictos con políticas de licencias y seguridad. Antes de aceptarla, conviene comprobar si el proyecto ya tiene una utilidad equivalente o si la funcionalidad puede resolverse con componentes existentes.
Manejo de errores y consistencia ante fallos parciales
El código generado por IA suele manejar el camino feliz con fluidez. La revisión de producción debe concentrarse en lo que ocurre cuando un recurso no existe, una base de datos no responde, un servicio externo devuelve un error, un mensaje llega duplicado o una operación termina a medias.
Capturar una excepción genérica y devolver un resultado exitoso, reintentar sin límites o ignorar un fallo para “no bloquear el flujo” son decisiones que pueden convertir un error transitorio en inconsistencia de datos.
Qué revisar en los errores
- ¿Se diferencian errores de validación, ausencia de recurso, conflicto de negocio y fallo inesperado?
- ¿Las excepciones se traducen al contrato de error definido por la API o el servicio?
- ¿Se preserva la causa original para diagnóstico sin exponer detalles internos al cliente?
- ¿Los reintentos tienen límites, backoff y condiciones claras para evitar amplificar una caída?
- ¿Una operación distribuida puede dejar datos en estados intermedios?
- ¿Los consumidores de eventos pueden procesar mensajes inválidos, duplicados o fuera de orden?
En procesos asíncronos, reenviar indefinidamente un mensaje que siempre falla puede saturar el sistema y ocultar el problema real. Según la plataforma y el caso de uso, puede ser preferible definir un número acotado de reintentos, registrar el contexto necesario y desviar el mensaje para investigación. La política concreta debe responder a la criticidad del flujo y a las garantías del sistema de mensajería.
La revisión también debe detectar bloques catch que silencian excepciones. Si el fallo es tolerable, el código debe expresar qué consecuencia se acepta y cómo se observará. Si no lo es, el error debe propagarse o activar el mecanismo de recuperación correspondiente.
Observabilidad: si falla en producción, el equipo debe poder entender por qué
Un cambio listo para producción no solo ejecuta su lógica: deja evidencia suficiente para operar y diagnosticar el comportamiento sin convertir los logs en un repositorio de datos sensibles.
La observabilidad debe ajustarse al tipo de componente. Un endpoint de API puede requerir métricas de latencia, tasa de errores y volumen. Un consumidor de eventos puede necesitar información sobre procesamientos fallidos, reintentos y antigüedad de mensajes. Una tarea programada puede requerir saber cuándo fue su última ejecución correcta y cuánto tardó.
Señales operativas que conviene evaluar
- Logs estructurados: deben incluir contexto útil, como identificador de correlación, operación y resultado, evitando secretos y datos personales innecesarios.
- Métricas: permiten detectar aumentos de errores, latencia, consumo de recursos, colas acumuladas o resultados de negocio relevantes.
- Trazas distribuidas: son especialmente útiles cuando una petición atraviesa varios servicios, colas o proveedores externos.
- Alertas: deben responder a condiciones accionables; una alerta sin responsable o procedimiento de respuesta agrega ruido.
No todo método necesita instrumentación propia. Agregar métricas a cada línea de código puede generar ruido y costo operativo. La decisión útil es identificar operaciones críticas, puntos de integración, caminos de error relevantes y procesos con riesgo de degradación silenciosa.
Si la IA propone registrar el cuerpo completo de una petición para depurar un problema, la revisión debe cuestionarlo. Puede ser útil en desarrollo controlado, pero en producción podría registrar contraseñas, tokens, documentos o información personal. La necesidad de diagnóstico debe equilibrarse con minimización de datos y políticas de retención.
Pruebas y validación en el pipeline de entrega
Las pruebas no certifican que un cambio esté libre de defectos, pero reducen la probabilidad de integrar comportamientos no deseados. Para código generado por IA, su valor aumenta porque obligan a convertir supuestos implícitos en casos verificables.
Una buena pregunta durante la revisión es: ¿qué prueba fallaría si esta implementación interpretó mal el requisito? Si no existe una respuesta, probablemente el cambio no está suficientemente especificado o cubierto.
Capas de validación recomendables
- Pruebas unitarias: verifican reglas de negocio, transformaciones, validaciones y casos límite de forma rápida.
- Pruebas de integración: validan la interacción real con base de datos, colas, cachés, serialización o adaptadores externos controlados.
- Pruebas de contrato: ayudan a proteger APIs y eventos compartidos entre equipos o servicios.
- Análisis estático y revisión de dependencias: pueden detectar errores de calidad, vulnerabilidades conocidas o configuraciones inseguras, según las herramientas adoptadas por el equipo.
- Validación de despliegue: comprueba que variables de entorno, permisos, migraciones y configuración de infraestructura sean compatibles con el cambio.
No todas las modificaciones justifican una prueba end-to-end completa. Estas pruebas suelen ser más lentas y frágiles. En cambio, un cambio que modifica un flujo crítico de autenticación, pago, persistencia o integración externa puede requerir una validación más amplia que una prueba unitaria aislada.
Cuando la IA genera pruebas, también hay que revisarlas. Una prueba puede limitarse a confirmar que un mock fue invocado, sin validar el resultado relevante. Otra puede repetir la implementación internamente y fallar o pasar por los mismos motivos que el código productivo. Las pruebas útiles expresan comportamiento observable y casos de negocio, no solo detalles de implementación.
Mantenibilidad y dependencias: el código también será leído y modificado
Un cambio puede ser correcto hoy y costoso mañana si introduce duplicación, mezcla responsabilidades, oculta reglas de negocio en capas incorrectas o ignora convenciones del repositorio. La IA tiende a producir soluciones localmente razonables; el equipo debe evaluar su encaje global.
Durante la revisión, conviene comprobar si el código respeta los límites arquitectónicos existentes. Por ejemplo, un controlador HTTP no debería concentrar reglas complejas de negocio, acceso directo a múltiples repositorios, llamadas a terceros y lógica de transformación de errores si el sistema ya cuenta con capas o casos de uso para separar esas responsabilidades.
Señales de que el cambio necesita simplificarse
- Se agregó una abstracción nueva para resolver un caso único y sencillo.
- La misma regla aparece replicada en varios endpoints o consumidores.
- Los nombres son genéricos y no expresan una intención de dominio clara.
- El método combina validación, autorización, persistencia, publicación de eventos y formateo de respuesta sin una estructura comprensible.
- Se introdujo una dependencia sin justificar su necesidad ni su mantenimiento futuro.
- El cambio modifica archivos ajenos al objetivo sin una razón verificable.
La mantenibilidad no implica fragmentar todo en clases pequeñas ni aplicar patrones por defecto. Una solución simple y directa puede ser la mejor opción para una regla estable y acotada. El criterio es que otro integrante del equipo pueda entender qué hace el cambio, por qué existe y cómo modificarlo sin depender de reconstruir la conversación que originó el prompt.
Convertir la revisión de IA en un control repetible del equipo
El enfoque más sostenible no es pedir a cada persona que “tenga más cuidado” al usar IA. Es incorporar criterios de production readiness en los mecanismos habituales del equipo: definición de terminado, plantilla de pull request, revisión de código, pipeline de CI/CD y prácticas de despliegue.
Una plantilla de revisión puede incluir preguntas breves como las siguientes:
- ¿Qué requisito de negocio cambia y qué supuestos se validaron?
- ¿Qué controles de autorización y validación aplican?
- ¿Qué ocurre ante fallos parciales, reintentos o duplicados?
- ¿Qué pruebas cubren el camino principal y los casos de error relevantes?
- ¿Qué señal permitirá detectar una regresión en producción?
- ¿Se añadieron o actualizaron dependencias, configuraciones, permisos o migraciones?
- ¿Existe un plan de rollback o una estrategia de despliegue gradual si el riesgo lo justifica?
La profundidad de esta revisión debe ser proporcional al riesgo. Corregir un texto interno no requiere el mismo nivel de validación que cambiar la autorización de una API, una migración de datos o un consumidor que afecta facturación. Clasificar cambios por impacto ayuda a evitar tanto la burocracia innecesaria como la falta de control en modificaciones sensibles.
Los equipos que desarrollan capacidades de AI Software Engineering obtienen más valor cuando combinan asistentes de IA con arquitectura clara, pruebas confiables, automatización de calidad y revisiones que consideran la operación real. La IA acelera la implementación; el SDLC maduro reduce la probabilidad de que esa velocidad introduzca deuda o incidentes evitables.
Conclusión: integrar más rápido exige decidir con más claridad
El código generado por IA puede ahorrar tiempo en tareas repetitivas, exploración de alternativas, refactors acotados y creación de borradores. Pero un código que compila no está necesariamente preparado para producción. Antes de integrar un cambio, el equipo debe validar sus supuestos, controles de seguridad, comportamiento ante errores, observabilidad, pruebas, dependencias y mantenibilidad.
El siguiente paso práctico es transformar esta lista en una guía breve para pull requests y aplicarla primero a los cambios de mayor riesgo. Con el tiempo, parte de esos controles puede automatizarse en el pipeline, mientras que las decisiones de dominio, arquitectura y riesgo permanecen bajo responsabilidad técnica del equipo.
Usa IA para acelerar el desarrollo, pero define controles explícitos antes de llevar cambios a producción.
