A Era da Inteligência
Ainda vale aprender programação e ler código na era dos agentes?
No primeiro capítulo de A Era da Inteligência, eu separei revolução tecnológica de excesso financeiro. No capítulo sobre custo de IA, a conclusão foi parecida: a pergunta certa quase nunca é “IA ou humano?”, mas qual arquitetura produz um resultado válido com custo e risco aceitáveis.
Agora chegamos à pergunta que mais mexe com quem programa:
ainda vale aprender programação se agentes já escrevem código, executam testes, abrem pull requests e começam até a revisar o trabalho uns dos outros?
Minha resposta curta é:
sim — mas o que significa “saber programar” está mudando.
Memorizar sintaxe perde valor.
Digitar boilerplate perde valor.
Conhecer de cabeça a assinatura de cada método perde valor.
Mas entender comportamento, dependências, estado, contratos, riscos, testes, arquitetura e produção ganha valor.
Quanto mais código as máquinas conseguem produzir, mais importante fica saber ler o que foi produzido, entender o sistema em que aquilo entra e perceber quando algo aparentemente correto está errado.
Isso parece um paradoxo.
Não é.
É a mesma mudança que aconteceu em várias profissões quando a ferramenta automatizou a parte mecânica do trabalho: a competência migrou da execução repetitiva para julgamento, diagnóstico e decisão.
O agente já não é apenas autocomplete
Seria fácil responder essa pergunta pensando no Copilot de alguns anos atrás, quando IA para programação significava completar uma linha ou sugerir uma função.
Esse cenário ficou para trás.
Hoje os agentes conseguem:
- navegar em repositórios;
- alterar vários arquivos;
- executar comandos;
- rodar testes;
- abrir pull requests;
- responder a comentários;
- buscar contexto;
- usar ferramentas externas;
- realizar code review;
- iterar sobre feedback.
A documentação atual do GitHub descreve agentes de terceiros que recebem uma issue, trabalham de forma assíncrona e criam um pull request para revisão. Quando terminam, pedem revisão ao desenvolvedor.
O próprio fluxo oficial do GitHub continua terminando com algo muito tradicional:
agente implementa
↓
abre PR
↓
você revisa
↓
pede alterações ou corrige
↓
aprova
↓
merge
Não é por acaso.
A automação está avançando rapidamente na parte de produzir uma mudança.
A responsabilidade de decidir se aquela mudança pertence ao sistema ainda não desapareceu.
O GitHub é explícito na documentação de Copilot Code Review: a revisão automática não é garantida para encontrar todos os problemas e o feedback deve ser validado cuidadosamente e complementado por revisão humana.
Ou seja, já estamos chegando a um ponto curioso:
a IA escreve código e outra IA revisa código — e mesmo assim o fornecedor recomenda que alguém que entenda o sistema valide o resultado.
Isso diz muito sobre a habilidade que está ficando escassa.
Programar nunca foi apenas escrever código
Existe uma confusão histórica entre três coisas:
sintaxe
programação
engenharia de software
Elas se sobrepõem, mas não são iguais.
Sintaxe
É saber escrever:
foreach ($orders as $order) {
// ...
}
ou:
const result = await fetch(url);
Essa camada é extremamente automatizável.
Uma IA é ótima em lembrar APIs, gerar estruturas repetitivas, converter formatos e produzir código plausível rapidamente.
Programação
É transformar uma intenção em uma sequência de comportamento verificável.
Aqui entram perguntas como:
- qual é a entrada?
- qual é a saída?
- quais estados são válidos?
- o que acontece no erro?
- essa operação pode repetir?
- qual condição encerra o processo?
- quem pode executar isso?
- como sabemos que funcionou?
A linguagem usada para escrever a resposta é apenas uma parte.
Engenharia de software
É fazer aquela lógica sobreviver no mundo real.
Aí aparecem:
- arquitetura;
- segurança;
- concorrência;
- banco de dados;
- observabilidade;
- deploy;
- rollback;
- manutenção;
- compatibilidade;
- custo;
- ownership;
- evolução do produto.
Um agente pode escrever uma função correta e ainda assim produzir uma mudança ruim para o sistema.
É exatamente por isso que ler código não é uma atividade menor que escrever código.
Em muitos contextos, sempre foi o contrário.
A era dos agentes aumenta o volume de código antes de aumentar a compreensão
Imagine uma equipe em que cada desenvolvedor consiga colocar três agentes para trabalhar em paralelo.
Um agente refatora um módulo.
Outro implementa uma feature.
Outro corrige testes.
Em poucas horas podem aparecer milhares de linhas modificadas.
A capacidade de produção cresceu.
Mas a capacidade humana de entender não cresce na mesma proporção.
Esse é um dos gargalos que vejo ficando mais importantes:
capacidade de gerar código ↑↑↑
capacidade de revisar código ↑
capacidade de compreender ↑
tempo humano =
Quando geração era cara, escrever código era parte grande do gargalo.
Quando geração fica barata, o gargalo migra para:
- especificar;
- validar;
- integrar;
- diagnosticar;
- decidir.
A pergunta então deixa de ser:
“Eu ainda preciso saber escrever isso?”
e passa a ser:
“Eu consigo perceber se isso deveria existir dessa forma?”
Essa segunda pergunta exige mais engenharia, não menos.
Os próprios desenvolvedores já estão sentindo o custo do “quase certo”
A pesquisa de desenvolvedores do Stack Overflow de 2025 capturou um sinal importante.
Entre os respondentes, 46% disseram desconfiar da precisão das ferramentas de IA, contra 33% que disseram confiar.
A maior frustração relatada, por 66%, foi receber soluções de IA “quase certas, mas não totalmente”.
E 45% apontaram outro problema diretamente ligado a isso: depurar código gerado por IA pode consumir mais tempo.
Esses números não provam que IA piora desenvolvimento.
Também não significam que agentes não evoluíram desde 2025.
Eles mostram outra coisa:
plausibilidade não é equivalência a correção.
Essa é uma distinção que um iniciante sem capacidade de leitura encontra dificuldade para fazer.
Código gerado por uma IA costuma ter uma característica perigosa: ele parece profissional antes de você saber se está certo.
Nomes são bons.
Estrutura é limpa.
Comentários parecem convincentes.
A solução compila.
Talvez até passe em alguns testes.
Mas o erro pode estar em uma hipótese errada sobre:
- negócio;
- autorização;
- concorrência;
- estado;
- contrato;
- idempotência;
- consistência;
- fluxo de exceção.
É aí que conhecimento de programação deixa de ser “saber produzir código” e vira saber interrogá-lo.
A pesquisa sobre compreensão está ficando mais relevante
Em fevereiro de 2026, uma revisão sistemática publicada na ACM Transactions on Computing Education analisou o uso de assistentes generativos para compreensão de código.
A motivação do trabalho é praticamente a tese deste capítulo: conforme programadores passam a depender mais de IA para produzir soluções, cresce a necessidade de compreender essas soluções para verificar se são apropriadas e integrá-las corretamente.
Outro trabalho apresentado em 2026 na International Conference on Program Comprehension parte de um princípio semelhante: entender o codebase é fundamento do trabalho de desenvolvimento e manutenção, mesmo com LLMs disponíveis.
Isso muda como eu pensaria ensino de programação agora.
Antes, havia um caminho muito linear:
aprenda sintaxe
↓
faça exercícios
↓
crie projetos
↓
entre em sistemas maiores
Hoje podemos aproveitar agentes desde o início.
Mas eu não removeria a etapa de compreensão.
Eu a colocaria mais cedo.
O perigo não é usar IA para aprender. É terceirizar a formação do modelo mental
Existe uma diferença enorme entre:
“Usei IA para me explicar esse código.”
e:
“O código funciona, então não preciso entender.”
A primeira postura pode acelerar aprendizado.
A segunda cria dívida.
Eu chamaria isso de dívida de compreensão.
Ela aparece quando um sistema cresce mais rápido que o entendimento de quem é responsável por ele.
No começo não dói.
A feature funciona.
Os testes passam.
O deploy sobe.
Depois aparece uma mudança que exige saber:
- por que essa abstração existe;
- onde esse estado nasce;
- por que existe esse lock;
- o que depende desse evento;
- por que o retry não pode ocorrer duas vezes;
- onde a autorização deveria ser aplicada.
Se ninguém sabe responder, o código deixou de ser um ativo completamente compreendido e virou um artefato que a equipe apenas espera que continue funcionando.
Agentes podem ajudar a reduzir essa dívida.
Mas também podem criá-la em velocidade industrial.
Um estudo de 2026 encontrou justamente uma lacuna entre desempenho e compreensão
Uma pesquisa sobre programação em codebases existentes encontrou um resultado interessante: participantes usando Copilot concluíram tarefas mais rapidamente e passaram mais testes, mas isso não se traduziu automaticamente em maior compreensão do código legado.
É uma amostra pequena e não deveria ser transformada em regra universal.
Mas o padrão é plausível.
Você consegue produzir progresso observável sem construir na mesma velocidade o modelo mental do sistema.
Isso é ótimo quando a tarefa é descartável ou de baixo risco.
É perigoso quando você precisa manter aquilo por anos.
Uma aplicação SaaS não é um exercício de benchmark.
Ela acumula:
- clientes;
- dados;
- regras;
- integrações;
- exceções;
- histórico;
- compromissos de compatibilidade.
Nesse ambiente, “o agente conseguiu implementar” é apenas metade da história.
A outra metade é:
a equipe sabe o que acabou de aceitar?
A evidência sobre produtividade também ficou mais complicada
Em 2025, a METR publicou um experimento randomizado com desenvolvedores open source experientes trabalhando em repositórios que conheciam há anos.
Naquele contexto, usando ferramentas de IA do início de 2025, os desenvolvedores levaram em média 19% mais tempo quando podiam usar IA.
O resultado ficou famoso porque contrariava a percepção dos próprios participantes.
Mas seria errado usar esse número em 2026 como se nada tivesse mudado.
A própria METR atualizou a discussão em fevereiro deste ano.
No estudo posterior, os pesquisadores encontraram sinais de que ferramentas mais novas provavelmente aceleravam mais os desenvolvedores, mas concluíram que efeitos de seleção e mudanças no modo de trabalhar — inclusive uso paralelo de agentes — tornavam os dados insuficientes para uma estimativa confiável.
Essa atualização é mais interessante que uma manchete do tipo “IA deixa dev mais lento” ou “IA deixa dev 10x mais rápido”.
Ela mostra que a ferramenta está mudando tão rapidamente que o workflow humano também muda.
E, quando o workflow muda, a competência necessária muda junto.
Existe uma inversão acontecendo: escrever menos, verificar mais
A OpenAI publicou em fevereiro de 2026 um experimento interno de engenharia em que um produto foi desenvolvido sem linhas de código escritas manualmente pela equipe humana.
Segundo o relato, o sistema foi construído em uma fração do tempo que teria sido necessário manualmente.
A frase que resume o modelo é simples:
humanos conduzem; agentes executam.
Esse tipo de relato é do próprio fornecedor da tecnologia, então deve ser lido como estudo de caso, não como média do mercado.
Mas ele aponta para uma direção real.
Se você consegue delegar a produção de código, seu trabalho passa a se concentrar mais em:
- decompor problemas;
- fornecer contexto;
- definir invariantes;
- criar critérios de aceite;
- revisar arquitetura;
- validar resultados;
- melhorar o ambiente para o agente.
Esse é um tipo de programação em que você pode tocar menos no teclado e usar mais conhecimento de engenharia.
Então ainda preciso decorar sintaxe?
Cada vez menos.
Eu não treinaria hoje um desenvolvedor para competir com um modelo em memória de API.
Não faz sentido avaliar alguém pela capacidade de lembrar se determinado método recebe três ou quatro argumentos quando documentação e agentes estão a segundos de distância.
Mas existem fundamentos que eu continuaria exigindo.
Tipos e estruturas
Você precisa entender o que está sendo representado.
Uma lista não é um mapa.
Um valor ausente não é igual a zero.
Uma string não é um identificador seguro só porque contém números.
Fluxo de controle
Você precisa conseguir seguir:
- condições;
- loops;
- retornos;
- exceções;
- async;
- callbacks;
- filas.
Estado
Onde o dado está agora?
Quem pode alterá-lo?
O que acontece se duas coisas alterarem ao mesmo tempo?
Funções e contratos
O que essa unidade promete?
Quais pré-condições assume?
Qual saída garante?
Banco de dados
Transação, índice, consistência e modelagem continuam existindo mesmo quando uma IA escreveu a query.
HTTP e sistemas distribuídos
Timeout, retry, cache, idempotência, autenticação e rede não desaparecem porque um agente criou a integração.
Testes
Não basta saber pedir “crie testes”.
Você precisa saber o que deveria ser testado.
Essas ideias duram mais que qualquer framework e mais que qualquer modelo.
O que eu ensinaria diferente para quem começa hoje
Eu não proibiria IA para o iniciante.
Também não deixaria a IA fazer tudo.
Usaria um ciclo deliberado.
1. Resolva uma parte sem agente
Não para provar que você é “raiz”.
Para construir referência interna.
Você precisa sentir:
- condição;
- variável;
- função;
- erro;
- loop;
- transformação de dados.
2. Peça ao agente uma solução
Agora compare.
O que ele fez diferente?
Que abstração escolheu?
Você entende por quê?
3. Leia o diff linha a linha
Não aceite o arquivo inteiro como bloco mágico.
Pergunte:
- o que mudou?
- qual comportamento mudou?
- o que foi removido?
- qual dependência apareceu?
4. Explique o código sem a IA
Se você não consegue explicar o fluxo principal, ainda não terminou.
5. Quebre propositalmente
Troque uma condição.
Remova uma validação.
Simule erro de rede.
Insira dado inválido.
Veja o que acontece.
6. Escreva ou revise testes
Um teste força você a declarar qual comportamento considera correto.
7. Só então delegue mais
Autonomia deveria crescer junto com sua capacidade de verificar.
Esse é o caminho oposto de “vibe coding até funcionar”.
É usar IA como multiplicador de compreensão.
Um checklist simples antes de aceitar código de um agente
Eu usaria sete perguntas.
1. Consigo explicar o comportamento principal?
Se não consegue, pare.
2. Sei quais dados entram e saem?
Incluindo formatos, nulabilidade e validação.
3. Sei quais estados o código altera?
Banco, cache, arquivos, sessão, serviços externos.
4. Sei o que acontece quando algo falha?
Timeout, exceção, resposta inválida, concorrência, repetição.
5. Sei quais permissões estão envolvidas?
Quem pode chamar?
Quem pode ler?
Quem pode alterar?
6. Os testes cobrem o risco ou apenas o caminho feliz?
Teste que passa não é sinônimo de cobertura útil.
7. Eu saberia desfazer essa mudança?
Rollback é parte da compreensão.
Se a resposta para várias dessas perguntas for “não”, o problema não é que você usou IA.
É que a responsabilidade foi delegada sem a compreensão correspondente.
Ler código é diferente de apenas reconhecer código
Essa distinção importa muito.
Reconhecimento é olhar uma função e pensar:
“Parece certo.”
Leitura é conseguir rastrear:
requisição
↓
validação
↓
regra
↓
persistência
↓
evento
↓
efeito externo
e responder o que acontece quando cada etapa falha.
Agentes tornam reconhecimento fácil porque o código gerado tende a parecer familiar.
Engenharia exige leitura causal.
Você precisa entender o que causa o quê.
Quanto mais agentes houver, mais importante fica saber revisar
Há uma tentação de imaginar que o problema da revisão será resolvido simplesmente colocando outro agente para revisar.
Isso ajuda.
Eu uso esse padrão como defesa em profundidade:
agente implementa
↓
teste automático
↓
análise estática
↓
agente revisa
↓
humano revisa risco e intenção
Cada camada remove classes diferentes de erro.
Mas não existe garantia de independência entre os agentes.
Dois modelos podem compartilhar:
- vieses;
- dados;
- padrões;
- hipóteses erradas;
- cegueiras semelhantes.
Um segundo modelo não transforma automaticamente uma premissa falsa em verdade.
Por isso a revisão humana mais valiosa não é procurar ponto e vírgula.
É perguntar:
“Estamos resolvendo o problema correto, com o contrato correto, no lugar correto do sistema?”
Essa é uma pergunta de engenharia.
A habilidade premium será navegar entre níveis de abstração
O desenvolvedor mais valioso na era dos agentes não precisa ser quem digita mais rápido.
Ele precisa conseguir subir e descer de nível.
Nível de produto
Qual problema estamos resolvendo?
Nível de sistema
Que serviços, módulos e dados participam?
Nível de contrato
Quais entradas, saídas e invariantes?
Nível de código
Como isso foi implementado?
Nível de operação
Como sabemos que funciona em produção?
Nível de incidente
Como descobrimos o que quebrou?
Um agente pode operar em vários desses níveis.
Mas alguém precisa manter coerência entre eles.
É isso que eu chamaria hoje de saber programar de verdade.
E se eu nunca quiser trabalhar como programador?
A resposta muda.
Se seu objetivo é criar um protótipo, uma automação pessoal ou um site temporário, talvez você não precise aprofundar engenharia da mesma forma.
Ferramentas agentic estão diminuindo drasticamente a barreira para criar software.
Isso é ótimo.
Nem todo mundo que usa uma planilha precisa estudar ciência da computação.
Nem todo mundo que cria um aplicativo interno precisa dominar sistemas distribuídos.
O erro é concluir daí que ninguém mais precisa aprender.
Quanto maior:
- o número de usuários;
- o valor dos dados;
- o risco financeiro;
- a exposição pública;
- a vida útil do produto;
- a complexidade da integração;
mais caro fica não entender.
O que muda para junior, pleno e senior
Para quem está começando
A meta não deveria ser escrever tudo sozinho.
Deveria ser construir fundamentos suficientes para não ficar refém da resposta do agente.
Aprenda:
- lógica;
- estruturas;
- Git;
- HTTP;
- banco;
- debug;
- teste.
Use IA junto.
Mas mantenha a obrigação de explicar.
Para quem já é pleno
A vantagem migra para trabalhar melhor com sistemas maiores.
Você precisa fortalecer:
- design;
- observabilidade;
- segurança;
- integrações;
- async;
- performance;
- code review.
Aqui agentes começam a multiplicar bastante.
Para quem é senior
Seu diferencial fica menos visível no número de linhas produzidas.
Ele aparece em:
- decisões;
- decomposição;
- restrições;
- risco;
- arquitetura;
- qualidade do ambiente;
- capacidade de fazer agentes trabalharem com segurança.
O senior que apenas digita código mais rápido perde vantagem.
O senior que consegue transformar contexto ambíguo em um sistema verificável ganha.
A programação não está desaparecendo. Está subindo de nível
Quando compiladores surgiram, programadores deixaram de escrever grande parte do trabalho diretamente em código de máquina.
Quando frameworks amadureceram, deixamos de implementar manualmente milhares de detalhes de infraestrutura web.
Quando cloud cresceu, paramos de instalar fisicamente boa parte da infraestrutura.
Nenhuma dessas mudanças eliminou engenharia.
Elas deslocaram o ponto em que usamos nossa atenção.
Agentes estão fazendo algo parecido com a produção de software.
A diferença é que o deslocamento agora acontece muito mais rápido.
O que está ficando obsoleto não é compreender código.
É tratar digitação de código como a principal prova de competência.
Minha regra para aprender programação em 2026
Eu resumiria assim:
aprenda o suficiente para compreender, validar e modificar o que você delega — e continue aumentando sua capacidade de delegação conforme aumenta sua capacidade de verificação.
Isso evita dois extremos ruins.
O primeiro é rejeitar IA e insistir que todo mundo deveria trabalhar como em 2019.
O segundo é acreditar que, porque um agente entregou uma feature, conhecimento técnico virou opcional.
Nenhum dos dois descreve o trabalho que está surgindo.
O futuro mais provável é híbrido:
menos código digitado manualmente
+
mais código produzido por agentes
+
mais necessidade de especificação
+
mais revisão
+
mais testes
+
mais observabilidade
+
mais julgamento
É por isso que eu continuaria aprendendo programação hoje.
Talvez com menos obsessão por sintaxe.
E com muito mais obsessão por entender sistemas.
Para quem quer construir exatamente essa base — fundamentos, Git de time, arquitetura, APIs, segurança, testes, observabilidade e entrega até produção — a EngStack é o próximo passo que mais combina com este capítulo.
A pergunta que fica para o próximo capítulo é ainda mais incômoda:
se escrever código deixar de ser o centro do trabalho, o que exatamente passa a definir um programador?
