Seu time de engenharia agêntica abriu mais pull requests este trimestre. A pergunta que decide o próximo passo não é quantos, mas quais desses PRs ainda vão estar de pé em seis meses sem retrabalho.

Velocity subiu. Story points multiplicaram. Só que essas métricas foram desenhadas para medir esforço humano escasso, não geração de código por agentes que produzem sem cansaço nem hesitação.

O problema não está no agente, mas no dashboard que continua medindo o que ficou barato e ignora o que virou escasso: atenção humana qualificada para revisar, validar e assinar cada entrega. Entenda melhor sobre as métricas de engenharia agêntica a seguir.

Por que métricas tradicionais perdem referência na engenharia agêntica

Velocity, story points e horas entregues nasceram numa lógica simples: esforço humano é finito e caro, então mede-se o que sai desse esforço por unidade de tempo. Essas métricas de engenharia de software sustentaram décadas de gestão ágil e ainda funcionam bem em times compostos só por pessoas. O problema aparece quando parte do time passa a ser um agente que gera código em minutos, sem fadiga, sem troca de contexto e sem custo marginal perceptível por linha escrita.

Na engenharia agêntica, o gargalo migra de lugar. Geração de código deixa de ser o recurso escasso, e a atenção humana qualificada, que revisa, valida e assina cada gate antes da próxima etapa, passa a ser o ativo mais disputado do ciclo. Contar pull requests abertos por um agente informa volume, não diz nada sobre quem vai revisar e aprovar o resultado antes da produção.

Quando o dashboard continua medindo esforço, ele erra a mão duas vezes: superestima a contribuição do agente, porque volume não é performance, e subestima o risco acumulado, porque não captura quanto da produção agêntica está avançando sem revisão humana adequada. É a consequência direta de manter o painel: uma fase inicial de produtividade aparente, seguida por picos de retrabalho que o método antigo não foi desenhado para antecipar, porque nunca mediu a variável que passou a importar.

Os SLAs que precisam ser redefinidos quando agentes entram no fluxo

Três SLAs mudam de forma direta quando um agente passa a operar dentro do ciclo de desenvolvimento. O termo está presente no vocabulário de gestão de serviços de TI desde os anos 1980, quando empresas terceirizavam infraestrutura e passaram a exigir contrato explícito sobre tempo de resposta e disponibilidade, algo que antes ficava implícito numa relação de confiança entre fornecedor e cliente. A engenharia agêntica reintroduz esse problema dentro do próprio time: o agente é, na prática, um fornecedor interno que precisa de contrato claro sobre o que entrega e em quanto tempo alguém confirma que aquilo funciona.

• SLA de revisão humana: define o tempo máximo entre o agente entregar um output e um engenheiro revisar, aceitar ou rejeitar esse material antes de ele avançar para o próximo estágio do pipeline. Sem esse limite, o agente continua produzindo enquanto a fila de revisão cresce, e o sistema fica parado por tempo indefinido por falta de pessoal para pegar a demanda. 

• SLA de detecção e correção: mede quanto tempo leva para identificar e corrigir um problema introduzido pelo agente. O modo de falha mais caro aqui é a regra de negócio mal interpretada: código que compila, passa nos testes automatizados e ainda resolve o problema errado, porque o agente seguiu a especificação ao pé da letra sem captar a intenção de negócio por trás dela. Detectar isso exige revisor com entendimento do domínio, não só da sintaxe. 

• SLA de contexto: estabelece quem garante que a arquitetura, os padrões de código e as restrições de negócio estão atualizados e disponíveis para o agente no momento da geração. Sem esse SLA definido, o agente trabalha com contexto desatualizado, e ninguém percebe até o retrabalho aparecer, muitas vezes semanas depois, já embutido em outras entregas que dependiam daquele código. 

Esses três SLAs não são burocracia adicional. São, para a engenharia agêntica, o equivalente ao que o SLA de disponibilidade sempre foi para infraestrutura: um compromisso mensurável que transforma expectativa implícita em responsabilidade rastreável. Quando nenhum dos três está definido, o time descobre o problema no pior momento possível, já em produção.

KPIs que fazem sentido para acompanhar a engenharia agêntica

Se os SLAs definem prazos e responsáveis, os KPIs medem o resultado ao longo do tempo. Quatro indicadores substituem ou complementam as métricas de engenharia de software tradicionais quando a engenharia agêntica entra no fluxo de desenvolvimento, e cada um captura uma dimensão diferente do que pode dar errado quando um agente produz em escala.

• Taxa de aceitação de output: percentual do código gerado pelo agente que o revisor humano aceita sem modificação significativa. Queda nessa taxa costuma ser o primeiro sinal de que o agente está operando fora de contexto ou de que os guardrails do processo precisam de ajuste, antes que o problema apareça como bug em produção. 

• Taxa de retrabalho pós-agente: mede quanto do código gerado precisou ser corrigido depois de já ter passado pela revisão e sido integrado. É diferente da taxa de aceitação porque aqui o código já foi validado uma vez e ainda assim voltou. Times que definem acceptance criteria antes de o agente gerar qualquer linha, e não depois, mudam essa curva de forma mensurável: a DB1 Global Software registra 0,3% de retrabalho em projetos estruturados dessa forma. 

• Débito técnico independente do agente: um agente pode gerar código funcional que, ainda assim, degrada a arquitetura a cada iteração: decisões de acoplamento, duplicação sutil, padrões inconsistentes que passam no teste, mas custam caro depois. Análise estática aplicada ao output do agente, separada do que o time humano produziu, permite enxergar essa curva antes que ela vire reescrita completa de módulo. 

• Cobertura de revisão humana: percentual do código de origem agêntica que passou por um gate de validação com responsável nomeado antes de chegar à produção. Na engenharia agêntica, esse KPI não é opcional nem cosmético, é o que garante que velocidade de geração não virou velocidade de risco. 

Nenhum desses quatro indicadores funciona isolado. Taxa de aceitação alta com cobertura de revisão baixa é sinal de alerta, não de sucesso, porque significa que o time parou de olhar de perto exatamente quando deveria continuar olhando. A combinação dos quatro é o que dá visibilidade real sobre a saúde da engenharia agêntica em produção, não apenas sobre o volume que ela consegue gerar.

Quando os números parecem bons e a qualidade cai

A métrica de vaidade mais comum na engenharia agêntica é volume: número de pull requests abertos pelo agente, linhas de código geradas por dia, velocidade de commit. Alta produção não é sinônimo de alta qualidade, e em sistemas com agentes autônomos essa distância entre volume e qualidade cresce mais rápido do que em qualquer ciclo anterior de desenvolvimento de software assistido por ferramentas.

Em fluxos com agentes, o volume de output pode ultrapassar a capacidade humana de revisão em semanas, não em meses. Quando isso acontece, e a governança de IA não acompanhou a velocidade da adoção, a cobertura de revisão cai de forma silenciosa: ninguém decide formalmente revisar menos, o time não consegue acompanhar o ritmo, e o débito técnico cresce na mesma proporção que a velocity comemorada no dashboard.

O relatório DORA de 2025 confirma o padrão: IA acelera a entrega, mas expõe fragilidades ao reluxo quando faltam sistemas de controle, e segue associada a queda na estabilidade das equipes pesquisadas. A própria DORA reagiu no nível da métrica: a edição de 2025 passou de quatro para cinco indicadores oficiais, incluindo pela primeira vez a taxa de retrabalho, a proporção de entregas não planejadas motivadas por incidente em produção. É a mesma variável que todo KPI de engenharia agêntica precisa capturar: volume alto com retrabalho oculto não é performance, é atraso de detecção.

Como estruturar a governança de KPIs em projetos com engenharia agêntica

Definir SLAs e KPIs é a parte relativamente simples. A parte que decide se eles funcionam é a governança de IA em torno deles: quem define as métricas, quem monitora no dia a dia e como o ciclo se fecha entre a performance do agente e a saúde real do projeto. Três práticas sustentam essa governança em contextos de engenharia agêntica:

• Separe dashboards de output humano e agêntico: misturar os dois esconde exatamente o dado que mais importa, quanto da produção total veio de um agente e como essa fatia se comporta em relação à fatia humana. Comparação direta entre as duas fontes é o que permite decisões objetivas de ajuste de guardrails e de escopo de autonomia. 

• Revise os KPIs dos agentes a cada ciclo: parâmetros humanos de performance mudam pouco de um sprint para outro, mas os parâmetros de um agente evoluem junto com o próprio projeto, com o modelo por trás dele e com o contexto que ele recebe. Um KPI calibrado para o início do projeto pode estar defasado três meses depois, e ninguém percebe até o número parar de fazer sentido. 

• Atribua responsabilidade nominal pela revisão de output agêntico: sem um dono definido para cada gate, a validação humana vira burocracia que ninguém prioriza quando a sprint aperta. Responsabilidade nominal é o que transforma o gate em compromisso real, não em checkbox esquecido no fim da esteira. 

Governança de IA sem essas três práticas tende a existir só no papel, num documento de processo que ninguém consulta quando a pressão de prazo aumenta. Com elas, a engenharia agêntica ganha o que faltava nas primeiras gerações de automação de código: um ciclo fechado entre o que o agente produz e o que o negócio pode confiar.

Leia também: Governança de IA no desenvolvimento de software: o problema do "AI Only"

Medir para durar: o papel da governança na engenharia agêntica

Engenharia agêntica não dispensa governança, ela exige governança mais precisa do que qualquer ciclo anterior de desenvolvimento de software. Quando um agente opera de forma autônoma, a ausência de SLAs e KPIs adequados deixa de ser detalhe operacional e vira risco técnico e de negócio que cresce na mesma velocidade do output que o agente produz.

Métricas de engenharia de software pensadas para humanos não desaparecem, elas continuam valendo para o time humano, mas precisam de complemento específico para o que a IA produz. Taxa de aceitação, taxa de retrabalho, débito técnico por agente e cobertura de revisão formam esse complemento, e SLA de revisão, de detecção e de contexto garantem que ele seja cumprido, não apenas medido de longe.

A DB1 Global Software estrutura projetos de engenharia agêntica com validação humana obrigatória, métricas de qualidade definidas antes da primeira linha de código e governança de IA desde a concepção do projeto, não como ajuste posterior de processo. Fale com a nossa equipe e avalie como esses indicadores se aplicam ao seu ciclo de desenvolvimento hoje.