TL;DR
En una organización de ingeniería nativa de IA, generar código ya no es la parte más lenta del proceso de entrega de software. La revisión, la verificación, la corrección y la toma de decisiones humanas se convierten en los cuellos de botella y, en última instancia, definen cuánto más rápido puede avanzar la organización. Las herramientas de codificación con IA independientes pueden ofrecer una mejora del 30–40 % en velocidad, pero lograr un cambio significativo en la productividad requiere optimizar todo lo que ocurre después de que se escribe el código.
En nuestra publicación anterior sobre cómo resolver la revisión de código con Cosmos, describimos un sistema de revisión que ayudó a nuestra organización de ingeniería a aumentar la producción de código en 3×, reduciendo a la vez el tiempo medio de merge y manteniendo la calidad. Desde entonces, hemos ampliado ese sistema más allá de la revisión para abarcar todo el ciclo de PR a merge: los agentes especializados se encargan del trabajo mecánico, verifican la corrección y atienden los comentarios, mientras que los humanos aportan criterio y transferencia de conocimiento, y siempre conservan la decisión final del merge.
Esto es loop engineering: mejorar el sistema completo que convierte el código generado en un cambio verificado, comprendido y listo para merge, en lugar de optimizar una sola herramienta de forma aislada.
Por qué una “herramienta de revisión de código con IA” no es suficiente
Una herramienta convencional de revisión de código con IA, como CodeRabbit o Greptile, analiza un diff y publica comentarios. Es útil, pero la revisión es solo un paso. El verdadero lastre es la cadena de traspasos manuales:
- Reconstruir la intención y la arquitectura.
- Clasificar los cambios de bajo riesgo.
- Aplicar los comentarios de la revisión.
- Corregir los fallos de CI y los conflictos de merge.
- Verificar el comportamiento de la funcionalidad de extremo a extremo.
- Reunir suficiente evidencia para publicar con seguridad.
- Re-revisar después de cada push.
Un ciclo de PR a merge mantiene a Expertos especializados trabajando en la revisión, la corrección, la verificación y el soporte de decisiones hasta que un humano pueda hacer el merge con confianza. Cada Experto de la flota se hace cargo de uno o más de estos traspasos, convirtiendo una secuencia fragmentada de tareas manuales en un sistema coordinado. El objetivo es optimizar el ciclo completo: tiempo humano, costo, calidad y latencia del merge, no el tiempo hasta el primer comentario.
1. Descripción general: la ingeniería del ciclo completo
lee la descripción de la imagen
ALT
Un ciclo de revisión de código nativo de IA: los agentes encuentran y corrigen errores, verifican cambios y evalúan políticas; los humanos resuelven las decisiones de criterio y toman la decisión final del merge.
Nuestro sistema original separaba el análisis de riesgo (Risk Analyzer), la revisión de corrección línea por línea (Deep Reviewer) y la revisión de diseño guiada por humanos (Pair Review). El sistema ampliado agrega corrección, verificación en tiempo de ejecución y aprobación automática ampliada, lo que reduce aún más el cuello de botella humano. Para obtener una descripción general de Cosmos y sus Expertos configurables, consulta nuestra publicación anterior sobre cómo resolver la revisión de código con Cosmos.
Expertos y capacidades, no un revisor generalista
Responsabilidad
Clasifica el riesgo y aplica la política de aprobación automática
Realiza un análisis exhaustivo, línea por línea, para detectar defectos objetivos de corrección
Reconstruye la intención, la arquitectura, el contexto del producto y las compensaciones
Recuerda los comentarios de las sesiones de PR y Pair Review para mejorar ejecuciones futuras
<sup>
NUEVO
</sup>
Ejercita el comportamiento afectado de extremo a extremo en un entorno de prueba (
)
<sup>
NUEVO
</sup>
Corrige los hallazgos de la revisión, los fallos de CI y los conflictos de merge
<sup>
NUEVO
</sup>
Observa y resume el estado de los expertos
<sup>
NUEVO
</sup>
Evalúa una política de aprobación configurable a solicitud del autor
La distinción entre Deep Reviewer y Pair Reviewer es especialmente importante:
- Deep Reviewer pregunta: “¿Hay un error objetivo en esta implementación?” Se ejecuta de forma autónoma y verifica el PR contra las pautas de AGENTS.md o CLAUDE.md.
- Pair Reviewer pregunta: “¿Tiene sentido este cambio en el sistema más amplio y qué decisiones requieren criterio humano?” Se ejecuta de forma interactiva con el humano. El humano también puede indicarle que monitoree el PR después de publicar los comentarios de revisión y que apruebe en su nombre una vez que se hayan atendido esos comentarios.
El Experto PR Author antes cumplía una doble función: redactar el PR y corregir los comentarios de revisión, los fallos de CI y otros trabajos de seguimiento. En el diseño desacoplado, PR Author se detiene en la creación del PR en borrador y PR Fixer toma el control. Esto les da a los usuarios más control sobre cómo se ejecutan las correcciones y admite PR creados sin PR Author.
El Review Dashboard reúne en una sola vista el estado de los Expertos, los commits revisados, la evidencia y las acciones disponibles.
- Diseño del enfoque con humanos en el ciclo
La revisión y la verificación humanas se están convirtiendo en los recursos escasos de las organizaciones de ingeniería nativas de IA. El objetivo no es eliminar a los humanos de manera indiscriminada. Se trata de invertir la atención humana solo donde tiene el mayor impacto.
Por qué los humanos siguen siendo parte del ciclo
Los agentes pueden realizar una gran parte del análisis y la ejecución mecánica, pero no tienen el contexto completo del negocio y de la organización. Los humanos siguen siendo esenciales para:
- Decisiones de criterio: ¿Esta lógica debería estar en el frontend o en el backend? ¿Esta compensación es adecuada para el producto? ¿Este riesgo es aceptable ahora?
- Transferencia de conocimiento: La revisión es una de las formas en que los ingenieros construyen un entendimiento compartido de la arquitectura y el comportamiento del producto.
- Responsabilidad y rendición de cuentas: Los agentes no son dueños del software después de que se publica; los desarrolladores humanos y las organizaciones de ingeniería sí lo son. Por lo tanto, un humano siempre toma la decisión final y hace clic en Merge. Ninguno de estos expertos hace merge de un PR.
Por lo tanto, el objetivo de diseño es:
Los agentes hacen el trabajo mecánico. Los humanos toman las decisiones importantes.
El flujo de trabajo del autor y del revisor: antes y después
Flujo de trabajo con humanos en el ciclo
Deja que
Risk Analyzer
clasifique el riesgo y aplique la política de aprobación automática de la organización
Confía en
Deep Reviewer
para que realice un análisis exhaustivo, línea por línea
Usa el informe de
Pair Reviewer
para entender el cambio e identificar las decisiones de criterio
Inspecciona la evidencia del
Verifier
: capturas de pantalla, logs, trazas y salidas capturadas
Deja que
Pair Reviewer
monitoree si se atendieron los comentarios autorizados
Deja que
PR Fixer
—o
PR Author
cuando es dueño del ciclo completo— maneje el seguimiento mecánico e informe qué cambió
Usa el
Review Dashboard
como punto de entrada
Invoca
cosmos approve
para evaluar la política de aprobación configurada contra la evidencia actual
Tú sigues decidiendo si hacer merge
La intuición económica de usar múltiples expertos
Los tokens que reducen de forma medible el tiempo humano en el cuello de botella de la revisión valen la inversión. Cuando los Expertos convierten horas de revisión y gestión de PR en minutos, liberan el escaso criterio de ingeniería para las decisiones importantes que solo los humanos pueden tomar, y además ayudan a que las funcionalidades lleguen más rápido a los clientes.
Uno de los compromisos centrales de Augment es ayudar a las organizaciones a optimizar costos. Eso significa optimizar el costo total por tarea: esfuerzo humano más costo de tokens. No significa minimizar el uso de tokens a expensas de los resultados exitosos. Un solo Experto cargado con seis responsabilidades hará un trabajo deficiente en cada una y requerirá más intervención humana. Seis Expertos dedicados pueden enfocarse cada uno en una parte diferente de la revisión de PR, producir artefactos de revisión de mayor calidad e impulsar más del proceso de forma autónoma.
3. Costo y calidad: optimiza el costo por resultado exitoso
El modelo más barato por precio de token suele ser una falsa economía. Un defecto no detectado, una corrección deficiente o un reintento pueden costar más que hacer la tarea bien a la primera. Evaluamos trabajos representativos y elegimos el modelo de menor costo que supera el estándar de calidad de cada Experto, el mismo principio de costo por éxito que usamos en todo Cosmos.
Hoy usamos GPT-5.6 Sol para trabajos que requieren mucho criterio, como el análisis de riesgo, la revisión Deep y Pair, y la corrección de código. Las tareas acotadas y mecánicamente verificables, como la agregación del dashboard y el monitoreo de conflictos de merge, se ejecutan en GPT-5.6 Luna. Los modelos con TTL de caché más largos también favorecen a los agentes de larga duración, porque la entrada en caché suele tener un descuento del 90 %.
4. Una ruta de aprobación configurable con cosmos approve
El Risk Analyzer siempre ha podido aprobar cambios intrínsecamente de bajo riesgo bajo una política conservadora. Ahora admitimos un segundo modo de aprobación, deshabilitado por defecto, para otros cambios.
El autor del PR puede comentar cosmos approve para solicitar una evaluación contra una política de aprobación. Un humano sigue siendo el dueño y responsable del merge final.
Las organizaciones definen su propia política de aprobación. Nuestra política interna verifica:
- Propiedad: El solicitante es el autor del PR, y el autor es un CODEOWNER efectivo de cada archivo modificado.
- Revisión del head actual: No hay hallazgos sin resolver del Deep Reviewer, bloqueos del Pair Reviewer ni comentarios humanos sin atender.
- Sin evidencia contradictoria en tiempo de ejecución: El Verifier no ha reportado un defecto sin atender contra el commit actual.
5. La personalización es parte de la arquitectura
Diseñamos la flota para que los equipos puedan personalizar el ciclo con Cosmos Advisor.
- Flota: Agrega, elimina o reemplaza expertos; elige el modelo y el prompt para cada responsabilidad.
- Operación: Configura disparadores, herramientas, integraciones y entornos de verificación.
- Control: Restringe quién puede invocar acciones y a qué credenciales, repositorios y sistemas puede acceder cada experto.
- Política: Define reglas de aprobación, verificaciones requeridas, requisitos de CODEOWNER y evidencia aceptable.
El modelo operativo para la revisión de PR nativa de IA
La lección de nuestra primera versión fue que la revisión de código no podía escalar pidiéndoles a los humanos que leyeran código generado por IA más rápido. La lección de esta versión es más amplia: ningún agente de revisión individual puede optimizar el camino completo hacia el merge.
Un ciclo de PR a merge de alto funcionamiento necesita:
- Especialización de agentes: Separa el riesgo, la corrección, el criterio de diseño, la verificación en tiempo de ejecución y la reparación.
- Minimiza los puntos de control humanos: Involucra a los humanos solo para decisiones importantes y transferencia de conocimiento.
- Evidencia: Dales a los revisores pruebas inspeccionables en lugar de veredictos sin respaldo.
- Bucles de corrección: Deja que los hallazgos regresen a la implementación sin esperar la intervención manual.
- Observabilidad: Haz que el estado de toda la flota sea legible en un solo lugar.
- Disciplina de costos: Usa el modelo más barato que supere el estándar de calidad para cada responsabilidad.
- Configurabilidad: Personaliza el ciclo según los requisitos únicos de cada organización
