O Aviso Que Ninguém Quer Ouvir
Tem gente que vai virar Uber de novo — e dessa vez não é culpa do mercado.
Quando falo que devs vão virar Uber, não estou sendo alarmista. Estou descrevendo um padrão que já vi acontecer antes: profissionais que achavam que sua função era executar tarefas se descobriram substituíveis quando a tecnologia automatizou essa camada.
A IA está fazendo isso agora com código.
O Que É um Pedreiro de Software
Um pedreiro de software é aquele que recebe uma tarefa e executa. "Cria um CRUD aqui." Faz. "Adiciona esse campo no form." Faz. "Integra essa API." Faz.
Ele é competente na execução. Conhece a sintaxe, sabe usar o framework, entrega dentro do prazo.
O problema é que essa camada — a execução mecânica de tarefas de código — é exatamente o que a IA faz bem. Muito bem. E cada vez melhor.
O Cursor escreve CRUD. O Claude integra API. O GitHub Copilot adiciona campo no form.
Se o seu valor como dev está concentrado em executar essas tarefas, você tem um problema real.
O Que É um Engenheiro de Software de Verdade
Um engenheiro de software entende o sistema.
Não apenas "como escrever esse código", mas:
- Por que essa arquitetura foi escolhida
- Qual o trade-off entre essa abordagem e aquela
- Como isso se comporta sob carga, com dados reais, no caso extremo
- O que vai quebrar quando o requisito mudar (e vai mudar)
- Qual a dívida técnica que estamos acumulando e quando vai cobrar o preço
Essas perguntas a IA não responde — porque as respostas dependem de contexto de negócio, histórico do sistema, restrições que nunca estão documentadas e julgamento acumulado de quem trabalha no problema há meses.
A Diferença na Prática
Laço nos meus projetos com IA o tempo todo. Laravel, Next.js, integrações de API, pipelines de dados. A IA escreve uma quantidade absurda de código por mim.
Mas o que eu faço que a IA não faz?
Eu defino o problema. A IA resolve o problema que eu descrevo. Se eu descrever errado, ela resolve o problema errado — com perfeição.
Eu reviso com julgamento. Código que funciona não é o mesmo que código que deveria existir. Ás vezes a solução certa é não ter aquele código.
Eu entendo as consequências. Quando a IA sugere uma solução, eu sei se aquilo vai explodir em produção, criar um gargalo de performance daqui a três meses ou violar uma constraint de negócio que não está no prompt.
Essa camada de julgamento — de engenharia de verdade — não é automatizável. Pelo menos não ainda, e não para sistemas reais com complexidade real.
A Ilusão do "Eu Sei Programar"
Tem um trecho de desenvolvedor que acha que está seguro porque "sabe programar". Digita código, o sistema funciona, o cliente aprova.
Mas o teste real não é "consegue fazer funcionar". É:
- Quando um bug aparece em produção às 23h, você consegue diagnosticar em 30 minutos?
- Quando o sistema precisa escalar 10x, você sabe onde está o gargalo antes de ir para produção?
- Quando o requisito muda radicalmente, você consegue avaliar o impacto real?
Se a resposta é "não sei, vou perguntar pra IA", você está em território perigoso.
A IA é uma ferramenta de multiplicação. Ela multiplica o que você já sabe. Se o que você sabe é raso, ela multiplica raso.
O Que Fazer Com Isso
Não estou dizendo para ignorar IA. Pelo contrário — use. Use muito. Mas use com entendimento.
A diferença entre quem vai ficar e quem vai sair não é quem usa IA. É quem consegue:
- Definir problemas com precisão — garbage in, garbage out
- Avaliar soluções criticamente — não aceitar cegamente o que a IA gera
- Entender sistemas, não só código — a diferença entre fazer funcionar e fazer certo
- Acumular julgamento — experiência que contextualiza as respostas da IA
Isso é engenharia de software. Não é sobre qual linguagem você usa ou qual framework conhece.
Prefere Assistir?
Gravei um vídeo curto sobre esse tema no TikTok:
