Tem time descobrindo isso do jeito mais caro possível: a IA realmente ajuda a entregar mais rápido, mas velocidade sozinha não melhora arquitetura, não simplifica sistema e não assume a conta da manutenção depois.
O ponto mais incômodo desse debate nem é técnico. É cultural. Quando a régua vira “produzir mais código”, fica muito fácil confundir volume com maturidade — e empilhar decisões que parecem boas no sprint, mas voltam como custo, retrabalho e complexidade nos meses seguintes.
Bryan Cantrill resumiu essa tensão de um jeito difícil de ignorar no texto The peril of laziness lost. Para ele, uma das virtudes clássicas da programação é a “preguiça” no bom sentido: criar abstrações melhores para não precisar repetir trabalho ruim depois. O problema, diz ele, é que modelos de IA não têm esse instinto. Eles não sentem a dor futura do sistema. Se ninguém frear, a tendência é despejar mais e mais coisa em cima de uma base já confusa.
O risco não é a IA escrever código. É ninguém querer pagar o custo de entender o que entrou
Esse alerta ficou especialmente concreto num relato aberto do Lobsters sobre um ambiente que rodava trocando planilhas por e-mail. Um funcionário começou a automatizar partes do processo em VBA. Aos poucos, a empresa foi pedindo mais. Segundo o relato, “com 3 mil linhas ele descobriu loops; com 10 mil linhas descobriu que podia definir as próprias funções”. Quando ele avisou que aquilo já pedia um sistema de verdade e um desenvolvedor de verdade, a resposta foi a mais previsível do mundo: sem orçamento.
Ele saiu. A gambiarra ficou. E a empresa seguiu dependente de um código que ninguém queria assumir de verdade.
É aí que esse caso conversa muito com a fase atual da IA no trabalho real. O problema quase nunca começa como loucura. Começa como atalho razoável: acelerar uma tarefa repetitiva, fechar um backlog, tirar um fluxo manual do caminho, montar uma primeira versão mais rápido. O estrago aparece quando o time para de perguntar se aquela saída ficou mais simples, mais legível e mais sustentável.
A parte boa da IA existe — mas ela não substitui rigor
As diretrizes públicas da Oxide para uso de LLMs são bem claras num ponto importante: IA é ferramenta, não substituto de responsabilidade humana. O texto insiste que julgamento, rigor e responsabilidade continuam no time, mesmo quando a máquina ajuda a produzir código, documentação ou revisão.
Esse ponto aparece também numa discussão aberta no Hacker News sobre entrevistas na era do código assistido por IA. Um dos comentários mais úteis resume bem a nova régua: o sinal não é “quem sabe usar o brinquedo da semana”, mas quem consegue definir o escopo, revisar a saída, explicar trade-offs e limpar o que o modelo errou.
Em português claro: IA pode acelerar a mão. Mas não deveria desligar o cérebro.
O que muda na prática para equipes de TI
Se a sua equipe já usa Copilot, Claude, Codex ou similares, a pergunta útil não é mais se vale usar. Essa etapa já passou. A pergunta útil agora é outra: o que vocês não aceitam mergear, mesmo que a IA tenha feito em minutos?
Alguns filtros simples ajudam muito:
1. Quem pediu a mudança consegue explicar a decisão sem abrir o chat?
Se a pessoa não consegue justificar por que aquele fluxo existe, por que aquela abstração entrou ou por que aquele trecho foi escrito daquele jeito, o time provavelmente está herdando código sem dono intelectual.
2. A solução ficou mais simples ou só ficou maior?
Código gerado costuma errar pelo excesso: camadas demais, defensividade demais, arquivos demais, complexidade demais para resolver pouco.
3. O ganho de velocidade veio com teste e observabilidade suficientes?
Feature que “funciona” em demo e quebra silenciosamente em produção não é aceleração. É só dívida chegando mais cedo.
4. O time aceitaria manter esse trecho por um ano?
Essa pergunta corta muita ilusão. Se ninguém quer tocar no que acabou de entrar, o problema não é a produtividade. É a qualidade da decisão.
5. A IA está tirando trabalho mecânico — ou tirando aprendizado essencial?
Para gente mais júnior, isso importa ainda mais. Boilerplate, organização inicial e busca de referências podem ganhar velocidade. Já entendimento de fluxo, leitura de código, debug e tomada de decisão continuam sendo base de carreira.
O erro de gestão que mais se repete
O erro mais perigoso nessa fase é usar IA para baratear discernimento.
Quando liderança começa a olhar só para volume, prazo ou número de entregas, a ferramenta vira biombo para mascarar problema antigo: falta de arquitetura, revisão fraca, pressa crônica e pouca disposição de investir em sistema decente antes de a bagunça escalar.
Foi exatamente isso que o caso da planilha escancarou. Não faltou automação. Faltou a decisão de profissionalizar a solução antes que ela virasse dependência.
Com IA, a diferença é que essa bagunça pode crescer muito mais rápido.
O melhor uso da IA ainda parece o mais pé no chão
Quando o time sabe o que está fazendo, IA ajuda bastante a destravar rascunho, explorar caminhos, reduzir trabalho repetitivo e acelerar partes chatas do fluxo. Quando o time não sabe, ela também acelera — só que acelera confusão, falsa confiança e acúmulo de código que ninguém quer ler depois.
No fim, a régua continua bem menos futurista do que parece: software bom ainda depende de clareza, simplificação, revisão e responsabilidade.
Mais código nunca foi sinônimo automático de engenharia melhor. Com IA, isso só ficou mais urgente.
