O enquadramento ao qual eu sempre volto é o da palestra que Andrej Karpathy deu em junho de 2025 na AI Startup School da YC. Ele chamou de “Software 3.0” e disse uma frase que fez a sala parar: LLMs são um novo tipo de computador, e você os programa em inglês.
Oito anos antes, ele já havia escrito “Software 2.0”, o ensaio que defendia que redes neurais não eram apenas mais um classificador, e sim uma nova forma de construir software. O texto do 2.0 falava sobre treinar. A palestra do 3.0 fala sobre pilotar.
Se você leva o enquadramento de Karpathy a sério, a discussão sobre se a Inteligência Artificial ajuda ou atrapalha a produtividade dos desenvolvedores é a discussão errada. É como debater quais pincéis um pintor deveria usar em 1860, enquanto a fotografia está sendo inventada na rua de baixo. A pergunta interessante é o que muda no papel do engenheiro.
Passei o último ano acompanhando isso acontecer na Cheesecake Labs, com nossos próprios times e com clientes de fintech, mobilidade e engenharia de plataforma. Os padrões já estão claros o suficiente para colocar no papel.
Era um: código escrito por humanos
A primeira era vai mais ou menos até 2021. O código era escrito, linha por linha, por humanos. As ferramentas eram editores de texto, debuggers, terminais e mecanismos de busca. O resultado do dia de um engenheiro era código que compilava.
Essa era não acabou. Muito código ainda é escrito assim, e tudo bem em alguns contextos. Mas a trajetória seguiu adiante. O ponto a se notar é que praticamente toda ferramenta que construímos nessa era partia do princípio de que o engenheiro é o gargalo. As IDEs ficaram mais rápidas. Os frameworks subiram de nível. As linguagens ficaram mais expressivas. A stack inteira se otimizou para velocidade de digitação e carga cognitiva de um único humano em frente ao teclado.
Era dois: assistida por IA, os anos do autocomplete
A segunda era vai do fim de 2022 até meados de 2024. O ChatGPT foi lançado, o GitHub Copilot furou a bolha e o Cursor v1 transformou a IDE em uma superfície de chat. O padrão dessa era era o mesmo independentemente do fornecedor: a IA sugeria, o humano colava.
Isso foi útil. E também foi limitado de um jeito bem específico. A unidade de trabalho ainda era uma linha, uma função, um trecho de código. O engenheiro continuava no volante. A IA era um autocomplete inteligente e um canal alternativo para as perguntas que antes iam parar no Stack Overflow.
Os números dessa era são reais e vale citá-los. Em abril de 2025, Sundar Pichai afirmou na teleconferência de resultados da Alphabet que mais de 30% do código novo no Google estava sendo gerado por IA. A ressalva importa: humanos revisam e aceitam essas sugestões. Não é algo sem supervisão. Mas 30% não é erro de arredondamento.
No mesmo período, o Cursor relatou que a IA escrevia de 40% a 50% do código produzido dentro do editor. Superfície diferente, mesma trajetória. O que se manteve constante nas duas ferramentas foi a estrutura do trabalho em si: o engenheiro continuava digitando, revisando e sendo o único ponto de contato com a base de código. A produtividade aumentou, mas o formato do papel não mudou.
Leia também: A maioria das empresas não está pronta para IA. Veja como descobrir onde a sua realmente está.
Era três: agêntica
A era três começou a aparecer no fim de 2024 e se popularizou ao longo de 2025. A mudança é estrutural. O agente não completa código. Ele age. Lê a base de código, planeja uma mudança, edita arquivos, roda os testes, abre um pull request. O humano sobe uma camada.
Na prática, a era três é assim. Um engenheiro sai de uma reunião, dispara dois ou três agentes em branches diferentes, volta vinte minutos depois e revisa três pull requests. Cada um implementou uma feature. O engenheiro não digitou o corpo de nenhuma função. Ele escreveu uma spec, aprovou um plano e revisou um diff.
Isso não é um experimento mental. Boris Cherny, criador do Claude Code na Anthropic, descreve essa rotina em suas palestras. Ele também conta que o tempo de onboarding na Anthropic caiu de algumas semanas para alguns dias, porque as novas pessoas agora aprendem a base de código fazendo perguntas ao agente e lendo as respostas, em vez de passar horas em pareamento com alguém sênior. É a era três funcionando como projetado.
A mudança que a era três representa não é sair de “escrever código sem IA” para “escrever código com IA”. Isso descreve a era dois. A mudança estrutural é sair de assistir para pilotar: o engenheiro se torna o orquestrador, o agente faz a digitação e a unidade de trabalho sai da função e vai para a feature. O artefato que você revisa é um pull request, não um parágrafo.
Se você ainda vive na era dois, essa distinção provavelmente soa exagerada. Não é. A diferença entre usar o tab complete do Cursor e rodar uma sessão do Claude Code em plan mode é a diferença entre digitar mais rápido e ter outra descrição de cargo.
A era três cria um novo papel. Dois nomes, na verdade.
Quando você transfere boa parte da digitação para agentes de IA, duas coisas acontecem com o papel humano. Primeiro, a parcela de digitação do trabalho encolhe. Segundo, as partes que sempre foram as difíceis ficam mais expostas: decidir o que construir, julgar se o que foi construído está certo e conversar com as pessoas que vão usar aquilo.
Essa mudança cria um papel que atende por dois nomes em 2026. São primos próximos, mas não o mesmo trabalho, e vale entender a diferença.
O Product Engineer é a versão interna: um engenheiro em uma empresa de produto que assume resultados de ponta a ponta, conversa diretamente com PMs, designers e stakeholders, consulta dados de produção via MCPs e entrega features que chegam a todos os usuários de uma vez. O papel já está sendo contratado em escala. A Stripe tem uma vaga aberta de Staff Product Engineer no time de Checkout. A Linear está contratando um Senior/Staff Product Engineer para IA. A Vercel está contratando um Product Engineer para o v0.
A articulação mais clara do papel vem de Guillermo Rauch na Lenny’s Newsletter: o Product Engineer toma decisões de design, de produto e de engenharia na mesma cabeça, em vez de passar a bola entre três funções separadas.
O sinal de contratação também é um sinal de oferta. Um Product Engineer que só tem senso de produto é, na prática, um PM com título novo. Um que só tem profundidade de engenharia é um engenheiro de plataforma. O papel vive na interseção dos dois, e é exatamente por isso que a oferta é escassa e as vagas continuam abertas.
O Forward Deployed Engineer é o primo próximo, e o formato é outro. A Palantir criou o modelo no começo dos anos 2010. O FDE trabalha na empresa de produto (Anthropic, OpenAI, Palantir, Google) e é alocado dentro do ambiente de um cliente específico para integrar o produto ali. Um cliente por vez. Um para um.
O papel explodiu em 2025 e 2026, à medida que a integração de IA em empresas virou o gargalo. Gergely Orosz, do The Pragmatic Engineer, mapeou um crescimento de mais de 800% nas vagas de FDE em 2025. A a16z chamou a posição de “o trabalho mais quente da tecnologia”.
Anthropic, OpenAI, Scale AI e a maioria das empresas AI-native contratam ativamente sob esse título. A vaga atual de FDE da Anthropic pede “experiência em produção com LLMs, incluindo engenharia de prompt avançada, desenvolvimento de agentes, frameworks de avaliação e deploy em escala”.
A PostHog traçou a linha mais limpa entre os dois: “Product engineers buscam resolver um problema que muita gente tem, para criar uma solução reutilizável. FDEs focam em um cliente por vez.”
O que os dois papéis têm em comum é justamente o que os torna era três: um engenheiro que conversa com usuários, assume resultados e entrega rápido, com um agente fazendo a maior parte da digitação. A diferença é o escopo. Se você constrói um produto SaaS, provavelmente está contratando Product Engineers.
Se você vende capacidade de IA e precisa integrá-la a fundo com clientes corporativos, provavelmente está contratando Forward Deployed Engineers. Se a sua empresa é uma consultoria ou prestadora de serviços, nenhum dos dois títulos é tecnicamente correto, mas o músculo é o mesmo: gente capaz de entregar em dias o que antes levava um time um mês.
A resposta que a maioria dos líderes evita: a trilha de carreira que existe hoje não produz muita gente com esses dois formatos. A oferta é escassa e o conjunto de habilidades é mais amplo do que aquilo para o qual a maioria dos engenheiros sênior foi treinada.
Leia também: Sua estratégia de IA tem um problema de dados
O abismo: onde o resto do mercado está
A Pesquisa de IA Corporativa 2026 da Writer entrevistou 1.200 executivos C-level e 1.200 profissionais de áreas não técnicas. Dois números desse relatório valem ficar na cabeça. 79% das organizações relatam desafios significativos para adotar IA, número maior que o do ano anterior. Apenas 29% dizem enxergar ROI relevante, apesar de 97% terem colocado agentes de IA para rodar nos últimos doze meses.
Ou seja: a maioria das empresas colocou IA em algum lugar. A maioria não está tendo retorno. Por quê?
O gargalo é tudo que está em volta do modelo. O organograma ainda pressupõe um repasse sequencial: o PM escreve uma spec, o tech lead quebra em partes, o engenheiro escreve um ticket, o engenheiro escreve o código, o QA testa, o ops faz o deploy. IA dentro desse pipeline acelera uma etapa. As outras continuam com a mesma duração. O cycle time total quase não se move, e o custo dos tokens aparece como uma linha na planilha sem economia correspondente do outro lado.
Nas empresas do Vale que operam na era três, o pipeline é outro: o engenheiro conversa com o PM, consulta dados de produção diretamente com um agente conectado via MCP, entrega, revisa, instrumenta e aprende, com o agente cuidando da digitação. O cycle time despenca porque os repasses despencam junto.
A escolha diante da maioria dos líderes de engenharia não é “devemos adotar IA”. A maioria já fez isso. A escolha é “vamos redesenhar o papel e o pipeline para de fato usar aquilo que adotamos”. Esse é o trabalho que produz resultado, e é o trabalho que a maioria das empresas ainda não começou.
O que eu faria com isso
Quatro movimentos, nesta ordem, que eu colocaria na mesa neste trimestre.
Primeiro, pare de tratar IA como autocomplete. Se alguém do seu time ainda usa um agente de código do jeito que usava o Copilot em 2023, isso é lacuna de treinamento. Feche essa lacuna. O mínimo aceitável é que os engenheiros saibam colocar um agente em plan mode, revisar o plano e entregar uma feature de ponta a ponta sem escrever código à mão. Se o seu time não fez isso em uma feature real neste mês, agende.
Segundo, nomeie o papel de Product Engineer internamente. Você não precisa renomear todo mundo. Precisa reconhecer que as pessoas mais efetivas do seu time já operam mais perto desse papel do que de “desenvolvedor full-stack”. Promova com base no novo formato. Contrate com base nele para as novas vagas. A entrevista deve testar taste, capacidade de escrever specs no spec-driven development e julgamento sob ambiguidade, não LeetCode.
Terceiro, invista no harness. Esse é o trabalho que compõe juros. Skills, arquivos CLAUDE.md no nível do projeto e do usuário, servidores MCP conectados aos seus dados reais, automação de code review, gates de conclusão. Nada disso é glamouroso. Tudo isso é o que separa “usamos IA” de “mudamos como trabalhamos”. Dois dos três cases que rodamos na Cheesecake Labs no último trimestre saíram do papel porque o harness era forte.
Quarto, meça a coisa certa. Pare de contar tokens. Comece a contar features por engenheiro por semana e custo por feature entregue. Se você não consegue medir isso, não consegue saber se o investimento em IA está se pagando. A maior parte dos 79% do relatório da Writer não sabe responder “qual é o nosso custo por feature hoje versus um ano atrás”. Essa é a lacuna a fechar antes do próximo ciclo de orçamento.
Para fechar
O enquadramento das três eras de Karpathy é útil porque força uma pergunta que a maioria dos líderes ainda desvia. Não estamos na mesma era de dois anos atrás. As ferramentas são outras, o papel é outro, e o organograma que a maioria das empresas roda foi desenhado para a era dois. A tecnologia está pronta. O desenho dos papéis não.
As empresas que daqui a três anos vão parecer visionárias serão as que nomearam esse abismo e se reconstruíram em torno dele. As que continuarem tratando IA como um recurso de produtividade dentro do pipeline atual vão gastar muito dinheiro em tokens e se perguntar por que o ROI nunca apareceu.
Esse é o trabalho que fazemos na Cheesecake Labs todos os dias. Somos parceiros de empresas que já passaram da fase de protótipo e precisam colocar IA em produção com o rigor que isso exige. Specs, evals, harnesses, entrega agent-native, a infraestrutura sem glamour que separa demos de produtos duradouros. Se o seu time está encarando esse abismo, fale com a gente.
