OpenAI just dropped their Cursor killer - CourtneyR.dev's 2nd Brain

OpenAI just dropped their Cursor killer 🔗 **Source:** [OpenAI just dropped their Cursor killer](https://www.youtube.com/watch?v=qKf9sgKFQLU) > [!note]+ Document Notes > tags: [ai-coding-tools, codeex, openai, developer-workflow] > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=qKf9sgKFQLU > date created: 2025-01-01 00:00 > > # 🏷️ Title: OpenAI just dropped their Cursor killer >  ## 🧰 Action Inbox - [H1] Try Codeex app for multi-project workflow management — Free release available #ai-coding - [H2] Consider Blacksmith for CI/CD speed improvements — 8-10x faster builds #devops - [H3] Evaluate work tree implementations for parallel development — Current solutions have limitations #git-workflow ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Codeex App](https://codeex.com) - [Blacksmith CI/CD](https://useblacksmith.io) ## 📝 Summary - OpenAI released Codeex, a new desktop application for Mac that provides a GUI for AI-assisted coding workflows - The app integrates CLI functionality with project management, allowing developers to work on multiple projects and threads simultaneously - Key features include work trees, cloud environments, automations, and skills/MCP server integrations - Despite being Mac-only and having some rough edges, early users report high productivity gains and workflow transformation - The tool represents a shift from terminal-based AI coding tools back to GUI-based interfaces ## 📖 Main Content Codeex is OpenAI's new desktop application that serves as a comprehensive GUI wrapper around their existing CLI coding tools. The app addresses a fundamental problem with current AI coding workflows: managing multiple projects and parallel tasks while maintaining context and history. The application provides several key components: - **Desktop GUI**: Native Mac application for managing coding projects - **CLI Integration**: Shared history and configuration between CLI and GUI - **Work Trees**: Implementation for working on multiple branches simultaneously - **Cloud Environments**: Integrated cloud-based development with GitHub sync - **Automations**: Cron-like scheduled tasks with AI prompts - **Skills System**: MCP (Model Context Protocol) servers for extended functionality The tool is positioned as competing directly with Cursor, Claude Code, and other AI-assisted development environments, with early users reporting significant workflow improvements despite some configuration challenges around environment variables and work tree management. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/qKf9sgKFQLU?t=0) — [H1] Introduction and Product Overview - Key idea: Theo stopped using Cursor entirely for 2 weeks due to Codeex - Evidence: "I bought a second laptop" to continue using the NDA product #### ⏱️ [02:30](https://youtu.be/qKf9sgKFQLU?t=150) — [H2] Blacksmith CI/CD Sponsorship - Key idea: Build times improved from 2-3 minutes to 47 seconds with Blacksmith - Evidence: "8 to 10 times faster" builds by changing "Ubuntu latest to blacksmith" #### ⏱️ [04:45](https://youtu.be/qKf9sgKFQLU?t=285) — [H1] What is Codeex? - Key idea: Multi-component system including CLI, web app, and desktop application - Evidence: "shares history between the CLI runs and the app runs" #### ⏱️ [05:30](https://youtu.be/qKf9sgKFQLU?t=330) — [H2] Similar Tools Comparison - Key idea: Not first to market - Conductor, Codeex Monitor, and Anti-gravity exist - Evidence: "Ben, my channel manager, called me out hard for this. And now he's admitting he's wrong" #### ⏱️ [07:00](https://youtu.be/qKf9sgKFQLU?t=420) — [H1] Live Demo - Lawn Project - Key idea: Building Frame.io alternative entirely within Codeex - Evidence: "all of the actual scaffolding of the app and building it and creating the functionality, all of it was done across many threads" #### ⏱️ [08:15](https://youtu.be/qKf9sgKFQLU?t=495) — [H2] Parallel Workflow Management - Key idea: Can work on multiple projects simultaneously while tasks run - Evidence: "I feel more like a manager than ever, but I also feel way more productive than ever" #### ⏱️ [10:00](https://youtu.be/qKf9sgKFQLU?t=600) — [H2] Work Trees Implementation - Key idea: Work trees are "the wrong primitive" - copies instead of true git work trees - Evidence: "you can't have the same branch or commit checked out in two places at the same time" #### ⏱️ [12:30](https://youtu.be/qKf9sgKFQLU?t=750) — [H2] Cloud Environments - Key idea: Cloud development integrated into same UI but requires GitHub sync - Evidence: "Everything inside of codeex has to be a git repo" #### ⏱️ [15:45](https://youtu.be/qKf9sgKFQLU?t=945) — [H3] Configuration Challenges - Key idea: Environment variable management is unclear and problematic - Evidence: "I still haven't figured out how to make it so when I create a work tree that the env is carried over" #### ⏱️ [17:30](https://youtu.be/qKf9sgKFQLU?t=1050) — [H2] Skills and MCP Integration - Key idea: Extensible through skills browser with practical automations - Evidence: "yeet, which will stage, commit, and open a PR" #### ⏱️ [19:00](https://youtu.be/qKf9sgKFQLU?t=1140) — [H2] Usage Patterns - Key idea: Codeex for git repos, Claude Code for general computer tasks - Evidence: "if I have any intention to commit and push this, I'm probably doing it inside of codecs" #### ⏱️ [21:15](https://youtu.be/qKf9sgKFQLU?t=1275) — [H3] Automations Feature - Key idea: Cron-like scheduled tasks with AI prompts for maintenance - Evidence: "Something like writing a change log automatically, summarizing CI failures" #### ⏱️ [23:30](https://youtu.be/qKf9sgKFQLU?t=1410) — [H1] Native Alternative Attempt - Key idea: Loved workflow so much he tried building Swift alternative - Evidence: "I built a full desktop app from scratch with Swift and AppKit" #### ⏱️ [25:00](https://youtu.be/qKf9sgKFQLU?t=1500) — [H1] Workflow Transformation - Key idea: Shift from wanting to edit code to orchestrating agents - Evidence: "I don't want to be in there editing code. I don't want to be in there looking over every line" ## 📚 References - [Codeex](https://codeex.com) - [Blacksmith](https://useblacksmith.io) - [Conductor](https://conductor.ai) - [Frame.io](https://frame.io) ## 🗣️ Paraphrase - OpenAI released Codeex, a desktop GUI application that wraps their CLI coding tools, enabling developers to manage multiple AI-assisted coding projects simultaneously with shared context and history - The tool includes work tree functionality for parallel development, cloud environments for remote work, and automation features for scheduled maintenance tasks, though configuration management remains challenging - Early adopters report significant productivity gains and workflow transformation, with the tool representing a shift from terminal-based AI coding back to GUI-driven interfaces ## 📰 Newsletter **OpenAI's Codeex App: A New Paradigm for AI-Assisted Development** The AI coding tool landscape just shifted dramatically with OpenAI's release of Codeex, a desktop application that's converting even die-hard terminal users back to GUI workflows. This isn't just another code editor - it's a project orchestration platform that lets developers manage multiple AI coding threads simultaneously. What makes Codeex compelling is its approach to parallel development. Instead of waiting for one AI task to complete, you can spin up multiple threads across different projects or branches, effectively turning coding into a management workflow where you guide multiple AI agents toward your goals. Key features include work tree support for parallel branch development, integrated cloud environments, and an automation system for scheduled maintenance tasks. While still Mac-only with some rough configuration edges, early users report productivity gains significant enough to change their entire development approach. For WordPress developers working on multiple sites or plugins, this parallel workflow model could be transformative for managing complex projects with AI assistance. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Demo Codeex workflow at conferences, create comparison content with Cursor/Claude - Education: Workshop on parallel AI development workflows, best practices for project orchestration - Developer experience: Document integration patterns for multi-project development environments - Developer marketing: Case studies of productivity improvements, workflow transformation narratives - Community management: Survey developer tool preferences, gather feedback on GUI vs CLI preferences #### Community - Maintainers: Evaluate AI-assisted maintenance workflows, automation opportunities - Contributors: Training on AI-assisted contribution workflows, parallel development techniques - Sponsors: ROI analysis of developer productivity tools, team efficiency metrics - Ecosystem: Cross-project coordination using AI orchestration tools #### WordPress - Core: Evaluate AI assistance for core development workflows, parallel branch management - Community: AI-assisted meetup content creation, automated community maintenance tasks - Training: Curriculum on AI-assisted WordPress development, modern workflow patterns - Documentation: AI-generated documentation workflows, automated content maintenance - CLI: Integration opportunities with AI coding tools, workflow optimization ## 🧪 Hypotheses - GUI-based AI coding tools will outperform terminal interfaces for complex project management within 12 months - Parallel AI agent orchestration will increase developer productivity by 3-5x for multi-project workflows - Work tree implementations in AI tools will converge on copy-based rather than true git work tree approaches - Developer tool preferences will shift back toward GUI interfaces as AI capabilities increase ### 📊 Methodology - Study design: A/B testing of GUI vs CLI AI coding workflows across 100 developers for 30 days - Data sources: Productivity metrics, task completion times, project complexity scores - Experiments: Parallel workflow benchmarks comparing serial vs concurrent AI task management ### ❓ Questions - How will work tree implementations evolve to better support parallel AI development workflows? - What configuration management patterns will emerge for AI coding environments? - Which developer workflows benefit most from AI agent orchestration vs direct AI assistance? ### 🔮 Future Research - Comparative analysis of AI coding tool architectures and their impact on developer productivity - Investigation of optimal UI/UX patterns for managing multiple AI agents simultaneously - Study of developer workflow transformation patterns as AI capabilities advance ### 💡 Implications - Practice: Fundamental shift from code editing to AI agent orchestration in daily development - Policy: Need for new guidelines on AI tool evaluation and adoption in development teams - Security: Increased attack surface from multiple AI agents accessing codebases simultaneously - Education: Training programs must evolve to teach AI orchestration rather than just AI assistance - Funding: Budget allocation shifts toward AI coding tools and infrastructure vs traditional IDEs ### 🧠 Learning Styles Assessment Reading level estimate: 10th-11th grade #### 👀 Visual learners - Present: Screenshots of Codeex interface, workflow diagrams, side-by-side comparisons - Improve: Architecture diagrams of AI agent orchestration, visual workflow maps #### 🔊 Aural learners - Present: Video walkthrough with detailed narration, live demonstrations - Improve: Podcast-style discussion of workflow transformation, audio summaries #### 🗣️ Verbal learners - Present: Clear terminology definitions, analogies to traditional development workflows - Improve: Glossary of AI coding terms, comparative language between tools #### 🧩 Kinesthetic learners - Present: Step-by-step setup instructions, hands-on demonstrations - Improve: Interactive tutorials, sandbox environments for testing workflows #### 🧠 Logical learners - Present: Feature comparison tables, productivity metrics, workflow flowcharts - Improve: Decision trees for tool selection, quantitative performance analysis #### 🧑‍🤝‍🧑 Social learners - Present: Community discussions, developer testimonials, team adoption stories - Improve: Peer review exercises, collaborative workflow examples #### 🧘‍♀️ Solitary learners - Present: Detailed documentation, self-guided exploration opportunities - Improve: Personal productivity tracking templates, individual assessment tools #### 🌿 Naturalistic learners - Present: Evolution of development tools, ecosystem thinking about AI tools - Improve: Tool lifecycle analysis, sustainable development practices with AI ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Video has spoken narration describing interface interactions - Improve: Detailed alt text for screenshots, structured heading hierarchy in documentation #### Keyboard navigation - Present: Desktop app likely supports standard keyboard shortcuts - Improve: Document keyboard accessibility patterns, ensure full keyboard navigation #### Contrast and readability - Present: Standard desktop application contrast ratios - Improve: High contrast theme options, font size customization #### Text resizing and reflow - Present: Native Mac app scaling support - Improve: Responsive layout design for different screen sizes #### Media and captions - Present: YouTube auto-generated captions available - Improve: Professional captions, transcript downloads, audio descriptions #### Forms and interactions - Present: Standard form controls in desktop application - Improve: Clear error messaging, accessible form validation #### Standards reference - Map desktop app accessibility to macOS accessibility guidelines and WCAG 2.2 AA ### 🌍 DEIB Assessment #### Cultural breadth - Present: Single developer perspective from US-based creator - Improve: Multi-regional developer workflows, international team use cases #### Inclusive language - Present: Technical terminology generally accessible, some developer jargon - Improve: Plain-language explanations, avoid cultural assumptions #### Neurodiversity support - Present: Multiple interaction modalities (GUI, CLI, automation) - Improve: Customizable interface complexity, attention management features #### Representation - Present: Single male developer perspective - Improve: Diverse developer voices, varied team structures and workflows #### Psychological safety - Present: Enthusiastic but honest critique of limitations - Improve: Balanced coverage of learning curves, failure scenarios ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical connection between parallel workflows and productivity gains - Inductive strength: Solid evidence from personal extensive testing over weeks - Causal reasoning: Clear cause-effect relationships between tool features and workflow improvements - Analogical strength: Good comparisons to existing tools and workflows #### Fallacies - Appeal to novelty: Assumes newer AI coding approach is inherently better - address by discussing trade-offs - Anecdotal evidence: Heavy reliance on single user experience - acknowledge need for broader testing #### Tone of voice - Overall tone: Highly enthusiastic and convinced, with honest acknowledgment of limitations and rough edges ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on critics or competing tools - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: High enthusiasm and excitement, but balanced with honest critique of limitations ## 🎯 Conclusion Codeex represents a significant evolution in AI-assisted development tools, moving beyond simple code generation to comprehensive project orchestration. While still in early stages with Mac-only --- ## Full Transcript [00:00] I have a confession to make. For the [00:01] past 2 weeks, I've entirely stopped [00:03] using cursor and I've barely used Claude [00:05] Code at all. The reason why is a new app [00:07] that OpenAI just put out for developers. [00:09] It's called Codeex. Yes, again, while [00:12] the name is annoying, the product is [00:14] actually really, really good. Way more [00:16] so than I ever would have expected. It's [00:18] a different way of managing your agents [00:20] across projects while you're doing real [00:22] work. It was built by and for developers [00:24] and it feels fundamentally different [00:26] from any other similar tool I've used [00:28] and everyone else I know with early [00:30] access feels the same. This honestly [00:32] feels like one of those moments where [00:33] just like the way we build changes on a [00:36] fundamental level. I know we're having a [00:38] lot of those lately, but like I can't [00:40] stop using this app. I was under NDA, [00:42] but I wanted to keep using it. So, I did [00:43] something I never thought I would do. I [00:45] bought a second laptop. Yeah, it's that [00:48] good. I still can't believe who I've [00:51] become that I haven't opened cursor. I [00:53] didn't even install it on that laptop. [00:55] I've just been building with the new [00:57] codeex app and they put it out for free. [00:58] By the way, I have so much to say about [01:00] this. I can't wait to show you guys how [01:02] it works, why I like it so much, and all [01:04] the cool workflows that I've built [01:06] around it. As you all know, Open Eyes [01:07] never pay me a scent. In fact, they're [01:09] not even giving us free access to the [01:10] models during the early testing anymore. [01:12] I've paid every cent of everything I've [01:14] done here. And this app's also in direct [01:16] competition with a ton of my [01:17] investments. So yeah, I am the most [01:20] biased against this you can imagine, and [01:22] I'm still about to shill the absolute [01:23] hell out of it. I just want to make sure [01:25] you all know nobody is paying me today [01:27] to talk about anything other than [01:29] today's sponsor. As you can probably [01:30] tell, I've been building a lot more [01:31] lately. Not just like writing more code, [01:33] but also building that code on servers. [01:36] And that means I have to wait for the [01:37] builds to complete. And I used to have [01:39] to wait a long time, especially when I [01:41] started building with Rust. And then I [01:43] moved to blacksmith and all of the pain [01:44] disappeared. I'm going to be real with [01:46] you guys. I thought this is a cool [01:47] product and I was really happy to [01:49] recommend it before, but then my team [01:50] moved over and that means my team set it [01:52] up. Not that it was hard to set up. You [01:54] just link it to your GitHub and then [01:56] change one line. But now that it is set [01:58] up, anytime I make a new project and I [02:00] want the CI to be less slow, I literally [02:02] go to the runs on and change Ubuntu [02:04] latest to blacksmith and then suddenly [02:06] it's like 8 to 10 times faster. Here are [02:10] the real builds I was doing for my new [02:12] CLI app that I'm writing in Rust. And [02:14] you can see the builds here are between [02:16] two and 3 minutes. Occasionally, if [02:18] we're lucky, one will be like a little [02:19] under 2 minutes, but they're two to [02:21] three, sometimes six plus. And now you [02:23] can see 47 seconds, 46 seconds, 48 [02:26] seconds. Those long builds are [02:28] publishes, so they're a bit different. [02:29] This looks way cooler from their [02:31] dashboard, which is, by the way, [02:33] significantly nicer for tracking your [02:35] actions than anything that I've seen [02:37] inside of the official GitHub action [02:38] stuff. Not only can I trivially check my [02:40] workflows and jobs and see what's going [02:42] on with a really nice UI, they have [02:44] search that works. Oh, it's so good. You [02:48] can even see success and failure rates [02:49] across different actions at different [02:50] steps to make it way easier to debug [02:52] what's going wrong. Here, we can even [02:53] see how the length of our jobs is [02:55] distributed. So, across T3 chat, the [02:57] vast majority of our jobs are under 30 [03:00] seconds now, and the worst ones are up [03:01] to 11 minutes. And we can look and see [03:03] why. What steps took how long. This is [03:06] so good. It's so good. We have fixed so [03:07] many things about our CI. Our developers [03:09] are significantly happier. I'm over the [03:11] moon with this. It's one of those things [03:12] where once you've tried it, you can't go [03:14] back, which is why it's crazy that let [03:16] you start for free. If you're not using [03:18] Blacksmith, you're wasting time and [03:19] money. Fix both now at soy. [03:22] So, what even is Codeex? Well, it's a [03:25] CLI. It's a series of models for coding. [03:28] It's a web app that is used for making [03:30] PRs to repos. And now, it is an [03:32] application you can install on your Mac [03:34] for managing all of the work being done. [03:36] To be very very clear, this is still [03:38] using the same agent base that the CLI [03:40] uses. In fact, it shares history between [03:42] the CLI runs and the app runs. So, if I [03:45] go do something in the CLI in one of [03:46] these directories, it'll carry over to [03:48] the app as well. And so does your [03:50] config, which is really nice. It does [03:53] just feel like a UI for the CLI, but [03:55] with a lot of nicities handled as well [03:58] that make it way better for day-to-day [04:00] use, especially if you're one of those [04:02] people that spins up a lot of different [04:03] projects or branches and works on [04:05] multiple different things at the same [04:06] time. I've never parallelized my work [04:08] quite as much as I am today with the [04:09] Codeex app. I want to make something [04:11] very clear though. They are not the [04:12] first ones to do this. I've seen a [04:14] handful of these CLI wrappers pop up [04:16] that make it easier to manage what [04:18] projects you're working in in the [04:20] threads going on within them. apps like [04:22] Conductor, which is built largely around [04:23] cloud code, but does also work with [04:25] codecs to make it easy to take a given [04:27] git repo and work on multiple things in [04:29] it at the same time. Conductor is really [04:31] cool, but has had terrible performance [04:32] issues for me, so it's not a thing I've [04:34] used that much. Funny enough, there's [04:35] also codeex monitor, which was made by a [04:36] user of Codex that wanted to do [04:38] something like this, and he was also [04:40] brought in as an early tester. And for [04:42] one last throwback, anti-gravity. Not [04:45] that anti-gravity does this directly, it [04:48] doesn't. But what it did do, and I even [04:49] call this out on my video, was the agent [04:51] manager, which let you keep track of [04:53] work going on across different projects [04:55] at the same time. When I first played [04:57] with anti-gravity, this was like the one [04:59] thing in it that I thought was actually [05:01] quite cool. And a lot of people said I [05:03] was wrong there. In particular, Ben, my [05:05] channel manager, called me out hard for [05:07] this. And now he's admitting he's wrong, [05:09] too. So, this orchestration layer of a [05:12] UI for managing your work threads does [05:15] seem pretty damn good. And I've yet to [05:17] meet anybody who's used it heavily that [05:18] hasn't committed. Even my own team with [05:20] Ben and Julius have been making the move [05:22] to this workflow in this UI. And I I [05:24] should just show you guys why. On this [05:26] laptop, I only have a handful of my [05:27] projects. But even then, you see I did a [05:29] lot of legitimate work here. Let's start [05:31] with lawn, which is one of the like 10 [05:33] new apps that I've been working on. This [05:35] is Lawn. It's meant to be a cheap, [05:36] simple alternative to Frame.io. I'm [05:39] pretty close to finish with this one. I [05:40] might actually release it in the next [05:41] week or two. We need it for my team and [05:43] I'm excited to get it out for others if [05:45] they end up wanting it as well because [05:46] frame.io is a bit rough nowadays. It's [05:49] an easy way to upload videos and do [05:51] video review with your team which is [05:52] essential for us as we do a lot of [05:54] videos. And as you can guess, I built [05:56] this whole app inside of codeex. I did [05:59] hop to cloud code here and there mostly [06:00] for UI work like the homepage. I did a [06:02] bunch of different additions on it [06:03] there. But all of the wiring pieces [06:05] together, all of the actual scaffolding [06:08] of the app and building it and creating [06:09] the functionality, all of it was done [06:11] across many threads inside of this app. [06:14] To be clear, not on this computer, on my [06:15] other laptop. I might plug it in in a [06:17] sec, but just want to show the type of [06:19] thing I'm building here. Right now, when [06:21] I click a timestamp, it doesn't move to [06:23] that point. I'll ask it to fix that. [06:25] When a user clicks a timestamp in a [06:27] comment, the video player should [06:28] automatically skim to that point in the [06:30] video. Hit send and now it's going. And [06:32] as we all know with the GPT5 models, [06:35] this will take a bit. On one hand, it's [06:37] because they're actually slow. Like [06:38] their TPS is not super high. On the [06:40] other hand, it's because they're very [06:41] thorough. This model loves to just scan [06:44] the codebase and find every single thing [06:46] that might be related to what you're [06:47] trying to do and figure out a cohesive [06:50] and coherent plan to do all of that. But [06:52] here's where things get really cool. We [06:54] know it's going to take a while. So, [06:55] let's go do something else. Maybe I'll [06:58] go back to my blog and work on some [07:00] things here. I'm currently in the [07:01] process of rethinking how I manage blog [07:03] posts because I've been trying to write [07:04] more. This one ended up making changes I [07:06] didn't expect it to. I had asked it to [07:08] explore, but it didn't. It just wrote [07:10] code. But if I want to see what it [07:12] wrote, I just click the open button with [07:14] VS Code, which by the way, they have [07:16] call outs for basically every editor you [07:18] would possibly want to use. If it's [07:19] installed on your computer, it'll [07:20] probably appear here. So, I just open [07:22] that in VS Code. Now, we can see all the [07:24] blog posts I had open are dead because [07:26] it changed the structure of how my blog [07:27] is organized. I now have active and [07:30] archived folders for all of my blog [07:31] posts. This is significantly easier to [07:34] manage. I'm actually quite hyped for [07:36] this. This is a good change. So, let's [07:37] say I want to commit this. There's a [07:39] little button up here, commit. You also [07:41] have a code diff panel button that you [07:43] can look in here and see what actually [07:45] changed. It's fine. Not going to [07:47] complain too much about it, but [07:49] honestly, I don't find myself in there a [07:51] whole lot because I much prefer just [07:53] opening in my editor or somewhere else. [07:55] They also have a terminal on the bottom [07:56] if you want to have a terminal directly [07:58] here. Some people really like that. I [07:59] personally don't, but there are some use [08:00] cases where it's great that I'll show [08:02] you in a sec. But I want to commit this. [08:04] So I'm going to just click commit. And [08:06] here's a feature I bullied them into [08:08] adding. Leave blank to autogenerate a [08:10] commit message. Nice. So I can commit [08:13] commit and push or commit and create PR. [08:16] I think commit and create PR sounds like [08:18] a good idea. So we will do that. And as [08:20] we are here, I just noticed the other [08:22] work we were doing completed. And this [08:23] is part of the magic is I'm just hopping [08:25] between different threads, seeing where [08:26] tasks are. I feel more like a manager [08:28] than ever, but I also feel way more [08:30] productive than ever. Now I have the PR [08:32] for all these changes at the same time. [08:34] I have lawns update here with the video [08:36] player changes. Pop back in. See if [08:39] clicking a time stamp works. Look at [08:41] that by OpenAI. [08:43] >> And now in literally 5 minutes, I got [08:45] two major changes on two real projects [08:48] done. But what happens if you want to [08:49] work on two things at the same time in [08:50] the same project? This is where work [08:53] trees come in and they I'll just say [08:55] they have an interesting way of doing [08:57] work trees. I don't think anyone's [08:58] gotten this right because there's so [09:00] many layers to work trees. If you're not [09:02] familiar, work trees are a concept [09:04] within Git to take a git repo, make a [09:07] new branch, and put it somewhere else on [09:09] your computer. So, you can be working on [09:10] two things at the same time. This is a [09:12] feature that just didn't matter too much [09:14] for a long time because like who's [09:16] working on two things at once? Hi, I am [09:18] I'm working on like 10 things at once [09:20] now and it sucks. So, work trees are the [09:22] promised solution that fixes all of [09:24] this. And now that I've gone really deep [09:26] on them, I'm telling you, we've been [09:27] lied to. Work trees are not a good way [09:29] to do anything other than make it harder [09:31] to figure out where your code is. I have [09:33] been very upset with them on a [09:34] fundamental level. They just feel like [09:36] the wrong primitive. Like, you can't [09:38] have the same branch or commit checked [09:40] out in two places at the same time. So, [09:42] you always have to make a branch, but [09:43] then keeping them in sync sucks. So, the [09:45] way that they're doing this in codeex is [09:47] a bit different. Initially when you [09:49] create a work tree it makes a copy of [09:50] the project and puts it in another [09:52] directory somewhere else. It's not a [09:54] traditional get work tree though it is [09:55] an actual copy and then you can sync the [09:58] changes back in after. So let's try this [10:01] with lawn really quick. We have the [10:03] actual redesign branch that we're on. I [10:04] click work tree. It switches us to from [10:06] main which is not what I want cuz that's [10:08] not the branch I'm on. I hate that. One [10:10] of the many things I've complained [10:10] about. Hopefully it'll get fixed. Switch [10:12] that to actual redesign. That's where we [10:14] want to start from. When a user uploads [10:16] a new video, a thumbnail needs to be [10:18] created for that video. I think the [10:20] easiest way to do this is going to be to [10:22] do it on client side when they upload. [10:25] We should grab a still, either the first [10:26] still or something from early in the [10:28] video and upload that alongside the [10:30] video so that we can use it as the [10:32] thumbnail. And now this is being worked [10:33] on in a work tree. And I have the option [10:36] to sync this with my local or somehow [10:38] create a PR with it. I've yet to figure [10:40] out how to actually do that part. I [10:42] honestly have found the work tree [10:44] implementation to somehow be one of the [10:46] most thought out work tree [10:48] implementations I've seen, but also one [10:49] of the least useful. I have not been [10:52] enjoying work trees a whole lot inside [10:54] of codeex. And I do hope in the future [10:56] they find a way to make them feel a bit [10:58] better because having to sync to local [11:00] then push just doesn't feel great. I'm [11:02] on a branch of a branch right now. I [11:04] should be able to make a PR that merges [11:06] it in or have some other way to put this [11:07] work up that isn't pulling it back in [11:10] first. As such, there's a different [11:12] workflow that I've been finding [11:13] surprisingly useful. There's one more [11:15] button to the right, cloud. Turns out [11:18] cloud environments are a lot less [11:19] painful when you just have them in the [11:22] same exact UI. So, I'll paste the same [11:23] prompt. I have to pick a cloud [11:25] environment because it needs to know how [11:27] to use it in the cloud. It's one of the [11:29] most annoying things. It can't just use [11:30] a random folder on your computer. [11:32] Everything inside of codeex has to be a [11:34] git repo. And if you're using the cloud, [11:36] it has to be on GitHub and already [11:37] synced with them. And as such, we must [11:41] do this. So now lawn is a new [11:43] environment that I can create. I'm not [11:46] going to bother with all of those [11:47] things. I don't need it to actually have [11:48] internet access or do things should [11:50] actually give it internet access now I [11:51] think about it. So we can do search and [11:52] whatnot. But uh yeah, and as always, [11:55] we're switching that back on. So the [11:56] agent has unrestricted access. But the [11:58] fact I have to go configure all these [11:59] things and manage environment variables, [12:01] figure out what container we're in and [12:02] all that, this is a very unsolved space [12:05] in my opinion. I do dream of a future [12:07] where the cloud stuff's a little less [12:08] annoying to config. But now that I've [12:10] made these changes, lawn is available. [12:12] We're starting from main. Shouldn't [12:14] start from main. We start from the [12:15] redesign. And then I hit go. And now we [12:18] have two separate tasks going on my [12:21] computer in the same project. Neither of [12:23] which are touching code in the actual [12:25] folder the project lives. This one is [12:27] going to happen in the cloud and it will [12:28] eventually propose a pull request. This [12:30] one is happening on my machine but in a [12:32] work tree so that I can pull it back [12:34] into the main branch later. And again, [12:36] when we have all of this going, I can go [12:38] hop into other projects like the native [12:40] clone of the T3 chat app that I've been [12:41] working on that's gone surprisingly far. [12:44] Or the file system that I built. Yes. [12:47] Okay. Not a real file system. It's an [12:48] alternative way of syncing files between [12:50] machines that I also have built almost [12:52] entirely within codecs. Or T3 chat [12:54] itself, which wait, a month ago? Have I [12:57] had this app for a month? Nope. The way [12:59] that works is it's syncing with the [13:01] project because it knows where it is on [13:03] my computer that I've used Codex for it. [13:04] So it has the history of different [13:06] things I've done in Codex on my machine [13:08] as well as the things I've done in Codex [13:09] Cloud on my machine. And here we can see [13:11] some of the like heavier things I asked [13:13] it to do like improving the performance [13:14] for long threads, overhauling [13:16] compaction, some of the bolder things I [13:18] was just curious if it could do. And [13:20] it's all here. And at the same time, we [13:22] have our main threads going up there. [13:23] It's just it's so easy to hop around [13:25] that I've become more frustrated about [13:27] the other things I have to hop around [13:28] in. Like between my browser, my code [13:30] editor, and other surfaces, it's [13:32] annoying, especially when you also have [13:34] to like spin up a dev environment or [13:35] manage environment variables. I still [13:37] haven't figured out how to make it so [13:39] when I create a work tree that the env [13:41] is carried over. There's a surprising [13:43] amount of config available. They've been [13:45] pretty open to whatever suggestions we [13:47] have about things we want to do or do [13:49] different. And here we can see that a [13:51] lot of the config is just put under the [13:53] config toml. But there's a lot of other [13:55] little things we can do. We can give [13:56] some custom instructions. We can change [13:58] how detailed the info we get out in the [14:00] thread is. And by default, they don't [14:02] actually show the code output. They only [14:04] show steps with code commands because [14:05] again it's a very different way of [14:07] building. This no longer is we're [14:09] commanding our code editor via AI. This [14:12] is now we are orchestrating agents that [14:15] control our code for us with a better [14:17] UI. and it's fully caused me to lose [14:20] interest in terminal based UIs for real [14:22] code work. But I was saying before, I [14:23] don't really know how to set up [14:25] environment stuff properly. The [14:26] environment has a name. It has a setup [14:28] script and also platform overrides, [14:31] which is interesting because right now [14:32] it's a Mac only app. Obviously, that'll [14:34] change in the future. Right now, it's [14:36] just a Mac. So, nothing in here seems to [14:39] show me how do I get over my environment [14:41] variables. This will run in the project [14:44] route, but how do I know what path [14:46] things are going to? There is no clear [14:48] method anywhere here on how to manage [14:50] environment variables, which kind of [14:51] makes the whole thing feel useless [14:53] beyond just writing code somewhere else [14:55] for you in parallel. I do genuinely hope [14:57] they find ways to clarify these things [14:59] and make it easier in the future. At the [15:00] very least, they should just copy the [15:02] existing cursor configs that describe [15:04] how to do a lot of the stuff in work [15:05] trees. Yeah, we'll get there when we get [15:07] there, I'm sure. There's also MCP [15:09] servers cuz of course there is. They [15:11] also have a pretty cool skills browser. [15:13] You can see all of the ones I have, [15:14] which yeah, I have quite a few now. I [15:16] know I've become a skills guy. It is [15:18] what it is. They also have a bunch of [15:19] recommended ones like deploying on [15:21] Cloudflare, managing Atlas so that it [15:23] can see what's going on in the browser, [15:25] controlling linear issues through the [15:26] app. So if you tell it about an issue [15:28] and then it addresses the issue, it can [15:29] update the status accordingly. Pretty [15:31] cool. Built-in image gen, which is [15:33] really cool. One of the demos they did [15:34] is making a full game with one prompt [15:36] where the agent could generate images [15:38] for the things that it needed and also [15:40] use Atlas to see it as it went. And my [15:42] personal favorite, yeet, which will [15:44] stage, commit, and open a PR. When you [15:46] think it's ready to go, you just tell it [15:48] to yeet, and it will use its skill and [15:50] figure that out. Silly, but useful. I [15:51] haven't set it up just yet myself. I [15:53] just have my usual skills, but I can see [15:55] myself using that one. Actually, good, [15:56] useful, tasteful things. And as you can [15:58] guess, the team building this has been [16:00] using it to build it. So, they have been [16:02] deep in here making tons of changes. The [16:05] speed at which things have been getting [16:06] fixed when I report them is absurd. This [16:08] isn't some random side project they're [16:10] going to half-heartedly invest in. It [16:12] does really feel like a thing they want, [16:14] they use, and they really want to see [16:16] succeed. I've been surprised at how much [16:18] effort they're putting in. Not like how [16:20] hard they're pushing it on me. They're [16:21] really not that much. I seem to be the [16:23] person in the test group that's gotten [16:24] the most excited about this, but we've [16:26] all been using it a ton and it's been [16:27] really good. But now the question is [16:29] left of what do I use every day? I [16:32] mentioned before that I've still been [16:33] using cloud code for a bunch of random [16:35] things, but what are those things? Most [16:38] of my cloud code use has been general [16:40] computer things, things that don't need [16:41] to be so deeply tied to a git repo. So I [16:44] was trying to set up a way to easily [16:45] create scripts that I could execute from [16:47] a directory that would just become [16:48] globals. I did that. I do a lot of [16:50] changes to like my zshell config via [16:52] cloud code. I find files. I write [16:54] scripts to do one-off tasks. I scrape [16:56] websites. I get information. I use cloud [16:58] code similar to like how I use a [17:00] computer. But codeex is how I actually [17:02] build. The way I think about it at this [17:04] point is if I have any intention to [17:06] commit and push this, I'm probably doing [17:08] it inside of codecs. If I'm just [17:10] changing things on my computer, [17:12] around, writing one-off scripts, or the [17:14] one real use case, doing passes on UI [17:17] and sometimes even full-on UI overhauls, [17:20] then I use Cloud Code. Everything else I [17:22] have been doing since I got access to [17:24] this app, I have done inside of Codeex. [17:26] It really feels like it fixes the [17:28] biggest issue I had with codecs, which [17:30] is that the model was slow and using it [17:32] was unpleasant as a result and I would [17:34] just lose track of which terminal tab [17:36] had which run going. Because the codeex [17:38] models have a generally higher hit rate [17:40] and success rate for these big heavy [17:41] tasks, I found myself paralyzing with [17:44] them already. I was at the point where I [17:46] would run something that I knew would [17:47] take a while in codeex and then go spin [17:49] up a work tree manually and play with it [17:51] in cloud code to see how it would feel [17:53] to use while waiting for the codeex run [17:55] to complete. And now there's a UI tailor [17:58] made for this use case. And it's so [18:00] good. It's so good. It's so nice having [18:02] a UI that you can just do things in. And [18:05] like crazy, I know being able to paste a [18:09] screenshot and see it in the UI. It's [18:12] been a while since I could do that [18:14] because I've been spending too much time [18:15] in these terminals and now I'm spending [18:17] almost none. It's crazy how fast things [18:19] change. I went from using VS Code for [18:21] eight years to cursor for a year and a [18:24] half to cla code for 2 months to this. [18:26] And I bet it's going to keep changing. [18:28] Sorry for the scenery change. I forgot [18:30] to talk about automations. They're [18:31] really cool and I needed to clean some [18:33] things up before I could show you [18:34] because the screen disappears if you [18:36] have any of them set up, which is really [18:38] annoying. Automations are kind of like [18:40] cron jobs with prompts that have access [18:42] to files, folders, and all the things [18:44] agents can do on your computer. I [18:45] haven't played with them too too much [18:47] yet, but the little bit I have was cool [18:48] enough that I wanted to add this in [18:49] quick. The examples are all pretty basic [18:51] things, but you can see how they would [18:53] be useful. Something like writing a [18:54] change log automatically, summarizing CI [18:57] failures, scanning recent commits, and [18:58] looking for bugs. Let's just go with [19:01] this one. I'm going to change it to last [19:04] 48 hours. Here, we'll pick a project. [19:08] Let's say T3 chat. Make sure you pull [19:12] the latest. So you are checking recent [19:16] changes. [19:18] 72 hours. This is the weekend and I [19:20] don't think we've shipped too much over [19:21] the week. You can choose when it runs. [19:22] So this would be 9:00 a.m. every day of [19:24] the week. It would run this and look for [19:26] things that might be bugs. You can also [19:28] add multiple different projects at once, [19:29] which is super super cool. So I'll do [19:32] these two projects. Set that up. Test [19:35] just so we can see what it looks like. I [19:36] definitely have my potential concerns, [19:39] but uh Oh, look. It does actually spawn [19:41] as a thread here. That's cool. So, if [19:42] you go to the different projects, you'll [19:44] see a thread that it made with a work [19:46] tree to do the thing that you requested. [19:49] That's really cool. It's like an [19:50] automatic thread creation. We even set [19:52] this up to automatically add new models [19:54] when they're added on open router. Like [19:55] I Oh, boy. Again, this when I play with [19:58] this app, I think of things. It's a [20:00] different way of building that lets you [20:02] like use your brain in a different way. [20:04] Obviously like a terminal is kind of the [20:06] same and you could have set this up [20:07] yourself by setting up a cron in your [20:09] terminal with cloud code with a specific [20:11] path but just having it in front of you [20:13] like this feels different and I wanted [20:14] to capture that. And look here we are no [20:17] actionable bugs but there is some things [20:19] that it scanned. Yeah, this is really [20:21] cool. By the way, switched to my other [20:23] laptop so you can see a lot more of what [20:25] I've been building to the point where we [20:27] got to a show more there. But I want to [20:29] show you guys a project I was having a [20:30] lot of fun with vibe faster. I was so [20:32] pumped with the workflow I had in this [20:34] app that the performance issues it had [20:36] at the time got really really [20:38] frustrating. There was a brief moment, [20:39] like one build where it was eating [20:41] memory and my battery and it really [20:43] really frustrated me. But I had gotten [20:45] so hooked on this workflow that I [20:47] wouldn't take no for an answer. So I [20:49] plugged in a charger and started [20:50] building a native alternative. Yes, [20:53] really. I built a full desktop app from [20:55] scratch with Swift and AppKit, not Swift [20:58] UI cuz Swift UI performs like And [21:01] this is my attempt to rebuild the things [21:03] I loved so much about Codeex app in a [21:06] native build. But like that's how much I [21:09] loved this. I loved it so much that I [21:11] went and tried to build my own native [21:12] alternative so that I could have better [21:15] battery life and I could not feel as bad [21:17] watching my battery drain hoping that my [21:18] task completed before it went down. And [21:20] then they fixed all those problems. And [21:21] now I'm happy as can be. I made this [21:23] post a few days ago obviously inspired [21:25] by the thing I was testing. All these [21:27] agent coding TUIs are a phase and it [21:30] will be shortlived. Most devs will be [21:31] back in GUIs and IDEIDes in a few [21:34] months. Notice that I said GUIs and IDE. [21:37] That was intentional because while [21:38] Codeex isn't an IDE, it has absolutely [21:41] killed my interest in opening them. I [21:43] just don't care anymore. I didn't think [21:46] this would happen as fast as it has, but [21:49] I don't want to be in there editing [21:50] code. I don't want to be in there [21:52] looking over every line. I want to make [21:54] sure I understand what the agent's doing [21:55] and why. and build something awesome [21:57] with it. And this has been an incredible [22:00] tool for doing exactly that. So much so [22:03] that I don't even regret the $4,000 [22:05] gigantic monstrosity of a laptop [22:07] currently sitting in front of me that I [22:09] bought exclusively to be able to do this [22:11] work with separately from my computer [22:13] that I use on stream. [22:16] If you can't tell, it's been a rough two [22:18] weeks of me not being able to talk about [22:19] this. And I'm so pumped I can finally [22:22] share it with y'all. I know I get hyped [22:24] about a lot of different things on this [22:25] channel. It's kind of my thing. I love [22:26] trying new things, but none of them have [22:28] changed my day-to-day work quite this [22:30] much in a long time. And I'm so hyped [22:33] that you guys get to go play with it [22:34] yourselves, too. That's all I have on [22:36] this one. I'm going to go back to [22:37] building because I am fully addicted [22:40] again, like the way I was as a kid. It's [22:42] been so genuinely fun, and I can't wait [22:45] to go back and keep doing it. Until next [22:47] time, peace nerds.