Reflexão sobre a Indústria

O Apagão de Senioridade

Nunca foi tão fácil produzir código. Mas estamos produzindo código mais rápido do que produzimos compreensão.

Existe uma contradição meio estranha acontecendo na indústria de software.

Nunca foi tão fácil produzir código.

Nunca.

Você descreve uma funcionalidade. A IA escreve. Você pede para corrigir. Ela corrige. Pede testes. Ela cria. Pede para alterar vinte arquivos. Ela altera.

Em algumas horas, você consegue produzir uma quantidade de código que levaria dias ou semanas para escrever manualmente.

Parece ótimo.

E é.

Só que tem um detalhe no meio disso tudo que está sendo convenientemente ignorado.

A Grande Encruzilhada da Engenharia

"Produzir código e entender software são coisas completamente diferentes."

E talvez a indústria esteja ficando muito boa na primeira enquanto começa a ficar perigosamente ruim na segunda.

A ilusão do Vibe Coder

O problema não é usar IA.

Eu uso IA.

O problema começa quando a ferramenta deixa de ser uma extensão da capacidade do desenvolvedor e passa a ocupar o lugar onde deveria existir conhecimento.

O desenvolvedor não sabe por que a aplicação está lenta.

Então pede:

"Otimize isso."

Não entende concorrência.

"Resolva essa race condition."

Não entende arquitetura.

"Refatore esse sistema."

Não entende segurança.

"Adicione as melhores práticas de segurança."

E pronto.

Funciona.

Até parar de funcionar.

Porque software real tem uma característica inconveniente: ele não precisa quebrar quando você está olhando.

Às vezes ele quebra depois de algumas horas.

Às vezes só acontece sob carga.

Às vezes acontece em uma arquitetura específica.

Às vezes depende da ordem em que duas threads executam alguma coisa.

Às vezes o problema não está naquele arquivo que você acabou de modificar, mas em uma decisão tomada três camadas abaixo.

Quando a Fantasia Acaba

Aí aparece o deadlock. A race condition. O vazamento de memória. A degradação de performance. A inconsistência de estado. A falha de segurança.

E aí não existe prompt mágico. É nesse momento que aparece a diferença entre quem produziu o código e quem entende o sistema.

O primeiro olha para a tela e pergunta para a IA o que fazer.

O segundo começa a investigar.

E essa diferença não aparece no GitHub.

Não aparece na quantidade de linhas produzidas.

Não aparece em quantos agentes você sabe configurar.

Ela aparece quando alguma coisa quebra e ninguém sabe por quê.

O problema que ninguém está contando

Tem uma coisa ainda mais preocupante.

Boa parte da experiência de um desenvolvedor vem justamente dos problemas que ele precisou resolver sozinho.

Você passa horas tentando descobrir por que uma thread não acorda.

Descobre um lock.

Depois descobre que o lock não era o problema.

Lê documentação.

Instrumenta o sistema.

Olha stack trace.

Mede performance.

Faz um teste absurdo para reproduzir um comportamento que acontece uma vez a cada algumas centenas de execuções.

E finalmente encontra.

É frustrante.

Mas você nunca mais esquece.

Você acabou de ganhar um modelo mental novo.

Esse é o tipo de experiência que transforma um desenvolvedor.

Agora imagine uma geração em que a IA pula justamente essa parte.

O código é gerado.

Os testes são gerados.

O refactoring é gerado.

O debugging é sugerido.

A solução aparece.

Produtividade sobe.

Mas e o aprendizado?

A Pergunta sem Resposta

"Talvez estejamos automatizando não apenas o trabalho do desenvolvedor, mas também os problemas que deveriam formar o desenvolvedor."

Se eliminarmos boa parte das experiências que tradicionalmente formavam um desenvolvedor júnior, de onde exatamente esperamos que venham os desenvolvedores seniores daqui a dez anos?

O AI Slop já está aparecendo

E existe outro problema.

A quantidade de código produzido por IA está crescendo muito mais rápido do que a capacidade humana de revisar esse código.

Começa pequeno.

Um comentário genérico aqui.

Uma abstração desnecessária ali.

Uma função de 200 linhas que poderia ter 30.

Uma documentação que parece escrita para impressionar outro modelo.

Nomes exageradamente descritivos.

Código duplicado.

Tratamento de erro que existe só porque "parece importante".

Até que o repositório começa a ficar cheio de coisa que ninguém realmente entende.

É o chamado AI slop.

Código sintético produzido em volume, mas sem a mesma proporção de julgamento humano.

E isso é particularmente irônico.

A indústria passou décadas tentando reduzir technical debt.

Agora podemos criar technical debt em uma velocidade industrial.

Mas enfim.

O problema não é a IA escrever código ruim.

Programadores humanos também escrevem.

O problema é quando ninguém percebe que o código ficou ruim porque todo mundo assumiu que a máquina já tinha feito a parte difícil.

Estamos produzindo código mais rápido do que produzimos compreensão

Essa talvez seja a parte mais importante.

A IA reduz o custo de produzir software.

Mas ela não reduz na mesma proporção o custo de entender software.

Você pode pedir para um agente criar 100 mil linhas.

Mas não consegue pedir para ele criar, na mesma velocidade, dez engenheiros experientes capazes de entender aquelas 100 mil linhas seis meses depois.

E software não termina quando compila.

Depois alguém precisa manter.

Alguém precisa investigar.

Alguém precisa fazer o sistema escalar.

Alguém precisa descobrir por que a latência aumentou.

Alguém precisa entender o incidente de produção.

Alguém precisa decidir se aquela abstração deveria existir.

Alguém precisa olhar para uma solução gerada pela IA e dizer:

"Não. Isso está errado."

Esse alguém precisa existir.

E existe um limite econômico nessa história

Também existe uma crença de que podemos simplesmente aumentar o uso de modelos cada vez maiores para resolver tudo.

Só que inferência custa dinheiro.

GPU custa dinheiro.

Energia custa dinheiro.

Infraestrutura custa dinheiro.

Contexto custa dinheiro.

E empresas fazem contas.

Pode ser que, no futuro, ninguém queira gastar um modelo de fronteira caríssimo para gerar uma função trivial.

Aí começa uma migração para modelos menores, locais, especializados e mais baratos.

E nesse cenário a dependência de uma IA perfeita começa a parecer uma aposta ruim.

Porque o modelo pode ser menor.

Pode errar mais.

Pode ter menos contexto.

Pode não conhecer exatamente aquele framework.

Pode não entender aquele código legado.

E aí volta a aparecer uma figura que nunca deixou de ser necessária:

o desenvolvedor que sabe o que está fazendo.

O verdadeiro diferencial não será "saber usar IA"

Saber escrever prompts é útil.

Saber configurar agentes é útil.

Saber dividir uma tarefa entre diferentes modelos é útil.

Saber automatizar seu fluxo de desenvolvimento é excelente.

Mas isso vai virar commodity.

Quando todo mundo tiver acesso às mesmas ferramentas, possuir a ferramenta deixa de ser diferencial.

O diferencial passa a ser o que você consegue fazer com ela.

E, principalmente, o que você consegue fazer sem depender dela.

O Core da Fundamentação Técnica
Arquitetura
Sistemas Op.
Redes & Memória
Concorrência
Bancos de Dados
Performance
Segurança
Observabilidade

Essas coisas continuam existindo quando o prompt termina.

E tem uma habilidade ainda mais importante:

saber questionar a resposta da IA.

Porque uma IA pode produzir uma explicação absolutamente convincente para um bug que não existe.

Pode sugerir uma solução arquitetural que parece excelente.

Pode passar em todos os testes.

E ainda assim estar errada.

Quando isso acontece, você precisa ter conhecimento suficiente para perceber.

Não existe ferramenta que substitua completamente essa autonomia.

O futuro pode ser estranho

Eu não acho que a resposta seja ignorar IA.

Seria uma estupidez.

A IA é uma das ferramentas mais poderosas que um desenvolvedor pode ter hoje.

O problema é outro.

É entregar para ela justamente a parte que deveria continuar sendo humana:

o raciocínio.

Porque quando todo mundo tiver uma IA capaz de gerar milhares de linhas em segundos, gerar milhares de linhas não será mais uma habilidade especial.

Vai ser barato.

Vai ser comum.

Vai ser esperado.

A pergunta vai mudar.

Não será mais:

"Você consegue escrever esse código?"

Será:

"Você consegue me explicar por que esse sistema está quebrando?"

E talvez seja aí que descubramos o tamanho do problema.

Porque podemos chegar a um futuro onde temos mais código do que nunca.

Mais ferramentas do que nunca.

Mais automação do que nunca.

E, ao mesmo tempo, menos pessoas capazes de entender profundamente tudo isso.

O Verdadeiro Risco do Apagão

Esse é o apagão que me preocupa. Não o desaparecimento dos desenvolvedores...

O desaparecimento gradual dos desenvolvedores que realmente entendem o que estão fazendo.