An interview and live demo of OpenAI's newly launched Codex, an autonomous coding agent that builds features and fixes bugs, with Alexander Embiricos of OpenAI's product team. Topics include Codex's interface for delegating and reviewing tasks, how it works under the hood, why an "abundance mindset" (delegating many agents in parallel) works best, how OpenAI thinks about agent design within a unified super-assistant vision, and the future of programming as more social and agent-guided work. # Channel Presentation Observations: "OpenAI Launches Codex: An Autonomous Programming Agent" ## Format & Demonstrated Content - The channel produces **interview-style podcast/video content** featuring guests directly involved in building the product discussed. - Evidence: host invites "Alexander Ambiraos, a member of the product staff at OpenAI who's responsible for Codeex, to come on the show and talk to us about it." - Episodes include **live on-screen product demos** walkthroughs, not just discussion. - Evidence: "We walk through Codex screen by screen"; the host screen-shares the Codex UI mid-episode ("so I'm so excited that you're screen sharing this"). - The host frames a typical episode structure: news framing → guest introduction → demo → product-decision discussion → future-vision discussion. - Evidence: "talk through all of the product decisions that led to its release... what OpenAI's vision is for the future of programming." ## Claimed Scope (Creator Self-Description) - The host positions the channel as covering **major AI product launches**, timed to news cycles ("Huge news. OpenAI is launching a new coding agent"). - The host states he produces **companion reviews** alongside interviews: > "I got to try it. I have a review coming out along with this podcast." - The host presents himself as an **early tester with pre-release access**, which he uses as an editorial differentiator: > "Thanks for letting me try it early." ## Demonstrated Audience - **Developer- and builder-oriented audience**: conversation assumes familiarity with GitHub PRs, diffs, evals (SWE-bench), containers, CLIs, npm installs, and competitor tools (Devin, Claude Code). - Also **product/design-interested listeners**: host repeatedly probes design trade-offs ("how do you think about that tension between making something good for a particular situation... and loss of flexibility"). - Audience interested in **AI industry strategy and vision**, evidenced by the closing question on the agent landscape ("how do you see that market evolving? Is this a one agent to rule them all type situation?"). ## Host Presentation Style - Host offers **critical, first-hand observations**, including "gripes," not just promotion: > "It's not in ChatGPT... it feels very one-shot... it's definitely for senior engineers." - Host references his own team's internal product work ("Kieran is the GM of that product"), suggesting the channel is run by someone **actively building software with the tools covered**. - Host pushes back on guests' framing (e.g., questioning whether OpenAI risks building "this Balkanized thing that's kind of forgotten about in 3 months"). ## No Explicit Channel-Level Self-Description - No channel name, tagline, or audience statement appears in the transcript; all identity evidence is inferred from demonstrated format, guest access, and topical scope rather than direct claims. # Delivery Observations: "OpenAI Launches Codex: An Autonomous Programming Agent" ## Format Two-speaker interview/demo: a host (interviewer) and Alexander, the OpenAI product team member. The host drives structure; the guest demos and explains product decisions. The opening segment is a solo host monologue. --- ## Host Delivery ### Enthusiasm-Forward Openings The host repeatedly signals excitement and personal investment: > "Huge news. OpenAI is launching a new coding agent." > "I've been using Codeex for a couple days, and it's pretty great." > "I'm super excited about it. I got to try it." This framing recurs at the end: "I'm psyched to see where it goes." ### Conversational Fillers and Hedges Speech is heavily filled with "like" and "you know," suggesting an informal, unscripted register: > "it's like you're it's basically like built to make me just create a bunch of tasks" > "you know, uh, for anyone listening, basically Codex is it's a cloud-based software engineer" > "it's like very collaborative, like a lot of like really good tab completion, right?" ### Interactive Question Framing The host frequently narrates his questions as reactions and self-corrections: > "So tell tell me about like this screen and how you thought about this and and why you did it like this." > "One of the things that I notice about um this that feels different from like a Devon for example..." He also labels critiques lightly as "gripes": > "which is one of my gripes about this" > "this gripe that you have right of like the sort of the interaction loop" ### Storytelling with Personal Anecdotes The host supports points with first-person testing stories: > "I actually like shipped a feature on one of our products that I've never I've never coded in." > "we just sat together on a video call... it was just like a very different it was like social coding in this like weird way" ### Structural Signposting He explicitly manages time and topics: > "we only have a couple minutes left so I really need to ask like how do you see the agent landscape evolving?" > "I want to pause here for a sec" --- ## Guest (Alexander) Delivery ### Habitual Pausing Qualifiers Recurring "you know" and "um" as connective tissue, plus softening phrases: > "Um, and you know, there's a ton of AI tools out there." > "you know, I'm sure you hear this a lot, but you know, it's the G& AGI." ### Framing Answers Around Design Rationale Alexander consistently answers "why" questions with process narratives — "we realized," "we saw," "we wanted": > "Um and so we basically want to give the agent its own computer to do work in." > "And so we kind of ended up realizing like, hey, there's actually like kind of a spec for what a good PR description looks like." ### Repetition for Emphasis He uses stacked repetition to underline contrasts: > "not only not only optimized for real world software engineering, but also optimized for this form factor" > "Um you know, just actually to give you a bit of the story..." ### Safety/Scope Framing Vocabulary A recurring vocabulary cluster around constraint and iteration: - **"research preview"** — "we want to ship a research preview" - **"start small"** — "we're going to start like the smallest most constrained thing possible" - **sequencing vs. vision** — "that's more of a just like sequencing decision rather than like um a vision decision" ### Enthusiasm Markers Occasional intensity words that stand out against the measured baseline: > "I'm so excited that you're screen sharing this uh and showing people so we get to nerd out about all the details." > "totally yeah man I have I have so many so many fun thoughts here" > "it's and I'm very jazzed about it." ### Guiding the Live Demo Alexander directs the host's screen-sharing in real time: > "if you mouse over that little like terminal icon next to the testing... Yeah. So, we'll actually pro the model learns how to site its output." > "This is not what I was hoping you would see. Um, we clearly have some prompt tuning to do between now and tomorrow." The demo visibly includes improvised moments — the host navigates the wrong repo at one point ("this may not be what you actually see"). --- ## Shared Patterns - **Mutual back-channeling**: frequent "Yeah," "Exactly," "Got it," "That makes sense" from both speakers. - **Analogy-driven explanation**: delegation ("this feels a bit like delegation"), management ("it's a bit like becoming a manager"), gardening/food ("that's vegetables. I'm not going to eat that" — Alexander, a one-off colorful moment). - **Named concepts coined mid-conversation**: the "abundance mindset" (Alexander) which the host then adopts and reflects back; "wham" as an internal code name Alexander flags as jargon ("I'll explain what the word wham is later"). --- ## Uncertainty Notes - Timestamps are coarse (transcript line markers only); exact pacing/tonal delivery (pauses, laughter) beyond filler words cannot be verified. - "That's vegetables" and "wham" appear once each — treated as isolated moments, not patterns. - The host is not named in the transcript; identity inferred only from context (he references "my review," "our products," "the show"), so speaker attribution beyond host/guest is unstated. # Position Extraction: OpenAI Launches Codex (Alexander Embiracos interview) ## Speakers - **Host** — video presenter, early tester of Codex; refers to himself as "Dan" ("this UI that Dan's showing us") - **Alexander Embiracos** — identified by host as OpenAI product staff member responsible for Codex (name rendered "Alexander Ambiraos" in host's introduction; his own statements are otherwise unattributed by name in transcript) ## Product Description & Claims ### What Codex is - **Host**: Codex is a **web-based, largely autonomous software engineering agent** that can work on many features and bugs in parallel; he describes it as "pretty great" after a couple days of use. - **Alexander**: Codex is a **"cloud-based software engineer"** working on many tasks in parallel; the current form factor is "the beginning" of thinking about what programming looks like a year from now. - Model: **Codex-1**, a custom model trained for the product — "a version of o3 optimized for real world software engineering" and for the diff-return form factor. Claims it "slightly outperforms o3" on evals like SWE-bench. ### Design rationale - **Alexander**: Engineers wanted an efficient, structured **delegation** tool rather than chat. UI shows tasks, lines changed, and PR status. - **Style/mergeability**: heavy training effort on producing minimal, mergeable diffs matching the repo's existing style ("no extraneous comments"). - **PR descriptions**: learned from testers that engineers "just want to see the diff" first; good descriptions are concise, non-duplicative, and explain validation. - **Testing/citations**: model describes tests run, reports pass/fail honestly, and provides **deterministic citations** to log output so reviewers can verify. Claims effort to ensure it's "never hallucinating" test results. ### Sandbox/security - **Alexander**: Tasks run in a container; setup commands (written by the user, e.g., `npm install`) run with network access, then **internet is cut off** before the agent runs — "for absolute maximum safety," citing theoretical exfiltration risk. He notes he has "never actually ever seen it happen." - **Missing capabilities** (framed as sequencing, not vision decisions): no multimodal input, no browser, no network access for the agent. ## Tensions & Disagreements ### One-shot vs. interactive (host's gripe) - **Host**: Not being in ChatGPT makes it feel "very one-shot," better suited to senior engineers who can see the full task in advance; follow-up requests "didn't work quite as well." - **Alexander**: Acknowledges it is "quite one-shotty in the way people use it"; offers mitigations — **ask mode** vs. code mode, ask-mode speed improvements, and click-to-execute suggested tasks. Long-term goal: "converge delegation and pairing... into a single experience." ### Balkanization concern (host's gripe) - **Host**: Compares it to **Operator** — a separate tool that "feels like it's hanging out there" without updates. - **Alexander**: Defends the approach — side "speedruns" with specific customers generate evals and configs that get **reintegrated into mainline models**; says learnings (citations, steerability, describing work) will generalize back. Notes an updated small model is planned for the **Codex CLI**. ## Positions on the Future ### One assistant vs. many tools - **Alexander**: Long-term vision is **one general super assistant** (ChatGPT) with all tools; specialized "power UIs" still have a place for professionals (podcast-recording UI analogy; Codex's task-list/archive UI). "We cannot lose sight of that [generalized assistant] but we should give ourselves room to give users the power UI." - **Host** proposes a "middle manager" future where ChatGPT calls Codex. **Alexander**: "one possible future" — suited for on-the-go users or non-specialists; specialists will go straight to the tool. ### Developer experience - **Host**: Describes novel "social coding" — he and Kieran (GM of "Kora," an early tester) ran parallel agents on a video call, reviewing outputs together; he shipped a feature in a repo he'd never touched. - **Alexander**: Coding is already more social; envisions developers shifting time toward **planning, design, and validation**, plus "becoming a manager" mindset for enabling agent teams. ### Feature overproduction - **Host**: Raises concern that high throughput creates bloated, ill-fitting products needing "new product management hygiene practices." He then states he welcomes this: "taste is fun to exercise... this is a great future" (with the qualification "that doesn't apply to everyone"). - **Host** (personal opinion): Hopes acceleration yields **many more small, bespoke, beautifully crafted apps** (e.g., a texting app just for him and his wife). ## Mindset & Usage Claims - **Alexander**: Heavy users adopt an **"abundance mindset"** — firing off many tasks without perfect specification; use cases include on-call triage (sometimes full fix, sometimes draft, sometimes just bug localization) and morning phone-based task dispatch. Mobile web supported; iOS app "coming soon." - **Host**: Endorses this as a genuinely different skill — "direct intelligence at a problem" without full formation; draws analogy to his changed habits with Deep Research ("it kind of lets me be more curious"). ## Competitive Landscape - **Alexander**: Calls it "an incredibly exciting time"; positions OpenAI's advantages as (1) **training the model itself** for delegation/mergeability/style/citations, (2) **scalable compute infrastructure** from training experience, (3) commitment to a general AGI super assistant. - **Host's** closing claim: ChatGPT integration is "the big thing" that will differentiate Codex from other tools. ## Live Demo Notes (with uncertainties preserved) - **Alexander** on the documentation suggestion result: "This is not what I was hoping you would see. We clearly have some prompt tuning to do between now and tomorrow." - The "find bugs and suggest tasks" prompt did produce clickable task-stub buttons; **Alexander** attributes the difference to the words "suggest some tasks" in the prompt. - **Host**: UI "has been changing massively every single day" pre-launch (Alexander confirms), so what's shown "definitely is not going to be what you see." - **Host** anecdote: the collapse-state task was initially run in the wrong repo; the agent found something else to collapse in an untested internal app. # Speaker Attribution & Provenance Record **Video:** OpenAI Launches Codex: An Autonomous Programming Agent **Video ID:** `01a0f15a-e004-76c0-b4e8-9e4b68f605d6` ## Speakers & Roles - **Host / Creator (unnamed in transcript)** - Identifies himself as an **early tester** of Codex ("I've been using Codeex for a couple days"). - States he is **recording a review** to be published alongside the podcast. - References his colleague **Kieran**, described as **GM of a product called "Kora"** and also an early tester, who supervised the host's testing. - Note: the guest addresses the host as **"Dan"** at one point ("this UI that Dan's showing us"). - **Alexander Embir (transcribed as "Alexander Ambiraos") — Guest** - **Member of the product staff at OpenAI**, responsible for Codex. - Provides product decisions, model details, and OpenAI vision statements. - **No narrator** is present; the host performs all framing/announcement duties. ## Referenced Products, Sources & Claims - **Codex** — OpenAI's cloud-based software engineering agent, launched "today, Friday" (recording made the prior day). - **Codex 1** — guest claims it is a custom model, "a version of o3 optimized for real world software engineering," claiming it "slightly outperforms o3 on eval like SWE-bench" *(third-party benchmark claim attributed to OpenAI, unverified here)*. - **Codex CLI** — existing collaborative terminal tool; guest states an **updated small model for Codex CLI is planned**. - **Other named third-party products (host mentions, no evaluation by guest):** ChatGPT, Operator, GPT-4.1, o3, Deep Research, Claude Code ("cloud code"), Devon, unnamed competitor agents ("we're testing like four or five of them internally"). - Guest cites his prior experience: **5 years writing native macOS apps**, including pre-OpenAI work. - Guest references internal OpenAI workflows and an internal app demo; host clarifies the demo repo was **internal and has no tests**. ## Promotional Segments - **Opening segment is promotional**: host announces the launch, discloses he received **early access** from OpenAI, and promotes his accompanying written review. - Host's closing remarks ("Thank you for building this. Thanks for letting me try it early. I'm psyched") are appreciative/promotional in tone. - Guest promotes the product throughout via feature walkthrough and demo; host's live demo of task suggestions functions as product demonstration. ## Availability & Evidence Limits - **No curated metadata supplied** — speaker identities derived solely from transcript; the host's surname and the guest's exact name spelling are uncertain ("Ambiraos"/"Dan" per audio transcription). - **Comments availability:** not stated. - Demo UI explicitly flagged as **pre-launch and changing daily** ("this may not be what you actually see"). - No citations, timestamps, or external sources verifiable from the transcript. Huge news. OpenAI is launching a new coding agent. It's called Codeex. Codex is a web-based software engineering agent that's designed to work pretty much autonomously, so you can have it working on many different features and bugs in parallel while you watch. I've been using Codeex for a couple days, and it's pretty great. So, I invited Alexander Ambiraos, a member of the product staff at OpenAI who's responsible for Codeex, to come on the show and talk to us about it. We're going to demo Codeex together and talk through all of the product decisions that led to its release. We walk through Codex screen by screen and he'll talk to us about how OpenAI is thinking about agents and what OpenAI's vision is for the future of programming. Let's jump in. Alexander, welcome to the show. Hey, thanks for having me. So for people who don't know, you are a member of the product team at OpenAI and you are one of the people responsible for building Codeex, which is a new programming agent that is launching today. Well, we're recording technically recording yesterday, but it's launching today, Friday. I'm super excited about it. I got to try it. Um I have a review coming out along with this podcast and uh I just wanted to go through it with you and understand like all the things that you put into it and all the ways that you're thinking about it. So thank you for coming on the show. Yeah, excited to be here and uh thank you for being an early tester. Awesome. So, what I want to do is um just like give people right off the bat a sense for like actually what it looks like and and like we can sort of talk about it together. So, uh so this is codeex terminate processes. Great. This is codeex and it's a coding agent, right? So, uh I can type in a task like uh please replace the headline on the homepage with codeex is out now. Uh, and I can just press code. And one of the really cool things is um it doesn't go into like an agent experience. Like it just adds it as a task. So it's like you're it's basically like built to make me just create a bunch of tasks and then not look at them more or less is what that's how I feel about it. So tell tell me about like this screen and how you thought about this and and why you did it like this. Yeah. So I'm so excited that you're screen sharing this uh and showing people so we get to nerd out about all the details. Um, but you know, for anyone listening, basically Codex is it's a cloud-based software engineer that can work on like many tasks in parallel. And um, you know, there's a ton of AI tools out there. I feel like programming with AI is completely different now than it was like 2 years ago. And this form factor that we're looking at is kind of the beginning of us thinking about what is it going to look like even like a year from now today. Um, and the big shift is, you know, today when people are accelerated, um, working with AI, uh, a lot of it is like very like a very tight feedback loop. It's like very collaborative, like a lot of like really good tab completion, right? And like really good chat. Um, and sort of where we see things going is um, we have these really awesome reasoning models and we want to give them time to think and we want to let them use tools safely so they can do more stuff. for example, like running commands to execute tests to be more sure of their changes um and then iterate. And so we basically want to give the agent its own computer to do work in. And so as we started thinking about that um you know, you kind of realize, okay, this this feels a bit like delegation. Um and I'm sure we'll get into this, but we tried a bunch of different form factors for what it would feel like to delegate to an agent, including like maybe the most obvious one, which is just like talking to chat GPT and having it do stuff. Um but the short version of it is what we realized is that engineers wanted like this really functional tool to be like very efficient in how they delegate. Um and so the thing you see here it's like you know it's very structured. You've got the list of tasks that you have. You can see how many lines were changed in each. You can see what the status of the PR is which is ultimately the thing you're going for. Um, and so this ended up just being a thing that we iterated our way too. Um, that we thought was the best first version to ship, but actually like, you know, I would love it if we end up talking a bit about what it might look like in chat as well because we we definitely plan to bring it there. I would love to do that and and I have a bunch of follow-ups on that specific point about like sort of the chat GBT versus what what this is point. But um, so to give people like a sense um, for how this actually looks. So uh, a couple I did a couple things yesterday. I actually like shipped a feature on one of our products that I've never I've never coded in. Um like I've never touched that repo and I shipped a feature to prod uh yesterday with Kieran is the Kieran is the um GM of that product and he's a really really talented engineer who's also early an early tester of of codec. So he was watching me the whole time to make sure I didn't mess anything up. But it was really cool. Um, and basically like to show people what it looks like. Um, uh, we have this, uh, we have this UI in, um, this is not the right one. Uh, weird. You're looking for the diff, right? Yeah. Where is it? Um, you should be able to click. Um, there you go. Yeah. Nice. By the way, this UI that Dan's showing us has been like editing like changing massively like every single day as we race towards launch. So, you know, thanks again for testing our league. Yeah, this this may not be what you actually see or depending on when you're listening to this, it definitely is not going to be what you see. But, uh, for now, for people who are listening, basically, I clicked into one of the tasks and you can see basically for the feature I wanted to build, we have this we have a um a view that I wanted to create a a persisted collapsed state. we wanted to be able to like collapse that particular view and I just said I just said do that basically. Um and you can kind of see a uh log of all the things it thought while it was doing the um doing the task and then it gives me like a summary of um what it did. I can see a diff um and I can also just push that right to GitHub. And one of the things that um that I noticed is the the summary is very concise. And in talking to Kieran about the code that it generates, um the code seems very um minimal or like tur. Uh can you tell me a little bit about how you thought about making this thing code and and talk about its um talk about what it makes? Yeah. Um it's a great question. So, uh Codeex the agent runs on a custom model that we train just for this product called Codex 1. Um, Codex 1 is a version of 03 that's optimized for real world software engineering, but not only not only optimized for real world software engineering, but also optimized for this form factor, which is, hey, it's going to go off and do a bunch of work and then you're going to get a diff back. And, you know, once you're using this a lot, actually, you're going to be getting many diffs a day back. And uh you know I'm sure this thing we talk about a lot with even human software engineers like would you rather review like 1000 line diffs or 20 50 line diffs or you know 1,000line PR right definitely the thing is you don't want to review the 10,000 line PR right um and so and was as we trained this model we we both wanted to make sure it was great at coding so the model like slightly over outperforms 03 actually on like eval like swbench but more importantly actually we wanted it to produce like code that was really mergeable and then talk about the work that it in a way that was like actually really reviewable for the human reviewer. So, um we put a lot of effort into style here. Um you know, making sure it's not doing things like adding extraneous comments, making sure that uh the style that it's using is actually like the style in your codebase and not like its own style that it has and thinks is correct. Um okay. And so getting to your point about the the PR descriptions, um you know, early versions we've had of tools like this or models that did this would tell you everything about what they did. Um, and you know, just actually to give you a bit of the story, like in our UI, we would like show you kind of the model's thoughts first and then we would show the diff underneath. And whenever like a full-time software engineer was trying to use this a lot, they were always like, "Man, I just want to see the diff. Like, I don't want to read the description until I see the diff. And if the diff is good, then maybe I'll look at the description." Um, and so we kind of ended up realizing like, hey, there's actually like kind of a spec for what a good PR description looks like. Uh, and that's like pretty concise and only maybe explaining like at a high level what it is, the non-obvious parts. Like you definitely don't want to duplicate content that's in the diff. Um, then the other thing we realized is that because it didn't run on your computer, you you didn't necessarily see each iterative step. And so you really want to know how validated is this change and how did the model try to validate the change. And so you can see here on the left side, the model's also describing the testing that it ran. Um, and here, uh, we put a lot of effort into, first of all, just making sure that it's like never hallucinating, but also making sure that it tells you when tests passed and when tests failed, which like super important in a concise way. And then lastly, perhaps the thing I'm most excited about, like if you mouse over that little like terminal icon next to the testing. Uh, yeah. So, it's sort of like the last thing on the third line there. It's a little icon. It's like a carrot. Yeah. So, we'll actually pro the model learns how to site its output. And so it's not just saying like, hey, here's a test I ran. Um, you know, in the case of test that passed, which it didn't hear, you know, it's not saying like, hey, the test passed. Uh, believe me, it's saying, hey, the test passed. Here's like a deterministic citation that we did to actually pull the part from like the log out so you can review it yourself and be super sure. Uh, and in this case, the test it tried to run failed. And it's kind of telling you this because maybe you would want to run it yourself or like upgrade the environment it's operating in to so that those tests can be run. Um, and it's giving you the output there so you can like go and review it and improve it. That's really interesting. This this particular repo. So I actually this uh the one we're looking at I I I kicked off uh the the collapse state task in the wrong repo at first. So this is the wrong repo. This is an internal um this is an internal app we built and so it does not have any tests. Um, and I was just kind of curious what it would do uh if if I gave it a task that was totally not not possible to accomplish and it found a section something else to collapse. Um, so that's kind of just like an interesting little detail, but yeah. Okay, that makes a lot of sense. One of the things that I notice about um this that feels different from like a Devon for example is I don't see this. It has an environment that it uses that it sets everything up and it runs a test and all that kind of stuff, but it doesn't have a browser for example. So it's not going and like logging in to the app to check if it's working or not. Like tell me about that decision. Why' you do it that way? Yeah, I would say that's more of a just like sequencing decision rather than like um a vision decision. Like ultimately kind of like the thing that we view ourselves as building like super long-term is just like one super assistant. Um, and it has a bunch of tools and you don't even have to decide, you know, if you even want to use code mode or if you want to use like, I don't know, newsletter publisher mode. You just have one assistant catch PT and you can just ask it for stuff and it'll use the appropriate tools and it'll also just like answer quickly if that's the right thing or it'll like do work if that's the right thing. So long term that's that's where we're trying to get to just like one thing with all the tools. Um, but what we're starting with is kind of like, hey, we want to ship a research preview. We want to like iteratively deploy this out in like small steps as capabilities grow and we're going to start like the smallest most constrained thing possible. So for instance, uh it doesn't take multimodal inputs yet. We'd obviously love to add that. Uh it doesn't have a browser that would obviously be useful for validating front end changes. Um it doesn't even have network access. So the way that it runs uh is so when when you kick off a task um we set up a container pull the repo into that container um and then with network access we run some setup commands that like you wrote so it's not the agent running those commands it's like you writing those commands and so that can pull in like you know any dependencies like npmi npm install or you know whatever you need and then actually we cut off internet access and I think we updated the logs recently to show that so if you were to like click into logs and scroll to the top you would see like no internet access all the way at the Uh, and then you would see no internet access. Um, yeah. So, like we ran the environment setup that you put in there and then we turned off internet and then the agent runs. And that's just for absolute maximum safety. Um, you know, I haven't actually ever seen it happen, but you know, there's like a theoretical risk or a tail risk that there could be like some exfiltration. Maybe the agent wants to go to Stack Overflow and ask a question about some code and it pastes it in. Right? That's a theoretical scenario. Um, and so we're starting really small in scope and then over time we'll start like adding more and more capabilities. Got it. And that actually brings me to my next thing which is which is one of my gripes about this. um which is it's not it like the fact that it's not in chatbt means that it feels like a very um oneshot type uh user experience which to me makes it feel very like it's definitely for senior engineers where you can kind of like see the entire thing you need to build in your head and you just type it out and then it's done whereas for me for example like um I might want to like go back and forth and chat with chat with it to like figure out okay like what is it that I'm actually trying to build or um in this case in in this particular session I asked it to build I asked to build a feature and then I realized after I built it that I needed to add something else so I asked it a followup um and in the follow-up case it didn't work quite as well as the like oneoff oneshot thing so tell me about that yeah it's it's really interesting like delegating to agents requires like a bunch of like mindset updates that actually I think will take time for people to learn how to get to the most use out of and we'll like I think end up temporarily in a state where we kind of have tools that feel more like you're delegating and tools that feel more like you're collaborating and then our goal at least is bring those together so you don't think about it again like I think about like our future super assistant I don't think about if I'm delegating I just ask it for stuff and it just does stuff um but you know people are pretty used to working like collaboratively with tools locally on their computer right now and in fact we have the codec cli which is exactly that right like so you can do a back and forth CLI have it exe some commands it'll ask you for permission cuz it's it's on your computer, but you can kind of sit with it and and kind of pair program with the CLI. Um, so a little bit about the mind shift mindset shift that we've seen people who get a lot of value out of out of codeex like the agent that you delegate to. Um, I'll just share for because it's you know kind of interesting here. One of them is like an abundance mindset. So something that we've seen a lot of people who are using this a ton do is they just fire off many many many tasks without thinking actually too hard about whether it's going to work or you know whether uh it's like perfectly described or not and whenever you need to do something new you just kind of fire off a new task. And so for example a really common use case is like on call triage. It's like maybe you don't know if uh what the the bug is. you you know you were talking about how like oh like I've noticed it works best if I can kind of see through the full arc of the feature like you don't need to know that you just fire it and then sometimes it's like hey here's like the exact fix and you're just like wow like amazing not only did I save myself time but that that bug was fixed faster than I could have ever gotten to it otherwise other times maybe it just like provides a draft and then you have to land it in your own time and and other times it like just maybe finds where the bug is or helps you just reason about it and so it's kind of like this idea of like this is a service to that accelerates me the developer and I'm going to use it without necessarily always knowing if it's going to like provide emergible PR or not. Um so that's like on call triage as an example. Another like very analogous place we see people use it is like um in every morning like people will kind of like think about what they want to do and then like they're at home they'll just be on their phone like fire off some tasks. We have mobile support coming soon. Well we already support mobile web and a mobile app uh on iOS uh we'll support soon. Um, so they'll just be like, "This is what I want to do." Fire off some stuff, then get to their desk, uh, and like look at what they want to use. Um, so it is it is quite one-shotty in the way people use it, like those two examples I gave you. So I think you're right about that. And so we started um, poking at this like does it need to be oneshotty? And so you saw in the UI there's when you send a task, you can choose if it's going to be in ask mode or code mode. Um, and uh, code mode is definitely the thing we've spent the most time on, but we're starting to experiment with making ask mode faster. Um, and so like, you know, one way that this could evolve potentially is where when you want to do what I just described, like fire off like a one shot or a few shot thing, you basically ask code mode. But if you want to be a little bit more exploratory, you can try ask mode. Um, and so I don't know if you tried this, um, but one thing you could do is ask for some recommendations using ask mode. And that should be relatively fast. It'll probably finish during the like pretty quickly during this call. Um, and then we could try kicking off some of those tasks if you want. Okay. So, what should I ask for? Yeah. Like I don't know. Is there like a class or that you find very complicated that you would love to refactor in some code somewhere? A wish that I was familiar enough with this codebase to tell you, but maybe Okay. What about what about just uh suggest let's run two prompts. And again, this is abundance mindset. Let's run one like suggest places to add documentation. Um, that's a safe one. Actually, a lot of people use it for documentation and it's really good at documentation. And then let's do another one which is like find some bugs and suggest some tasks to improve the bugs or to fix the bugs. Cool. I I think that this is uh really interesting. I want to pause here for a sec. like the sort of abundance mindset that you're talking about where um yeah, you can just like direct intelligence at a problem and you don't have to like have it like that well formed and if it doesn't work it's fine. And that's just a different way of thinking about how to how to program or how to manage a resource. Um that I think is really interesting and yeah like if if there's some sort of like priority bug that's going on like why not send off like three different workers to figure out while you try it yourself cuz if they fix it like that's great. Um, and I think obviously there's always a time and a place for understanding the full system and and maybe stepping through it step by step, but it's like it's not every time. And that's an that's just an interesting shift. It's a it's a different skill it seems like. Yeah. It's like I think I figure you probably use PD deep research on occasion. Yeah. Right. And like um if I think about like how some of my habits have changed like I'm much I I deep research a lot of things that I wouldn't have spent like I don't know how long it would take me to do a deep research but probably quite a long time like hours and now I like read sort of deep researchers on custom queries that I have like way more often. It kind of lets me be more curious in a way. Um yeah like you know many things a day basically. Um and I think there's kind of a similar thing here with agents in general. Yeah. Yeah, it's like you find you have more questions to ask when it's really easy to ask a question to get a really good answer, you know? Um I find that too. I'm just I've learned way more because of 03 and deep research. Um and just like AI in general. Um what about like I feel like there's a tension here that I I sense in this product and I've sensed myself and built trying to build these things. There's a sort of tension between um making something good for a particular situation like for example like you know uh this is great for picking off a bug or a feature um but you kind of get this like loss of flexibility where it's not for example it's not nearly as good at just doing follow-up questions and CHBT is just great at that. Um, and so how do you think about that when you're designing something like this? The sort sort of trade-off between specializing and the brittleleness or loss of flexibility that you get and how do you manage that? Yeah, I think the long-term goal, you know, it's the I'm sure you hear this a lot, but you know, it's the G& AGI. Uh, it's to build something pretty general. And, um, a lot of specialization, at least when it comes to like building UI, is a bunch of design decisions that we have to make. But if you're just talking to an entity, it can make a bunch of decisions about the right behavior and just kind of be general for you, right? And so kind of the where I see things like this going and maybe just like working with agents in general is you can have a conversation with an agent and that is incred that that should be an incredibly general thing. Like I was mentioning earlier, it shouldn't only be for coding. It should just be an agent. Um and it should be able to work across any modality whether you're, you know, in your car or at your desk. Um, so that thing stays general and it should be able to like do all the things it needs using tools, etc. Um, but you know, when we're professionals doing a specific thing, like right now we're recording this podcast and this is like some pretty specialized UI, but it's really good. Like it would be quite annoying to have to like use a chat interface to mute myself or adjust my volume here, right? And so kind of the way I think about it is there can be nearly an infinite number of like bespoke possibly even AI generated like UIs that like serve the specific purpose of the user who knows kind of like exactly what they want. And so like for me like the most interesting thing about this CEX research preview isn't actually the UI although don't get me wrong we've spent a little like rewriting it massively as we speak. But um the most interesting thing is actually training a model that's designed to work more more independently and make the most of that asynchronicity and its own comput environment and then building the actual comput environments that we can scale up and that like let people set up the agent to have the tools that it needs. So once you have those two things right the model and the comput environments we can then start bringing that that UI to everywhere. So, you know, I would, like I mentioned, I would love for that to be more readily available just like if you're talking to chatbt. Um, I would love for that to be available also closer to where developers spend their time, right? So, if you spend a lot of time in terminal, then like the codec cli would be a perfect place for you to be able to like, you know, delegate to that agent. Similarly, if you spend time in your editor or in your CI or in your issue tracker, like all of these places should be places where the agent is just sort of like ubiquitously available for you to delegate to it. Well, so, so let me just push on that a little bit. So, uh, so in a in a perfect future, basically I'm talking to CHBT and CHBT is the one that's like calling, uh, codeex and telling it to, okay, go do what do this thing and then handling the follow-ups to be like, actually, I want you to do it a little bit better and I'm maybe not even talking directly to a chuch is almost like the middle manager. Um, yeah, that that I think that is one possible future. Um, and I think that is a feature that might you might use if you're like on the go like on your phone, not at your desk or you know, let's say I I don't spend like a ton of time like on marketing, but I want to like interact with some like marketing tools. Like maybe I'd go through CHP because I don't have mastery of the the actual like underlying systems. But then if I'm like a full-time person who spends a lot of time like coding or you know whatever thing that it is that I'm doing, I probably have a lot of like mastery that I've learned over time and that also brings me great joy in my life hopefully uh to spend time with these tools and so then I would like go straight to the tool um and the should be like just available in that tool. Yeah. So I totally get that especially for the for like the interface layer and like having specialized interfaces for specialized tasks makes total sense. Uh what about at the model layer? Like obviously the goal is to have a perfectly general model that no matter what you ask it, it can like just fulfill the request. But also it seems like um for example when you do you know you did reinforcement learning on this model to make a better more sort of like senior software engineer type personality but even within that like this model clearly has a different personality than cloud code um or like the underlying model for cloud code. Um and so like how do you think about that? There's there's always even if you're trying to be as general as possible, there's always these sorts of like trade-offs between making it good for that thing and making it generally, you know, it's it's it's flexibility in other areas or it personality. Totally. Um yeah, I mean I feel like at at OpenAI at least we've kind of done this like a few times now where we've shipped chatbt, a ton of people use it. Um and then we get some feedback from a specific audience we care about. So like with GBT4.1 developers and we just you know spent a bunch of time with them um this is a different team but you know they spent a bunch of time like talking u with developers understanding their feedback and kind of like creating like a different set of evals that we realized we like wanted to improve on we cared about and so then we had this decision right like do we try to um you know get uh a bunch of like improvements into the mainline model uh which takes time and has a bunch of trade-offs or do we kind of want to speedrun on the side, ship a separate model um and then like reintegrate some of those changes. And I think our belief as a company is that like there are going to be times where we kind of want to speedrun something. So like often just maybe even for learning purposes just to like have the flexibility like really go deep with the set of customers and like kind of like generate the evals that they have in their heads. Um and then from there like ship it, validate and then take those configs or you know those changes that we're making to the model and remain them. when like it seems like whenever we can do that the whole overall system gets better and maybe even more powerful than a custom side thing that we've done. That's really Yeah. Go ahead. Um, and like what that makes me think about because one of the one one of my other like little gripes with this is it reminds me kind of of operator where like this cool thing but it's like separate from chatgbt and like it's I don't think that they've you guys have released an operator update since the first one and so it just feels like it's like hanging out there and and not necessarily getting improved or not I'm not using as much as I am using like sort of base chatbt and so is that kind of the like one version of of the vision is obviously like codeex stays stays as this separate thing but then you integrate all the learnings back into like the base 03 that I use inside of chat GBT and that's how everything coexists together or how do you kind of make sure that you're not building like this bulcanized thing that's kind of forgotten about in you know 3 months or whatever totally yeah man I have I have so many so many fun thoughts here um one thing I'll say is that uh yeah we have a lot of sort of like these capabilities that we've we've talked about like being kind of like different and separate like are coming together and like that's a thing we think a lot about and it's I'm very jazzed about it. So I'm excited to share more as that happens. But let's take let's take CEX um the uh in in my mind here there's there's kind of like two interesting things. The first is like what we said which is like hey anything we learn um as we like build this codeex model is like really helpful to us just as we think about agents in general and like you know like this idea of like say like citations right or like describing your work really efficiently for the user to read um after you've done a lot of work uh like tuning the steerability so that it like kind of makes the right amount of assumptions uh which I'm not saying we nailed perfectly but like that's a that's a theme like that's a generalizable thing for agents and like something that's going to be useful in general. eneral um similarly um and I don't know if you have this in your briefing but we are going planning to release an update um an updated small model for use in the codeex CLI um and you know there's a lot of I mean it's pretty obvious right but there's a lot of overlap between these two models and then actually you know a lot of the learnings that we have from like both of those codeex models like we plan to use even in like mainline models right so there's a lot of that generalizing that comes back I feel like your question also though is a bit about user experience and like having to go to operator, right? Or having to go to codeex. And so like, you know, I think Codex is kind of interesting because it's maybe one of the first products or features we've built into chatbt where we have a professional audience that like spends a lot of time in their tools every day. You know, like a lot of how like chatbt overall is quite a general tool and I think this is like maybe some of the first time that we're getting like fairly specialized. And so my view here is that like we're not exactly sure what this should look like. I I think like catch PT a year from now where we have more of this will look fairly different from chatp today but the goals we'll have in mind will kind of be these things that I've been saying which is like I think we we're trying to build a generalized assistant and we cannot lose sight of that but we should give ourselves the room to give users the like power UI that they want. Um so for instance um just to give you an example going back to your opening question about the UI uh you know it's a list right and it's a list and it has features like archive like why do we have that well it turns out that people uh internally who use codeex use it a ton every day and when they're using it and it's just like mixed in with chat it's a little hard to find your things and then you know there's kind of this workflow you develop where you basically you're like hey I have an idea like for example like so I'm on the product team Uh, I mostly do small changes. People make fun of me affectionately at work. Uh, but you know, a string should be different or there's this bug here, right? And if the bug's really hard to fix, I'm like that that's vegetables. I'm not going to eat that. I'll, you know, I'll put it in in a small ninja. Yeah. But if it's like an easy bug, you know, um, I'll wham it. I'll explain what the word wham is later, but that's our code name for the project. And so, you know, I'm whamming a bunch of stuff and then I don't want to track it separately. like I just want to have this list of things and then like when they're done my workflow is basically look at each one and make a decision on if it's mergeable or if I want to like pull it open to my computer test it maybe change it or if I'm just like this is over like I don't have time to do this and so that workflow really needs that UI of like what did you open a PR what is the status of that PR and the ability to archive so that I'm only looking at the things that I my current tasks basically um so that's just an example of like the power user UI that um that makes a lot of sense yeah we That was important. Yeah. Yeah. I feel like chat is only appropriate when it's incredibly underspecified what you actually want to be doing. Whereas as soon as you know exactly what you should be doing, like chat is not the right really the right interface. Um I'll add one thing to that which is actually the other cool thing about chat is that it unlocks a lot of like emergent behaviors that are just mind-blowing. Right? So one I I like I'm obviously really excited to bring to bring us back into chat as well. Um but you know one experience that I had when we' prototyped in chat was um I had uh I had asked for a change on on front end and actually when I was getting started on this project I had I had spent I spent like 5 years including before open AI just like writing native Mac OS apps uh uh and so you know I'm not super familiar with the latest you know tailwind whatever stuff so uh I asked for this change and I a bunch of like classes were added in line and I'm like I don't even what is this class? So I asked but we were in chat so I just replied with what is this? Can you explain it to me? And because we were in chat um and the context of like what was changed was just like in line in chat. Chat replied quickly which was the thing you were saying is one of your gripes that this doesn't reply as quickly right. Chat replied quickly and it asked me do you want me to generate an image for you? And I was just mind blown. I said absolutely and then it generated an image and you know I was very happy. Um, and so I think I think it's important that we we always like make sure that like the overall assistant has access to these tools so we can experience things like this and then like work those into the more functional like UIs as well. How do you feel about and with your own personal experience and and what you see internally or I don't know other beta customers or alpha customers that are using this like how this changes what it is to be a developer, what the developer experience is. And I'll give you an example in in my testing over the last couple days um with Kieran. Uh again, he's a GM for Kora. He's, you know, super technical. I'm like technical, but like in a I can just build the stuff to make it work kind of way. Um and what was really interesting is we just sat together on a video call. We were both screen sharing. Um we both had a bunch of agents up and we were just like talking about how we wanted to make the product better, Kora better. And then he would just say, "Okay, I want you to like, you know, build this little thing." And I' and I'd be off being like, I want to fix this little bug. And both of us have like these different agents all working on different features and bugs all at the same time. And we're just chatting while we do this. Like we have the brain space to be able to like talk about what's going on. You know, an agent would come back, then we'd like kind of look at it together and be like, is this good? Is this not good? And then either edit it or merge it. And it was just like a very different it was like social coding in this like weird way where we're just like chatting together and work is getting done which I've never really experienced before and um feels like a new model for building things that was not really possible previously and I'm kind of curious if that resonates with your experience or if there are other things that you're noticing about what it how this changes what it is to be a developer what developing looks like. Yeah. Um that sounds pretty fun. I'd even say even like before we had any uh you know like before Codex I I've already started feeling coding is like more social. It's like even if it's just me coding with an LLM. Um and yeah, you know, like that startup I was tell I mentioned that I I was working on like I I built the first prototype for one of the things that became it in the airplane without Wi-Fi. Uh and I would never do that today. Like if there was no Wi-Fi, it's just over like I'm going to watch a movie. I just can't do it. Um, and you know, I do think this is we're kind of on the precipice of it'll never like change of similar magnitude. Um, so the vision for like what it should feel like to be a developer if we get things right. Um, and maybe what it feels like in general to like just be a knowledge worker. Um, the vision in my mind is you should be um able to do the work that you want to do. Um, and maybe that's because it's work that's difficult to automate, which is a lot of work. Um maybe it's it's work that's like very ambiguous uh that requires a lot of like complex decisioning uh or maybe work that you just want to do for fun or you want to be creative and like that's the stuff you do and I think it's really important that we invest in making sure that when the when you're doing the work yourself you're maximally accelerated right so like things like the codeex CLI that you can pair with I think are critical for us to invest in but then the the lion's share of kind of like known work should just be done by agents that you're delegating to And so I think this kind of like shifts where we spend our time. Um and maybe we're spending more time um in planning or like thinking about what to do, more time in design. Um and then more time in like validation as well. Um now I do think it's interesting like you know right now um I think at least for the next couple months we're we are going to also be spending time thinking about how to set up the environment for agents. Um, and so it's not only like um I think we're only going to be spending our time like being creative. I think there's also going to be a lot of like it's a bit like becoming a manager and you're thinking about I have this team and how do I enable my team to be productive? I mean and it creates it like creates new problems that you still need to solve. So like a really interesting example that I'm noticing is um you can implement so many features that the features start to crowd in on each other and the product is just feels like less well thought through because like you have so much throughput to just go like do this little thing and it just takes 10 minutes and then you've done that like 50 times and you're like this product is like way too bloated and no one's like stepped back and been like how does all this stuff fit together? Um and that I think is like we need new product management or like hygiene practices for we have so much capacity to build stuff or fix bugs like how do we deal with the the overp production of of features almost you know which is a new problem. Well I I have some takes on this. Uh, so I don't think this applies to everyone, but at least I'm happy to hear what you're saying in that I think like taste is like fun to exercise. Yeah. And so like and also like great fun for humans, you know? So it's like I'm excited like oh we can produce too many features and now we have to like choose which ones. I'm like this is a great future like wow product person's dream. But obviously I know that doesn't apply to everyone but for me that that sounds awesome. Uh the other thing that I like hope that happens is that um we actually just build many more software products and I don't mean like many more features but like many more apps and this again is this is just like my personal opinion but I really like these like small like beautifully crafted apps that have like a small number of features and you know and sort of almost the more niche the use case like kind of the more fun it is to use them for a little bit. Um, so like you know an example in my mind that I've like poked at but I haven't really spent time on is like maybe like a texting app but for just me and my wife only you know like that would just be kind of a slightly ridiculous thing to consider doing while you have a full-time job like a while ago but like I would love to have that app and like it doesn't have to have many features but it's just for me right and I think that like as software development gets like more and more accelerated like my hope is that because it's like we can produce more of it we end up actually using much more but in much more bespoke ways for That makes sense. Yeah. And I I think you can see that in the history of other art forms like you know photography or illustration where 150 years ago like you had to do like woodcut blocks and then we figured out how to like do mass reproduction of photos and and it just there's a whole Yeah. It's it's a similar kind of thing where now we all have a camera in our pocket or we can do studio like generations or whatever, you know. Well, yeah. Now we're recording a podcast together, right? Like for on a like specific topic. Yeah, exactly. Um, so I want to uh go back because uh our our ask query came back a while ago. Um, so I'm gonna make forget about that. So, so we asked it to suggest documentation. Um, and so it gave me some interesting things. It said the repos guidelines emphasize documenting Ruby classes with Yard and seamless controllers apprehensive JS doc blocks C development guide. And then it just founded some places where Yard documentation is lacking. Um, yeah. So this is real quick. This is cool. This is not what I was hoping you would see. Um, we clearly have some prompt tuning to do between now and tomorrow. Um, because let's Can we check out the other one real quick? Because so this is good, but what what I would love to see in there is that it actually stubs out tasks for you that Oh, there we go. This one did it. And I think that's because we said suggest some tasks. Like we put those words in the prompt. Um, and so it's kind of similar, right? It's answering kind of the question, but it's giving you these buttons you can click to like actually do the thing if you want to do it. Interesting. Okay. So, I'm seeing so we said find some bugs and suggest some tasks to fix the bugs and it says issue number one and it gives me some relevant code and then it has a play button on the code which if I click it just it does the changes that it's that it's uh suggesting. Exactly. That's really right. And so this is us beginning to like sort of play with this this this gripe that you have right of like the sort of the interaction loop. Um and you know the us beginning to think like yeah how can we make it so that it's like if you want to be more quickly like sort of collaborating with the model to figure out what to do you can um you can do it. And also in a way how can we encourage it? How can we you know this is going back to like a lot of what we're spending our time thinking about is like this future where agents are writing a lot of code like how do we make that work well? um you probably would rather like get a large refactor done in a bunch of small PRs that don't have merge conflicts and all independently compile. Um so for instance like a common use case is if there's a large file you like suggest several tasks to um break this down into a smaller class and then you can like do the refactor in like a few small buttons. So basically this is this is something we're thinking about and like I think longterm like our goal is to like converge a delegation and pairing real-time pairing into just like a single experience. That's interesting. Okay. And and we only have a couple minutes left so I really need to ask like how do you see the agent landscape evolving? So there's a lot of agents. Feels like every programmer is working on their own agent. Um there's like the the big labs like cloud code's got you know cloud's got their agent. Um there's there's like a ton of startups. There's like the Devons of the world and there's a couple that are coming out soon. Like we're testing like four or five of them internally. And so how do you think about this like codeex versus every other agent the the the the difference in the positioning or the functionality? Um and then more generally like how do you see that market evolving? Is there like is this sort of like a one agent to rule them all type situation or do you think there's going to be sort of like this ecosystem of agents with different personalities? Yeah, I mean I I just think this is an incredibly exciting time to be doing software development uh because there's just so much innovation happening and there's like so many good products out there. So personally just like really excited about that. Um I think the things that we're we're really focused on and uniquely positioned to do well are like well the fact that we basically can train the model, right? And we can go as deep as we want into making a model that's like as good as possible for this specific use case, right? And so like the things that I'm most excited about us doing are like things like well you know obviously having like really good coding intelligence. Uh but then beyond that like really thinking about like okay but you know this is going to be used by an engineer delegating to many agents in parallel like how do we make that mergeable like how do we get the style right the instruction following the steering you know have it site um its work stuff like that. And so I think like for us like really leaning into the model is like definitely like one thing that we're going to continue to do. And then I think the other thing is like just like thinking about like the scalable compute infrastructure. It just happens to be something that we're like quite good at here because of the way we do training. Um and then lastly like for me um and this might be like a little bit more out there but like ultimately like so the reason that I work here uh you know bring the benefits of AGI to all humanity and like if I think of the shape of that that's not like some like ultra bespoke thing. It's like this general like AGI super assistant. And so like that's kind of the world that I want to live in. Like I want to wake up and just like well probably not immediately maybe go for a walk first and look at my phone. But then at some point I want to just like reach out to an assistant like have a conversation with it and like just have one thing and it does stuff and then I can like dive in and do stuff myself. And so I think like that's I feel like the the chat PT is like as a as an app and as an organization is like very like AGI super assistant pill. And so like for me that's kind of where we end up bringing this towards. Yeah, that makes sense. The the integration with HGBT is the big thing that's going to make this very different from any other um any other tool like this. Yeah, yeah. Uh Alexander, uh it was so great to chat. Thank you so much for coming on. Thanks for building this. Thanks for letting me try it early. I'm psyched to see where it goes. Cool. Yeah, thanks so much for trying it early. Thank you for all the feedback. Hopefully you noticed many uh many of the issues are addressed. Um, and yeah, thanks