Habr: agentes de IA mudam o delivery e obrigam as equipes a remontar todo o ciclo de desenvolvimento

O Habr publicou uma análise de por que, com a chegada dos agentes de IA, o gargalo das equipes de engenharia deixa de ser a velocidade de escrita de código e passa a ser o custo de verificação e de transferência de contexto. O autor cita o DORA 2025, segundo o qual 90% dos profissionais de tecnologia usam IA no trabalho, e mais de 80% associam a ferramenta a ganhos de produtividade. Só que, quanto mais rápido se produzem código, ADRs e documentação, maior fica a carga sobre a revisão e o controle de estabilidade.

Por isso, a proposta é enxergar a IA não como mais uma ferramenta dentro do processo antigo, mas como motivo para remontar todo o ciclo de entrega de mudanças. O artigo separa três modos de trabalho. O primeiro é o ai-assisted development: o modelo ajuda a levantar requisitos mais rápido e a escrever rascunhos de ADRs, casos de teste ou documentação, mas o processo continua o mesmo.

O segundo é o agentic delivery, em que o agente já lê o repositório, prepara as mudanças, roda as verificações e abre o PR, enquanto o humano entra em cena nas escalações. Como exemplo dessa virada, o autor menciona a chegada do GitHub Copilot coding agent à disponibilidade geral (general availability). O terceiro modo é o ai-native sdlc: aqui o LLM deixa de ser um “chat ao lado” e se torna a interface para o fluxo de trabalho, por meio da qual a equipe leva a tarefa da ideia ao release.

A tese central do texto é que a economia dessa transição gira não em torno do código, mas da comunicação. No delivery real, o caro não são apenas as mudanças em si, mas a passagem de trabalho entre análise, desenvolvimento, testes e operação, a reconstrução repetida de conhecimento e os pedidos constantes de esclarecimento. Quando a geração acelera, o gargalo migra para aprovações, validação e controle de riscos.

Por isso, as equipes precisam de um contexto externo e legível por máquina, acessível tanto a pessoas quanto a agentes: objetivos, restrições, riscos, critérios de pronto, ADRs, contratos de API, regras de segurança, comandos de verificação local e notas de rollout. Se o conhecimento crítico continuar vivendo em chats, calls e na memória de desenvolvedores específicos, o agente simplesmente trabalhará com um quadro incompleto. Daí surge o novo foco no harness, o ambiente de execução dos agentes.

Já não se trata de um grande prompt de sistema, mas de um conjunto de regras e restrições embutidas no processo. O repositório deve ganhar instruções explícitas para os agentes, comandos de build e de testes, critérios de pronto e restrições de arquitetura e de segurança. A sugestão é formalizar cenários recorrentes como skills, playbooks e repo rules, em vez de explicá-los de novo em cada chat.

E as restrições não devem ser apenas textuais: o sistema precisa ser capaz de barrar ações arriscadas, proibir merges sem confirmação e repassar etapas controversas a um humano. O autor analisa à parte 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 reverter a mudança.

Sobre isso, são necessários quality gates: limites para o tamanho das mudanças, comandos validate obrigatórios, checagem de restrições de arquitetura e atualização sincronizada da documentação. Outra camada são os evals para tarefas recorrentes. Eles permitem fixar explicitamente o comportamento esperado do agente e verificar se o workflow continua estável após novas mudanças, ou se o processo está descambando para uma versão cara de vibe coding, com uma enxurrada de PRs ruidosos.

Depois do release, na visão do autor, é preciso observar não só o produto, mas o próprio processo de entrega. A equipe deve analisar onde faltou contexto ao agente, quais regras se mostraram fracas, quais tarefas eram grandes demais para uma delegação segura e onde a revisão se afogou em ruído. Isso afeta diretamente a organização: cresce o valor dos engenheiros generalistas, ganham peso o platform engineering e as ferramentas internas, e o onboarding de juniores deixa de ser um efeito colateral natural do trabalho.

Se nada disso for feito, a equipe corre o risco de formar não engenheiros, mas operadores de autocompletar. A conclusão prática do texto do Habr é que os agentes de IA, por si só, não tornam o delivery maduro. Eles apenas amplificam os pontos fortes e fracos do sistema de engenharia existente.

Portanto, a próxima etapa para as equipes não é apenas gerar código e documentos mais rápido, mas construir um processo em que o contexto fique externalizado, o ambiente de execução seja restrito, as verificações sejam formalizadas e cada falha melhore não só o produto, mas também a própria forma de entregá-lo.