O desenvolvedor como a gente conhece está acabando
Escrever código virou commodity. O que sobra pra quem construiu carreira fazendo isso?
Eu vi o jQuery virar React. Vi deploy manual virar CI/CD. Vi servidor físico virar cloud virar serverless virar “não se preocupa com infra”. Vi ORM, vi container, vi micro serviço, vi gente voltando pra monolito. Quinze anos nessa área e eu já perdi a conta de quantas vezes alguém disse que uma nova abstração ia “mudar tudo.”
Na maioria das vezes, não mudava. Mudava o como, mas não mudava o quê. Você continuava pegando uma demanda, entendendo o problema, escrevendo código, entregando, e voltando pro começo. O ciclo era o mesmo. As ferramentas novas, algumas boas e outras francamente inúteis, eram camadas novas em cima do mesmo trabalho.
Dessa vez é diferente. E eu não digo isso com entusiasmo. Digo com aquele desconforto de quem entende o que tá vendo.
O loop quebrou
Com a IA, não é mais uma abstração nova em cima do mesmo trabalho. É o trabalho em si que tá mudando. O ciclo clássico de pegar demanda, entender, desenvolver, entregar e repetir tá sendo comprimido de uma forma que não tem volta.
Eu olho pra trás e vejo quinze anos construindo uma expertise que era, no fundo, sobre traduzir problemas humanos em código. Essa tradução tá ficando cada vez mais barata. Cada vez mais rápida. Cada vez mais acessível pra quem nunca escreveu uma linha de código na vida.
Escrever código virou commodity. E quando uma coisa vira commodity, o valor migra pra outro lugar.
O que sobra quando código vira commodity
Sobra critério.
Sobra a decisão de o que construir, e não só de como construir. Sobra a habilidade de olhar pra um briefing vago e enxergar o problema real escondido lá dentro. Sobra saber quando uma entrega que “funciona” ainda está longe de estar boa. Sobra ter gosto pra reconhecer arquitetura ruim antes que ela cobre juros. Sobra saber onde a pressa pode rolar e onde ela vai destruir o produto em seis meses.
Nada disso é novo. Sempre foi o que separava o desenvolvedor sênior do júnior. A diferença é que, antes, dava pra ter uma carreira inteira sendo excelente tecnicamente sem precisar mostrar muito desse critério, porque o critério estava embutido no código entregue, e o código entregue era o ativo. Hoje o código entregue é barato. Quem não consegue tornar o critério visível vira invisível.
Por que comecei a escrever
A pergunta que ficou na minha cabeça durante meses foi essa: como é que eu mostro critério?
Currículo não mostra. Tempo de carreira não mostra. Lista de tecnologias não mostra. Repositório no GitHub mostra um pouco, mas só pra quem entende e tem paciência de ler. Critério aparece nas escolhas, nos trade-offs, no jeito de falar sobre os problemas. Aparece quando alguém te ouve por dez minutos e pensa “esse cara já passou por isso umas mil vezes”. E pra alguém pensar isso, você precisa estar falando.
Esse blog é onde eu vou falar.
Não vai ser tutorial. Tutorial todo mundo já tem em excesso, e a IA escreve melhor do que eu. Vai ser sobre como eu penso quando preciso decidir alguma coisa difícil. Sobre os critérios que eu uso pra separar entrega boa de entrega medíocre. Sobre as decisões que eu tomo antes de uma linha de código ser escrita. Sobre o que eu desligo o agente pra fazer e por quê. Sobre o que eu acho que é trabalho de gente e o que eu acho que virou trabalho de máquina.
Vai ter convicção. Vai ter coisa que eu vou escrever hoje e olhar daqui a um ano com vergonha. Tudo bem. Pensar em público é assim mesmo.
O contexto pessoal
Vou ser direto sobre o pano de fundo. Eu sou co-fundador da Germina, um startup studio. A decisão de empreender pra mim não foi por ambição clássica de carreira. Foi mais um instinto: se o valor está migrando de quem executa pra quem define, faz sentido estar do lado de quem define. Ter algo seu. Ser dono do problema, não só do código que resolve ele.
Esse blog não é a Germina, não é pitch, não é funil. Mas também não é descolado dela. As ideias que aparecem aqui são as mesmas ideias que guiam como eu construo lá. Faz sentido isso ficar claro desde o começo.
O que esperar
Texto sobre como pensar em decisões difíceis na construção de software. Sobre o que mudou no meu jeito de trabalhar com agentes de IA. Sobre os critérios que eu uso pra separar entrega boa de entrega medíocre. Pouco sobre tendências de mercado, porque o que me interessa mostrar aqui é o ofício, não o setor.
Não tenho a pretensão de fazer engenharia reversa do futuro do desenvolvedor de software. Tenho a pretensão de fazer um trabalho honesto, mostrar o critério por trás dele, e deixar registro. Se daqui a três anos eu olhar pra trás e os posts envelhecerem mal, ótimo: significa que a indústria mudou de novo, e eu mudei com ela.