Por muito tempo, a parte difícil de programar foi descobrir como implementar. O problema chegava e o esforço ia para a estrutura: que abordagem, que modelo de dados, como encaixar no que já existe sem criar dívida. Escrever um bom código sempre foi requisito — qualidade nunca foi opcional —, mas era no "como" que o trabalho de verdade morava.
A IA resolve esse "como" mais rápido do que quase qualquer um resolveria à mão. Descrita a intenção, a implementação aparece pronta: organizada, coerente, muitas vezes melhor que o primeiro rascunho humano. A consequência não é que o código virou descartável. É que produzir um bom código deixou de ser onde está o valor. Código limpo que funciona é a linha de base agora, não o entregável. O entregável é a arquitetura — qual forma o sistema deveria ter, e se essa forma é a certa para o problema.
E há uma armadilha no caminho: o erro da máquina quase nunca é feio. Sai limpo, bem indentado, convincente — e furado. O risco não é o código que não compila; é o que parece pronto e não está.
Onde a máquina falha
As falhas da IA não são aleatórias; repetem-se em formatos previsíveis.
Ela não dimensiona. Ataca um problema pequeno com um canhão — três camadas de abstração para o que pedia uma função — com a mesma tranquilidade com que subestima um problema grande, devolvendo uma solução simples e confiante para algo que escondia cinco casos de borda.
Ela não tem memória de convenção. Sem um padrão definido, gera N soluções igualmente plausíveis e igualmente diferentes: três formas de tratar erro, dois jeitos de nomear, quatro estilos de organizar uma pasta. Cada uma funciona isolada; juntas, formam um museu de estilos que ninguém mantém.
Ela escreve inseguro com a mesma naturalidade com que escreve correto. Não hesita antes de concatenar uma query, confiar num input, deixar um segredo no lugar errado.
A raiz é sempre a mesma: a IA resolve o problema que foi descrito, com o contexto que recebeu, sem ser dona do resultado. A dona é você. Tudo abaixo é sobre exercer essa posse.
As abordagens — o que fazer
Especificar antes de gerar. A saída é um espelho do enunciado: a IA amplifica tanto a clareza quanto a confusão de quem pede. Um prompt que é só "faça X" terceiriza decisões que são suas, e ela escolhe por você — em geral errando na escala ou no risco. Definir o problema (o que entra, o que sai, os invariantes, os casos de borda que você conhece e ela não) virou skill de primeira classe.
Dimensionar conscientemente. Pergunte de que tamanho é o problema antes de aceitar a solução. Separe a complexidade essencial, que vem do domínio, da acidental, que a máquina adicionou. O instinto da IA é abstrair cedo; o seu trabalho é segurar — e, no sentido inverso, recusar a primeira resposta limpa quando o domínio é difícil demais para ela.
Tornar a convenção executável. Disciplina não escala contra throughput. Linter, formatter, tipos, testes e CI são o que faz o padrão sobreviver ao volume. E code review deixa de ser cosmético: é onde a arquitetura é defendida.
Revisar volume, não trecho. A IA deixou de ser autocomplete. Como agente, ela edita dezenas de arquivos e abre o PR inteiro — e ninguém revisa seiscentas linhas com a atenção que dá a seis. Esse é o novo gargalo: o custo migrou de escrever para verificar, e revisar dez vezes mais código com o mesmo cuidado é um problema que ninguém resolveu de verdade. Trate cada diff como o de um estranho talentoso e apressado: provavelmente certo, ocasionalmente perigoso.
Verificar com evidência. Teste o caminho real com o dado real. "Parece pronto" é a armadilha favorita de quem confia na fluência da máquina. E vale o limite honesto: teste só prova o que você pensou em testar — a concorrência, o ordering, o caso que ninguém imaginou ficam de fora. Verificação reduz risco; não o zera.
A base — o que saber
Cada verbo acima pressupõe um substantivo que você precisa ter na cabeça. Sem fundamento, as abordagens viram ritual.
Fundamentos. Como a linguagem, o runtime, o banco e a rede funcionam por baixo da API. É o que deixa você olhar uma solução e sentir o custo: esta query vai varrer a tabela inteira, este laço é quadrático, este await serializa o que devia ser paralelo. A IA escreve o código; você precisa saber ler a física dele. Sem isso, aceita-se qualquer estrutura que compile.
Arquitetura e design. Acoplamento e coesão, fronteiras, modelagem de domínio — o vocabulário com que se decide a forma do sistema. Junto, o repertório de padrões e anti-padrões: conhecer o padrão é o que permite recusá-lo quando ele é canhão.
Segurança. OWASP, autenticação e autorização, validação na fronteira, gestão de segredos. A IA não tem noção de superfície de ataque; você precisa ter, porque o código inseguro dela sai tão convincente quanto o resto. Toda fronteira validada, toda query parametrizada, todo segredo fora do código.
O domínio e o negócio. Os casos de borda que importam quase nunca estão no código; estão na regra de negócio. Conhecer o domínio é o que deixa você enxergar o problema que existe por trás do problema que foi descrito — e é justamente o que a máquina tem menos como acessar.
A régua subiu
Embaixo de tudo há um pré-requisito que não mudou: para dirigir um sistema, é preciso conhecê-lo inteiro, e na era da IA isso vale dobrado. Ninguém revisa o que não entende, dimensiona o que não mapeou, ou protege um fluxo que nunca traçou. A IA amplia quem carrega o modelo do todo na cabeça e expõe sem dó quem só sabia digitar a parte.
Não é a primeira vez que uma tecnologia promete dispensar o programador. 4GL, CASE, low-code: cada onda terceirizou a digitação e, em vez de apagar o ofício, subiu a régua para quem entende sistema. A IA é a versão mais poderosa do mesmo movimento — e a ironia se mantém. Produzir código ficou barato; o julgamento sobre o que produzir ficou caro. A régua subiu de "sabe escrever" para "sabe dimensionar, decidir e garantir".
E essa é só metade da subida. A outra metade não é técnica: é sair do código e entender o negócio que ele serve. Sobre isso, em Falar de negócio deixou de ser diferencial.