Pular para o conteúdo
Todos os artigos

A IA deixou seu time mais rápido para escrever código. Não para entregar produto.

Quase todo time programa com IA, mas poucos entregam produto mais rápido. Por que bases de código complexas travam sem intenção escrita, e como PRDs e specs resolvem.

Filipe Abreu14 min de leitura

Todo mundo adotou IA. A entrega não ficou mais rápida.

Quase todo time de engenharia hoje programa com IA, e quase nenhum entrega produto significativamente mais rápido. Essa distância é o número mais importante do software neste momento.

O lado da adoção está resolvido. O relatório DORA 2025 encontrou 95% dos desenvolvedores usando ferramentas de IA, e mais de 80% relatando ganho de produtividade.

O lado da entrega conta outra história. A Faros analisou dois anos de telemetria de 22.000 desenvolvedores em 4.000 times para o relatório de 2026, The Acceleration Whiplash. O volume de tarefas concluídas subiu 33,7% e o de épicos, 66,2%. Os deploys por semana caíram 11,7%, o tempo mediano de review cresceu 5x e os incidentes por pull request triplicaram.

Entra mais código. Sai menos valor do outro lado, e com mais defeitos.

Nem a percepção é confiável. No estudo randomizado de 2025 do METR, desenvolvedores experientes foram 19% mais lentos com IA, acreditando que estavam 20% mais rápidos. A atualização de fevereiro de 2026 diz que os desenvolvedores provavelmente estão mais rápidos agora, mas que os dados já não permitem medir quanto.

Eu não leio isso como "IA não funciona". Uso agentes todos os dias e não voltaria atrás. Leio assim: digitar código nunca foi o gargalo, e nós acabamos de deixar dez vezes mais barato justamente o que não era o gargalo.

Onde a IA é espetacular: o pequeno, o novo e o de baixo risco

A IA consegue levar um MVP pequeno da ideia ao mercado em dias, e isso é real. Um projeto greenfield não tem legado, não tem regra de negócio escondida, não tem cliente para quebrar e tem uma base de código que cabe na cabeça do agente.

O problema é que a maior parte da evidência pública vem exatamente desse tipo de trabalho. A demo no palco é um app de tarefas. A thread viral é um projeto de fim de semana. O experimento que "prova" um ganho de 10x é uma tarefa isolada, com linha de chegada clara.

Os benchmarks têm o mesmo viés. Os autores do SWE-Bench Pro observaram que 161 dos 500 problemas do SWE-bench Verified pedem uma mudança de apenas uma ou duas linhas. O benchmark mais difícil que eles criaram tem em média 107 linhas em 4 arquivos por tarefa.

As notas acompanharam. Modelos que passavam de 70% no benchmark mais fácil ficaram em torno de 43% no conjunto público do Pro na época do artigo. Em bases de código comerciais privadas, que nenhum modelo tinha visto no treinamento, o melhor resultado foi 17,8%.

Modelos mais novos pontuam melhor, mas o formato do resultado se mantém. Quanto mais a tarefa se parece com a base de código de uma empresa real, menos o número da manchete se aplica. Estamos extrapolando do caso fácil para o difícil.

A complexidade muda a conta

Numa aplicação complexa, o crescimento descontrolado do código custa mais do que a velocidade que ele comprou. Gerar código ficou quase de graça, então as bases de código crescem mais rápido do que a capacidade de qualquer pessoa de dar forma a elas. Vejo três custos que se acumulam.

O time to market da próxima feature piora. A análise de 2026 da GitClear, sobre 623 milhões de alterações de código, encontrou 81% mais blocos duplicados. A refatoração caiu de 21% das linhas alteradas em 2022 para 3,8%. Agentes adicionam; raramente consolidam. Cada nova feature agora precisa passar por várias quase-cópias da mesma lógica.

Os próprios agentes pioram. Essa é a parte que a maioria dos times não percebe. A pesquisa da Chroma sobre context rot, resumida aqui, mostrou que todos os modelos testados degradam conforme a entrada cresce, bem antes de a janela de contexto encher. Uma base de código inchada, duplicada e inconsistente é contexto ruim. O agente lê três versões da mesma função, escolhe uma e estende o padrão errado. A bagunça que você gerou no trimestre passado vira o prompt deste trimestre.

O produto se desvia da intenção. Um agente otimiza para a tarefa que está na frente dele. Ele não conhece o seu roadmap, a sua estratégia de preço nem o segmento de cliente que vocês decidiram deixar de atender. Centenas de mudanças localmente razoáveis somam um produto que ninguém decidiu construir.

Os três se alimentam. Mais código significa saída pior do agente, que significa mais retrabalho, que significa mais código. A curva que parecia exponencial no primeiro mês achata, e depois vira para baixo.

Disparar, esquecer, e a memória do código que se apaga

Um time que manda o prompt, faz o merge e segue em frente deixa de entender o próprio produto em poucos meses. Chamo isso de fluxo fire-and-forget: descreve a tarefa, aceita o diff, fecha o ticket, nunca registra o porquê.

A indústria já tem nomes para o resultado. Addy Osmani chama de comprehension debt, a dívida de compreensão: a distância crescente entre quanto código existe e quanto dele algum humano realmente entende. Margaret-Anne Storey chama de cognitive debt, a dívida cognitiva, a partir da velha ideia de Peter Naur de que um programa é uma teoria que vive na cabeça de quem o desenvolve.

Storey descreve um time de alunos que já não conseguia fazer mudanças simples sem quebrar alguma coisa. Eles culpavam o código bagunçado. A causa real era que ninguém sabia explicar por que as decisões de design tinham sido tomadas nem como as partes se encaixavam.

O efeito também aparece nos indivíduos. No estudo da Anthropic com 52 engenheiros aprendendo uma biblioteca nova, o grupo com IA fez 50% num teste de compreensão, contra 67% do grupo que programou à mão. A maior diferença foi em debugging. E eles nem foram significativamente mais rápidos.

Isso importa porque o humano continua sendo o sistema de controle. Sem um modelo mental funcional da base de código e das regras de negócio, um engenheiro não consegue:

  • Direcionar o agente, porque uma boa instrução exige saber onde a mudança pertence e no que ela não pode tocar.
  • Detectar uma alucinação, porque plausível e correto são idênticos para quem não conhece o domínio.
  • Prever efeitos colaterais, porque a regra de cobrança que quebra está a três módulos de distância do diff.

Diferente da dívida técnica, essa é silenciosa. Os testes passam, o build está verde, os gráficos de velocidade estão ótimos. O custo só aparece no dia em que alguém precisa mudar algo importante e ninguém sabe como aquilo funciona.

O mesmo estudo da Anthropic aponta a saída. Os engenheiros que pediam explicações e conceitos à IA mantiveram a compreensão. Os que delegaram passivamente a perderam. A ferramenta é a mesma; o fluxo de trabalho decide o resultado.

Por que prompts, contexto e harness melhores não bastam

Engenharia de prompt, de contexto e de harness melhoram a forma como o agente trabalha. Nenhuma delas decide o que a empresa deve construir nem mantém vivo o entendimento do time. Por isso a solução é mais difícil do que a conversa sobre ferramentas sugere.

A resposta da indústria veio em três passos. Primeiro ajustamos o prompt. Depois passamos a curar o contexto: arquivos de regras, retrieval, memória. Em 2026 o termo é harness engineering: as instruções, travas, ferramentas, evals e ciclos de feedback em volta do modelo.

As três são necessárias, e eu invisto nas três. Mas olhe o estado da prática. O State of AI Harness Engineering 2026, da Marmelab, encontrou arquivos de instrução para agentes em 63% dos grandes projetos open source, mas 60% dos harnesses não têm testes nem evals. Só 4,4% das regras de segurança eram sustentadas por um controle de verdade. Arquivos de contexto gerados por máquina reduziram a taxa de sucesso dos agentes em comparação com não dar contexto nenhum.

O mesmo levantamento lista como problema em aberto justamente o que mais me interessa: não há consenso sobre como traduzir objetivos de produto de alto nível em regras que um harness consiga impor.

Esse é o limite. Um harness consegue fazer o agente seguir as suas convenções. Não consegue dizer a ele qual feature importa neste trimestre, por que a regra de reembolso tem uma exceção para contas enterprise, ou o que vocês decidiram não construir. Esse conhecimento está na cabeça das pessoas, em threads antigas do Slack e em reuniões que ninguém gravou.

Então o problema é só em parte técnico. Ele trata de como uma organização registra decisões, de quem é dono delas e de como elas chegam ao lugar onde o trabalho acontece. Isso é fluxo de trabalho e cultura, e nenhum arquivo de configuração entrega isso.

PRDs e specs: onde a intenção fica escrita

PRDs e spec-driven development são as ferramentas mais eficazes que temos hoje para construir com agentes, porque colocam a intenção por escrito antes de o código existir. Elas só funcionam se o fluxo de trabalho do time mudar em torno delas.

A divisão de trabalho é simples. O PRD guarda o porquê e o quê: o problema, o usuário, os requisitos, os critérios de aceite, o que está fora do escopo. A spec guarda o como: o design, o plano, as tarefas. O agente implementa com base nos dois, e os dois ficam no repositório, ao lado do código.

As ferramentas amadureceram rápido. GitHub Spec Kit, AWS Kiro, OpenSpec e BMAD seguem um pipeline parecido: especificar, esclarecer, planejar, quebrar em tarefas, implementar e verificar, com um ponto de aprovação humana a cada etapa. Um bom panorama de 2026 resume a mudança em uma linha: a spec agora é onde o pensamento acontece.

Isso responde diretamente aos problemas acima. A spec dá ao agente um contexto pequeno e preciso, em vez de uma base de código enorme para adivinhar. Dá ao revisor algo contra o qual conferir o diff. E deixa um registro do porquê, que é a memória que o fire-and-forget destrói.

Mas instalar uma ferramenta de spec, sozinho, não muda nada. Numa conversa da Thoughtworks de maio de 2026, Birgitta Böckeler e Laura Tacho insistiram que o fluxo de trabalho importa mais do que o formato da spec. Elas também deram nome às armadilhas em que vejo times caírem:

  • Waterfall com outro nome. Planejar tudo de antemão porque o agente consegue construir tudo de uma vez. Mantenha os incrementos pequenos e o ciclo de feedback curto.
  • Specs que ninguém lê. O agente gera 2.000 linhas de markdown e o humano aprova sem ler. Isso é fire-and-forget com etapas a mais.
  • Spec desatualizada. O código muda, a spec não. A próxima feature é construída em cima de uma descrição falsa do sistema.
  • Um time de spec e um time de build. Separar quem escreve de quem implementa recria o handoff que o método deveria eliminar.

A adaptação, portanto, está nos hábitos. Engenheiros passam mais tempo esclarecendo e revisando intenção do que digitando. Pessoas de produto escrevem requisitos precisos o bastante para serem testáveis. Specs são revisadas como código e atualizadas no mesmo pull request que o código. "Pronto" significa que a spec voltou a ser verdadeira.

Osmani faz uma ressalva com a qual concordo: uma spec não captura toda decisão implícita, e duas implementações da mesma spec se comportam de formas diferentes. Specs reduzem a necessidade de entendimento humano do sistema. Não a eliminam.

O mesmo problema, um nível acima

A engenharia é só um dos departamentos que hoje trabalham com IA, e se cada um acelera sozinho, a empresa produz desalinhamento mais rápido. Produto rascunha PRDs com IA. Design gera fluxos e protótipos. Marketing produz campanhas e posicionamento. Times de estratégia modelam cenários.

Cada um roda o seu próprio ciclo de fire-and-forget, com o seu contexto e a sua versão do que a empresa está tentando fazer.

Os dados batem com o que eu vejo. Na pesquisa de 2026 da WRITER sobre IA nas empresas, com 2.400 executivos e funcionários, 79% disseram que as aplicações de IA estão sendo criadas em silos. 55% descreveram o uso de IA na empresa como um vale-tudo caótico. 75% dos executivos admitiram que a estratégia de IA é mais fachada do que orientação real.

Agora ligue isso ao problema da engenharia. O agente que escreve o seu código depende da spec. A spec depende do PRD. O PRD depende de posicionamento, pesquisa e estratégia. Se cada um desses documentos foi gerado isoladamente, o agente está executando com precisão uma intenção confusa.

O desvio que descrevi dentro da base de código acontece na empresa inteira. Marketing promete uma feature que saiu do roadmap. Design prototipa um fluxo que contradiz o modelo de preço. A engenharia entrega tudo, rápido.

A solução tem o mesmo formato da solução de engenharia, aplicada à organização:

  • Uma fonte escrita de intenção. Estratégia, prioridades e decisões de produto vivem em documentos que pessoas e agentes de todos os departamentos conseguem ler.
  • Rastreabilidade entre camadas. A campanha aponta para a feature, a feature para o requisito, o requisito para o objetivo.
  • Vocabulário compartilhado. Um glossário parece trivial até os agentes de três departamentos usarem a mesma palavra para três coisas diferentes.
  • Um ciclo, não um revezamento. Produto, design e engenharia trabalham juntos no mesmo incremento, em vez de passar artefatos por cima do muro.

Böckeler e Tacho defendem algo parecido: o próximo passo é um contexto compartilhado que todo mundo no time consiga ler e alimentar, seja desenvolvedor ou não. As empresas que chegarem lá terão a IA puxando numa única direção. As outras terão vários times rápidos puxando cada um para um lado.

O gargalo mudou de lugar

A IA eliminou o custo de escrever código e expôs o que sempre foi a parte difícil: saber o que construir, por quê, e como isso se encaixa em tudo o que já existe. Times que tratam a IA como um teclado mais rápido ganham mais código. Times que a tratam como motivo para ter disciplina com a intenção ganham mais produto.

Se eu tivesse que reduzir isso a um ponto de partida para quem lidera engenharia, seriam quatro perguntas:

  1. Na última feature que vocês entregaram, o porquê está escrito em algum lugar onde um agente ou uma pessoa recém-contratada conseguiria encontrar?
  2. Alguém do time conseguiria explicar como essa feature funciona sem abrir o código?
  3. A sua base de código está ficando mais fácil ou mais difícil para um agente trabalhar, e vocês estão medindo isso?
  4. Produto, design, marketing e engenharia alimentam suas ferramentas de IA com as mesmas prioridades?

Nenhuma delas é sobre qual modelo ou ferramenta você usa. Esse é o ponto.

Como o seu time está lidando com isso? Quero ouvir o que está funcionando em bases de código que já passaram da fase de MVP.

Fontes