Código nunca foi commodity · Episódio 8
A ferramenta não tem culpa. E agora, pra onde olhar
A IA é amplificador, não ré: por que automatizar o repetitivo e não o julgamento, e onde investir para a ferramenta render. O fecho da série.
Neste artigo · 6 seções
Sete artigos falando de IA e crise de engenharia, e em nenhum deles a IA foi a ré. Isso não foi descuido. Foi o ponto. A tese que costura esta série inteira nunca foi "a IA está estragando o software". Foi o contrário: a ferramenta não tem culpa de nada, e é exatamente por isso que ela é tão perigosa na mão errada e tão poderosa na mão certa.
Hunt e Thomas, no Pragmatic Programmer, escreveram em 1999 uma regra que hoje parece feita pra reunião de post-mortem: "Não culpe todos os problemas num fornecedor, numa linguagem de programação, na gestão ou nos seus colegas. Qualquer um deles pode ter um papel, mas cabe a você prover soluções, não desculpas" (no original, "Don't blame all the problems on a vendor, a programming language, management, or your coworkers. Any and all of these may play a role, but it is up to you to provide solutions, not excuses."). Eles chamaram a seção de "o gato comeu meu código-fonte". Vinte e sete anos depois, a desculpa ganhou roupa nova. "A IA escreveu errado" é o novo gato comendo o dever de casa. A ferramenta muda, a responsabilidade não.
são duas ferramentas, não uma
O erro de leitura que originou toda a confusão foi tratar a IA como substituta de uma ferramenta que já existia: a engenharia. Como se fossem concorrentes, e uma tornasse a outra obsoleta. Não são. São duas ferramentas que se usam juntas. A engenharia é o que decide o que construir, como modelar, o que recusar. A IA é o que acelera a parte mecânica de produzir. Quem tem as duas na mão anda mais rápido. Quem largou a primeira achando que a segunda faz o trabalho dela ficou com meia caixa de ferramentas e a ilusão de estar completo.
É por isso que a IA amplifica. Ela pega o que você já é e multiplica. Fundamento forte embaixo, ela multiplica acerto. Fundamento fraco, multiplica lixo, na mesma velocidade e com a mesma confiança. O amplificador não tem opinião sobre o sinal que entra. Ele só aumenta o volume. Ligar um amplificador num instrumento desafinado não conserta a afinação; deixa o desafinado mais alto.
automatize o repetitivo, não o julgamento
Tem uma linha divisória que separa o uso bom do uso desastroso da IA, e ela é antiga. O Accelerate, a maior pesquisa de entrega de software que existe, resume numa frase: "Computadores executam tarefas repetitivas; pessoas resolvem problemas" (no original, "Computers perform repetitive tasks; people solve problems."). O Pragmatic diz o mesmo pelo outro lado: "As pessoas simplesmente não são tão repetíveis quanto os computadores" (no original, "People just aren't as repeatable as computers are."). Junte os dois e você tem a régua: entregue pra máquina o que é mecânico e repetível, e guarde pra pessoa o que exige julgamento e entendimento.
Automatizar o build, o deploy, o boilerplate, a tarefa chata que se repete: isso é a face legítima de "deixar a máquina fazer". Sempre foi. Delegar o julgamento sobre o que é correto, sobre qual código deveria existir, sobre o que vai quebrar em produção: isso é onde a coisa desanda. E os autores do Pragmatic já tinham visto esse filme, com a ferramenta da época deles, os geradores de código do IDE. O aviso é cirúrgico: "usar um wizard projetado por um guru não torna o desenvolvedor Joe automaticamente igual de especialista... a menos que Joe realmente entenda o código produzido em seu nome, ele está se enganando. Está programando por coincidência" (no original, "using a wizard designed by a guru does not automatically make Joe developer equally expert... unless Joe actually understands the code that has been produced on his behalf, he's fooling himself. He's programming by coincidence."). Troque wizard por modelo de linguagem e o parágrafo é de 2026. Eles escreveram sobre geradores de IDE, sem imaginar um LLM; a transposição é minha, mas o princípio não envelheceu um dia. Aceitar código que você não entende porque "passou no teste rápido" é programar por coincidência, e o problema da coincidência é que você não consegue debugar o que nunca entendeu.
sem fundamento, o enfeite é irrelevante
Aqui está a frase do Pragmatic que eu queria emoldurar na parede de quem decide orçamento de IA: "Se você não tem os fundamentos ou a infraestrutura corretos, sinos e assobios brilhantes serão irrelevantes" (no original, "If you don't have fundamentals or infrastructure correct, brilliant bells and whistles will be irrelevant."). Os sinos e assobios brilhantes de hoje são as features geradas em minutos, a demo que impressiona na sexta. Sem fundamento embaixo, tudo isso é irrelevante, porque quebra no primeiro caso que ninguém previu, e aí não tem quem conserte, porque ninguém entende o que foi gerado.
Isso amarra o que a série inteira foi dizendo, artigo por artigo. O fundamento não é uma coisa só. É liderança que constrói em vez de só cobrar prazo. É produto que entende o domínio a ponto de saber qual feature move o ponteiro. É código em que "sei SOLID" aparece no diff, não só na entrevista, tema que destrinchei em Você disse que sabe SOLID. Seu código diz que não.. É a rede de testes que deixa mudar sem apostar, o caso que fiz em Testes não são burocracia. São a sua apólice.. É o modelo de domínio no lugar certo, que defendi em DDD não é coisa de dev. Cada um desses é um pedaço do fundamento que a IA pressupõe e não fabrica.
o mercado já mostrou a conta
Nada disso é opinião de quem tem medo de perder o emprego pra máquina. Ao longo da série, os números foram aparecendo, e todos apontam pro mesmo lugar. A GitClear mediu a erosão: menos reaproveitamento de código, mais duplicação, mais retrabalho, exatamente no período de adoção em massa. Stanford mediu que quem usa assistente escreve código menos seguro e fica mais convencido de que está seguro. A METR mediu desenvolvedores experientes ficando mais lentos com a ferramenta enquanto juravam estar mais rápidos. O relatório DORA de 2024 foi seco ao dizer que a IA, sem os fundamentos, não melhora a entrega. E a Replit deu o retrato do pior caso, com a IA apagando um banco de produção e chamando o próprio estrago de erro catastrófico de julgamento.
E a big tech, que não é romântica com engenharia, reagiu da forma mais reveladora possível. Depois de uma série de incidentes ligados a mudanças assistidas por IA, a Amazon voltou a exigir que um engenheiro sênior aprove todo código gerado com IA, tratando o sênior como filtro humano. Repara na direção do movimento. No auge do discurso de que a IA dispensaria o engenheiro, a empresa que mais escala engenharia no mundo recolocou o humano experiente no centro do processo. Não por nostalgia. Por sobrevivência operacional.
pra onde olhar
Se a ferramenta não tem culpa, pra onde a gente olha? Não pra ela. A resposta incômoda é que o lugar certo de olhar é o mais chato, o mesmo de sempre, o que nenhum vendedor de GPU vai te vender: o fundamento.
O Accelerate fecha o livro inteiro com a frase que devia encerrar esta série: você não compra nem copia alta performance, ela se desenvolve com esforço, investimento, foco e tempo. Ferramenta é comprável. Capability não. Quem trata a IA como um atalho pra pular a construção do fundamento entendeu a coisa exatamente ao contrário, porque a IA só rende sobre um fundamento que já existe. Olhar pra onde importa é investir onde a série toda apontou: na liderança que amplifica o time em vez de só cobrar, no produto que senta na sala de modelagem, no engenheiro que domina os fundamentos, na rede de testes, no modelo de domínio, na agilidade que é capability e não cerimônia. É tudo a mesma doença tratada de ângulos diferentes: parar de comprar o rótulo e voltar a construir a capacidade.
E aí a IA deixa de ser ameaça e vira o que ela é de verdade, uma alavanca absurda de poderosa. Na mão de quem tem o fundamento, ela multiplica o alcance de cada bom engenheiro. Foi essa a promessa real, não a de substituir o julgamento, mas a de amplificá-lo. Confundir as duas é o erro que a conta cobra.
Volto pra onde a série começou. Quem corta o julgamento porque a digitação ficou barata compra a pá que enriquece a NVIDIA e cava o próprio buraco, achando que fez um ótimo negócio. Quem mantém o julgamento e usa a ferramenta pra ampliá-lo faz o oposto: transforma o mesmo modelo, o mesmo custo de token, em vantagem competitiva real. A ferramenta é a mesma nos dois casos. O que muda é quem está segurando ela, e se essa pessoa sabe o que está fazendo.
A ferramenta nunca teve culpa. E nunca vai ter. A pergunta que decide o futuro da sua empresa não é o que a IA vai fazer com você. É o que você tem embaixo dela pra ela amplificar. Olhe pra lá.
Insights & Takeaways
- A IA nunca foi a ré. "A IA escreveu errado" é o novo "o gato comeu meu código-fonte": a ferramenta muda, a responsabilidade pelo resultado não. Você provê soluções, não desculpas.
- São duas ferramentas, engenharia e IA, usadas juntas. A IA é um amplificador: multiplica o acerto de quem tem fundamento e o lixo de quem não tem, na mesma velocidade e com a mesma confiança.
- Automatize o repetitivo, não o julgamento. Deixar a máquina fazer o mecânico é legítimo e antigo; delegar o entendimento sobre o que é correto é programar por coincidência, e não se debuga o que não se entende.
- Sem fundamento, o enfeite é irrelevante. As features geradas em minutos quebram no primeiro caso não previsto se não houver liderança, domínio, testes e design embaixo. O mercado já mediu a conta: GitClear, Stanford, METR, DORA, e a Amazon recolocando o sênior como filtro.
- Pra onde olhar não é pra ferramenta, é pro fundamento. Você não compra nem copia alta performance. Quem investe no fundamento usa a IA como alavanca; quem corta o fundamento achando que a IA substitui compra a pá e cava o próprio buraco.
