¿CON QUÉ IA?A quién le sirve. Equipos de desarrollo que quieren que unos agentes abran y revisen cambios de forma repetible, con una persona que apruebe al final.
Qué hicieron
La guía divide una fábrica de software en cinco fases: entrada de tareas, aislamiento, herramientas, verificación y una puerta de fusión. Se apoya en configuraciones publicadas por Stripe, Spotify, Shopify y Ramp. Da ajustes para cada fase: un filtro de incidencias, un espacio de trabajo git aparte por agente, un bloque común de herramientas MCP, una habilidad de verificación con capturas y reglas de fusión por niveles. Al final revisa una persona.
Cómo salió
Los datos de dotnet/runtime de Microsoft muestran que los cambios de agentes se aceptan el 67,9 % de las veces frente al 87,1 % de los ingenieros, y el 55,1 % cuando son totalmente autónomos. La capacidad de revisión se convierte en el cuello de botella, y los resultados probados son sobre todo migraciones mecánicas.
Conviene saber
Construye las puertas antes que la flota, y empieza por una sola donde los agentes generen más repetición de trabajo. Los espacios de trabajo nuevos empiezan vacíos, sin .env, dependencias ni puerto libre, y las ejecuciones sin supervisión no limpian lo que dejan.
Qué necesitas
- Un repositorio en GitHub o similar, que es donde se guarda el código del proyecto, con pruebas automáticas
- Un agente de programación, como Claude Code o Codex
- Un sistema de incidencias con etiquetas
- Quien revise los cambios: la capacidad de revisión es el cuello de botella
- Soltura técnica para configurar espacios de trabajo y herramientas
Cómo hacerlo tú, paso a paso
- Elige un único repositorio y un único tipo de tarea repetitiva, como migraciones mecánicas o correcciones pequeñas.
- Entrada: define un filtro de incidencias, por ejemplo una etiqueta, que marque qué tareas puede coger el agente.
- Aislamiento: dale a cada agente su propio espacio de trabajo separado. Asegúrate de que lleva lo necesario para funcionar, como dependencias, configuración y un puerto libre.
- Herramientas: configura un bloque común de herramientas MCP, el estándar que conecta agentes con servicios, para todos los agentes.
- Verificación: añade una comprobación que ejecute las pruebas y haga capturas de pantalla para confirmar el resultado.
- Puerta de fusión: escribe reglas por niveles de riesgo. Lo de bajo riesgo puede pasar con menos revisión y el resto lo aprueba una persona.
- No actives la fusión automática al principio. Mide cuántos cambios acepta tu equipo y cuánto tarda en revisarlos.
Prepara un flujo para el repositorio [nombre del repositorio] en el que un agente tome las incidencias con la etiqueta [etiqueta], abra un pull request con una corrección y sus pruebas, y un segundo agente lo revise. Escribe la configuración y una guía breve de cómo funciona. No actives todavía la fusión automática: enséñame las reglas de fusión que propones y espera mi aprobación. Habrás terminado cuando una incidencia de prueba llegue a un pull request revisado.
Consejos
- Cuenta con que se acepten menos cambios de agentes que de personas, y reserva tiempo de revisión.
- Programa una limpieza periódica de los espacios de trabajo que dejan los agentes. Las ejecuciones sin supervisión no limpian lo que dejan.
- Empieza por tareas repetitivas y mecánicas, que es donde los resultados probados son mejores.
Preguntas frecuentes
¿Cuántos cambios de agentes se aceptan?
En los datos de Microsoft que cita la guía, menos que los de ingenieros, y menos aún si el agente trabaja sin supervisión. Cuenta con rehacer una parte.
¿Se puede dejar que fusione solo?
Mejor no al principio. Empieza con aprobación humana y amplía el permiso solo para los cambios de menor riesgo, si los datos lo justifican.
Fuentes
La conversación en Hacker News, 11 de septiembre de 2026 ↗En el directorio desde el 3 de octubre de 2026.
@german-noob.win en Bluesky
tidydesign en Substack