Devin Review 2.0 abarata la revisión de código un 82%: un PR cuesta ahora entre $0,25 y $0,75

Imagine el siguiente escenario: un desarrollador reúne en un día, con ayuda de un agente, una decena de pull requests (PR, el conjunto de cambios que espera revisión antes de fusionarse con el código principal), pero un revisor humano solo logra leer con atención dos o tres. Los demás se quedan en la cola o pasan con una lectura «en diagonal». Los creadores de Devin creen que la primera línea de revisión debería encargarse a otro agente, y han lanzado Devin Review 2.

0. El principal argumento de esta versión es el precio: desde agosto, revisar un PR cuesta un 82% menos (aproximadamente cinco veces menos) y ahora sale por entre $0,25 y $0,75. Con esa tarifa se puede ejecutar el bot en cada PR, como las pruebas automáticas en un CI, en lugar de elegir a mano los «importantes».

Cuánto cuesta y qué se obtiene

Según la empresa, el ahorro procede de dos fuentes: una combinación de modelos más acertada para cada etapa de la revisión y la optimización de la infraestructura que los rodea (harness). La calidad no ha empeorado: el promedio de bugs detectados ha subido de 1,22 a 1,32 por PR.

El blog aporta algunas cifras más. El tiempo mediano de revisión ha bajado de 139 a 94 segundos, es decir, unas 1,5 veces menos. Cerca del 80% de los PR cuestan menos de un dólar si se cuentan todos los pushes a la rama. Y el precio medio de un bug realmente corregido es, entre los clientes, de unos $2,25. No sustituye a una persona, pero la comparación con una hora de trabajo de un ingeniero favorece al bot.

Cómo evitar pagar dos veces por lo mismo

El principal cambio técnico es la revisión incremental. Si se añade otro commit al PR, Devin Review analiza solo las partes modificadas, no el PR completo otra vez. Esta opción viene activada por defecto. Tiene dos ventajas: la factura es menor, porque cada push es más pequeño que el PR entero, y hay menos ruido, porque los nuevos comentarios se refieren a los cambios recientes y no repiten los antiguos.

La revisión se puede lanzar de varias maneras:

• con el comentario /devin review en GitHub o GitLab;
• desde la página de Devin Review en Devin Cloud o Devin Desktop;
• automáticamente, cuando el PR está listo para revisión, o en cada push.

El lanzamiento automático se configura con reglas: se pueden incluir borradores y filtrar por rutas de archivos, ramas y etiquetas. Los clientes lo usan para no gastar dinero en PR de poco valor. También existe un límite de gasto por PR, de modo que un PR que crece sin control no dispare la factura. Además, el bot elabora una «visita guiada» del PR: explica de forma breve qué ha cambiado y adónde conviene mirar, de modo que a la persona le resulte más fácil entrar en contexto. Esta visita también se puede actualizar en cada push.

Integración con Devin y ajuste fino

Devin Review puede revisar PR de cualquier origen, pero, según sus creadores, funciona mejor junto con el propio Devin. En esa combinación, el agente analiza cada comentario por su cuenta y decide si corregirlo, descartarlo o pasárselo a una persona. Cuando el desarrollador vuelve a la sesión, solo quedan los bugs reales y las decisiones discutibles.

Se han añadido dos modos. El primero son los niveles de esfuerzo. Por defecto, la revisión está configurada para ahorrar, pero en facturación o en código de seguridad un bug que se escapa cuesta mucho más que la revisión.

Para esas zonas existe Devin Review Ultra: una revisión más minuciosa y más cara. El segundo son los Custom Reviewers, todavía en beta. Se trata de revisores propios con instrucciones definidas por el usuario.

Dentro de la empresa se usan para comprobar prácticas de seguridad del backend, migraciones seguras de bases de datos, consultas SQL eficientes y componentes de UI accesibles. Cada revisor puede tener sus propias reglas de lanzamiento, sus hallazgos pasan al informe general y a la autocorrección de Devin, y su gasto queda sujeto a los mismos límites.

Qué hacer con todo esto

La conclusión práctica: si la revisión cuesta menos de un dólar, resulta más rentable activarla en todos los PR que elegirlos a mano. Lo razonable es empezar con el lanzamiento automático en los PR listos, descartar los cambios menores con filtros por ruta y etiqueta, y reservar Ultra para pagos y autorización. Los Custom Reviewers merece la pena probarlos con los comentarios que su equipo repite una y otra vez en las revisiones.

También hay salvedades. Todas las cifras proceden del blog de la propia empresa, y los «1,32 bugs por PR» son un promedio entre clientes, sin comparación con herramientas independientes. La métrica de «bugs encontrados» no indica cuántos de ellos son realmente importantes. Por eso, en su propio repositorio conviene observar durante un par de semanas la proporción de comentarios útiles y la factura real antes de convertir al bot en un paso obligatorio del CI.