IA no dia a dia de quem programa: onde acelera de verdade e onde cria dívida silenciosa

O exagero e o uso real

Existem dois discursos sobre IA generativa aplicada a código, e os dois exageram. Um diz que ela vai substituir programadores. O outro diz que é só um autocomplete chique, sem valor real. A experiência prática de quem usa isso todo dia está no meio: IA muda o ritmo de partes específicas do trabalho, sem mudar a natureza do trabalho em si — que continua sendo entender problemas e tomar decisões.

Vale separar onde ela ajuda de verdade de onde ela só parece ajudar.

Onde a IA realmente acelera

• Boilerplate e código repetitivo. Configuração inicial, CRUDs, adaptação de um padrão já existente para um caso novo — tudo isso é exatamente o tipo de tarefa que IA resolve rápido e bem, porque a solução já existe em algum lugar e só precisa ser adaptada.
• Exploração de bibliotecas e APIs desconhecidas. Perguntar "como eu faço X nessa lib" e receber uma resposta contextual economiza o tempo de vasculhar documentação incompleta.
• Testes para código já escrito. Gerar casos de teste a partir de uma função existente costuma ser mais rápido — e mais completo — do que escrever na mão, porque a IA lembra de casos de borda que a pessoa cansada às 18h esquece.
• Primeira versão de algo que você vai revisar de qualquer forma. Rascunho de uma migração, de um script de dados, de uma função utilitária — onde o valor está em ter um ponto de partida, não em ter a versão final.

Onde ela cria dívida silenciosa

• Código que resolve o problema mas ninguém entende por quê. O maior risco não é a IA gerar algo errado — é gerar algo que funciona, mas cuja lógica ninguém do time consegue explicar seis meses depois. Isso é dívida técnica pura, só que sem o alívio de saber que foi um atalho consciente.
• Revisão superficial de pull request grande. Quando o volume de código gerado cresce, a tentação é revisar por cima. Um PR de duzentas linhas geradas revisado em cinco minutos é um convite a bug sutil.
• Decisões de arquitetura. IA é ótima para preencher os detalhes de uma decisão já tomada. É ruim para tomar a decisão em si — porque decisão de arquitetura depende de contexto de negócio, de restrições de time e de futuro que não estão no prompt.
• Confiança em nome de velocidade. Aceitar uma sugestão porque "parece certa" e o prazo está apertado é a receita clássica para o bug que só aparece em produção, sob carga, três semanas depois.

Uma regra simples: se você não consegue explicar, não faça merge

A régua mais prática que existe para isso é antiga e não tem nada de específico de IA: se você não consegue explicar por que aquele código funciona, ele não está pronto para o merge — não importa quem ou o que escreveu. Isso não é desconfiança da ferramenta. É a mesma régua que já deveria valer para código copiado do Stack Overflow, de um colega, ou de qualquer fonte externa.

O ganho real está no ciclo, não na linha de código

O erro de medir o valor da IA é contar linhas de código geradas por minuto. O ganho de verdade aparece no ciclo inteiro: menos tempo perdido em tarefas mecânicas libera tempo para a parte que IA ainda não faz bem — entender o problema certo, desenhar a solução certa e decidir o que não construir. Times que usam IA bem não programam mais rápido. Pensam mais rápido, porque terceirizaram a parte que não exigia pensamento.