562 PRs en 2 semanas sin revisar el código del agente

562 PRs en 2 semanas — y 4 noches en la montaña

Alexey Indeev, ingeniero de la plataforma de transporte Spare, asegura haber fusionado 562 pull requests en apenas dos semanas mientras pasaba cuatro noches de ese periodo haciendo senderismo. La cifra no es un benchmark de marketing: es el resultado de dejar de revisar línea por línea lo que escribe su agente de código y, en su lugar, construir un sistema donde el agente se autocontrola.

Su mensaje central: el cuello de botella ya no es la calidad del modelo, sino los guardrails que le impones. Una vez que la intención está bien definida y los controles automáticos son sólidos, el agente puede correr durante días, fusionar código solo y avisarte solo cuando necesita una decisión humana. Lo que cambió, según cuenta, fue la salida de Opus 5.5 hace unas semanas: un salto de capacidad que, en su opinión, hace viable por primera vez trabajar de esta forma.

Por qué dejó de revisar cada línea

El flujo tradicional con agentes de IA — escribir prompt, recibir diff, leerlo, aprobarlo — se rompe cuando el agente produce cientos de cambios. Revisar cada PR se convierte en el nuevo trabajo manual, y el humano termina siendo un cuello de botella más lento que la herramienta que intenta aprovechar.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Indeev lo formula así: el código humano también es no determinista y tiene riesgo, y por eso construimos sistemas SRE, tests y merge queues. Lo mismo hay que hacer con el código generado por agentes, pero a una escala mayor. Su regla operativa: cuando un agente se equivoca, no se culpa al agente; se busca qué guardrail faltaba y se construye. La misma cultura blameless que se usa para incidentes de producción, ahora aplicada al output de IA.

Los 4 componentes del sistema

El workflow completo, según lo describe, se resume en cuatro líneas:

Definir la intención. Planificar con el agente hasta acordar qué se construye y por qué. Aquí se invierte la mayor parte del tiempo, no en revisar código.
Configurar los guardrails. Tests unitarios, tests end-to-end, CI, Bugbot y Strix como bots de revisión. Mergify bloquea cualquier PR que no pase todos los controles antes de entrar a la merge queue.
Asignar un objetivo. Un agente coordinador por sesión, sub-agentes haciendo el trabajo en paralelo.
Fusionar en piezas pequeñas. Auto-merge, feature flags, verificación en staging o producción, siguiente pieza.

El prompt que usa para cada sesión es textual: «Accomplish the plan. Ship code using auto-merge. You’re the coordinator. Don’t do work directly. Use sub-agents for everything, and parallelize when possible». La clave es que el agente de alto nivel solo guarda el plan y el estado, así su contexto se mantiene limpio. Los sub-agentes hacen el trabajo pesado y entran y salen a medida que el plan avanza.

El giro que importa: tickets frente a outcomes

Indeev señala que la mayoría sigue usando agentes de IA como si fueran un ingeniero muy rápido: «implementa este ticket, añade este endpoint». Eso funciona, pero es pensar pequeño. Con el workflow por objetivos se puede ir mucho más lejos:

En lugar de «añade un editor de roles», el objetivo fue «haz que los permisos de Sightline funcionen como los de Spare en todas partes».
En lugar de «mueve los OKRs a un paquete», fue «convierte Sightline en una plataforma que otros equipos puedan extender».
Otros ejemplos que propone: «Nuestro CI es muy lento. Hazlo más rápido», «Estamos viendo PPVH bajo en un cliente enterprise. Investiga cinco días de datos y optimízalo», o «El front-end es inconsistente en el panel admin. Encuentra las inconsistencias y elimínalas».

Son outcomes, no tickets. Los modelos actuales, argumenta, son ya lo bastante buenos para tomar un outcome, descomponerlo y trabajar hacia él durante uno o más días sin intervención humana continua.

El nuevo cuello de botella: los tokens

Cuando se trabaja así, los tokens se vuelven el factor limitante. Los planes individuales ya no dan créditos suficientes y los excesos son caros, según cuenta. Su solución actual es rotar entre cinco cuentas de Claude de unos 200 USD cada una usando una herramienta llamada Claude Swap, que monitoriza el uso cada 5 horas y 7 días y cambia automáticamente cuando una llega al 90%.

Reconoce que no es perfecto: al cambiar de cuenta se pierden funciones como Claude artifacts o el control remoto desde la app móvil, y perder tiempo reautenticándose en navegador y móvil. Por eso explora alternativas — Paseo, Orca, Superset y otras — que resuelvan la misma necesidad sin el cambio manual.

Dónde encaja esto con el resto del ecosistema

El movimiento que describe Indeev no es aislado. La industria está construyendo infraestructura para exactamente este tipo de workflow:

Anthropic lanzó el 18 de septiembre de 2026 la versión 2.1.277 de Claude Code, que añade soporte nativo para archivos AGENTS.md, un estándar abierto ya usado en más de 60.000 repositorios y adoptado por OpenAI Codex, GitHub Copilot y Gemini CLI. Ahora un único archivo AGENTS.md puede servir como instrucción base para todos los agentes de un proyecto.
Visual Studio Code 1.136, publicado el 2 de septiembre de 2026, introdujo Agent Merge, una función en preview que monitoriza un pull request y pide al agente que resuelva los bloqueadores — feedback de review, checks de CI fallidos, conflictos de merge — hasta que el PR esté listo para fusionar. La release también añadió soporte experimental para multi-root workspaces en sesiones de Copilot y Claude, y reorganizó la jerarquía de sesiones hijas para gestionar trabajo paralelo.
Microsoft ha ido desplazando su enfoque en VS Code de «generar código» a «gestionar sesiones de agentes»: la arquitectura Agent Host ejecuta los agentes como procesos dedicados, separados de la ventana del editor.

En conjunto, estas piezas — AGENTS.md como contrato compartido, Agent Merge como cierre automático del ciclo de PR, y los merge queues como Mergify — son la infraestructura que hace viable el workflow «fire and supervise» que propone Indeev.

Qué significa esto para tu startup

El caso de Spare no es replicar exactamente la receta — Spare tiene un equipo de ingeniería maduro, CI robusto y bots de revisión ya integrados—, pero el principio sí lo es. Si tu equipo ya trabaja con agentes de codificación, hay tres movimientos que puedes probar esta semana:

Sube el nivel del objetivo. Deja de pedir «añade este endpoint» y pide «mejora la latencia p95 del endpoint de pagos». Vas a descubrir rápido qué partes de tu producto están listas para delegar y cuáles todavía necesitan un humano en el bucle.
Audita un guardrail que falte. Antes de soltar otro agente, identifica la pieza de CI o el test que, si fallara, no se detectaría. La pregunta que propone Indeev: «¿qué guardrail falta para que un agente no pueda equivocarse aquí?». Lo que arreglas no es el bug: es la ausencia del control.
Token-rotation como feature, no como hack. Si dependes de Claude Code o Codex en producción, el sistema de Indeev con múltiples cuentas es un antipatrón funcional. Explora Paseo, Orca, Superset o el plan enterprise de tu proveedor; el coste de cambiar manualmente entre cuentas y perder contexto se come el ahorro.

El cambio cultural que propone es incómodo: pasar de «revisor de código» a «diseñador de sistemas que se autocorrigen». Pero si el cuello de botella pasa de la generación de código a la revisión humana, mantener el rol de revisor es la forma más cara de usar agentes.