Forward Deployed Engineering
A parceria de design que nunca termina. O que é Forward Deployed Engineering, por que a Palantir apostou a empresa inteira nisso, quais empresas realmente precisam — e por que a IA está empurrando mais gente para esse quadrante sem ninguém perceber.
A talk não abre com definição — abre com um dado. Pegue as SaaS públicas e meça por average contract value (ACV): quanto um cliente gasta com você por ano. A distribuição conta qual jogo cada empresa está jogando.
US$4M no topo — e um penhasco embaixo
ACV médio por cliente, valores aproximados. E repara no tamanho da empresa no topo: avaliação de outro planeta, com apenas alguns milhares de funcionários.
“A Palantir não está liderando essa lista. Está jogando um jogo diferente de todo mundo que aparece nela.”
Kevin Bai — dos dois lados da linha de frente
Na Anthropic ele não tem título formal: é do time técnico de Applied AI. Antes disso, entrou na Rippling para construir a função de FDE — foi a primeira pessoa do time, que cresceu até ~25 pessoas em um ano. E antes ainda, passou por várias funções na Palantir. A talk foi dada para mil engenheiros de AI no AI Engineer World's Fair.
O caminho que a talk percorre
- Parte 1 — O diagnóstico
- Comece pelo número: o ACV que separa a Palantir de todo mundo
- Por que a Palantir teve que inventar o FDE
- Em que quadrante do mercado o FDE é necessário
- Parte 2 — A prática
- A parceria de design que nunca terminou
- A armadilha do dev shop (e o papel da plataforma)
- As duas perguntas antes de montar uma função FDE
- O que mudou em 2026 — e as perguntas da plateia
Antes de ser um motion comercial, o FDE foi uma necessidade. A Palantir construiu a plataforma e depois descobriu que plataforma, sozinha, não se vende.
Foundry: dar nome próprio aos dados
A Foundry centraliza os dados de uma organização — de qualquer tamanho — e constrói uma ontologia em cima. Traduzindo: transformar dados em substantivos próprios. Em vez de tabela 1, tabela 2, tabela 3, existe um único conceito de verdade — “armazéns” — e você constrói aplicações em cima disso.
Genuinamente poderoso. Mas diga isso para o líder de uma indústria: “legal, você organizou os meus dados. O que isso faz pelo meu negócio de verdade?”
E ele tem razão. É exatamente aí que vender tecnologia pura fica devendo.
Plataforma de apps entrega o seu sucesso na mão do cliente
Se você vende uma plataforma de construção de aplicações, o seu sucesso passa a ser determinado por quão bem o cliente usa o seu software. E a conta não fecha:
- O cliente paga pela plataforma;
- paga de novo para treinar as pessoas nela;
- e só então consegue construir alguma coisa.
É uma forma péssima de fazer negócio.
Produto + serviço como uma coisa só
A resposta da Palantir: parar de vender serviços, parar de vender produtos — e vender os dois como uma coisa única. O cliente não compra software. Não compra as horas de ninguém. Compra um resultado.
O movimento: mandar gente realmente boa entender o negócio do cliente, construir em cima da plataforma e entregar o resultado.
Se você opera CPG, o negócio se decide em espaço na prateleira e volume de vendas. Como o dado está organizado? Detalhe de implementação — não deveria nem chegar perto da sua lista de preocupações.
A Fortune 500 de petróleo não tem esse tipo de engenharia
Foundry é uma plataforma para construir apps — o que a torna inerentemente pouco interessante para Google, Meta ou os labs: eles têm engenheiros excelentes e constroem o que precisarem. O problema aparece do outro lado: venda para uma petroleira da Fortune 500 e essa profundidade de engenharia simplesmente não existe. Os pipelines deles não são pipelines de dados.
Sobram dois caminhos: confiar que o cliente vai investir anos para ficar bom na sua plataforma — ou dizer: “aqui está o setup; emprestamos engenheiros excelentes que você não precisa contratar, recrutar, gerenciar ou manter”.
“Eles conhecem a plataforma de cor — e trabalham com você como o garçom de um restaurante fino: descobrem o que você realmente precisa e vão construir.”
Foi assim que a Palantir chegou à Fortune 500 global. O placar é o número da primeira aba.
Substantivos e verbos: os três ingredientes de um sistema centrado em decisão
A ontologia, no fundo, é os substantivos e os verbos do seu negócio. No exemplo de manufatura: plantas, armazéns de onde saem produtos, clientes que recebem. Relações interconectadas, complexas — que a ontologia modela como o negócio de fato opera, não como os outros sistemas precisam que os dados estejam para funcionar.
Para um sistema centrado em decisão, são necessárias três coisas:
Conexão com todos os sistemas: internos, de prateleira, legado ou novos. São mais de 300 conectores prontos — e dá para usar direto dados que já vivem em Snowflake, Databricks e BigQuery.
De regras simples em planilha a modelos de ML, previsões e otimizadores de terceiros — dentro ou fora da plataforma, tudo modelado no objeto semântico.
Escrita de volta nos sistemas: abrir uma transferência no SAP, acionar o chão de fábrica, finanças, legado, edge, cloud — até webhooks.
Junte os três e a ontologia vira um gêmeo digital de como a empresa opera. Em cima dela nascem os workflows (com pessoas e processos embutidos) — e as análises são um subproduto desses workflows.
É isso que dá contexto ao agente — e matéria-prima ao FDE
Com a ontologia no lugar, a camada generativa (via AIP) deixa de ver “dados soltos” e passa a ter contexto: a lógica de como a empresa pensa e o poder de agir. O modelo raciocina sobre a ontologia, chama modelos determinísticos e dispara ações de volta nos sistemas — em vez de a pessoa ficar pulando de dashboard em dashboard para transformar insight em ação.
A razão pela qual isso importa: os LLMs não foram treinados nos dados nem nos processos do seu negócio. A ontologia é exatamente esse contexto que falta.
Em cima dela vêm os produtos: apps (inclusive um app de chão de fábrica), aplicações React sob medida e um SDK da ontologia — um SDK do seu negócio e dos seus processos, com workflows agênticos que se plugam nas aplicações que já existem.
“O objetivo, com o tempo, é automatizar cada vez mais o seu negócio — IA e humanos trabalhando juntos na ontologia.”
Quando a talk diz que o FDE monta primitivas em soluções sob medida, é nesta camada que ele trabalha: a ontologia é a matéria-prima da customização. E quando diz que “quase toda plataforma ficou agêntica e customizável”, é a ontologia que dá contexto ao agente.
Mandar engenheiro para a frente de cliente é uma ideia genuinamente estranha — engenheiros de software, ele incluso, estão entre as últimas pessoas que deveriam atender cliente. Então a decisão se resume a duas dimensões: quão técnico é o que você vende, e quão técnico é quem compra.
Três caixas — só uma precisa de FDE
Seus usuários são engenheiros de software. Eles absorvem a complexidade porque isso é o trabalho deles.
Não precisa de FDE
As ferramentas podem até ser complicadas, mas não são feitas para construir em cima. Configurar não é programar.
Não precisa de FDE
O único canto do mercado onde o FDE é necessário — e era exatamente onde a Palantir estava: vender algo extremamente técnico para quem não é técnico.
É aqui que o FDE nasce
Você se reconhece no terceiro quadrante?
Guarde esse filtro — ele decide tudo que vem adiante: das duas perguntas até a armadilha do dev shop. Se a sua empresa vende produto técnico para comprador não-técnico, o resto da talk é sobre você. Se não, é bem possível que o FDE não seja o seu caso.
O FDE nasce onde a complexidade do produto não tem quem a absorva do outro lado da mesa.
FDE não é invenção tecnológica — é uma readaptação. A parceria de design das startups, escalada para dentro do enterprise. E sem data de validade.
Toda startup começa do jeito FDE — e desiste no capítulo 1
Quem já viveu startup reconhece o movimento por outro nome. Nos primeiros dias, você não sabe qual é o seu produto, e o cliente não sabe o que está comprando. Então você diz: “deixa eu trabalhar junto com você — eu gasto meu tempo, minha energia e meus recursos, você me dá contexto sobre o problema, e eu construo algo bom”. É assim que a maioria dos B2B encontra product-market fit.
O FDE é isso escalado para o enterprise. A aposta central da Palantir:
“Quem decidiu que parcerias de design valem só para os primeiros dezoito meses de uma empresa?”
Se cada FDE constrói do zero, você não tem uma função FDE — tem um dev shop
O contra-argumento é óbvio e correto: não dá para manter isso no enterprise. Construir algo customizado para cada cliente vira pastoreio de gatos em cima de código terrível — ninguém quer aprender 55 repositórios. Correto — se cada FDE construir do zero.
E aqui vem a parte dita sem rodeios: se você monta uma função FDE em que cada FDE constrói do zero, você não tem uma função FDE. Você tem um dev shop.
Nada de errado com dev shops — são negócios lucrativos. Mas é uma empresa diferente da que você acha que está construindo.
Código ruim espalhado por dezenas de repositórios, manutenção comendo o P&L — quando os engenheiros não pediram demissão antes.
Já existe um conjunto de primitivas compartilhadas. O trabalho é montá-las em aplicação, workflow, solução — nunca reinventar a roda.
FDEs nunca escrevem software do zero. Eles montam algo arbitrariamente valioso para aquele cliente em cima da plataforma. Sem plataforma, o custo de manutenção engole o negócio — com ou sem engenheiros.
Para levar isso de volta à sua empresa, duas perguntas. Uma evita moda; a outra evita falência. E, no fim, o que mudou em 2026 — o ano em que a IA empurrou todo mundo para o quadrante.
Eu preciso — ou só quero — uma função FDE?
É fácil querer o que está na moda. O teste real: você tem algum canto do negócio onde é obrigado a levar uma coisa tecnicamente complicada para um comprador não-técnico?
Se não tem, o FDE provavelmente não é a sua resposta. Para motion técnico, existe trabalho ótimo com DevRel e engajamento de desenvolvedores; para SaaS mais tradicional, com um bom motion sales-led.
Eu tenho uma plataforma — ou estou disposto a investir numa?
Por mais tentador que seja ter engenheiros gerando receita direto: se eles não constroem sobre primitivas compartilhadas, você está entrando num período muito ruim.
Não dá para exagerar a carga de manutenção que isso cria — mesmo quando já existe uma plataforma robusta. Sem plataforma, é fatal.
1) FDE é resposta para um contexto específico: produto técnico + comprador não-técnico. 2) FDE sem plataforma não é FDE — é um jeito caro de virar dev shop.
Quase toda plataforma ficou agêntica — e customizável
A Palantir foi a mercado por volta de 2004. A IA obviamente tornou escrever código muito mais fácil — e construir software sofisticado e customizável para clientes também. Mas essa não é a mudança interessante.
A hipótese: o mundo não acordou de repente reconhecendo que o motion FDE é uma boa ideia. O que mudou foi a natureza de fazer negócio em software.
- Quase toda plataforma agora é agêntica;
- logo, quase toda plataforma agora é customizável;
- logo, seus clientes não têm ideia do que o seu produto de fato faz.
E deixar o sucesso ou o fracasso do produto nas mãos da capacidade de implementação do cliente não vai ser um movimento confortável na hora de subir de mercado — ou expandir horizontalmente, ou verticalmente.
“A IA está empurrando em silêncio muito mais empresas para o terceiro quadrante. A maioria delas ainda não percebeu.”
As perguntas da plateia — e as respostas. Tudo em discussão, exceto o emprego atual dele.
Quão atômicas devem ser as primitivas compartilhadas?
“Resposta de advogado: depende da sua base de usuários.” Existem indústrias onde dá para vender primitivas robustas — o app já vem 60% construído e o cliente customiza os 40% restantes. Em outras, isso é completamente inadequado: você precisa de ferramentas extremamente granulares.
O exemplo universal é a AWS: boa parte da plateia conseguiria comprar racks, subir servidores e mantê-los de pé — mas quem faz isso desde os anos 90? A AWS entrega primitivas compartilhadas, tipo o DynamoDB, para você não inventar um banco de dados do zero. E faz isso justamente porque atende uma base enorme e diversa de clientes.
Deve haver mais de um FDE por conta?
Fortemente encorajado. Em trabalho customizado, a última coisa que você quer é um ponto único de falha: uma pessoa segurando todo o contexto, tirando férias, e você encrencado.
Às vezes são até duas empresas diferentes no mesmo projeto — como parceria ou como competição. O modelo mental é o de um contractor: basta definir quem é o contractor daquela situação.
O que vai para a plataforma e o que fica no forward deployed?
Qualquer coisa bespoke, única de um cliente, fica com aquele cliente. Qualquer coisa generalizável deve ser generalizada com o tempo. No começo você não vai ter muitas primitivas — e tudo bem.
Mais do que isso: o FDE é uma forma fantástica de batedor (scout) — ir a campo para descobrir quais investimentos de produto realmente valem a pena.
Qual é o perfil ideal de FDE?
A frase que ele deixa: um FDE é nada mais que um engenheiro de software voltado ao cliente.
Alguém que você contrataria como engenheiro do seu time — e também confiaria na frente de um cliente, em qualquer situação. O resto você descobre com o tempo.
As frases que resumem a talk
“O cliente não compra software. Não compra horas de ninguém. Compra resultado.”
“A Palantir não lidera a lista: ela joga um jogo diferente de todo mundo que está nela.”
“Só um quadrante precisa de FDE: produto técnico para comprador não-técnico.”
“Quem decidiu que parcerias de design só valem para os primeiros 18 meses de uma empresa?”
“Se cada FDE constrói do zero, você não tem uma função FDE — tem um dev shop.”
“FDE é uma parceria de design que nunca terminou.”
“Sem plataforma, a carga de manutenção é fatal.”
“Um FDE é nada mais que um engenheiro de software voltado ao cliente.”
Complemento: um ensaio da Sequoia Capital que anda junto com a tese do FDE — e vai um passo além. “A próxima empresa de US$1 trilhão será uma empresa de software disfarçada de firma de serviços.” Ensaio de Julien Bek, março de 2026.
Se você vende a ferramenta, corre contra o modelo. Se vende o trabalho, o modelo trabalha para você.
Todo fundador de ferramenta de AI faz a mesma pergunta: o que acontece quando a próxima versão do Claude transformar o meu produto em uma feature? A preocupação é justa — mas tem lado. Quem vende a ferramenta está numa corrida contra o modelo. Quem vende o trabalho fica mais rápido, mais barato e mais difícil de competir a cada melhoria do modelo.
Uma empresa gasta US$10 mil/ano com QuickBooks e US$120 mil com um contador para fechar os livros. A próxima empresa lendária vai simplesmente fechar os livros.
Escrever código é inteligência. Saber o que construir é julgamento.
Traduzir uma spec em código, testar, debugar: as regras são complexas, mas são regras. Julgamento é diferente — exige experiência e gosto, instinto construído em anos de prática. Decidir qual feature construir depois, se vale assumir dívida técnica, quando lançar antes de estar pronto.
A razão de código ter puxado a fila é simples: é trabalho primariamente de inteligência. E o que chegou primeiro para uma profissão está vindo para todas.
O copiloto vende a ferramenta. O autopiloto vende o trabalho.
Até recentemente, os modelos ainda estavam desenvolvendo inteligência e julgamento — então o caminho era começar como copiloto: AI nas mãos do profissional, que decide o que fazer com ela. Harvey vende para escritórios de advocacia. Rogo vende para bancos de investimento. O profissional é o cliente, a ferramenta o deixa mais produtivo, e ele responde pelo resultado.
Hoje os modelos ficaram inteligentes o suficiente para, em algumas categorias, começar direto como autopiloto. A Crosby vende para a empresa que precisa de um NDA — não para o advogado externo. A WithCoverage vende para o CFO que precisa de seguro — não para o corretor. O cliente compra o resultado direto.
O orçamento de trabalho de qualquer profissão é muito maior que o orçamento de ferramenta — e o autopiloto captura o orçamento de trabalho desde o dia 1. Quanto maior a razão de inteligência de um campo, mais cedo os autopilotos vencem.
O julgamento de hoje é a inteligência de amanhã.
Conforme os sistemas acumulam dados proprietários sobre o que é bom julgamento no seu domínio, a fronteira se move: copilotos e autopilotos convergem — e a transição já começou em várias categorias.
A posição de largada importa: ela determina onde o autopiloto ganha clientes agora e começa a compor os dados que, no fim, vão deixar ele encarar também o julgamento.
Terceirização como cunha: comece pelo trabalho que já é outsourced
Para cada US$1 gasto com software, US$6 são gastos com serviços. O mercado dos autopilotos é todo o gasto de trabalho da categoria (interno + terceirizado) — mas o lugar certo de começar é onde a terceirização já existe.
Se uma tarefa já é terceirizada, isso diz três coisas:
- A empresa já aceitou que esse trabalho pode ser feito externamente;
- já existe uma linha de orçamento que pode ser substituída de forma limpa;
- o comprador já compra um resultado.
Substituir um contrato de outsourcing por um provedor de serviços AI-native é uma troca de fornecedor. Substituir headcount é uma reorg.
Comece pela tarefa terceirizada e intensiva em inteligência; acerte a distribuição; expanda para o trabalho interno e intensivo em julgamento conforme a AI compõe. A tarefa terceirizada é a cunha; o trabalho interno é o TAM de longo prazo. (A Crosby começou com NDAs: tarefa bem definida, majoritariamente inteligência, que quase toda empresa já terceiriza para advogado externo.)
Onde os autopilotos já têm porta de entrada
Cada vertical de serviços no espectro inteligência → julgamento × terceirizado → interno, com o TAM de trabalho em destaque. Lista ilustrativa do ensaio.
O maior mercado em dólares da lista. Linhas comerciais padrão são altamente padronizadas: o valor do corretor é cotar entre seguradoras e preencher formulários — puro trabalho de inteligência. A distribuição é fragmentadíssima: milhares de corretoras pequenas, nenhum incumbente dono da relação.
WithCoverage · Harper
Os EUA perderam ~340 mil contadores em cinco anos enquanto a demanda crescia; 75% dos CPAs estão perto de se aposentar. Essa escassez estrutural empurra o setor a aceitar AI mais rápido que quase todos.
Rillet · Basis
Parece “saúde”, mas a camada de billing é quase pura inteligência: codificação médica é traduzir notas clínicas em ~70 mil códigos ICD-10. Terceirização madura e orientada a resultado — o autopiloto só precisa fazer o mesmo mais barato.
Anterior
Do outro lado da apólice: interpretar a linguagem do contrato contra tabelas de danos e fixar reservas por tabelas atuariais. A força de trabalho está envelhecendo sem reposição; o mercado é massivamente terceirizado para independentes e TPAs (Crawford, Sedgwick).
Pace · Strala
A licença de CPA cria um moat regulatório, mas 80–90% do trabalho por baixo é inteligência. Cada jurisdição adicional aprofunda o moat de dados — e complexidade multi-jurisdição é exatamente o que o SMB terceiriza.
TaxGPT · Skalar · Ravical
Redação de contratos, NDAs, filings: alta inteligência e rotineiramente terceirizado. O produto é padronizado o suficiente para a qualidade ser verificável — dá para confiar no output sem expertise jurídica profunda.
Harvey · Crosby · Lawhive
Todo SMB terceiriza TI: patch, monitoramento, provisionamento, triagem de alertas — inteligência rodando em repetição por milhares de ambientes idênticos. O software atual vende ferramenta para o MSP; ninguém vendeu “sua TI roda” como resultado.
Edra · Serval
Só os 20% maiores de fornecedores são negociados a sério; a cauda longa fica sem atenção porque não é econômico. Leakage de contrato: 2–5% do gasto total. A cunha é trabalho abandonado — sem orçamento a justificar, sem incumbente a deslocar: dinheiro achado.
Magentic · AskLio · Tacto
O maior mercado de serviços da lista. O topo do funil (screening, matching, outreach) é pura inteligência; fechar candidato e avaliar fit cultural é julgamento. A cunha mora nas vagas de alto volume e baixo julgamento.
Juicebox · Mercor · Jack & Jill
Enorme, mas majoritariamente julgamento. A pergunta interessante: dá para disaggregar consultoria em componentes de inteligência (coleta de dados, benchmarking) e de julgamento (recomendação estratégica) — automatizando a primeira e mantendo a segunda humana?
A definir
TAM de trabalho citado no ensaio (valores ilustrativos).
Quem vende ferramenta tem medo de vender o trabalho
Em 2025, as empresas de AI que mais cresceram eram copilotos. Em 2026, muitas vão tentar virar autopilotos — têm o produto e o conhecimento do cliente. Mas enfrentam o dilema do inovador: vender o trabalho significa cortar os próprios clientes de fazerem o trabalho. É aí que abre a janela para os autopilotos pure-play.
Duas teses, a mesma venda: resultado
O FDE vende o resultado construído ao vivo com o cliente, em cima de uma plataforma. O autopiloto vende o resultado empacotado — um software se passando de firma de serviços. Quando a talk diz que o cliente não compra software nem horas, compra resultado, este ensaio é o mesmo raciocínio aplicado a cada vertical de serviços.
Complemento a16z: se a interface some e os agentes assumem, onde fica a defensabilidade de um sistema de registro? Ensaio de Seema Amble, maio de 2026, a partir do movimento headless da Salesforce.
Se você tira a UI e expõe o banco, o que sobra de verdade?
A Salesforce anunciou que vai abrir suas APIs e lançar um produto headless — a aposta de que, num mundo agêntico, o valor está na camada de dados, não na interface. (Nota da autora: não mudou quase nada tecnicamente — as APIs que a Salesforce agora chama de “produto headless” existem há anos; foi um clássico lançamento de marketing.)
Mas o anúncio serve a uma pergunta melhor: se você tira a UI e expõe o banco, no que isso difere de um Postgres, um schema bem desenhado e uma API? Na era SaaS, o sistema de registro era defensável porque humanos viviam na interface. Na era agêntica, essa vantagem enfraquece.
As camadas defensáveis se movem para baixo — modelos de dados, permissões, lógica de workflow, compliance — e para cima: redes, geração de dados proprietários e execução no mundo real.
A mesma onda aparece em volta de outros incumbentes: a a16z nota um ecossistema AI-friendly inteiro proliferando ao redor da SAP.
Por que os humanos tornavam o sistema de registro pegajoso
Sistema de registro é a fonte autoritativa da verdade de um domínio de dados: o CRM é o sistema de registro da receita, o HRIS das pessoas, o ERP do dinheiro. O que os torna poderosos não é só guardar dados — é virar a realidade compartilhada de onde a empresa inteira opera.
Por duas décadas, a Salesforce vendeu uma forma de líderes de vendas tocarem o time: dashboards, pipeline, forecast, activity feeds. O modelo de negócio era assento de usuário; o banco embaixo era crítico, mas incidental. A UI é que dirigia a pegajosidade — forçava higiene de dados, criava vocabulário compartilhado (Leads, Opportunities, Accounts) e fazia milhares de vendedores alimentarem o sistema. Tanto que muita gente insiste em levar a Salesforce junto na troca de emprego: não pela UI em si, mas pela memória muscular.
Agentes começam a desmontar esse modelo: em vez de interagir pela UI, leem e escrevem direto nos dados — e vão tornando obsoletos os fatores humanos clássicos (preferência, treinamento, contexto não documentado).
O que sempre tornou um sistema de registro pegajoso
O CRM é usado diariamente pelo time de GTM e além — vira infraestrutura crítica. A camada humana em cima (rituais, memória muscular, cadências de gestão) é a parte mais difícil de migrar: nem é reconhecida como algo que precisa migrar.
Um SoR pegajoso é lido e escrito o tempo todo — não há momento seguro para o corte, então empresas tendem a ficar com o fornecedor. (Um ATS, por contraste, tende a ser write-only: depois da contratação, quase ninguém volta naquele registro.)
Regras construídas ao longo de anos por admins e integradores: “deals acima de US$100K precisam de aprovação de VP”, “EMEA exige revisão de privacidade”, “desconto de logo estratégico só no fim do trimestre”. Migrar é fazer engenharia reversa de cada automação — ou perder a memória institucional.
Quanto software a jusante depende do SoR (internas) e quantos atores externos precisam de acesso direto — auditores, contadores, reguladores, no caso de um ERP (externas). Quanto mais conexões em qualquer dimensão, mais coisa para destrinchar numa migração.
Folha, ERP e dados de RH exigem fonte da verdade legalmente defensável, controle estrito de admin e envolvimento de auditores/reguladores em qualquer migração — muito mais pegajosos. Vendas e suporte (tipo Zendesk) ficam no outro extremo.
SoRs clássicos coletavam dados de cliente, mas pouco faziam com eles (e muitas vezes não podiam, por contrato) — insights cross-customer nunca vieram de verdade. E network effects históricos eram, no melhor caso, fracos: o workflow sozinho já criava moat suficiente.
“Substituir um ATS é doloroso, mas sobrevivível. Substituir um CRM é cirurgia de peito aberto. Substituir um ERP é cirurgia de peito aberto com o paciente correndo uma maratona.”
O que os agentes derrubam — e o que eles tornam ainda mais importante
Um agente não precisa de browser: precisa de API, contexto, instruções e capacidade de agir. Dois avanços destravaram isso em escala: LLMs capazes de raciocinar (ler contexto, formar plano, escolher ferramentas, executar e revisar — sem humano na maioria das tarefas) e o MCP, padronizando o acesso a ferramentas. Com MCP, o agente faz em milissegundos, em escala, o que o humano fazia na UI. E computer-using agents devem conseguir navegar as interfaces dos incumbentes sem nem precisar de API.
O que cai: frequência de acesso e read-write como moats — são fatores de memória muscular humana, e agente não tem memória muscular.
O que fica (e cresce):
- A lógica operacional e o contexto. Agentes precisam de regras explícitas, permissões e definição de processo para agir com segurança — a SOP vira ainda mais importante. É também a coisa mais difícil de reconstruir: não exporta limpo (ainda), especialmente com humanos no meio do processo. Mas capturar contexto está ficando mais fácil.
- Conectividade. Deixa de ser “acompanhar humanos” e passa a ser costurar dados e contexto entre funções e softwares tradicionalmente silados (vendas + billing + sucesso do cliente). Se a plataforma é o nó por onde agentes de várias organizações transacionam, a dependência aprofunda mais ainda.
- Compliance como arquitetura de confiança. Num mundo totalmente agêntico, o problema difícil é: qual agente pode fazer o quê, em nome de quem, com qual auditabilidade? Quem vira a camada de identidade e permissão das interações agente-a-agente ganha um papel estrutural difícil de deslocar.
Depois do headless, três caminhos
- Incumbente + agentes: usar os CLIs e APIs do incumbente — o produto nativo de agente (Agentforce, Joule) ou agentes próprios em cima. (Suspendendo a descrença de que as APIs são completas e usáveis, e que virar headless não é operacionalmente complexo.)
- DIY do sistema inteiro: construir do zero o modelo de dados, a lógica operacional, permissões, trilhas de auditoria, integrações — e os próprios agentes.
- Comprar um substituto AI-native: software nascido para a era agêntica, legível por máquina, com orquestração de agentes como recurso de primeira classe — e possivelmente headless.
Os novos fatores de defensabilidade
A AI derruba o custo de recriar os primeiros 80% do sistema (extração de dados, ferramentas cada vez melhores). Os incumbentes vão dificultar — APIs dolorosas, fechadas, incompletas ou economicamente desinteressantes. Os 20% restantes — exceções, aprovações, compliance, edge cases — é o que separa uma cunha de uma substituição de verdade.
O dado defensável não é o que você importa: é o que o produto faz existir. Walled gardens (proprietário, regulado, sempre atualizado) e o data exhaust de estar no loop: comportamento observado, taxas de resposta, timing, desfechos, benchmarks, padrões de exceção, traces de performance dos agentes. O dado virou o contexto.
Antes, guardar o registro bastava. Agora a defensabilidade vai para quem opera o ciclo fechado: agir → capturar o desfecho → melhorar a próxima decisão (aprovar gasto, disparar folha, conciliar nota, enviar aviso). Quem fica dentro da execução gera dado único, melhora com o uso e fica difícil de remover sem quebrar o workflow.
Modelos com conexão a operações do mundo real que não vão ser 100% automatizadas — despachar pessoas, mover bens, completar serviço (logística, field ops, pagamentos). A oportunidade: mercados onde o software decide e os agentes coordenam, mas o quilômetro final ainda exige execução física — ex.: software vertical de field services.
Historicamente fracos porque o software era interno. Na era agêntica, se o sistema media interações recorrentes entre partes (compradores e vendedores, empresas e auditores, pagadores e provedores), cada participante novo melhora a rede — via coordenação de workflow compartilhado, benchmark/inteligência da rede e confiança/estandardização: vira trilho do mercado, não só database.
Mesmo podendo, em tese, construir os próprios agentes, a maioria dos compradores verticais e funcionais não tem time de engenharia para manter database, lógica, stack de agente e governança — e DIY empurra o gasto para implementação e complexidade. Sobra espaço em operações complexas e tecnicamente mal atendidas: manufatura, back-office de construção, industrial, field service, contabilidade.
A ontologia precisa ser outra: o object model antigo capturava workflow para humanos (oportunidades, tickets, candidatos); o schema agêntico precisa capturar raciocínio, ações, estado, exceções, delegação e coordenação — o objeto nativo vira tarefa, intenção, thread, política, resultado. E o permissionamento precisa gerenciar agentes, não só humanos: quem pode o quê, via qual agente, sob qual política, com quais aprovações, qual trilha de auditoria e qual rollback. Tudo isso no contexto de custo — construir e manter agentes e banco, e quanto custa o acesso às APIs.
O próximo sistema de registro não é um repositório — é quem inicia o trabalho
Indo headless, os incumbentes fazem uma aposta implícita: a camada de dados continua sendo a fonte de valor. Em categorias fortemente reguladas (serviços financeiros), a aposta pode segurar por um tempo. Para quem constrói, a janela é outra: a próxima geração de sistemas de registro já nasce diferente — não repositórios que registram trabalho humano, mas sistemas agênticos que capturam contexto, iniciam o trabalho e gravam o data exhaust.
Os negócios mais interessantes vão se estender para execução no mundo real — coordenando equipes de campo, logística, service e ativos físicos — ou sentar entre múltiplas partes. Modelos de negócio do mundo velho, núcleo clássico do sistema de registro, com os dados ao fundo.
Tudo aqui fala da mesma pilha: a ontologia é o object model que precisa ser redesenhado; o “vender o trabalho” da Sequoia é a camada de ação; e o FDE é quem constrói a solução sobre essas primitivas. Quando a plataforma é agêntica e customizável, o sistema de registro vira o substrato — e a interface deixa de ser o produto.
Complemento Lightcone (YC): o playbook FDE contado por quem estava lá — a estrutura de times, os perfis, o pricing por outcome, a dor e o que faz virar (ou não) uma consultoria. Com Bob McGrew: early engineer no PayPal, executivo early na Palantir, Chief Research Officer da OpenAI na era ChatGPT/GPT-4/o1.
Bob McGrew — as duas pontas do mesmo modelo
Bob McGrew foi engenheiro early no PayPal, executivo early na Palantir e, até recentemente, Chief Research Officer da OpenAI, onde liderou o desenvolvimento do ChatGPT, do GPT-4 e do modelo de raciocínio o1. Agora, explora o futuro da AI e ocupa um posto inusitado: tenente-coronel da reserva do Exército americano (unidade Detachment 2011, assessorando a força em tecnologia).
A conversa no Lightcone começa com uma cena reveladora: numa conferência da YC, founders de AI não queriam saber do ChatGPT — queriam entender o modelo FDE da Palantir. Na job board da YC já passa de 100 startups contratando forward deployed engineers, contra praticamente zero três anos atrás.
Um FDE é alguém técnico que senta no site do cliente e preenche a lacuna entre o que o produto faz e o que o cliente precisa — pega um problema que a empresa nunca resolveu e entrega, com o time de produto, o outcome.
“Com agentes de AI, não existe produto incumbente. É por isso que o modelo FDE está decolando: tem tanta descoberta de produto a ser feita. O FDE é, na prática, fazer coisas que não escalam — em escala.”
Software para espiões — e a invenção do FDE
A Palantir começou construindo software para a comunidade de inteligência: software para espiões. O problema: não dá para conhecer espiões. E, se você encontra um, ele não vai te contar o que faz. A saída foi construir um demo e levar aos potenciais clientes. Stephen Cohen, fundador, mostrou o demo e ouviu: “isso está terrível, não tem nada a ver com o que a gente faz”. A resposta: “e como vocês gostariam que fosse?” — e anotou tudo.
Soa como o conselho padrão de founder de hoje (faça algo que as pessoas querem, saia do prédio), sendo feito em meados dos anos 2000. Como brinca o McGrew: o memezinho de “passei anos dominando essa técnica e o Paul Graham tuitou ela pra todo mundo”.
A virada: o caminho clássico — coisas que não escalam → product-market fit → abraçar a distância e escalar tudo igual — não funcionou. Cada cliente precisava de algo um pouco diferente. Foi aí que Shyam Sankar (early employee, hoje presidente/CTO da Palantir) inventou a estratégia FDE: em vez de um produto por cliente ou a feature exata por site, construir algo mais plataforma que produto, customizável em cada lugar — e usar os FDEs como descoberta de produto.
O FDE vai ao campo e constrói uma estrada de terra até onde o produto precisa chegar. O time de produto olha aquilo e pergunta: qual é a versão que generaliza para os próximos 5 ou 10 clientes? — e transforma a estrada de terra numa rodovia asfaltada.
Comece perto do que o produto já faz, mas resolvendo um dos cinco problemas mais importantes do CEO. Se não for prioridade do topo, ninguém terá energia para persistir no caminho difícil. Resolvido o primeiro, os FDEs enxergam outros problemas (às vezes muito mais valiosos) — e o jogo vira land and expand, não “vender a mesma coisa para todo mundo”.
Echo & Delta: as duas metades de um time FDE
Vão ao site, falam com os usuários e descobrem qual caso de uso e qual problema-chave fazem sentido — e são também os account managers. Perfil: gente do domínio (ex-oficial do Exército, gente de saúde), mas rebeldes — nas palavras do time, hereges: entendem como as coisas são feitas hoje e reconhecem que é insuficiente. Sem essa inconformidade, não se acha a mudança de degrau (3x, 10x) que dá sentido ao esforço.
Pegam as ideias e as trazem para o mundo real: protótipo que funciona, deploy. “Extremamente bons em escrever código muito rápido — e em comer muita dor.” Perfil: gente ótima de prototipagem. O perfil errado é o craftsman que ama abstrações perfeitas e software mantível por doze anos — esse não é o trabalho. A primeira versão pode (e vai) ser jogada fora; talvez uma segunda, talvez escrita por outra pessoa.
O ciclo é curto: entra-se com uma ideia, monta-se a solução, marca-se uma apresentação de progresso com a liderança em poucos meses — e, se der certo, é deploy na organização inteira.
E não é coincidência que a Palantir tenha gerado tantas startups: o treino de FDE é o treino de founder — você é founder em cada cliente novo, só que com uma poderosa alavancagem de produto na mão.
“É consultoria fantasiada” — e como não virar uma
A crítica clássica: “é só consultoria com marketing bonito”. McGrew responde sem gelosia: “existe um risco real de isso estar certo.” Em 2015, diziam que a Palantir era uma consultoria que nunca escalaria — que nem era um negócio de software. O que se deve ver no modelo, em vez disso:
- Perde dinheiro no começo de cada deployment — e tudo bem;
- com o tempo, o produto fica mais adequado ao cliente e menos gente é necessária no site;
- você vira “dono do direito” de atacar problemas mais importantes — o custo por valor entregue cai e a margem, negativa no início, fica positiva depois de um ano (ou mais).
É esse arco que separa valor repetível de um dev shop. E há dois modos de falha que empurram para a consultoria:
- Construir o que o cliente pede, não o que de fato é valioso para ele. “O cliente” é uma organização inteira: você fala com o CIO ou com um sponsor alguns níveis abaixo do CEO — que muitas vezes prefere que você resolva o problema fácil para ele, não o que melhora o negócio;
- deixar a customização por cliente dominar, sem nunca generalizar de volta para o produto.
Exige disciplina organizacional? “Sim — absoluta.” E o aviso de abertura do McGrew para quem pensa em copiar o modelo:
“Meus três primeiros conselhos são: não faça isso em casa. Só se você tentar muito não fazer — e falhar — talvez o FDE seja um moat para você. Se der para evitar, evite.”
Quem segura a visão — e onde nasceu a ontologia
O papel do time de produto não é desenhar a vertical perfeita; é segurar a visão: quando um problema novo aparece num cliente, qual é a versão generalizável para os próximos 10? O failure mode clássico é enfiar direto no produto o que um cliente precisou — e acabar com algo super especializado para um cliente só.
Foi nesse processo que nasceu a ontologia da Palantir. No início, a dúvida: “uma tabela para pessoas, outra para dinheiro, outra para x?”. Não funciona se você vai implantar em vários clientes. A saída foi subir um nível de abstração: o schema vira extremamente geral — objetos, propriedades, mídia e links entre objetos — e a ontologia define, por cliente, o que cada coisa significa (“isto é uma pessoa, isto é um navio, isto é um fluxo de dinheiro”). Como resume o McGrew: pense numa operação comum aplicada a coisas que têm certa propriedade — pessoas têm, navios também; pagamentos, não.
Detalhe de contratação: os PMs precisavam pensar nesse nível de abstração — e, conta ele, bons PMs de outras empresas não conseguiam; descreviam o fluxo de um cliente em vez de mexer na ontologia. A tensão entre campo e produto existia sempre, mas era menos de skill e mais de incentivo e ambiente: no site, a resposta certa é a solução mais simples para aquele problema (a estrada de terra); a asfaltada precisa servir vários clientes.
E o processo que dissolvia a briga: o FDE constrói algo num cliente → leva de volta ao time de produto → “qual a versão generalizada?” — com o FDE na conversa → puxam-se FDEs de outros clientes para co-desenhar a feature → com três workflows sutilmente diferentes na mesa, ninguém mais discute “geral vs. específico”: todos estão resolvendo o mesmo problema.
Contrato subindo, alavancagem subindo
Custo caindo, contrato estável, contratos simples e repetíveis, iguais para todos — e tudo bem serem pequenos, porque o custo marginal de deploy é baixo.
Mais e mais trabalho valioso para o mesmo cliente — e para os próximos. A customização por cliente pode até ficar igual; o que muda é o valor entregue. Contratos maiores, mais complexos, mais flexíveis.
Duas métricas para acompanhar: (1) o tamanho do contrato — ou melhor, o valor do outcome que você entrega (talvez você ainda não tenha o músculo de monetizá-lo por completo; entregar outcomes crescentes já é o sinal); e (2) a alavancagem de produto sobre esse outcome.
O produto precisa entregar a coisa boa ao usuário final e entregar alavancagem ao FDE que a entrega. O mesmo outcome no segundo cliente tem que ser mais fácil que no primeiro — e mais fácil ainda a cada cliente. E, se você abstraiu bem o núcleo, está construindo uma plataforma: os próprios FDEs acham usos novos para a técnica, e existe um “mercado interno” em que eles escolhem usar o produto abstraído em vez de hackear um one-off.
A parte da dor. “Não consigo usar a palavra dor o suficiente no FDE.” McGrew conta das vezes em que construiu algo que achava lindo e ouviu dos FDEs: “não, isso dá muito mais trabalho, não ajuda”. Na maioria das vezes, ele estava construindo o produto errado; outras vezes, estava no caminho certo, mas não fizera o bastante para ficar fácil — chegou a mandar devs ao campo para a solução emplacar. E os FDEs estão sempre certos? “Sim — para tudo isso.” A resposta certa é questão de julgamento: com o primeiro cliente, você literalmente não tem a informação necessária.
Venda o outcome — e assuma o risco primeiro
O modelo FDE empurra para contratos cada vez maiores; o SaaS empurra para contratos simples e iguais. Exemplos citados: a Castle (agente de voz para mortgage servicing, grandes bancos — a rampa é o número de chamadas bem-sucedidas) e a Happy Robot (agentes de voz para logística, clientes como a DHL).
A assimetria fundamental: a grande empresa não acredita que ela mesma consegue realizar nada (são muitos projetos fracassados) e também não acredita em você (acha que você é igual a ela). Você, por outro lado, sabe que consegue executar. Então, no começo, faz sentido a startup assumir o risco: “você paga quando funcionar” — ou quando formos capazes de expandir.
Onde emperra: se algo precisa rodar on-prem, prepare-se para brigar com o time de IT. Mais geral: descubra quem precisa dizer sim dentro da organização. Essas pessoas não pensam como startups e não estão alinhadas com o usuário final — dê-se um jeito de passar por elas. É mais um motivo para mirar os top-5 do CEO: você precisa de alguém do topo dizendo “dê autoridade de operação a eles”.
E o buy-in executivo é disciplina e skill: as empresas que fizeram melhor trouxeram gente que já tinha feito — mas dá para aprender. “Nós aprendemos.”
Sem incumbente: a descoberta de produto virou a categoria
- Não existe incumbente para substituir. No SaaS clássico, você troca um jeito de pagar contas por outro — todo mundo entende o mercado, e você escala sendo melhor. Com agentes, é uma categoria nova (como a Palantir foi: de PowerPoint + arquivos soltos para todo mundo editando o mesmo banco de dados).
- Mercado é segmentos, não uma coisa só. Você acha PMF num segmento, deploya quase sem customização nos vizinhos — e, quando satura, desenvolve tecnologia nova para o próximo segmento. “Coisas que não escalam — escalando”, segmento após segmento. (E um segmento não é igual a um cliente: num governo, um cliente pode ser dezenas de milhares de usuários.)
- Contratos gigantes sustentam o high-touch. Startups clássicas param o atendimento manual porque não sustentam o crescimento; com contratos de AI tão grandes, dá para ir longe indo ao escritório do cliente “fazer o install na Collison” — sentando do lado dele.
- A descoberta de produto só acontece de dentro. Daqui a cinco anos, olharemos para trás e “AI agents” nem vai ser uma coisa só — serão várias. Há descoberta demais para fazer, e ela só acontece dentro da empresa.
E a lição de carreira: construa — ou junte-se a — uma learning company. Google e Meta conseguem não aprender: a estratégia funciona, o mercado cresce, dá para cruzar em velocidade de cruzeiro. A Palantir nunca teve essa folga — por isso virou fábrica de founders. O conselho do Bob: procure uma empresa jovem (não necessariamente pequena) que ainda está descobrindo as coisas; é o que te posiciona para fundar depois.
O gap de agora é de adoção — e é aí que você entra
A capacidade dos modelos acelera num ritmo absurdo (abril de 2024 → abril de 2025, por exemplo), e vai continuar — mas a adoção está anos-luz atrás do que a velocidade da capacidade sugeriria. Nos próximos cinco anos, a capacidade dispara e o mundo parece... cada vez mais banal: “você está no seu Waymo e o pensamento é: ‘puxa, o trânsito está lento’”.
É o mesmo papel do FDE: preencher a lacuna entre o que a capability já consegue fazer e o que as pessoas conseguem adotar. AI precisa ser adotada — não acontece sozinho; exige engenhosidade humana, exploração e bastante dor.
O host Jared propôs a analogia; McGrew concordou:
“A OpenAI é o time de produto na matriz; as startups são os FDEs descobrindo como fazer a pesquisa virar adoção. Não é uma analogia ruim — talvez seja a verdade por baixo de por que a estratégia FDE está empolgante de novo.”
Este é o playbook por trás de tudo: a parceria de design do Kevin Bai, a plataforma com primitivas, a ontologia da Palantir e o “vender o trabalho” da Sequoia — aqui está o como, contado por quem construiu, com os erros para não repetir.
Complemento Lenny's Podcast: por dentro da empresa que mais forma founders no mundo — a cultura, o murder board, a vida de engenheiro de campo e o loop que transforma FDE em founder. Com Nabeel S. Qureshi: ~8 anos de Palantir como FDE, depois GoCardless, NIH e Mercatus.
Nabeel Qureshi — oito anos de campo na Palantir
Nabeel Qureshi passou ~8 anos como forward deployed engineer na Palantir — incluindo projetos de saúde pública com agências federais americanas na COVID-19 e aplicações de AI para descoberta de fármacos. Antes e depois: membro fundador e VP de business development da GoCardless (um dos maiores unicórnios fintech da Europa), trabalho com o NIH montando um dos maiores datasets médicos do mundo, uma passagem pelo Bank of England e um período como visiting scholar no Mercatus Center, com Tyler Cowen, pesquisando política de AI.
E não é só na fundação: a Palantir é nº 1 em PMs promovidos imediatamente no cargo seguinte, nº 2 em PMs que viram o primeiro PM da próxima empresa e nº 3 em ex-PMs que chegam a Head of Product. É a “fábrica de founders”: por que ela produz tanto — e o que dá para copiar.
Uma empresa estranha — e um filtro desenhado para repelir
“É uma empresa estranha. Não sei como alguém que não fosse o Peter Thiel poderia ter fundado isso.” Em certo momento, a Palantir ocupava um pedaço enorme de Palo Alto: andando pela cidade, só se viam pessoas de moletom da empresa e seus prédios. O dinheiro entrou; o funil de gente, mais ainda.
Os critérios de contratação eram três:
- Independentes de verdade — gente que não tem medo de discordar e questiona tudo;
- Interesses intelectuais amplos — o Karp lançou livro e cita intelectuais europeus como Camus: não é o que se vê num CEO de tech;
- Ultracompetitivos — mentalidade de vencer em todas as situações.
Nenhuma oferta saía sem um fundador na sala — Karp, Stephen Cohen ou, no início, gente como Joe Lonsdale. Com Cohen, eram 1h30 de filosofia: ele escolhia um tema aleatório, impossível de preparar, e cavava fundo para achar o limite do seu entendimento. Quem passava, entrava num filtro fortíssimo.
O conceito é o do “bat signal” (atribuído a Thiel): os melhores recrutadores do mundo emitem um sinal idiossincrático que repele parte das pessoas — quem sobra, está muito alinhado. É o que OpenAI e Anthropic fazem hoje com quem tem fervor quase religioso por AI. A versão Palantir: preocupação com preservar a civilização ocidental, tipo salvar o condado — falavam de defesa e inteligência muito antes de todo mundo, na era em que o Vale só olhava Facebook, Pinterest e apps sociais.
E a lição de valores: um negócio durável precisa deixar explícito para quem a empresa NÃO é — “não é todo mundo que precisa trabalhar aqui”. Isso poupa o tempo de quem não encaixa e atrai justamente os melhores.
Murder board — e a empresa sem cargos
Todo projeto novo começava com um “murder board” (termo militar): um plano de 2 páginas com visão, metas, a estratégia dos próximos 3 meses e os princípios do projeto — apresentado a 3 ou 4 pessoas inteligentes que não sabiam nada do assunto, convocadas para rasgar o plano.
Novatos escreviam “move fast”. “Todo mundo gosta de trabalhar rápido — isso não é um princípio, ninguém pode discordar racionalmente.” Um bom princípio faz alguém dizer: “por que você escolheu isso? isso me parece errado.”
A Palantir basicamente não usava cargos: todos no mesmo nível, com um título só — forward deployed engineer. Era o Thiel de Zero to One na prática: quando você cria títulos, as pessoas passam a competir por eles; e vale a Lei de Goodhart, a métrica vira o alvo e as pessoas jogam o sistema. (O exemplo Google: relatos de que lançar produto novo promove mais que melhorar produto existente — e o incentivo distorcido se acumula.) Na Palantir, só havia título para o CEO e seis diretores. Virava piada nos LinkedIn alheios — “fui SVP de XYZ” — mas o efeito interno importava: você ocupava um projeto por ser capaz — meritocracia permanente. Parou de entregar, é fácil trocar: não existia o cargo de “GM daquele projeto”.
Segunda a quinta no prédio do cliente
Havia dois tipos de engenheiro: um ficava no produto core (software engineer tradicional, sem sair de Palo Alto ou Nova York) e outro ia para o campo — de segunda a quinta, você praticamente se mudava para o prédio do cliente e sentava numa mesa ao lado dele. Esse era o forward deployed engineer, organizacionalmente dentro do BD, não do PD.
E havia duas variedades de FDE: a mais técnica (entrevista de engenharia, normalmente exigia CS) e uma cuja entrevista testava “quão razoavelmente você raciocina sobre dados” — não algoritmo em C++. Nessa, descobriram um perfil valioso: gente técnica que sabia traduzir o próprio trabalho para a linguagem de executivos e ler a dinâmica social de uma reunião.
O ritmo era o ponto: segunda reunião → segunda à noite constrói → terça mostra → feedback → corrige à noite → quarta mostra de novo… 4 a 5 ciclos por semana. “Em 6 semanas, você descobre que aquilo é muito valioso e alguém está disposto a pagar US$20 milhões.” É exatamente por isso que saem tantos founders dali.
Todo deal era grande, de vários milhões. “Se consertar um avião da Airbus vale US$100 milhões para o cliente, é assim que se precifica — não como comprar infraestrutura de dados.” Você tinha que virar amigo das pessoas-chave que reportam o problema ao CEO. E, como resume um post do Ted Mabrey, executivo da Palantir: FDE de verdade constrói produto novo quando o trabalho exige — não é “arquiteto de solução” encaixando um produto pronto. (E a IA barateou esse modelo: pelo menos 5–10x.)
O amigo Barry McCardel (CEO da Hex) escreveu: você provavelmente não precisa de FDEs — o modelo exige tolerância a desperdício e um ticket mínimo alto, na casa de US$1M de receita por cliente. A oportunidade derivada que ex-Palantir estão enxergando: fazer “uma Palantir” para quem a Palantir não atende por ticket pequeno — US$250 mil/ano em vez de US$5 milhões; o FDE existe, mas atende 5 clientes, em vez de morar numa fábrica na França.
A vida no campo: a cultura de viagem era avisada na contratação — “você vai ter que se adaptar; tudo bem?”. Chamado de última hora: “amanhã você voa para um país que não conhece”. E a lição que ficou: presença física vale muito mais — uns dias no local e um jantar à noite geram mais confiança que meses de Zoom. (Isso encolheu com a COVID e, depois do IPO, com os controles internos.)
Airbus A350: de tabelas “S3F1_Z” à ontologia
A Airbus estava lançando o A350 e precisava escalar a produção como nunca: de ~4 aviões por mês para 8, depois 16. O pedido não era “atualize nossa infraestrutura de dados” — era “nos ajude a atingir esse objetivo”. As peças vinham de vários países (cauda na Espanha, fuselagem no Reino Unido e na Alemanha) para montagem final na França; Nabeel ia e voltava entre eles só para entender onde as coisas estavam.
No chão de fábrica, o avião se move fisicamente de estação em estação, cada uma executando work orders e precisando de peças. O problema: a estação seguinte precisa saber o que foi feito e o que ficou pendente na anterior — e o trabalho atrasado transborda para o time seguinte. Tudo dependia de conversa informal no chão de fábrica. Os dados existiam, mas no SAP, em tabelas com nomes tipo “S3F1_Z”, indecifráveis sem expertise.
O insight que virou produto: pegar um monte de tabelas, fazer os joins certos e mapeá-las para conceitos humanos — peça, work order, avião. Aí o usuário loga e pergunta o que quer perguntar:
“Onde está o avião 79? Está na estação 31. Aqui estão as work orders.”
Isso inspirou diretamente a ontologia — hoje a maior parte do discurso da Palantir e, segundo ele, um diferencial que pouquíssimas empresas conseguem construir. O Lenny cita 4x de produtividade; Nabeel: “não lembro o número exato, mas pelo menos 4x naquele ano — obviamente a Airbus fez o trabalho; nós só ajudamos. Mas o CEO disse que tivemos papel importante.”
“Não é só uma Accenture chique?”
Disseram isso da fundação ao pós-IPO: consultoria fingindo ser empresa de produto. Hoje é inegável — procure “Palantir demo” no YouTube e o software está lá; você assina com cartão de crédito (via AIP); e as margens acima de 80% provam (consultoria bruta fica em 20–30%).
A gênese é bonita: havia talento de altíssimo nível no time de produto usando as ferramentas internas (Jupyter Notebooks e integrações primitivas) para criar valor — a Palantir era sua própria primeira cliente. A ideia revolucionária: “e se a gente abrisse as ferramentas internas para os clientes usarem?”. Então Shyam Sankar (hoje presidente/CTO) deu a ordem: “todo deployment de cliente tem que ter o cliente usando isso em até 3 meses.” Foi assustador — as ferramentas quebravam, exigiam debugar Spark — mas trouxe rigor e, depois de 3–4 anos, gerou o Foundry. O mesmo caminho tinha gerado antes o Gotham.
Pense numa pirâmide — ingestão de dados → mapeamento → camada para o usuário. O Gotham é otimizado para defesa e inteligência: mapas (tropas, tanques) e análise em grafo (achar redes; “quem o alvo ligou na semana passada?” — também usado contra fraude). O Foundry é o mundo “tradicional”: pipelines, limpeza, UIs point-and-click, notebooks e SQL — numa empresa comum, você não faz análise de grafo, faz queries clássicas.
E o segredo descoberto: integrar dados dentro de grandes organizações é doloroso e subestimado. “Você ouve: ‘estou tentando calcular as vendas do trimestre, mas esperei 6 semanas pela equipe de analytics’.” Ver o mesmo problema se repetir é o que permite construir algo generalizável. A análise é a ponta do iceberg: os últimos 5–10%; os outros 95% são obter acesso, limpar, juntar e normalizar tudo no mesmo formato. (Na Foundry, isso virou um “adaptador universal de dados” — lê JDBC, S3 e afins, mostra uma prévia das primeiras linhas e agenda ingestões.)
Boa parte do trabalho de campo, aliás, era político: em toda corporação há gatekeepers de dados cuja identidade profissional depende de serem os únicos que entendem o pipeline de vendas ou escrevem o SQL — “quando a empresa anuncia ‘dados acessíveis a todos, em ponto e clique’, instala-se o atrito”. E o concorrente, no fundo, nunca foi outro fornecedor: “o maior concorrente são as empresas que constroem a própria solução.”
Por que saem tantos founders
O time de Nabeel ao entrar tinha 20–25 pessoas; só ali, pelo menos 6 viraram founders de unicórnios ou pré-unicórnios. A retenção era altíssima; quem saía ia subir de nível no jogo — empreender (sair para big tech tradicional era raríssimo). E o dado que resume tudo: entre founders da YC há mais ex-Palantir do que ex-Google — com uma amostra do Google umas 50x maior.
Parte disso é o funil de PM: a Palantir ficou um tempo sem PMs e depois decretou que só quem se provou FDE no campo podia virar PM — nunca contratação externa (nada de PM vindo do Google). Quem conduziu o deployment da fábrica de aviões virou PM do Ontology. O fracasso temido era a “síndrome do Google Docs” (escrever o PRD e gerenciar por processo); o sucesso era ser engenheiro — ou muito fluente com engenheiros. O critério real: os engenheiros gostam e confiam em você?
Entrar numa organização, ganhar confiança, achar a dor real (não a que pediram), construir, ver em campo e incorporar ao produto — com 4–5 iterações por semana e precificação por valor. É o treino de founder completo, só que com alavancagem de produto na mão. “Pode parecer meio culto, mas todo mundo pensava assim.”
As zonas cinzentas, sem desviar o olhar
Ele entende os críticos — a Palantir faz produtos que, em alguns casos, causam mortes; e trabalha com governos impopulares. Mas pede nuance: trabalhou na resposta americana à COVID-19, com amigos na Operation Warp Speed — “esses projetos salvaram muitas vidas” — e, antes, na pesquisa de câncer no NIH. “Rasgar relações nem sempre é a resposta certa.” (O Google saindo do projeto de AI com o Pentágono? Para ele, é uma posição bem mais à esquerda que o americano médio.)
Sobre targeting: comparando 2010 com a metodologia atual, os ataques são muito mais precisos e específicos — menos erros. “Se você melhorou o processo e reduziu o erro, deveria se sentir bem.” Ele não trabalhou na divisão de defesa, mas insiste que zonas cinzentas precisam ser encaradas, sem garantia de que defesa seja sempre a escolha certa.
E a analogia do Vale que dói: engenheiros otimizando vídeo curto não querem pensar no efeito “no cérebro das crianças — uma criança de 11 anos rolando por 5 horas; você acha isso bom?”. Havia uma recusa geral em olhar a política do que a tecnologia faz — “deixem-nos brincar com nossos brinquedos, sentados em Menlo Park”. Até a Ucrânia tornar concreto: faltavam veículos e munição — “ainda bem que existem empresas como a Anduril”; e os EUA só estão à frente da China no espaço, diz, por causa da SpaceX. Dissuasão forte é necessária. “Não é uma pergunta difícil para mim.”
Três coisas que ele replicou no próprio startup
- Iteração rápida. Muitas apostas, ciclo curto: a dúvida “está falhando ou desistimos cedo demais?” se resolve testando rápido. Regra emprestada da YC: ao levar a ideia a um cliente, peça dinheiro de verdade — se ele não paga, mude de problema (não espere três semanas como times novos fazem);
- Cultura de confiança profunda. O sentimento “você trabalhou aqui, logo é competente; eu confio em você” — como na Palantir e na Airbnb. Trabalhar num lugar assim calibra seu padrão interno para sempre;
- Problema complexo do mundo real. Ele brincou que queria “software puro” (um IDE, sem e-mail de suporte) — e percebeu que a força dele é a rede e a experiência com as partes difíceis do mundo. “Daqui a dois anos teremos AI, e a saúde continuará bagunçada, o aluguel em Nova York nas alturas…”
O que destravou essa escolha: LLMs mudaram o jogo. Em 2015, vender software setor a setor era brutalmente difícil; desde o ChatGPT, setores antes evitados por investidores — saúde, governo — dão chance a startups pequenas. E o custo do trabalho tipo FDE caiu 5–10x.
E sobre pivotar: o erro mais comum é ficar rígido demais na visão de produto (“estamos construindo analytics”) quando o cliente mostra um problema maior — ou fora do alvo original. O caso que ele conta: a Retool mudou só o enquadramento do outbound — “construa ferramentas internas com facilidade” — e CTOs começaram a responder “sim, isso é uma dor enorme”. A solução era a mesma. Mantenha a matriz de opções aberta e saiba qual você está escolhendo, e por quê.
As frases, os livros e o mantra
“É uma empresa estranha. Não sei como alguém que não fosse o Peter Thiel poderia ter fundado isso.”
“Princípio bom é aquele com o qual se pode discordar.”
“O FDE não instala software nem vende software: o trabalho dele é resolver o problema.”
“A análise é a ponta do iceberg: os últimos 5–10%.”
“O maior concorrente são as empresas que constroem a própria solução.”
“Entre fundadores da YC há mais ex-Palantir do que ex-Google — com uma amostra 50x maior.”
- Leitura obrigatória de todo FDE da Palantir: Impro, de Keith Johnstone — improvisação e comportamento social. Ele também recomenda a “Henriad” de Shakespeare (poder, política e os sacrifícios de quem chega ao topo), High Output Management (Grove, o jeito de pensar) e Anna Karenina — Tolstói entrava na mente de qualquer personagem, até do criado de mesa; é empatia aplicada, metade do trabalho de produto. No cinema: Decision to Leave, do Park Chan-wook.
- O mantra dele: Christopher Alexander, arquiteto, repetia toda semana: “há uma catedral gótica na França chamada Chartres — mirem em algo como Chartres; façam algo ainda melhor.” Não mire no “bom o suficiente”.
- Ferramentas que ele usa: Wispr Flow (ditado), Claude Code (“viciante — um vislumbre dos agentes de AI”) e Gemini 2.5 Pro.
- Sobre acompanhar AI: Latent Space (swyx) e virar um “ciborgue híbrido”. Analogia do xadrez: os melhores do mundo (Carlsen, Caruana) foram os que mais se entrosaram com os engines — aprenda como a AI joga e copie os lances.
- Contrarian: faculdade vale a pena — 3–4 anos para pensar, ler, escrever e se conhecer; depois dos 21 fica quase impossível. “Não largue sem um motivo muito bom.”
A cada poucos meses, reavalie o que você faz e se está alinhado ao ritmo da AI — isso importa mais do que nunca, “porque a alavancagem que a tecnologia põe nas nossas mãos está no ponto mais alto da história”. Ele está em nabeelqu.co e @nabeelqu.
Complemento sobre design de produto na era da AI: seu app de AI é a “carruagem sem cavalo” da vez? Ensaio de Pete Koomen (partner da YC) sobre system prompts que pertencem ao usuário, agentes que leem por nós — e o que é software AI-native de verdade.
O Gmail construiu uma carruagem sem cavalo
Koomen abre com uma observação: ele gosta mais de usar AI para construir software do que de usar a maioria dos apps de AI. Construir com AI parece uma ferramenta elétrica; muitos apps parecem ter features de AI coladas — inúteis ou contraproducentes. A suspeita: são as “carruagens sem cavalo” da era da AI — ruins porque imitam o jeito antigo de fazer software e amarram, sem necessidade, os modelos com que são construídos.
O caso símbolo: a feature do Gmail de gerar e-mails com o Gemini. Ele pede um rascunho para avisar o chefe de que não vai trabalhar. O modelo devolve um e-mail “perfeitamente razoável” — que não parece nada com algo que ele escreveria. O e-mail que ele teria mandado:
“ei garry, minha filha acordou com gripe, então hoje não vou conseguir ir”
Pior: o e-mail que ele teria escrito é mais curto que o próprio prompt — ele gastou mais tempo pedindo ajuda do que teria gasto escrevendo. “O time do Gmail entregou um produto que captura perfeitamente a experiência de gerenciar um funcionário que não performa.” Milhões de pessoas concluíram que “a AI ainda não sabe escrever e-mails” — conclusão errada: o Gemini é capaz; o app é que impede.
Toda vez a mesma coisa — e o workaround é ridículo
O rascunho é prolixo, formal demais, tão “não-Pete” que o Garry acharia que é phishing. É AI slop — e todo mundo que já usou um LLM para escrever conhece a sensação. A estratégia inconsciente para driblar isso: escrever instruções cada vez mais detalhadas (“não use mais de uma linha… ignore pontuação… assine ‘pete’, não ‘Best Regards, Pete’…”).
Funciona — e é obviamente idiota: o prompt fica ainda maior que o original, e você teria que reescrever tudo isso toda vez. Existe uma solução simples que muitos apps de AI ignoram: deixe eu escrever o meu próprio System Prompt.
O que é do usuário, ao usuário
Por fora, um LLM é simples: entra um fluxo de palavras (o prompt), sai a predição das próximas (a resposta). Tudo é texto — a interface do LLM é texto. A convenção dos providers separa dois pedaços: o System Prompt (como o assistente se comporta; reusado; pense numa função) e o User Prompt (a tarefa específica; o input).
E aí vem o mapeamento velho-mundo: “naturalmente” o desenvolvedor escreve o System e o usuário escreve o User. O Google mantém o System Prompt em segredo — dá para imaginar algo como “use tom formal e businessy, com pontuação correta, para parecer que o usuário é sério e inteligente”. O problema nem é o prompt ser ruim: é eu não poder mudá-lo.
Com o “System Prompt do Pete” — 43 anos, marido, pai, programador e partner da YC; e-mails o mais curtos possível; sem pontuação desnecessária; uma linha quando dá; gentil sem ser informal — o mesmo pedido vira:
“Garry, minha filha está com gripe. Não consigo ir hoje.”
Ao escrever o meu System Prompt, estou ensinando o LLM a escrever como eu escrevo — e o ensino se reusa para sempre. O exercício proposto: pense alguns minutos em como você escreve e-mail, escreva o “System Prompt de você mesmo” e itere — a cada rascunho, você vê se sua explicação foi suficiente. “É mais fácil que ensinar um humano, porque o feedback é instantâneo e honesto.” E, de quebra: ensinar é divertido.
E quem não sabe escrever prompt? Talvez precise de ajuda no começo, mas “escrever prompt é surpreendentemente intuitivo”. E agentes não-pessoais, tipo contabilidade ou jurídico? Um System Prompt para fazer X deveria ser escrito por um especialista em X — mas os próprios especialistas vão querer escrever o deles, porque expertise é específica ao contexto. Exemplo: o time de contabilidade da YC usa um mix próprio de sistemas, convenções YC-specific e estruturas de fundo únicas — um agente one-size-fits-all seria tão útil quanto um contador que não sabe nada da YC. “É por isso que tanto de finanças ainda roda em Excel: uma ferramenta geral que aguenta um número infinito de casos específicos.”
“A maioria dos apps de AI deveria ser construtores de agentes — não agentes.”
Carruagens, middlemen — e por que o design saiu assim
Toda tecnologia nova nasce imitando a antiga: a “carruagem sem cavalo” — o design a vapor de Trevithick, de 1803 — trocou o cavalo por um motor sem redesenhar o veículo para as velocidades maiores. A quebra era invisível na época — e óbvia depois.
O mesmo acontece com apps de AI. A mentalidade velha: se você quer que um computador faça algo, há duas opções — escrever um programa ou usar o programa de outra pessoa. Como programar é difícil, a indústria inteira se construiu na suposição de que precisamos de desenvolvedores como intermediários: eles traduzem nossos desejos em código e os escondem atrás de interfaces one-size-fits-all. A divisão do trabalho: o dev decide o caso geral; o usuário fornece o caso específico. O System Prompt e o User Prompt são análogos perfeitos desses domínios antigos — daí a suposição automática de que o System é do dev.
Mas: “este assistente deveria me representar. São os meus e-mails — eu quero que sejam escritos na minha voz, não na voz de um comitê de PMs e advogados do Google.” No mundo antigo, aceitar o one-size-fits-all era a única opção — a alternativa era escrever seu próprio programa. No mundo novo, não preciso mais de intermediário: basta escrever o meu System Prompt — e escrever System Prompts é fácil.
Construtores de agentes e a camada de tools
Se os devs não escrevem os prompts, o que eles fazem?
- UIs para construir agentes de um domínio (uma caixa de entrada, um razão contábil) — com templates e “agentes que escrevem prompts” para o usuário não começar do zero;
- Uma interface de revisão e iteração: ver o trabalho do agente, ajustar o prompt, repetir — um loop de feedback rápido para ensinar o agente a executar com confiabilidade;
- Tools — o mecanismo pelo qual o agente age no mundo (enviar o rascunho para revisão, buscar e-mails antigos, checar o diretório de founders). E tools são a camada de segurança: o que o agente pode ou não fazer é definido pelo que ele tem acesso — muito mais fácil de garantir com tools escritas em código do que entre System e User Prompt, que são texto.
“Acho que vamos olhar para trás e rir” da era em que “prompt injection” era uma preocupação séria. A ideia de proteger uma parte do prompt de outra parte do prompt é sinal de que as abstrações estão quebradas: “se qualquer parte do prompt está no espaço do usuário, o prompt inteiro está no espaço do usuário.”
LLMs são ótimos em ler — e é aí que está o agente
A admissão contraintuitiva: para gerar texto, modelos generativos não são tão úteis — se os meus e-mails são tão curtos quanto o prompt que os descreve, não ganho tempo nenhum pedindo um rascunho. O que LLMs fazem brilhantemente é ler e transformar texto. Então o agente útil não é o que escreve: é o que lê a minha caixa de entrada.
Um System Prompt define o comportamento por remetente e tipo — da Sumana (esposa): rascunhar resposta, label Pessoal/prioridade; do Garry (chefe): prioridade 1; de qualquer @yc.com: YC; de founders de fora: label específico; digest de tecnologia: só label; quem quer vender: arquivar. Com tools (rotular, arquivar, rascunhar), ele processa 12 e-mails de uma vez: prioriza, mata spam (melhor que o filtro nativo do Gmail, diz ele) e deixa rascunho pronto na sua voz. Com mais tools: cancelaria listas, agendaria compromissos e pagaria contas.
Direto do ensaio: é isso que ele quer de um cliente de e-mail AI-native — “automatizar o trabalho mundano para passar menos tempo no e-mail”. E o ponto: os modelos já são bons o suficiente. “Não é falta de inteligência da AI que nos separa desse futuro — é design de app.”
AI-native: maximizar a alavancagem do usuário
Por que o Gmail fez uma carruagem? Porque partiu de adicionar AI ao cliente de e-mail que já existia — em vez de perguntar como um cliente de e-mail seria desenhado do zero com AI. Resultado: um pouco de AI enfiado numa interface projetada para o trabalho humano mundano, não para automatizar o trabalho humano mundano.
O critério do software AI-native: maximizar a alavancagem do usuário no domínio. Cliente de e-mail AI-native minimiza o tempo gasto com e-mail; software contábil AI-native minimiza o tempo fechando os livros. “É um mundo onde não gasto tempo com trabalho mundano porque agentes fazem por mim; onde foco no que importa porque o resto é deles. Não vejo a hora.”
“Eles são ruins porque imitam o jeito antigo de construir software — e amarram desnecessariamente os modelos com que são construídos.”
“A maioria dos apps de AI deveria ser construtores de agentes, não agentes.”
“Quando um agente age em meu nome, eu deveria poder ensiná-lo editando o System Prompt.”
“Não é falta de inteligência da AI que nos separa do futuro — é design de app.”
“Modelos generativos não são tão úteis para gerar texto. O que LLMs fazem de ótimo é ler e transformar.”
“Se qualquer parte do prompt está no espaço do usuário, o prompt inteiro está no espaço do usuário.”
O ensaio fecha o círculo dos outros complementos: os tools são a “camada de ação” que a a16z diz que os agentes precisam; o System Prompt do usuário é a customização que sustenta o “vender o trabalho”; e o critério — maximizar alavancagem no domínio — é o mesmo que separa o FDE de um dev shop: valor entregue, não features coladas.
O contraponto de realidade do resumão: por que a AGI não está logo ali — e por que, quando destravar, a conta muda para todo mundo. Ensaio de Dwarkesh Patel (junho de 2025) sobre o gargalo do aprendizado contínuo, o ceticismo com computer use e suas apostas 50/50.
Dwarkesh Patel: a AGI em 20 anos ou em 2?
Dwarkesh entrevista os maiores pesquisadores de AI do mundo no Dwarkesh Podcast — e este ensaio é onde ele fixa a própria posição depois de dezenas de conversas sobre timelines. Alguns convidados acham que a AGI vem em 20 anos; outros, em 2.
“As coisas demoram mais para acontecer do que você pensa — e então acontecem mais rápido do que você poderia imaginar.” — Rudiger Dornbusch, na epígrafe
O ponto de partida: às vezes dizem que mesmo se todo o progresso em AI parasse, os modelos de hoje seriam economicamente mais transformadores que a internet. Ele discorda. “Os LLMs de hoje são mágicos — mas a razão de as Fortune 500 não os usarem para transformar seus workflows não é gestão retrógrada: é genuinamente difícil extrair trabalho humano normal de LLMs.”
E não é julgamento distante: ele se considera “AI forward” e passou mais de 100 horas construindo ferramentas de LLM para a pós-produção do podcast — reescrever transcrições com legibilidade humana, achar clipes para tweet, co-escrever ensaios parágrafo a parágrafo. “São tarefas simples, curtas, de língua para língua — deveriam estar no centro do repertório dos LLMs. E eles são nota 5/10.” Impressionante, sim — mas o problema é o que falta: esses modelos não ficam melhores com o tempo.
No blog dele, a conversa continuou: Karpathy — “AGI ainda está a uma década” (out/2025); Dario Amodei — “estamos perto do fim da exponencial”; e “A ascensão e queda das civilizações de agentes”.
O saxofone, o RL e a memória que evapora
O problema fundamental: LLMs não melhoram com o tempo como um humano. Você fica preso com as habilidades que vieram de fábrica — e mexer no system prompt não produz nada perto do aprendizado de um funcionário humano.
“A razão de humanos serem úteis não é a inteligência bruta. É a capacidade de acumular contexto, interrogar os próprios fracassos e absorver pequenas melhorias e eficiências conforme se pratica uma tarefa.”
A analogia do saxofone: ensinar uma criança é dar o instrumento, ouvir o som e ajustar. Agora imagine outro método: o aluno faz uma tentativa; assim que erra, é mandado embora e você escreve instruções detalhadas sobre o erro; o próximo aluno lê as notas e tenta tocar Charlie Parker de primeira. “Isso simplesmente não funcionaria. Por mais afiado que seja o seu prompt, nenhum garoto aprende saxofone só lendo suas instruções. Mas é a única modalidade que nós, usuários, temos para ensinar LLMs.”
Existe RL fine-tuning — mas não é um processo deliberado e adaptativo como o aprendizado humano. Os editores dele ficaram extremamente bons, e não teria sido assim se ele precisasse construir ambientes de RL específicos para cada subtarefa: eles simplesmente notaram coisinhas, pensaram no que ressoa com a audiência, no que empolga o Dwarkesh, em como melhorar o próprio workflow.
Talvez um modelo mais esperto construa o próprio loop de RL (problemas verificáveis, um ambiente de treino) — “mas isso soa muito difícil”, e não há jeito óbvio de encaixar aprendizado online e contínuo nos modelos atuais nos próximos anos.
E tem o caso da sessão: um LLM fica mais útil no meio de uma sessão — depois de quatro parágrafos de sugestões ruins e um “seu texto ficou ruim, olha o que eu escrevi”, ele passa a sugerir bem. Mas esse entendimento sutil das preferências se perde no fim. Transformar essa experiência tácita num resumo de texto é frágil fora de software engineering: “até o Claude Code às vezes reverte uma otimização duramente conquistada antes de eu apertar /compact — porque a explicação de por que ela foi feita não entrou no resumo.”
Bearish no curto prazo, absurdamente bullish nas décadas
Ele discorda diretamente de Sholto Douglas e Trenton Bricken (que ele entrevistou): mesmo com o progresso parando, dados seriam suficientes para automatizar o trabalho white collar em 5 anos. Dwarkesh: “se o progresso parar hoje, menos de 25% do emprego white collar some.” Muitas tarefas se automatizam tecnicamente — mas sem melhorar com o tempo e aprender preferências, ele ainda contrata um humano para elas.
E é exatamente isso que o deixa bullish no longo prazo: quando o aprendizado contínuo for resolvido, vem uma descontinuidade enorme no valor dos modelos. Mesmo sem uma “singularidade só de software”, dá para imaginar uma explosão de inteligência amplamente deployada: AIs espalhadas pela economia, aprendendo enquanto trabalham — e, diferente de humanos, amalgamando os aprendizados entre todas as cópias.
“Um AI capaz de aprendizado online pode se tornar funcionalmente uma superinteligência rapidamente — sem nenhum progresso algorítmico adicional.”
E ele não espera um livestream da OpenAI anunciando “resolvemos o continual learning”: labs soltam inovações rápido, então veremos uma versão inicial quebrada (test-time training) antes da coisa de verdade. “Espero ter muitos avisos antes.”
“Estamos na era GPT-2 dos agentes de computador”
Sholto e Trenton preveem agentes confiáveis de computer use até o fim do “ano que vem”: você diz “faz os meus impostos” e o agente atravessa e-mail, pedidos da Amazon e Slack, troca mensagens com todo mundo que precisa mandar nota fiscal, junta recibos, decide o que é despesa, pede aprovação nas bordas e envia a declaração ao IRS.
Dwarkesh aposta contra. Três razões:
- Rollouts mais longos. Horizonte maior = o agente precisa fazer duas horas de trabalho antes de você sequer conseguir checar se fez certo — e computer use processa imagem e vídeo, que já é caro mesmo sem o rollout longo;
- Falta corpus de pretraining. “Nos acostumamos com a montanha de dados da internet — suficiente para NLP, não para agentes confiáveis. Treinar um GPT-4 com todos os textos existentes em 1980 não chegaria nem perto, mesmo com o compute.” (citação do post da Mechanize sobre automatizar engenharia de software);
- O que parece fácil demora. O procedimento de RL que o DeepSeek descreveu no R1 parece simples em alto nível — e levou ~2 anos do lançamento do GPT-4 até o o1. “Ver quanto tempo levou para implementar uma ideia simples me faz pensar que estamos subestimando o problema muito mais cabeludo do computer use.”
A régua: para computer use, estamos na era GPT-2; “fazer os impostos de uma pequena empresa” é o que o GPT-4 foi para linguagem — e do GPT-2 ao GPT-4 foram 4 anos. (Ele não diz que não haverá demos legais em 2026–27 — o GPT-3 era “super cool” e pouco útil na prática —, e sim que não serão projetos de uma semana ponta a ponta.)
Mas o reasoning é, de fato, reasoning
Depois do balde de água fria, o elogio: “não vou ser como as crianças mimadas do Hacker News que recebem uma galinha dos ovos de ouro e passam o tempo reclamando do grasnado”. Ler os traces de raciocínio do o3 ou do Gemini 2.5 “é raciocínio de verdade”: decompõe o problema, pensa no que o usuário quer, reage ao próprio monólogo interno e se corrige ao notar que pegou um caminho improdutivo.
Parte do pessimismo vem de quem não brincou com os modelos mais espertos nos domínios em que a própria pessoa é mais competente. “Dar ao Claude Code uma spec vaga e ficar 10 minutos parado até ele zerar um app funcional é uma experiência selvagem. A explicação mais próxima, concisa e precisa é simplesmente que aquilo é alimentado por uma ‘inteligência geral bebê’.”
“Em algum ponto, parte de você tem que pensar: está funcionando. Estamos fazendo máquinas inteligentes.”
As apostas — e por que as timelines são lognormais
“Minhas distribuições são super largas — e eu acredito em distribuições.” Ou seja: preparar para uma ASI desalinhada em 2028 continua fazendo muito sentido; é um outcome plausível. As apostas em que ele toparia um 50/50:
Por que “ou é nesta década, ou bust (quase)”: o progresso recente veio de escalar compute (>4x/ano) — impossível de sustentar além de 2030 por chips, energia e fração do PIB. Depois disso, o progresso teria de vir sobretudo de algoritmos — e as frutas mais baixas também acabam. Resultado: a probabilidade anual de AGI cratera depois. Se ficarmos no lado longo das apostas, dá para imaginar um mundo relativamente normal até os anos 2030 ou 2040; em todos os outros mundos, mesmo sóbrios sobre as limitações atuais, dá para esperar resultados de verdade loucos.
Os comentários: discordância fina e discordância de fundo
Mediana dele para a explosão de inteligência: 2028 (um ano a mais que o AI 2027). O único desacordo sério é o continual learning. Argumento: ao chegar no “superhuman coder”, o ritmo de progresso algorítmico acelera → automação completa de P&D → acelera mais. Então inovações que “parecem de 2032” chegam no mesmo ano — com estágios intermediários toscos (fine-tuning empilhando dados reais do trabalho toda semana, depois todo dia).
Também ~2032 para as coisas ficarem loucas; concorda que sem progresso não há automação massiva do white collar. Mas: humanos aprendem no trabalho com algo análogo a um update de RL — notar o que deu certo/errado e atualizar de forma sample-efficient. O que falta aos AIs são duas coisas quantitativas (e melhorando): self-verification robusta e sample efficiency. Bônus: “vamos ver P&D de AI totalmente automatizado antes de igualar a sample efficiency humana — e, se igualarem com compute comparável, já temos compute para AIs vastamente superhumanas.”
As frases do ensaio
“As coisas demoram mais para acontecer do que você pensa — e então acontecem mais rápido do que você poderia imaginar.”
“A razão de humanos serem úteis não é a inteligência bruta.”
“É a única modalidade que nós, usuários, temos para ensinar LLMs.”
“Um AI com aprendizado online pode virar funcionalmente uma superinteligência rapidamente.”
“Estamos na era GPT-2 do computer use.”
“As timelines de AGI são muito lognormais: ou é nesta década, ou bust.”
Este é o contraponto de realidade dos outros complementos: se o aprendizado contínuo é o gargalo e o computer use está na “era GPT-2”, a automação ponta a ponta ainda precisa de gente por perto — e é nessa brecha que o FDE, o “vender o trabalho” e a captura de contexto vivem hoje. No dia em que o gargalo cair, a conta muda para todo mundo: a “explosão amplamente deployada” deixa de ser hipótese.