O responsável pelo Codex: "Todos são construtores" é uma péssima ideia.

Andrew Ambrosino é o líder da equipe do OpenAI Codex. Com formação em design, já trabalhou como engenheiro, product manager, empreendedor, e agora lidera o Codex, que tem mais de 5 milhões de usuários ativos semanais. Ele é provavelmente uma das pessoas mais adequadas hoje para responder "como fazer produtos na era da IA".

Na sua visão, quando quase todos na empresa conseguem criar rapidamente um protótipo funcional, o verdadeiro desafio não é mais "se é possível fazer", mas "se deveria ser feito".

Em uma conversa com Lenny, Andrew Ambrosino detalhou o processo de desenvolvimento interno da OpenAI: quando o custo de implementação é drasticamente reduzido pela IA, cada etapa do desenvolvimento de produto, desde a definição, documentação, prototipagem, design até a divisão de papéis, colaboração em equipe e planejamento de produto, está mudando. Quais regras antigas estão se tornando obsoletas? Quais novos padrões estão se formando? Quando a implementação deixa de ser escassa, o que realmente se torna o recurso escasso?

Algumas ideias centrais:

Quando 90 pessoas conseguem criar 90 protótipos de produtos que parecem prontos para lançamento, o mais valioso é o bom gosto (taste).

Um dos requisitos duros para contratar na equipe Codex é o bom gosto, a capacidade de distinguir sinal de ruído em meio a um grande volume de conteúdo. Em um mundo de "tokens infinitos", eles não querem produzir conteúdo de baixa qualidade.

Se o Codex tivesse sido lançado três meses antes, teria sido um fracasso total; a única diferença foi o avanço do modelo. Não julgue facilmente uma funcionalidade como ruim; ela pode simplesmente não ter chegado na hora certa.

Se uma funcionalidade é boa ou não, muitas vezes não depende da sua forma, mas sim de quão inteligente o modelo é.

Assim como o Codex já revolucionou o ChatGPT, o Codex também pode ser revolucionado por novas tentativas. É preciso preservar uma cultura de exploração de baixo para cima; não se pode esperar que a mesma equipe refine detalhes e ao mesmo tempo se revolucione.

A seguir, os destaques da conversa.

Com o custo de implementação reduzido, o bom gosto se torna mais importante

Lenny: Você disse que a IA está mudando a forma do trabalho de produto. Você trabalha agora em uma das equipes de produto de IA mais avançadas do mundo. Especificamente, como o trabalho da equipe de produto mudou em comparação com dois anos atrás?

Andrew Ambrosino: Hoje, como líder de equipe, a coisa mais difícil é que o processo está invertido.

Como se fazia produto antes, todo mundo conhece: primeiro pesquisa, depois ideias, protótipos. Mesmo que já tenhamos passado da era do desenvolvimento em cascata, a lógica subjacente ainda era a mesma: implementar é caro. Então, antes de implementar, você precisa eliminar todos os riscos com documentação, pesquisa, protótipos. Porque protótipo e design são mais baratos que desenvolvimento, essa era a suposição básica do passado.

Agora essa suposição mudou completamente; qualquer um pode fazer qualquer coisa. Eu realmente acredito que, conversando do zero com esses modelos, sejam os nossos ou de outras empresas, você pode construir qualquer funcionalidade que quiser. Essa pode não ser a parte mais difícil do desenvolvimento de software, mas é realmente legal.

Você dá tokens infinitos para as pessoas, todos na OpenAI são muito proativos e têm boas ideias. Então todo mundo está fazendo todo tipo de coisa. Hoje, temos uma funcionalidade que precisamos urgentemente, e tenho certeza de que há 90 pequenas equipes diferentes, não coordenadas, cada uma implementando e testando algo. Dessas 90 tentativas, quais são boas? Quais partes devem ser incorporadas em outras? Como definir isso? Deve ser parte de outra funcionalidade? Quantas opções deve ter na chave? São essas coisas.

Então, a resposta curta é: está invertido. Não é que as pessoas estejam fazendo papéis fundamentalmente diferentes, nem que as habilidades tenham desaparecido ou os cargos não existam mais. Implementar não é mais a parte mais cara; ouso dizer que a parte mais cara é o bom gosto (taste).

Lenny: Então, antes as pessoas escreviam PRDs, documentos de estratégia, agora todo mundo faz protótipos. Muitas pessoas na empresa têm ideias semelhantes, e surgem 90 coisas diferentes, e depois escolhem uma direção?

Andrew Ambrosino: Sim, isso acontece muito. Não só na OpenAI; você já viu muitos líderes de produto dizendo "PRD morreu, protótipo é o caminho", mas na verdade discordo totalmente disso.

Porque implementar se tornou barato em todos os meios, fica muito tentador pular o pensamento e ir direto para o protótipo. Especialmente se você não é engenheiro, nunca escreveu código, não tem interesse ou tempo, você vai querer dizer: "PRD morreu, deixa eu te mostrar diretamente o que quero."

Mas também notei um fenômeno oposto. Para engenheiros, escrever muita documentação se tornou tentador, muita documentação que não vale a pena ser lida. Não estou dizendo que quem escreve documentação é ruim, mas sim que, quando a implementação se torna abundante, escolher o formato certo para expressar seu ponto de vista se torna realmente importante.

Se você quer expressar clareza de produto em uma área nebulosa, talvez deva escrever um documento. Se você quer que as pessoas testem e estressem um padrão de interação, faça um protótipo. O importante é escolher o meio certo.

Lenny: Existe um conceito chamado "primal mark" (marca primária), a primeira pincelada do pintor na tela, da qual tudo o mais se estende. Você quer dizer que às vezes o protótipo é a primeira pincelada errada? Porque as pessoas ficam ancoradas nele, em vez de pensar em soluções maiores?

Andrew Ambrosino: Sim. Antes, havia um sinal implícito: a aparência de algo indicava em que estágio do processo estava. Se algo parecia um produto pronto para lançamento, significava que já estava em fase final, riscos eliminados, design revisado, objetivos de negócio razoáveis.

Agora essas coisas se desconectaram. A razão é que antes, para obter recursos para construir, você precisava reduzir o risco suficientemente; agora esse limite desapareceu. Então, algo que era apenas uma exploração já parece pronto para lançamento, visualmente está pronto. Mas pode não ser a direção certa, não corresponde às conclusões da pesquisa, não é o que os usuários realmente precisam, nem é o melhor para o negócio.

Não quero superenfatizar a questão do bom gosto. Mas, novamente, saber o que fazer, como apresentar, como atingir o objetivo, qual meio usar, está se tornando a habilidade mais importante em todas as áreas.

Lenny: A palavra "taste" (bom gosto) está na moda agora. Especificamente, o que você quer dizer com "bom gosto"?

Andrew Ambrosino: É preciso decompor o bom gosto.

Há uma parte estética, mas também há uma parte de pensamento sistêmico: como isso se encaixa no sistema todo; há uma parte direcional: para onde vamos, de que tema isso faz parte; há uma parte de expressão: como apresentar essa informação; e uma parte de interação: essa animação não corresponde ao significado que pretende transmitir, é muito rápida, não combina com o que quer dizer.

Essas coisas são realmente importantes, mas a verdadeira questão do bom gosto é: se podemos fazer tudo, qual é o objetivo? Como chegar lá?

Lenny: À medida que a IA fica mais forte e faz mais coisas, onde o cérebro humano continuará tendo valor? O bom gosto parece ser um desses lugares. Mas a produção de design da IA ainda não é boa; por que os melhores modelos não conseguem fazer bom design?

Andrew Ambrosino: Há razões práticas e outras mais difíceis de resolver. Design é mais difícil de avaliar do que software; criar um ciclo de feedback para treinar o modelo sobre o que é bom design é muito mais trabalhoso do que treinar se o código compila, porque o gosto humano faz parte do mecanismo de feedback.

Além disso, historicamente, os laboratórios priorizaram que os modelos fossem bons em coisas que aceleram a pesquisa de IA. Um modelo que escreve código correto claramente acelera a pesquisa; o design não permite a mesma argumentação. Não que design não seja importante, mas não está nesse ciclo virtuoso.

Essas são razões práticas; elas vão desaparecer. Os modelos vão se tornar muito bons em design, mas há coisas mais complicadas.

Primeiro, o design tem um componente cultural. Você lembra que no ano passado todo site novo copiava o design do Linear. Se o modelo sempre gerasse sites do Linear, esse não seria o desafio. A importância da novidade no design é muito maior do que na engenharia de software. Na engenharia, você quer que o modelo siga padrões conhecidos; no design, você precisa de certa aleatoriedade e novidade.

Segundo, é a interação entre design visual e código. Se amanhã a empresa mudar de marca, a abordagem superficial é atualizar um por um os 263 componentes. A abordagem profunda é entender que duas coisas aparentemente diferentes pertencem a um mesmo estilo de lista e transmitem o mesmo padrão de interação. Essa camada de abstração, a tecnologia atual ainda não alcança.

Lenny: Jenny Wen (líder de design do Claude Code da Anthropic) disse que o processo de design morreu, é só construir diretamente. O que você acha?

Andrew Ambrosino: Eu e Jenny provavelmente concordamos em muitas coisas. O processo formal de design, concordo com ela, morreu. E eu já não era fã desse processo antes da IA.

Há alguns anos, quando eu tinha minha startup, havia um artigo chamado "Fábrica de Casos de Estudo", que falava sobre designers sendo treinados a seguir um processo fixo e, gradualmente, valorizar mais o processo do que o resultado. Se algo passava por esse processo, automaticamente se concluíam duas coisas: primeiro, que seria bom, porque o processo garantia qualidade; segundo, mesmo que ninguém usasse, seria bom porque passou pelo processo.

Pesquisa de usuário, divergência, convergência, o framework está certo, mas sempre foi um pouco acadêmico. A premissa desse processo é que implementar é caro; você só pode construir uma vez, então precisa esgotar todo o espaço de problemas e soluções antes de fazer.

Depois vieram Figma e Origami, e trouxemos protótipos interativos para o processo. Agora o problema é que você pode trazer toda a implementação para o início do processo. Um protótipo totalmente refinado parece pronto para lançamento. Muitas pessoas na empresa veem e perguntam: "Podemos lançar agora?" Mas, na verdade, vocês ainda estão em exploração inicial de design, só que ninguém disse isso explicitamente.

Então, dizer que o processo de design morreu é ao mesmo tempo certo e errado. Se você está preso a ferramentas específicas e operações diárias específicas, então sim, morreu. Mas a cognição de "em que estágio do processo estamos" é mais importante do que nunca.

Prender o processo de design a um meio específico é o perigoso. Os designers agora têm mais ferramentas: podem colocar coisas diretamente no produto existente, fazer testes A/B. Muitas empresas têm versões "baby" do produto, baby Cursor, baby Codex, uma base de código drasticamente simplificada que simula todas as interações do produto real. Você pode usá-la para "vibe code" (programação por vibe) e dizer "e se a barra lateral for assim? E se aparecer um painel?" Isso é uma nova ferramenta para designers, mas precisa ser combinada com a cognição antiga: onde você está no processo.

Cargos e papéis estão se fundindo, mas PM não vai desaparecer

Lenny: Muitas empresas estão falando sobre "morte dos cargos". Você acha que as funções de PM, engenheiro e designer vão desaparecer completamente?

Andrew Ambrosino: Algumas empresas gostam de seguir tendências e ir a extremos. O perigo de eliminar o conceito de cargos é que pode eliminar também o reconhecimento de que essas áreas têm práticas recomendadas que podem ser aprendidas.

Ouço muitas empresas dizerem "vamos eliminar o papel de produto", acho uma péssima ideia, e depois dizem "todo mundo é builder". O resultado é que a gestão de produto, uma disciplina que acumulou práticas recomendadas reais e aprendeu com erros, é descartada diretamente. Porque alguém escreveu algumas linhas de código e acha que está tudo certo; isso não é um bom estado.

Acolho o fim das fronteiras do tipo "isso não é sua área, você não pode mexer", mas precisa de equilíbrio. Nem todo mundo pode fazer tudo, seja em amplitude ou profundidade; é por isso que gestores não vão desaparecer.

Além disso, cada disciplina tem componentes de habilidade. Muitos engenheiros não reconhecem isso, acham que engenharia tem habilidade, mas outros papéis são "vibe". Não é assim; saber usar Excel não significa que você pode trabalhar no time financeiro.

O que acho que está acontecendo mais é que as pessoas estão colaborando entre papéis com mais facilidade, e aprender as melhores práticas de outras áreas também ficou mais fácil, sem precisar amarrar sua eficiência em um papel ao uso de uma ferramenta específica.

Passei muito tempo achando que não deveria ser engenheiro de software porque não me importava com assembly e não queria memorizar o sistema de tipos do TypeScript. Esses papéis sempre tiveram algumas barreiras, como se "ser bom nesse papel = dominar essa ferramenta". Acho que isso está começando a se dissolver, mas as pessoas estão exagerando.

Lenny: Na sua equipe Codex, há de fato mais fusão de papéis. Como é exatamente?

Andrew Ambrosino: Na equipe Codex, vemos mais fusão de papéis do que em outras equipes da empresa e em outras indústrias. Parte disso é porque é um produto técnico voltado para engenheiros. Então nossos designers falam a linguagem dos engenheiros, nossos product managers falam linguagem técnica e sabem programar.

Internamente, temos uma maneira de descrever a colaboração: hoje, a sobreposição entre papéis é muito maior do que no passado. Definir uma pessoa não é mais pela fronteira de "onde o design termina e onde a engenharia começa", mas pela distribuição média de todo o seu trabalho.

Se você pegar tudo o que uma pessoa no time de design faz, pode incluir muito código e muito trabalho de produto. Mas, tirando uma "média" dessas atividades, ela ainda cai em uma região mais voltada para design.

Lenny: Você mencionou que o trabalho do product manager é mais como "zone defense" (defesa por zona). O que exatamente significa?

Andrew Ambrosino: Se dois product managers colaboram muito intensamente, geralmente não é um bom sinal. É melhor expandir a equipe como um layout orientado a força e ver onde há lacunas, onde ninguém está cobrindo.

No mundo de hoje, curadoria, orientação e alinhamento se tornaram o trabalho mais importante. Todo mundo está constantemente jogando ideias, o ambiente inteiro é ruidoso; o antigo modelo de cima para baixo e planejamento anual não funciona mais. Precisamos de alguém como guardião do bom gosto, guiando algo do conceito ao produto, e isso significa cobrir todos os cantos da empresa.

Então, você precisa espalhar a equipe, ver quem é bom em quê? Manter distância entre eles para garantir cobertura abrangente. Depois preencher as lacunas, tipo: "queremos contratar um engenheiro com forte pensamento de produto." Não queremos uma situação em que um grupo escreve muito código e depois todo o time de produto precisa revisar e calibrar a consistência. Queremos que todos tenham essas habilidades, apenas suas áreas de aprofundamento precisam mudar.

Lenny: Então, a pessoa mais valiosa agora é aquela que consegue levar uma ideia do início ao fim e tem bom gosto para saber "isso é ótimo"?

Andrew Ambrosino: Sim, acho que essa é a mudança central atual. Isso também reflete minha compreensão da relação entre IC (contribuidor individual) e gestor. Não é que gestão vá desaparecer, nem que todos sejam apenas IC, mas agora cada pessoa, de certa forma, exerce ambos os papéis simultaneamente.

Se você é IC, não está mais digitando caractere por caractere. Na verdade, você está gerenciando algo: gerenciando agents, gerenciando o trabalho organizado para concluir tarefas. Se você é gestor de equipe, essencialmente faz a mesma coisa, mas em granularidade diferente.

As pessoas que procuro, além de habilidades profissionais sólidas, precisam ter bom gosto. Porque em um mundo de "tokens infinitos", não podemos produzir conteúdo de baixa qualidade. Você precisa ter a capacidade de distinguir sinal de ruído em meio a um grande volume de conteúdo.

Toda vez que alguém pergunta quantas pessoas tem a equipe Codex, minha resposta é: "Entre 10 e alguns milhares." Parece piada, mas na verdade, o trabalho de todos converge para este produto: pesquisa de modelos, uso de navegador, personalidade do modelo, infraestrutura de frontend, experiência do usuário, tudo isso compõe o produto.

Mas ao mesmo tempo, não recebemos todos os dias PRs (pedidos de código) de milhares de pessoas. A equipe tem engenheiros na casa das dezenas, designers cerca de metade dos engenheiros, mais alguns product managers; a grande maioria são ICs. O impacto da equipe é grande, mas a hierarquia de gestão não é espessa. Aqui há muitas pessoas que já fundaram empresas, muitas que trabalham em grandes empresas com "mentalidade de fundador", e muitas pessoas de excelente bom gosto.

Todo o aplicativo Codex foi moldado pelo ciclo de dogfooding (uso interno). Todos nós temos um desejo comum: fazer o máximo possível do nosso trabalho dentro do aplicativo, mesmo que temporariamente não seja a melhor ferramenta, porque só assim ele terá a chance de se tornar a melhor ferramenta. Frequentemente, deixamos de melhorar certos processos internos de propósito, deixando o produto melhorar sozinho para suportar esses processos. Isso é, na verdade, um estado muito desconfortável. Mas, semana após semana, continua mudando.

Se o Codex tivesse sido lançado três meses antes, teria morrido; a única diferença foi o avanço do modelo

Lenny: Em um ritmo tão acelerado de mudanças, como vocês fazem planejamento? Com quanto antecedência olham?

Andrew Ambrosino: Não temos nada revolucionário no planejamento. O princípio básico é: quanto mais próximo do presente, mais específico o planejamento precisa ser. Não é que não façamos planos de nove meses, mas eles precisam permanecer muito vagos. Porque qualquer precisão que você adicionar a um plano de nove meses é precisão falsa e só vai perder tempo.

No lado do aplicativo, o que você planeja em novembro pode ainda estar certo em dezembro, mas em fevereiro já não é mais.

Na minha empresa anterior, quando começamos a basear o desenvolvimento de funcionalidades na capacidade do modelo, o processo de produto básico desmoronou. Depois, passamos a listar todas as direções de interesse, fazer protótipos, julgar quais já eram viáveis, e adiar as outras. Sempre que a capacidade do modelo dava um salto, pegávamos aquelas coisas adiadas e tentávamos de novo. Porque, no final, se uma funcionalidade é boa ou não, muitas vezes não depende da sua forma, mas de quão inteligente o modelo é. Muitas pessoas sempre ficaram insatisfeitas com minha maneira de planejar. Mas essa coisa é realmente muito difícil.

Lenny: Existe um exemplo concreto de como o timing é importante?

Andrew Ambrosino: Há uma boa história sobre o Codex. Tenho certeza de que o aplicativo Codex que lançamos em fevereiro, se estivesse pronto em novembro e fosse lançado, teria fracassado totalmente no mercado. A única diferença foi o avanço do modelo entre novembro e fevereiro. Mesmo produto, exatamente a mesma forma, resultados completamente diferentes, questão de meses.

Lenny: Então, o que não funciona agora pode funcionar depois? Manter ambições maiores?

Andrew Ambrosino: Sim. Recomendo às pessoas que não julguem facilmente "isso não funciona agora, então é uma funcionalidade ruim"; pode ser que ainda não tenha chegado a hora.

Voltando ao lançamento original do Codex, Codex web. Basicamente, você dava uma tarefa ao modelo, ele fazia e voltava com o resultado. Não parece radical, mas o problema é que ele não fazia bem o suficiente; aquela forma era prematura.

Depois veio o Claude Code, totalmente local, sem nuvem, sem fingir ser muito AGI. Ele faz perguntas, espera, você não pode delegar toda a sua vida a ele. Era muito mais utilizável porque correspondia ao nível de capacidade do modelo na época.

Nós éramos muito "AGI" na época; penso muito nessa lição. Antes, o fracasso de um produto no mercado geralmente dizia muito sobre a forma do produto ou a comunicação. Agora é diferente; você pode precisar lançar a mesma coisa seis vezes até dar certo, a forma pode permanecer exatamente a mesma.

O navegador no aplicativo também foi assim. Tínhamos uma versão funcional; na época do Atlas, já tínhamos agents executando tarefas no navegador. Antes disso, o Operator no ChatGPT, que não deu certo. Mas se você ligar Operator, Atlas, Codex e ChatGPT, verá que há uma linha contínua de evolução entre eles. Essencialmente a mesma funcionalidade, mas, à medida que a inteligência mudava, foi relançada repetidamente, e os resultados mudaram radicalmente.

Depois que um produto ou funcionalidade existe, as pessoas tendem a se concentrar em vários detalhes e micro-otimizações, e elas realmente deveriam. Mas é também por isso que sempre mantemos uma cultura de exploração de baixo para cima. Porque, às vezes, assim como o aplicativo Codex revolucionou o ChatGPT de certa forma, o próprio Codex pode ser revolucionado por novas tentativas no futuro. Você não pode esperar que a mesma equipe produza inovações disruptivas continuamente e ao mesmo tempo se concentre na qualidade do produto e nos detalhes. Em algum ponto, você precisa projetar um mecanismo para que essas duas capacidades coexistam.

Lenny: Qual é a visão do Codex? Para onde você quer levá-lo?

Andrew Ambrosino: Em janeiro e fevereiro deste ano, durante nossos testes internos, descobrimos um claro ajuste produto-mercado (PMF) nos fluxos de trabalho de engenharia e pesquisa. Mas, ao mesmo tempo, pessoas de marketing, comunicação, finanças e jurídico também estavam usando o Codex, mesmo que o aplicativo não fosse amigável para eles; mostrava código, pedia aprovação para executar ferramentas de linha de comando.

Tentamos adicionar capacidades do Codex em outros produtos: aplicativo de desktop do ChatGPT, navegador Atlas. O resultado mais irritante foi que ninguém queria sair do aplicativo Codex para usar aqueles produtos supostamente feitos para eles.

Isso nos deu a percepção de que há muitas sutilezas em comum entre ferramentas de desenvolvedor e ferramentas de trabalho de conhecimento geral. Acreditamos que a forma de produto que estamos construindo é a forma correta para suportar vários cenários verticais profundos. Começa simples e aumenta a complexidade conforme necessário.

Não é um produto do tipo "desenhe um retângulo na tela e tudo deve ser feito dentro dele". É mais como uma base, onde você começa e termina o trabalho, gerencia automações, e ele chama todas as ferramentas que você precisa. Alguns chamam isso de "super app"; eu gostaria que não tivessem chamado assim, porque agora ouço essa palavra quase todos os dias.

Dan Shipper teve uma ideia interessante: ele acha que no futuro usaremos ferramentas SaaS "de dentro para fora" no Codex; Notion, Linear, Salesforce não serão abertas no navegador, mas agentes no Codex as operarão. E realmente estamos fazendo isso: navegador no aplicativo, extensão Chrome, uso de computador (computer use), todas essas são formas de o Codex interagir com ferramentas externas.

Um exemplo excelente: nosso produtor de vídeo interno Brent usou o Codex para editar o vídeo de lançamento do Codex. O Codex não é um editor de vídeo, não tem aquela interface. Mas ele entende que Brent está usando o Premiere Pro e pode fazer algumas modificações editando os arquivos por trás do Premiere Pro. Quando descobriu que não conseguia fazer tudo, ele mesmo escreveu uma extensão para o Premiere Pro, instalou no Premiere Pro e passou a conversar com ele através dessa extensão. Ficamos chocados ao ver isso.

É um bom modelo: ferramentas profissionais fazem coisas profissionais. O Codex não precisa ser um editor de vídeo melhor; só precisa interagir perfeitamente com ferramentas profissionais.

Saber escrever código não é mais importante; saber deletar código é importante

Lenny: De escrever código manualmente para IA escrever 100% do código, e agora agents e loops. Como as equipes mais avançadas trabalham hoje?

Andrew Ambrosino: Loops? Isso foi na semana passada.

Estamos discutindo constantemente a questão "qual porcentagem do produto é código escrito por IA". Pelos padrões do ano passado, agora 100% do nosso código é escrito por IA. Então a questão não é mais "quanto é escrito por IA", mas "o código foi escrito supervisionado ou não supervisionado"; essa é uma dimensão completamente diferente. Acolho que esses padrões sejam constantemente atualizados, porque isso significa que estamos progredindo no produto.

Fizemos muitas explorações em desenvolvimento autônomo de software, como muita engenharia de "harness", tipo "e se o modelo fizer coleta de lixo e limpeza automática na base de código durante a noite?"

Mas atualmente todos os modelos têm um problema: eles sempre aumentam a complexidade. Se alguém da pesquisa está ouvindo: por favor, façam o modelo aprender a deletar código. Quando você tenta deixar o desenvolvimento totalmente autônomo, isso se torna um problema sério, tanto no nível humano quanto no nível da base de código.

Feature requests (solicitações de funcionalidades) também. Como ensinar o modelo a julgar quais funcionalidades valem a pena, quais devem ser ignoradas, quais devem ser mescladas e redefinidas? E como ensinar o modelo a construir as abstrações corretas?

Essas capacidades estão melhorando continuamente. Mas não acho que já chegamos ao ponto de configurar um loop para o modelo "melhorar o aplicativo" automaticamente, monitorando constantemente Twitter, Slack e e-mail, e então iterar de forma autônoma. Embora, na verdade, estejamos tentando tornar isso realidade.

Lenny: Você acha que vamos chegar a esse ponto? Tipo definir um objetivo: "vencer"?

Andrew Ambrosino: "/goal me gere 1 bilhão de dólares." Não sei. Não vou dizer que nunca ou sempre.

Lenny: Como você, como líder de produto e engenharia, usa IA no seu trabalho?

Andrew Ambrosino: Acho que talvez eu tenha o melhor trabalho do mundo agora.

Quando comecei o Codex, meu objetivo pessoal era torná-lo bom o suficiente para que eu pudesse usá-lo para escrever o código do Codex. Era um ciclo de produto de uso pessoal super apertado: eu não conseguia fazer algo, então consertava, e então conseguia fazer, e conseguia fazer mais.

Depois meu papel mudou. Precisei fazer mais descoberta de produto, entender o que a equipe estava fazendo, corrigir desvios. Então o Codex se tornou a ferramenta para eu fazer essas coisas. "Me ajude a criar uma planilha com esses dados." "Faça uma pesquisa interna aprofundada sobre o que já foi explorado nessa direção."

A série de lançamentos de maio: navegador no aplicativo, uso de computador (computer use), criação de artefatos (artifact creation), foi a primeira vez que gerenciamos um lançamento com "vibe coordination" (coordenação por vibe). Eu tinha um documento no Notion com todas as tarefas e usava o Codex para ir automaticamente em PRs e canais do Slack coletar progresso, atualizar o rastreador de status; na época, achei que era a vanguarda de como gerenciar lançamentos de produto.

Agora, todas as manhãs, vejo o relatório diário gerado pelo Codex, que filtra os cerca de 3000 canais do Slack que participo para o que precisa da minha atenção. Posso responder "me dê cinco perguntas e eu respondo". Ele se autoajusta; digo "da próxima vez, preste menos atenção a esse fluxo de trabalho" ou "isso aconteceu mas não apareceu no relatório, garanta que seja capturado no futuro", e ele atualiza a forma de notificação, ajusta o foco.

Lenny: Como isso é configurado? Qual é o fluxo de trabalho?

Andrew Ambrosino: Ainda está em fase de descoberta. É basicamente uma tarefa agendada: "Verifique meus canais do Slack, essas são as coisas que me importam, organize nessas categorias, aqui está algum contexto." As primeiras vezes podem precisar de orientação. A boa notícia é que não preciso descobrir como editar as instruções; converso diretamente e digo "da próxima vez, me ajude a mudar isso", e ele atualiza.

Mas acho que esse é o problema central da forma de chatbot: eu sei como configurar porque para mim é descoberta de produto. Mas se você não trabalha na OpenAI nem desenvolve isso, não vai querer descobrir. Precisamos descobrir como tornar essas formas utilizáveis para pessoas comuns.

Lenny: Eu mesmo usei o Codex para fazer uma automação de filtragem de spam. Uma das etapas envolvia ir ao console do Google Cloud e configurar vários gatilhos de API, uma interface muito chata. Pedi ao Codex para fazer e ele assumiu o controle do meu computador, usando a funcionalidade de uso de computador (computer use).

Andrew Ambrosino: Ele simplesmente: "Não me importo se você tem conectores, camarada, vou começar a clicar."

É muito interessante como definir os limites entre conectores, navegador no aplicativo, extensão Chrome e uso de computador. Muitas vezes, esses limites são explorados por tentativa e erro.

Acho esses fluxos de trabalho pessoais particularmente interessantes. Todo mundo está tentando várias coisas, cada um monta sistemas completamente diferentes. Mas gradualmente, alguns padrões comuns emergem. E então percebemos: "Isso deveria ser uma experiência de primeira classe no produto."

Por exemplo, memória (memory). Muitas pessoas estão configurando bases de conhecimento no Obsidian ou espaços no Notion para construir seus próprios palácios mentais. Você não deveria precisar fazer isso sozinho; deveria haver uma funcionalidade de memória suficientemente genérica para fazer isso por você. Estamos constantemente filtrando o que funciona a nível pessoal, mas deve ficar no nível pessoal, e o que deve entrar no produto como componente básico.

Lenny: As pessoas de fora só veem você vencendo. Mas certamente houve coisas que não deram certo?

Andrew Ambrosino: É engraçado ouvir você descrever assim. Na verdade, é a primeira vez que sinto que não estou fracassando.

Antes, empreendi por muitos anos e, no final, basicamente desmontei e vendi a empresa. Trabalhar em indústrias altamente regulamentadas foi como um fracasso contínuo. Depois fui para outra startup, fazendo ferramentas de IA em outra indústria fechada e regulamentada, e também não deu certo repetidamente. Na verdade, fracassei muito. Às vezes é só uma questão de timing, quando habilidades, paixão e janela de mercado se alinham.

Mesmo agora, neste projeto que combina Codex e ChatGPT, há inúmeros pequenos fracassos. Dizemos "deveria ser assim", postamos no Slack, e vêm 2000 mensagens dizendo como somos estúpidos. É isso que gosto na OpenAI: as pessoas nos dizem diretamente, são impiedosas com fracassos de produtos internos, e é por isso que os produtos externos são bons. Antes de chegar onde estou, fracassei por cerca de 10 a 15 anos. Então ainda fico um pouco surpreso todos os dias por as coisas estarem dando certo.

Lenny: Algum conselho final para os leitores?

Andrew Ambrosino: Não se "case" com seu fluxo de trabalho atual. O que realmente deve ser mantido são os resultados que só você pode entregar de forma única. E então, continue tentando mudar seu processo. Se sua habilidade de maior orgulho é "sou o melhor no auto layout do Figma", o que você está fazendo? A IA também vai ficar melhor que você. Encontre coisas que valem a pena fazer, e então descubra como fazê-las.