Métricas DORA em 2026: a Inteligência Artificial Acelera a Entrega e a Estabilidade Paga a Conta

Há dois anos que a conversa sobre inteligência artificial no desenvolvimento de software se faz em torno de velocidade. Entrega-se mais depressa, escreve-se código mais depressa, revê-se mais depressa. Essa parte confirmou-se e está medida.

O que também está medido, e circula muito menos, é o que acontece do outro lado. A mesma investigação que regista o ganho de velocidade regista, ano após ano, que a estabilidade da entrega não acompanha. E a telemetria de produção diz onde é que ela se perde.

O que mudou no relatório de referência do setor

O DORA, o programa de investigação que mede desempenho de entrega de software há mais de uma década, mudou de nome e de método em 2025. Passou a chamar-se State of AI-assisted Software Development, e abandonou os grupos de desempenho que toda a gente citava, os quatro escalões de baixo a elite, substituindo-os por sete arquétipos construídos sobre oito medidas.

A mudança não é cosmética. Os escalões descreviam equipas ao longo de um único eixo, do pior para o melhor. Os arquétipos admitem que uma equipa pode entregar muito e ser instável, ou ser estável e lenta, e que essas são situações diferentes e não graus da mesma coisa.

Quem continua a citar "equipa de elite" a partir de dados de 2025 está a citar uma categoria que deixou de existir.

A adoção já não é a variável interessante

Quando quase toda a gente adota uma prática, a adoção deixa de explicar diferenças de resultado. A pergunta útil passa a ser outra: o que separa as organizações onde a inteligência artificial produziu ganho sustentado daquelas onde produziu ganho seguido de mais incidentes.

O padrão que não desaparece com mais adoção

A investigação de 2025 é consistente num ponto incómodo. A utilização de inteligência artificial correlaciona positivamente com débito de entrega, com eficácia individual percebida e com desempenho organizacional. E correlaciona, ao mesmo tempo, com maior instabilidade de entrega.

Vale a pena parar aqui, porque a leitura fácil deste resultado é errada. Não diz que a inteligência artificial degrada a qualidade do código. Diz que o volume e a cadência de alterações sobem mais depressa do que a capacidade do sistema de as absorver com segurança.

A conclusão que o próprio relatório retira é que o desafio definidor deixou de ser a velocidade. Passou a ser a estabilidade.

O que a telemetria de produção mostra, e os inquéritos não

Os dados acima vêm de inquérito. O que se segue vem de observação directa, o que lhe dá outro peso.

Este é o número que muda a natureza do problema. A maioria das falhas de inteligência artificial em produção não é um problema de modelo. É um problema de quotas, de limites de débito, de concorrência e de dimensionamento. Ou seja, é infraestrutura.

E há um segundo detalhe na mesma fonte que agrava a conta. Sete em cada dez organizações correm três ou mais modelos em paralelo, o que multiplica os pontos onde um limite pode ser atingido, e distribui a responsabilidade por fornecedores diferentes com regras diferentes.

Porque é problema de plataforma, não de modelo

Junte-se o que as duas fontes dizem, e o quadro fecha.

O inquérito diz que a entrega acelera e a estabilidade sofre. A telemetria diz que, quando a parte de inteligência artificial falha em produção, a causa dominante é capacidade. As duas apontam para o mesmo sítio: a arquitetura que serve os modelos, não os modelos que ela serve.

Isto tem uma consequência prática desconfortável para quem decide investimento. A resposta a instabilidade associada a inteligência artificial não é trocar de modelo, nem afinar prompts, nem esperar pela versão seguinte. É trabalho de engenharia de plataforma: limites explícitos, degradação controlada quando a quota se esgota, isolamento entre serviços que partilham o mesmo fornecedor, e instrumentação que distingue uma falha de modelo de uma falha de capacidade.

Nenhuma dessas coisas se compra numa subscrição.

A métrica que passa a decidir

As métricas DORA organizam-se em dois eixos. Débito, que junta frequência de implantação, tempo de espera até à alteração chegar a produção e, desde 2024, também o tempo até repor o serviço. E estabilidade, que junta taxa de falha de alteração e a mais recente taxa de retrabalho.

O que costuma passar despercebido é uma mudança de vocabulário com significado real. O antigo tempo médio de reposição, conhecido pela sigla MTTR, foi reposicionado como tempo de recuperação de implantação falhada. Não é a mesma coisa. O primeiro mede quanto tempo demora a repor um serviço, seja qual for a causa. O segundo mede especificamente a capacidade de desfazer o que se acabou de fazer.

Numa operação onde a cadência de alterações subiu por via de inteligência artificial, é esta segunda métrica que separa quem absorve o custo da instabilidade de quem o sofre. Entregar cinco vezes mais depressa só é um ganho se reverter continuar a demorar minutos.

Onde entra a disciplina de operação

Nada disto é um argumento contra adotar inteligência artificial no desenvolvimento. Os ganhos de débito estão medidos e são reais.

É um argumento sobre onde o investimento seguinte tem de ir. Uma organização que acelerou a entrega e não reforçou a plataforma que a sustenta comprou velocidade a crédito, e a fatura chega em incidentes.

O trabalho concreto costuma ser este, por ordem de retorno:

1. Instrumentar a distinção entre falha de modelo e falha de capacidade. Sem isso, todas as falhas parecem problemas de modelo, e a resposta é sempre a errada.
2. Definir e testar a degradação controlada. O que acontece quando a quota se esgota a meio da tarde, e quem decide o que fica de fora.
3. Medir o tempo de recuperação de implantação falhada, e não só a frequência de implantação. A primeira métrica é a que protege; a segunda é a que impressiona.
4. Isolar serviços que partilham fornecedor. Três modelos em paralelo com o mesmo limite de conta não são três caminhos independentes.

Quando isto ainda não é prioridade

Convém dizer também quando este assunto não é o mais urgente, para não se transformar tudo em prioridade.

Se a utilização de inteligência artificial na operação for residual, ou se ainda não estiver em produção com tráfego real de clientes, o risco descrito acima é teórico. Nesse caso, a prioridade continua a ser a fiabilidade da operação existente: recuperação testada, propriedade clara dos sistemas críticos e objetivos de serviço definidos.

O problema descrito neste artigo aparece quando a cadência de entrega já subiu e a plataforma continua dimensionada para a cadência anterior.

Perguntas frequentes

A inteligência artificial torna a entrega menos fiável por natureza? Não. A investigação mostra correlação entre adoção e instabilidade, não causalidade directa do modelo. O mecanismo observado é de volume: mais alterações, mais depressa, sobre plataformas dimensionadas para o ritmo anterior.

O que é a nova métrica de recuperação do DORA? O antigo tempo médio de reposição foi reposicionado como tempo de recuperação de implantação falhada. Mede especificamente quanto tempo demora a desfazer uma alteração que correu mal, e não o tempo de reposição de qualquer avaria.

Como se distingue uma falha de capacidade de uma falha de modelo? Pela instrumentação. Códigos de erro de limite de débito, tempo de espera em fila, e taxa de rejeição por quota são sinais de capacidade. Respostas fora de formato ou incorrectas são sinais de modelo. Sem separar os dois na observabilidade, tudo se lê como problema de modelo.

Ainda faz sentido citar os escalões de desempenho do DORA? Não, a partir de 2025. Os quatro escalões foram substituídos por sete arquétipos construídos sobre oito medidas. Citar "elite" com dados recentes é citar uma categoria que já não existe no relatório.

Isto exige uma equipa dedicada? Exige competência dedicada, que não é o mesmo que quadro fixo. O trabalho é de engenharia de plataforma e fiabilidade, e pode ser interno, reforçado, ou gerido em regime de capacidade dedicada.

Conclusão

A pergunta que abre este artigo tem resposta. A inteligência artificial faz entregar mais depressa, e isso está medido. O que também está medido é que a estabilidade não acompanha sozinha, e que a maior parte das falhas em produção vem de limites de capacidade e não do modelo.

Quem responde por uma plataforma tem aqui um argumento raro: um investimento de fiabilidade que não compete com a agenda de inteligência artificial, sustenta-a. Sobre o que fazer quando a função de fiabilidade não tem dono, vale a pena ler também quando compensa construir uma equipa de fiabilidade interna e quando compensa contratar capacidade, e porque ter cópias dos dados não é o mesmo que conseguir voltar a operar.

Para perceber onde é que a plataforma atual absorve o aumento de cadência e onde é que ela parte, a xGrowth começa por uma reunião breve, sem compromisso, sobre fiabilidade e operação: Agendar Sessão de Esclarecimento.