Del squad al pod: quién hace qué en AI-DLC

El agente escribe el código. Cuando se rompe, a quien llaman sigue siendo a ti.

Casi todo lo que se escribe sobre AI-DLC trata de la maquinaria: fases, etapas, agentes, gates. La maquinaria es la parte fácil. Lo que de verdad cambió en los equipos que vi adoptarlo fue quién hace qué, y si la organización se dio cuenta a tiempo.

AI-DLC es el AI-Driven Development Life Cycle, un método publicado por AWS en el que un agente de IA planifica el trabajo y escribe los artefactos mientras las personas los aprueban o rechazan en los gates. Seguí su rollout dentro de una gran organización de ingeniería, de los squads piloto a las personas formadas para llevarlo a todos lados. Las preguntas de herramientas se respondieron en semanas. Las preguntas de roles siguen abiertas, y son las que deciden si el método sobrevive.

Las personas deciden, la IA opera

La descripción más limpia de esa división vino de una de las personas que trajeron AI-DLC a esa organización, en la primera sesión de la formación: la IA se encarga del trabajo operativo, y las personas se quedan con la definición del problema.

La división del trabajo

Una Unit es una parte de la solución que se puede construir de forma independiente. Un gate es el punto donde una persona aprueba antes de que empiece el siguiente paso.

La IA hace	La persona hace
Refina una intención vaga en preguntas estructuradas	Define el problema y dice qué queda fuera del alcance
Escribe requisitos, historias, diseños y planes	Juzga cada artefacto en el gate: Approve o Request Changes
Descompone el trabajo en Units y tareas	Decide los trade-offs de arquitectura y de producto que la IA solo puede proponer
Genera código y pruebas	Construye los guardrails que le avisan a la IA cuando se equivoca
Mantiene el estado y la traza de auditoría	Corrige el rumbo antes de que un error se vuelva incidente

Lee la columna de la derecha con cuidado, porque no es menos trabajo. Es otro trabajo. Juzgar un documento de requisitos que no escribiste exige más conocimiento del dominio que escribirlo, porque tienes que ver lo que falta, y lo que falta no aparece en la página. El trabajo pasó de producir a decidir, y decidir es la parte que nunca se abarató.

Los squads se achican hacia pods

El segundo cambio es el tamaño del equipo alrededor de una pieza de trabajo.

Squad ágil

1. 01De cuatro a seis personas por squad
2. 02Las personas empiezan el trabajo, la IA asiste
3. 03Sprints de dos semanas
4. 04Daily, planning, review, retro

Pod de AI-DLC

1. 01Un ingeniero y un PM, más datos o diseño cuando el trabajo tiene esa superficie
2. 02La IA empieza y conduce, las personas validan en los gates
3. 03Bolts de horas o días
4. 04Mob Elaboration, Mob Construction, gates de aprobación

Un pod funciona porque el agente cubre la amplitud operativa que antes necesitaba más manos. No funciona recortando gente y esperando lo mejor. Las organizaciones que trataron los pods como una jugada de headcount se llevaron lo peor de los dos mundos: menos gente, el mismo proceso, y un agente produciendo más trabajo del que alguien tenía tiempo de revisar.

La daily también cambia. Cuando el estado del trabajo vive en un archivo que el agente actualiza después de cada paso, la daily deja de ser un reporte de estado. La guía del equipo en ese rollout la fijó en cinco minutos. El planning y el Mob Elaboration también dejaron de ser la misma reunión: el planning decide en qué trabajar, el mob decide qué es realmente ese trabajo.

Quién se sienta en el mob

Mob Elaboration es el ritual de AI-DLC en el que el equipo y el agente convierten una intent en requisitos, historias y Units en una sola sesión. La regla que lo hizo funcionar en la práctica era estricta: solo entra quien tiene poder de decisión sobre alguna dimensión del trabajo. Los observadores inflan el costo sin aportar contexto.

Composición del mob según el tipo de trabajo

Producto no necesita quedarse en las preguntas técnicas. Llámalo para las de negocio.

Tipo de trabajo	Quién entra
Feature de cara al usuario	Ingeniería, producto, diseño
Datos o machine learning	Ingeniería, datos, producto
Cambio puramente técnico	Ingeniería y una persona de arquitectura
Optimización algorítmica	Ingeniería y un especialista del dominio

Esa leyenda es una lección de un piloto, no del método. Después de que el agente hace la ingeniería inversa del código, hace una lista larga de preguntas, y la mayoría son técnicas. El patrón que quedó fue simple: ingeniería responde sola las preguntas técnicas y llama a producto para las de negocio, en bloques cortos. El ritual completo está en la guía de Mob Elaboration.

Qué hace cada disciplina ahora

Antes y después, por disciplina

Inception es la fase de AI-DLC en la que se define el trabajo antes de escribir cualquier código.

Disciplina	Antes	Con AI-DLC
Ingeniería	Escribe el código	Valida y decide en los gates, es dueña de lo que llega a producción
Producto	Escribe el PRD	Trae una intent bien formada, responde las preguntas de negocio
Diseño	Produce wireframes	Valida la UX que propone el agente, dentro del mob
Datos	Analiza después del despliegue	Define las métricas de éxito antes de que empiece la Inception

La fila de producto es la que los equipos subestiman. AI-DLC asume que la intent llega en buena forma, y el método casi no dice cómo. Cuando producto trae un pedido vago, el agente llena los huecos con suposiciones genéricas y todo lo que viene después las hereda. Ese hueco tiene su propio artículo.

Los ingenieros de backend ahora entregan front-end

Un principio del whitepaper original de AWS es simplificar las responsabilidades: con la IA haciendo la descomposición y la generación, los devs pueden cruzar los viejos silos de front-end, back-end, infraestructura y seguridad. Los pilotos que seguí reportaron exactamente eso: ingenieros de backend entregando trabajo de front-end, y gente recién contratada entregando más rápido con menos onboarding, porque el agente cargaba el contexto de la codebase que esas personas todavía no tenían.

Es una ganancia real y tiene un costo. Un ingeniero hoy puede entregar una pantalla en un stack que el mes pasado no habría sabido escribir a mano. Todo bien hasta que la pantalla se rompe en producción y la persona de guardia no puede leer el código. La convergencia amplía lo que un ingeniero puede entregar. No amplía lo que entiende, a menos que hagas lugar para eso.

El ingeniero sigue siendo dueño del código

Esta es la frase que escuché en la primerísima sesión de la formación, y es la que pondría en la pared: si esto llega a producción y causa un incidente, al que van a llamar no es a la IA. Es a nosotros.

AI-DLC no mueve la responsabilidad. Mueve la autoría. El agente escribió el código, y una persona con nombre lo aprobó en el gate, así que una persona con nombre es su dueña. El riesgo que los pilotos señalaron temprano es que la gente empiece a enfocarse en cómo usar la IA en lugar de entender el código, y que la propiedad se vaya erosionando sin que nadie lo note.

La investigación empieza a describir lo mismo desde afuera. Un análisis de supervivencia de más de 200.000 unidades de código en 201 proyectos open source, “Will It Survive?”, encontró que el código escrito por agentes se modifica con menos frecuencia que el código humano, y concluyó que el cuello de botella del código generado por agentes quizá no sea la calidad de la generación, sino “las prácticas organizacionales que gobiernan su evolución a largo plazo”. Un segundo estudio, sobre archivos generados por IA en 100 repositorios, encontró que reciben mantenimiento con menos frecuencia, y que los desarrolladores humanos hacen la gran mayoría del mantenimiento que sí reciben. El código que nadie siente que escribió es código que nadie quiere tocar.

El manager sostiene el ritmo

El rol que más cambió fue el que nadie planificó: el engineering manager.

AI-DLC produce artefactos en segundos y le pide a una persona que juzgue cada uno. Sin alguien que marque el ritmo, gana la presión por seguirle el paso a la máquina. En una de las sesiones de la formación, una persona del equipo describió que llegó a los últimos documentos de una Inception y se dio cuenta de que ya no le quedaba atención para revisarlos, y que si seguía iba a empezar a aprobar cualquier cosa. La solución a la que llegaron los equipos piloto fue organizacional, no técnica: sesiones de alrededor de una hora, después una pausa, y el archivo de estado hace que la pausa no cueste nada.

Alguien tiene que hacer cumplir eso, y muchas veces un tech lead no puede, porque parar parece ir más lento. Así que el manager entra en los dos o tres primeros mobs de cada equipo nuevo. No para mirar. Para decidir cuándo parar, para notar cuándo las aprobaciones llegan sin preguntas, y para distinguir la curva en J, la caída esperada del cycle time mientras un equipo aprende, de un problema estructural real. Estar presente sin intervenir es peor que no estar, porque crea la ilusión de que alguien supervisa. Después de algunos ciclos el equipo debería regular su propio ritmo, y si el manager todavía hace falta en cada mob, algo más está mal. La curva en sí está en por qué AI-DLC te hace más lento primero.

Los seniors frenan, los juniors aceleran, y ese es el problema

El patrón que más me preocupó apareció en el trabajo upstream, donde el agente redacta los documentos que definen una feature. Las personas senior con conocimiento profundo del dominio interrogaban cada afirmación del agente y tardaban más. Las personas con menos conocimiento del dominio aceptaban la primera salida y avanzaban rápido. Quien menos sabe es quien más confía.

Eso invierte la suposición habitual de que la IA ayuda más a los juniors. La velocidad en un gate no es señal de habilidad. Muchas veces es lo contrario. La respuesta a la que llegaron los pilotos no fue mantener a los juniors lejos de AI-DLC, sino dejar de ponerlos en los gates antes de que tuvieran contexto para juzgar: tiempo de estudio y onboarding primero, después un gate, y por un tiempo, una persona senior revisando al lado.

Tu matriz de competencias premia lo equivocado

Este es el problema abierto, y no vi a nadie resolverlo.

Una persona de gestión lo planteó al final de la formación. Las matrices de competencias premian la profundidad técnica en código: escribirlo, depurarlo, diseñarlo. En AI-DLC el agente escribe el código. El valor del ingeniero pasó a especificar, revisar, decidir y atrapar el código que funciona y aun así está mal. Si la matriz sigue premiando volumen de código, los ingenieros van a optimizar volumen, y en un workflow agéntico eso significa aprobar código generado sin leerlo.

El ejemplo del piloto se me quedó. El agente generó un proceso que disparaba cientos de queries a la base de datos para una sola operación. Funcionaba. Las pruebas pasaban. No habría sobrevivido a la carga de producción. Se atrapó en el code review, gracias a alguien que leyó el código generado línea por línea, por el camino lento. Ese tipo de hallazgo es de lo más valioso que hace un ingeniero hoy, y casi ninguna matriz que conozco lo puntuaría.

Comportamientos que vale la pena premiar en un equipo de AI-DLC

• ✓Obligatorio:
  Specs que un agente construye bien a la primera.El rigor de la especificación es ahora la entrada principal de la calidad del código.
• ✓Obligatorio:
  Rechazos en el gate con una razón clara.Un Request Changes que frena un diseño equivocado temprano vale más que diez aprobaciones.
• ✓Obligatorio:
  Atrapar código que funciona y está mal.Trampas de performance, agujeros de seguridad, lógica que pasa las pruebas y no cumple el requisito.
• ✓Obligatorio:
  Corregir la causa, no el síntoma.Cuando el agente se equivoca, volver a la spec o a las reglas en lugar de parchar el código a mano.
• ✓Obligatorio:
  Ser dueño de lo que aprobaste.Poder explicar, depurar y operar en producción el código que firmaste.
• ✗Anti-pattern:
  Sacar la profundidad técnica de la matriz.La corrección equivocada. Todavía necesitas entender código para revisarlo. El énfasis cambia. La profundidad se queda.

El camino no es un framework nuevo que baja de RR. HH. Son managers que estuvieron en los mobs anotando qué comportamientos vieron que la matriz actual ignora, y ajustándola en pasos chicos. El lado de la medición, qué seguir en lugar de los story points, está en después de los story points.

Los agentes son un mapa de roles

AI-DLC 2 hace visible el lado humano de una forma fácil de pasar por alto. Sus 14 agentes llevan nombres de roles: producto, diseño, entrega, arquitectura, plataforma AWS, compliance, DevSecOps, desarrollo, calidad, pipeline y despliegue, operaciones, más dos revisores y un composer. La documentación llama a la filosofía “Small Mob, Broad Agents” y explica que refleja cómo trabajan los equipos humanos efectivos: un mob de tres a cinco personas que cubre una feature entera, cada una con habilidades amplias en lugar de una especialidad angosta.

Es un espejo útil para quien lidera. Para cada agente de la lista, pregunta qué persona de tu pod juzga lo que produce. Si nadie en el equipo puede juzgar lo que produce el agente de compliance o el de DevSecOps, el agente no está sumando cobertura. Está sumando salida sin revisar. AI-DLC 2 también tiene un modo de equipo, en el que las personas reclaman Units individuales y las construyen en paralelo, cada una en su propio checkout. Más trabajo en paralelo vuelve la pregunta más filosa, no más blanda.

Preguntas frecuentes

¿AI-DLC elimina roles?+

Los cambia más de lo que los elimina. El trabajo operativo de escribir documentos y código pasa al agente. Definir el problema, juzgar los artefactos, decidir los trade-offs y ser dueño de producción se queda con las personas. Los equipos se achican alrededor de una pieza de trabajo, pero el criterio que necesitan no se achica.

¿Quién aprueba los gates en AI-DLC?+

La persona con poder de decisión sobre esa dimensión del trabajo: alguien de ingeniería o de arquitectura para diseño y código, producto para requisitos e historias. AI-DLC 2 registra cada aprobación en un log de auditoría. Asegúrate de que cada aprobación tenga un dueño con nombre y tiempo suficiente para leer de verdad lo que aprueba.

¿Todavía necesitamos ingenieros de QA?+

Sí, con otro trabajo. AI-DLC 2 tiene un agente de calidad que escribe la estrategia de pruebas y las pruebas, lo que elimina el tipeo, no el criterio. Alguien todavía tiene que decidir qué es suficientemente bueno, encontrar los casos que las pruebas generadas no cubren y ser dueño de la release.

¿Cómo deberían trabajar los juniors en AI-DLC?+

Dales tiempo de estudio y onboarding antes de ponerlos en un gate, y al principio pon a una persona senior revisando con ellos. Los pilotos mostraron que quien tiene menos conocimiento del dominio tiende a aceptar la primera salida del agente. La velocidad en un gate no es señal de habilidad.

¿Cómo evaluamos a ingenieros que ya no escriben la mayor parte del código?+

Nadie tiene una respuesta terminada. Empieza premiando lo que el trabajo necesita ahora: specs que el agente construye bien, rechazos bien fundamentados en los gates, atrapar código que funciona y está mal, y ser dueño de lo que aprobaste. Deja que los managers que asisten a los mobs ajusten la matriz a partir de lo que observan.

A dónde ir ahora

AI-DLC llevó el código al agente y dejó la responsabilidad en las personas. Las organizaciones a las que les va bien son las que rediseñan el lado humano a propósito: pods más chicos, un manager que protege el ritmo, gates con dueños con nombre y una matriz que premia el criterio en lugar de las teclas. Las que se saltan esa parte obtienen código más rápido y nadie que pueda responder por él.