01 · já caiu
Escrever
Agente digita. Tokens têm preço. Tempo humano, não.
Laurie Voss · Arize AI · AI Engineer
Agentes escrevem oito vezes mais código e o time só entrega um terço a mais. A palestra pergunta o que o humano ainda faz quando a digitação some. Os comentários perguntam se a vaga que sobra cabe em todo mundo.
Abrir a palestra01 · já caiu
Agente digita. Tokens têm preço. Tempo humano, não.
02 · este mês
Humano lê ~450 linhas/hora. Diff de 10 mil linhas pede uma semana.
03 · 5–10 anos
Deploy, escala, o sistema no ar. Muito dado humano; ainda não está escrito.
04 · 5–10 anos
Segurança, privacidade, o agente não sair dos trilhos.
05 · a aposta
Falar com quem tem o problema. Escrever o spec. Delight.
A tese
Há três anos Swyx descreveu o AI engineer: quem empilha produto com modelo, sem ser pesquisador. Laurie diz que isso já é estreito. Todo engenheiro está virando outra coisa, e nem todo mundo vai gostar da notícia.
O motor da mudança é simples: agente tornou escrever código “de graça” na escala do salário. Tudo que vem depois — review, ops, segurança, gosto — não ficou de graça no mesmo dia. O gargalo andou.
Ele usa Goldratt (The Goal, 1984): um sistema tem um gargalo; acelerar o que não é gargalo não acelera o sistema. Quando o gargalo some, ele só muda de lugar. Review hoje. Ops e segurança depois, em cinco a dez anos, não em doze meses, apesar do coral “AGI 2027”.
A aposta de dez anos: o que o agente não come é achar o que a pessoa quer, escrever o que “resolvido” significa, e fazer isso ser gostoso de usar. Esse conhecimento não está nos pesos. Está na cabeça de quem toca a padaria, a autopeça, a fábrica. Só sai conversando — “flapping your meat parts”, no original.
Código é uma projeção com perda da especificação. Quem escreve o spec vira o programador. Shawn Grove, OpenAI — citado na palestra
Os números da palestra
Laurie avisa que tem 18 minutos, uma pilha de citações nos slides e vai jogar número com um “trust me, bro”. Abaixo, o que ele falou — não o paper por trás.
Quatro revisores de IA acharam bugs de verdade e não concordaram em nenhum bug individual. Dexter Horthy passou seis meses dizendo para não ler o código e voltou ao palco: foi desastre, teve que trocar sistema inteiro. Amazon ligou outage a slop de agente e agora senior assina review. Anthropic publicou postmortem de bug que passou por humano e máquina.
Claude passa ~80% de um benchmark padrão de testes. Troque a pergunta para “você, maintainer, mesclaria?” e o número cai. O que o maintainer acrescenta é o senso de bom: estilo, efeito colateral, sistema de fora, história que não está no repo.
Brooks, 1986
Fred Brooks separou dificuldade acidental (linguagem, syntax, ferramenta) de dificuldade essencial (o problema em si). Previu que nenhuma ferramenta sozinha daria 10× de produtividade. Laurie: geramos código 8× mais rápido e quase não aceleramos o shipping. A parte difícil continua sendo a essencial.
O corolário para quem treina modelo: tudo que dá para verificar barato dá para treinar contra até bater. Por isso ele acha que ops e segurança eventualmente saem do gargalo humano — dá para escrever. Por isso o “bom” de um calendário versus o “bom” de um agendador não transfere, mesmo sendo quase o mesmo problema. Jira com um zilhão de configs e ainda assim errado é o sintoma.
Andrew Ng ouviu de um time a proposta de ter o dobro de PMs que de engenheiros. A resposta dele não foi contratar PM: foi misturar o ofício. Engenheiro que entende o usuário decide o que construir e constrói. Nos anos 1960 isso se chamava systems analyst. Virou PM + engenheiro. Laurie diz que as duas profissões estão colapsando de novo numa só: product engineer.
Gergely Orosz descreveu o “product-minded engineer” em 2019 como traço bom de ter. Agora, diz Laurie, deixou de ser bônus e virou o próprio cargo. E ele admite a armadilha de todo mundo em AI land: “tudo se automatiza, menos o que eu sou bom”. Pede para contestarem.
O ofício que sobra
Universidade ensina estrutura de dados. Bootcamp ensina React. Ninguém ensina isso. IBM já redesenha o cargo de entrada em torno de conversar com cliente e escrever spec, não de programar.
Ticket bem especificado: escreve deste jeito e me devolve para eu listar o que você errou. Esse loop foi para o agente. O mercado já parou de contratar a faixa 22–25. A escada sumiu antes de existir o curso novo.
Quem entrou pelo gosto da abstração limpa e do bug que cede não assinou para entrevistar padeiro. Sem prêmio de consolação. Observação: talvez o que você amava fosse o instante antes de digitar, quando o problema fecha na cabeça. Isso não some. A marcenaria sobreviveu à fábrica de móveis. Só deixa de pagar seis dígitos por ano para você tornear sozinho.
Predição de dez anos: profissão maior que a de hoje, paga parecido, majoritariamente em forma de engenharia de produto. Compilador, framework, open source cada um matou uma geração de digitação e saímos com mais desenvolvedores — mudando o que a palavra quer dizer.
O que fazer esta semana
01
Humano revisa só o código de alto impacto. O resto, revisor automático quando ele ficar bom o bastante.
02
Tudo que dá para checar barato vira eval e vai para o agente. Não invente processo de review humano para o que uma rubrica resolve.
03
O que está só na cabeça do melhor do time vira spec, rubrica, eval. Esse é o trabalho do product engineer.
04
Produção. 741% mais código nunca foi o ponto. Meça o que saiu, se o comentário do review virou ação, e o fosso entre “passou no teste” e “o maintainer mesclaria”.
A plateia no YouTube
Coleta da API em 28/10/2026: 107 fios e 26 respostas (o YouTube conta ~225). Soma de likes baixa — conversa densa, não viral. Abaixo, o que se repete, não o recorte fofo.
20 likes · o comentário mais respondido
@matrinoxtm corta o pulo da palestra: Laurie admite que o agente não tem senso de bom e, no mesmo fôlego, assume que review, ops e segurança caem. LLMs não generalizam; a cauda de Zipf (os casos raros somados) é a maior parte dos casos. Mais regra e mais dado é batalha infinita. Respostas no fio: no nível baixo dá para checar consistência e bug comum, e a plateia vai aceitar perder esperteza no review em troca de velocidade (@pixelprizm). A barra de qualidade já baixou — o mercado topa pior se for bem mais barato (@dims4627). Fine-tune de domínio “resolve” (@LuxxVibin). “Bom” é contextual ou subjetivo, e talvez nunca formalize elegância.
Fio de @matrinoxtm · 5 respostas
20 likes
@ovidiudonciu580: todo mundo trata review como se, resolvido o gargalo, a qualidade do produto estivesse resolvida. @Lostarts1 completa: 30% mais “produtividade” com 8× código aponta dívida técnica, não ROI. Ninguém pergunta se o software ficou mais estável, se o gasto com token se paga, se o burnout (Harvard, citado no fio) come o ganho. Executivo quer mais e mais rápido e descarta o resto.
@ovidiudonciu580 + @Lostarts1
19 likes · a tese da cadeira
@4pp1e5auc3: product engineer já existe com outro nome. Não é promoção automática. No ideal, a demanda por software explode (Jevons) e o deslocado acha FDE em empresa nova. “Dez anos de dor soam certos.” @mk8054-r3u desenha o cenário feio: 80% layoff, 10% tocando IA, 10% virando PM. Sem mais projeto de cliente, não há para onde transformar o time.
@4pp1e5auc3 · @mk8054-r3u · @tsoier (Jevons ou colapso)
avião mais pesado
@chriswellsx: se o agente escreve cinco ou seis vezes o código necessário, o número não mede gargalo de leitura — mede avião mais pesado. @e-vd propõe o antídoto operacional: peça um dia de código humano, gaste meio dia revisando, +25% de shipping sem criar um problema que a semana não resolve. @amazingjoe76, o atalho cínico: pule o review e o gargalo vira incidente em produção. @MadMathMike viu no slide “incidents per PR +240%” — mais bug por entrega, não só mais entrega.
@chriswellsx · @e-vd · @MadMathMike
review não cai tão cedo
@jaspervanderstoop2035: geração melhorou e ainda depende de input. Review de IA acerta cheiro e bug e erra o resto; se o critério de aceite está furado, o review também. Agente continua campeão de abstração inchada, “mesmo com skill tipo Ponytail”. O ofício desloca para análise e refinamento. Outro fio: a IA só não tem ideia de simplicidade — não segue Occam (@avinashsuresh5221, lista de 7 checagens humanas).
@jaspervanderstoop2035 · @avinashsuresh5221
júnior e PM
@SuperPranx recusa o retrato do júnior como ticket-monkey: os que ele mentorou pensavam. @troygooden2525 mostra o treino novo na prática (intern no complexo, IA no resto, spec e teste juntos). Do outro lado, @Anagrit (BA/UX/PM): “você diz que o nosso cargo não some porque você não está nele”. Dono de negócio já gera spec de aparência em segundos e empurra segurança e escala para engenharia. @VolodymyrFrolov: a IA come product engineering no almoço — quem está falando com o cliente agora é o modelo. @leobarros20: PM pensa em ciência social, engenheiro em sequência; o switch de mente é duro para quem já está na carreira.
@SuperPranx · @Anagrit · @VolodymyrFrolov · @leobarros20
o gargalo que a palestra quase não nomeia
@grzegorz__ descreve a casa de software invertida: 5 devs, 2 QA, 1 UX, 3–4 “PMs” numa escada que não entrega produto. Em casa, vibe-coda em uma hora. No trabalho, dias de “clarificar” o que o ticket não clarificou. Conclusão dele: quem decide tem que ser quem constrói (CEO ou PM que code). Automatizar uma Anthropic com spec nítida é uma coisa; automatizar duas empresas que precisam se adaptar uma à outra é outra. @danherman212nyc pede chão: cabeleireiro/banco/governo como sites ruins é “adrenalina sem substância” — banco e trânsito de NYC já eram sistemas apertados antes do hype. @nexus888 lembra o nome antigo: solution architect. @TheLXRGroup propõe outro: handler.
@grzegorz__ · @danherman212nyc · @nexus888
O que fica de pé
A palestra acerta o diagnóstico de agora: o teclado deixou de ser o gargalo, o review humano não escala no diff de agente, e “passou no teste” não é “eu mesclaria”. A plateia acerta o pulo: “bom” não formalizado não autoriza assumir que review, ops e o próprio cargo de produto caem na sequência; e a cadeira de product engineer já está ocupada, então o desenho otimista (todo programador vira isso) precisa de demanda infinita de software — o efeito Jevons — ou vira enxugamento.
O recado operacional que sobrevive aos dois lados: não peça ao bot mais código do que você consegue julgar; escreva o juízo (spec, rubrica, eval); meça o que saiu e o que quebrou, não o LoC; trate júnior como gente que aprende o ofício novo, não como agente de carne. Laurie fecha: “we are all product engineers now.” Os comentários respondem: nem todos, e a vaga não é infinita.