Agentes geram funcionalidades; a equipe ainda precisa gerar confiança na integração

Rachel Laycock, CTO da Thoughtworks, relata um experimento em que uma equipe passou uma semana construindo uma aplicação sem escrever código manualmente.[13] O grupo estimou dedicar dois terços do tempo ao entendimento de domínio, limites e planejamento, e um terço ao ambiente de orientação e verificação dos agentes.[13] A aplicação executava, mas o build ficava frequentemente vermelho.[13]

O que muda para quem desenvolve

O contraste entre funcionalidade visível e integração instável é o centro da discussão. Laycock argumenta que a cautela de profissionais experientes envolve operação, evolução e fronteiras arquiteturais, não apenas apego ao ato de programar.[13] A capacidade de produzir uma primeira versão não responde, sozinha, como o sistema vai sobreviver às próximas mudanças.

O texto levanta hipóteses para o build instável, incluindo interferência entre agentes, modularidade insuficiente e alterações chegando mais rápido que a verificação.[13] Não demonstra qual delas foi a causa.[13] Essa distinção importa: um experimento exploratório ajuda a formular perguntas, não autoriza uma conclusão causal pronta.

Minha leitura é tratar integração como capacidade limitada. Antes de aumentar a geração de funcionalidades, é preciso saber quanto trabalho o sistema de revisão e aceitação consegue absorver sem perder significado. Um pipeline sempre quebrado deixa de fornecer um sinal útil, mesmo que cada agente declare sua tarefa concluída.

Como aplicar

Proponha um piloto com uma aplicação pequena e critérios de aceite escritos antes da implementação. Dê a cada tarefa uma fronteira clara e limite a quantidade de mudanças concorrentes. Registre o que cada agente pode alterar e quais contratos não podem mudar unilateralmente.

Compare duas rodadas semelhantes: uma com lotes pequenos e outra com escopo maior. Meça tempo até integração aceita, regressões, retrabalho e tempo de recuperação de falhas. Não use linhas de código como substituto de entrega. Inclua uma alteração posterior para avaliar se a primeira solução continua compreensível e modificável.

Mantenha exemplos de aceitação independentes da implementação. Quando o mesmo agente escreve código e testes, peça evidências de comportamento contra esses exemplos, em vez de aceitar apenas a existência de uma suíte que passa. Faça da conclusão da tarefa um estado demonstrável do produto integrado.

Cuidados e limites

O exercício foi repetido com outra equipe, sem pretensão de resolver as questões em duas semanas.[13] O artigo é uma análise apoiada em experiência, não um estudo controlado que quantifique um ganho universal de produtividade.[13]

A autora defende renovar práticas de entrega contínua e DevOps, não abandoná-las.[13] Esse é um limite importante para qualquer discurso de substituição total. Automatizar a escrita pode mudar onde a equipe investe esforço; não torna dispensável a responsabilidade pelo comportamento e pela manutenção do sistema entregue.

Fonte

[13] Fonte: Martin Fowler / Rachel Laycock