Integraste un agente de IA para revisar código en tu pipeline y funcionó. Marcó una comprobación de null que faltaba, detectó un import sin usar y dejó tres comentarios bien ordenados sobre nomenclatura. Hiciste el merge. Dos días después, un cliente se topó con un bug que el agente había pasado por alto: el cambio era impecable por dentro, pero hacía lo incorrecto. El agente de revisión verificó el código. No pudo verificar la intención.
Esa brecha es toda la historia de los agentes de IA para revisar código. Son buenos con un tipo concreto de problemas que se pueden comprobar y son ciegos ante otro tipo que, en un diff, parece idéntico. Si tomas su aprobación como aceptación, acabarás enviando a producción ese segundo tipo. Si sabes dónde está la línea, consigues una primera pasada rápida que libera a tus revisores para el juicio que solo las personas pueden aportar.
Este artículo traza esa línea: qué puede verificar un agente de IA para revisar código, qué no puede y el modelo operativo que mantiene ambos lados en orden. Sharkly es la capa que recorreremos, el espacio de trabajo compartido donde la revisión del agente y la aceptación humana son dos estados distintos de una misma Task, y no un único sello de aprobación. Ya tienes agentes de programación; de lo que se trata aquí es de revisar su resultado sin fingir que un segundo agente cierra el ciclo.
Qué puede verificar un agente de IA para revisar código
Un agente de IA para revisar código es un programa que lee un diff, ejecuta comprobaciones sobre él y reporta hallazgos igual que un revisor humano deja comentarios. Su zona fiable abarca todo aquello que un revisor cuidadoso podría confirmar leyendo el cambio y su entorno inmediato:
- Corrección mecánica: sintaxis, tipos, manejo evidente de null y de límites, promesas rechazadas sin gestionar, fugas de recursos visibles en el diff.
- Lógica local: errores off-by-one, condiciones invertidas, ramas muertas, una variable leída antes de asignarle un valor.
- Convenciones: nomenclatura, formato, higiene de imports, si una función nueva tiene una prueba al lado.
- Antipatrones conocidos: SQL construido por concatenación de cadenas, secretos incluidos en texto plano, un método público sin validación de entrada.
Todos comparten un rasgo: la evidencia está dentro del diff. El agente no necesita conocer tu negocio para detectarlos, y lo hace más rápido y de forma más consistente que una persona cansada a las seis de la tarde. Eso es valor real, y es la razón por la que los equipos recurren a estas herramientas. La guía de revisión de código de Google considera esta pasada mecánica como el mínimo indispensable para que la atención humana pueda centrarse en el diseño. Un revisor de IA es una forma paciente de superar esa pasada siempre.
Qué no puede verificar
Aquí está la frontera, dicha sin rodeos: un agente de IA para revisar código no puede verificar que el cambio sea el cambio correcto. Todo lo que sigue necesita un contexto que el diff no contiene.
- Intención frente a especificación. El código puede ser impecable y resolver el problema equivocado. Solo los criterios de aceptación del ticket lo determinan, y el agente rara vez los tiene a la vista.
- Corrección de negocio. Que una regla de descuento, un cálculo de impuestos o un límite de permisos se ajuste a cómo funciona la empresa es una cuestión de criterio, no una regla de lint.
- Comportamiento entre sistemas. Un cambio que se lee bien en un archivo puede romper a un consumidor que está a tres servicios de distancia. El Top Ten de OWASP está lleno de fallos como el control de acceso roto, que solo aparecen cuando sigues toda la ruta de la petición, no el diff.
- Si las pruebas son honestas. Un agente puede confirmar que una prueba existe y pasa. No puede decirte que la prueba verifique lo que de verdad importa, ni que el agente que escribió el código escribió también una prueba hecha a medida para pasar.
Ese último punto es la trampa propia del código escrito por IA. Cuando la misma clase de sistema produce el cambio y la revisión, un diff limpio y una marca verde pueden ser ambos ciertos y, a la vez, irrelevantes. Por eso, la aprobación de un agente de revisión es una señal, no una decisión. El agente informa; una persona acepta.
El modelo operativo que cubre la brecha
La solución no es un agente de revisión mejor. Es un modelo operativo en el que la tarea del agente de revisión y la de la persona son estados distintos, y ninguno de los dos se omite.
Sharkly hace explícitos esos estados a través de los estados de Task. Una Task pasa por In progress, Ready for review y Done. La regla es sencilla y fundamental: los agentes mueven el trabajo a Ready for review; las personas lo mueven a Done. Un agente, ya sea el que escribió el código o el que lo revisó, nunca puede marcar su propio trabajo como aceptado. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, otorgan autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo.
Cada rol tiene una única función. El Agente de programación produce el cambio. El Agente de revisión ejecuta la pasada mecánica y adjunta sus hallazgos. La persona revisora lee esos hallazgos, contrasta el cambio con la intención del ticket y decide. Todo vuelve a la Task: el diff, los comentarios del Agente de revisión, la salida de las pruebas y la decisión humana viven en una sola línea temporal, en lugar de estar dispersos entre un PR, un chat y la memoria de alguien.
Usa un agente de revisión como primera barrera cuando el cambio sea mecánico y autocontenido —una refactorización, una actualización de dependencias, una corrección de bug bien acotada—; deja que elimine el ruido para que la pasada humana sea rápida. No te apoyes en él como única barrera cuando el cambio afecte al dinero, a la autenticación, a migraciones de datos o a contratos públicos; ahí la persona lee primero y la pasada del agente es una lista de comprobación, no un veredicto.
Un ejemplo práctico: del ticket al PR fusionado
Tomemos SH-312: «Rechazar los cupones caducados al finalizar la compra». Una persona escribe los criterios de aceptación y asigna la Task. Un Agente de programación la toma, trabaja en un worktree aislado y devuelve a la Task un diff junto con una prueba que pasa, moviéndola a Ready for review.
Ahora se ejecuta el Agente de revisión. Confirma los tipos, señala una comprobación de null que falta y observa que la prueba cubre el caso de caducidad. Pasada limpia. Con la vieja costumbre, esa aprobación se fusiona.
En su lugar, la persona revisora abre la Task y lee contrastando con la intención. El código rechaza los cupones caducados, exactamente como está escrito. Pero los criterios de aceptación también daban a entender que debían rechazarse los cupones ya canjeados, y ni el Agente de programación ni el Agente de revisión lo sabían, porque eso vive en la cabeza del revisor y en la especificación del producto, no en el diff. El revisor solicita un cambio. SH-312 vuelve a In progress con una nota concreta, el Agente la amplía y solo entonces una persona la mueve a Done y fusiona el pull request.
El agente de revisión hizo bien su trabajo y, aun así, habría dejado pasar una brecha. El modelo operativo la detectó, porque la aceptación fue un acto separado realizado por una persona con el contexto. Esa es la misma disciplina que hay detrás de revisar código generado por IA con evidencia a nivel de Task: la unidad de revisión es la Task y su intención, no el diff aislado.
Dónde colocar tus barreras de revisión
La pregunta práctica no es si usar agentes de IA para revisar código. Es dónde cuenta su pasada y dónde tiene que leer primero una persona. Algunas reglas que resisten el paso del tiempo:
- Deja que el agente controle el estilo, el formato y los bugs mecánicos en todos los cambios. Es la pasada que mejor se le da y la que peor hacen las personas cuando están cansadas.
- Exige una barrera humana en todo lo que toque autenticación, facturación, migraciones de datos o una API pública. Ahí se concentra la zona ciega.
- Dimensiona tus barreras según tu capacidad de revisión. Los agentes producen más rápido de lo que las personas aceptan, así que invierte la pasada humana donde el agente es ciego.
- Convierte la barrera en un estado, no en una costumbre. Una barrera de aprobación documentada que bloquee el paso a Done es exigible; una norma de que «alguien debería echar un vistazo» no lo es. Mantener a un humano en el bucle solo funciona cuando el bucle es un paso que el flujo de trabajo exige.
Un agente de IA para revisar código no sustituye a una persona revisora. Es la primera pasada que hace que la pasada humana sea más rápida y más precisa. Si ya tienes varios agentes de programación en marcha y quieres que su resultado se revise y se acepte en un solo lugar en vez de en cinco pestañas de PR, ese es el problema en torno al que está construido Sharkly: asignar, seguir y revisar el trabajo de los agentes en Tasks compartidas, con los hallazgos del Agente de revisión y la decisión humana volviendo ambos al mismo registro. Conserva los agentes de programación y el agente de revisión que ya usas y, después, añade la capa que decide cuándo su pasada es suficiente.
