Codex saiu do laptop | DevDay 2026

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: Codex Has Left The Laptop | DevDay 2026 · Canal: OpenAI · 21:23 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

Dominic apresenta novas formas de usar Codex em diferentes ambientes e de delegar tarefas sem manter o laptop ou máquinas extras ligados. A demonstração cobre Codex Cloud, ambientes configuráveis, integrações com ferramentas e recursos privados, além de colaboração no Slack e no Teams. Ele também mostra melhorias para revisão de código, planejamento com a equipe, dots, CLI e acesso pelo navegador. Ao final, recomenda experimentar Codex Cloud, Space e dots para integrar Codex ao fluxo de trabalho de cada pessoa.

Pontos-chave

Codex Cloud permite executar tarefas em ambientes preparados na nuvem, sem depender do laptop ou de máquinas adicionais.
Ao configurar um ambiente, Codex pode inspecionar o repo e preparar dependências, um startup skill e um script de inicialização.
Os ambientes na nuvem podem acessar recursos privados por meio de Tailscale ou OIDC.
A integração com Slack permite colaborar em tarefas e PRs usando ambientes compartilhados.
A aba de revisão de código no app reúne PRs e permite comentar, enviar feedback e fazer perguntas a Codex.
Space mantém planos, diagramas e acompanhamento de tarefas em um espaço compartilhado entre a equipe e Codex.
Dots podem acompanhar discussões e tarefas em andamento; @ChatGPT é voltado à colaboração em conversas compartilhadas.
A CLI ganhou uma visualização de agents, suporte a diagramas e LaTeX no terminal e modo de voz.
A experiência web permite acessar tarefas na nuvem, interagir com sites publicados e usar dots.

Capítulos

Início	Capítulo	Resumo
00:19	Codex além do laptop	Dominic apresenta a evolução do uso de Codex e a proposta de executar tarefas sem depender de máquinas locais.
03:01	Configuração de ambientes no Codex Cloud	A demonstração mostra a preparação automática de ambientes, o trabalho com Figma e o acesso a recursos privados.
09:32	Ambientes compartilhados e colaboração no Slack	O apresentador configura um ambiente para a equipe e mostra como Codex ajuda a investigar e testar um PR pelo Slack.
12:13	Revisão de código e planejamento com a equipe	O vídeo apresenta a nova experiência de revisão de PRs e o uso de Space para criar e acompanhar planos.
14:20	Dots e colaboração no Slack	Dominic explica como dots acompanham tarefas contínuas e como @ChatGPT pode ajudar na colaboração compartilhada.
17:37	CLI, navegador e próximos passos	A demonstração percorre melhorias na CLI e na experiência web, antes de recomendar Codex Cloud, Space e dots.

Citações

Delegar trabalho deveria ser tão fácil quanto pedir algo ao Codex, e ele assumir a tarefa. — 02:27

Você deve poder usar o harness do Codex na interface que quiser e escolher onde o trabalho será executado. — 03:01

Os dots são uma extensão de você. — 16:01

Você não precisa adotar tudo o que mostrei hoje de uma só vez. — 20:19

Conceitos e entidades

Codex (ferramenta): Ferramenta da OpenAI demonstrada para executar tarefas de desenvolvimento em diferentes interfaces e ambientes.
Codex Cloud (ferramenta): Serviço apresentado para executar tarefas de Codex em ambientes na nuvem configuráveis.
Space (ferramenta): Espaço de colaboração para manter planos e acompanhamento de tarefas acessíveis à equipe e a Codex.
Dots (conceito): Assistentes pessoais apresentados como capazes de acompanhar canais e tarefas contínuas em nome de uma pessoa.
Slack (ferramenta): Plataforma de mensagens usada na demonstração para colaborar com Codex e encaminhar tarefas.
Tailscale (ferramenta): VPN usada no exemplo para permitir que um ambiente na nuvem acesse um recurso privado na rede.
OIDC (conceito): Mecanismo de autenticação mencionado como opção para acessar recursos na nuvem.
Figma (ferramenta): Ferramenta cujos arquivos foram consultados por Codex durante as demonstrações.
CLI (ferramenta): Interface de linha de comando que recebeu melhorias para gerenciar tarefas e interagir com Codex.
OpenAI (empresa): Empresa responsável pelos produtos e recursos apresentados no vídeo.

Tradução completa (pt-BR)

00:19 [aplausos] >> Olá a todos. Meu nome é Dominic. Trabalho com experiência de desenvolvimento aqui na OpenAI. Sam lançou mais cedo cerca de 20 novos recursos. E, entre esses recursos e os aproximadamente 300 que lançamos ao longo do último ano, construir com eles mudou drasticamente a forma como construímos as coisas na OpenAI e a forma como muitos de vocês constroem.

00:50 E sei que é incrivelmente difícil acompanhar tudo isso. Então, nos próximos 25 minutos, quero dar alguns exemplos práticos de como vocês podem incorporar essas coisas aos seus workflows. Porque o fato é que esses recursos mudaram drasticamente a forma como construíamos, e acredito que vão mudar a forma como vocês constroem. Mas também sei que pode ser não apenas algo avassalador, mas também confuso entender como incorporar essas coisas ao workflow. E, no fim das contas, quero que vocês construam como… E, no fim das contas, quero garantir que possam usar o Codex em qualquer lugar, da forma que

01:22 quiserem. No começo do ano, não sei quanto a vocês, mas, para mim, era bastante comum executar uma ou duas tarefas. Mas ver o Peter… >> [limpa a garganta] >> publicar esse tuíte com, sei lá, 40 Codex diferentes rodando ao mesmo tempo foi algo avassalador. Eu não conseguia imaginar executar tantas tarefas ao mesmo tempo. Mas então lançamos o app do Codex, e delegar e alternar entre tarefas ficou muito mais fácil. E, desde então, executar vários agents

01:54 ao mesmo tempo é quase o normal. E, à medida que os modelos ficaram melhores e mais capazes, especialmente no uso do computador e em trabalhos de longa duração, começamos a delegar aos modelos problemas cada vez maiores, muitas vezes com tarefas que duravam horas ou dias. Como resultado, começamos a deixar nossos laptops meio abertos só para mantê-los funcionando entre reuniões. E, para resolver isso, não sei quanto a vocês, mas quantos acabaram comprando um Mac Mini ou um Raspberry Pi, ou até alugando

02:27 alguns VPSs só para manter seus agents rodando? Mas mais máquinas significam que vocês precisam lidar com mais manutenção, mais espaço em disco, atualizações e a capacidade total que precisam gerenciar. E, sempre que querem fazer mais, precisam adquirir mais recursos. Mas delegar trabalho deveria ser tão simples quanto dizer ao Codex para fazer algo, e ele assumir o trabalho, sem que vocês precisem sair por aí adquirindo mais computadores. Porque, no fim das contas, vocês deveriam poder usar o harness do Codex na interface que preferirem

03:01 e escolher onde esse trabalho será executado. Assim, vocês têm a possibilidade de adaptar o workflow às suas necessidades e, conforme os agents e os modelos ficam mais capazes, continuar acompanhando essas mudanças. E hoje lançamos o Codex Cloud, dots e o ChatGPT no Slack e no Teams. Todos eles usam o mesmo agent que vocês já vêm usando. Isso significa que vocês têm acesso às mesmas ferramentas e informações por meio dos plugins que já instalaram na

03:32 sua conta. E isso significa que vocês podem escolher os recursos que se encaixam no workflow, sem precisar começar do zero. Chega de conversa, então. Vamos mostrar algumas dessas coisas e como vocês podem usá-las. Certo. No app para desktop, além de executar tarefas localmente ou remotamente, agora vocês também podem executar tarefas no Codex na nuvem, usando ambientes que sua equipe já criou ou

04:05 criando um novo ambiente. Ao criar um novo ambiente, vocês podem escolher os repositórios aos quais ele terá acesso. Vamos escolher dois dos projetos do Blossom Music, o projeto em que Holly estava trabalhando. Assim que eu selecioná-los, o Codex começará a preparar esse projeto. Ele fará toda a preparação para vocês, inspecionando o repositório e as dependências, e configurará tudo o que for necessário para trabalhar nesse projeto. Antes, isso exigia muita

04:37 configuração manual e muitas vezes era bastante trabalhoso. Como parte desse processo, ele não apenas descobrirá as dependências, mas também escreverá uma skill de inicialização que ensina o agent a usar o ambiente e um script de inicialização para garantir que possa iterar rapidamente nesses ambientes. Neste caso, se tudo der certo, ele perceberá que temos dependências de iOS e web aqui, ambas ao mesmo tempo. No entanto, como este é um ambiente Linux, vocês podem ver que ele percebe corretamente

05:11 que não poderá executar o aplicativo para dispositivos móveis, o que não tem problema para mim, porque, neste caso, eu só queria ter acesso a esse código para poder consultá-lo. No entanto, futuramente, vocês poderão trazer seus próprios ambientes de nuvem, o que significa que poderão adaptar a execução dessas tarefas da maneira que quiserem, sem deixar de aproveitar os mesmos recursos do Codex Cloud. Uma das coisas em que nos esforçamos bastante como parte disso foi garantir que tudo rode mais rápido do que antes. Para isso, dedicamos bastante esforço

05:44 à criação de snapshots do sistema de arquivos, para que as tarefas seguintes iniciem mais rápido. Mas isso também significa que podemos executar atualizações em segundo plano para garantir que ele tenha as alterações mais recentes do repo e executar quaisquer outros scripts de atualização necessários. Vou deixar isso rodando por um tempo, mas queria mostrar um exemplo do que vocês podem fazer com o Codex Cloud. Neste caso, iniciei uma tarefa mais cedo, na qual enviei uma captura de tela do app para ele implementar um shader que tínhamos projetado no Figma.

06:16 Então, peguei uma captura de tela do app como esta e a enviei para meu ambiente na nuvem. A partir daí, ele trabalhou nisso, buscando todos os detalhes necessários diretamente no Figma, usando o plugin do Figma que eu tinha instalado na minha conta. Depois, ele implementou o shader, testou e criou um vídeo que, por algum motivo, não está carregando agora. Mas, para poder realmente interagir com ele,

06:46 e como temos acesso a todos os diferentes plugins no nosso ambiente, pedi que transformasse a mesma coisa em um pequeno playground com o qual pudéssemos interagir. Isso está implantado como um site e, a partir daí, posso testar o shader antes de implantá-lo no próprio site. Posso ajustar algumas coisas e depois enviar atualizações adicionais das configurações de volta para o meu app. Também posso, da mesma forma que estou acostumado em qualquer outro ambiente na nuvem… em qualquer outro ambiente local em que já tenha usado o Codex, usar o app para deixar comentários diretamente no código que foi editado, inspecionar o que mudou e até iniciar um chat no site, caso queira fazer perguntas sobre a tarefa que acabou de ser executada.

07:18 A outra desvantagem comum dos ambientes na nuvem é o acesso a recursos privados. Talvez vocês tenham alguns recursos aos quais queiram permitir que o ambiente na nuvem acesse, mas sem expô-los à internet pública. Um exemplo disso é esta pequena API que tenho rodando agora em um Raspberry Pi. Ela não está disponível na internet. Ela roda apenas neste Raspberry Pi. Mas configurei meu ambiente aqui para poder usar o Tailscale como acesso por VPN. Então dei acesso a ele. Obrigado. Dei a ele uma chave de autenticação do meu Tailscale e, a partir daí, o Codex pode acessar

07:51 quaisquer recursos da minha rede Tailscale. Ao mesmo tempo, também adicionamos suporte a OIDC. Então, se quiserem acessar seus recursos na nuvem por meio de OIDC, também podem fazer isso. E tenho aqui um ambiente no qual podemos iniciar uma tarefa. Posso pedir que ele acesse a API que está rodando nessa tarefa. E, para provar que essa API realmente não roda na nuvem, este é o… Esta é a porta em que a API está rodando. No momento, ela não está respondendo, mas, se eu conectar meu laptop a ela

08:26 …

09:00 na mesma rede Tailscale. Certo. Tudo bem. Podemos ver que a API está respondendo. Então, voltando à tarefa. Talvez você tenha percebido que tivemos algumas interrupções durante a palestra. Há alguns desenvolvedores trabalhando nisso. Então, não sei exatamente o que está acontecendo aqui, mas vou mostrar um backup. Aqui você pode ver que fiz essa solicitação antes e estamos fazendo as mesmas chamadas de API nesta requisição. Pronto. Estamos fazendo as mesmas chamadas de API

09:32 aqui. Então, o Codex consegue acessar esses mesmos recursos que estão disponíveis na nossa rede Tailscale. Tudo bem, vamos ver como foi nossa tarefa de configuração. Como mencionei antes, ele percebeu que não consegue testar as alterações para iOS, mas ainda pode editar o código-fonte para dispositivos móveis. E então sugeriu aqui tanto um script de instalação que podemos executar quanto uma skill de inicialização. A partir daqui, posso modificar isso manualmente ou continuar fazendo perguntas ao Codex ou dando instruções sobre

10:07 como quero continuar configurando este ambiente. Você pode fazer isso enquanto o cria pela primeira vez ou voltar depois e continuar iterando. Da mesma forma, temos uma skill de inicialização que descreve todos os detalhes necessários para este projeto. Posso aceitar essas sugestões. E agora posso fazer outras alterações, como controlar o acesso à rede, configurar os segredos de rede e até configurar variáveis de ambiente específicas do ambiente de nuvem que tenho ou usar variáveis de ambiente pessoais

10:38 armazenadas no meu cofre, para que não sejam compartilhadas com a equipe. Outra coisa que posso fazer é escolher entre compartilhar esse ambiente só comigo ou com toda a minha equipe. E, como essas tarefas são executadas na nuvem, posso simplesmente fechar meu laptop e continuar tendo acesso a todas elas pelo celular ou pelo navegador. Outra vantagem de executar essas tarefas na nuvem é poder integrá-las aos ambientes

11:09 em que nossas equipes já trabalham. No nosso caso, isso é o Slack, onde eu e meu colega conversamos sobre um bug que ele encontrou no app: parecia que o app web não tinha os elementos visuais corretos implementados. Pedi ao Codex — ou pedi ao ChatGPT — para investigar isso. Ele abriu o pull request. Também acessou os arquivos do Figma para descobrir o que estava errado e percebeu

11:42 que já havia uma PR resolvendo esse problema. Pedi que investigasse melhor e até testasse essas alterações, e ele usou o mesmo ambiente de nuvem que eu já tinha criado e compartilhado com a minha organização para testar todas elas. Nós dois pudemos colaborar nisso e, por fim, chegamos a um ponto em que a PR estava pronta para ser revisada. Falando em revisão de código, não sei quanto a vocês, mas, à medida que os agents escrevem mais código, percebo que passo mais tempo revisando código.

12:13 Por isso, acabamos reformulando a aba de revisão de código no app para desktop. Agora você pode ver diretamente no app todas as PRs atribuídas a você ou criadas por você. E, a partir daqui, pode fazer tudo o que faria numa revisão de código normal: ver o código, deixar comentários, ver os comentários de outras pessoas, enviar seu feedback de revisão ou até pedir ao Codex que faça uma revisão. O que eu, pessoalmente, acho incrivelmente

12:43 útil, porém, é poder fazer perguntas diretamente no app. Vamos lá. Diretamente no app. Isso. Para obter detalhes sobre o assunto desta PR e me ajudar a entender melhor os possíveis efeitos colaterais que podem ocorrer neste pull request específico. Quando estiver satisfeito, posso enviar meu feedback. À medida que os agents assumem trabalhos maiores, outro aspecto importante é planejar e colaborar

13:15 com nossas equipes. O Space é uma ótima maneira de colaborar com seu agent e com sua equipe ao mesmo tempo, sem precisar ficar copiando e colando informações de um lado para o outro. Neste caso, eu estava trabalhando numa reformulação da implementação de referência da nossa API e em como queria fazer o deploy dela. O Codex elaborou um plano, eu o coloquei no Space e posso compartilhá-lo com minha equipe e receber feedback deles,

13:48 mas também posso continuar iterando com o Codex. Neste caso, pedi que adicionasse um diagrama do sistema para ajudar a entender como essas partes se encaixam. E que também incluísse um rastreador de tarefas. Enquanto o Codex trabalha nessas tarefas, posso pedir que atualize o rastreador; ou, se eu estiver trabalhando neste projeto com toda a equipe, todos podemos contribuir para este documento com nossos próprios pontos e com o Codex, para ficarmos a par do que está acontecendo. Outra coisa que posso fazer, quando estiver satisfeito com este plano,

14:20 é pedir ao Codex que o implemente, e ele vai começar a trabalhar e enviar atualizações continuamente, se eu quiser. A última parte de tudo isso é produtividade. Quantos de vocês têm usado loops ou threads de threads para gerenciar o trabalho? Certo, uma boa parte de vocês. Então, vocês vão gostar muito da produtividade dos dots, porque eles permitem gerenciar as tarefas existentes do Codex e encaminhar mais tarefas ao Codex, enquanto os dots ficam continuamente atentos ao que

14:55 está acontecendo. Isso significa que eles podem acompanhar discussões de produto e engenharia, detectar alterações no código e também iniciar tarefas quando necessário. Neste caso, por exemplo, meu colega Carolus me marcou em uma PR que eu não tinha visto. Recebi uma notificação no Slack do meu dot para conferir essa PR. Naquele momento, eu não tinha tempo para dar uma olhada. Eram 10h20 de um domingo. Então, perguntei do que se tratava a PR, e meu dot

15:28 começou a revisar a PR para tentar entender do que se tratava. Depois, pedi que fizesse uma revisão mais completa. Para isso, ele iniciou uma tarefa completa na nuvem diretamente do meu ambiente do Slack, para investigar a PR, descobrir quais eram os problemas e me informar. Mas, como esta é uma tarefa de verdade, também posso voltar aqui e fazer perguntas complementares mais tarde ou até usá-la para levar a PR até a

16:01 linha de chegada. Mostrei dois exemplos no Slack, e tenho certeza de que uma das perguntas que vocês estão se fazendo agora é: “Legal, existe o @ChatGPT e existe meu dot. Quando uso cada um e qual é a diferença?” A maneira de pensar nisso é que os dots são uma extensão de você. De propósito, demos a eles seu nome seguido do nome do seu dot, para que

16:33 as pessoas no Slack entendam que eles estão ligados à sua personalidade e têm contexto sobre o que você está fazendo, além da sua memória. Por isso, são ótimos para qualquer trabalho contínuo relacionado às suas atividades. Isso significa que meu dot acompanha regularmente os canais que me interessam e participa das conversas se eu der permissão, mas também significa que posso encaminhar tarefas a ele continuamente pelo Slack ou por outros canais, para que meu dot cuide delas por mim. Já o @ChatGPT foi pensado

17:05 para colaboração. É uma ótima maneira de você e seu colega trabalharem juntos numa thread, interagirem nela e colaborarem numa PR, por exemplo. Por isso, seu dot tem acesso a todos os seus ambientes de nuvem e ao seu código local, enquanto o ChatGPT só tem acesso aos ambientes de nuvem compartilhados. Mas ele facilita muito a colaboração. Antes, mencionei que quero que vocês possam usar o Codex em qualquer lugar

17:37 do jeito que quiser e da maneira que quiser. Até agora, a única coisa que mostrei foi o desktop, e conversamos sobre o mobile. Mas sei que muitos de vocês também adoram usar a CLI e, por isso, começamos a reformulá-la profundamente. Entre outras coisas, agora você tem uma visualização de agent, que permite ver todas as diferentes tarefas em execução dentro do Codex, para ficar de olho em quais precisam da sua atenção, iniciar novas e executar várias em

18:08 paralelo com muita facilidade. Também reformulamos coisas como a possibilidade de mencionar com @ todos os plugins que você está usando, além de deixar significativamente mais rápidas tarefas como selecionar imagens e texto. Você pode renderizar diagramas e LaTeX diretamente no terminal. Também adicionamos coisas como o modo de voz, para que agora você possa falar diretamente com seu agent pelo terminal usando

18:40 o mesmo microfone — neste aqui, o microfone não está ativado. Mas você pode usar o mesmo modelo GPT life que conhece e adora no aplicativo para desktop. Outra coisa que você pode fazer agora é usar mais recursos diretamente na web. Este é o Chrome. Não é o aplicativo para desktop, mas a experiência vai parecer bem familiar. Você pode acessar, diretamente pelo navegador, todas as tarefas na nuvem que executou usando o Codex cloud. Você pode

19:15 ver aqui que ele mostra a mesma captura do aplicativo que enviei. Podemos revisar aquele vídeo que não estava sendo reproduzido antes. Assim, você pode vê-lo interagindo com ele aqui. E também pode interagir com os sites que foram publicados diretamente na interface web. Você também pode acessar seu dot e, em breve — tomara que muito em breve, nos próximos dias —, poderá acessar também a aba de code review no aplicativo web.

19:46 Assim, você não precisa instalar nem usar o aplicativo para desktop só para fazer mais coisas. A maneira como desenvolvemos mudou drasticamente no último ano. Passamos de tarefas individuais a apresentar problemas cada vez maiores aos nossos agents. E isso facilitou para vocês assumirem as coisas que imaginaram e realmente criarem soluções de alta qualidade, em vez de apenas alguns protótipos.

20:19 E vocês não precisam adotar de uma só vez tudo o que mostrei hoje. Queremos que possam usar o Codex onde quiserem e da maneira que se encaixar no workflow de vocês. Mas há três coisas que eu recomendaria experimentar. Primeiro: se você ainda deixa o laptop aberto ou gerencia um conjunto de máquinas de desenvolvimento, seja qual for o formato, experimente o Codex cloud para o seu trabalho. Assim, você pode deixar de depender do laptop, reutilizar ambientes preparados e gastar menos tempo mantendo essa infraestrutura.

20:53 E, se você está cansado de alternar entre os documentos da equipe e depois copiar o plano de volta para um documento para o Codex usar, experimente o Space. Ele dá a você a possibilidade de reunir os recursos e os planos em um só lugar, tanto para seus agents quanto para sua equipe. E permite que o Codex atualize continuamente o progresso diretamente no documento, para que sua equipe saiba o que está acontecendo ao mesmo tempo.

21:23 E, se você está cansado de encaminhar trabalho manualmente para o Codex e de escrever um prompt para ele toda vez, dê ao seu dot uma responsabilidade contínua que você esteja cuidando e deixe que ele acompanhe esse trabalho e mantenha tudo avançando. Então, vá em frente e crie, com o Codex, as coisas que você vem imaginando, onde quer que esteja. Obrigado. >> [aplausos]

Transcrição original

[00:19] [applause] >> Hi everyone. My name is Dominic. I work on the developer experience here at OpenAI. Now Sam earlier launched around 20 or so new features. And between those and the roughly 300 features that we launched over the course of the last year, the building with them has drastically changed how we build things at OpenAI and how many of you built.

[00:50] And I know this is incredibly hard to keep up. So over the next 25 minutes, I want to give you some practical examples how you can actually incorporate these things into your workflows. Because the fact is these features have drastically changed how we built and I believe they’re going to change how you built. But I also know that it can be not just overwhelming but confusing how to actually build these things into your workflow. And ultimately, I want you to build how And ultimately, I want to make sure that you can use Codex anywhere the way that

[01:22] you want to. At the beginning of the year, I I don’t know about you all but for me, it was pretty common to like run one or two tasks. But seeing Peter um >> [clears throat] >> have this tweet uh with like I don’t know, 40 different Codexes running at the same time felt overwhelming. I could not imagine actually running that many tasks at the same time. But then we launched the Codex app and it made delegating and switching tasks so much easier. And since then, running multiple agents

[01:54] at the same time is almost the norm. And as models got better and more capable, especially around computer use and long-running work, we started handing increasingly more increasingly bigger problems off to the models, often running for hours or days. And as a result, we started carrying our laptops half open just to keep them running between meetings. And to solve that, I know about you all, but like how many of you ended up buying a Mac Mini or like a Raspberry Pi or even renting

[02:27] some VPSs just to keep your agents running. But more machines means that you have to deal with more upkeep, more disk space, dealing with updates, overall capacity that you need to manage, and every time you want to do more, you have to procure more. But delegating work should be as easy as just telling Codex to do something, and it picks up the work regardless of whether you have to like go and procure more computers. Cuz ultimately, you should be able to use the Codex harness in whichever

[03:01] interface you want to use and choose where that work runs for you. So that you have the opportunity to adapt the workflow um to to adapt the workflow to your needs, and as agents and models become more capable, continue to keep up with that. And so today, we launched Codex Cloud, dots, and add chat GPT in Slack and in Teams. And all of these use the same agent that you’ve been using. Meaning you have access to the same tools and information through the plugins that you already installed in

[03:32] your account. And it means that you can pick the features that fit your workflow without having to start from scratch. Enough talk, though. Let’s actually show you a couple of these things and how you can use them. All right. So, in the desktop app, um additionally to running tasks locally um or running them on your remote, you can now uh run tasks on Code X in the cloud using environments that either your team has already created or by

[04:05] creating a new environment. When you create a new environment, you can pick the different repositories that you want the environment to have access to. We’re going to pick two of the projects from Blossom Music, the project that Holly was working on. As soon as I uh select these, Code X is actually going to begin to work on setting up this project. It will do all the preparation for you by inspecting the repository, the dependencies, and set up all of the necessary things that might be required to work on this project. This used to take a lot of

[04:37] manual configuration and was often very cumbersome. As part of this, it will not just discover the dependencies, it will also write both a startup skill that teaches the agent how to use the environment, and it will uh write a startup script to make sure that it can quickly iterate on these environments. In this case, um if everything goes well, it will notice that we have iOS um and web dependencies in here both uh both at the same time. However, because this is a Linux environment, you can see here, it is noticing correctly

[05:11] that it won’t be able to run the mobile application, which is fine for me because in this case, I just wanted to have access to that code so I can reference that. However, um eventually, you’ll be able to bring your own cloud environments, which means that you can actually adapt this to whatever way you want want these tasks to run while still leveraging the same capabilities of Code X Cloud. One of the things that we did put a lot of effort in as part of this is making sure that things run faster than before, which means that we put a lot of effort

[05:44] into the snapshotting of the file system, making subsequent tasks faster to start up. But, it also means that we can run background updates to make sure it has the latest repo changes and run any other update scripts necessary. Now, I’m going to let this run for a bit, but I wanted to show you an example of what you can do with Codux Cloud. So, in this case, um I kicked off a task earlier where I sent it an app shot to go and implement a shader that we had designed in Figma.

[06:16] So, I took an app shot like this and sent it over to my cloud environment. And from here, it worked on it, pulling all of the necessary details directly from Figma using the Figma plugin that I had installed in my account. From here, it went and actually implemented the um the shader, it tested it, and created a video that for some reason is not loading right now. Um but in order to actually play with it,

[06:46] and because we have access to all of the different plugins in our environment, I went ahead and actually asked it to turn the same thing into a little playground that we can play with. So, this is deployed as a site, and from here, I’m able to test out the shader um before I actually deploy it to the site itself. I can tweak things, and then I can go and send off any additional updates to the settings back to my app. I can also the same way that I’m used to from any other cloud environ- uh any

[07:18] other local environment that I might have used Coduxin before, use the app to leave comments directly on the code that was edited, inspect what has changed, and even start up a site chat if I want to have questions about the task that was just executed. The other thing um that is normally a common drawback with cloud environments is access to private resources. You might have some resources where you want

[07:51] to be able to have the cloud environment access those but not expose them to the entire public internet. One of those examples is I have this little API running on this Raspberry Pi right now. It is not available to the internet. It runs on this Raspberry Pi alone. Um but I configure it my environment here to be able to use Tailscale as a VPN access. So I gave it access. Thank you. I gave I gave it an off key to my Tailscale and from here Codex can access

[08:26] any of my resources on my Tailscale network. Uh at the same time we also added OIDC support. So if you want to access your cloud resources through OIDC, you can do that as well. And so I have an environment here that we can start off a task. And I can ask it to pull the API that is running on this task. And to prove to you that this is actually an API that doesn’t run um on the cloud. This is the This is the port that the API runs on. Right now it’s not responding um but if I connect my laptop to that

[09:00] same Tailscale network. See. All right. We can see the API’s responding. And so if we’re going back to the task. Seems something You might have noticed we had some outages during the um keynote. There’s some devs working on it. So I don’t know exactly what’s going on here but I’m going to show you a backup. Um so here you can see I asked this earlier and we’re doing the same um API calls in this request. There we go. We’re doing the same API

[09:32] calls here. So Codex is able to access those same resources that are just available in our Tailscale network. All right, let’s take a look at how our setup task went here. Um so, as I mentioned earlier, it figured out that it cannot actually test the iOS changes, but that it can still do mobile source editing. And then it suggested to us here uh both an install script that we can run as well as a startup skill. From here, I can go and modify this by hand, or I can continue to ask Codex any questions or give it instructions about

[10:07] how I want to continue to configure this environment. You can do that at at while you’re creating it the first time, or continue to come back and iterate on it further. And similarly, we have a startup skill that describes all of the necessary details here for this project. And I can go and accept these. And now I can do any other changes, like controlling what network access it has, set up the network secrets, and even configure environment variables that are either specific to the cloud environment that I have, or use personal environment variables

[10:38] that are stored in my vault so that they are not shared with my team. Cuz the other thing that I can do is choose between sharing this environment with just myself, or with my entire team. And because these tasks run in the cloud, I can actually turn uh like close my laptop and continue to have access to all of those tasks on my phone or in the browser. The other thing that you get out of running these tasks in the cloud is that we can bring them into the environments

[11:09] where our teams are already working. So, in our case, that’s Slack, where we were able to have a conversation between me and my colleague about this bug that he found in the app where it looked like the web app didn’t actually have the right visuals implemented. I asked Codex or I asked ChatGPT to go and figure this out. It actually pulled up the pull request. It also accessed the Figma files to figure out what was wrong and noticed

[11:42] that there was already a PR that was solving this problem. I asked it to dive deeper into it and even test these changes and it used that same cloud environment that I had already created and shared with my organization um to test all of the changes. We were able to collaborate on this between both of us and ultimately get to a point where the PR is ready to be reviewed. Talking about reviewing code, I don’t know about you all, but as agents write more code, I find myself spending more time actually reviewing code.

[12:13] And because of that, we ended up overhauling the code review tab inside the desktop app. So, you can now see all of the PRs that are assigned to both yourself or were created by you um directly in the app. And from here, you can do all of the things that you would do with a regular code review. You can see the code, you can leave comments, you can see the comments of others, submit your review feedback, or even run a review with Codex. The thing that I personally find incredibly

[12:43] helpful, though, is to be able to ask questions directly inside the app. Come on. Directly within the app. There we go. Um to get details about what this PR is about and help myself better understand the the side effects that might be happening inside um this particular pull request. And when I’m happy, I can submit the feedback. As agents take on bigger work, the other big part is planning and collaborating

[13:15] with our teams. Um Space is a great way for you to actually collaborate both with your agent and with your team at the same time without having to copy-paste different pieces of information back and forth. So, in this case, I was working on a redesign of our API uh reference implement reference and how I wanted to deploy it. And so, in this case, Codex wrote up a plan, I put it into space, I can share it to with my team, get feedback from them,

[13:48] but I’m I can also continue to iterate with Codex on it. So, in this case, I asked it to add a system diagram to better understand how these different pieces fit together. And then, um have a task tracker as well. And as Codex works on these tasks, I can have it update those, or if I’m working with the entire team on this project, we can have all of our all of our dots and our Codex contribute to this document so that we’re all in sync on what is happening. The other thing that I can do is once I’m happy with this plan,

[14:20] I can go and ask Codex to implement the plan and it will pick it up and continuously push information back if I wanted to. The last part of all of this is productivity. Uh how many of you have been using like loops or threads of threads to manage their work? All right, a decent amount of you. So, you will actually love the productivity of dots uh because it gives you a way for you to manage both your existing Codex tasks and hand off more tasks to Codex while gaining some productivity of dots continuously watching out on what

[14:55] is happening. That means you can track product and engineering discussions, it can notice code changes for you, and then it can also spin up tasks for you when necessary. In this case, for example, my colleague Carolus had tagged me in a PR that I had missed. And I got a notification that in Slack from my dot to check out this PR. I didn’t really have time in this moment to take a look at it. It was uh 10 20 past 10 on a Sunday. So, I asked it what the PR was about um and my dot actually uh

[15:28] started reviewing that PR trying to figure out if it was what it was about. And then I asked it to do a more thorough review. As part of this, it went ahead and actually spun up a full-on cloud task uh directly from my Slack environment so that it could uh dive into the PR, figure out what the issues are, and then report back to me. But, because this is an actual task, I can also go in here and continue to ask follow-up questions myself later on, or even use this to bring the PR over the

[16:01] finish line. Now, I showed you two Slack examples, and one of the questions I’m certain you’re answering asking yourself right now is, “Great, there is @ChatGPT and there is my dot. Why when when do I use which and what’s the difference?” And the way to think about it is the dots are an extension of yourself. We intentionally named these with your name and then the name of your dot, so that

[16:33] people inside Slack understand that they’re tied to your personality, they have context about um what you’re working on, your memory. And so, they’re great for any ongoing work that is related to what you do. That means my dot regularly watches channels that I care about, weighs in on topics if I give it the permission to, but it also just means that I can forward constantly forward tasks to it in Slack or in other channels to go and have my dot tackle tasks for me. @ChatGPT, on the other hand, is meant

[17:05] for collaboration. It’s a great way for you and your colleague to work in a thread at the same time, interact on it, work together on a PR, for example, and because of that, your dot has access to all of your cloud environments and your local code acts while at chat GPT only has access to your shared cloud environments. But, it makes it so much easier for you to collaborate on things. Now, earlier I mentioned that I want you to be able to use code acts anywhere you

[17:37] want to, and whatever way you want. And so far, the only thing that I showed you is desktop and we talked about mobile. But, I know a lot of you also love using the CLI, and because of that, we started giving the CLI a big overhaul. Um Among other things, you now have an agent view, which means you can see all of the different tasks that are running inside your code acts, so you can keep an eye on on um which ones need your attention, start up new ones, and run multiple ones in

[18:08] parallel very easily. We’ve also overhauled We also overhauled things like being able to at mention both all of your plugins that you’re using, as well as making it significantly faster to do things like selecting image selecting text. You can render um diagrams and LaTeX directly inside the terminal. Uh and we even added things like voice mode, so that you can now talk to your agent directly within the terminal using

[18:40] the same um the microphone is not enabled on this one. Um but, using the same uh GPT life model that you know and love from the desktop app. The other thing that you can do now is use more of your experience directly in the web. So, this is Chrome. Um it is not the desktop app, but you’re going to see a very familiar experience. You can access all of your cloud tasks that you’ve been running using code acts cloud directly in the browser. You can

[19:15] see here actually it shows the same app shot that I sent over. We can review that video that wasn’t playing earlier. So you can see it here engaging with it. And you can even interact with the sites that were deployed directly within your web interface. You can also access your dot and soon hopefully very soon in the next coming days you’ll be able to access your code review tab inside the web app as well.

[19:46] So you don’t have to install or use the desktop app just to get more things done. Now the way we develop has drastically changed over the last year. We moved from individual tasks to giving increasingly bigger and bigger problems to our agents. And um and it made it easier for you to take on the things that you’ve dreamed up and actually build high quality solutions rather than just some prototypes.

[20:19] And you don’t need to adopt all of these things that I’ve showed you today all at once. We want you to be able to use codex wherever you want and however it fits into your workflow. But there are three things I would encourage you to try. One, if you’re still leaving your laptop cracked or managing a pile of dev boxes in whatever shape it is. Try out codex cloud for your work. It means you can move off your laptop and reuse prepared environments and spend less time maintaining that infrastructure.

[20:53] And if you’re tired of jumping across docs for your team and then go and copy the plan back into a doc for codex to be used. Instead, try out space. It gives you our It you the ability to take the features and plans and keep them in one place for both your agents and for your team. And it lets your Codex continuously update the progress directly within the doc so that your team knows what is happening at the same time.

[21:23] And if you’re tired of manually forwarding work to Codex and prompting each every time uh uh prompting it every time, give your dot an ongoing responsibility that you’re handling and let it keep that uh keep track of that work and let it uh handle keeping it moving. With then, go ahead and build the things that you’ve been dreaming up with Codex anywhere. Thank you. >> [applause]