Por que o AI-DLC te deixa mais lento primeiro

O agente tira o gargalo que você conseguia ver. O que você não via sempre foi o review, e agora ele é o único que sobrou.

Todos os squads piloto do rollout que acompanhei desenharam a mesma curva. O número de mudanças mergeadas por dev subiu desde a primeira semana. O tempo entre o primeiro commit e o deploy também subiu, que é a direção errada, e ficou lá por um tempo antes de cair.

Isso é uma curva em J: as coisas pioram antes de melhorar. Quem trabalha com gestão de mudança desenha essa curva há décadas, para toda mudança de processo séria. O que torna a versão do AI-DLC digna de um artigo é que as duas curvas se separam. Uma métrica parece ótima desde o primeiro dia. A outra parece péssima. Se você olha só a primeira, declara vitória cedo demais. Se olha só a segunda, mata o piloto bem no fundo da queda, que é o momento mais caro para desistir.

Este artigo é sobre o que causa a queda, por que ela cai no code review, e como diferenciar um time que está aprendendo de um time que está travado.

Duas métricas, duas curvas

Comece pelas definições, porque o argumento inteiro depende delas.

Throughput é quanto é mergeado: merge requests por dev por mês, por exemplo. Mede saída. Cycle time é quanto tempo uma mudança leva do primeiro commit até o início do deploy. Mede fluxo, a velocidade com que um trabalho isolado anda pelo sistema.

Num time normal, as duas andam juntas. Escreve mais código, entrega mais código. Num rollout de AI-DLC elas se separam, porque o método torna uma parte do trabalho quase de graça e deixa a outra exatamente tão cara quanto era.

O formato de uma adoção de AI-DLC

1. Primeiras semanasO throughput dispara, o cycle time sobe

   O agente gera código na hora, então mais mudanças são abertas e mergeadas. O processo novo é lento: sessões longas de Mob Elaboration, agentes chutando em repositórios que ninguém preparou para eles, Inceptions recomeçadas do zero.

2. A quedaUma fila se forma na frente do review

   Merge requests em maior número e maiores chegam às mesmas pessoas que já revisavam antes. As mudanças esperam. O cycle time chega ao pior ponto enquanto o throughput ainda parece um sucesso.

3. RecuperaçãoUnits menores, gates com fluência, repositórios preparados

   O time limita o tamanho de cada Unit, o repo ganha um mapa legível para o agente, as pessoas aprendem quais perguntas responder no mob. O cycle time começa a cair e continua caindo.

4. DepoisAs duas curvas apontam para o lado certo

   A saída continua alta e cada mudança anda mais rápido do que antes do método. É o estado a que o piloto deveria chegar.

Por que a curva cai

Três coisas deixam um time mais lento no começo, e nenhuma delas é o agente ser lento.

O que deixa um time de AI-DLC mais lento primeiro

As duas primeiras somem com a prática. A terceira é estrutural, e é ela que mata pilotos.

Causa	Como aparece	Quando vai embora
Choque de processo	Mob Elaboration síncrono substitui refinamento assíncrono. Todo mundo numa sessão por horas, mais discussão do que antes.	Quando o time aprende quais perguntas precisam de todo mundo e quais não.
Repositórios despreparados	O agente faz perguntas triviais, chuta padrões errados, e o time recomeça a Inception.	Quando o repo tem um mapa curto, legível para o agente, da stack e dos padrões.
A fila de review	Chega mais código, em merge requests maiores, para os mesmos revisores.	Só quando alguém muda o tamanho do trabalho. Ela não se resolve sozinha.

As duas primeiras são curva de aprendizado no sentido literal. Pessoas e repositórios ficam melhores no método, e o custo cai. Dá para esperar passar.

A terceira não dá para esperar passar. Ela é o motivo de a curva ter esse formato.

O review é o novo gargalo

O mecanismo, nas palavras de um engenheiro que viveu isso num dos pilotos. No começo o cycle time subiu pela própria adoção. Depois o throughput disparou, mas o cycle time não descia, porque o time tinha caído numa armadilha simples: o agente escreve código muito rápido, as pessoas abrem muitos merge requests, e tudo trava no review.

Piorou quando o time paralelizou. Vários engenheiros rodavam as próprias Units ao mesmo tempo, cada um produzindo merge requests grandes, e o repositório virou um caos. Uma ou duas Units que deveriam ser pequenas acabaram virando merge requests que ninguém conseguia revisar de uma vez.

Pense numa rodovia que ganha duas faixas a mais até um pedágio que continua com uma cabine só aberta. Mais carros chegam mais rápido. A fila no pedágio fica maior. A viagem leva mais tempo, não menos.

É o que acontece quando gerar fica barato e revisar não. O agente não deixou o seu time mais rápido na etapa mais lenta. Deixou mais rápida cada etapa antes da mais lenta, o que só aumenta a fila na frente dela. Escrevi sobre a mesma mudança para times que usam Spec-Driven Development: quando todo mundo tem um agente, produzir código deixa de ser o recurso escasso e integrar vira o trabalho.

Limite o tamanho da Unit, não a velocidade do agente

Não dá para resolver um gargalo de review revisando mais rápido. Revisor com pressa é como código ruim chega em produção. Você resolve mudando o que chega no review.

O AI-DLC te dá a alavanca no momento certo. Antes de a Construction começar, o agente propõe como dividir o trabalho em Units, e você aprova esse plano. É ali que se impõe um limite de tamanho, não depois que os merge requests estão abertos. Os times que se recuperaram fizeram duas coisas: pediram ao agente uma estimativa do tamanho de cada Unit antes de aprovar o plano, e combinaram como time o maior merge request que uma pessoa consegue revisar com cuidado de uma vez.

Como manter as Units revisáveis

1. 01

   Peça o tamanho antes de aprovar o plano.

   O plano é o lugar mais barato para dividir o trabalho. Depois que o código existe, dividir é refazer.

   Digite isto

   Before I approve these Units, estimate the files and lines each one will change, and flag any Unit that touches more than one layer.

2. 02

   Divida o que passar do limite do time.

   Um merge request com centenas de mudanças leva uma olhada, não um review. Até uma tarefa que parece pequena pode mexer em migration, entidade, API e testes ao mesmo tempo.

   Digite isto

   Unit 3 is too big to review in one sitting. Split it by endpoint, and put the database migration in its own Unit.

3. 03

   Transforme o limite em regra, não em lembrança.

   Um limite que mora na cabeça de um revisor é esquecido na próxima sessão. No AI-DLC 2, uma regra de projeto é carregada no começo de todo workflow.

   Digite isto

   Add to the project rules: no Unit may produce a merge request a reviewer cannot read carefully in one sitting. Estimate size before proposing Units.

O limite exato é decisão do time. O que importa é que ele exista, que seja aplicado no plano e que o agente saiba dele antes de propor qualquer coisa.

As evidências públicas dizem o mesmo

Nada disso é exclusivo da organização que acompanhei. A pesquisa pública aponta na mesma direção, por ângulos diferentes.

O estudo randomizado do METR é o mais afiado. Desenvolvedores experientes de open source, trabalhando em código que conheciam bem, levaram cerca de 19% mais tempo com ferramentas de IA, enquanto achavam que tinham ficado cerca de 20% mais rápidos. A lição para um rollout de AI-DLC não é que a IA deixa as pessoas lentas. É que sentir-se mais rápido e ser mais rápido são medidas diferentes, e a sensação é o que todo mundo relata na retro. Meça o cycle time. Não pergunte às pessoas como elas se sentem.

A pesquisa do DORA defende a mesma coisa há anos pelo outro lado: lead time, frequência de deploy, taxa de falha em mudanças e tempo de recuperação são o que prevê desempenho de entrega. Volume de saída não está nessa lista. A análise de AIDLC da Augment Code resume o estado atual sem rodeio: a adoção de IA entre desenvolvedores é quase universal, e as métricas de entrega mal se mexeram, porque ferramentas presas a um engenheiro otimizam teclas digitadas e nada coordena o resto.

O estudo da Microsoft sobre o próprio rollout de Claude Code e Copilot CLI, no começo de 2026, para dezenas de milhares de engenheiros (arXiv 2607.01418), encontrou que quem adotou mergeou cerca de 24% mais pull requests do que teria mergeado sem. Os autores têm o cuidado de dizer o que isso não significa: um pull request mergeado não é a mesma coisa que o valor que ele entrega. É a curva de throughput, bem medida e rotulada com honestidade. Ela ainda não diz nada sobre a fila.

Curva de aprendizado ou problema real?

A queda é esperada. Isso não quer dizer que toda queda é a curva em J. Às vezes o método realmente não encaixa no trabalho, e esperar mais só aumenta a conta.

Marque um ponto de decisão em umas quatro semanas, e diga isso em voz alta antes de o piloto começar. Se o cycle time não começou a virar até lá, pare de perguntar “é a curva?” e comece a perguntar “o que está estruturalmente errado?”

Ainda é a curva em J

1. 01O cycle time está alto, mas já começou a virar
2. 02As sessões de mob ficam mais curtas a cada semana
3. 03O agente faz menos perguntas triviais sobre o repo
4. 04Os merge requests estão menores desde a regra de tamanho
5. 05Os revisores estão atrasados, mas a fila está diminuindo

Um problema estrutural

1. 01O cycle time está parado ou ainda subindo depois de um mês
2. 02O trabalho é quase todo correção de uma linha, para a qual o método nunca foi feito
3. 03O repo ainda não tem um mapa de si mesmo legível para o agente
4. 04Ninguém no mob conhece o domínio bem o bastante para julgar os artefatos
5. 05Os gates são aprovados sem perguntas, e o retrabalho aparece no review

Cada problema estrutural tem uma solução, e a maioria está em outras partes desta série. Um repositório despreparado é um problema de brownfield. Gates carimbados são um problema de desenho de gate. Usar um ciclo de 33 estágios numa mudança de uma linha é um problema de perfil: o AI-DLC 2 entrega um perfil Bugfix com 9 estágios por um motivo, e às vezes o perfil certo é nenhum.

O papel do manager durante a queda

A curva em J é um problema de gestão antes de ser um problema técnico, porque quem decide se o piloto sobrevive costuma ser quem está olhando para o pior número.

A recomendação que saiu do rollout foi chata e específica. Antes de o piloto começar, o manager avisa o time que as primeiras semanas vão ser mais lentas e que isso é esperado, não um fracasso. Depois o manager participa dos dois ou três primeiros mobs, não como observador, mas como a pessoa com autoridade para dizer “a gente para aqui e continua amanhã”. Um tech lead tem autoridade técnica para questionar um artefato. O manager tem autoridade organizacional para desacelerar a sessão inteira sem que ninguém leia isso como fracasso individual.

Leia o throughput só ao lado do cycle time

A regra prática que sai de tudo isso cabe numa frase: nunca olhe o throughput sozinho.

Coloque três números na mesma tela. Throughput, para saber que a saída está subindo. Cycle time, para saber se uma mudança isolada anda mais rápido ou só espera mais. E retrabalho, a parcela de artefatos e merge requests devolvidos com mudanças pedidas, para saber se a velocidade é real ou emprestada da próxima sprint. O guia de métricas passa pelo que substitui story points e velocity quando o AI-DLC está rodando.

Perguntas frequentes

A curva em J é normal ao adotar agentes de IA para código?+

É. Toda mudança de processo séria produz uma queda inicial antes dos ganhos, e o AI-DLC é uma mudança de processo, não a instalação de uma ferramenta.

O que é específico do AI-DLC é que a queda aparece no cycle time enquanto o throughput sobe desde o primeiro dia. Gerar fica barato na hora. Revisar e validar não.

Quanto tempo dura a curva em J do AI-DLC?+

Tempo suficiente para assustar um manager e curto o suficiente para valer a pena, se as causas forem do tipo aprendizado. Marque um ponto de decisão em umas quatro semanas: se o cycle time não começou a virar até lá, procure uma causa estrutural em vez de esperar mais.

Por que o cycle time piora com agentes de IA?+

Porque o agente produz mais mudanças, e maiores, do que a capacidade de review do time consegue absorver. As mudanças esperam numa fila na frente dos mesmos revisores humanos, então cada uma leva mais tempo do primeiro commit ao deploy, mesmo com o código escrito mais rápido.

Um modelo mais rápido ou mais inteligente resolve a queda?+

Não. Um modelo mais rápido escreve código mais rápido, o que deixa a fila de review maior. A solução está do lado humano: Units menores, um limite de tamanho aplicado no plano, repositórios preparados e um ritmo que mantenha os gates com sentido.

Devemos parar o piloto se o cycle time piorar?+

Não nas primeiras semanas. Espere por isso, e avise o time para esperar também. Marque um ponto de decisão em torno de quatro semanas, e use-o para separar uma curva de aprendizado de um problema estrutural, como repositórios despreparados, trabalho pequeno demais para o método ou gates que ninguém consegue julgar.

O que medir em vez de só throughput?+

Throughput ao lado do cycle time, mais retrabalho: com que frequência artefatos e merge requests voltam com mudanças pedidas. Throughput sozinho mostra uma fila crescendo e chama isso de sucesso.

Para onde ir agora

A curva em J é a coisa mais previsível de um rollout de AI-DLC, e o motivo mais comum para pilotos morrerem cedo. Espere por ela, explique antes de começar, limite o tamanho do trabalho no plano e coloque o cycle time ao lado de todo gráfico de throughput que você mostrar. Depois decida com dados na quarta semana, e não com o nervosismo da segunda.