Na era da AI, precisamos de engenheiros com mais «pensamento de produto».

Claude Code permite que a organização de engenharia da Anthropic tenha uma produção real equivalente a cerca de três vezes a força de trabalho, mas o gargalo não desapareceu, mudou de "escrever código" para "decidir o que fazer".
(Contexto anterior: Claude Code adiciona funcionalidade de tarefas agendadas na cloud! Sem precisar de abrir o computador, a IA analisa automaticamente PRs e faz atualizações)
(Complemento de contexto: Engenheiros da Anthropic já não escrevem código: Claude está a treinar a próxima geração de Claude, CEO diz "não tenho a certeza de quanto tempo resta")

A produtividade dos engenheiros triplicou, mas a empresa continua a contratar mais pessoas. Isto parece contraditório, mas é exatamente o que a Anthropic está a fazer. Segundo um artigo de opinião do engenheiro de software da Amazon Ishan Gupta no VentureBeat, a Anthropic pediu recentemente à sua equipa de crescimento para "contratar mais" gestores de produto (PMs), em vez de reduzir, porque o Claude Code fez com que a produção real de toda a organização de engenharia equivalesse a cerca de três vezes a força de trabalho, transferindo o gargalo do IDE (ou seja, o local onde se escreve código) para as pessoas que "decidem o que fazer".

Simplificando, a ferramenta tornou-se mais rápida, mas quem diz à ferramenta o que fazer não acompanhou.

O gargalo não está a escrever

Gupta descreveu o aspeto típico do processo de engenharia na última década: os engenheiros aprofundam-se na tecnologia, escrevem código, consultam o Stack Overflow quando ficam presos. E agora, o número de novas perguntas mensais no Stack Overflow caiu cerca de 77% desde o lançamento do ChatGPT em novembro de 2022. Este número é, por si só, um retrato da indústria: os engenheiros já não precisam de esperar por respostas na comunidade.

Ele divide esta mudança em cinco fases. A primeira fase é a era do Stack Overflow (2014 ao final de 2022), onde o pensamento dos engenheiros se concentrava num local, e os problemas tinham soluções fixas da comunidade. A segunda fase é a era dos separadores do navegador (final de 2022 a 2024), onde a primeira geração do ChatGPT funcionava fora do IDE, os engenheiros escreviam prompts no navegador e colavam-nos no VS Code, todo o processo ainda era single-thread e orientado pelo engenheiro.

A terceira fase é a era nativa do IDE (2024 a 2025): Cursor e Claude Code trouxeram o modelo para dentro do editor e deram-lhe acesso a todo o repositório. A consequência chave deste passo é que o papel do engenheiro sénior como "caminho de upgrade" desapareceu em grande parte; quando um engenheiro júnior fica preso, já não precisa de bater à porta do sénior, o modelo é mais paciente do que qualquer colega.

Em 2026, muitos programadores já digitam claude como primeiro comando no novo terminal.

A quarta fase é a era orientada por especificações (2025 a 2026): janelas de contexto maiores comprimem o trabalho que antes exigia tickets, ficheiros de design e um sprint inteiro numa única sessão. A equipa do Kiro IDE da Amazon supostamente reduziu o desenvolvimento de funcionalidades de duas semanas para dois dias. Uma equipa de engenharia da AWS completou uma reestruturação que originalmente exigia 30 engenheiros e 18 meses com 6 pessoas em 76 dias.

A quinta fase, a atual, é a era das Routines (2026): a Anthropic lançou em abril as Claude Code Routines, agentes programáveis e persistentes que podem executar periodicamente, por webhook ou durante a noite com o portátil fechado.

O Cron voltou, os Hooks voltaram. O trabalho dos engenheiros começa a ter uma componente de "orquestração": abrir um grupo de agentes antes de dormir, rever uma pilha de PRs de manhã.

Quem decide o que fazer?

No entanto, enquanto a produtividade da engenharia triplicou, a gestão de produto não mudou. Para preencher esta lacuna, o LinkedIn substituiu o percurso de Associate Product Manager (APM) pelo programa "Product Builder", formando generalistas que abrangem produto, design e engenharia; a Anthropic optou por contratar diretamente mais PMs.

O conselho de Gupta para os engenheiros é direto: o engenheiro importante em 2026 é aquele que já não espera que os requisitos apareçam. Em vez disso, deve falar ativamente com clientes, ler sugestões de apoio, sentar-se em chamadas de vendas, gerar ideias genuínas em vez de apenas dar estimativas passivamente.

O bom engenheiro de 2026 não é o que escreve mais código, mas sim o que sabe o que fazer, consegue provar que vale a pena, tem uma frota de agentes mais disciplina de revisão para o entregar, sem deixar o sistema colapsar devido à velocidade.

O texto final de Gupta deixa uma escolha clara: os engenheiros que interiorizarem isto passarão pela década mais interessante da história do software; os que continuarem à espera de tickets verão os agentes ao lado a processá-los.