Existe uma expectativa silenciosa em muitas empresas de tecnologia: se o time de engenharia está lento, cheio de retrabalho ou com entregas instáveis, dar acesso a Copilot, Cursor ou Claude vai resolver. Contratar a ferramenta certa, achar que o problema técnico vira problema de adoção.
O relatório DORA 2025, um dos estudos mais respeitados sobre performance de engenharia de software, testou essa hipótese com dados de cerca de 5.000 profissionais de tecnologia ao redor do mundo e mais de 100 horas de análise qualitativa. A conclusão central é direta: IA não conserta um time. Ela amplifica o que já existe. Times fortes usam IA para ficar ainda melhores. Times com processos frágeis veem seus problemas crescerem mais rápido.
Se em 2023 e 2024 a pergunta era "sua empresa já usa IA para programar?", em 2026 essa pergunta perdeu sentido. Segundo o DORA 2025, 90% dos profissionais de tecnologia já usam IA no trabalho, e mais de 80% acreditam que isso aumentou a própria produtividade. A ferramenta deixou de ser vantagem competitiva. Virou piso.
O terceiro número é o que costuma ser ignorado nos anúncios de produtividade: quase um terço dos profissionais não confia no código que a própria IA gera. Produtividade individual percebida e confiança técnica estão andando em direções opostas — e é exatamente aí que mora o paradoxo que o relatório revela.
O DORA 2025 encontrou uma relação positiva clara entre adoção de IA e throughput de entrega de software e performance de produto. Times entregam mais rápido, e o produto avança. Até aqui, a narrativa é a que todo fornecedor de ferramenta de IA vende.
O problema aparece na segunda métrica: a relação entre adoção de IA e estabilidade de entrega é negativa quando o time não tem controles robustos — testes automatizados confiáveis, revisão de código consistente, guardrails de segurança já embutidos no pipeline. Sem isso, IA gera código mais rápido, só que também gera incidentes mais rápido.
IA sem fundação técnica sólida não é neutra. Ela acelera tanto a entrega de valor quanto a entrega de problemas — e o segundo efeito costuma aparecer só depois que o primeiro já foi comemorado em uma reunião de resultado.
Entre os arquétipos de times mapeados pelo relatório, dois extremos ilustram bem a distância entre usar IA bem e usar IA sem base:
Times presos em modo de sobrevivência: baixa performance de entrega, alta instabilidade de sistema, burnout elevado e lacunas grandes de processo e ambiente. IA, nesse contexto, amplia o volume de código — e de incidentes.
Times com métricas positivas de bem-estar, outcomes de produto favoráveis e excelência na entrega de software. IA, nesse contexto, potencializa uma engenharia que já funcionava bem.
O relatório identifica um conjunto de capacidades organizacionais que determinam se a adoção de IA vai amplificar o lado bom ou o lado ruim de um time. Seis delas aparecem com destaque:
Clarificar e socializar políticas de IA. O time sabe o que pode e não pode fazer com IA — não descobre isso incidente por incidente.
Conectar IA ao contexto interno. A ferramenta enxerga o código, os padrões e as decisões da própria empresa — não só o conhecimento genérico do modelo.
Priorizar práticas fundamentais. Testes automatizados, revisão de código e CI/CD confiáveis continuam sendo pré-requisito, não luxo.
Fortalecer redes de segurança. Guardrails de segurança e compliance embutidos no pipeline, não revisados manualmente depois do deploy.
Investir em plataforma interna. Golden paths e self-service reduzem a distância entre "código gerado por IA" e "código em produção com segurança".
Focar nos usuários finais. IA usada para resolver o problema real do produto, não só para gerar mais linhas de código por hora.
Investir em plataforma interna não é uma capacidade isolada — é o mesmo golden path que discutimos no artigo anterior. Sem uma rota opinativa, segura e observável por padrão, cada linha de código gerada por IA vira mais uma variável fora de controle.
A pergunta deixou de ser "vamos adotar IA?". Quase todo mundo já adotou. A pergunta que separa os times que colhem os ganhos dos que só acumulam risco é: a nossa fundação técnica aguenta a velocidade que a IA está entregando?
Isso significa auditar antes de acelerar: os testes automatizados cobrem o que precisam cobrir? Existe um caminho padrão seguro para código chegar em produção? A equipe tem clareza sobre onde IA pode e não pode decidir sozinha? Comprar mais licença de IA sem responder essas perguntas é acelerar na direção errada.
O relatório DORA 2025 não diz para parar de usar IA — os dados mostram que os times que já são bons ficam ainda melhores com ela. O que ele mostra é que IA não é um atalho para pular a maturidade de engenharia que um time ainda não tem. Amplificador não corrige direção. Só acelera a que já existe.
A FuncCloud atua exatamente nesse ponto: diagnóstico de maturidade de engenharia, testes e guardrails automatizados, e construção de plataforma interna — a base que faz a IA amplificar o lado certo do seu time.
Falar com a FuncCloud →