De 45 a más de 225 tareas por sprint: cómo un proceso de desarrollo agente transformó un proyecto de IA médica

Resumen rápido

• Cómo un proceso de cuatro fases reemplazó los flujos de trabajo secuenciales con un desarrollo agente concurrente
• Por qué los prototipos de diseño funcional superan a los entregables estáticos en equipos de alta velocidad
• Cómo los agentes de control de calidad autónomos redujeron los rechazos antes de que las funciones llegaran a la revisión humana
• Cómo se ve la evolución de roles en la práctica para desarrolladores, diseñadores y analistas de control de calidad.
• Por qué el componente cultural y emocional de la transformación fue más difícil que el técnico

El desafío: un producto de alto riesgo que alcanza sus límites

Crear un asistente de inteligencia artificial para salas de emergencia no es un proyecto de software típico. El sistema necesita apoyar a los médicos en tiempo real (en la ventana anterior a la llegada de un especialista), lo que significa que las funciones incompletas, los ciclos de iteración lentos o las compilaciones inestables no son sólo inconvenientes. Son riesgos.

El equipo de este proyecto era capaz y estaba motivado. El problema era estructural. La capacidad era de 45 tareas por sprint, muy por debajo de lo que requería la hoja de ruta del producto. El diseño funcionó de forma secuencial (investigación, archivos Figma manuales, revisión del cliente, iteración) y entregó los activos estáticos al desarrollo solo después de la aprobación. El control de calidad realizó pruebas de regresión manuales en la puesta en escena después de cada ciclo de desarrollo. Cada traspaso entre disciplinas creaba un retraso, y ese retraso se estaba agravando.

Se repetían tres patrones. El desarrollo entregó características que pasaron la revisión interna pero no cumplieron con los criterios de aceptación de control de calidad, lo que generó retrabajo en lugar de progreso. Las iteraciones del diseño tardaron más de lo que el ciclo del producto podía absorber. Las pruebas de regresión consumieron suficiente tiempo como para que las nuevas funciones esperaran en cola en lugar de enviarse. El equipo no tuvo un desempeño deficiente. El flujo de trabajo no se creó para la velocidad que requería el proyecto.

Nuestro enfoque: cuatro fases para un proceso de gestión de agentes de circuito cerrado

La transformación no fue un cambio de herramienta. Fue una reconstrucción completa de cómo opera el equipo, ejecutada en cuatro fases estructuradas durante seis semanas.

El modelo de servicio completo detrás de este trabajo está disponible en AI Transformation Sprint.

Fase 1: Migración de la gestión de proyectos

El proyecto se trasladó a la plataforma de gestión de proyectos patentada de CodeBranch. Esto le dio al equipo tres cosas que no tenía antes: seguimiento del desempeño individual por desarrollador, módulos de ingeniería rápida integrados para ayudar a generar instrucciones efectivas para los agentes y estimación de requisitos asistida. El trabajo pendiente dejó de ser una lista de características vagas y se convirtió en una cola estructurada de tareas granulares listas para los agentes.

Fase 2: Canal de desarrollo de circuito cerrado

El oleoducto fue reconstruido de secuencial a concurrente. Claude de Anthropic y Codex de OpenAI se convirtieron en los principales agentes de desarrollo. Cada resultado que produjeron fue auditado automáticamente para determinar la calidad del código, la alineación con la base de código existente y el cumplimiento de los patrones arquitectónicos, antes de que cualquier humano lo revisara. La producción no avanza a través del oleoducto a menos que pase todos los controles automáticos.

Éste es el cambio estructural que importa. En un oleoducto tradicional, el control de calidad ocurre al final. En un proceso de agente de circuito cerrado, está integrado en cada paso.

Fase 3: Integración del diseño

El proceso de diseño estaba integrado dentro de la metodología del agente. En lugar de producir archivos Figma estáticos, el diseñador comenzó a guiar a los agentes para que construyeran prototipos de interfaz funcionales directamente en el código. Una vez que el cliente aprobó un prototipo, la rama de diseño acudió a los desarrolladores para conectarse con el backend, haciendo que la interfaz fuera completamente operativa sin una capa de traducción separada entre el diseño y el código.

Fase 4: control de calidad agente y pruebas de un extremo a otro

Se integraron agentes de IA en el proceso de control de calidad para ejecutar pruebas de regresión automatizadas antes de que las funciones llegaran al analista humano. El analista pasó de ejecutar todas las pruebas manualmente a revisar los resultados, diseñar marcos de pruebas y validar casos extremos que requerían juicio humano. Se agregaron pruebas de extremo a extremo a la tubería como verificación final antes de la producción.

Lo que cambió para el equipo

Los cambios en la tubería aparecieron en las métricas en cuestión de semanas. La evolución del papel llevó más tiempo y requirió un esfuerzo más deliberado.

Los desarrolladores dejaron de trabajar en IDE y de revisar el código línea por línea. Su función ahora es la orquestación de agentes: escribir indicaciones precisas, validar que la salida del agente cumpla con los criterios de aceptación y garantizar el cumplimiento de la arquitectura. El oleoducto maneja controles de calidad automatizados. El desarrollador maneja las decisiones de juicio.

Los diseñadores dejaron de producir entregables estáticos. Ahora guían a los agentes para que creen prototipos funcionales con los que las partes interesadas puedan interactuar desde el primer día. La brecha entre las aportaciones del cliente y una interfaz de trabajo se cerró significativamente.

Los analistas de control de calidad pasaron de las pruebas manuales reactivas a definir los marcos de prueba y las reglas de validación que ejecutan los agentes. La revisión humana se centra en lo que las pruebas automatizadas no pueden detectar: ​​casos extremos y comportamientos de dominios específicos en un contexto médico.

El equipo también cambió la forma en que maneja el trabajo paralelo. Anteriormente, cada desarrollador trabajaba en un requisito a la vez. La canalización agente permite que múltiples requisitos se muevan simultáneamente, porque los agentes pueden ejecutar tareas en paralelo sin la sobrecarga que hace que la multitarea humana sea ineficiente.

Resultados: Seis Semanas de Desarrollo Agentico

Los números superaron la proyección del propio equipo. El objetivo antes de la transformación era una aceleración de 2 a 3 veces la velocidad de entrega. A las seis semanas, la velocidad de desarrollo era 5 veces mayor.

La calidad de la trayectoria importa tanto como la velocidad. Los rechazos de control de calidad cayeron un 85%, lo que significa que el equipo no solo enviaba más, sino que enviaba con menos defectos ingresando a la cola de revisión. Esa reducción crea capacidad de capitalización con el tiempo: menos retrabajo significa más espacio para nuevas funciones en cada sprint.

La confianza del cliente mejoró junto con las métricas. Menos rechazos e iteraciones más rápidas cambiaron la naturaleza de la relación laboral, desde gestionar retrasos hasta planificar qué construir a continuación.

El lado humano: por qué el coaching determinó el resultado

Una tubería que produce una velocidad 5x no alcanza ese número por sí sola. Las primeras semanas de la transformación surgieron fricciones que la configuración técnica no pudo solucionar.

Los desarrolladores senior sintieron que dejar de escribir código reducía su valor profesional. Para los ingenieros cuya experiencia se mide por la calidad del código y la profundidad técnica, que les pidan que dejen de escribir es un desafío directo a la identidad profesional. El oleoducto estaba funcionando. El equipo aún no estaba seguro de que estuviera funcionando para ellos.

Los diseñadores enfrentaron un obstáculo diferente. La configuración técnica necesaria para guiar a los agentes (entornos de desarrollo local, control de versiones, gestión de sucursales) era un terreno nuevo. La curva de aprendizaje fue más pronunciada de lo esperado.

Tres prácticas de coaching abordaron ambos problemas.

Sesiones individuales con cada miembro del equipo redefinieron cómo se ve el éxito profesional en un flujo de trabajo de agencia. La medida pasó de líneas de código escritas a mantener la calidad del sistema y validar la salida del agente. El valor de la ingeniería no desapareció: avanzó hacia arriba, desde la ejecución hasta la arquitectura y el juicio.

Los controles diarios de las tuberías detectaron cuellos de botella antes de que se convirtieran en obstáculos. Cuando el seguimiento diario fue constante, los resultados se mantuvieron encaminados. Cuando caducó, el rendimiento cayó. El patrón fue directo y mensurable: el acompañamiento estructurado no es opcional en esta escala de cambio.

Un protocolo de autoridad humana estableció que no se integrara ninguna salida de agente sin la aprobación arquitectónica superior. Esto abordó ambas preocupaciones a la vez: los humanos seguían siendo quienes tomaban las decisiones finales y el oleoducto les brindaba mejor información para decidir.

El Informe DORA 2025 identifica la velocidad del ciclo de retroalimentación como el principal impulsor de la ventaja competitiva en la entrega de software. El programa de entrenamiento se creó para cerrar ese ciclo a nivel humano, garantizando que el equipo pudiera procesar los resultados de los agentes y corregir el rumbo casi en tiempo real.

Aprendizajes clave: qué haríamos diferente

Quedaron claras tres cosas que no previmos del todo al principio.

Entrenamiento individual desde el primer día, no como corrección

El entrenamiento inicial fue un saque de grupo. Cubrió la metodología, las herramientas y el razonamiento detrás del cambio. No fue suficiente. En el primer sprint, quedó claro que cada miembro del equipo tenía una relación diferente con la transición. Las sesiones individuales en pareja se convirtieron en el mecanismo de adopción real. Deberían haber estado en el plan desde el principio, no como respuesta a fricciones que ya se habían desarrollado.

El seguimiento diario es parte de la metodología, no una elección de gestión

La correlación entre los registros diarios y la producción fue directa. En un flujo de trabajo tradicional, una revisión de sprint semanal detecta la mayoría de los problemas antes de que se agraven. En un flujo de trabajo agente, donde la velocidad es alta y el equipo está aprendiendo un nuevo modelo operativo, un problema que pasa tres días sin identificación puede consumir la producción de un sprint completo. El seguimiento diario es el mecanismo de retroalimentación que requiere la metodología para funcionar.

La calidad del trabajo pendiente se convierte en la limitación vinculante

Con 45 tareas por sprint, un requisito vago se puede aclarar en una conversación sin mucho costo. Con más de 225 tareas por sprint, detiene el proceso. Los agentes no pueden resolver la ambigüedad de la misma manera que lo hace un desarrollador humano: producen resultados en función de lo que reciben. Las entradas imprecisas producen resultados que necesitan reelaboración, y la reelaboración a una velocidad cinco veces mayor se acumula más rápido de lo que el equipo puede abordar. La precisión del trabajo pendiente antes de cada sprint no es una sobrecarga. Es lo que mantiene el oleoducto funcionando a su máxima capacidad.

¿Está tu equipo preparado para multiplicar su capacidad de entrega? Hablemos de tu proyecto →

¿No estás seguro de si tu equipo está preparado para este tipo de transformación? El Análisis de brechas listo para IA le brinda una imagen clara de dónde se encuentra su canal y lo que se necesitaría para llegar hasta aquí.

Escrito por el equipo de CodeBranch.

CodeBranch es una empresa de desarrollo de software agente con sede en Medellín, Colombia, que crea canales de desarrollo optimizados para IA para equipos de productos en todo Estados Unidos.

Estudio de caso completo: Transformación del desarrollo de software agente para una aplicación sanitaria