Uma equipe adota um agente de programação e passa a abrir mais pull requests. Em poucas semanas, o gargalo apenas muda de lugar: requisitos chegam incompletos, diffs ficam grandes, revisão demora, testes quebram e incidentes exigem reconstruir o contexto do zero. O volume de código sobe, mas o tempo até o valor não acompanha.
Em 6 de novembro de 2026, o GitHub descreveu esse fenômeno ao apresentar a engenharia agêntica como um fluxo que conecta Planejar, Construir, Verificar e Observar. A empresa citou crescimento expressivo de commits e um estudo externo no qual pull requests permaneceram muito mais tempo em revisão entre equipes de alta adoção de IA. A lição não é produzir menos com IA; é redesenhar o sistema de entrega para que contexto, revisão e operação evoluam junto.
O que é engenharia agêntica?
É uma disciplina para delegar partes do trabalho de engenharia a agentes, mantendo objetivos, restrições e responsabilidade sob direção humana. O agente não entra apenas no editor: ajuda a organizar requisitos, propor plano, implementar mudanças, executar verificações, analisar telemetria e transformar aprendizados de produção em novos itens.
A diferença para “vibe coding” está na unidade de trabalho. O foco não é obter uma aplicação a partir de uma conversa, mas operar um ciclo repetível dentro de arquitetura, padrões, segurança e métricas da equipe.
As quatro etapas do ciclo
1. Planejar com contexto verificável
Antes de alterar código, o agente reúne requisito, decisões anteriores, contratos de API, componentes afetados e critérios de aceite. A saída é um plano revisável: escopo, alternativas, riscos, dependências, testes e estratégia de reversão.
Contexto não significa despejar toda a empresa no prompt. Forneça somente fontes autorizadas e atuais, com links. Decisões importantes precisam ser registradas em issue, ADR ou especificação; uma resposta efêmera do chat não é fonte de verdade.
2. Construir em tarefas isoladas
Divida o plano em mudanças pequenas e independentes. Cada sessão usa uma cópia isolada do repositório, branch própria e instruções versionadas. O agente deve conhecer comandos de teste, convenções, limites de dependência e arquivos que não pode modificar.
Trabalho paralelo exige um grafo de dependências. Atualizar documentação pode avançar enquanto a implementação acontece; uma migração que depende do novo modelo de dados precisa esperar. O orquestrador evita que dois agentes editem a mesma fronteira sem coordenação.
3. Verificar antes da atenção humana
O agente executa lint, testes, análise de segurança e verificações de contrato antes de pedir revisão. Outro modelo ou agente pode criticar o plano e o diff, mas não substitui os gates determinísticos. O objetivo é entregar ao revisor um pacote pequeno, explicado e com evidências.
Pull requests devem mostrar por que a mudança existe, como foi testada, quais riscos permanecem e como reverter. Código gerado não recebe confiança automática: recebe o mesmo — ou maior — rigor que código escrito manualmente.
4. Observar o resultado em produção
Depois do deploy, conecte logs, traces, métricas técnicas e indicadores de negócio ao contexto da mudança. O agente pode correlacionar erro, release e segmento afetado, preparar uma investigação e propor teste de regressão. A decisão de rollback continua condicionada à política definida.
Uma descoberta útil volta ao início como issue, caso de teste, instrução ou melhoria de arquitetura. Assim, o ciclo aprende com comportamento real em vez de acumular conversas desconectadas.
Arquitetura mínima
- fontes de contexto: repositório, issues, documentação, design, observabilidade e políticas;
- orquestrador: decompõe trabalho, resolve dependências e escolhe o agente;
- ambientes isolados: separam branches, credenciais, arquivos e execução;
- gates: testes, contratos, segurança, acessibilidade, custo e aprovação;
- trilha: registra instrução, modelo, ferramentas, commits, evidências e decisões;
- feedback: transforma revisão e produção em melhorias versionadas.
Exemplo: nova regra de limite de crédito
O produto solicita limite variável por perfil. No planejamento, o agente encontra regra vigente, integrações do ERP, decisões de risco e jornadas do aplicativo. Propõe separar cálculo e concessão, preservando uma API compatível.
Na construção, uma tarefa altera o motor, outra atualiza o painel e outra cria migração. Os agentes trabalham em branches isoladas. O pipeline valida contrato, arredondamento, autorização, acessibilidade e carga. Um revisor humano concentra-se na regra financeira e nos cenários de exceção.
Após publicar, a observabilidade compara aprovação, latência e inadimplência com o baseline. Se um segmento apresenta anomalia, o agente reúne evidências e abre investigação com os commits relacionados. Isso é engenharia agêntica: acelerar a cadeia sem retirar controle das decisões.
Métricas que importam
Contar sugestões aceitas ou linhas geradas mede atividade, não resultado. Em 5 e 6 de novembro, o GitHub ampliou seus relatórios para mostrar uso de agentes, taxa de comentários de revisão tratados e pull requests que chegaram ao merge sem pedido humano posterior de alteração. Essas métricas ajudam, mas devem ser combinadas com o fluxo real.
- lead time entre requisito e produção;
- tempo em fila de revisão e tamanho do diff;
- retrabalho, rollback e defeitos escapados;
- percentual de tarefas concluídas sem reabertura;
- custo de modelo e execução por mudança aprovada;
- tempo de recuperação e impacto no indicador de negócio.
Erros comuns
- automatizar implementação e manter planejamento manual desestruturado;
- abrir pull requests enormes porque gerar código ficou barato;
- permitir que sessões compartilhem diretório ou credenciais;
- usar texto do chat como decisão sem versionamento;
- medir adoção em vez de valor entregue;
- ignorar revisão, observabilidade e retorno de produção;
- dar autonomia sem limite de escopo, custo e efeito.
Como começar
- Mapeie um tipo de mudança frequente e seu fluxo completo.
- Documente fontes, critérios de aceite e comandos de validação.
- Delegue primeiro planejamento assistido e tarefas pequenas.
- Crie ambiente isolado e gates obrigatórios.
- Padronize a descrição do pull request e as evidências.
- Ligue a mudança à telemetria e ao resultado.
- Compare lead time, qualidade e custo com o baseline.
Velocidade com engenharia
O ganho real aparece quando o agente reduz espera e reconstrução de contexto em todo o ciclo, não quando apenas escreve mais código. Planejamento explícito, mudanças pequenas, verificação automática e feedback de produção preservam a capacidade de evoluir o produto.
A ProativaIA desenvolve software sob medida, aplicativos integrados e pipelines com agentes, testes e observabilidade. Podemos estruturar o fluxo de engenharia agêntica de acordo com sua arquitetura, equipe e risco.