Totales, en los tres proyectos de clientes: 127 tickets fusionados y 539 tareas de agentes ejecutadas desde junio de 2026.
Versión actual, medida aparte desde el 19 de agosto: 0.4% de commits humanos en ramas y 2% de tickets que necesitaron una aprobación humana, en los mismos proyectos de clientes.
Velocidad: una mediana de 54 minutos del primer commit a la fusión, en la misma versión actual y los mismos proyectos de clientes.
El reto
Dutopilot entrega proyectos de clientes con el mismo pipeline que vende. Todas las cifras de esta página se midieron en tres proyectos de clientes: el sitio web de una empresa de servicios de Salesforce, el sitio web de serpent.cloud y un monorepo que contiene código de Salesforce y de iOS nativo. Ninguna se midió en el repositorio del propio Dutopilot. El objetivo: que los miembros virtuales del equipo de Dutopilot lleven el trabajo rutinario de entrega y que las personas del cliente se queden con las decisiones.
Antes del pipeline, el trabajo rutinario de un ticket recaía en personas: alguien escribía el plan, construía el cambio, leía la pull request, perseguía las comprobaciones fallidas y hacía clic en fusionar. Ese trabajo es necesario, y casi todo es repetitivo.
Antes y después
| Paso | Antes | Ahora |
|---|---|---|
| Plan | Lo escribe una persona. | Lo propone un agente. Una persona lo aprueba cuando el cambio es nuevo o arriesgado. |
| Construcción | Una persona. | Un agente, en su propia rama. |
| Comprobaciones | Una persona las espera y persigue los fallos. | Un veredicto combinado. Los fallos van directo a un agente corrector. |
| Revisión | Una persona de tu equipo, cuando tiene tiempo. | Miembros virtuales del equipo de Dutopilot distintos como revisores, en cada pull request. |
| Fusión | Una persona hace clic en el botón. | La pull request se fusiona sola cuando todo está en verde, con protección de rama. |
| Release a producción (en estos proyectos de clientes) | Decide una persona. | Sigue decidiendo una persona. |
Cómo funciona
Cada ticket del tablero del proyecto pasa por nueve etapas: architect, planner, implementer, control, tres revisores, autofixer y QA. Alrededor, las personas fijan una vez por proyecto los puntos de aprobación humana, el pipeline recoge el ticket antes de la primera etapa y una persona hace el release a producción después de la última. Esos tres no son etapas. El ticket muestra en qué punto está.
- Architect: propone un plan a nivel de archivos, los flujos de datos y un plan de pruebas antes de escribir código. Una persona lo aprueba cuando el cambio es nuevo o arriesgado.
- Planner: convierte la arquitectura aprobada en una lista ordenada de tareas para el implementer.
- Implementer: escribe el cambio en su propia rama.
- Control: ejecuta las comprobaciones automáticas sobre la pull request y devuelve un único veredicto.
- Primer revisor: un agente distinto lee el cambio por su cuenta.
- Segundo revisor: otro agente distinto lee el cambio de forma independiente.
- Tercer revisor: un tercer agente distinto lee el cambio de forma independiente.
- Autofixer: repara lo que halló una comprobación o un revisor, y el control se ejecuta de nuevo.
- QA: el cambio se fusiona en staging o test y QA prueba el resultado.
En estos proyectos de clientes, el trabajo fusionado llega al entorno de staging o de pruebas y una persona hace el release a producción. Dutopilot también construye su propio producto de la misma manera.
Un ticket, del tablero a la fusión
Este es un ticket ilustrativo de los proyectos web, para mostrar qué produce cada etapa: "Añadir un filtro por sector a la página de casos de éxito".
| Paso | Qué ocurre |
|---|---|
| Ticket | Una persona de producto lo escribe con el resultado esperado y cómo se ve "terminado", y lo marca como listo. |
| Architect y planner | El architect publica los archivos que cambiará y las pruebas que añadirá, y el planner lista las tareas. Una persona aprueba, porque cambia el comportamiento de una página. |
| Implementer | El implementer construye el cambio en su propia rama y abre una pull request. |
| Control | Se ejecutan lint, build y pruebas. Una prueba falla. |
| Autofixer | El autofixer recibe el registro del fallo, corrige el código, y el control pasa en la siguiente ejecución. |
| Revisores | Los revisores dejan comentarios. El autofixer los responde y las comprobaciones se ejecutan de nuevo. |
| QA | La pull request se fusiona en staging o test y QA prueba el resultado. |
| Release (una persona) | En estos proyectos de clientes, una persona hace el release a producción. |
En la versión actual, la mediana desde el primer commit hasta la fusión es de 54 minutos.
Cuando algo falla
Los fallos son normales, así que el pipeline los prevé. Una comprobación fallida o un comentario de revisión vuelve a un corrector con el registro o comentario exacto. Una prueba que falla al azar se reintenta y se repara, para que no bloquee un buen trabajo. Desde el 19 de agosto, el pipeline ha reparado por sí solo 150 fallos de etapa. Cuando una corrección deja de avanzar, o el riesgo sube, la ejecución se detiene y el ticket pide ayuda a una persona.
Resultados
| Métrica | Resultado | Periodo y alcance |
|---|---|---|
| Tickets fusionados | 127 | Desde junio de 2026, en los tres proyectos |
| Tareas de agentes ejecutadas | 539 | Desde junio de 2026, en los tres proyectos |
| Commits humanos en ramas | 0.4% | Versión actual, desde el 19 de agosto |
| Tickets que necesitaron aprobación humana | 2% | Versión actual, desde el 19 de agosto |
| Tiempo mediano del primer commit a la fusión | 54 minutos | Versión actual, desde el 19 de agosto |
| Fallos de etapa reparados por el pipeline | 150 | Versión actual, desde el 19 de agosto |
Todas las filas vienen de los tres proyectos de clientes. Las dos primeras filas son totales de todo el periodo. Las demás filas se miden solo en la versión actual, así que los dos grupos no están pensados para compararse entre sí.
Lo que siguen haciendo las personas
- Decidir la arquitectura de lo nuevo o arriesgado antes de escribir código.
- Aprobar los cambios en las áreas donde un error sale caro.
- Decidir el release a producción, en estos proyectos de clientes.
- Responder cuando un ticket se detiene y pide una decisión.
Las aprobaciones las eliges tú. La guía sobre cómo elegir qué pasos necesitan aprobación muestra cómo las configuran los equipos.
En la práctica: una persona de producto que escribe y ordena tickets, un ingeniero que aprueba planes y cambios sensibles, y una persona de delivery que decide los releases. El resto del tiempo nadie tiene que vigilar, y el ticket avisa cuando hace falta una persona.
Cada cliente tiene un Forward Deployed Engineer
Un Forward Deployed Engineer de Dutopilot trabaja con tu equipo desde el primer día. No escribe el código de tu producto. Adapta el pipeline a tu forma de trabajar.
- Incorporación: conecta tus herramientas contigo y elige el primer tramo del backlog.
- Tickets listos: acuerda con tu product owner una plantilla corta de ticket para que los agentes reciban trabajo claro.
- Aprobaciones y controles: define qué planes y qué partes del código necesitan a una persona, según cómo revisa tu equipo.
- Mejora continua: revisa contigo los tickets atascados y los resultados, y mueve los controles a medida que crece la confianza.
Qué significa esto para tu equipo
Una cuenta de Claude Ultra entrega unos 50 tickets de tamaño medio por semana (unos 25 archivos cambiados por ticket de media), unos 200 al mes, cuando suficientes miembros virtuales del equipo de Dutopilot la usan. En Solo, el equipo más pequeño de Dutopilot (hasta 3 miembros virtuales del equipo) mantiene una cuenta en unos 100 tickets al mes; en Team, obtienes unos 200 tickets al mes por cada cuenta de Claude Ultra que conectes. 8 miembros virtuales del equipo de Dutopilot pueden terminar unos 50 tickets en un solo día, lo que consume aproximadamente la cuota semanal de IA de una cuenta. Cada agente de un plan es un miembro virtual del equipo. Cada miembro virtual del equipo puede ejecutar cientos de subagentes en paralelo, en todos los planes, y Enterprise no limita cuántos agentes ejecutas. Los planes se cobran por miembro virtual del equipo de Dutopilot, no por usuario: todo tu equipo puede usar Dutopilot. Dutopilot funciona con Jira, Linear, Notion, GitHub Issues y Azure DevOps para tu backlog, con GitHub, GitLab, Bitbucket y Azure DevOps para tu código, con Slack y con Claude Code, Codex, OpenCode y Oh My Pi como IA. Para verlo en una parte de tu propio backlog, reserva una llamada.