Por que o Código Escrito por IA Frustra as Equipes — e o que Fazer a Respeito

Com a maioria das tecnologias, quanto mais você as usa, mais calmamente você passa a confiar nelas. Com as ferramentas de IA, o oposto tem sido verdadeiro: em sua pesquisa anual de mais de 49.000 desenvolvedores, a Stack Overflow registrou o uso subindo para 84% mesmo enquanto a confiança na precisão dessas ferramentas caía de 40% para 29% em um único ano.

Esse efeito é familiar para mim. A nossa primeira experiência com ferramentas de IA no desenvolvimento teve pouco em comum com o efeito “wow” de um trabalho mais rápido e menos rotineiro que a imprensa tecnológica continuava escrevendo sobre. Nossos desenvolvedores foram desapontados: a IA produziu um código medíocre que levou muito tempo para revisar e, no final, teve que ser reescrito. A equipe esperava que a IA economizasse tempo e, em vez disso, obteve trabalho extra. Então, não muito tempo após as primeiras tentativas de incorporar as ferramentas de IA no fluxo de trabalho diário, a equipe voltou a trabalhar do jeito que sempre havia feito.

Hoje, essas mesmas ferramentas aceleram tanto a escrita de código quanto a revisão para nossos desenvolvedores — não porque encontramos um modelo melhor, mas porque mudamos a forma como trabalhamos com ele. Aqui está o que nos ajudou a chegar lá.

Por que o Código Escrito por IA Frustra os Desenvolvedores

A IA se baseia em uma enorme massa de código público de toda a internet, e esse código raramente é exemplar: sua qualidade é média, e o modelo reproduz essa média.

Mas “médio” não é o limite do que é possível — é simplesmente o que o modelo produz até que ele conheça o seu projeto: suas convenções, sua estrutura de código, suas decisões arquitetônicas. Em uma pesquisa de 600 desenvolvedores, a Qodo encontrou que, entre aqueles insatisfeitos com a qualidade do código da IA, 44% atribuem isso precisamente à falta de contexto. É isso que mantém a saída presa em um nível medíocre.

A boa notícia é que o contexto que a IA recebe é quase a única variável que uma equipe controla completamente. Quão bem a ferramenta entende o projeto depende não do modelo, mas do que você alimenta.

A segunda razão é mental — a própria natureza do trabalho muda. Quando a IA escreve a maior parte do código, o ato principal do desenvolvedor não é mais escrever, mas verificar o que foi gerado: ler a solução de alguém, pesar as alternativas, decidir o que está pronto para ser enviado. Isso é uma habilidade diferente de escrever código sozinho, e para qualquer um que amava a parte de escrita, isso não vem facilmente.

No relatório Octoverse de 2025, o GitHub descreve exatamente essa mudança: os desenvolvedores que mais avançaram com a IA não se chamam mais de “autores de código” e se tornam algo mais próximo de seus “diretores criativos”, onde a habilidade-chave é direcionar e verificar. Mas o caminho para esse papel passa por erros e frustração, até que uma pessoa veja o benefício em seu próprio trabalho.

O que Transforma a IA de uma Fonte de Frustração em uma Ferramenta de Trabalho

Quando nossa equipe começou a usar a IA, alguns desenvolvedores trabalhavam com Claude Code, outros tentaram OpenAI Codex, GitHub Copilot ou Gemini CLI, e cada ferramenta deu um resultado diferente. Então, quando começamos a organizar a forma como a equipe trabalhava com a IA, a primeira coisa que fizemos foi escolher uma ferramenta única.

Isso não é apenas nossa prática. Pegue a história da equipe da Linear: até o início de 2026, eles funcionavam com um princípio de “deixe todos trabalharem como melhor lhes convier”, e em janeiro a liderança abandonou essa abordagem e moveu todos para uma forma única de trabalhar — restringindo a escolha a duas ferramentas de IA e pedindo aos desenvolvedores que escrevessem código apenas com elas, em vez de à mão. De acordo com a empresa, a produtividade média aumentou já no mês seguinte em 30% em PRs mesclados e em 33% em tarefas fechadas por engenheiro.

Isso dito, uma ferramenta compartilhada por si só não melhora o código — ela precisa ser configurada: definir regras, algo como um arquivo de regras, que especifiquem como escrever código — quais abordagens seguir, o que evitar. Em seguida, vêm habilidades personalizadas para as tarefas típicas do seu projeto, para que você não precise explicar a mesma coisa repetidamente. E, finalmente, vale a pena apontar o agente para a base de código existente: ele analisa como o projeto é escrito e produz novo código nesse mesmo estilo, em vez de um estilo genérico. Quanto mais contexto a ferramenta recebe, menos você precisa reescrever à mão posteriormente.

Mas a parte mais difícil não é técnica. A mudança de autor do código para seu avaliador não acontece sozinha — essa transição precisa de ajuda. A rota mais direta é o treinamento e a certificação. No nosso caso, por exemplo, dez desenvolvedores estão passando por um programa de parceiro com o fornecedor da ferramenta, enquanto ao lado deles trabalha uma pessoa responsável pela adoção, que explica por que a ferramenta produziu um determinado resultado e como corrigi-lo.

Uma vez que a equipe está trabalhando de forma coordenada, uma única gargalo permanece — a revisão — e vale a pena reforçar com a IA. O agente passa por cada solicitação de pull primeiro e assume o óbvio: erros rotineiros, estilo, repetição, lacunas de segurança. O revisor humano então não olha mais para tudo indiscriminadamente, apenas para a arquitetura e as decisões críticas. O efeito é notável, mesmo dentro das empresas que constroem essas ferramentas: na Anthropic, após a introdução de tal agente, a parcela de solicitações de pull que receberam uma revisão substantiva aumentou de 16% para 54%, e os engenheiros discordaram de menos de 1% de seus comentários.

Para nós, isso encurtou um ciclo de revisão que costumava se estender por dois ou três dias em várias rodadas, e removeu a rotina dos nossos engenheiros seniores, deixando-lhes apenas os pontos realmente difíceis. Uma vez que a ferramenta finalmente começou a produzir resultados que não precisavam ser refeitos, a confiança nela também apareceu.

Onde a Confiança nas Ferramentas de IA Vale a Pena

Em primeiro lugar e principalmente — na escrita de código: quando a ferramenta conhece o projeto e o agente lida com a primeira revisão, a equipe escreve mais e melhor no mesmo tempo. No nosso caso, as ferramentas de IA aceleraram o trabalho em cerca de 30–40%.

Além disso, a IA tornou a integração mais fácil. Quando uma nova pessoa se junta a um projeto, alguém experiente geralmente precisa responder a dezenas de perguntas sobre como o código do projeto é montado. Agora o agente assume esse papel: se o projeto estiver bem documentado, o recém-chegado direciona até 95% dessas perguntas para ele, em vez de para os colegas.

É uma história semelhante com a documentação: um rascunho arquitetônico bruto que antes consumia horas agora é, em grande parte, escrito pelo agente em si — por nossas estimativas, cerca de 80% do rascunho, se você der a ele contexto suficiente. O que resta para o humano é o que não está no repositório — as decisões, as compensações, a expertise.

Tão importante quanto é ser honesto sobre os limites do que a IA pode fazer, porque são as expectativas infladas que geram desapontamento desde o início. A IA não assume a conformidade — um humano assina a dados médicos ou financeiros, e a empresa, não o modelo, é responsável por uma violação. Ela não acelera as integrações com parceiros, onde dezenas de horas são gastas em chamadas e coordenação.

A IA fora da caixa realmente é irritante — mas apenas quando é usada como uma solução finalizada. A diferença inteira entre frustração e benefício está no que você constrói em torno dela: um padrão compartilhado, o contexto do seu projeto e o novo papel do desenvolvedor.