A era do código descartável
Comecei a aprender programação há cerca de um ano e meio.
Quem entra nesse mundo normalmente começa do mesmo jeito: graduação, cursos, aulas, tutoriais, aquela sequência clássica de “aprenda linguagem X em 30 dias”. Parecia um caminho lógico.
Mas muito rápido apareceu um problema.
Os cursos pareciam… lentos. E completamente desalinhados com a realidade.
Explicações longas sobre detalhes de sintaxe, semanas discutindo coisas que uma IA, até mesmo naquele momento, já resolvia.
Parecia que eu estava estudando para algo que já não existia mais.
Demorei um pouco para entender exatamente o que estava errado. Não era falta de conteúdo. Era outra coisa. Uma sensação de que a pergunta principal estava sendo ignorada.
O que exatamente significa programar hoje?
Enquanto isso, algo curioso estava acontecendo no mundo real.
Ferramentas como Claude Code começaram a escrever código útil em segundos. Funções inteiras, APIs, testes, correções...
Não era mais aquela IA que sugeria uma linha de autocomplete.
Era código funcional, quase sem erros, produzido em uma velocidade absurda.
Programadores mais experientes sabem o que isso significa.
Escrever código sempre foi a parte mais cara em termos de tempo humano. Horas pensando, escrevendo, testando, refatorando.
Agora imagine algo que faz isso 10 vezes mais rápido.
Isso faz a gente pensar um pouco...
Se código pode ser produzido quase instantaneamente, por que estamos tratando código como a coisa mais importante do processo?
Essa pergunta começou a me perseguir enquanto eu estudava.
De um lado havia a turma mais “raiz”, olhando para IA como se fosse apenas mais uma moda. Do outro lado apareceu a turma do vibe coding, achando que bastava escrever um prompt mágico e a IA faria tudo sozinha.
Nenhum dos dois lados parecia certo.
Então comecei a fazer um exercício mental simples: e se a IA realmente escrever a maior parte do código?
Não como experimento. Como padrão.
O que sobra para o programador?
A resposta demorou um pouco para aparecer.
Porque a programação sempre foi ensinada da mesma forma: aprender linguagem, aprender frameworks, aprender padrões, escrever código...
Só que existe uma parte do processo que quase nunca aparece nos cursos e graduações de forma séria...
Antes de qualquer código existir, alguém precisa responder perguntas muito mais fundamentais:
- o que o sistema precisa fazer
- quais são as regras do negócio
- quais comportamentos são permitidos
- quais comportamentos são proibidos
- quais cenários precisam funcionar sempre
Essa parte é chamada de várias coisas: especificação, arquitetura, PRD, modelagem de domínio.
Mas ela sempre foi tratada como pré-processamento do código.
Aqui, vale lembrar uma curiosidade histórica.
No início da computação, muito código era literalmente descartável.
Pesquisadores escreviam pequenos programas para resolver um problema científico, rodavam uma vez e pronto. O valor estava na resposta obtida, não no código.
Depois veio a engenharia de software e transformou código em algo duradouro. Sistemas complexos, décadas de manutenção, arquiteturas cuidadosamente projetadas.
Durante mais de cinquenta anos foi ensinado a tratar código como infraestrutura permanente.
Só que existe uma pequena diferença agora.
Máquinas escrevem código.
Quando uma coisa pode ser criada instantaneamente, ela deixa de ser escassa.
E quando algo deixa de ser escasso, seu valor muda.
Esse é o ponto central.
O valor não está mais no código.
Se uma IA consegue construir um sistema inteiro a partir de um conjunto de regras, então o ativo mais importante deixa de ser o código final.
Passa a ser, em outras palavras: a especificação do sistema.
Mas ainda falta uma peça.
Porque se o código pode ser recriado a qualquer momento, precisamos de algo que garanta que o sistema continua correto.
Essa peça também já existe.
Ela sempre existiu.
Testes.
Testes automatizados são, na prática, leis físicas do software.
Se os testes passam, o sistema está potencialmente correto.
Não importa se o código foi escrito por um humano, por uma IA, ou regenerado inteiro cinco minutos atrás.
O comportamento esperado permanece?
Não foram criadas novas falhas, bugs, brechas de segurança?
Agora junte as duas peças.
Definição clara do sistema e testes que garantem o comportamento.
Com isso, uma IA pode gerar um projeto inteiro.
Se algo estiver errado, o processo é simples: ajustar as regras, regenerar o código.
Não refatorar.
Regenerar.
Em minutos.
E é aqui que chegamos na conclusão que parece estranha no começo, mas cada vez faz mais sentido.
O código em si pode se tornar descartável.
Ele deixa de ser o produto final e passa a ser apenas uma materialização temporária das regras do sistema.
Como um build.
Ou como um binário compilado.
Algo que pode ser gerado novamente a qualquer momento.
Isso muda completamente o papel do programador.
O profissional mais valioso não será quem escreve código mais rápido.
Será quem entende profundamente:
- o domínio do problema
- as regras do sistema
- os cenários críticos
- os comportamentos inválidos
E consegue transformar tudo isso em definições claras e testes precisos.
Nesse cenário, a IA escreve o código.
Os testes dizem se o universo está funcionando.
Se algo falha, o código pode simplesmente desaparecer.
E outro nasce no lugar.
A era do código descartável.