Times que adotaram IA pro desenvolvimento de software estão produzindo mais código do que em qualquer momento dos últimos trinta anos. Os pull requests cresceram junto com as tarefas completadas por sprint, e o volume de linhas escritas por desenvolvedor disparou. Só que o impacto correspondente nos resultados do produto, na maioria dos casos, simplesmente não existe.
Vinte e um por cento mais tarefas completadas por sprint, 98% mais pull requests mergeados, mas o relatório da Faros AI, plataforma de métricas de engenharia, que analisou telemetria de mais de dez mil desenvolvedores em 1.255 times, quantificou um fenômeno com precisão desconfortável. Ao mesmo tempo que o tamanho médio dos PRs cresceu 154%, o tempo de revisão aumentou 91% e os bugs subiram 9%. As métricas DORA dessas organizações, que medem a capacidade real de entrega, ficaram estagnadas. O output explodiu, mas o outcome não se mexeu.
Se você desenvolve sistemas há tempo suficiente, seja ou não de TI, sabe que quando se otimiza um componente isolado de um pipeline sem considerar o sistema como um todo, você está simplesmente migrando o gargalo mais pra frente. A Lei de Amdahl descreve: o ganho máximo de um sistema é limitado pela fração que não foi acelerada. IA acelerou a geração de código, que já era, em muitos contextos, uma das partes menos restritivas do ciclo de entrega. O que ficou pra trás (revisão, validação, decisão sobre o que construir) passou a ser o fator limitante. E agora recebe 98% mais volume.
Dezesseis desenvolvedores experientes, 246 tarefas reais nos próprios repositórios open-source, e um resultado que ninguém esperava. O estudo controlado da METR, instituto de pesquisa em avaliação de modelos de IA, publicado em julho de 2025, mostrou que a utilização de ferramentas de IA resultou em tarefas 19% mais lentas, com intervalo de confiança entre +2% e +39%. Antes do experimento, os participantes estimaram que a IA os tornava 24% mais rápidos. Depois de receberem os dados mostrando que foram objetivamente mais lentos, ainda estimaram um ganho de 20%. Em fevereiro de 2026, a própria METR revisou o estudo: uma amostra maior (57 desenvolvedores, mais de 800 tarefas) reduziu a lentidão pra 4%, com intervalo de confiança de -15% a +9%, e a equipe reconheceu vieses severos de seleção na amostra original. Mas o número exato importa menos que o padrão subjacente. A persistência da percepção inflacionada mesmo diante de evidência contrária é o achado mais revelador. Quando o desenvolvedor sente que está produzindo mais independentemente da realidade medida, a tendência natural é gerar mais output sem que a qualidade ou a relevância acompanhem.
O anti-padrão da feature factory ganha uma dimensão nova com IA. Assim que o custo de produzir uma feature cai drasticamente, a barreira natural que antes forçava priorização desaparece. Se construir uma funcionalidade custava duas sprints de um time de quatro pessoas, havia um incentivo econômico real pra validar se aquela funcionalidade merecia existir. Se a mesma funcionalidade pode ser gerada em dois dias com assistência de IA, o backlog inteiro vira candidato a implementação. A organização produz mais funcionalidades que ninguém pediu nem validou, e que ninguém vai usar, só que agora faz isso na metade do tempo.
Num time que acompanhei recentemente, quatro desenvolvedores utilizando Cursor com Claude Sonnet como assistente principal triplicaram as funcionalidades entregues num trimestre. O backlog de bugs no trimestre seguinte cresceu na mesma proporção. O tempo de onboarding de novos desenvolvedores mais que dobrou. Tickets de suporte sobre funcionalidades que os usuários não entendiam como usar subiram significativamente. A velocidade percebida no T1 converteu-se em custo operacional no T2 e T3, e o saldo líquido de valor entregue ao negócio foi negativo.
Considero a IA um amplificador. Amplifica a capacidade de produção de quem sabe o que tem que produzir, enquanto amplifica o desperdício de quem não tem. A diferença está na existência de um critério de filtragem que deve ser anterior à produção. Esse critério pertence ao domínio de produto e a pergunta que o materializa deveria preceder qualquer linha de código: esta funcionalidade resolve um problema validado por usuários reais? O impacto esperado justifica o custo total de propriedade, incluindo manutenção, testes, suporte e complexidade adicionada?
A fragilidade organizacional que percebo em tudo isso não é nova. Só estava escondida pela fricção natural do processo de desenvolvimento. Muitas organizações nunca tiveram um processo de validação de valor porque o custo de construir era alto o suficiente pra funcionar como filtro implícito. IA reduziu o custo marginal de produção e removeu esse filtro. A ausência de disciplina de produto agora é visível na forma de repositórios inchados, produtos confusos e times que trabalham mais horas em coisas que importam menos.
Produzir código rápido foi comoditizado. O valor de um engenheiro migrou pra capacidade de decidir o que NÃO construir. Quem está, contraintuitivamente, usando IA pra entregar menos features, mas com melhor validação e com superfície menor de manutenção, está precisamente no nível que a ferramenta sozinha não alcança. Esse é o diferencial a ser buscado, pois é onde mora o real valor técnico do novo mercado de desenvolvimento.