A IA vai acabar com os programadores — ou mudar o que significa programar?
Agentes já escrevem uma parcela enorme do código. O sinal mais importante, porém, não é o desaparecimento uniforme dos devs: é a migração de valor da digitação para julgamento, arquitetura, validação e operação.
A Era da Inteligência
A IA vai acabar com os programadores — ou mudar o que significa programar?
No capítulo anterior de A Era da Inteligência, eu defendi que ainda vale aprender programação porque ler, revisar, depurar e compreender sistemas continua sendo fundamental mesmo quando agentes escrevem cada vez mais código. No primeiro capítulo desta série, eu separei revolução tecnológica de bolha financeira. Aqui precisamos fazer outra separação.
Uma coisa é perguntar se a IA vai automatizar tarefas que hoje chamamos de programação. Outra é perguntar se ela vai eliminar a ocupação, a demanda por software e a necessidade de pessoas responsáveis por transformar problemas reais em sistemas que funcionam.
A primeira já está acontecendo em velocidade impressionante. A segunda continua em aberto — e os dados atuais não sustentam uma resposta simples.
Minha tese é esta:
a IA não precisa acabar com os programadores para destruir uma parte enorme do trabalho que historicamente associamos à programação. O valor está migrando de produzir código para definir, orientar, verificar, integrar e operar software.
Isso ameaça alguns perfis. Também aumenta brutalmente a alavancagem de outros.
O código está ficando abundante antes de o software ficar automático
A pesquisa global da JetBrains com mais de 15 mil desenvolvedores profissionais, coletada entre maio e julho de 2026, encontrou 90% usando agentes de código pelo menos semanalmente no trabalho e 68% usando diariamente.
Em outra análise da mesma pesquisa, desenvolvedores relataram uma parcela muito alta de código produzido integralmente por agentes. A própria JetBrains ressalva que os percentuais são autorrelatados e estimados a partir de faixas, portanto não devem ser tratados como telemetria precisa de linhas de código. Mesmo assim, a direção é difícil de ignorar: escrever tudo manualmente deixou de ser o padrão para uma parte relevante da profissão.
Isso muda a economia de boilerplate, CRUD, testes iniciais, documentação, migrations, refactors localizados e primeiras versões de APIs.
Mas existe uma diferença enorme entre gerar código e entregar software.
Código é material intermediário. Software precisa resolver o problema correto, preservar dados, respeitar permissões, integrar serviços, sobreviver a concorrência, lidar com falhas, ser observável, custar um valor aceitável e continuar operando depois do deploy.
Quando produzir código fica muito barato, um gargalo novo aparece: validar com segurança uma quantidade muito maior de mudanças.
Um detalhe do BLS mostra a mudança de papel
Os números atuais do Bureau of Labor Statistics dos Estados Unidos separam duas categorias que no cotidiano costumamos misturar.
Para computer programmers, o BLS projeta queda de 7% entre 2025 e 2035.
Para software developers, quality assurance analysts and testers, a projeção agregada é de crescimento de 10% no mesmo período, com cerca de 106 mil aberturas por ano em média ao considerar crescimento e reposição.
Essas projeções não são profecias. Mas a divergência é uma pista.
O papel mais próximo de traduzir especificações em código está sob pressão. O papel mais amplo de projetar, construir, testar, evoluir e manter sistemas continua com demanda projetada.
Talvez a fronteira entre “programador” e “engenheiro de software” esteja ficando economicamente mais importante justamente quando agentes ficam bons em produzir a parte mais explícita do trabalho.
Exposição alta não é sinônimo de desemprego automático
Seria confortável parar no dado de crescimento de software developers. Também seria intelectualmente desonesto.
A Anthropic publicou em março de 2026 uma análise que combina capacidade teórica dos modelos com uso real observado. No indicador chamado observed exposure, computer programmers aparecem no topo, com cerca de 75% de cobertura de tarefas.
Isso é enorme.
Mas “75% de tarefas cobertas” não significa “75% dos programadores perderam o emprego”. Os próprios pesquisadores não encontraram, até aquele momento, aumento sistemático do desemprego nas ocupações mais expostas desde o lançamento do ChatGPT.
Eles encontraram, porém, um sinal que merece atenção: a entrada de trabalhadores de 22 a 25 anos em ocupações altamente expostas parece ter desacelerado. A estimativa é de uma queda aproximada de 14% na taxa de início de novos empregos em relação a 2022, com significância estatística apenas no limite e várias explicações alternativas possíveis.
Portanto, duas frases precisam permanecer verdadeiras ao mesmo tempo:
não existe evidência para anunciar o fim dos programadores.
existem sinais reais de que a estrutura de contratação pode já estar mudando, especialmente na porta de entrada.
A OIT chega a uma conclusão conceitualmente parecida em seus estudos sobre IA generativa: exposição de tarefas não deve ser confundida com automação integral de uma ocupação. Empregos são conjuntos heterogêneos de tarefas, contexto e responsabilidade.
O paradoxo de 2026: mais agentes e mais desenvolvedores
O relatório de difusão de IA da Microsoft registra uma explosão de atividade agentic no GitHub: o número de pull requests associados a agentes teria passado de cerca de 83 mil em maio de 2025 para 2,3 milhões em março de 2026.
No mesmo relatório, a Microsoft aponta que o emprego de software developers nos Estados Unidos chegou a aproximadamente 2,2 milhões em 2025, alta de 8,5% no ano, e que os dados iniciais de março de 2026 ainda mostravam crescimento de cerca de 4% em relação a março de 2025.
Isso não prova que IA cria empregos de desenvolvimento. Correlação não é causalidade.
Mas mostra que uma explosão na automação de código pode coexistir, pelo menos durante uma fase, com crescimento do número de desenvolvedores.
A explicação econômica é simples: produtividade não atua apenas pela substituição. Se construir software fica mais barato, empresas podem construir mais software.
Uma feature que não justificava três semanas passa a caber em dois dias. Um sistema interno que nunca sairia da planilha passa a existir. Uma pequena empresa que não contrataria cinco pessoas consegue operar com uma ou duas pessoas e agentes. Um produto que exigia muito capital chega ao mercado com uma equipe menor.
Por isso esta conta está errada:
agente escreveu 50% do código
logo
50% dos programadores ficaram desnecessários
A unidade de trabalho pode cair enquanto a quantidade economicamente viável de software aumenta.
O que realmente está sendo automatizado?
Uma forma útil de pensar é dividir engenharia de software em seis camadas:
| Camada | O que está em jogo | Pressão de automação |
|---|---|---|
| Produção de artefatos | código, testes, docs, queries, migrations | muito alta |
| Correção local | compilar, testar, lintar, reproduzir bug | alta |
| Coerência do sistema | contratos, arquitetura, compatibilidade, dívida | crescente |
| Operação | observabilidade, custo, rollout, rollback, incidentes | crescente |
| Responsabilidade de produto | escolher problema, risco e comportamento correto | parcial |
| Responsabilidade organizacional | ownership, aprovação, evidência e consequência | não desaparece |
Agentes já são extremamente fortes nas duas primeiras camadas. Também estão avançando nas seguintes.
Mas quanto maior a autonomia, mais importante fica o desenho dos limites: que ferramentas o agente pode usar, que mudança precisa de revisão, quais testes são obrigatórios, qual evidência sustenta a decisão e como recuperar o sistema quando algo falha.
Se um agente vaza dados de clientes, “foi a IA” não é uma estrutura operacional aceitável. A organização continua precisando saber quem responde pelo resultado.
Um repositório sem código humano não significa engenharia sem humanos
A OpenAI descreveu em 2026 um experimento interno radical: um repositório em que cada linha deveria ser gerada pelo Codex.
À primeira vista, parece a prova final de que o programador acabou.
A parte mais interessante é justamente o que precisou ser criado para isso funcionar.
A equipe relata que redesenhou o workflow, construiu um ambiente amigável para agentes, investiu em testes automatizados e guardrails e criou um orquestrador para manter agentes trabalhando continuamente a partir das tarefas.
Ou seja:
zero linha escrita manualmente não significou zero engenharia humana.
A engenharia migrou da produção artesanal de cada linha para desenho do ambiente, decomposição do trabalho, contratos, testes, guardrails, infraestrutura, observabilidade, revisão e orquestração.
Talvez no futuro perguntar “quanto código você escreveu?” soe tão estranho quanto avaliar um arquiteto pelo número de tijolos que ele assentou.
O programador não vira apenas um “prompt engineer”
Existe uma versão superficial dessa transformação: antes você escrevia código; agora escreve prompts.
Não acho que seja isso.
Prompt é interface. Assim como IDE, framework e linguagem são interfaces.
O trabalho valioso continua sendo construir um modelo correto do problema e transformar esse modelo em comportamento verificável.
Em um workflow agentic, isso aparece como issue bem definida, spec, critérios de aceite, testes, constraints, exemplos, documentação de arquitetura, ferramentas, políticas, permissões, ambientes isolados e feedback automático.
O profissional forte não é quem descobriu a frase mágica para pedir código.
É quem cria um sistema de produção em que agentes têm contexto suficiente para avançar e limites suficientes para não causar estrago silenciosamente.
Quem está mais ameaçado?
Vejo quatro zonas de risco.
Trabalho medido por volume de código. Se o valor do profissional é essencialmente “recebe ticket, escreve código previsível, entrega”, a máquina está entrando exatamente nessa parte.
Software factories baseadas em horas repetitivas. Uma equipe menor, bem instrumentada com agentes, pode comprimir headcount e preço em trabalho padronizado.
Profissionais que nunca desenvolveram entendimento além da stack. O agente conhece APIs e padrões sintáticos em escala maior. O diferencial migra para por que, quando, risco, trade-off e consequência.
A antiga porta de entrada do junior. Historicamente, muita gente aprendia fazendo bug simples, CRUD, teste, endpoint e documentação. São justamente tarefas que agentes fazem muito bem.
Esse último ponto é particularmente importante: se a empresa automatiza todo trabalho simples, como alguém acumula contexto suficiente para virar pleno e senior?
Esse não é apenas um problema do junior. É um problema de pipeline de talento.
O junior não precisa competir com o agente em digitação
A resposta também não é proibir IA para quem está começando.
Um junior de 2026 deveria provar que consegue:
- explicar o problema antes de gerar a solução;
- ler um diff produzido por agente;
- identificar comportamento e risco;
- escrever ou revisar testes;
- reproduzir falha;
- observar logs e estado;
- explicar uma decisão de arquitetura;
- operar uma mudança até homologação;
- reconhecer quando não sabe;
- pedir revisão com evidência.
O agente pode escrever o código. O aprendizado acontece na obrigação de entender e defender o resultado.
Para o senior, a lógica é complementar. Quem construiu carreira apenas sendo o melhor digitador perde parte da vantagem. Quem acumulou julgamento — arquitetura, contexto do cliente, histórico de incidentes, limites do negócio e consequências operacionais — ganha alavancagem.
Três cenários podem acontecer ao mesmo tempo
Quando alguém pergunta “a IA vai acabar com os programadores?”, costuma imaginar um único futuro. Eu acho mais provável uma combinação de três.
1. Compressão
Algumas empresas fazem o mesmo com menos gente. Times que produzem software repetitivo podem encolher.
2. Expansão
Outras empresas mantêm ou aumentam capacidade porque agora conseguem construir muito mais. Backlogs antes inviáveis passam a caber e novos produtos surgem porque o custo de entrada cai.
3. Reconfiguração
Menos trabalho dedicado exclusivamente a produzir código e mais trabalho em produto, arquitetura, dados, segurança, avaliação, observabilidade, integração, operação e governança de agentes.
Esses movimentos não se anulam. Podemos ter menos pessoas em determinados times, mais software sendo criado no total e uma profissão com tarefas diferentes.
Uma matriz simples para avaliar sua própria exposição
Faça duas perguntas:
1. Quanto do meu trabalho pode ser descrito sem contexto local?
Se alguém especifica sua tarefa em poucas linhas e qualquer profissional competente poderia executá-la sem conhecer o sistema, ela tende a ser mais automatizável.
2. Quanto do meu valor está em julgar consequências?
Quanto mais seu trabalho conecta produto, arquitetura, dados, risco, operação e negócio, maior a parte que hoje ainda depende de contexto acumulado.
Isso cria quatro posições:
| Execução | Contexto | Leitura |
|---|---|---|
| alta | baixo | maior pressão de automação |
| alta | alto | agentes multiplicam produtividade, supervisão segue importante |
| baixa | alto | código pode ser delegado, profissional continua central |
| baixa | baixo | a própria tarefa pode deixar de justificar especialização |
O objetivo de carreira deveria ser simples:
migrar seu valor de “eu produzo artefatos” para “eu sou responsável por resultados em sistemas”.
O que eu faria se estivesse começando hoje
Eu aprenderia programação, mas não montaria minha identidade em torno de escrever código sem ajuda.
Estudaria fundamentos porque eles permitem verificar o agente: lógica, estruturas de dados, HTTP, banco, concorrência, autenticação, autorização, Git, testes, sistemas operacionais, redes e segurança.
Depois construiria a camada que transforma conhecimento em engenharia: arquitetura, observabilidade, CI/CD, deploy, rollback, filas, idempotência, performance e threat modeling.
E aprenderia agentes como mais uma parte do stack: dar contexto, decompor trabalho, limitar permissões, criar avaliações, revisar diffs, rodar tarefas em paralelo, registrar evidência e recuperar quando falham.
Não porque isso garante emprego. Nenhuma stack garante.
Mas porque coloca você mais perto do lugar onde a responsabilidade está migrando.
Depois de mais de 25 anos programando, eu não apostaria na digitação
Eu comecei a programar numa época em que muito do trabalho cotidiano era mais manual. Desde então vieram IDEs melhores, frameworks, pacotes, cloud, Stack Overflow, CI/CD, serviços gerenciados, copilots e agentes.
Cada camada removeu trabalho que antes parecia parte essencial de “ser programador”. E, mesmo assim, o software ficou maior, mais presente e mais complexo.
Isso não prova que agentes repetirão exatamente a história das abstrações anteriores. Eles são uma automação muito mais ampla e podem atingir tarefas cognitivas que as ferramentas anteriores não atingiam.
Por isso eu não trato o risco como exagero.
Mas também não acho inteligente defender justamente a parte do trabalho que está ficando mais barata.
Minha aposta seria outra:
código vai ficar abundante. Bom julgamento, contexto, responsabilidade e capacidade de fazer sistemas sobreviverem à realidade continuarão escassos por mais tempo.
Então a IA vai acabar com os programadores?
Com parte do trabalho dos programadores, sim.
Com alguns empregos, provavelmente.
Com alguns modelos de empresa, quase certamente.
Com a necessidade de pessoas capazes de construir e responder por software?
Os dados de 2026 ainda não mostram isso.
A pergunta útil deixa de ser “a IA consegue escrever meu código?”. Ela já consegue escrever muito dele.
A pergunta passa a ser:
“Quando escrever código deixar de ser escasso, qual parte do resultado continuará dependendo de mim?”
Se a resposta for apenas “digitar mais rápido”, existe um problema.
Se envolver entender o problema, desenhar o sistema, orientar agentes, validar comportamento, integrar peças, operar produção e assumir responsabilidade, talvez você não esteja vendo o fim da profissão.
Talvez esteja vendo a próxima definição dela.
Para quem quer aprofundar justamente essa base — fundamentos, Git e review, arquitetura, testes, segurança, observabilidade e entrega — a EngStack é um próximo passo coerente. O objetivo não é competir com agentes linha por linha; é aprender a entregar e defender sistemas de ponta a ponta.
Uma resposta