La Fábrica de Soluciones

Volver a los casos

Caso FIT · PAT-10

Célula de desarrollo mixta de personas y agentes

Caso de éxitoEmpresa de servicios digitales, anonimizada

Ejecutado con un cliente; los detalles se comparten en la sesión de diagnóstico.

Contexto

Ocurre en empresas donde la dirección pide funcionalidades como ideas sueltas y el equipo técnico es chico. Entre la idea y un ticket que se pueda programar pasan varias conversaciones, y el ticket llega con criterios ambiguos o sin saber qué partes del sistema toca. La célula se adopta por partes: el arnés de los repositorios de API ya opera, y el orquestador y los agentes de requerimientos y refinamiento se incorporan por etapas.

El reto

Los pedidos de la dirección llegaban como ideas sueltas y pasaban por varias personas antes de ser un ticket que un desarrollador pudiera tomar, con contexto incompleto y criterios ambiguos.

Cómo se resolvió

Se diseñó una célula en la que un orquestador convierte el pedido en una solicitud de requerimiento y entrevista para completar el ticket con criterios de aceptación. Pide análisis de impacto a agentes de backend y de frontend, crea el ticket en la herramienta de gestión y lo deriva al arnés del repositorio correcto. El desarrollador lo toma con el contexto armado, el arnés ejecuta y el orquestador revisa el cambio y cierra la tarea. Las personas aprueban el ticket, el plan y la integración.

Roles

  • Dirección que plantea el pedido
  • Dueño de producto que aprueba tickets e integraciones
  • Desarrollador que toma el ticket
  • QA que acepta el cierre

Antes y después

Antes

La idea pasa por varias personas hasta ser ticket

Con IA

El ticket llega completo y con impacto analizado

Quién hace qué

Quién hace qué: Célula de desarrollo mixta de personas y agentesFlujo en 6 pasos, en carriles de personas, agentes de IA y sistemas. 1. Personas: Dirección plantea el pedido 2. Agentes de IA: Redacta ticket con criterios 3. Agentes de IA: Analiza impacto técnico 4. Personas: Desarrollador toma el ticket 5. Agentes de IA: Revisa el cambio terminado 6. Personas: Aprueba integración y cierrePersonasAgentesde IASistemasDirecciónplantea elpedidoRedactaticket concriteriosAnalizaimpactotécnicoDesarrolladortoma elticketRevisa elcambioterminadoApruebaintegración ycierre
Quién hace qué: Célula de desarrollo mixta de personas y agentesFlujo en 6 pasos, en carriles de personas, agentes de IA y sistemas. 1. Personas: Dirección plantea el pedido 2. Agentes de IA: Redacta ticket con criterios 3. Agentes de IA: Analiza impacto técnico 4. Personas: Desarrollador toma el ticket 5. Agentes de IA: Revisa el cambio terminado 6. Personas: Aprueba integración y cierrePersonaDirección plantea el pedidoAgente de IARedacta ticket con criteriosAgente de IAAnaliza impacto técnicoPersonaDesarrollador toma el ticketAgente de IARevisa el cambio terminadoPersonaAprueba integración y cierre

Cómo funciona

  1. En el flujo diseñado, un agente convierte el pedido de la dirección en una solicitud de requerimiento: revisa si la función ya existe, evalúa si es viable y hace pocas preguntas por turno, sin jerga.
  2. Un agente de refinamiento entrevista para completar el ticket, pide análisis de impacto a los agentes de backend y de frontend, revisa la definición de listo y redacta criterios numerados.
  3. La persona aprueba, edita o cancela; solo con su aprobación el orquestador crea el ticket en la herramienta de gestión, sin crear ramas ni archivos.
  4. El orquestador deriva el ticket al repositorio correcto, leyendo su perfil desde la rama base, y el desarrollador lo toma con el contexto armado.
  5. Terminado el cambio, el orquestador revisa la evidencia del arnés, la cobertura de criterios, la seguridad, el impacto y el resultado de la integración continua.
  6. Integrar exige confirmaciones escritas de una persona y la aprobación de otra; el orquestador cierra la tarea pero nunca la da por aceptada.

Sistemas

  • Herramienta de gestión de tickets
  • Repositorio de código
  • Integración continua
  • Agente de código con arnés por repositorio

Capacidades

  • Orquestación de agentes en tareas de varios pasos
  • Automatización con aprobación humana
  • Generación y ejecución de pruebas de software

Criterios de éxito

IndicadorCómo se mideResultado
Tickets aprobados sin edición en la primera revisiónCómo se mideTickets aprobados con la opción aprobar, sin pasar por editar, sobre el total presentado.ResultadoSe mide en el piloto.
Tiempo desde el pedido hasta el ticket listoCómo se mideDiferencia entre el registro de la solicitud de requerimiento y la creación del ticket aprobado.ResultadoSe mide en el piloto.
Preguntas de aclaración por ticket después de creadoCómo se mideComentarios de aclaración registrados en el ticket después de creado, promedio por ticket y por mes.ResultadoSe mide en el piloto.
Tickets devueltos a refinamiento después de creadosCómo se mideTickets que vuelven de en progreso a refinamiento por criterios incompletos, sobre los creados.ResultadoSe mide en el piloto.

Lecciones

  1. Separar quién prepara de quién ejecuta: el orquestador nunca crea ramas ni commits; eso pasa por los controles de cada repositorio.
  2. Las instrucciones de los agentes se versionan y revisan como código; si la versión instalada y la del repositorio no coinciden, manda la del repositorio.
  3. Dejar escritos los puntos donde decide una persona evita que la célula se vuelva una cadena de agentes sin dueño.

Controles clave

Nivel de autonomía declarado por tarea · Aprobación con criterio, no por inercia · Dueño del caso de uso con nombre y apellido · Formación de usuarios y responsables

Implementación de referencia: Implementado con skills de Claude, Claude Code, ClickUp y GitHub.

Quiero revisar esto con FIT: Felipe Arentsen · felipe.arentsen@factorit.com

FIT Labs · La Fábrica de Soluciones