IA para programar: como usar sem virar refém da ferramenta

Tem dev que dobrou de produtividade com IA. E tem dev que não consegue mais escrever uma função sem ela. A diferença não é o modelo, não é a stack, não é o quanto a pessoa paga de assinatura. A diferença é o workflow.

Usar IA para programar virou o padrão. 84% dos desenvolvedores já usam ou planejam usar ferramentas de IA no fluxo de trabalho, contra 76% no ano anterior. O problema não é se você usa. É como você usa — e o que sobra de você quando a ferramenta sai da mesa.

Neste post a gente separa as duas coisas: IA como alavanca, que te deixa mais rápido sem te apagar, e IA como muleta, que te entrega velocidade hoje e cobra a conta lá na frente, quando o código quebra e você não faz ideia de por quê.

TL;DR

• O que é: um jeito de usar IA para programar mantendo o entendimento do próprio código — não terceirizando o raciocínio.
• O dado incômodo: num estudo controlado da METR, devs experientes ficaram 19% mais lentos com IA, mesmo achando que estavam mais rápidos.
• A regra de ouro: se você não consegue revisar e explicar o que a IA escreveu, você não programou — você apostou.
• Pra quem é: dev que quer ganhar velocidade sem perder a capacidade de debugar o sistema quando o agente erra.

IA para programar: o que os números realmente dizem

A narrativa de marketing é simples: IA te deixa mais rápido. E tem dado real por trás disso. O estudo da própria GitHub sobre o Copilot mostrou 55% mais velocidade pra completar uma tarefa. O detalhe que ninguém cola no slide: essa tarefa era uma — implementar um servidor HTTP em JavaScript, isolada, bem definida, sem dívida técnica, sem legado, sem ninguém pra revisar. Ou seja: o cenário de laboratório onde a IA brilha mais.

Aí veio o contraste. A METR rodou um experimento controlado no começo de 2025 com 16 devs experientes, em projetos open-source maduros, onde eles tinham em média 5 anos de bagagem. Resultado: com IA liberada, eles ficaram 19% mais lentos. E a parte que dói: antes do teste, esses devs achavam que a IA ia deixá-los 24% mais rápidos. Depois de terminar, ainda achavam que tinham sido 20% mais rápidos. Estavam mais lentos e não perceberam.

Não é que a IA seja ruim. É que ela é ótima no cenário do GitHub — código novo, escopo fechado — e traiçoeira no cenário da METR — base grande, padrões rígidos, contexto que o modelo não tem. O dev que mistura os dois e trata tudo como "é só pedir pro Cursor" é o que vira refém. (Qual ferramenta rende mais em cada cenário a gente já testou lado a lado.)

O "quase certo" é onde você se queima

Pergunta pra qualquer dev que apanhou de IA qual é a pior parte. A resposta bate com o dado: 66% dos desenvolvedores dizem que a maior frustração é "código que está quase certo, mas não exatamente". E a segunda maior, com 45%, é que debugar código gerado por IA dá mais trabalho.

Pensa no que isso significa. Código óbvio errado você descarta em dois segundos. O problema é o código que compila, parece certo, passa no teste feliz, e tem um bug sutil escondido numa borda que você nem olhou — porque você não escreveu, você aprovou. Quanto menos você entende o que a IA fez, mais caro fica achar esse bug. É exatamente aí que a velocidade da geração vira lentidão no debug.

E não é coincidência que a confiança esteja caindo enquanto o uso sobe. Na pesquisa da Stack Overflow de 2025, com 49 mil respostas, 46% dos devs desconfiam ativamente da precisão da IA, contra 33% que confiam. Só 3% confiam "muito". Os mais céticos? Justamente os mais experientes — os que já pagaram pra ver.

A conta que vem depois: atrofia

Tem um custo que não aparece na sprint atual. Aparece seis meses depois.

Um estudo de 2025 com 666 participantes mediu a relação entre uso de IA e pensamento crítico. O resultado é direto: quanto mais a pessoa terceiriza tarefas cognitivas pra IA (o tal "cognitive offloading"), menor o pensamento crítico — correlação negativa de -0,75. E o detalhe que importa pro nosso lado: os mais novos não estavam perdendo uma habilidade que tinham. Estavam terceirizando uma habilidade que nunca chegaram a construir.

Traduz pra dev: se você aprendeu a estruturar um sistema, ler um stack trace e modelar um domínio antes da IA, usar IA é alavanca — você delega o que já domina. Se você nunca construiu esse repertório e já começou pedindo tudo pronto, a IA não é alavanca. É a única perna que te sustenta. No dia que ela trava, alucina, ou te entrega o "quase certo", você não tem pra onde correr.

Isso é o "refém" do título. Não é deixar de usar IA. É depender dela pra coisas que você deveria conseguir fazer sozinho.

Workflow saudável: como usar IA para programar sem virar refém

Não tem fórmula mágica. Tem disciplina. Quatro regras que separam alavanca de muleta:

1. Você revisa tudo. Sem exceção.

Linha que entra no seu commit é sua responsabilidade, não da IA. Se você não consegue ler o diff e explicar por que cada parte está ali, não dá merge. Aceitar código sem revisar é o que a gente chamou de vibe coding — e onde ele quebra. O teste mental é brutal e simples: se esse código quebrar às 3 da manhã em produção, eu consigo debugar? Se a resposta é não, você não terminou.

2. Peça o "porquê", não só o "o quê".

Em vez de "escreve a função X", force a IA a expor o raciocínio. Isso mantém você no circuito de decisão em vez de virar carimbador.

Antes de escrever o código, me explique:
1. Quais abordagens existem pra resolver isso e o trade-off de cada uma.
2. Qual você recomenda pra um sistema com [contexto real: volume, latência, time pequeno].
3. Onde essa solução quebra se o requisito mudar.

Só depois escreva a implementação.

Você lê, discorda quando faz sentido, e aprende no processo. A IA vira par de programação, não oráculo.

3. Use IA pra acelerar o que você entende, não pra esconder o que você não entende.

Boilerplate, teste repetitivo, conversão de formato, varredura de uma API que você já conhece — manda ver, é exatamente onde os 55% de ganho aparecem. Arquitetura de um sistema novo, decisão de modelagem, escolha que vai custar caro pra reverter — aí você pensa primeiro, e usa a IA pra pressionar a sua ideia, não pra substituí-la.

4. Treine sem rede de vez em quando.

Como músico que pratica escala. Resolva um problema do zero sem autocomplete, leia um stack trace sem colar no chat, modele um domínio no papel. Não é nostalgia — é manter vivo o músculo que faz você conseguir avaliar quando a IA está errada. Quem não consegue avaliar a resposta não está no comando.

Sinais de que você já virou refém

Checklist honesto. Se bater três, acende o alerta:

• Você não consegue começar uma função sem abrir o chat.
• Quando a IA dá uma resposta errada, você pede de novo em vez de pensar.
• Você não revisa o código gerado — só roda e vê se passa.
• Você não saberia explicar, numa conversa técnica, por que o seu próprio código funciona.
• Travou a internet, travou você.

Nenhum desses é sobre usar IA demais. É sobre ter parado de entender.

FAQ rápido

Então eu devo usar menos IA? Não necessariamente. Use a mesma quantidade, com mais consciência. A diferença entre alavanca e muleta não é o volume de uso — é se você entende o que está aceitando. Dev sênior usa muita IA e continua no comando porque revisa, questiona e sabe quando ignorar.

IA não vai me deixar mais lento como no estudo da METR? Pode, em base grande e madura, se você usar no piloto automático. O próprio estudo sugere que o tiro sai pela culatra quando o modelo não tem o contexto que você já tem na cabeça. Em código novo e escopo fechado, o ganho é real. Saber em qual cenário você está já é metade do jogo.

Sou júnior. Como uso IA sem atrofiar o que ainda nem aprendi? Use a IA como professor, não como entregador. Peça explicação, peça alternativas, peça pra ela te apontar o erro — mas escreva você a primeira versão. O risco do júnior não é usar IA. É pular a etapa de construir o repertório que permite avaliar a IA depois.

Como sei se estou no controle? Teste do diff: leia o que a IA gerou e tente explicar em voz alta, linha por linha. Se travar, você não está usando uma ferramenta. Está confiando numa caixa-preta.

O ponto não é a IA. É quem está no comando.

Recapitulando: IA para programar deixa você rápido no escopo certo (código novo, bem definido) e te sabota no escopo errado (base madura, no automático). O "quase certo" é a armadilha cara. E a conta de longo prazo — atrofia — vem pra quem terceiriza raciocínio em vez de delegar execução. O divisor de águas é um só: você revisa, entende e consegue debugar, ou você aposta e torce.

O próximo salto do desenvolvedor não é usar IA. É saber construir produtos reais com IA — arquitetar a solução, decidir onde o agente entra, onde o humano decide, e onde nenhum dos dois deveria estar sozinho. É exatamente esse tipo de decisão que a gente coloca na mesa no Workshop Arquitetando Soluções de IA: como desenhar software com agents de IA sem terceirizar o entendimento do sistema. Porque no fim a pergunta não é se a IA escreve o código. É se você ainda entende o código que ela escreveu.