O futuro dos desenvolvedores: menos código, mais arquitetura

A economia mudou de lado

Durante cinquenta anos, escrever código foi a parte cara do software. Tudo na profissão se organizou em volta disso: linguagens para escrever menos, frameworks para não repetir, bibliotecas para não reescrever, estimativa medida em quanto código faltava.

Essa premissa caiu. Produzir código correto e idiomático ficou barato e rápido. E quando o custo de uma etapa desaba, o gargalo se muda para a etapa seguinte.

A etapa seguinte é decidir se aquele código deveria existir e se ele está certo.

O que fica caro quando escrever fica barato

Verificar. Ler mil linhas com atenção custa o mesmo de sempre. Times que aceleraram a produção sem acelerar a revisão estão acumulando dívida invisível — código que passou porque parecia certo.

Integrar. O sistema que funciona sozinho e o sistema que convive com outros sete são coisas diferentes. Contrato entre serviços, versionamento, compatibilidade retroativa, o que fazer quando o outro lado cai: nada disso a IA decide por você, porque depende de acordos entre times.

Operar. Custo de infraestrutura, latência, observabilidade, plano de retorno. Código gerado em massa tende a ser tecnicamente correto e operacionalmente ingênuo — funciona, mas ninguém pensou em quanto custa rodar mil vezes por minuto.

Escolher o que não fazer. A restrição sempre foi a capacidade de entrega. Com essa restrição afrouxada, o que sobra é a disciplina de dizer não — e ela é escassa.

Arquitetura não é diagrama

Quando digo que o trabalho migra para arquitetura, não estou falando de desenhar caixinhas nem de um cargo com o nome "arquiteto". Estou falando de quatro atividades concretas:

Definir fronteiras. O que é um módulo, o que ele expõe, o que ele esconde, quem pode chamar quem. Num mundo de código gerado, fronteira boa é o que impede que a bagunça se espalhe — e é o que dá ao agente um pedaço pequeno o bastante para trabalhar com segurança.

Escolher restrição em vez de possibilidade. Tipagem forte, esquema validado, migração versionada, teste de contrato. Cada restrição que você impõe é uma classe inteira de erro que o código gerado não consegue cometer. Isso mudou de "boa prática" para "infraestrutura de segurança".

Projetar para verificação. Se a saída de um componente só pode ser julgada por um humano lendo, ele não escala. Se ela pode ser checada por teste, tipo, invariante ou monitor, escala. Desenhar sistemas verificáveis virou a habilidade central.

Decidir o custo. Onde vale gastar, onde vale simplificar, o que aguenta ser feito mal de propósito. Julgamento econômico aplicado a software.

O desenvolvedor sênior de 2030 vai ler muito mais do que escrever, e o que ele escrever vai ser principalmente restrição: contrato, teste, tipo, política.

Como fica o dia a dia

Já dá para ver o formato nos times que adotaram IA a sério:

• Menos tempo no editor, mais tempo em revisão. A proporção se inverte, e revisar deixa de ser tarefa de fim de dia para ser a atividade principal.
• Pull requests menores. Porque o gargalo é a leitura, não a escrita. Quem manda mudança gigante gerada por IA está transferindo o próprio custo para o revisor.
• Testes e tipos como especificação. Você descreve a restrição; a implementação é gerada e verificada contra ela.
• Mais documento de decisão. Por que fizemos assim, o que consideramos, o que rejeitamos. É o contexto que nem o modelo nem o colega novo têm de outro jeito.

O que estudar agora

Se a aposta estiver certa, o retorno maior está nestes cinco:

1. Modelagem de domínio. Traduzir negócio em estrutura. É a habilidade mais durável da lista.
2. Sistemas distribuídos. Falha parcial, idempotência, consistência, fila. Agentes trouxeram esses problemas de volta para aplicações comuns.
3. Teste e verificação. Teste baseado em propriedade, teste de contrato, tipos expressivos. Tudo que transforma "parece certo" em "está provado".
4. Operação. Observabilidade, custo, performance. A parte que a IA menos cobre e que mais dói.
5. Escrita. Documento de decisão e especificação. Sua interface com humanos e com máquinas é a mesma agora.

Note o que ficou de fora: nenhum framework, nenhuma linguagem específica. Não porque não importem, mas porque essas cinco continuam valendo quando o framework da vez for aposentado — e o framework da vez sempre é aposentado.