A IA escreve o código. O que sobra para os engenheiros? — Laurie Voss, Arize AI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: AI Writes the Code. So What’s Left for Engineers? - Laurie Voss, Arize AI · Canal: AI Engineer · 26:55 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA

Resumo

Laurie Voss argumenta que agentes de IA estão tornando a escrita de código muito barata, deslocando os gargalos do desenvolvimento para etapas como revisão, operações e segurança. Em sua previsão, o trabalho humano acabará concentrado em descobrir o que as pessoas precisam, definir o que significa um bom resultado e transformar esse entendimento em especificações que os agentes possam executar. Voss chama esse perfil de product engineer e alerta que a profissão precisa repensar como formar profissionais iniciantes, já que as tarefas tradicionalmente usadas para treiná-los estão sendo automatizadas. Ela recomenda automatizar verificações, registrar o conhecimento de especialistas em specs, rubrics e evals e medir o que realmente chega à produção.

Pontos-chave

Agentes autônomos podem aumentar muito a quantidade de código produzido, mas isso não se traduz na mesma proporção em software entregue.
A revisão de código é um gargalo atual porque o volume gerado pelos agentes excede a capacidade de análise humana.
Resolver um gargalo desloca o problema para a próxima etapa, como operações, escalabilidade ou segurança.
O trabalho que Voss considera mais difícil de automatizar é entender as necessidades específicas de cada cliente e definir o que significa resolver bem o problema.
O perfil chamado product engineer combina entendimento dos usuários, definição do produto e entrega de software com agentes fazendo a digitação.
A queda na contratação de profissionais iniciantes põe em risco a formação da próxima geração de engenheiros.
Empresas e equipes precisarão ensinar iniciantes a conversar com clientes e escrever especificações, em vez de depender apenas de tarefas de programação bem delimitadas.
Voss recomenda registrar o julgamento de especialistas em specs, rubrics e evals, automatizar verificações baratas e medir entregas reais, não apenas o volume de código.

Capítulos

Início	Capítulo	Resumo
00:01	A escrita de código deixa de ser o gargalo	Voss afirma que os agentes tornaram a produção de código muito barata e que a revisão passou a limitar a velocidade de entrega.
03:09	Os limites da revisão automatizada	A palestra examina a dificuldade da revisão humana, as limitações dos revisores automáticos e os riscos de deixar código passar sem revisão adequada.
07:48	O gargalo se desloca	Com base na teoria das restrições, Voss prevê que, depois da revisão, operações, escalabilidade e segurança também poderão se tornar gargalos.
10:22	O valor de entender o problema	Voss argumenta que a demanda por software é ampla e que descobrir as necessidades concretas dos usuários e definir o que é bom continua sendo essencial.
14:00	Da programação à engenharia de produto	A palestra apresenta a distinção entre complexidade acidental e essencial e propõe que engenheiros combinem compreensão dos usuários com entrega apoiada por agentes.
19:41	O desafio de formar profissionais iniciantes	Voss alerta que a automação das tarefas tradicionalmente dadas a iniciantes pode enfraquecer a formação de novos product engineers.
22:49	O futuro da profissão e recomendações práticas	A palestra reconhece a perda do trabalho artesanal de programação, prevê uma profissão mais voltada a produto e recomenda registrar critérios e medir entregas reais.

Citações

O custo de produzir código plausível desabou, enquanto o custo de saber se esse código merece confiança permaneceu exatamente o mesmo. — 04:12

O gargalo passa a ser descrever o problema e definir o que significa tê-lo resolvido. — 13:29

Essa pessoa descobre do que as pessoas precisam, define como é um bom resultado e entrega com agentes fazendo a digitação. — 17:06

Transformar a compreensão do problema em uma especificação para que os agentes possam construí-lo para nós. — 25:55

Descobrir do que as pessoas precisam, registrar o que significa fazer bem e criar algo de que elas gostem: esse é o trabalho agora. — 26:25

Conceitos e entidades

Laurie Voss (pessoa): Palestrante que apresenta sua visão sobre como agentes de IA podem transformar o trabalho de engenharia de software.
Arize AI (empresa): Empresa identificada no título da palestra como vinculada a Laurie Voss.
AI Engineer (empresa): Canal do YouTube que publicou o vídeo da palestra.
Agentes de codificação autônomos (conceito): Agentes que produzem código e podem deslocar o gargalo do desenvolvimento para etapas posteriores.
Revisão de código (conceito): Etapa de avaliação das alterações de código que, segundo Voss, se tornou um gargalo diante do aumento de produção por agentes.
Teoria das restrições (conceito): Ideia de que sistemas têm gargalos e que, ao resolver um, a restrição tende a migrar para outra etapa.
The Goal (conceito): Livro de Eliyahu Goldratt citado pela palestra ao explicar a teoria das restrições.
Complexidade essencial (conceito): Dificuldade inerente ao problema que o software precisa resolver, em contraste com as dificuldades acidentais das ferramentas e linguagens.
Product engineer (conceito): Perfil profissional proposto por Voss, que identifica necessidades, define critérios de qualidade e entrega software com apoio de agentes.
Forward deployed engineer (conceito): Cargo citado como próximo do perfil de product engineer, com crescimento expressivo de vagas em 2025 segundo a palestra.
evals (conceito): Avaliações que podem ajudar a verificar se o software atende aos critérios definidos e observar seu comportamento em produção.
GitHub Copilot (ferramenta): Assistente de programação citado como responsável por uma parcela das revisões de código no GitHub.
Devin (ferramenta): Agente de codificação desenvolvido pela Cognition, mencionado na discussão sobre benchmarks de revisão.
BugBot (ferramenta): Revisor da Cursor que, segundo a palestra, transforma avaliações negativas da equipe em regras.
Cursor (empresa): Empresa cujo revisor BugBot é citado como exemplo de conhecimento de manutenção registrado em regras.
Cognition (empresa): Empresa que desenvolveu Devin e um benchmark que avalia se um mantenedor aceitaria integrar um PR.
Eliyahu Goldratt (pessoa): Autor de The Goal e criador da teoria das restrições, conforme apresentado na palestra.
Fred Brooks (pessoa): Autor de The Mythical Man-Month, citado por sua distinção entre complexidade acidental e essencial.
Andrew Ng (pessoa): Pesquisador citado por defender que engenheiros entendam os usuários e participem das decisões sobre o que construir.
Swyx (pessoa): Autor do ensaio The Rise of the AI Engineer, usado como ponto de partida para a tese da palestra.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é Laurie. Sou chefe de relações com desenvolvedores na Rise AI. Em uma vida passada, cofundiei a NPM Inc. Então, talvez alguns de vocês se lembrem de mim dos tempos do JavaScript. Mas, hoje em dia, penso em agents de IA e, neste caso, no que eles estão fazendo com nossos empregos. Há pouco mais de três anos,

00:32 Swyx escreveu um ensaio chamado “A ascensão do engenheiro de IA”, e seu argumento era que, quando se trata de lançar produtos de IA, você quer engenheiros, não pesquisadores. Acho que essa mensagem repercutiu em todo mundo, especialmente nas pessoas que vêm a esta conferência. E, por isso, ele criou o cargo de engenheiro de IA, e as empresas passaram a contratar para essa função. E parte do que vim fazer hoje é convencê-los de que, na verdade, ele não foi longe o suficiente. Não está acontecendo apenas uma revolução do engenheiro de IA.

01:04 Está acontecendo uma revolução para todo tipo de engenheiro. Todos os empregos de engenharia estão sendo substituídos por um novo tipo de trabalho, e nem todo mundo vai ficar feliz com essa notícia. A mudança fundamental que deu início a tudo isso é que os agents tornaram a escrita de código basicamente grátis. Quer dizer, você paga pelos tokens, mas, em comparação com o custo do tempo que isso costumava levar, é basicamente grátis. Tudo o que vem depois da escrita do

01:34 código não ficou grátis ao mesmo tempo. Então, o gargalo deixou de ser “escrever código é muito lento, e todo o resto acontece mais ou menos na mesma velocidade” e passou a ser “escrever código é super-rápido, e agora ficamos travados por causa de coisas novas”. Então, neste exato momento, neste mês, a primeira coisa que está nos travando é a revisão de código. Mas minha tese é que não vai parar por aí. Vamos descobrir como automatizar a revisão de código. Vamos fazer a revisão de código acontecer na velocidade dos agents e, então, vamos

02:04 esbarrar em outro gargalo, e em mais outro, e em mais outro, até que, em algum momento, vamos parar. Vamos chegar a um gargalo que não conseguiremos superar. E é isso que vai restar para os humanos fazerem: seja lá qual for o gargalo que não conseguirmos fazer os agents superar. Então, estou apostando que consigo pensar em algo que os agents realmente não serão capazes de fazer. E, quando chegarmos a esse gargalo, vamos ter que descobrir como treinar a próxima geração de engenheiros para que consiga fazer esse trabalho, porque não estamos treinando as pessoas

02:36 para fazer esse trabalho agora. Então, um rápido aviso — ou pedido de desculpas. Tenho 18 minutos, porque é esse o tempo que o Swyx dá para as palestras. E tenho uma pilha enorme de dados. Fiz uma tonelada de pesquisas para isso. E não tenho tempo de apresentar tudo a vocês. Não tenho tempo para citar minhas fontes e fazer todas essas coisas. Então, vou simplesmente jogar números para vocês, com um monte de citações nos slides, e vou ter que pedir que confiem em mim, cara. >> [risos] >> Então, os desenvolvedores que passam a usar agents de programação autônomos escrevem 741%

03:09 mais código, oito vezes mais. Mas eles lançam produtos apenas 30% mais rápido. Quer dizer, 30% mais rápido não é pouca coisa. É incrível. Estamos lançando muito mais código do que antes, mas, considerando que estamos escrevendo oito vezes mais código, lançar de fato apenas um terço a mais é meio ruim, certo? Isso significa que estamos travados em algum lugar. E estamos travados na revisão de código. E o motivo é que os humanos não conseguem simplesmente revisar mais rápido. A Cisco fez um estudo enorme há 20 anos sobre a velocidade com que você

03:41 consegue fazer uma revisão de código e a precisão com que consegue fazê-la. E acontece que a capacidade dos humanos de entender o que está acontecendo no código cai drasticamente depois de cerca de 450 linhas de código por hora. Então, se você produziu um diff de 10 mil linhas com seu agent, levaria mais ou menos uma semana para revisar esse código de forma razoável. E a resposta é que ninguém está fazendo isso de verdade, certo? Porque hoje em dia todos nós estamos espalhando diffs de 10 mil linhas por aí a torto e a direito.

04:12 Fiz uma palestra inteira sobre esse fenômeno em uma AIE anterior, chamada “A morte da revisão de código”. E, se quiserem todas as informações sobre a morte da revisão de código, podem assistir àquela palestra. Mas o problema que enfrentamos agora — que não é o mesmo problema que estou tentando resolver com esta palestra, de modo geral — é que o custo de produzir código plausível despencou, enquanto o custo de saber se esse código é confiável permaneceu exatamente igual. Então, a medida óbvia para a revisão, como eu disse, é deixar as máquinas fazerem a revisão.

04:43 E isso já está acontecendo. O Copilot do GitHub faz mais de uma em cada cinco revisões de código no GitHub, segundo dados do mês passado. Se quiser, você pode optar por deixar o Copilot ser o revisor final antes de algo ir para produção. Você pode dar a ele o poder de aprovação, se quiser, o que é loucura. Não sei quem está ativando essa opção, mas você pode fazer isso, se quiser. A OpenAI diz que, na OpenAI, humanos podem revisar os pull requests, mas

05:13 não são obrigados a fazê-lo. Mas o problema é que os revisores de máquina ainda não são muito bons. Os dados que encontrei mostram que colocaram quatro revisores de IA à prova, e todos encontraram vários bugs, mas nenhum dos mesmos bugs. Eles não concordaram em nenhum bug específico. Todos encontraram problemas reais no código. Todos encontraram problemas diferentes no código. Então, vale a pena executá-los, mas, se você leva isso a sério, nunca vai executar apenas um deles.

05:44 Porque eles ainda não são confiáveis o suficiente. E houve algumas pessoas que foram até o fim. Elas disseram: “Não vou mais revisar o código. Vou simplesmente presumir que meu agent vai acertar perfeitamente de primeira.” Dexter Horty, que está aqui — não sei se está na plateia, provavelmente não — passou seis meses dizendo às pessoas para não lerem o código. Depois desses seis meses, subiu ao palco e disse: “Não, eu estava errado. Na verdade, não dá para pular completamente a revisão de código. Tentamos. Foi um desastre. Tivemos que substituir sistemas inteiros.”

06:15 Isso não é uma opção. Os agents não são bons o suficiente. Eles não acertam o código de primeira. A Amazon teve uma série de interrupções, fez análises posteriores e concluiu que isso aconteceu porque seu agent de programação havia produzido um monte de código ruim, que foi lançado sem pensar. Então, agora não deixam mais que façam isso. Na Amazon, engenheiros seniores precisam aprovar as revisões de código. E a Anthropic publicou uma análise posterior sobre bugs que passaram por todos os revisores que tinham, tanto humanos quanto

06:45 máquinas. Então, o problema é que as automações que criamos até agora para verificar se nosso código é bom o suficiente não são boas o suficiente. Claude Fable 5 passa nos testes em 80% de um benchmark padrão de programação. E a Cognition, fabricante do Devin, criou um benchmark que faz uma pergunta diferente, que não é “ele passa nos testes?”. A pergunta é: “Você, como revisor e mantenedor deste repo, faria merge deste PR?”. E, se você fizer essa pergunta, em vez disso, a taxa de aprovação cai

07:17 de 87% para 54%. Isso acontece porque há muitas informações adicionais envolvidas na decisão de fazer merge. Há o estilo do código, os efeitos colaterais, os sistemas externos, o histórico que não está codificado na base de código. Está codificado no cérebro do mantenedor. Então, o que o mantenedor está acrescentando — e comprovadamente acrescenta — é algo que ainda não demos aos agents. Há informações que eles

07:48 não têm; há uma skill que eles não têm. E ela é a noção do que significa ser bom. É isso que nós… É isso que os agents ainda não têm. E essa é uma percepção crítica à qual vou voltar. Eliyahu Goldratt, se estou pronunciando corretamente, era um físico que se tornou um guru da administração e, em 1984, escreveu um romance sobre administrar uma fábrica. Isso parece um romance interessante para vocês? Ele se chama The Goal. E a grande ideia dele era a teoria das restrições. Todo sistema tem um

08:20 gargalo, e acelerar as coisas não funciona, a menos que aquilo que você está acelerando seja o gargalo. Esse é o nosso problema com a revisão de código. Aceleramos a escrita do código, mas não aceleramos a revisão. A segunda ideia dele é a que importa hoje: quando você resolve o gargalo, ele não desaparece; apenas muda de lugar e encontra outro gargalo para se acumular. Então, vamos supor, apesar de tudo que eu disse sobre como os revisores de código são ruins agora, que descobrimos como resolver isso, que elevamos a revisão de código automatizada a um padrão mais alto e deslocamos esse gargalo.

08:51 Qual é o próximo gargalo que ela vai encontrar? Se resolvermos a revisão, o próximo gargalo provavelmente será operações. Como faço o deploy disso? Como aumento a escala? E depois provavelmente vamos esbarrar em segurança. Como faço para deixar isso seguro em grande escala? Como faço para garantir que isso seja privado? Como faço para garantir que não saia completamente dos trilhos? Mas vou fazer — e esse é o

09:21 grande salto que estou dando nesta palestra — a suposição de que também resolvemos essas coisas, porque elas são muito bem resolvidas por humanos. Existe uma quantidade enorme de dados sobre elas. Se conseguirmos descobrir como fazer operações, escalar e cuidar da segurança usando agents cada vez mais avançados, o que nos resta fazer? Qual é o papel de um humano nessa situação? Essa também é uma grande pergunta

09:52 e é uma pergunta de longo prazo. Não estou dizendo o que vai acontecer nos próximos 12 meses. Nos próximos 12 meses, acho que provavelmente vamos avançar de verdade na revisão de código. Não acho que, daqui a 12 meses, teremos resolvido operações, escala e segurança. Acho que isso vai levar de 5 a 10 anos. Apesar das pessoas que dizem: “AGI em 2027”. Não, vamos avançar nisso aos poucos, de forma iterativa. Mas a outra suposição necessária para que minha tese esteja

10:22 correta é que a quantidade de software de que precisamos é efetivamente infinita. E acho que esse argumento é bem mais fácil de defender. Pense em todos os sites que você já encontrou no mundo, em produção, e provavelmente eles são bem ruins. E a razão de serem ruins não é que não saibamos criar sites realmente excelentes. O problema é que não há pessoas suficientes para deixar bons todos os sites. Toda vez que você se depara com um site terrível no cabeleireiro, no governo ou, sabe, no seu banco, não é porque não exista alguém que saiba deixar esse

10:52 site bom. É porque, primeiro, é muito caro deixá-lo bom; e, segundo, as pessoas que poderiam fazer isso estão ocupadas com outras coisas. Provavelmente lançando agents de IA. Então, suponha que possamos criar quanto software quisermos, basicamente de graça, e que a vontade de criar software seja, na prática, infinita. Essa é uma situação maravilhosa. Temos demanda infinita e, de repente, também oferta infinita. Onde acaba ficando o gargalo? O que achamos que os agents não vão assumir? Para tentar descobrir

11:25 isso, dividi o trabalho de desenvolvimento de software no maior número de partes que consegui imaginar e as ordenei pela rapidez com que os agents vão chegar a elas. A escrita de código já entrou em colapso; revisar e manter código vai acontecer em breve. Lançar em produção e escalar são os próximos na lista, embora ainda não haja muitos dados sobre isso. E então há as coisas que acho que provavelmente estão a salvo: decidir o que construir, definir o que significa ser bom e, por fim, torná-lo encantador. O que resta é descobrir o que as pessoas

11:56 realmente querem. Cada software é a formalização de algo que uma pessoa queria fazer. Então, se um cliente diz: “Preciso acompanhar meus pedidos”, existem 10.000 softwares que acompanham pedidos. É isso que eles fazem. Mas, se você tiver sorte, apenas um deles será bom para o seu caso, se o que você faz é administrar uma padaria. Se você administra, por exemplo, uma loja de autopeças, será diferente. Se você administra, sabe,

12:27 uma enorme empresa de manufatura, será completamente diferente. Esse requisito não é suficiente. O trabalho todo é descobrir o que exatamente você quer dizer quando diz que quer acompanhar seus pedidos. O que isso significa para a sua empresa? O que o software precisa fazer? Como isso funciona? E esse conhecimento não está nos dados de treinamento. Não está nos pesos. Está na mente de quem administra a empresa. E a única maneira de extraí-lo é mexendo as partes de carne diante dessa pessoa e fazendo com que ela mexa as partes de carne de volta. Ou seja, você precisa conversar com

12:57 ela. Essa é a única maneira de obter a informação. E esse trabalho tem uma propriedade muito importante: ele não se transfere. Se você pensar no que significa ser bom para um aplicativo de calendário e no que significa ser bom para um aplicativo de agendamento, eles resolvem quase o mesmo problema, certo? Um aplicativo de calendário e um aplicativo de agendamento, mas são softwares completamente diferentes. Eles têm requisitos totalmente diferentes e definições de qualidade totalmente diferentes, mesmo que esses dois casos de uso sejam tão próximos. E temos zilhões de casos de uso. Sempre que você usa um software que

13:29 tem zilhões de opções de configuração e, ainda assim, não faz o que você precisa, estou falando com você, Jira. Esse é o problema que você encontra em softwares que tentam fazer tudo e ainda assim não conseguem. Então, o gargalo passa a ser descrever o problema e definir o que significa resolvê-lo, e minha grande aposta para esta palestra e para os próximos 10 anos é que é aí que ele vai permanecer. Fred Brooks, que dirigiu o projeto IBM System 360 e escreveu The Mythical Man-Month, escreveu sobre isso em 1986. Ele dividiu a dificuldade do software em dois tipos. A complexidade acidental é a dificuldade das ferramentas ou das linguagens, da digitação, da sintaxe; depois, há a complexidade essencial, que é a dificuldade do próprio problema. E ele previu que nenhuma ferramenta isolada nos tornaria 10 vezes mais produtivos, porque a parte essencial é a parte difícil. E a previsão de Brooks parece bem acertada, porque deixamos o código oito vezes mais rápido e ainda não ficamos

14:00 e escreveu The Mythical Man-Month; ele escreveu sobre isso em 1986. Ele dividiu a dificuldade do software em dois tipos. A complexidade acidental é a dificuldade das ferramentas ou das linguagens, da digitação, da sintaxe; depois, há a complexidade essencial, que é a dificuldade do próprio problema. E ele previu que nenhuma ferramenta isolada nos tornaria 10 vezes mais produtivos, porque a parte essencial é a parte difícil. E a previsão de Brooks parece estar se confirmando, porque fizemos o código ficar oito vezes mais rápido e ainda assim não conseguimos

14:30 muito mais rápidos para lançar software, porque a parte difícil é a parte essencial. Shawn Grove, da OpenAI, fez a mesma observação há dois anos. Não, desculpe, há um ano. Que ano é esse? Ele disse que o código é uma projeção com perda da especificação e que quem escreve a especificação, seja um PM, um legislador, um engenheiro ou um profissional de marketing, passa a ser o programador. Portanto, escrever o que significa ser bom é onde está o valor agora.

15:02 Estou começando a ficar sem tempo porque não cronometrei isso direito. Qualquer coisa que você consiga verificar de forma barata, você pode usar como alvo de treinamento até superar, se for quem cria o modelo. Então, a Cognition tentou definir por escrito, com base no benchmark deles, o que conta como algo pronto para ser integrado: esse código pode ser integrado? Eles pensaram: “Vamos ver se conseguimos criar um benchmark que defina o que realmente significa estar pronto para integração. Vamos ver se conseguimos incluir no benchmark todas essas outras informações. Aí podemos

15:33 treinar um modelo com isso. O BugBot, revisor do Cursor, transforma cada voto negativo que sua equipe dá em uma regra, e agora eles têm umas 44 mil regras. Então, no momento em que a pessoa responsável pela manutenção tira o conhecimento da própria cabeça e o coloca em algum lugar escrito, onde um modelo possa ser treinado com ele, [risos] o gargalo muda de lugar novamente. É por isso que acho que segurança pode desaparecer. É por isso que acho que operações pode desaparecer. Acho que, eventualmente, podemos colocar essas coisas no papel, embora ainda não tenhamos feito isso. Então…

16:05 Andrew Ng, cofundador do Google Brain e da Coursera, diz que alguém da equipe dele propôs ter o dobro de gerentes de produto em relação ao número de engenheiros, e ele disse que essa era a primeira vez na vida que ouvia uma proposta assim. Mas, desde então, a resposta dele não tem sido contratar mais gerentes de produto. É misturar as funções. Nas palavras dele, quando um engenheiro entende os usuários, consegue decidir o que construir e construir diretamente, pode executar com uma rapidez incrível. E acho que estamos começando a encontrar a resposta aí. Nos anos 1960, havia uma função chamada…

16:36 analista de sistemas. O trabalho dessa pessoa não era escrever código. Era conversar com a empresa e descobrir qual era o problema. Depois, essa função de analista se transformou no que hoje chamamos de gerente de produto, e passamos a ter duas profissões onde antes havia uma e meia. Acho que o que está acontecendo é que elas estão se fundindo de novo em uma só. Estamos voltando aos anos 1960. Então, essa pessoa não é um engenheiro de IA. Não está apenas criando IA. Não está apenas criando com IA. Está criando tudo. Está criando…

17:06 todo tipo de software. E decidi chamar essa função de engenheiro de produto. É alguém que descobre do que as pessoas precisam, define o que significa fazer um bom trabalho e entrega o produto, com agents fazendo a digitação. Gergo Orosz — provavelmente pronunciei o nome dele errado — escreve o boletim The Pragmatic Engineer. Em 2019, ele descreveu o engenheiro com mentalidade de produto como uma qualidade desejável em um engenheiro. E o que estou dizendo agora é que isso deixou de ser desejável e se tornou essencial. Deixou de ser…

17:37 uma habilidade que engenheiros seniores costumavam ter e passou a ser uma habilidade que todo engenheiro precisa ter para ser engenheiro. E já dá para ver o mercado pagando por isso. As vagas para engenheiros alocados junto ao cliente, que se parecem muito com as de engenheiros de produto, aumentaram 800% em nove meses de 2025. Eles estão por toda parte; todo mundo está tentando contratá-los. Quem aqui está tentando contratar um engenheiro alocado junto ao cliente? Levantem a mão.

18:08 Certo, bom, esperava mais mãos levantadas. Tudo bem. A propósito, a remuneração média de um engenheiro alocado junto ao cliente é de US$ 240 mil, ou seja, é paga como a de um engenheiro sênior porque é uma função de engenheiro sênior. É um tipo de engenheiro muito útil. Mas ninguém chegou a um acordo sobre como chamar essa função. Há umas mil denominações diferentes para o que estou descrevendo e que decidi, arbitrariamente, chamar de engenheiro de produto. E provavelmente, a esta altura, alguns de vocês…

18:39 estão pensando que isso não é programação, e vocês têm razão. Não é programação. A programação está sendo feita por um agent. Mas, ainda assim, é claramente desenvolvimento de software, e vamos ter que assimilar a ideia de que, em 2026, ser desenvolvedor de software e ser programador se tornaram coisas distintas. E quando digo coisas como “bem, acho que a parte difícil é decidir o que é bom”, percebo que estou caindo numa armadilha…

19:10 em que muita gente no mundo da IA cai: tudo, absolutamente tudo, pode ser automatizado por IA, menos aquilo em que eu sou bom, porque isso é difícil demais. Ouvi um investidor de capital de risco dizer isso outro dia e pensei: “Cara, não. Não. Alguém vai automatizar o seu trabalho a qualquer momento.” Então, é preciso considerar isso com cautela. Será que estou apenas pensando que aquilo de que gosto no desenvolvimento de software — descobrir qual é o problema — é a parte difícil do…

19:41 software? Vocês podem me dizer se estou errado. Mas digamos que, até aqui, vocês acreditem em mim. A programação vai a zero, a engenharia de produto vai ao infinito. Isso nos leva a um problema novo e importante: os desenvolvedores juniores. Porque a forma como costumávamos treinar um desenvolvedor júnior era dando a ele tarefas muito bem especificadas, que diziam: “Escreva este software deste jeito específico e depois me entregue para que eu possa apontar todas as maneiras como você errou.” Então…

20:11 isso acabou, porque é isso que fazemos com os agents de programação agora. Dizemos: “Escreva isto e depois vou apontar onde você errou.” E então conversamos com eles. Isso não é mais um trabalho que precisamos que uma pessoa faça. Mas ainda precisamos de um número enorme de engenheiros alocados junto ao cliente, ou engenheiros de produto, e temos que encontrá-los em algum lugar. Não podemos simplesmente abandonar a geração atual de novos desenvolvedores que apareceu e perguntou: “Como faço esse tipo de coisa?” E nós respondemos: “Não sei, porque já não sei qual é o seu trabalho.”

20:43 [fungada] Isso não é um futuro teórico. Este é um gráfico real de estatísticas de emprego desde janeiro de 2023. Ele está dividido por faixa etária. A linha vermelha representa engenheiros de 22 a 25 anos. O emprego deles está despencando. Não estamos contratando engenheiros juniores. Não é algo que acho que vai acontecer. É algo que vem acontecendo há dois anos. O mercado de trabalho está péssimo para eles. Enquanto isso, o emprego de engenheiros mais velhos, de 41 a 49 anos, aumentou muito, porque engenheiros seniores continuam sendo extremamente valiosos, mais valiosos do que antes, mas os engenheiros juniores…

21:15 estão sendo prejudicados, e precisamos corrigir isso como profissão. Então, se quisermos colher os benefícios de um mundo em que multiplicamos por dez a produção de código e descobrimos o restante da cadeia de produção de software e o que as pessoas precisam fazer, vamos precisar de muita gente para fazer isso. Eu disse que a demanda por software vai ao infinito. Precisamos de infinitas pessoas. De onde vamos tirá-las? Até agora, temos formado essas pessoas por acaso, e precisamos descobrir como fazer isso de propósito. O Google tem um programa chamado…

21:46 programa de gerente de produto associado, que forma pessoas muito parecidas com engenheiros de produto. Eles formam 50 por ano. Precisamos de 10 mil por ano. Mesmo que consideremos todas as outras empresas que têm um programa parecido com o APM do Google — que está sendo amplamente copiado —, elas formam apenas cerca de mil pessoas por ano, e precisamos de pelo menos dez vezes esse número para acompanhar a demanda. [fungada] As universidades ensinam estruturas de dados, os cursos intensivos ensinam React, mas ninguém ensina a passar uma semana conversando com um padeiro e voltar com uma especificação. E é dessa pessoa que precisamos.

22:17 Então, se você lidera uma equipe de engenharia, vai ter que desenvolvê-la de propósito. A IBM já está reformulando sua função de entrada para priorizar conversar com clientes e escrever especificações, em vez de programar. Você vai ter que descobrir como fazer isso na sua própria equipe. Vai ter que descobrir como treinar profissionais de produto. E vai ter que fazer isso muito rápido, porque deveríamos ter começado há dois anos, e agora há toda uma geração de juniores muito desanimados e desempregados enfrentando esse problema.

22:49 E não estamos contratando essas pessoas. Precisamos fazer alguma coisa a respeito, ou vamos nos dar mal — e não serão só elas. Então, se tudo isso acontecer, há uma grande questão que não quero simplesmente ignorar nem tratar superficialmente: muita gente entrou na programação porque ama o ofício. Ama uma abstração elegante, a sensação de finalmente fazer um bug difícil ceder, de fazer uma máquina executar exatamente o que você mandou. Essas pessoas não se inscreveram para entrevistar padeiros sobre o que querem da vida.

23:19 Isso não é o trabalho para o qual eles se candidataram. E eles vão odiar isso. Já odeiam. Estão reclamando disso em alto e bom som. Não tenho prêmio de consolação para eles. Mas tenho uma observação: para muita gente que acha que adora digitar, talvez o que você adorasse fosse o momento logo antes de começar a digitar, quando descobria qual era o problema. Essa parte não vai desaparecer. Ela continua existindo. Aquele lampejo criativo, quando você pensa: “Sei como transformar isso em…

23:50 um sistema repetível que brilha na minha mente.” Isso não vai desaparecer. E a arte da programação vai sobreviver, assim como a marcenaria sobreviveu à fábrica de móveis. Os programadores programam como os cantores cantam, certo? Fazem isso numa sala vazia, sem ninguém olhando, simplesmente porque adoram, e isso não vai desaparecer. Você ainda pode fazer isso. Só não será mais algo pelo qual as pessoas vão pagar centenas de milhares de dólares por ano. Então, aqui vai minha previsão. Os próximos 10

24:22 anos vão ser difíceis. Os últimos 2 anos foram difíceis. O impacto disso tudo está chegando antes de as ferramentas estarem prontas. A escada para os cargos juniores desapareceu antes de descobrirmos como formar mais profissionais juniores, e muita gente que ama a arte vai ter que decidir se ama o trabalho que está tomando o seu lugar. Mas isso já aconteceu antes. Compiladores, depois frameworks e, em seguida, open source tornaram desnecessárias gerações de trabalho de digitação que vieram antes; e, em todas essas vezes, saímos disso com mais desenvolvedores de software. Nós

24:52 simplesmente mudamos o significado de desenvolvimento de software. E acho que isso vai acontecer de novo. Daqui a 10 anos, teremos uma profissão maior que a de hoje, que pagará mais ou menos tão bem quanto hoje e terá, em grande parte, o formato da engenharia de produto. Esse é o argumento que estou defendendo hoje. Mas isso é um monte de previsões de alto nível, e eu detesto esse tipo de coisa. O que isso significa na prática? O que você deveria fazer hoje? Primeiro, prepare-se para um mundo em que os humanos quase não participam da produção de código. Então, identifique o código de alto raio de impacto e faça com que essa seja

25:24 a única coisa que você ainda revisa, porque o resto será resolvido pelos seus revisores automáticos. Depois, delegue tudo o que for barato de verificar. Dedique bastante tempo a pensar em como eu poderia criar um método automático para determinar se essa coisa, seja lá o que for, é boa ou não; depois, passe isso ao seu agent, em vez de tentar descobrir o processo de revisão. E, por fim, coloque o julgamento dos seus melhores profissionais em specs, rubricas e evals. Sabe, eu, o cara da Arize, ia falar de evals em algum momento.

25:55 Traga para o código aquilo que existe apenas na cabeça das pessoas. Esse é o seu trabalho como engenheiro de produto. É transformar a compreensão do problema em uma spec do problema, para que os agents possam desenvolvê-lo para nós. E meça a coisa certa. Produzir 741% mais código nunca foi o objetivo. Meça quanto vocês estão realmente entregando. Meça com que frequência os comentários dos revisores são levados em conta. Meça a diferença entre passar nos testes [limpa a garganta] e um maintainer aceitar o merge. E lembre-se: o último revisor é a

26:25 produção. Observar o que acontece lá, com outro modelo avaliando, isso é um eval. Não vou fazer propaganda da Arize; é simplesmente o que fazemos, e é por isso que estamos tão populares agora. E vou parar por aqui. Há 3 anos, Swyx escreveu sobre a ascensão do engenheiro de IA, isto é, engenheiros aprendendo a construir com modelos. A ascensão do engenheiro de produto diz respeito ao que resta quando os modelos fazem a construção. Descobrir do que as pessoas precisam, registrar o que significa fazer um bom trabalho e criar algo de que as pessoas gostem: esse é o trabalho agora. Esse será o trabalho de

26:55 todos nesta sala, gostemos ou não. Agora somos todos engenheiros de produto. Muito obrigado pelo tempo e pela atenção. >> [aplausos]

Transcrição original

[00:01] [music] >> My name is Laurie. I’m head of developer relations at Rise AI. Uh in a former life I co-founded NPM Inc. So some of may you some of you may remember me from JavaScript days. Uh but these days I think about AI agents and uh in this case what they are doing to our jobs. Uh so a little bit over 3 years ago um

[00:32] uh Swix wrote an essay called the rise of the AI engineer and his argument was that when it comes to shipping AI products you want engineers not researchers. I think that is a message that resonated with everybody especially who the people who come to this conference. Uh and so he created the job title of the AI engineer and companies since then have been hiring for it. Um and part of what I’m here to do today to do is to convince you uh that he did not in fact go far enough. Uh there’s not just an AI engineer

[01:04] revolution happening. There is a revolution happening to every kind of engineer. Um all engineering jobs are being replaced by a new type of job and not everybody is going to be happy to get that news. Um the underlying change that kicked all of this off is that agents have made writing code basically free. Like you pay for the tokens but relative to the cost of the time it used to take you uh it is basically free. Um everything that comes after writing the

[01:34] code did not become free at the same time. So the the bottleneck moved from writing code is really slow and all of this other stuff happens at roughly the same speed to writing code is super fast uh and now we get stuck behind new things. So the first the thing it’s stuck behind right this second like this month is code review. Um uh but my thesis is that it’s not going to stop there. We are going to figure out how to automate code review. We are going to make uh code review move at the speed of agents, and then we are going

[02:04] to run into another bottleneck, and another bottleneck, and another bottleneck, and at some point we’re going to stop. We’re going to hit one that we can’t get past. Uh and that is what is going to be left for the humans to do. Whatever the bottleneck is that we can’t get agents past. So, I’m making a bet that I can think of a thing that agents really are not going to be able to do. Uh and then once we’ve come to that bottleneck, we’re going to have to figure out how do we train the next generation of engineers to be able to do that job because we’re not training them

[02:36] to do that job right now. So, a quick warning {slash} apology. I have 18 minutes because that is how long Swiss gives for talks. Uh and I have a really big pile of data. I did a ton of research for this. Uh and I don’t have time to give it all to you. I don’t have time to like quote my sources and do all that stuff. So, I’m just going to throw numbers at you with a bunch of citations on the slides, and I’m just going to have to sort of ask you to trust me, bro. Uh >> [laughter] >> Uh so, developers who switch on autonomous coding agents write 741%

[03:09] more code, eight times as much. Uh and but they ship only 30% faster. Like, 30% faster is not nothing. 30% faster is amazing. We are shipping a lot more code than we used to, but given that we’re writing eight times more code, only a third more actual shipping is kind of bad, right? It means that we’re stuck somewhere. Uh and where we’re stuck is code review. Um and the reason that we’re stuck is because humans can’t just review faster. Uh there is an enormous study done by Cisco 20 years ago about how fast you

[03:41] can do code review, and how accurately you can do code review. Um and it turns out that humans’ ability to like parse what’s going on in code falls off radically after about 450 lines of code per hour. So, if you’ve produced a 10,000 line diff with your agent, it would take you like a week to reasonably review that code. And the answer is that nobody’s actually doing that, right? Cuz we’re all throwing 10,000 diffs around willy-nilly these days.

[04:12] Um so, I did a whole talk about this phenomenon at a previous AIE, and that talk is called the death of the code review. And if you want all of the information about the death of the code review, you can watch that talk. Um but the problem facing us right now, uh which is not the same as the problem I’m trying to solve with this overall with this talk, is that the cost of producing plausible code has collapsed while the cost of knowing whether to trust that code has stayed exactly the same. Um so, the obvious review move right now is to make the machines do the review,

[04:43] like I said. And that is already happening. Um GitHub’s Copilot uh does more than one in five of the code reviews on GitHub as of last month. Uh you can, if you want to, opt in to let uh Copilot be the final reviewer before something goes to uh production. You can make it have the approval power, if you want to, which is crazy. I don’t know who’s turning on that option, but you can do it if you want to. Um OpenAI says that at at OpenAI, humans may review their pull requests, but

[05:13] aren’t required to. Um but the problem is that the machine reviewers aren’t very good yet. Uh the data says that there’s uh the data that I found put four AI reviewers through their paces, and they all found a bunch of bugs, but none of the same bugs. They did not agree on any individual bug. Uh they all found actual issues in the code. They all found different issues in the code. Um so, they’re worth running, but if you are serious about this, you’re never going to run just one of them. Uh

[05:44] because they are not reliable enough yet. Um And there are some people who went all the way. They were like, “I’m just not going to review the code anymore. I’m just going to assume my agent has one shot at this perfectly.” Um Dexter Horty, who is here, I don’t know if he’s in the audience, probably not. Um uh he spent 6 months telling people not to read the code, and then after that 6 months, he got on stage and said, “Nope, I was wrong. You can’t actually uh skip code review entirely. We tried that. It was a disaster. We had to rip

[06:15] replace whole systems.” Uh that’s not an option. The agents are not good enough. They’re not one shotting the code. Um Amazon had a run of outages uh that they did postmortems on and decided that it was because their coding agent had produced a bunch of slop and they just released it into the wild without thinking. Uh and so now they don’t let them do that anymore. Uh senior engineers must sign off on code reviews at Amazon. Um and Anthropic published a postmortem uh on bugs that had got past every reviewer that they had, both human and

[06:45] machine. So, the problem is that the automations that we’ve built so far to check whether our code is good enough are not themselves good enough. Um Claude Fable 5 passes the tests uh on 80% of a standard coding benchmark. Um and co- So, Cognition, the makers of Devin, um they built a benchmark that asks a different question, which is not does it pass the tests? The question is would you as the reviewer, as the maintainer of this repo, merge this PR? And if you ask that question instead, the pass rate falls

[07:17] from 87% uh to 54%. Um because there’s a lot of extra information that goes into deciding whether you would merge it. There’s code style, there’s side effects, there’s external systems, there’s history that is not encoded into the code base. It is encoded into the brain of the maintainer. Um So, what the maintainer is adding, what maintainer is demonstrably adding, is something that we haven’t given the agents yet. There is information they

[07:48] don’t have, there is a skill they don’t have. Um and it is the sense of what good means. That is what we are That is what the agents don’t have yet. Uh and that is a critical insight that I’m going to come back to. Um Eliyahu Goldratt, if I’m pronouncing that correctly, was a physicist who became a management guru and in 1984 he wrote a a novel about running a factory. Does that sound like an interesting novel to you? Um it is called The Goal. Um and his big idea was the theory of constraints. Uh every system has one

[08:20] bottleneck and speeding things up does not work unless the thing that you were speeding up is the bottleneck. Uh that is our problem with code review. Uh we’ve sped up the code and we have not sped up the review. Um his second idea is the one that matters today, which is that when you fix the bottleneck, it doesn’t go away, it just moves and finds another bottleneck to pile up against. Um so let’s assume, despite everything that I’ve said about how bad the code reviewers are right now, that we figured that out, that we get automated code

[08:51] review to a higher standard and we move that bottleneck. What is the next bottleneck uh that it is going to run into? Um if we figure out review, the next bottleneck is probably going to be operations. How do I deploy this thing? How do I scale it up? Uh and then you’re probably going to run into security. How do I make this thing safe at scale? Uh how do I make sure that this thing is private? How do I make sure that it’s not radically going off the rails? Uh but I’m going to make and this is the

[09:21] big leap that I’m making in this talk. I’m going to assume we figured those things out as well because those things are very heavily solved by humans. There’s an enormous amount of data out there about them. If we can figure out how to do operations, how to do scaling, how to do security using progressively more advanced agents, what is it that we are left to do? Like, what is the role of a human in that situation? Um it’s also it’s a big question

[09:52] [clears throat] and it’s also a long-term question. I’m not telling you what is going to happen in the next 12 months. In the next 12 months, I think we’ll probably make some real progress on code reviews. I do not think 12 months from now we’ll have sorted out operations and scaling and security. I think that is going to take somewhere between 5 and 10 years to get done. Uh despite people who are like, “AGI 2027.” No, we’re going to slowly iterate on this stuff. Um But the other assumption that you need to make for my for the my thesis to be

[10:22] correct is that the amount of software that we need is effectively infinite. And I feel that one is a much easier case to make. Think of every website you’ve ever run into uh in the world in production, and it’s probably pretty bad. Uh and the reason it’s bad is not because we don’t know how to make really great websites. The problem is that there’s not enough people to make all of the websites good. Every time you run into a terrible website at your hairdresser or the government or like, you know, your bank, like it’s not because there’s not somebody who knows how to make that

[10:52] website good. It’s because A, it’s very expensive to make it good, and B, the people who are doing that are busy doing other things. Uh you know, probably shipping AI agents. Um so assume that we can make as much software as we want basically for free, and that the appetite for making software is essentially infinite. That is a wonderful situation in which to be in. We’ve got infinite demand and also suddenly infinite supply. Uh where does the bottleneck end up? What do we think the agents are not going to eat? Um to try and figure that

[11:25] out, I split up the job of software development into as many pieces as I could think of, and I sorted them by how soon the agents uh get to them. Uh writing code is already collapsed, reviewing and maintaining code is going soon. Um shipping to production and scaling are next on the chopping block, although there isn’t a lot of data there yet. Uh and then there’s the stuff that I think is probably safe, which is deciding what to build, uh defining what good means, and finally making it delightful. What’s left is finding out what people

[11:56] actually want. Every piece of software is a formalization of something that a human wanted to get done. Uh So, if a customer tells you, “I need to to keep track of my orders,” there are 10,000 pieces of software that keep track of your orders. That’s what they do. Uh but only one of those, if you’re lucky, is good if the thing that you’re doing is you’re running a bakery. If you’re running like an auto parts store, that’s going to be different. If you are running uh you know, a

[12:27] giant manufacturing concern, it’s going to be completely different. The That requirement is not sufficient. The whole job is figuring out what exactly do you mean when you say that you want to keep track of your orders. What does that mean for your business? What does it have to do? How does that work? Uh and that knowledge isn’t in the training data. It isn’t in the weights. It is in the mind of the person who runs that business. And the only way to get it out is by flapping your meat parts at them and having them flap their meat parts back. Like, you have to talk to

[12:57] them. That is the only way to get the information out. Um And that work has a very important property, which is that it doesn’t transfer. Uh if you think about what good means for like a calendar app and what good means for a scheduling app, those are solving almost the same problem, right? A calendar app and a scheduling [clears throat] app, but they’re completely different pieces of software. They have totally different requirements and a totally different definition of good, even though [clears throat] those two use cases are so close together, and we have a zillion use cases. Um Anytime that you’ve used software that

[13:29] has a zillion configuration options and it still doesn’t [snorts] do what you need. I’m looking at you, Jira. Uh like that is the problem you’re running into of software that is trying to do everything and still failing at it. Um so the bottleneck moves to describing the problem and defining what it means to have solved the problem and my big bet for this talk and for the next 10 years is that is where it stays. Uh Fred Brooks, who ran IBM System 360 project

[14:00] and wrote uh The Mythical Man-Month, uh he wrote about this in 1986. He split the difficulty of software into two kinds. Accidental complexity is the difficulty of the tools or the languages, the typing, the syntax, and then there’s the essential complexity, which is the prob- difficulty of the problem itself. Uh and he predicted that no single tool would make us 10 times more productive because the essential part is the hard part. Uh and Brooks’s prediction is looking pretty solid because we made code eight times faster and we still didn’t get

[14:30] very much faster at shipping because the hard part is the essential part. Um Shawn Grove from OpenAI made the same point uh 2 years ago. Uh no, sorry, a year ago. Uh what year is it? Um he said that code is a lossy projection of the specification and whoever writes the spec, if it’s a PM or a lawmaker or an engineer or a marketer, they become the programmer. Uh and so writing [clears throat] down what good means is where the value is now. Uh

[15:02] I’m beginning to run out of time because I haven’t timed this well. Um anything that you can verify cheaply, you can train against until you beat it if you are model maker. Uh so uh Cognition tried to write down because of their benchmark about what what it counts to merge something, does it, you know, is is this code mergeable? They were like, let’s see if we can figure out a benchmark that defines what mergeable really means. Let’s see if we can get all of that other information into the benchmark, and then we can

[15:33] train a model on it. Um uh Cursor’s reviewer BugBot turns every thumbs down that you that your team gives it into a rule, and they have like 44,000 rules now. Uh so the moment the maintainer takes knowledge out of their brain and puts it somewhere written down that a model can train on it, [laughter] uh the bottleneck moves again. That is why I think security can go. That is why I think operations can go. I think we can write those things down eventually, even though we haven’t done it yet. Uh

[16:05] Andrew Ng, the co-founder of Google Brain and Coursera Coursera, says that one of his team proposed having twice as many product managers as engineers, uh and he said that that was a first in his life, uh but his answer is since then hasn’t been hire more PMs. It’s to blur the jobs together. In his words, when an engineer understands users and can make decisions on what to build and build it directly, uh they can execute incredibly quickly, and that is where I think we are beginning to hit on the answer. Uh in the 1960s, there there was a job

[16:36] called the systems analyst. Their job was not to write code. Their job was to talk to the business and find out what the problem was. Uh then that analyst turned into something that we call a product manager today, and we’ve had two professions uh where there used to be one and a half. I think what is happening is they are collapsing back into one. We are going back to the ’60s. So that is not an AI engineer. They’re not just building AI. They’re not just building with AI. They are building everything. They are building

[17:06] all software. Uh and I’ve decided to call this job the product engineer. This is somebody who finds out what people need, defines what good looks like, and ships it uh with agents doing the typing um Gergo Orosz whose name I have probably butchered he writes the pragmatic engineer newsletter he described the product-minded engineer back in 2019 as a nice trait for an engineer to have and what I’m saying now is it has gone from nice to essential. It has gone from the

[17:37] from a skill that senior engineers used to have to a skill that every engineer has to have if they’re going to be an engineer. um And you can see the market already paying for this. Forward deployed engineers who look very much like product engineers job postings for them rose 800% in 9 months of 2025. They are everywhere everybody is trying to hire them. Who in this room is trying to hire a forward deployed engineer show of hands.

[18:08] Okay, well more I was expecting more hands oh well. uh So uh The average comp for forward deployed forward deployed engineer by the way is $240,000 which is to say that it pays like a senior engineer because it is a senior engineer. It’s a very useful kind of engineer. um But nobody agrees on what to call it yet. There are like a thousand different job titles for this thing that I am describing and have decided arbitrarily to call the product engineer. um And probably at this point some of you

[18:39] are thinking that isn’t programming and you are correct. It is not programming. The programming is being done by an agent. It is however recognizably still software development and we are going to have to wrap our minds around the idea that being a software developer and being a programmer have become divorced in 2026. um And when I say stuff like well I think the hard part is deciding what good is I realize that I’m falling into a trap

[19:10] that lots of people in AI land fall into, which is all of the parts everything about everything can be automated by AI except the thing that I’m good at because that’s too hard. I heard a VC say that the other day and I was like, “Buddy, uh like, no. No, someone is going to automate your job any day now. Um uh so you have to take this with a grain of salt. Am I Am I just thinking that the thing that I enjoy about software development, which is figuring out what the problem is, is the hard part of

[19:41] software? You can tell me if I’m wrong. Um but say you believe me so far. Programming goes to zero, product engineering goes to infinity. That brings us to a new and important problem, which is junior developers because the way we used to train a junior developer is we used to give them very well-specified tickets that said, “Write this software this way in particular and then give it to me so that I can tell you all the ways that you were wrong.” Uh

[20:11] and that is gone because that’s what we do with the That’s what we do with the coding agents now. We say, “Write this thing and then I’ll tell you how you’re wrong.” And then we have a conversation with them. Uh and there’s That is not a job that we need a human to do anymore. But we still need an enormous number of forward-deployed engineers or uh product engineers and we have to get them from somewhere. We can’t just abandon the current generation of new developers who’ve showed up and said, “How do I do this stuff?” We’re like, “I don’t know because I don’t know what your job is

[20:43] anymore.” Uh >> [snorts] >> this is not a theoretical future. This is an actual graph of labor statistics since January 2023. It is sorted by age. The red line is engineers aged 22 to 25. Their employment is collapsing. We are not hiring junior engineers. This is not a thing that I think is going to happen. This is a thing that’s been happening for 2 years. Job market sucks for them. Meanwhile, the job for older engineers 41 to 49 has gone way up because senior engineers are still super valuable, more valuable than before, but junior

[21:15] engineers are being screwed and we need to fix that as a profession. Uh so if we’re going to reap the benefits of a world where we 10x code output and figured out the rest of the software supply chain and figured out what humans need to do, uh then we are going to need a lot of people to do that. I said that the demand for the software is going to infinity. We need infinity people. Where are we going to get them? Uh we’ve been creating them accidentally so far and we need to figure out a way to do them on purpose. Google has a product uh has a program called the

[21:46] associate product manager program which turns out people that look very much like product engineers. They turn out 50 of them per year. We need 10,000 of them per year. Even if you look at all of the other pro all of the other companies that have something a program like Google’s APM, it’s being extensively copied. They’re only turning out about a thousand people a year and we need 10 times that number at minimum uh to keep up with demand. Uh >> [snorts] >> universities teach data structures, boot camps teach React, nobody teaches go sit

[22:17] with a baker for a week and come back with a spec and that is the person that we need. Um so if you lead an engineering team, you’re going to have to grow them on purpose. Uh IBM is already redesigning its entry-level role around talking to customers and writing specs instead of programming. Um you’re going to have to figure out how to do that for yourself. You’re going to have to figure out how do you train product people? Uh and you’re going to have to do it very quickly because the time we should have started was two years ago and there’s a whole cohort of very sad unemployed juniors right now who have this problem

[22:49] and we are not hiring them and we need to do something about that or we are going to be screwed and not just them. Uh so if all of that happens, there’s one big thing that I don’t want to just gloss over or hand wave away, which is a lot of people got into programming because they love the craft. They love a clean abstraction, the feeling of a hard bug finally giving up, making a machine do exactly what you told it to do. They did not sign up to interview bakers about what they want in their lives.

[23:19] Like that is not the job that they signed up for. Um and they are going to hate this. They already hate this. They are complaining about it very loudly. I have no consolation prize for them. Um but uh I do have an observation, which is that for a lot of people who think they love the typing, maybe what you loved was the moment just before you started typing, when you figured out the problem. That That part doesn’t go away. That part is still there. That creative spark when you’re like, I know how to make

[23:50] this into a repeatable system that glows in my brain. That’s not going away. Uh and the craft of programming will survive uh in the same way that like woodworking survived the furniture factory. Like programmers program the way that singers sing, right? They do it in an empty room with nobody watching just because they love it and that won’t go away. You can still do that. Um it just won’t be the thing that people pay you hundreds of thousands of dollars every year to do. Um so here is my prediction. The next 10

[24:22] years are going to be ugly. The last 2 years have been ugly. Um the load of this stuff is arriving before the tools are ready. The junior ladder is gone before we have figured out how to train more juniors uh and a lot of people who love the craft are going to have to decide if they love the job that is replacing it. Um but this has happened before. Compilers and then frameworks and then open source each made a generations worth of typing before them uh unnecessary and each time we came out of it with more software developers. We

[24:52] just changed what software development meant. Uh and I think that’s going to happen again. Uh, in 10 years time we will get a profession that is bigger than today’s, pays about as well, and is mostly shaped like product engineering. That is the case that I’m making for you today. But that is a whole lot of high-level predictions, and I hate those. What does this mean for real? What should you actually do with this today? Uh, first, be prepared for a world in which humans are barely involved in the production of code. So, write down your high blast radius code, and make that be

[25:24] the only thing that you are reviewing anymore, because the rest of it your automatic reviewers are going to get done. Uh, then delegate that everything that’s cheap to verify. Spend a lot of time thinking about how would I build an automatic way of telling whether this thing, whatever that thing is, is good or not, and then feed that to your agent instead of trying to figure out the review process. Uh, and finally, put your best people’s judgment into specs and rubrics and evals. You know, I the arise guy was going to say evals at some point. Uh,

[25:55] get stuff that exists only in people’s heads into code. That is your job as a product product engineer. It is turning the sense of the problem into a spec of the problem, so that the agents can build it for us. Uh, and measure the right thing. 741% more code was never the point. Measure how much stuff you are actually shipping. Uh, measure how often your reviewers comments get acted on. Measure the gap between the tests [clears throat] passed and a maintainer would merge this. Uh, and remember that the last reviewer is

[26:25] production. Watching what it does there with another model grading it, that is an eval. I’m not going to pitch arise, that’s just what we do, and that’s why we’re so popular right now. Uh, and I’ll leave it at that. Um, 3 years ago, Swyx wrote about the rise of the AI engineer, which is engineers learning to build with models. And the rise of the product engineer is about what’s left when the models do the building. Uh, finding out what people need, writing down what good means, and making it something people like, that is the job now. It is going to be the job for

[26:55] everyone in this room, whether we like it or not. We are all product engineers now. Thank you so much for your time and attention. >> [applause]