publicado originalmente no medium em 27 de janeiro de 2026. revisado em abril de 2026.
eu lembro quando comecei a ouvir falar de programação. existia uma figura quase mítica chamada “o programador” — alguém que dominava a linguagem da empresa e resolvia tudo que envolvia computador. mas o que muita gente não sabe é que, antes disso, a palavra “computador” nem se referia a máquina. era uma profissão.
como chegamos aqui
antigamente, “computer” era o cargo das pessoas que faziam cálculos matemáticos supercomplexos na unha. trabalhavam com tabela, régua de cálculo e muita paciência.
quando os primeiros computadores eletrônicos foram criados, essas pessoas foram as primeiras a “programá-las” — já sabiam a lógica por trás dos cálculos.
inclusive Margaret Hamilton foi quem cunhou o termo “software engineer” pra descrever o próprio trabalho — que foi, nada modesto, o software que pousou a gente na lua.
o ponto aqui não é só histórico. é que a nossa profissão nunca foi estática. ela se adapta ao que a tecnologia permite, e essa adaptação às vezes muda tudo: o que você faz, como faz, e como se apresenta no mercado.
nos anos 90 e início dos 2000, o mercado de tecnologia funcionava diferente. se você olhasse as vagas (tinha até seção de classificado no jornal), via “Desenvolvedor ASP.NET”, “Programador Java”, “Analista PHP”, “Desenvolvedor Delphi”. a linguagem era a identidade do profissional. fazia sentido: framework pesado, biblioteca específica, trocar de stack era quase começar do zero. se você era dev Java, provavelmente passava anos em Java.
e não era só o código. era o ecossistema todo — arquitetura, build, deployment, IDE. migrar de Java pra Ruby era quase mudar de carreira.
lá pelo meio dos anos 2010 as vagas começaram a pedir “desenvolvedor backend” ou “desenvolvedor frontend” em vez de linguagem específica. a especialização ainda existia, mas o eixo mudou.
por quê? javascript explodiu no frontend com Angular, React e uma dúzia de outros (tinha até um chamado Batman.js). o backend se fragmentou entre Go, Node, Rust, Kotlin. e as empresas perceberam que um bom dev backend que sabia Java aprendia Go em semanas — o que importava era entender API, banco, concorrência, não a sintaxe.
o frontend, por outro lado, virou um mundo à parte. não bastava montar uma tela bonita. era state management, build, componentização, teste automatizado, acessibilidade. especialização legítima.
foi nessa fase que “full stack” virou moda. mas, sejamos honestos: a maioria dos full stack era (e ainda é) mais forte num lado do que no outro. o título era mais sobre se virar do que sobre dominar os dois mundos.
enquanto backend e frontend iam ficando fluidos, mobile resistia. fazia sentido: iOS e Android eram (e ainda são) ecossistemas completamente diferentes — Swift vs Kotlin, UIKit vs Jetpack Compose, App Store vs Play Store, guideline de design distinto. um dev iOS sênior que tentasse fazer um app Android do zero ia sofrer. não por incompetência, mas porque anos de conhecimento específico de plataforma não se transferem.
existiam soluções cross-platform como React Native e Flutter, claro. mas com trade-off. app crítico geralmente ainda era nativo. por isso “Dev iOS” e “Dev Android” seguraram o posto de vaga mais específica do mercado por muito tempo.
o que a ia muda
aí chegamos em 2024, 2025.
Dario Amodei, CEO da Anthropic, mencionou recentemente que a grande maioria do código na empresa já é gerada por ia. não é exagero de marketing — eu vejo isso acontecendo.
um dev backend que nunca mexeu com React cria uma interface funcional em horas com ajuda de uma ia. um dev frontend que não sabe nada de Kubernetes configura um deployment básico seguindo sugestão. um engenheiro web prototipa um app mobile em Flutter sem nunca ter estudado Dart.
o código gerado não é perfeito. mas é bom o suficiente pra desbloquear o trabalho. e em muitos contextos — startup, MVP, projeto interno — bom o suficiente é tudo que precisa.
aqui tem um ponto que me incomoda, mas preciso ser honesto: até a revisão profunda do código gerado por ia já tá sendo questionada. o argumento é: se a ia gera código que funciona, passa nos testes, e resolve o problema, vale gastar hora revisando linha por linha? em time pequeno, com pressão de entrega, a resposta prática tem sido “não, não vale”.
isso não é necessariamente bom. código sem revisão acumula débito técnico, tem problema de segurança, fica difícil de manter. mas é a realidade de muito time hoje. e a tendência é a própria ia melhorar nessa revisão, criando um ciclo onde o humano intervém cada vez menos no código linha por linha.
pra onde vamos
não acho que engenheiro de software vai ser substituído. mas o trabalho tá mudando. se a ia consegue escrever código, o que sobra de único pro humano?
primeiro, entender o problema de verdade. a ia gera código pra qualquer coisa que você pedir. mas pedir a coisa certa — entender o que o negócio precisa, o que o usuário quer, quais são as restrições reais — isso ainda é profundamente humano.
segundo, decisão de arquitetura. qual banco usar? como dividir os serviços? onde colocar a complexidade? são decisões com consequência de longo prazo que exigem experiência e julgamento.
a ia sugere, mas alguém precisa escolher e se responsabilizar.
terceiro, revisar criticamente. mesmo que a revisão linha por linha diminua, alguém precisa entender se a solução faz sentido no contexto maior. se vai dar problema de performance em escala. se a abordagem é sustentável.
quarto, comunicar e alinhar. traduzir requisito vago em especificação clara. negociar escopo. explicar trade-off pra stakeholder não-técnico. isso não vai pra ia tão cedo.
se eu fosse descrever o perfil que tá emergindo, seria algo assim: uma pessoa que entende profundamente de sistemas (não de uma linguagem), que sabe usar ia como alavanca, que se vira em qualquer parte da stack quando precisa, mas ainda tem uma área onde vai mais fundo.
é quase um retorno ao generalista. mas diferente. não é o generalista que sabe um pouco de tudo superficialmente — é alguém com profundidade numa área e ferramenta moderna pra ter alcance nas outras.
pra startup, isso é ouro. em vez de contratar um frontend, um backend e um mobile, você contrata uma pessoa sênior que confia na própria capacidade de se desbloquear. essa pessoa usa ia pra escrever o CSS que não domina, pede ajuda pra configurar CI/CD, prototipa o app mobile sem experiência nativa.
e se você tá entrando na área agora, o conselho é simples: não se apegue demais a uma linguagem ou framework. aprenda os fundamentos — estrutura de dados, algoritmo, arquitetura, rede, banco. isso transcende qualquer ferramenta. e aprenda a usar ia bem. não como muleta, como amplificador. entenda o que ela gera, questione, itere.
a habilidade de fazer boa pergunta pra uma ia (e avaliar criticamente a resposta) vai ser tão importante quanto saber programar foi nos últimos 20 anos.
olhando pra trás, a profissão de “pessoa que trabalha com computação” nunca ficou parada. computador humano virou programador de linguagem. programador de linguagem virou dev de stack. dev de stack tá virando… o quê, exatamente? “engenheiro de sistemas assistido por ia”? “arquiteto de solução”? quem sabe engenheiro de produto?
talvez algo que ainda nem tem nome. o rótulo importa menos do que a realidade: o trabalho tá mudando, e quem se adapta continua relevante.
uma coisa que aprendi acompanhando essa história toda: resistir à mudança nunca funcionou muito bem na área. quem ignorou a web, quem achou que mobile era moda passageira — todos tiveram que se adaptar, só que com mais dificuldade. a ia é a próxima onda, e já tá aqui. a pergunta não é se você vai usá-la, é como vai usá-la pra fazer o trabalho que ainda só você consegue fazer.