Responsável pelo Codex: «todos são construtores» é uma péssima ideia.

Andrew Ambrosino é o líder da equipa OpenAI Codex. Designer de formação, já trabalhou como engenheiro, produto, e fundou startups. Agora, o Codex que lidera tem mais de 5 milhões de utilizadores ativos semanais. Ele é provavelmente uma das pessoas mais indicadas para responder "como fazer produto na era da IA".

Na sua opinião, quando quase todos na empresa conseguem rapidamente criar um protótipo funcional, o verdadeiro desafio já não é "se consegue fazer", mas sim "se deve fazer isto".

Numa conversa com Lenny, Andrew Ambrosino detalhou o processo de desenvolvimento interno da OpenAI: quando o custo de implementação é significativamente reduzido pela IA, cada etapa do desenvolvimento de produto — desde a definição do projeto, documentação, protótipo, design, até à divisão de funções, colaboração em equipa e planeamento de produto — está a mudar. Que regras antigas estão a perder validade? Que novos padrões estão a formar-se? Quando a implementação já não é escassa, o que é que realmente se torna escasso?

Algumas ideias centrais:

Quando 90 pessoas conseguem fazer 90 protótipos que parecem prontos para lançar, o mais valioso é o taste (gosto).

Um dos critérios rígidos de contratação da equipa Codex é o taste: conseguir distinguir sinal de ruído numa imensidão de conteúdo. Num mundo com "tokens infinitos", não querem produzir lixo.

Se o Codex tivesse sido lançado três meses antes, teria fracassado completamente; a única diferença foi o avanço do modelo. Não julgues facilmente uma funcionalidade como má; pode ser que ainda não tenha chegado a sua hora.

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

Tal como o Codex revolucionou o ChatGPT, o Codex também pode ser revolucionado por novas tentativas. É preciso preservar uma cultura de exploração bottom-up, não se pode esperar que a mesma equipa refine os detalhes e ao mesmo tempo se revolucione a si própria.

Segue-se o essencial da conversa.

O custo de implementação diminuiu, o taste tornou-se mais importante

Lenny: Disseste que a IA está a mudar a forma de trabalhar em produto. Estás agora talvez na equipa de produto de IA mais avançada do mundo. Em concreto, como é que a forma de trabalhar da equipa de produto mudou em relação a há dois anos?

Andrew Ambrosino: Agora, como líder de equipa, a coisa mais difícil é que o processo se inverteu.

Antigamente, todos sabiam como fazer produto: primeiro investigação, depois ideias, depois protótipo. Mesmo depois de já termos ultrapassado a era do desenvolvimento em cascata, a lógica de base era a mesma: implementar era caro. Por isso, antes de implementar, eliminavas todos os riscos através de documentos, investigação e protótipos. Porque protótipo e design são mais baratos do que desenvolvimento — essa era a suposição básica do passado.

Agora, essa suposição mudou completamente. Qualquer pessoa pode fazer qualquer coisa. Acredito genuinamente que, a partir do zero, ao dialogar com estes modelos — sejam os nossos ou os de outras empresas — consegues construir qualquer funcionalidade que queiras. Isto não é necessariamente a parte mais difícil do desenvolvimento de software, mas é muito fixe.

Dás às pessoas tokens ilimitados, e em toda a OpenAI há pessoas com iniciativa e boas ideias. Por isso, toda a gente está a fazer todo o tipo de coisas. Neste momento, na empresa, há uma funcionalidade que precisamos urgentemente, e tenho a certeza de que há 90 equipas pequenas, não coordenadas, a implementá-la e a experimentá-la de forma independente. Dessas 90 tentativas, quais são boas? Que partes devem ser integradas noutros aspetos? Como defini-la? Deve fazer parte de outra funcionalidade? Quantas opções deve ter o interruptor? São estas as questões.

Portanto, a resposta curta é: inverteu-se. Não é que as pessoas estejam a fazer papéis fundamentalmente diferentes, nem que as competências tenham desaparecido ou os papéis deixem de existir. Implementar já não é a parte mais cara; atrevo-me a dizer que o mais caro é o taste.

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

Andrew Ambrosino: Sim, isso acontece muito. Não é só na OpenAI; já viste muitos responsáveis de produto a dizer "o PRD morreu, o protótipo é que manda", mas eu discordo totalmente dessa opinião.

Porque implementar tornou-se barato em todos os meios, e é muito tentador saltar a reflexão e ir direto ao protótipo. Especialmente se não fores engenheiro, se nunca escreveste código, se não tens interesse ou tempo, dizes: "o PRD morreu, deixa-me mostrar-te o que quero."

Mas também notei o fenómeno oposto. Para os engenheiros, tornou-se tentador escrever muita documentação, toneladas de documentação que não vale a pena ler. Não estou a dizer que quem escreve documentação é mau; mas sim que, quando a implementação se torna abundante, escolher o formato certo para expressar a tua opinião torna-se realmente importante.

Se queres clarificar um produto num domínio nebuloso, talvez devas escrever um documento. Se queres que as pessoas experimentem e testem à pressão um padrão de interação, faz um protótipo. O importante é escolher o meio certo.

Lenny: Há um conceito chamado "primal mark" (marca primitiva), o primeiro toque do pintor na tela, de onde tudo o resto se desenvolve. Queres dizer que, por vezes, o protótipo é a marca primitiva errada? Porque as pessoas ficam ancoradas nele, em vez de pensar em soluções maiores?

Andrew Ambrosino: Sim. No passado, havia um sinal implícito: a aparência de algo indicava em que fase do processo se encontrava. Se vias algo com aspeto de produto finalizado, significava que já estava numa fase avançada, com riscos eliminados, design revisto e objetivos de negócio razoáveis.

Agora, estas coisas estão dissociadas. A razão é que, antes, para obter recursos para construir, precisavas de reduzir suficientemente o risco; agora, esse limiar desapareceu. Assim, algo que está apenas em fase de exploração já parece pronto para lançar, visualmente está preparado. Mas pode não ser a direção certa, pode não corresponder às conclusões da investigação, pode não ser o que os utilizadores realmente precisam, nem a melhor opção para o negócio.

Não quero exagerar a importância do taste. Mas, mais uma vez, saber o que fazer, como apresentar, como atingir o objetivo, que meio usar — isto está a tornar-se a competência mais crucial em todas as áreas.

Lenny: A palavra taste está na moda agora. Em concreto, o que é que entendes por "bom gosto"?

Andrew Ambrosino: O taste tem de ser desconstruído.

Há a parte estética, claro, mas também há a parte de pensamento sistémico: como é que isto se encaixa no sistema global? Há a parte direcional: para onde vamos, de que tema faz parte? Há a parte expressiva: como apresentar esta informação? E há também uma parte do taste ao nível da interação: esta animação não corresponde ao significado que pretende transmitir, é demasiado abrupta, não condiz com a mensagem.

Tudo isto é realmente importante, mas a verdadeira questão do taste é: se podemos fazer tudo, qual é o objetivo? Como é que lá chegamos?

Lenny: À medida que a IA se torna mais forte e faz cada vez mais coisas, em que áreas é que o cérebro humano continuará a ter valor? O taste parece ser uma delas. Mas os outputs de design da IA ainda não são bons; porque é que os melhores modelos não conseguem fazer bem design?

Andrew Ambrosino: Há razões práticas e outras mais difíceis de resolver. O design é mais difícil de avaliar do que o software; criar um ciclo de feedback para treinar o modelo sobre o que é bom design é muito mais complicado 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 deram prioridade a tornar os modelos bons em coisas que aceleram a investigação em IA. Um modelo que escreve código correto acelera claramente a investigação; o design não consegue fazer essa mesma defesa. Não estou a dizer que o design não é importante, simplesmente não está nesse ciclo virtuoso.

Estas são razões práticas, que desaparecerão. Os modelos tornar-se-ão bastante bons em design, mas há coisas mais difíceis.

Primeiro, o design tem uma componente cultural. Lembras-te no ano passado de todos os sites novos a copiar o design do Linear. Se o modelo produz sempre o site do Linear, esse não é o desafio. A novidade no design é muito mais importante do que na engenharia de software. Na engenharia, queres que o modelo siga padrões conhecidos; no design, precisas de alguma aleatoriedade e novidade.

Segundo, a interação entre design visual e código. Se amanhã a empresa mudar de marca, a abordagem superficial é atualizar os 263 componentes um a um. A abordagem profunda é perceber que duas coisas com aspeto diferente fazem, na verdade, parte do mesmo estilo de lista e transmitem o mesmo padrão de interação. Esta camada de abstração está fora do alcance da tecnologia atual.

Lenny: Jenny Wen (design lead do Claude Code da Anthropic) disse que o processo de design morreu, que é melhor construir diretamente. O que achas?

Andrew Ambrosino: Provavelmente estou de acordo com a Jenny em muitas coisas. O processo de design formal, concordo com ela, morreu. E já não era fã desse processo antes da IA.

Há uns anos, quando tinha uma startup, havia um artigo chamado "A Fábrica de Casos de Estudo", que descrevia como os designers eram treinados para seguir um processo fixo e gradualmente passavam a valorizar mais o processo do que o resultado. Se algo passava pelo processo, assumia-se automaticamente duas conclusões: primeiro, que seria bom — o processo garantia qualidade; segundo, mesmo que ninguém usasse, era bom porque tinha passado pelo processo.

Investigação de utilizadores, divergência, convergência — o quadro está certo, mas sempre foi um pouco académico. A premissa desse processo era que implementar era caro, só se podia construir uma vez, por isso era necessário esgotar todo o espaço de problemas e soluções antes de construir.

Depois vieram o Figma e o Origami, e integrámos protótipos interativos no processo. Agora, o problema é que podemos trazer toda a implementação para o início do processo. Um protótipo completamente refinado parece pronto para lançar. Quando pessoas suficientes na empresa o veem, perguntam: "Podemos lançar já?" Mas, na realidade, ainda estamos numa fase inicial de exploração de design, apenas ninguém o diz.

Portanto, dizer que o processo de design morreu é ao mesmo tempo certo e errado. Se estás vinculado a ferramentas específicas e a rotinas diárias específicas, então sim, morreu. Mas a consciência de "em que fase do processo estamos agora" é mais importante do que nunca.

O perigo está em amarrar o processo de design a um meio específico. Os designers têm agora 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 — um código drasticamente simplificado que simula todas as interações do produto real. Podes usá-lo para "vibe coding" (codificação por ambiente) e dizer "e se a barra lateral ficasse assim? e se aparecesse um painel?" Isto é uma nova ferramenta para designers, mas requer a velha consciência: onde estás no processo.

Funções e papéis estão a fundir-se, mas o PM não vai desaparecer

Lenny: Muitas empresas falam em "morte dos papéis". Achas que a divisão entre PM, engenheiro e designer vai desaparecer completamente?

Andrew Ambrosino: Algumas empresas gostam de seguir modas e ir a extremos. O perigo de eliminar o conceito de papéis é que pode eliminar ao mesmo tempo a perceção de que "estas áreas têm especialistas com melhores práticas que podem ser aprendidas".

Ouço muitas empresas a dizer "vamos acabar com o papel de produto", acho que é uma péssima ideia, e depois dizem "toda a gente é builder". O resultado é que a disciplina de gestão de produto, que já acumulou verdadeiras melhores práticas e verdadeiros erros, é simplesmente descartada. Porque alguém escreveu umas linhas de código e acha que está tudo bem — isso não é um bom estado.

Acolho bem o desaparecimento de fronteiras do tipo "isto não é a tua área, não mexe", mas é preciso equilíbrio. Nem toda a gente pode fazer tudo, seja em amplitude ou profundidade, e é por isso que os gestores não vão desaparecer.

Além disso, cada disciplina tem componentes de competência. Muitos engenheiros não reconhecem isso, acham que a engenharia tem competências, mas os outros papéis são "só ambiente". Não é assim. Saberes usar Excel não significa que possas trabalhar na equipa financeira.

Acho que o que está a acontecer é mais que as pessoas conseguem colaborar entre funções mais facilmente, e aprender melhores práticas de outras áreas também se tornou mais fácil, sem que a tua eficiência num papel esteja ligada à capacidade de usar ferramentas específicas.

Passei muito tempo a achar que não devia ser engenheiro de software, porque não me importava com linguagem assembly nem queria decorar o sistema de tipos do TypeScript. Estes papéis sempre tiveram barreiras, como se "ser bom neste papel equivalesse a dominar esta ferramenta". Acho que isso está a começar a dissolver-se, mas as pessoas exageram.

Lenny: Na vossa equipa Codex, há efetivamente mais fusão de papéis. Como é que é na prática?

Andrew Ambrosino: Na equipa Codex, vemos mais fusão de papéis do que noutras equipas da empresa ou noutras indústrias. Em parte, porque é um produto técnico para engenheiros. Os nossos designers falam a linguagem dos engenheiros, os nossos PMs falam linguagem técnica e sabem escrever código.

Temos uma maneira interna de descrever a colaboração: hoje em dia, a sobreposição entre papéis é muito maior do que no passado. Definir uma pessoa já não é pela fronteira de "onde acaba o design e começa a engenharia", mas sim pela distribuição média de todo o seu trabalho.

Se olhares para todas as tarefas que alguém da equipa de design faz, pode incluir muita programação e muito trabalho de produto. Mas se tirares a "média" dessas tarefas, essa pessoa acabará por cair numa zona mais inclinada para o design.

Lenny: Disseste que o trabalho do PM é mais como "defesa por zona" (zone defense). Podes explicar?

Andrew Ambrosino: Se dois PMs trabalham demasiado próximos, normalmente não é bom sinal. Devias olhar para a equipa como um layout orientado por forças: onde há lacunas? Que áreas ainda não estão cobertas?

No mundo de hoje, curadoria, orientação e alinhamento tornaram-se o trabalho mais importante. Toda a gente está constantemente a lançar ideias, o ambiente está cheio de ruído. O modelo antigo, top-down, com planeamento anual, já não funciona. Precisamos de alguém que funcione como gatekeeper do bom gosto, que guie uma ideia desde o conceito até ao produto, e isso significa que tens de cobrir todos os cantos da empresa.

Por isso, é preciso espalhar a equipa, perceber quem é bom em quê, manter alguma distância entre si, garantir uma cobertura abrangente. Depois, preencher as lacunas, por exemplo: "queremos contratar um engenheiro com forte pensamento de produto." Não queremos que um grupo escreva toneladas de código e depois toda a equipa de produto tenha de rever e alinhar a consistência do produto. Queremos que todos tenham essas capacidades, mas as áreas de especialização precisam de mudar.

Lenny: Portanto, a pessoa mais valiosa agora é aquela que consegue levar uma ideia do início ao fim e tem taste para saber "isto é ótimo"?

Andrew Ambrosino: Sim, acho que é essa a mudança central. Também reflete a minha compreensão da relação entre IC (contribuidor individual) e gestor. Não estou a dizer que a gestão vai desaparecer, nem que todos são apenas ICs, mas sim que agora cada pessoa desempenha, em certo grau, ambos os papéis.

Se és IC, já não estás a escrever código caráter a caráter. Na verdade, estás a gerir algumas coisas: gerir agents, gerir o trabalho organizado para cumprir tarefas. Se és gestor de equipa, fazes essencialmente o mesmo, apenas com granularidade diferente.

As pessoas que procuro, além de terem competências sólidas na sua área, precisam de ter taste. Porque num mundo com "tokens infinitos", não podemos produzir lixo. Tens de ser capaz de distinguir sinal de ruído numa imensidão de conteúdo.

Sempre que alguém pergunta quantas pessoas tem a equipa Codex, respondo: "Entre 10 e alguns milhares." Parece uma piada, mas na verdade, o trabalho de todos converge para este produto: investigação de modelos, uso do navegador, personalidade do modelo, infraestrutura de front-end, experiência do utilizador — tudo isto faz parte do produto.

Ao mesmo tempo, não estamos a receber PRs (pedidos de código) de milhares de pessoas todos os dias. A equipa tem engenheiros na casa das dezenas, designers cerca de metade dos engenheiros, e alguns PMs. A maioria são ICs. A equipa tem um grande alcance, mas a hierarquia de gestão não é espessa. Há muitas pessoas que já fundaram empresas, muitas que trabalham com "mentalidade de fundador" em grandes empresas, e muitas com excelente taste.

Toda a aplicação Codex foi moldada pelo loop de dogfooding (auto-uso). Todos partilhamos o desejo de usar a aplicação para fazer o nosso trabalho o máximo possível, mesmo que ainda não seja a melhor ferramenta, porque só assim pode tornar-se a melhor. Muitas vezes, evitamos intencionalmente melhorar certos processos internos, deixando que o próprio produto melhore para os suportar. É um estado muito desconfortável. Mas, semana após semana, continua a mudar.

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

Lenny: Com um ritmo de mudança tão rápido, como é que fazem planeamento? Até onde olham?

Andrew Ambrosino: Não temos nada de revolucionário no planeamento. O princípio básico é: quanto mais próximo do presente, mais específico deve ser o plano. Não é que não façamos planos a nove meses, mas esses planos têm de ser muito vagos. Qualquer precisão que adiciones a um plano a nove meses é falsa precisão, só perde tempo.

Do lado da aplicação, o que planeias em novembro pode ainda estar certo em dezembro, mas em fevereiro já não é nada disso.

Na minha empresa anterior, quando começámos a desenvolver funcionalidades baseadas nas capacidades do modelo, o processo de produto básico basicamente desmoronou. Depois, passámos a listar todas as direções que nos interessavam, fazer protótipos, determinar quais já eram viáveis, e colocar as outras de lado. Sempre que o modelo dava um novo salto, voltávamos a testar as que tinham ficado de lado. Porque, muitas vezes, se uma funcionalidade é suficientemente boa ou não, não depende da sua forma, mas sim de quão inteligente o modelo é. Muitas pessoas sempre ficaram insatisfeitas com a minha forma de planear. Mas é realmente muito difícil.

Lenny: Há algum exemplo concreto que mostre como o timing é importante?

Andrew Ambrosino: Há uma boa história sobre o Codex. Tenho a certeza absoluta de que a aplicação Codex que lançámos em fevereiro, se tivesse ficado pronta em novembro e tivesse sido lançada, teria falhado completamente no mercado. A única diferença foi que o modelo evoluiu entre novembro e fevereiro. O mesmo produto, exatamente a mesma forma, resultados completamente diferentes, apenas com alguns meses de diferença.

Lenny: Portanto, o que não funciona agora pode vir a funcionar? Devemos manter maior ambição?

Andrew Ambrosino: Sim. Recomendo que as pessoas não digam facilmente "isto não funciona agora, por isso é uma má funcionalidade"; pode ser que ainda não tenha chegado a sua hora.

Voltando ao lançamento inicial do Codex, o Codex web. Basicamente, davas uma tarefa ao modelo, ele executava-a e trazia-te o resultado. Não parecia radical, mas o problema é que não o fazia suficientemente bem; aquela forma era demasiado avançada para a altura.

Depois apareceu o Claude Code, totalmente local, sem ligação à nuvem, sem fingir ser super AGI. Fazia perguntas, esperava, não podias delegar-lhe toda a tua vida. Era muito mais útil, porque correspondia ao nível de capacidade do modelo na altura.

Nós fomos demasiado "AGI" na altura; penso muitas vezes nessa lição. Antigamente, o fracasso de um produto no mercado dizia muito sobre a forma do produto ou a comunicação. Agora é diferente; podes ter de lançar a mesma coisa seis vezes até funcionar, com a forma exatamente igual.

O mesmo aconteceu com o navegador dentro da aplicação. Já tivemos uma versão funcional; na era Atlas, já tínhamos agents a executar tarefas no navegador. Antes disso, o Operator no ChatGPT, que não funcionou. Mas se olhares para Operator, Atlas, Codex e ChatGPT em sequência, vês que se pode traçar uma linha contínua de evolução. É essencialmente a mesma funcionalidade, apenas re-lançada à medida que a inteligência avança, e os resultados mudam completamente por causa disso.

Depois de um produto ou funcionalidade existir, é fácil focar-se em vários detalhes e micro-otimizações, e as pessoas devem fazê-lo. Mas é também por isso que mantemos sempre uma cultura de exploração bottom-up. Porque, tal como a aplicação Codex de certa forma revolucionou o ChatGPT, o próprio Codex pode ser revolucionado por novas tentativas no futuro. Não podes esperar que a mesma equipa produza consistentemente inovações disruptivas e, ao mesmo tempo, se mantenha focada na qualidade do produto e no polimento de detalhes. Numa determinada fase, tens de conceber um mecanismo que permita que ambas as capacidades coexistam.

Lenny: Qual é a visão do Codex? Para onde o queres levar?

Andrew Ambrosino: Em janeiro e fevereiro deste ano, durante os testes internos, descobrimos que o Codex tinha um claro PMF (product-market fit) nos fluxos de trabalho de engenharia e investigação. Ao mesmo tempo, pessoas de marketing, comunicação, finanças e jurídico também estavam a usar o Codex, mesmo que a aplicação não fosse amigável para eles — mostrava-lhes código, pedia-lhes para aprovar a execução de ferramentas de pesquisa na linha de comandos.

Tentámos integrar as capacidades do Codex noutros produtos: aplicação de desktop do ChatGPT, navegador Atlas. O resultado foi o pior possível: ninguém queria sair da aplicação Codex para usar os produtos que supostamente foram feitos para eles.

A lição que tirámos é que há muitas subtilezas comuns entre ferramentas de developer e ferramentas de trabalho de conhecimento geral. Acreditamos genuinamente que a forma de produto que estamos a construir é 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 "desenha um retângulo no ecrã e tudo tem de ser feito lá dentro". É mais como uma base: começas aqui, terminas aqui, geres automações, e ele convoca todas as ferramentas de que precisas. Alguém chamou a isto "super app"; gostava que não tivessem feito isso, porque agora ouço essa palavra todos os dias.

O Dan Shipper teve uma ideia interessante: no futuro, vamos usar ferramentas SaaS "de dentro para fora" dentro do Codex — Notion, Linear, Salesforce não serão abertas no navegador, mas sim operadas por um agent dentro do Codex. E nós estamos a fazer exatamente isso: navegador dentro da aplicação, extensão Chrome, computer use — tudo formas de o Codex interagir com ferramentas externas.

Um exemplo perfeito: o 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 essa UI. Mas percebe que o Brent está a usar o Premiere Pro, e consegue fazer alterações editando os ficheiros subjacentes do Premiere Pro. Quando percebeu que não conseguia fazer tudo, escreveu ele próprio uma extensão para o Premiere Pro, instalou-a no Premiere Pro e passou a comunicar com o Premiere Pro através dela. Ficámos chocados ao ver isto.

É um bom padrão: ferramentas especializadas fazem coisas especializadas. O Codex não precisa de ser um melhor editor de vídeo; basta que consiga interagir perfeitamente com as ferramentas especializadas.

Saber escrever código já não é importante; saber apagar código é que é importante

Lenny: Desde escrever código manualmente, passando por IA a escrever 100% do código, até aos agents e loops atuais. Como é que as equipas mais avançadas trabalham realmente?

Andrew Ambrosino: Loops? Isso foi na semana passada.

Temos discutido constantemente a questão de "que percentagem do produto é escrita por IA". Pelos padrões do ano passado, agora 100% do nosso código é escrito por IA. Por isso, a questão já não é "quanto é escrito por IA", mas sim "o código é escrito com supervisão ou sem supervisão" — é uma dimensão completamente diferente. Acolho bem esta atualização constante dos padrões, porque significa que estamos a fazer progresso no produto.

Fizemos muitas explorações em desenvolvimento autónomo de software, como "harness engineering" e "e se o modelo fizer limpeza de código e recolha de lixo automaticamente durante a noite?"

No entanto, todos os modelos atuais têm um problema: estão sempre a aumentar a complexidade. Se alguém da investigação está a ouvir: por favor, ensinem o modelo a apagar código. Quando tentamos deixar o desenvolvimento completamente autónomo, isto torna-se um problema grave, tanto a nível humano como a nível do código.

O mesmo se aplica a pedidos de funcionalidades. Como ensinar o modelo a avaliar quais funcionalidades valem a pena, quais devem ser ignoradas, quais devem ser fundidas e redefinidas? E como ensinar o modelo a construir as abstrações corretas?

Estas capacidades estão a melhorar constantemente. Mas não acho que já tenhamos chegado ao ponto de criar um loop em que o modelo "melhora a aplicação" automaticamente, ouvindo constantemente o Twitter, Slack e email, e iterando autonomamente. Apesar disso, estamos a tentar torná-lo realidade.

Lenny: Achas que vamos lá chegar? Onde defines um objetivo e dizes "ganha"?

Andrew Ambrosino: "/goal ganha mil milhões de dólares para mim." Não sei. Não vou dizer que nunca ou que sempre.

Lenny: Tu, como responsável de produto e engenharia, como é que usas a IA no teu trabalho?

Andrew Ambrosino: Acho que tenho o melhor trabalho do mundo.

Quando comecei o Codex, o meu objetivo pessoal era torná-lo suficientemente bom para eu poder usá-lo para escrever o código do Codex. Era um loop de auto-uso muito apertado: não conseguia fazer algo, corrigia-o, depois conseguia, e depois conseguia fazer mais coisas.

Depois o meu papel mudou. Precisava de fazer mais descoberta de produto, perceber o que a equipa estava a fazer, corrigir desvios. O Codex tornou-se a ferramenta para fazer essas coisas. "Ajuda-me a criar uma folha de cálculo com estes dados." "Faz uma pesquisa interna aprofundada sobre o que já foi explorado nesta direção."

A série de lançamentos em maio — navegador dentro da aplicação, computer use, criação de artefactos — foi a primeira vez que gerimos um lançamento com "vibe coordination" (coordenação por ambiente). Tinha um documento Notion com todas as tarefas pendentes, e o Codex ia automaticamente aos PRs e canais Slack recolher progresso, atualizar o rastreador de estado. Na altura, achei que era o estado da arte na gestão de lançamentos de produto.

Agora, todas as manhãs, vejo o relatório diário que o Codex gera para mim, filtrando dos 3000 canais Slack de que faço parte as coisas que precisam da minha atenção. Posso responder "dá-me cinco perguntas, eu respondo". O Codex ajusta-se automaticamente: digo "da próxima vez, foca menos neste fluxo de trabalho" ou "isto aconteceu mas não apareceu no relatório, garante que apanhas da próxima"; ele atualiza as notificações, ajusta o foco.

Lenny: Como é que se configura isso? Qual é o fluxo?

Andrew Ambrosino: Ainda está em fase de descoberta. É uma tarefa agendada: "percorre os meus canais Slack, estas são as coisas que me interessam, organiza-as nestas categorias, aqui está algum contexto." As primeiras vezes podem precisar de orientação. A vantagem é que não preciso de saber como editar as instruções; digo "da próxima vez, muda isto para mim" e ele atualiza.

Mas acho que isto também é o problema central da forma do chatbot. Eu sei configurá-lo, porque para mim é descoberta de produto. Mas se não trabalhares na OpenAI, se não estiveres a desenvolver isto, não vais querer descobrir como funciona. Precisamos de pensar como tornar estas coisas utilizáveis para pessoas comuns.

Lenny: Eu também fiz uma automação com o Codex para filtrar spam. Numa das etapas, precisei de ir à consola do Google Cloud configurar uma série de acionadores de API, e a interface era muito chata. Pedi ao Codex para o fazer, e ele assumiu o controlo do meu computador, usando a funcionalidade computer use.

Andrew Ambrosino: Ele simplesmente: "não me interessa se não há conector, vou começar a clicar."

É muito interessante como dividimos as fronteiras entre conectores, navegador dentro da aplicação, extensão Chrome e computer use. Muitas vezes, essas fronteiras são definidas intuitivamente.

Acho estes fluxos de trabalho pessoais particularmente interessantes. Toda a gente está a experimentar coisas diferentes, cada um monta sistemas completamente diferentes. Mas, com o tempo, alguns padrões comuns emergem. Depois, percebemos: "isto devia ser uma experiência de primeira classe no produto."

Por exemplo, a memória. Muitas pessoas configuram bases de conhecimento Obsidian ou espaços Notion para construir o seu palácio mental. Não devias ter de fazer isso; devia haver uma funcionalidade de memória suficientemente genérica para o fazer. Estamos constantemente a selecionar: o que funciona para o indivíduo mas deve ficar a nível pessoal, e o que deve entrar no produto como componente base.

Lenny: De fora, só se vê o vosso sucesso. Mas certamente já houve coisas que não funcionaram?

Andrew Ambrosino: É engraçado ouvires descrever assim. Esta é a primeira vez que sinto que não estou a falhar.

Passei muitos anos a empreender, e no fim acabei por desmantelar e vender a empresa. A trabalhar em indústrias altamente reguladas, foi como uma falha contínua. Depois fui para outra startup, noutra indústria fechada e regulada, a fazer ferramentas de IA, e também foi uma falha atrás de outra. Na verdade, falhei muitas vezes. Às vezes, é apenas uma questão de momento: as competências, a paixão e a janela de mercado alinharam-se.

Mesmo neste projeto de combinar Codex e ChatGPT, houve inúmeras pequenas falhas. Dizíamos "devia ser assim", publicávamos no Slack, e vinham 2000 mensagens a dizer como éramos estúpidos. É isso que gosto na OpenAI: as pessoas dizem-nos diretamente, são implacáveis com o fracasso dos produtos internos, e é por isso que os externos saem bem. Falhei durante cerca de 10 a 15 anos antes de chegar onde estou. Por isso, ainda fico um pouco surpreso todos os dias por as coisas estarem a correr bem.

Lenny: Que conselho final dás aos leitores?

Andrew Ambrosino: Não te cases com o teu fluxo de trabalho atual. O que deves manter são os resultados que só tu podes entregar de forma única. Depois, continua a tentar mudar o teu processo. Se a tua maior habilidade é "sou o melhor no auto layout do Figma", o que é que estás a fazer? A IA vai tornar-se melhor que tu nisso. Encontra coisas que valham a pena fazer, e depois arranja maneira de as fazer.