# Por que a IA está atrasando sua entrega de software?

> Porque a IA acelera o trabalho local de produzir código, specs e tarefas, enquanto o trabalho que trava a entrega, concordar sobre o que é verdade, segue em velocidade humana. A solução é reconciliação em velocidade de máquina, não um modelo mais esperto.

_Análises · 2026-07-09_

**A IA não está atrasando sua entrega porque os modelos são ruins. Está atrasando porque ela acelera o trabalho local de produzir código, specs e tarefas, enquanto o trabalho que de fato trava a entrega, concordar sobre o que é verdade entre pessoas e ferramentas, segue em velocidade humana ou simplesmente não acontece.** O efeito é mensurável. Em um estudo randomizado controlado da [METR (2025)](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), devs experientes usando IA levaram 19% mais tempo para completar tarefas reais, acreditando que tinham sido cerca de 20% mais rápidos. Eu vi isso acontecer de dentro, na iniciativa de IA de uma empresa.

## Como um refactor de três dias com IA virou duas semanas de limpeza em produção

Cada etapa de um desastre com IA parece uma vitória enquanto está acontecendo. No início de 2026, o CEO de uma empresa com quem trabalho mandou uma mensagem que vai soar familiar: precisamos acelerar o desenvolvimento de software com IA. Até o fim de janeiro ele tinha repetido o pedido para cada liderança técnica, e iniciativas isoladas começaram a aparecer em semanas. Cada uma era local e parecia razoável por si só.

A primeira foi um upgrade de versão major do Next.js. O time de frontend apontou um agente de código para a tarefa e deixou rodar por quase três dias. A base de código não tinha testes unitários. O build passou, testes manuais em ambiente controlado passaram, e o time estimou que o agente tinha economizado pelo menos duas semanas de trabalho.

Aí chegou em produção. No caminho, o agente tinha reescrito integrações em silêncio e inventado endpoints que nunca existiram. Features pararam de funcionar sem alarde. Estabilizar levou duas semanas, durante as quais o trabalho planejado das outras frentes também parou. Algumas features ficaram quebradas por dois ou três meses, descobertas só quando um único usuário finalmente mexeu nelas.

Inventar endpoints não é um azar raro. Um [estudo do USENIX Security 2025](https://arxiv.org/abs/2406.10279) gerou 576.000 amostras de código em 16 modelos e constatou que pelo menos 5,2% das referências a pacotes em modelos comerciais, e 21,7% nos open-source, apontavam para pacotes que não existem. Referenciar com confiança coisas que não estão lá é comportamento documentado e medido dos modelos.

## Fundamentos antigos quebrando em velocidade de máquina

Agentes de código não inventaram um modo de falha novo; eles tornaram barato um modo com décadas de idade, o rewrite big-bang de uma base sem testes. Martin Fowler escreveu o manual em [Refactoring](https://martinfowler.com/books/refactoring.html), publicado originalmente em 1999: refatora-se em passos pequenos que sempre deixam o código funcionando, e sobre [código que se testa sozinho](https://martinfowler.com/bliki/SelfTestingCode.html). Um rewrite de três dias sem testes viola as duas regras de uma vez. O agente só tornou a violação barata.

E esse é o padrão da indústria, não o erro de um time. A [GitClear](https://www.gitclear.com/ai_assistant_code_quality_2025_research) analisou 211 milhões de linhas alteradas entre 2020 e 2024 e mostrou que a fatia das mudanças que refatoram ou movem código existente caiu de 25% em 2021 para menos de 10% em 2024, enquanto linhas copiadas e coladas subiram de 8,3% para 12,3% das mudanças. A IA, do jeito que é usada hoje, produz mais código, não mais reuso.

## Aí cada área ganhou sua própria IA, e os nomes pararam de bater

Quando cada área de uma empresa ganha a própria IA, as contradições vêm da soma das ferramentas, não de nenhuma delas sozinha. Depois do refactor, a iniciativa continuou: o designer passou a gerar layouts e especificações de design com IA, a PM passou a escrever tarefas no Asana com IA, produto passou a escrever specs no Notion com IA, os devs passaram a programar com IA. Cada frente produziu um volume impressionante de artefatos. E produziu também a contradição mais simples que existe: os nomes usados nas definições de produto pararam de bater com os nomes usados no código.

Eric Evans deu nome ao que se perdeu. O Domain-Driven Design (2003) chama de [linguagem ubíqua](https://martinfowler.com/bliki/UbiquitousLanguage.html): um vocabulário rigoroso, compartilhado entre quem define o produto e o código que o implementa. Essa linguagem era o protocolo de consenso informal do time, mantido de graça enquanto humanos escreviam tudo à mão e liam o trabalho uns dos outros. A produção com IA apagou isso em um único trimestre.

Os bugs que isso cria são silenciosos. A tarefa "funciona", mas com diferenças sutis do que foi especificado, então nada estoura no primeiro dia. E como nenhum humano entendia mais o todo, cada erro só aparecia quando alguém construía em cima de uma suposição e batia na realidade.

## A IA moveu o gargalo de escrever código para concordar que ele é seguro de mergear

O gargalo da entrega de software nunca foi digitar. Era concordar. Gene Amdahl formalizou a forma geral em [1967](https://en.wikipedia.org/wiki/Amdahl%27s_law): acelere uma parte de um sistema e o ganho total fica limitado pelas partes que você não acelerou. A IA acelerou a produção. Não acelerou review, QA, integração nem reconciliação, a parte serial da entrega. E é pior do que um teto, porque produção mais rápida despeja mais trabalho justamente na parte que não escalou.

A [telemetria da Faros AI](https://www.faros.ai/blog/ai-software-engineering), com mais de 10.000 devs em 1.255 times, mostra exatamente esse padrão: times com alta adoção de IA mergearam 98% mais pull requests, enquanto o tempo de review subiu 91%. No mesmo conjunto de dados, a adoção de IA esteve associada a PRs 154% maiores e 9% mais bugs por dev. No nível da empresa, a Faros não encontrou melhora significativa em nenhuma métrica, DORA incluída. O gargalo se moveu de escrever código para decidir se o código é seguro de mergear.

Nada disso deveria surpreender quem leu a [pesquisa da DORA](https://dora.dev/capabilities/working-in-small-batches/): trabalhar em lotes pequenos é um dos preditores mais fortes de performance de entrega, e a ênfase está em mudanças pequenas com feedback rápido, não no volume de código produzido. A empresa acelerou justamente a única coisa que a DORA nunca apontou como a restrição.

## Seu stack de IA é um sistema distribuído sem protocolo de consenso

Uma empresa rodando IA dentro de cada ferramenta é um sistema distribuído, e quase ninguém entrega isso com protocolo de consenso. A computação distribuída tem nome para o que eu vi: [split-brain](https://en.wikipedia.org/wiki/Split-brain_(computing)). Particione um cluster e, se as duas metades continuarem aceitando escritas, cada uma constrói a própria versão da verdade. A ferramenta de design, o gerenciador de tarefas, a spec e a base de código estavam todos aceitando escritas mais rápido do que qualquer humano conseguia ler. Nada os reconciliava.

Melvin Conway enxergou a lei por trás disso em [1968](https://www.melconway.com/Home/Conways_Law.html). Nas palavras dele: "Qualquer organização que projeta um sistema (em sentido amplo) produzirá um design cuja estrutura é uma cópia da estrutura de comunicação dessa organização." Dê a cada silo a sua própria IA e você não conserta a fragmentação, você a automatiza.

Há uma diferença em relação ao cenário clássico, e ela piora as coisas. O cluster particionado um dia teve consenso e o perdeu. O stack de IA da sua empresa nunca teve. Ele nasceu split-brain.

## A falha que ninguém mede: certo localmente, errado globalmente

A falha perigosa é a resposta que está certa localmente e errada globalmente: respostas inventadas são auditadas, respostas incoerentes passam. Todo mundo mede alucinação, e a indústria tem benchmarks para isso. Mas a falha mais profunda naquela empresa era outra: cada ferramenta fazia o próprio trabalho corretamente sobre a fatia que conseguia ver, e a soma das respostas corretas era um sistema incoerente.

Nenhuma avaliação padrão captura isso. Benchmarks como MMLU e HELM testam um modelo em uma tarefa. Não existe eval que pergunte se os seus cinco pontos de contato de IA concordam entre si sobre a mesma feature. Quem está na prática já sente a lacuna: na [pesquisa de 2025 do Stack Overflow](https://survey.stackoverflow.co/2025/ai/), com mais de 49.000 devs, 84% usam ou planejam usar IA, mas mais devs desconfiam da precisão dela (46%) do que confiam (33%). A frustração número um, citada por 66%, é código "quase certo, mas não exatamente", e 45% dizem que depurar código gerado por IA toma mais tempo. Quase certo é exatamente como o certo localmente e incoerente globalmente aparece para quem está dentro.

## O que destrava a entrega travada pela IA: reconciliação em velocidade de máquina

Se a produção roda em velocidade de máquina, a reconciliação precisa rodar em velocidade de máquina, ou a aceleração se anula. A solução não é menos IA, um modelo mais esperto ou prompts melhores. A peça que falta é a função que os humanos executavam em silêncio quando tudo era lento: reconciliar em uma única verdade atual o que design, spec, tarefas e código afirmam, cada um por si. Essa função agora precisa ser infraestrutura: uma [camada de contexto](/pt/blog/guias/camada-de-contexto-para-agentes-de-ia) que toda ferramenta lê antes de agir e pela qual escreve de volta. A linguagem ubíqua e o protocolo de consenso, reconstruídos como sistema em vez de hábito.

Essa solução também já foi medida, com uma ressalva que vem antes. Num preprint de 2026, [Dillon e Varanasi](https://arxiv.org/abs/2605.08112) testaram um agente de código contra 41 decisões de time num único repositório e levaram a conformidade de 46% para 95%. A ressalva: eles constroem a ferramenta de contexto que testaram, e o ganho veio de um pacote de decisões registradas, spec gerada e consulta durante a construção, então nenhum ingrediente sozinho leva o crédito. O que sobrevive à ressalva é um caso da tabela por decisão. O repositório tinha duas funções de auditoria, e uma regra de SOC-2 tornava exatamente uma delas obrigatória nas exportações. A regra em si não estava escrita em nenhum lugar que o agente alcançasse. Mandaram ele garantir que a ação fosse registrada, ele foi procurar, achou uma função de auditoria e usou a errada, uma distinção que, nas palavras dos autores, exige saber por que a certa existe. Ele conseguia ler as duas funções. Não conseguia ler o acordo sobre qual delas o time tinha escolhido. Recuperação sozinha não fecha essa lacuna, porque [recuperação encontra texto parecido, não governa a verdade](/en/blog/comparisons/mcp-vs-rag-for-agent-context) (em inglês).

## O que exigir de uma camada de contexto

Antes de comprar a próxima IA, faça uma pergunta ao seu time: onde todas as nossas IAs leem o que é verdade? Uma camada de contexto merece esse papel apenas se fizer quatro coisas. Reconciliar os muitos nomes de uma mesma coisa real em uma entidade só. Rastrear proveniência, para que cada fato aponte de volta para uma fonte. Reter ou sinalizar fatos contestados em vez de misturá-los em uma resposta confiante. E ficar por baixo das ferramentas que você já usa, para que os agentes a leiam primeiro, por uma interface padrão como o MCP.

A maioria dos produtos dessa categoria roda como assinatura em nuvem, na infraestrutura de terceiros. A [LoomSignal](/pt#pricing) é a nossa resposta para o ciclo de entrega especificamente: uma camada de contexto local que as suas ferramentas de IA compartilham, rodando nos seus próprios servidores, paga uma única vez. Ela refina sinais brutos pelos [níveis bronze, prata e ouro](/pt/docs/architecture), para que um agente só aja sobre contexto que passou por um gate de governança.

As empresas que vão de fato colher os ganhos da aceleração não são as que têm o modelo mais esperto. São as que têm ferramentas que concordam sobre o que é verdade.

---
Source: https://loomsignal.io/pt/blog/analises/por-que-a-ia-atrasa-sua-entrega-de-software