Lenny Rachitsky: o PM nativo de IA escreve o "bom" antes

Lenny Rachitsky construiu a maior newsletter de produto do mundo entrevistando quem constrói software de verdade, do Airbnb para baixo. Quando alguém assim para de falar de descoberta e prioridade para desenhar o que chama de PM nativo de IA, vale ouvir com atenção. A tese dele não é sobre usar mais ferramentas de IA no dia a dia. É sobre uma mudança de método que, lida com cuidado, descreve exatamente o trabalho de quem coloca IA em produção.

O que ele está dizendo

O centro da tese cabe em uma frase: defina o que é bom antes de escrever o código. Parece óbvio, e é o oposto do que a maioria dos times faz. O reflexo comum é pedir a funcionalidade, ver o que a IA cospe e reagir. Rachitsky inverte a ordem. Primeiro você escreve, em texto claro, como se parece uma boa resposta, um bom comportamento, um bom resultado. Só depois pede o código.

Disso saem duas ideias práticas que ele repete. A primeira é trocar especificação de funcionalidade por especificação de comportamento. Em vez de descrever a tela e o botão, você descreve o que o sistema deve fazer diante de cada situação, incluindo as situações ruins. A segunda é o que ele chama de botão de autonomia. Autonomia de agente não é chave de liga e desliga, é um botão que você gira: em alguns fluxos o agente resolve sozinho, em outros ele sugere e um humano aprova, em outros ele nem começa sem permissão. O trabalho do PM nativo de IA é decidir, caso a caso, em que ponto esse botão fica.

Por baixo dessas ideias há uma exigência que incomoda parte da profissão: elevar a régua técnica. Rachitsky é direto ao dizer que o PM nativo de IA precisa aprender a escrever lógica estruturada que a engenharia consiga testar. Não é virar programador, é parar de entregar desejo vago e passar a entregar critério verificável. E há o pano de fundo do mercado de trabalho, que ele não suaviza. Quem tem como função executar tarefas predefinidas está na zona de perigo, porque é justamente isso que a IA absorve primeiro. Quem é dono do resultado, faz as escolhas difíceis e navega a ambiguidade fica escasso e muito valioso. A IA deixa uma pessoa entregar o que antes exigia um time, mas só se essa pessoa souber reger a orquestra.

Defina o que é bom antes de escrever o código. É a diferença entre pedir para a IA e conseguir avaliar o que ela devolveu.

A nossa leitura

Aqui a tese do Rachitsky encosta em tudo que a gente defende sobre IA em produção, às vezes com outro nome. Definir o que é bom antes do código não é conselho de produtividade, é a descrição exata de um eval. O texto contra o qual você testa o comportamento do agente é o mesmo artefato que separa quem confia no modelo por fé de quem confia no modelo por verificação. Escrever a especificação de comportamento primeiro é escrever o teste primeiro, e é isso que impede o agente de parecer bom na demonstração e falhar no cliente.

O botão de autonomia é a mesma conversa que a gente teve sobre onde colocar o agente segundo o Cynefin: domínio claro e repetível aceita autonomia alta, domínio complicado ou confuso exige humano no meio. Rachitsky dá a essa decisão um nome operacional e diário, o que ajuda. O erro que a gente mais vê não é escolher autonomia demais ou de menos, é não escolher, deixar o agente rodar com uma autonomia que ninguém decidiu de propósito.

Onde vale um contraponto honesto é na euforia da orquestra de um homem só. É verdade que um bom PM técnico entrega hoje o que antes exigia time. Também é verdade que boa parte do valor de um time era justamente o atrito, a segunda cabeça que discorda, a revisão que pega o erro. Concentrar decisão em uma pessoa que rege agentes acelera tudo, inclusive o erro. A régua técnica que Rachitsky pede é o que evita que velocidade vire dívida. Por isso, antes de colocar no ar um fluxo com agente decidindo sozinho, vale rodar um premortem do projeto e listar como esse agente sem par de revisão vai falhar.

A parte mais útil da tese é a que menos parece sobre IA. Ser dono do resultado, decidir no ambíguo, definir o bom: isso sempre foi o núcleo do bom trabalho de produto. A IA só tornou caro continuar fingindo que dava para pular essa parte. Quem já fazia sobe de nível. Quem terceirizava o julgamento para o processo descobre que não tem para onde terceirizar quando o processo virou um agente que faz o que você mandou, exatamente como você mandou, inclusive quando você mandou errado.

Se você quer transformar o trabalho de produto do seu time em especificação de comportamento e eval, e ajustar o botão de autonomia dos seus agentes com critério, fale com a AI Boutique no WhatsApp. A gente ajuda a montar o método que faz a IA entregar em produção.