Já ouviu a frase “Adotamos IA, mas o resultado não veio do jeito esperado”?
Pull requests ficaram mais rápidos, o volume de código aumentou e o time parece produzir mais. Ainda assim, o lead time segue igual. iIncidentes crescem. Tickets se acumulam e o retrabalho consome parte do ganho inicial. Esse paradoxo tem aparecido com frequência em times que aceleraram a adoção de IA nos últimos meses.
Em um caso recente, a equipe passou a usar assistentes de código diariamente. O número de commits quase dobrou em poucas semanas. O tempo entre a ideia e a entrega em produção, porém, permaneceu estável. O problema saiu da escrita de código e foi parar em revisão, decisão e correção de falhas. A tese por trás desse padrão é: a IA não corrige o sistema de trabalho. Ela amplifica o que já existe.
Quando a IA realmente ajuda?
Pesquisas recentes ajudam a separar expectativa de realidade. Um estudo da GitClear, que analisou mais de 2.000 desenvolvedores e cerca de 30.000 pontos de dados entre o final de 2024 e 2025, mostrou ganhos claros em atividades como boilerplate, variações de implementação, rascunhos de testes e exploração inicial de soluções. Usuários avançados de IA tiveram aumento de produtividade de até 81% quando comparados a eles mesmos no período anterior. Usuários regulares cresceram cerca de 12%. Quem não usou IA ficou estável. A própria GitClear destaca que esse efeito ocorre porque os melhores profissionais adotaram a IA primeiro, caracterizando viés de seleção.
O mesmo conjunto de dados expôs o outro lado. Onde o sistema já era frágil, a IA acelerou o problema. Requisitos mal definidos continuam gerando retrabalho, só que mais rápido. Ownership confuso faz pull requests ficarem presos em revisão por mais tempo. Ambientes inconsistentes transformam incidentes em caça ao log. Documentação desatualizada faz decisões voltarem à estaca zero porque ninguém sabe o motivo original. Se o desafio está em decisão e fluxo, IA na codificação não conserta, mas amplifica os problemas. Essa mesma conclusão é encontrada na pesquisa DORA 2025, reforçando o diagnóstico.
Há ainda impactos diretos na qualidade. Segundo a CodeRabbit, pull requests gerados por IA apresentam 1,7 vez mais problemas do que PRs humanos, com aumento de 75% em erros de lógica e até oito vezes mais questões de performance. A GitClear também observou mais duplicação de código, mais tempo de revisão e maior risco de débito técnico, sobretudo entre usuários intermediários.
O que um líder faz em 60 dias para capturar ganho sem aumentar risco
Liderança técnica não começa escolhendo ferramentas, mas sim. Começa definindo o que é um bom resultado. Para alguns times, isso significa reduzir change lead time. Para outros, diminuir incidentes ou retrabalho. Sem esse norte, a velocidade facilmente é trocada por ruído.
O passo seguinte é reduzir fricção antes de automatizar. Padronizar critérios de pronto e de entrada, clarificar quem decide o quê, encurtar ciclos de revisão e melhorar handoffs muda mais o fluxo do que qualquer prompt. A IA passa a atuar sobre um sistema mais previsível, não sobre um caos que já era instaurado.
Limites claros também fazem parte do plano. Há áreas onde a IA pode agir com autonomia e outras que exigem validação humana, como mudanças destrutivas, segurança e produção. Isso reduz risco sem matar o ganho. Métricas como change lead time e frequência de deploy ajudam, desde que usadas como termômetro.
As restrições e direcionamentos para a IA podem ser adicionados como configuração base para o desenvolvimento, tanto no código usando um arquivo chamado AGENTS.md quanto nas regras no ambiente de desenvolvimento. No cursor, existem os arquivos .cursor/rules/*.mdc., mas outros editores e ambientes tem os seus.
Em 60 dias, o objetivo não é adicionar IA em tudo. E sim ter as bases para que a IA consiga auxiliar com salvaguardas suficientes para adicionar velocidade sem aumentar o risco.
O grande resumo
A IA não cria talentos nem conserta sistemas quebrados. Ela amplifica padrões existentes, bons ou ruins. Antes de escalar o uso, líderes técnicos precisam mapear fricções reais e escolher um fluxo para modificar. Criar experimentações e avaliar os resultados traz uma segurança extra, especialmente quando se usa boas práticas e arquivos que permitam “domar” a IA de maneira sistemática.
A pergunta que fica é: hoje, o que mais limita seu time é a decisão, padronização, revisão, ambiente ou observabilidade? E por que isso ainda não foi resolvido?
