Habr: Agentes de IA transformam delivery, e equipes precisam reconstruir todo o ciclo de desenvolvimento

No Habr, houve uma análise de por que, com a chegada dos agentes de IA, as equipes de engenharia esbarram não na velocidade de escrita de código, mas no custo de revisão e transferência de contexto. O autor faz referência ao DORA 2025, onde 90% dos especialistas em tecnologia usam IA no trabalho, e mais de 80% a vinculam ao crescimento de produtividade. Mas quanto mais rápido são criados código, ADR e documentação, maior se torna a carga em revisão e controle de estabilidade.

Portanto, propõe-se considerar a IA não como mais uma ferramenta dentro do processo antigo, mas como uma razão para remontar todo o ciclo de entrega de mudanças. O artigo distingue três modos de operação. O primeiro é desenvolvimento assistido por IA, onde o modelo ajuda a reunir requisitos mais rapidamente, escrever rascunhos de ADR, casos de teste ou documentação, mas o processo em si permanece o mesmo.

O segundo é entrega por agente, onde o agente já lê o repositório, prepara mudanças, executa verificações e abre PRs, enquanto os humanos se envolvem em escalações. O autor menciona o lançamento do GitHub Copilot coding agent para disponibilidade geral como um exemplo dessa mudança. O terceiro modo é SDLC nativo de IA: aqui o LLM deixa de ser um "chat ao lado" e se torna uma interface para o loop de trabalho, através do qual a equipe move uma tarefa da ideia até o lançamento.

A tese principal do texto é que a economia de tal transição é construída não em torno do código, mas em torno da comunicação. Na entrega real, o que é caro não é apenas as mudanças em si, mas também a transferência de trabalho entre análise, desenvolvimento, testes e operações, a reconstrução de conhecimento e constantes esclarecimentos. Quando a geração se acelera, o gargalo se desloca para acordos, validação e controle de risco.

Portanto, as equipes precisam de um contexto externo, legível para máquinas e disponível tanto para pessoas quanto para agentes: objetivos, restrições, riscos, critérios de prontidão, ADRs, contratos de API, regras de segurança, equipes de validação local e notas de rollout. Se o conhecimento crítico continua a viver em chats, chamadas e na memória de desenvolvedores individuais, o agente simplesmente trabalha com uma imagem incompleta. Isso leva a um novo foco em harness—o ambiente de execução dos agentes.

Não se trata mais de um grande prompt do sistema, mas de um conjunto de regras e restrições incorporadas no processo. O repositório deve ter instruções explícitas para agentes, equipes de construção e testes, critérios de prontidão, restrições arquitetônicas e de segurança. Cenários repetíveis são propostos para serem formatados como skills, playbooks e regras de repositório, em vez de serem explicados novamente em cada chat.

Além disso, as restrições não devem ser apenas textuais: o sistema deve ser capaz de parar ações arriscadas, proibir merges sem confirmações e rotear etapas contestadas para humanos. O autor discute separadamente a camada de controle. A revisão não deve receber apenas um diff, mas um evidence pack: o que exatamente mudou, quais cenários estão cobertos, quais verificações foram executadas, quais riscos permanecem e como fazer rollback da mudança.

Acima disso, são necessários quality gates—limites no tamanho das mudanças, comandos validate obrigatórios, verificação de restrições arquitetônicas e atualização síncrona da documentação. Outra camada são evals para tarefas repetidas. Eles permitem fixar explicitamente o comportamento esperado do agente e verificar se o workflow permanece estável após cada mudança, em vez de deslizar para uma versão cara de vibe coding com um fluxo de PRs ruidosos.

Após o lançamento, segundo o autor, deve-se monitorar não apenas o produto, mas também o próprio processo de entrega. A equipe deve analisar onde o agente careceu de contexto, quais regras se mostraram fracas, quais tarefas eram grandes demais para delegação segura, e onde a revisão se afogou no ruído. Isso afeta diretamente a organização: cresce o valor dos engenheiros de perfil amplo, fortalece-se o papel da engenharia de plataforma e ferramentas internas, e o onboarding de juniores deixa de ser um efeito colateral natural do trabalho.

Se isso não for feito, a equipe corre o risco de crescer não engenheiros, mas operadores de preenchimento automático. A conclusão prática do texto do Habr é que agentes de IA por si só não tornam a entrega madura. Eles apenas amplificam os pontos fortes e fracos do sistema de engenharia existente.

Portanto, o próximo estágio para as equipes não é apenas gerar código e documentos mais rapidamente, mas construir um processo no qual o contexto seja exposto, o ambiente de execução seja restringido, as verificações sejam formalizadas e cada falha melhore não apenas o produto, mas também a forma como é entregue.