Do squad ao pod: quem faz o quê no AI-DLC

O agente escreve o código. Quem recebe a ligação quando quebra continua sendo você.

Quase tudo o que se escreve sobre AI-DLC é sobre a máquina: fases, estágios, agentes, gates. A máquina é a parte fácil. O que mudou de verdade nos times que eu vi adotarem o método foi quem faz o quê, e se a organização percebeu a tempo.

AI-DLC é o AI-Driven Development Life Cycle, um método publicado pela AWS em que um agente de IA planeja o trabalho e escreve os artefatos enquanto as pessoas aprovam ou rejeitam nos gates. Acompanhei o rollout dentro de uma grande organização de engenharia, dos squads piloto às pessoas treinadas para espalhá-lo. As perguntas de ferramenta foram respondidas em semanas. As perguntas de papel continuam abertas, e são elas que decidem se o método sobrevive.

As pessoas decidem, a IA opera

A descrição mais limpa dessa divisão veio de uma das pessoas que trouxeram o AI-DLC para aquela organização, na primeira sessão do treinamento: a IA cuida do trabalho operacional, e as pessoas ficam com a definição do problema.

A divisão do trabalho

Uma Unit é uma parte da solução que pode ser construída de forma independente. Um gate é o ponto em que uma pessoa aprova antes de o próximo passo começar.

A IA faz	A pessoa faz
Refina uma intenção vaga em perguntas estruturadas	Define o problema e diz o que está fora do escopo
Escreve requisitos, histórias, designs e planos	Julga cada artefato no gate: Approve ou Request Changes
Decompõe o trabalho em Units e tarefas	Decide os trade-offs de arquitetura e de produto que a IA só consegue propor
Gera código e testes	Constrói os guardrails que avisam a IA quando ela está errada
Mantém o estado e a trilha de auditoria	Corrige a rota antes que um erro vire incidente

Leia a coluna da direita com atenção, porque ela não é menos trabalho. É outro trabalho. Julgar um documento de requisitos que você não escreveu exige mais conhecimento de domínio do que escrever um, porque você precisa enxergar o que está faltando, e o que falta não aparece na página. O trabalho saiu de produzir e foi para decidir, e decidir é a parte que nunca ficou mais barata.

Os squads encolhem para pods

A segunda mudança é o tamanho do time em volta de uma unidade de trabalho.

Squad ágil

1. 01Quatro a seis pessoas por squad
2. 02As pessoas começam o trabalho, a IA ajuda
3. 03Sprints de duas semanas
4. 04Daily, planning, review, retro

Pod de AI-DLC

1. 01Um engenheiro e um PM, mais dados ou design quando o trabalho tem essa superfície
2. 02A IA começa e conduz, as pessoas validam nos gates
3. 03Bolts de horas ou dias
4. 04Mob Elaboration, Mob Construction, gates de aprovação

Um pod funciona porque o agente cobre a amplitude operacional que antes precisava de mais mãos. Não funciona cortando gente e torcendo. As organizações que trataram pods como movimento de headcount pegaram o pior dos dois lados: menos gente, o mesmo processo, e um agente produzindo mais trabalho do que alguém tinha tempo de revisar.

A daily também muda. Quando o estado do trabalho mora num arquivo que o agente atualiza depois de cada passo, a daily deixa de ser um relatório de status. O guia do time naquele rollout definiu cinco minutos. Planning e Mob Elaboration também deixaram de ser a mesma reunião: o planning decide em que trabalhar, o mob decide o que esse trabalho realmente é.

Quem senta no mob

Mob Elaboration é o ritual do AI-DLC em que o time e o agente transformam uma intent em requisitos, histórias e Units numa sessão só. A regra que fez isso funcionar na prática era rígida: só entra quem tem poder de decisão sobre alguma dimensão do trabalho. Observadores inflam o custo sem trazer contexto.

Composição do mob por tipo de trabalho

Produto não precisa ficar nas perguntas técnicas. Chame para as de negócio.

Tipo de trabalho	Quem entra
Feature voltada ao usuário	Engenharia, produto, design
Dados ou machine learning	Engenharia, dados, produto
Mudança puramente técnica	Engenharia e uma pessoa de arquitetura
Otimização algorítmica	Engenharia e um especialista de domínio

Essa legenda é uma lição de piloto, não do método. Depois que o agente faz a engenharia reversa do código, ele faz uma lista longa de perguntas, e a maioria é técnica. O padrão que pegou foi simples: a engenharia responde as perguntas técnicas sozinha e chama produto para as de negócio, em blocos curtos. O ritual completo está no guia de Mob Elaboration.

O que cada disciplina faz agora

Antes e depois, por disciplina

Inception é a fase do AI-DLC em que o trabalho é definido antes de qualquer código ser escrito.

Disciplina	Antes	Com AI-DLC
Engenharia	Escreve o código	Valida e decide nos gates, é dona do que vai para produção
Produto	Escreve o PRD	Traz uma intent bem formada, responde as perguntas de negócio
Design	Produz wireframes	Valida a UX que o agente propõe, dentro do mob
Dados	Analisa depois do deploy	Define as métricas de sucesso antes de a Inception começar

A linha de produto é a que os times subestimam. O AI-DLC assume que a intent chega em boa forma, e o método quase não diz como. Quando produto traz um pedido vago, o agente preenche as lacunas com suposições genéricas e tudo o que vem depois herda essas suposições. Essa lacuna ganhou um artigo próprio.

Engenheiros de backend entregam front-end agora

Um princípio do whitepaper original da AWS é simplificar as responsabilidades: com a IA fazendo a decomposição e a geração, os devs conseguem atravessar os velhos silos de front-end, back-end, infraestrutura e segurança. Os pilotos que acompanhei relataram exatamente isso: engenheiros de backend entregando trabalho de front-end, e gente recém-contratada entregando mais rápido com menos onboarding, porque o agente carregava o contexto da codebase que essas pessoas ainda não tinham.

É um ganho real e tem um custo. Um engenheiro hoje consegue entregar uma tela numa stack que ele não saberia escrever na mão no mês passado. Tudo bem até a tela quebrar em produção e a pessoa de plantão não conseguir ler o código. A convergência amplia o que um engenheiro consegue entregar. Não amplia o que ele entende, a não ser que você abra espaço para isso.

O engenheiro continua dono do código

Esta é a frase que ouvi na primeiríssima sessão do treinamento, e é a que eu colocaria na parede: se isso for para produção e causar um incidente, quem vai ser chamado não é a IA. Somos nós.

O AI-DLC não move a responsabilidade. Move a autoria. O agente escreveu o código, e uma pessoa com nome aprovou no gate, então uma pessoa com nome é dona dele. O risco que os pilotos apontaram cedo é as pessoas começarem a focar em como usar a IA em vez de entender o código, e a posse ir se perdendo sem ninguém notar.

A pesquisa está começando a descrever a mesma coisa de fora. Uma análise de sobrevivência de mais de 200.000 unidades de código em 201 projetos open source, “Will It Survive?”, descobriu que o código escrito por agentes é modificado com menos frequência do que o código humano, e concluiu que o gargalo do código gerado por agentes talvez não seja a qualidade da geração, mas “as práticas organizacionais que governam a sua evolução de longo prazo”. Um segundo estudo, sobre arquivos gerados por IA em 100 repositórios, descobriu que eles recebem manutenção com menos frequência, e que desenvolvedores humanos fazem a grande maioria da manutenção que eles recebem. Código que ninguém sente que escreveu é código que ninguém quer mexer.

O manager segura o ritmo

O papel que mais mudou foi o que ninguém planejou: o engineering manager.

O AI-DLC produz artefatos em segundos e pede que uma pessoa julgue cada um. Sem alguém definindo o ritmo, a pressão de acompanhar a máquina vence. Numa das sessões do treinamento, uma pessoa do time descreveu ter chegado aos últimos documentos de uma Inception e percebido que não tinha mais atenção para revisá-los, e que se continuasse começaria a aprovar qualquer coisa. A correção a que os times piloto chegaram foi organizacional, não técnica: sessões de mais ou menos uma hora, depois uma pausa, e o arquivo de estado faz a pausa custar nada.

Alguém precisa garantir isso, e muitas vezes um tech lead não consegue, porque parar parece atrasar. Então o manager entra nos dois ou três primeiros mobs de todo time novo. Não para assistir. Para decidir quando parar, para notar quando as aprovações chegam sem perguntas, e para separar a curva em J, a queda esperada do cycle time enquanto um time aprende, de um problema estrutural de verdade. Presença sem intervenção é pior do que ausência, porque cria a ilusão de que alguém está supervisionando. Depois de alguns ciclos o time deveria regular o próprio ritmo, e se o manager ainda é necessário em todo mob, outra coisa está errada. A curva em si está em por que o AI-DLC te deixa mais lento primeiro.

Os seniores desaceleram, os juniores aceleram, e esse é o problema

O padrão que mais me preocupou apareceu no trabalho upstream, onde o agente rascunha os documentos que definem uma feature. Pessoas seniores com conhecimento profundo do domínio interrogavam cada afirmação do agente e demoravam mais. Pessoas com menos conhecimento do domínio aceitavam a primeira saída e andavam rápido. Quem sabe menos confia mais.

Isso inverte a ideia comum de que a IA ajuda mais os juniores. Velocidade num gate não é sinal de habilidade. Muitas vezes é o contrário. A resposta a que os pilotos chegaram não foi manter os juniores longe do AI-DLC, mas parar de colocá-los nos gates antes de terem contexto para julgar: tempo de estudo e onboarding primeiro, depois um gate, e por um tempo, uma pessoa sênior revisando junto.

A sua matriz de competências premia a coisa errada

Este é o problema em aberto, e eu não vi ninguém resolver.

Uma pessoa da gestão levantou o tema no fim do treinamento. Matrizes de competência premiam profundidade técnica em código: escrever, depurar, desenhar. No AI-DLC o agente escreve o código. O valor do engenheiro foi para especificar, revisar, decidir e pegar o código que funciona e mesmo assim está errado. Se a matriz continuar premiando volume de código, os engenheiros vão otimizar para volume, e num workflow agêntico isso quer dizer aprovar código gerado sem ler.

O exemplo do piloto ficou comigo. O agente gerou um processo que disparava centenas de queries no banco para uma única operação. Funcionava. Os testes passavam. Não teria sobrevivido à carga de produção. Foi pego no code review, por alguém lendo o código gerado linha por linha, do jeito lento. Esse tipo de achado é uma das coisas mais valiosas que um engenheiro faz hoje, e quase nenhuma matriz que eu conheço daria pontos para isso.

Comportamentos que valem ser premiados num time de AI-DLC

• ✓Obrigatório:
  Specs que um agente constrói certo na primeira passada.O rigor da especificação agora é a principal entrada da qualidade do código.
• ✓Obrigatório:
  Rejeições no gate com um motivo claro.Um Request Changes que barra um design errado cedo vale mais do que dez aprovações.
• ✓Obrigatório:
  Pegar código que funciona e está errado.Armadilhas de performance, falhas de segurança, lógica que passa nos testes e erra o requisito.
• ✓Obrigatório:
  Corrigir a causa, não o sintoma.Quando o agente erra, voltar para a spec ou para as regras em vez de remendar o código na mão.
• ✓Obrigatório:
  Ser dono do que aprovou.Conseguir explicar, depurar e rodar em produção o código que você assinou.
• ✗Anti-pattern:
  Tirar a profundidade técnica da matriz.A correção errada. Você ainda precisa entender código para revisá-lo. A ênfase muda. A profundidade fica.

O caminho até lá não é um framework novo vindo do RH. São managers que sentaram nos mobs anotando quais comportamentos viram que a matriz atual ignora, e ajustando em passos pequenos. O lado da medição, o que acompanhar no lugar dos story points, está em depois dos story points.

Os agentes são um mapa de papéis

O AI-DLC 2 torna o lado humano visível de um jeito fácil de passar despercebido. Os 14 agentes têm nomes de papéis: produto, design, entrega, arquitetura, plataforma AWS, compliance, DevSecOps, desenvolvimento, qualidade, pipeline e deploy, operações, mais dois revisores e um composer. A documentação chama a filosofia de “Small Mob, Broad Agents” e explica que ela espelha como times humanos eficientes trabalham: um mob de três a cinco pessoas cobrindo uma feature inteira, cada uma com habilidades amplas em vez de uma especialidade estreita.

É um espelho útil para uma liderança. Para cada agente da lista, pergunte qual pessoa do seu pod julga o que ele produz. Se ninguém no time consegue julgar o que o agente de compliance ou o agente de DevSecOps produz, o agente não está acrescentando cobertura. Está acrescentando saída sem revisão. O AI-DLC 2 também tem um modo de time, em que as pessoas reivindicam Units individuais e as constroem em paralelo, cada uma no seu checkout. Mais trabalho em paralelo deixa a pergunta mais afiada, não mais branda.

Perguntas frequentes

O AI-DLC elimina papéis?+

Muda mais do que elimina. O trabalho operacional de escrever documentos e código vai para o agente. Definir o problema, julgar os artefatos, decidir os trade-offs e ser dono da produção ficam com as pessoas. Os times ficam menores em volta de uma unidade de trabalho, mas o julgamento de que precisam não encolhe.

Quem aprova os gates no AI-DLC?+

A pessoa com poder de decisão sobre aquela dimensão do trabalho: alguém de engenharia ou de arquitetura para design e código, produto para requisitos e histórias. O AI-DLC 2 registra cada aprovação num log de auditoria. Garanta que toda aprovação tenha um dono com nome e tempo suficiente para ler de verdade o que aprova.

Ainda precisamos de engenheiros de QA?+

Sim, com outro trabalho. O AI-DLC 2 tem um agente de qualidade que escreve a estratégia de testes e os testes, o que tira a digitação, não o julgamento. Alguém ainda precisa decidir o que é bom o bastante, achar os casos que os testes gerados não cobrem e ser dono da release.

Como os juniores devem trabalhar no AI-DLC?+

Dê tempo de estudo e onboarding antes de colocá-los num gate, e no começo coloque uma pessoa sênior revisando junto. Os pilotos mostraram que quem tem menos conhecimento do domínio tende a aceitar a primeira saída do agente. Velocidade num gate não é sinal de habilidade.

Como avaliar engenheiros que não escrevem mais a maior parte do código?+

Ninguém tem uma resposta pronta. Comece premiando o que o trabalho pede agora: specs que o agente constrói certo, rejeições bem fundamentadas nos gates, pegar código que funciona e está errado, e posse do que você aprovou. Deixe os managers que participam dos mobs ajustarem a matriz a partir do que observam.

Para onde ir agora

O AI-DLC levou o código para o agente e deixou a responsabilidade com as pessoas. As organizações que se dão bem com ele são as que redesenham o lado humano de propósito: pods menores, um manager que protege o ritmo, gates com donos nomeados e uma matriz que premia julgamento em vez de teclas apertadas. As que pulam essa parte ganham código mais rápido e ninguém capaz de responder por ele.