A Anthropic disse recentemente à sua equipe de crescimento para contratar mais gerentes de produto, e não menos. A razão, conforme relatado na cobertura do setor, foi que a Claude Code havia silenciosamente transformado sua organização de engenharia em uma equipe que emprega cerca de três vezes o número real de funcionários, e o gargalo passou do ambiente de desenvolvimento integrado (IDE) para as pessoas que decidiam o que construir.
Esse detalhe é fácil de perder em meio ao ruído de todas as reivindicações de produtividade da IA. É também a mudança estrutural que o resto da indústria está a viver agora. O gargalo do software não é mais a digitação. É decidir o que digitar. E os engenheiros que tratam isso como problema de outra pessoa estão prestes a estagnar.
Durante a maior parte da última década, essa decisão cabia a outra pessoa. A engenharia de software era uma arte que você absorvia lentamente e depois praticava em uma sequência longa e previsível: mergulhe fundo na tecnologia, escreva o código, pergunte ao Stack Overflow quando travar, encaminhe para um engenheiro sênior quando o Stack Overflow falhar, envie o tíquete. O gerente de produto era o dono do funil. O engenheiro era o dono da construção. Ambos os lados trataram esta divisão como física.
Então o funil desabou em cinco etapas.
Uma breve história de como o dia do engenheiro ficou comprimido
A era Stack Overflow (2014 até o final de 2022): A maneira como os engenheiros pensavam que viviam em um só lugar. Mas as novas perguntas mensais no Stack Overflow caíram cerca de 77% desde novembro de 2022, o que não foi coincidentemente quando o ChatGPT foi lançado. A queda não é um referendo no site. É um referendo sobre o fluxo de trabalho que representava.
A era das guias do navegador (final de 2022 a 2024): A primeira geração do ChatGPT ficou fora do IDE. Os engenheiros executaram o mesmo loop de sempre, apenas com um oráculo mais rápido: escreva um prompt em um navegador, cole a resposta de volta no VS Code e repita. O trabalho ainda era de thread único e conduzido por engenheiros. A alavancagem foi real, mas local.
A era nativa do IDE (2024 a 2025): Cursor e Claude Code moveram o modelo dentro do editor e deram acesso ao repositório completo. O caminho de escalada do engenheiro sênior foi em grande parte dissolvido. Durante anos, a sabedoria predominante entre os engenheiros veteranos era que o Bash tinha a vida útil mais longa de todas as ferramentas da pilha. Em 2026, para uma parcela significativa de desenvolvedores ativos, o primeiro comando digitado em um novo terminal será Claude.
A era impulsionada pelas especificações (2025 a 2026): Janelas de contexto maiores transformaram o trabalho de sessão única em algo que antes exigia tickets, documentos de design e sprints. A equipe Kiro IDE da Amazon supostamente comprimiu compilações de recursos de duas semanas para dois dias usando o mesmo fluxo de trabalho baseado em especificações que eles estavam enviando. Uma equipe de engenharia da AWS descreveu uma rearquitetura de 18 meses, originalmente planejada para 30 engenheiros, que foi concluída por 6 pessoas em 76 dias. O gargalo deixou de ser o tempo necessário para escrever o código. Começou a ser a clareza com que a equipe consegue descrever a aparência correta.
A era das rotinas (2026): Em abril, a Anthropic lançou Claude Code Routines: agentes programados e persistentes que são executados em cadência, em um webhook ou durante a noite enquanto o laptop está fechado. Cron voltou. Ganchos voltaram. O trabalho do engenheiro agora é parte da orquestração: criar um enxame antes de dormir e revisar uma pilha de pull requests pela manhã. Wrappers de terceiros, como o OpenClaw, que foi brevemente suspenso pela Anthropic em abril antes da reintegração parcial, defenderam o mesmo ponto do lado do código aberto.
O gargalo mudou; a maioria das equipes não
A engenharia praticamente triplicou. O gerenciamento de produtos não mudou. A proporção tradicional de 1:8 entre PMs e engenheiros, já sobrecarregada, agora se aproxima de uma proporção efetiva de 1:20 porque cada engenheiro envia mais por dia. Por exemplo, o LinkedIn substituiu seu cargo de gerente de produto associado por um "Construtor de Produto" programa que treina generalistas em produto, design e engenharia. A Anthropic está contratando mais PMs, não menos. O padrão é consistente em todas as empresas que realmente implantaram fluxos de trabalho de agente na produção: o sistema produz recursos construídos mais rapidamente do que toma decisões sobre o que deve ser construído.
Para os engenheiros, este é o sinal de carreira mais importante da década e o mais fácil de ignorar enquanto as histórias de produtividade dominam o feed.
Os primeiros princípios importam mais, não menos
O instinto de declarar os fundamentos obsoletos na era dos agentes interpreta a tendência de forma totalmente errada.
Quando um vazamento de memória interrompe a produção às 3 da manhã e a causa acaba sendo um sutil bug de propriedade lançado há 4 anos, nenhum agente atualmente em atividade fecha esse ciclo de ponta a ponta. Sistemas operacionais, redes, simultaneidade e planos de consulta ainda decidem quem pode resolver um incidente real. Eles também decidem quem pode detectar os momentos em que a produção de um agente parece correta na superfície e está silenciosa e dispendiosamente errada por baixo. O agente que escreveu 70% do código em um repositório moderno não pode dizer com segurança a ninguém onde suas suposições sobre segurança de thread, propriedade de memória ou isolamento de transação divergiram do tempo de execução. O engenheiro que consegue ler as diferenças e captá-lo é o engenheiro que o resto da equipe precisa na sala, e esse engenheiro é construído com base em fundamentos, não em habilidades de estímulo.
O corolário é que os fundamentos são agora uma competência de alavancagem e não uma competência de higiene. Em 2014, saber como funcionava uma retransmissão TCP fez com que um ticket de depuração fosse fechado mais rapidamente. Em 2026, o mesmo conhecimento impedirá que todo um pipeline de lançamento orientado por agente envie uma regressão em escala. O raio de explosão do engenheiro que sabe o que está acontecendo por baixo aumentou, não diminuiu.
A revisão é a nova escrita
Os engenheiros em 2026 geram código a uma taxa que excede o que qualquer um deles pode ler com atenção. A equipe que entrega rápido e sobrevive é aquela cujos engenheiros tratam a revisão do código gerado pela IA com pelo menos o mesmo rigor que antes reservavam para escrevê-lo. A pesquisa de desenvolvedores Stack Overflow de 2025 colocou 84% dos desenvolvedores em ferramentas de IA, com 46% dizendo que não confiam no resultado, um aumento acentuado em relação aos 31% do ano anterior. Essa lacuna, o uso intenso aliado à baixa confiança, é exatamente onde as habilidades de revisão são mais importantes agora. Os codificadores que pressionam muito e revisam pouco estão acumulando uma dívida que vencerá durante o primeiro incidente real, e o engenheiro que pode pagá-la é aquele que combinou seu volume com um conhecimento profundo dos primeiros princípios dos sistemas envolvidos.
O novo diferencial é o funil de produto
Ambos são necessários. Nenhum dos dois é suficiente. O engenheiro que importa em 2026 é aquele que parou de esperar a chegada do funil em forma de ticket Jira.
Isso significa fazer coisas que historicamente o papel foi autorizado a ignorar.
Fale com os clientes. Observe como eles realmente usam o produto. Leia a fila de suporte. Participe da chamada de vendas. O sinal que uma equipe de produto recebe por meio de três camadas de resumo, um engenheiro agora pode obter em primeira mão em uma tarde.
Gere ideias, não apenas estimativas. O gerente de produto que costumava buscar ideias para 8 engenheiros não consegue encontrar ideias para 20 com a mesma fidelidade. O engenheiro que aparece com uma oportunidade validada e com escopo definido não está mais fazendo o trabalho do PM. O engenheiro está fazendo o trabalho que a nova proporção exige.
Trabalhe de trás para frente a partir do cliente. A Amazon escreve o comunicado à imprensa primeiro há duas décadas. A disciplina funciona bem para equipes de um só e para enxames de agentes. Ambos produzem uma grande quantidade de software funcional na direção errada, sem uma declaração clara do que "cliente ganha" significa antes de qualquer código ser escrito.
Pare de se esconder atrás da largura de banda. A resposta honesta para "Você tem capacidade para essa ideia?" costumava ser ‘Não’. Com rotinas, ganchos e uma pilha de agentes cooperativos, a resposta honesta está mais próxima de "Quanto vale a ideia?" Essa é uma conversa diferente e muito mais difícil de ter sem um ponto de vista real sobre o cliente.
O que a próxima década recompensará
A história de cinco fases acima não é realmente uma história de ferramentas. É uma história de qual parte do trabalho um ser humano teve que fazer. A parte que ainda é humana, e que permanecerá humana no futuro próximo, subiu no funil: da digitação à revisão, à decisão, à escolha do cliente a atender e do problema a resolver.
A versão 2026 de um grande engenheiro não é aquela que escreve mais código. É aquele que sabe o que construir, pode provar que vale a pena construir e tem a frota de agentes mais a disciplina de revisão para enviá-lo sem que o sistema entre em colapso sob sua própria velocidade.
Os engenheiros que internalizarem isso passarão a próxima década realizando o trabalho mais interessante que o software já produziu. Os engenheiros que esperam por um tíquete vão gastá-lo observando o tíquete ser redigido pelo agente ao lado deles.
Ishan Gupta é engenheiro de software na Amazon.
Fonte ==> Cyberseo
