Clean Code e IA: o que sobra quando a máquina escreve por você?

Se a IA já aplica os princípios do Clean Code melhor e mais rápido que a gente, esse conhecimento ficou obsoleto ou mais importante do que nunca? Uma reflexão sobre o que a IA automatiza — e o que ela não consegue substituir no dev que entende o porquê por trás das regras.

Se você trabalha com desenvolvimento há mais de dois ou três anos, provavelmente já teve aquela fase: comprou o Clean Code, leu com fé, saiu renomeando variável, quebrando função, aplicando SRP em tudo que via pela frente. Alguns de nós até viraram o dev exigente do code review — o que pedia para trocar o nome do método porque não tava "expressivo o suficiente."

Agora abre o Copilot, o Cursor, o Claude — qualquer um deles. Desenvolve um módulo junto com a IA. O código que volta já vem com nomes razoáveis, funções curtas, responsabilidades mais ou menos separadas. Não é perfeito, mas é bom o bastante. Só que isso traz uma constatação desconfortável: aquele conhecimento que você levou meses para internalizar, a máquina entrega de bandeja. Se você é experiente, o que sobra do Clean Code quando a execução deixa de ser sua? Se está começando agora, vale a pena sequer estudar?

O código que você não escreveu

A IA gera código rápido. Isso não é novidade para ninguém, e é justamente por isso que o uso explodiu. Times inteiros já incorporaram ferramentas de geração de código no fluxo do dia a dia — e o resultado prático é que o volume de código nos projetos cresceu. Só que boa parte desse código não foi escrita por você. Nem pelo seu colega de equipe. Foi gerada por uma máquina — e mesmo que o raciocínio por trás seja seu, a implementação não é. Você não tomou cada decisão de escrita.

No dia a dia, isso muda mais do que parece. O volume de código para revisar aumenta, o ritmo de PRs acelera, e cada vez mais o seu trabalho se parece menos com escrever código e mais com avaliar código que já chegou pronto. Você abre um arquivo gerado por IA e precisa decidir rápido: isso aqui resolve o problema? Resolve do jeito certo? Vai dar manutenção daqui a seis meses? A leitura de código, que sempre foi parte importante do trabalho, virou o centro dele.

E é aí que o papel se inverte. O Clean Code sempre foi tratado como uma disciplina de escrita — como escrever melhor, como nomear melhor, como estruturar melhor. Mas num cenário onde cada vez mais você lê, revisa e mantém código que não escreveu, o valor muda de lugar. Os mesmos princípios que te ensinavam a escrever passam a ser a sua principal ferramenta de leitura. Saber o que é um bom nome de variável importa menos na hora de criar e mais na hora de avaliar se o que a IA te entregou faz sentido.

E aqui vale um ponto de atenção: a IA entrega código funcional. Compila, roda, passa nos testes. Mas funcional não é o mesmo que sustentável. Código que funciona hoje mas que ninguém entende daqui a três meses é dívida técnica disfarçada de produtividade. O "bom o bastante" que a IA entrega pode ser uma armadilha se ninguém na equipe tem repertório para olhar aquilo com olho crítico. O Clean Code não perdeu utilidade — ele trocou de função.

Para quem estamos escrevendo código limpo?

Uma das ideias centrais do Clean Code é que código é comunicação. Você não escreve para o compilador — escreve para o próximo humano que vai ler aquilo. Pode ser um colega, pode ser você mesmo daqui a seis meses. O Uncle Bob repete isso de várias formas ao longo do livro, e não só nos capítulos mais conhecidos sobre nomenclatura ou funções. Quando ele fala sobre comentários, por exemplo, o argumento é claro: um comentário é uma falha em se expressar através do código. Se você precisa de um comentário para explicar o que um trecho faz, o problema não é a falta de comentário — é o código que não está comunicando bem.

É curioso que a IA erre justamente nisso. Peça para qualquer modelo gerar um módulo e observe: o código volta recheado de comentários. // Iterates over the list and filters active users. // Returns the total amount. Comentários que descrevem literalmente o que a próxima linha faz — exatamente o tipo que o Clean Code ensina a evitar. A IA aprendeu a forma, mas não o princípio. Ela comenta porque viu milhões de arquivos comentados, não porque avaliou que ali existe uma complexidade que justifica explicação. Isso, por si só, já revela algo importante: aplicar Clean Code não é seguir padrões — é tomar decisões sobre comunicação.

E isso fica ainda mais evidente quando a gente sai do nível do arquivo e vai para o nível de sistema. Um dos capítulos menos citados do livro é o que trata de limites — as fronteiras entre o seu código e código externo, entre módulos, entre o que você controla e o que você não controla. Definir onde um módulo termina e outro começa, decidir como dois subsistemas se comunicam, escolher o que expor e o que esconder — essas são decisões de arquitetura que carregam visão de negócio. Não existe regra mecânica para isso. Não tem linter que te diga onde colocar a fronteira. É uma decisão humana que exige entender o domínio, os tradeoffs e o que o sistema precisa ser daqui a um ano.

Só que o cenário mudou. Hoje, quem escreve boa parte do código é uma IA. Quem faz a primeira revisão, muitas vezes, também é. Ferramentas de code review automatizado, linters inteligentes, agentes que refatoram — a cadeia de produção de código tem cada vez mais participantes não-humanos. E quando você percebe isso, a pergunta surge naturalmente: se a IA escreve e a IA revisa, para quem exatamente estamos mantendo o código "limpo"?

É tentador concluir que legibilidade humana perde relevância. Mas código não é só instrução funcional — é registro de decisões. Cada escolha de estrutura, de fronteira entre módulos, de quando não comentar, carrega contexto que vai além do que o código faz. Carrega o porquê ele faz daquele jeito. Se otimizamos para máquinas e abrimos mão dessa camada, perdemos algo que nenhuma documentação externa substitui por completo: a intenção embutida no próprio código. E talvez a pergunta certa não seja "para quem escrevemos código limpo", mas "para quê."

O que a IA não automatiza

Se o Clean Code trocou de função — de disciplina de escrita para ferramenta de leitura — e o valor real está na intenção por trás do código, a conclusão natural é que os princípios do livro sempre apontaram para algo mais profundo do que regras de formatação. Eles sempre foram sobre clareza de pensamento.

Pense no tratamento de exceções. O Clean Code dedica um capítulo inteiro a isso, e o argumento central não é sobre sintaxe — é sobre honestidade. Retornar null quando algo dá errado é esconder o problema. Lançar uma exceção genérica é ser vago sobre o que aconteceu. Tratar exceções de forma adequada exige que você tenha pensado nos cenários de falha antes de escrever a primeira linha. Exige que você tenha se perguntado: o que pode dar errado aqui? O que o consumidor desse código precisa saber quando falhar? A IA gera try-catch sem dificuldade. Mas decidir o quê é uma exceção de negócio e como ela deve ser comunicada para o resto do sistema — isso exige entendimento do domínio que nenhum modelo tem sozinho.

O mesmo vale para testes. O Clean Code e o TDD propõem que testes não são uma etapa burocrática no final do desenvolvimento — são uma ferramenta de pensamento. Escrever um teste antes do código te obriga a definir o comportamento esperado antes de se preocupar com a implementação. Te força a responder: o que esse módulo deveria fazer? Quais são os casos de borda? Onde estão as fronteiras de responsabilidade? A IA gera testes unitários com facilidade impressionante. Mas gera testes para o código que existe, não para o comportamento que deveria existir. A diferença é sutil e enorme ao mesmo tempo. Um teste gerado pela IA valida implementação. Um teste escrito com intenção documenta decisão.

E é aqui que o Clean Code sobe de camada. O dev que decorou "funções devem ter no máximo 20 linhas" ou "não use comentários óbvios" aprendeu regras. A IA aplica regras. Mas o dev que entende por quê uma função deve ser pequena — porque responsabilidades misturadas geram acoplamento invisível — ou por quê um comentário óbvio é ruim — porque desloca a responsabilidade de comunicação do código para um texto paralelo que vai desatualizar — esse dev não fica redundante. Ele é justamente quem consegue olhar para o código gerado pela IA e dizer: "isso aqui compila, passa nos testes, mas está escondendo uma decisão de negócio que deveria estar explícita."

O Clean Code não morreu. Ele deixou de ser um checklist e se tornou um filtro crítico para avaliar o que a IA entrega. A IA automatizou a execução — mas o julgamento continua sendo humano.

E agora?

Se você é experiente, talvez o Clean Code já tenha cumprido o papel dele na sua formação — e o desafio agora é perceber que aquilo que você internalizou anos atrás é justamente o que te diferencia num cenário onde a IA escreve código por você. Se está começando, a resposta para aquela pergunta lá do início é: sim, vale a pena estudar. Mas não para decorar regras que uma máquina aplica melhor que você. Vale para construir o repertório que te permite questionar o que a máquina entrega.

O livro continua relevante. Só que o motivo mudou.