IA escrevendo código: o que mudou no custo de software e o que não mudou

Em quase toda conversa comercial do último ano aparece alguma versão da mesma pergunta: se a IA escreve código, por que ainda preciso de uma empresa de software? É uma pergunta legítima, e merece uma resposta honesta — inclusive na parte em que a IA realmente mudou o jogo.

O que os números mostram

A pesquisa anual do Stack Overflow de 2025 ouviu mais de 49 mil desenvolvedores em 177 países. Dois resultados dela, lidos juntos, contam a história inteira.

84% usam ou pretendem usar ferramentas de IA no desenvolvimento, contra 76% no ano anterior. A adoção não é tendência: já é o padrão.

A desconfiança na precisão subiu de 31% para 46%. Quase metade dos desenvolvedores não confia no que a ferramenta devolve.

Repare que essas duas curvas apontam para lados opostos. Normalmente, quanto mais se usa uma ferramenta, mais se confia nela. Aqui aconteceu o contrário — e o motivo aparece na pergunta sobre frustrações.

A queixa mais citada, por 66% dos respondentes, não é que a IA não consegue escrever código. É lidar com soluções "quase certas, mas não exatamente". E 45% dizem que depurar código gerado por IA toma mais tempo do que depurar código escrito à mão.

O problema não é o código errado. Código errado quebra, você descobre e conserta. O problema é o código quase certo, que funciona na demonstração e falha em produção, num caso que ninguém pensou em testar.

O custo não sumiu — mudou de lugar

Construir software sempre teve quatro custos: decidir o que construir, escrever, fazer funcionar junto com o que já existe e manter de pé ao longo do tempo.

A IA atacou o segundo com força. Escrever ficou drasticamente mais barato — e quem diz o contrário não usou as ferramentas a sério. O ponto é que os outros três continuam praticamente intocados, e eles sempre foram a maior parte da conta.

Decidir o que construir. A IA não sabe que o seu financeiro fecha no dia 5, que esse cliente tem contrato diferente, nem qual das três regras conflitantes que você descreveu é a que vale. Essas respostas vêm da operação, não do modelo.

Integrar. O ERP legado com documentação desatualizada, a API do banco que responde diferente do manual, o sistema interno que só aceita arquivo posicional. É aqui que projeto corporativo trava, e não é por falta de linha de código.

Manter de pé. Carga de fechamento de mês, dependência externa que cai, mudança de regra, auditoria pedindo explicação de uma decisão de oito meses atrás.

Na nossa experiência com operações grandes, o tempo de digitação nunca foi o gargalo. Era entender a regra de negócio e sobreviver à integração.

Onde a IA ganha de lavada

Seria desonesto escrever só a parte cética. Há usos em que a diferença é brutal, e eles valem para qualquer empresa:

Protótipo para decidir. Transformar uma ideia em algo clicável em dias, para descobrir cedo que metade do que foi pedido ninguém usaria. Isso economiza dinheiro de verdade.

Trabalho repetitivo com padrão claro. Migração de formato, cobertura de teste, refatoração mecânica, documentação de código existente.

Entrar em território desconhecido. Uma biblioteca nova, uma linguagem que o time não domina: a IA encurta a rampa de dias para horas.

Primeira versão de interface. Partir de algo pronto para criticar é mais rápido do que partir da tela em branco.

O padrão nos quatro casos é o mesmo: a IA é excelente quando existe alguém capaz de julgar o resultado. Ela acelera quem sabe avaliar, e multiplica o erro de quem não sabe.

A armadilha do código plausível

Vale separar esse ponto, porque ele é contraintuitivo. Revisar código humano ruim é relativamente fácil: ele costuma ser confuso, e a confusão é o sinal de alerta.

Código gerado por IA raramente é confuso. Ele é bem formatado, tem nomes razoáveis e estrutura coerente. Quando está errado, está errado de forma organizada — e isso atravessa revisão humana muito mais facilmente, porque o revisor lê a forma e assume o conteúdo.

A consequência prática é que a revisão precisa mudar de método: menos "isso parece certo?" e mais "o que acontece se a entrada vier vazia, duplicada, fora de ordem ou grande demais?". É uma revisão mais cara que a antiga, não mais barata — e é essa conta que some das estimativas otimistas.

O que perguntar antes de aceitar um sistema

Se você está avaliando uma proposta — interna ou de fornecedor — em que a IA tem papel grande no desenvolvimento, essas perguntas revelam mais do que qualquer apresentação:

Quem revisa o que a IA gera, e com que critério escrito?

O que existe de teste automatizado, e o que acontece quando um teste falha depois da entrega?

Como o sistema se comporta quando uma dependência externa fica fora do ar? Isso foi testado ou está no papel?

Quem responde pela sustentação depois da entrega, e por quanto tempo?

Você fica com o código e com a infraestrutura, ou fica preso a quem construiu?

A pergunta útil deixou de ser "quanto tempo leva para ficar pronto". Passou a ser "quem responde quando isso quebrar às duas da manhã".

O que isso significa para quem vai construir

Nenhuma das duas conclusões extremas se sustenta. "IA substitui time de software" ignora que escrever código era a parte barata. "IA não serve para nada sério" ignora 84% de adoção entre profissionais que não têm motivo para se enganar.

A leitura que se sustenta é mais chata e mais útil: a IA mudou a economia da primeira versão, e não mudou a economia do sistema que fica. Projeto que confunde as duas coisas entrega rápido, parece barato e cobra a diferença no primeiro ano de operação.

Se o que você precisa é descobrir se uma ideia merece investimento, prototipe — com IA, rápido e barato. Se o que você precisa é um sistema que vai sustentar faturamento, atender auditoria e durar anos, a conversa é outra, e a ferramenta usada para escrever o código é o detalhe menos importante dela.