En numerosas conversaciones con equipos de desarrollo, emerge un problema común: los ingenieros más talentosos y comprometidos con la calidad del código se ven sobrepasados por listas interminables de revisiones, que no solo no disfrutan, sino que tampoco pueden mantener al día. Algunos profesionales experimentados llegan incluso a rechazar explícitamente revisar código generado por inteligencia artificial (IA), lo que refleja una resistencia directa hacia ese tipo de tareas.
Gestiono una comunidad de ingenieros senior y líderes técnicos, donde la evaluación de código generado por IA aparece recurrentemente como una de las principales preocupaciones. Según un estudio reciente, el 77% de los ingenieros afirma dedicar menos tiempo a escribir código manualmente, destinando esa capacidad principalmente a revisar el output producido por herramientas de IA.
El cambio en el rol de los ingenieros: de crear a verificar
En los equipos con una alta adopción de tecnologías de inteligencia artificial, se ha observado un incremento del 98% en la cantidad de solicitudes de incorporación de código (pull requests o PRs) y un aumento del 91% en los tiempos de revisión. Muchos ingenieros no firmaron para pasar su jornada analizando líneas generadas por máquinas, pero esa se ha convertido en la demanda actual de la labor. 
Los profesionales que más sufren esta situación no son aquellos que rechazan la IA, sino precisamente quienes la adoptaron primero y con más entusiasmo, y que además han establecido la cultura de revisión que sostiene a sus equipos. Estas personas suelen tener una cola diaria de 15 PRs, cada uno con 400 líneas de código, para revisar.
¿Por qué es más complicado revisar código generado por IA?
Cuando un colega escribe código, su intención se transmite durante el proceso de revisión. Puede explicar las razones detrás de sus decisiones, los trade-offs contemplados y las alternativas descartadas. Este contexto, aunque no siempre esté explícito, es accesible y ayuda a evaluar el código en profundidad.
«Cuando el código lo escribe la IA, esa lógica desaparece. El revisor debe deducir la intención a partir de un simple diff.»
Con el código generado por IA, el razonamiento original no está disponible. El revisor se ve obligado a inferir cuál era el propósito del código solo con base en las diferencias mostradas, una tarea cognitiva muy distinta y más ardua. Además, el código producido por IA suele superar el «test visual», parece correcto a primera vista.
Cinco tipos de errores comunes en código de IA
1. Plausible pero incorrecto. El código parece coherente y funciona en situaciones estándar, pero falla en casos extremos debido a supuestos erróneos difíciles de detectar en la revisión.
2. Sobre-ingeniería. La IA crea soluciones complejas y extensas para problemas que podrían resolverse con unas pocas líneas, basándose en patrones extensos de código empresarial que no aplican al caso.
3. Ignorancia de convenciones. La IA genera código genérico y no adapta el estilo a las normas específicas del proyecto, como nombres, manejo de errores o límites de módulos.
4. Alucinaciones confiadas. Incluye llamadas a APIs inexistentes, usa métodos obsoletos o inventa opciones de configuración, a veces detectadas durante la revisión, otras solo en producción.
5. Patrones imitativos sin comprensión. Copia estructuras sin entender su finalidad, como lógicas de reintento inexistentes o manejo de errores superficial sin relación real con posibles fallos.
El denominador común es que este código parece válido, lo que dificulta enormemente su revisión a gran escala.
Cómo mejorar el proceso de revisión de código
La solución no es simplemente «revisar más duro» ni confiar en que otra IA evalúe el código, pues al usar el mismo modelo para escribir y revisar, se reproducen los mismos errores y limitaciones. Tampoco ayudan los flujos de trabajo en los que múltiples agentes de IA se revisan entre sí, que acaban convirtiendo a los ingenieros en gestores de bots en lugar de desarrolladores.
Lo efectivo es aliviar la carga del revisor en tres puntos clave: codificar las correcciones repetitivas, conservar la intención que originó el código y medir el trabajo que realmente evita la generación de código deficiente.
Crear un registro de errores habituales de la IA
Una manera práctica consiste en analizar los últimos 100 comentarios de revisión del equipo. Cada observación debe clasificarse en una categoría: determinista (algo que se puede verificar con reglas automáticas), verificable por ejecución (detectable al probar el código) o juicio subjetivo genuino.
De media, este análisis revela que el 45% de los comentarios son deterministas, 30% verificables por pruebas y solo el 25% requiere discreción humana. Así, tres cuartas partes del feedback pueden automatizarse.
«Tres cuartas partes de los comentarios repetidos pueden formalizarse como invariantes, reglas que si se cumplen, no necesitarán revisión manual futura.»
Por ejemplo, casos como «los nuevos endpoints deben incluir span de Open Telemetry» no son decisiones subjetivas sino reglas concretas que pueden implementarse como chequeos automáticos, evitando comentarios constantes y ahorrando tiempo valioso.
Conservar la cadena de razonamiento
Las solicitudes y conversaciones que dieron lugar a la generación del código contienen la intención original, pero la mayoría de los equipos las descartan. Esto es comparable a eliminar los mensajes de commit o las descripciones de las PRs y esperar que los revisores deduzcan el propósito solo por el código.
Por ello, herramientas como Verify de Aviator almacenan ese razonamiento estructurándolo en criterios de aceptación: qué hace el cambio, qué queda fuera del alcance y cómo validar que funciona. Así, las decisiones arquitectónicas, los límites y compensaciones entran en el proceso de revisión, permitiendo al revisor centrarse en problemas relevantes en lugar de analizar cientos de líneas.
Fomentar el intercambio de conocimiento
Cuando los revisores leen especificaciones y criterios de aceptación, en realidad están evaluando decisiones y negociaciones técnicas, comprendiendo la evolución del sistema y entendiendo las restricciones. Esta dinámica genera el verdadero intercambio de conocimiento, clave para equipos exitosos. Si se adelanta la revisión del código, el intercambio de conocimiento también debe adelantarse.
Métricas y reconocimiento al trabajo de verificación
En la actualidad, un 31% más de PRs se integran sin revisión alguna, una clara señal de los ingenieros sobre la insatisfacción con el proceso. Los dashboards que solo miden líneas de código generadas o PRs mergeados no reflejan el esfuerzo de los ingenieros senior que soportan la carga de las revisiones y construyen sistemas para evitar errores.
Annie Vella, que ha rastreado esta evolución en 158 ingenieros de 28 países, observa que muchos están abandonando sus roles, algunos con la esperanza de volver a trabajos más creativos, otros definitivamente dejando la profesión, debido a que el desplazamiento hacia tareas de verificación les ha privado del trabajo por el que se apasionaban.
«Esos dashboards muestran el throughput, pero no al ingeniero senior que pasa la tarde deduciendo la intención tras un diff de 400 líneas. El throughput parece excelente hasta que los que soportan la carga de revisión se marchan.»
Estos profesionales no suelen quejarse abiertamente; simplemente se van. Algunos buscan equipos con mejores herramientas, otros abandonan la ingeniería. Esto no ocurre por falta de capacidad para adaptarse, sino porque la naturaleza del trabajo ha cambiado y ya no se asemeja a lo que esperaban.
Los líderes que persiguen métricas como líneas de código o PRs completados corren el riesgo de desconocer esta crisis hasta que es demasiado tarde. El cambio urgente es reformar el proceso de revisión de código: automatizar lo repetitivo, conservar la intención y valorar el trabajo preventivo para evitar errores. De lo contrario, el equipo más valioso continuará abandonando la compañía y a pesar de la aceleración en entregas impulsada por IA, los errores y problemas aumentarán.
