Qué grabar para tu video YouTube

Yo manejé software factories durante veinte años. Equipos de cincuenta desarrolladores, presupuestos de millones, clientes en varias capitales de América Latina. Pensaba que era un buen líder porque mi gente cumplía deadlines y mis márgenes cerraban. Hace ocho meses me senté un domingo a revisar mis calendarios de los últimos dos años. Conté hora por hora. Setenta por ciento de mi semana era coordinación. Standups, reportes a stakeholders, reuniones para alinear lo que ya estaba alineado, tickets que viajaban tres días entre QA y desarrollo porque alguien no contestaba un Slack a tiempo. El trabajo real, el que mueve el producto, era el otro treinta por ciento. Y dentro de ese treinta, la mitad la hacían mis seniors mientras yo apagaba incendios. Lo más doloroso no fue el porcentaje. Fue darme cuenta de que estaba cobrando por coordinar lo que un sistema bien diseñado podía coordinar solo. No estaba vendiendo expertise. Estaba vendiendo mi calendario. Probé todo lo clásico antes de llegar a esto. Más procesos, más PMs, dailys de quince minutos, tableros Kanban color-coded, retros quincenales. Cada capa nueva me agregaba treinta minutos al día y resolvía cero del problema de fondo. Yo seguía siendo el cuello de botella. Hace seis meses corrí mi primer fix de producción con un squad de agentes. Diecisiete minutos, sin que yo aprobara nada en el medio. Solo el guardrail dual del QA. Cuando vi el commit landeado en main pensé: esto cambia el negocio. No te estoy diciendo que reemplaces a tu equipo. Te estoy diciendo que dejes de venderle tu calendario al cliente. Te dejo con Camila.

El software complejo requiere equipo. Cinco personas. Mínimo. Quince mil dólares al mes en nómina. Dos semanas por iteración, desde que el Product Owner pide algo, hasta que el usuario lo ve. Te muestro qué se siente eso en la realidad de la semana. Lunes en la mañana, llega un bug. Un cliente enterprise no puede cargar su reporte. El bug entra a la cola del QA. El QA lo escala al Developer. El Developer pide contexto al Architect porque toca un módulo que no domina. El Architect está en otra reunión. El ticket queda esperando. Llega el viernes. Cuatro días después, el cliente todavía no carga su reporte. Lo mismo con un standup de treinta y cinco minutos: cinco personas reportando bloqueos que cada uno ya conocía, sin que se desbloquee ninguno realmente. La conversación productiva pasa después, en un canal de Slack, donde se pierde, sin documentar. Y mientras tanto, el dueño del negocio atrapado siendo project manager, en lugar de concretar oportunidades. Cada feature que tu competidor saca, vas tres semanas atrás. Cada cliente enterprise que pide un ajuste, lo pierdes, porque tu roadmap ya está comprometido. El costo no es solo la nómina. Es el costo de oportunidad de no poder responder. Hasta que cambias de modelo. Dejas de armar equipos. Empiezas a armar squads de agentes.

Esto es Agent Squad. Cuatro agentes con roles distintos, cada uno con su propio modelo, su prompt, sus herramientas, y todos coordinados por una capa de guardrails. Te muestro qué hace cada uno con un ejemplo real. El primero es el PMO. Es el agente que coordina. Cuando llega un ticket nuevo, el PMO lee la descripción, identifica si depende de otro ticket, revisa qué partes del repo están en juego, y asigna. No es un orquestador genérico. Sabe quién es el cliente, qué proyecto está activo, qué deuda técnica hay pendiente. Ahora mismo maneja dieciséis frentes en paralelo sin perder contexto. El segundo es el Architect. Diseña la arquitectura antes de que se escriba código. Si el ticket pide agregar un campo nuevo, el Architect decide si va en la base de datos existente o en una tabla nueva, si requiere migración, qué impacto tiene en el frontend, y deja un plan de implementación tarea por tarea. Lo que un staff engineer hace en una hora, lo hace en dos minutos. El tercero es el Developer. Optimizado para implementación. Lee el plan del Architect, abre el repo, escribe el código, corre tests locales, y abre el pull request. Este agente no inventa: sigue convenciones del proyecto, respeta el styling guide, y si encuentra un patrón existente lo reutiliza en vez de duplicar. El cuarto es el QA. Validación end-to-end con TestSprite. Corre las suites existentes, prueba el flujo nuevo en un browser real, captura screenshots de los estados clave, y emite un veredicto: pasa o no pasa. Si no pasa, el ticket regresa al Developer con el detalle del fallo. Debajo de los cuatro, la capa de guardrails: ningún agente cierra un ticket sin evidencia de QA y aprobación explícita del cliente. Esto no es un asistente. Es un equipo.

Pero acá está la parte que nadie suele contar en estos videos: el squad también comete errores. Te cuento uno reciente. Hace dos semanas, uno de los agentes —el QA, en este caso— marcó un ticket como cerrado después de validar el código. El cliente todavía no había revisado el cambio. Para el sistema, el ticket estaba listo. Para el cliente, no había pasado por su aprobación. Eso erosiona confianza. Cuando lo detecté, tenía dos caminos. Camino uno: desconfiar del sistema entero, volver al modelo donde un humano cierra cada ticket. Camino dos: agregar un guardrail puntual sobre el problema específico. Tomamos el camino dos. Implementamos un cierre dual-gate: ahora ningún agente puede mover un ticket a Done sin dos cosas. Primero, evidencia del QA, screenshots y reporte de la suite. Segundo, un comentario del cliente con una palabra clave de aprobación, en el ticket. Si falta cualquiera de los dos, el agente no puede cerrar. La validación corre antes de cualquier mutación, no después. Eso también es parte del trabajo. Armar guardrails cuando el sistema te muestra dónde tiene oportunidades de mejora. El error no fue del agente: fue del diseño. Y el diseño lo controlas tú. El squad evoluciona cada semana porque cada error se convierte en código nuevo del sistema. Esto que estás viendo no es la versión final. Es la versión que sobrevivió a todos los fallos que ya documentamos.

Quiero darte un nombre para lo que acabas de ver. Lo llamamos el modelo del vendedor de calendario versus el vendedor de output. El vendedor de calendario te factura por las horas que pasaste coordinando: más reuniones, más reportes, más alineación. Su precio escala con su tiempo. El vendedor de output te factura por el resultado: el ticket cerrado, el bug arreglado, el feature en producción. Su precio escala con la decisión, no con la coordinación. Cuando metes un squad en tu operación, no estás reduciendo costos. Estás cambiando lo que vendes. Pasas de cobrar por tu calendario a cobrar por tu output. Ese cambio es lo que te permite competir contra equipos con diez veces tu headcount. Si te llevas una sola idea de este video, llévate esta: deja de venderle tu calendario al cliente.

Antes del cierre, una cosa. Este squad no es un experimento. Ahora mismo está corriendo dieciséis agentes coordinados en producción. Cuatro bots activos en Slack y Telegram, atendiendo todo el día. Más de ciento cuarenta tickets cerrados en clientes reales este trimestre, con QA pasado y aprobación del cliente en el ticket. Lo que acabas de ver no es una demo. Es lo que estamos haciendo todos los días.

Lo que acabas de ver es lo que llamamos un squad: PMO orquestando, Architect diseñando, Developer ejecutando, QA validando con dual-gate. No es un agente solo. Es un equipo donde cada rol tiene su modelo, su prompt, sus herramientas. La parte que la mayoría no muestra cuando habla de agentes: el guardrail. Cada output pasa por dos validaciones automáticas antes de tocar producción. Por eso diecisiete minutos no es una demo controlada. Es un fix real, con commit en main, deploy en producción, y el cliente notificado. Tienes dos caminos según dónde estés hoy. Si ya estás considerando delegar parte de tu desarrollo a agentes, el link de la calculadora de ROI está en la descripción. Te toma pocos minutos. Te dice qué tareas de tu equipo son delegables, en cuánto tiempo, y cuánto te cuesta hoy versus cuánto te costaría con un squad funcionando. Si todavía estás explorando, no hay problema. Suscríbete al canal y activa la campana. El próximo video documenta otro caso real en un stack distinto. Una cosa más antes de irme. Si este video te aportó algo, déjame en los comentarios qué tipo de caso te gustaría ver resuelto por un squad. Los próximos episodios los priorizo según esos comentarios. Nos vemos en el siguiente.