Skip to content

Podcast

310 - Mitchell Hashimoto on Ghostty & His Agentic Coding Workflow

Fragmented - AI Developer Podcast

Source ↗ ← All highlights
  • Native Cross-Platform Terminal Built On A Shared Core
    • Ghostty aims to be a native, fast terminal across macOS and Linux rather than a cross-platform compromise.
    • Mitchell built platform-specific UIs backed by a shared libghostty core so each client feels native while sharing terminal emulation logic. Transcript: Mitchell Hashimoto Yeah, okay. So I think it’s important to frame the fact that I started Ghosty for myself and not to solve what I was looking for and not thinking from the angle of what’s going to get the most downloads. And so from that angle for myself, what I really wanted was I wanted something that worked on Mac and Linux because I worked like 50-50, 60-40 on Mac and Linux. I split time. I wanted something that felt native on both of those. It’s like I wanted something that felt like a beautiful polished Mac OS app and the Apple ecosystem on Mac. And I wanted something that felt like it was built for my desktop environment on Linux. And then I wanted it to be fast. I think that existing terminals are a pick two of those things. So for example, I think kitty is an excellent, excellent terminal. Like whenever someone says they’re using kitty, I’m not sad about that at all. I’m like, cool, that stuff’s really good. But, you know, it’s not native at all, right? Like if you create a tab, it’s some weird ASCII pixelated thing. And native goes far beyond that. Go see on Apple. Mac has AppleScript integration, Apple Shortcuts integration. I want to do some form of iCloud syncing. To me, the definition of native is you should be taking full advantage of whatever platform primitives you’re running on. So that’s sort of the thinking is Kitty is fast and it’s cross-platform, but it’s not native. Terminal is just one of those things. It’s nothing, you know, so on and so forth. So that was my motivating factor. And for people today that are adopting it, I love getting feedback. I get a lot of people that will say, oh, you built a Mac app first or you built a Linux app first. I mean, the fact that people can’t tell means that we’re doing the native thing really well. (Time 0:02:10)
  • Terminals Are Ideal Platforms For Agentic AI
    • Terminals are a platform for other apps and are especially well suited for AI because CLIs give clean data-in/data-out interfaces.
    • Mitchell sees a renaissance driven by agentic AI that composes well with text-based CLIs and tooling. Transcript: Mitchell Hashimoto Yeah, I mean, a terminal is a platform for other applications. Like, I know that a lot of people say that aspirationally, and I say that very literally. Like, it is a place where other applications run. They just happen to be text-based applications versus a browser, which is more, you know, graphical-based. And so you need to be able to provide these platform features that people expect, which is a certain amount of text rendering, a certain amount of window management, a certain amount Of input, keyboard, mouse, etc. And I think that I like to break it down as there are terminal emulators and there are terminals. Because if you’re someone who really focuses in on the fact that a terminal emulator is emulating a piece of hardware from the 80s or 90s or 70s, depending which version of hardware. But if you view it as an emulator of that hardware, then you don’t believe in that innovation. You’re just trying to run applications on that existing technology. It wouldn’t make any sense if someone was creating a Nintendo Game Boy emulator and then added three graphics that didn’t exist to it then. People would argue that’s not an emulator anymore. And so I actually say that GoSee is a terminal emulator because we do emulate those things. But it is really more of a terminal because we’re just moving forward with the definition where we’re not, we’re no longer emulating. We still do, but for all the future-facing features, we’re not emulating anything. We’re innovating and really others are innovating and we’re adopting their features too is what we’re right now, is how it’s working. I think that’s really important because I do think a lot of applications work really well in a text-based fashion and I think AI is a great example of that. AI does not care about how things look. It just wants data in, data out. And CLIs are really good at that. They’re easy to run. They’re easy to compose with each other. It’s a really good platform for AI. And I would say agentic AI in particular to interface with. (Time 0:05:10)
  • Learn Terminal Layers Before Diagnosing Bugs
    • Understand terminal layers: emulator launches a shell which uses a PTY byte stream and runs programs; only one process owns the visible screen at a time.
    • This explains why tools like Cloud Code or multiplexer behavior can block features or redraws. Transcript: Mitchell Hashimoto So simply at the beginning, you have a terminal emulator, you have a shell, and then you have whatever program you’re running. So let’s use CloudCode as an example. And so when you run a terminal, I think people think terminals execute commands. But for the most part, terminals ever only execute one command, and that is your shell. So a terminal starts up, we launch the shell, and that’s what’s running for a long time. And the terminal is just drawing. It’s like a graphical interface to the shell, basically. The shell then is the thing that’s actually executing everything underneath. And the way everything communicates, like you might imagine that the way browsers communicate is you have JavaScript that talks to the DOM. The way another tool might communicate is you have a program that’s using a REST API. The API layer for a terminal is called the PTY, and it’s just a byte stream. And if you output text to the byte stream, we draw text to the terminal, but you could also output special invisible characters, control characters, in order to do things like move the Cursor and so on. So what ends up happening, the terminal starts, we create this PTY, we launch the shell, we hand it the PTY. So now we have sort of like the mailbox, they’re sending mail, we’re receiving mail, like that’s basically how that is. And then what the shell does is when you execute Cloud Code, it also hands Cloud Code the same PTY. It basically like yields control for a while. So the shell no longer has the ability to write to it. It says, I’m leasing you basically as PTY. You take over the screen. When Cloud Code exits, I get the PTY back. And so there can only ever be one person running the screen at a time. (Time 0:11:54)
  • Tmux Often Breaks New Terminal Features
    • Terminal multiplexers like tmux act as full terminals that render escape sequences, creating a least-common-denominator that blocks newer features.
    • Many Ghostty features fail under tmux because the multiplexer strips or doesn’t forward novel capabilities. Transcript: Mitchell Hashimoto Now you can introduce one more layer, which is a multiplexer, like Tmux in there. And so the way this works is you have a terminal emulator, which launches your shell. You have your shell, which then launches your multiplexer. And it’s long living. So that’s all your shell’s done at this point. And now you have the multiplexer, which itself is doing… A is a terminal. It’s creating more PTYs and handing them off to more shells in the same way that if you made more windows with Ghosty, we would be creating multiple PTYs. And the important thing here that people don’t understand is a terminal multiplexer on its own is a full-blown terminal. It has to parse and draw and handle all the same things that terminal is, but instead of rendering pixels with a GPU that Ghost is doing, it’s rendering more terminal escape sequences To get another thing to render the pixels. So the closest analogy there is it’s kind of like virtualization. Like you’re running another OS top of an OS. And so that’s why things get slower. That’s why you get less features because if you do like squiggly underlines and the multiplexer doesn’t understand squiggly underlines, then it’s going to ignore it and it’s not going To send it to the parent. And so like you end up in this least common denominator scenario. So there’s a lot of features we ship with GhostC that people will say, oh, but it’s not working. And one of my first questions (Time 0:13:33)
  • Prefer Feature Detection Over Term Variable Sniffing
    • Terminals should use feature detection (XTGETTCAP) rather than user-agent sniffing; encourage shells to adopt XTGETTCAP to fix many SSH/compatibility problems.
    • NeoVim already uses XTGETTCAP successfully across SSH, showing the practical path forward. Transcript: Mitchell Hashimoto Yeah, we’re in the world, this is just a broken system that I want to fix, but we’re in this world where basically everybody is determining terminal capabilities by user agent sniffing. That’s all that is. I don’t know, you depending on the listeners and how old they are and what they were a part of, but I remember when user agent sniffing got attacked a lot because it wasn’t good, it wasn’t Accurate. That’s why everyone, Chrome also sends Firefox and their user agent still and things like that. That’s why it goes to the X term in its term. But there’s luckily, the browser shipped a solution to this, which was feature detection via JavaScript rather than user agent. Terminals already have a solution for this as well. And Xterm actually invented it. And there’s a protocol called xt-get all capital letters. But basically, it’s a way for the program running to ask the terminal, hey, do you support a specific feature? And the terminal responds yes or no, or you don’t get a response, which says that it doesn’t even understand XD, you get TCAP, which you can make assumptions from at that point. Pretty much every mainstream terminal supports this to this point. I don’t know if like macOS built-in terminal does, but every other third-party terminal does, Xterm does. This is what they should be doing. They should not be reading the term. And the biggest violator of this are shells. It’s like NeoVim has used XC get TCAP for years. You could use NeoVim across SSH, even if your shell is totally broken and goes, so you launch NeoVim and everything magically fixes itself because NeoVim realizes it’s in a very capable Terminal through this mechanism. And shells don’t. And, you know, it’s like Bash and ZShell and all these things are just so archaic in terms of like they move so slow. They seem, I don’t know who is maintaining them, but they just seem very pleased with where they are and not innovating very hard. Like all the best Bash and ZShell environments have tons of plugins. You know, I’ve always had the mentality where if, you know, a majority of your user base is using a plugin, that plugin should be a first party feature. I imagine they disagree like philosophically, but we need the shells to at least use XT, get TCAP. (Time 0:17:17)
  • Make Terminal Emulation A Reusable Library
    • Extract terminal emulation into a reusable library (libghostty) so editors, cloud consoles, and other apps can embed a high-quality terminal.
    • Mitchell made Ghostty nonprofit to encourage broad adoption without commercialization concerns. Transcript: Mitchell Hashimoto It’s basically the core business logic that is cross-platform. And so there’s an API there that handles basically 100% of the terminal emulations amongst some other concerns as well. So we have like a cross-platform core that for keyboard encoding, for example, not quite terminal emulation, but basically if you take whatever Swift or AppKit on macOS or GTK on Linux Or, you know, a Windows input system, if you take that and form it into the right structure, then we will handle all the shared logic of how you convert that to what a terminal expects. And so that’s all LibGhosty. Iury Souza Was it, what was the goal from LibGhosty from the start? Did you have that vision from the get-go? Mitchell Hashimoto Pretty shortly. So, you know, Ghosty started as a, as just, I didn’t think it would ever be a real project. It started as an educational project for me. So I started building this terminal. And then once I got to a point where I realized that Ghosty could be useful to other people, it was right around the same time that I realized sort of how much work it is to build a terminal Emulator and what a waste that is because they pretty much all should do the same thing. And a platform behaves best when you get the same behaviors everywhere, right? I think one of the issues right now is there’s so much fragmentation in terminals. You want a certain amount of alternate implementations, but I think we’re at the point with terminals where there’s probably like over 100. And so part of that vision quickly turned, I would say three months into the GoStu project, quickly turned into the real mission of the project is to build a reusable embeddable library So that people could focus on the higher level unique features and value adds and differences they want to build while having a super fast, super stable cross-platform terminal emulation At the core. When I say this, some people think, and the way I just described it makes it sound like I want programs like Kitty or Alacrity or Terminal Appapp to replatform on LibGoSee. Some of that would be nice, but I don’t think that’s practically what I see happening. What I really see is there’s a much bigger world beyond first-party terminals of other programs that their primary function is not being a terminal that has a terminal embedded or has Terminal-like behaviors embedded. So the two biggest examples I give are editors and cloud systems. So editors, for example, VS Code, JetBrains stuff, they all have a terminal built in. VS Code uses extra JS, and JetBrains uses their own JEDI terminal. They’re good efforts, but they all have shortcomings. And so I think that’s a good example of where it would make much more sense to use something like libghosting. And then the cloud systems is more of a read-only terminal. But if you go to previously Heroku, Docker, AWS, Vercel, all these things, like when it’s doing build blocks, the stuff that’s coming out of the build block is actually terminal sequences. And they’re doing their own custom thing usually, hopefully using Xterm.js at the very least. But they’re doing their own thing to show a read-only version of terminal. But also a lot of those provide, if you have a running app, like a web-based SSH, give me a console into this application. And that’s a full-blown terminal at that point, read-write. And those usually have a ridiculous amount of bugs because it’s a really, really like, it’s not even like, it’s not their first priority, it’s not their second priority, it’s like their Eighth, ninth priority of the platform. And so they’re just riddled with good enough and good enough is never good enough. And so that’s the world where I think LibGhosty could really revolutionize and just make it so that building block of having a totally free, unencumbered, high quality, foundational Piece that you can adopt is there for you. And that’s part of the reason also I put Ghosty into a nonprofit organization is I wanted to make sure that everyone felt comfortable adopting this thing, knowing that there’s no commercialization Strategy here. (Time 0:22:13)
  • Ghostty Started As An Educational Project
    • Ghostty began as an educational side project for Mitchell and quickly shifted to a mission to reduce duplication across terminal implementations.
    • Within months he realized building a shared core would prevent repeated reimplementation across many terminals. Transcript: Mitchell Hashimoto Pretty shortly. So, you know, Ghosty started as a, as just, I didn’t think it would ever be a real project. It started as an educational project for me. So I started building this terminal. And then once I got to a point where I realized that Ghosty could be useful to other people, it was right around the same time that I realized sort of how much work it is to build a terminal Emulator and what a waste that is because they pretty much all should do the same thing. And a platform behaves best when you get the same behaviors everywhere, right? I think one of the issues right now is there’s so much fragmentation in terminals. You want a certain amount of alternate implementations, but I think we’re at the point with terminals where there’s probably like over 100. And so part of that vision quickly turned, I would say three months into the GoStu project, quickly turned into the real mission of the project is to build a reusable embeddable library So that people could focus on the higher level unique features and value adds and differences they want to build while having a super fast, super stable cross-platform terminal emulation At the core. (Time 0:22:56)
  • Forking Is A Healthy Part Of Open Source
    • Mitchell defends forking and many personal forks as healthy open source behavior; PRs transfer maintainership, not obligation.
    • He argues open source is about freedom to modify, not about building a centralized mass-market product without funding. Transcript: Mitchell Hashimoto Yeah, yeah, yeah. I think even, I think this is one of the real, I think AI is destroying open source in a lot of ways, but I also, it’s not black and white. I think that one of the ways that AI is making open source amazing is the ability for people to more easily maintain personal forks. And even before AI, I always thought this should be the case where there should be way forks. I think that my view on the real philosophical ideals of open source is really the freedom to do what you want with your software. You could break that down to the original free software movement for fundamental freedoms, but really it’s the freedom to inspect your software, modify your software, things like That. And there’s no part of the open source movement that has a centralized maintainer team and distributing generalized software for the masses. That has nothing to do with open source. That is like, to me, and I’m a part of the problem here with what I did with HashiCorp and stuff. I think that came from funded, subsidized capital, basically creating products that are open source, right? Open source isn’t about a product. You can’t expect that same experience from open source unless it’s funded in some way. And so I actually, I feel like there’s like a whole generation, whether it’s age-based or just timing in the industry-based, there’s like a whole generation now that doesn’t understand That. And so I do get angry people sometimes where they’ll be like, I built this PR, and I’m like, yeah, I don’t want it. And they feel like I’m obligated because it’s high quality code and I’ll be like, it is high quality code and it’s an interesting feature idea. It is an interesting feature idea. It’s like, I just don’t want to maintain it in my project. But you understand that open source lets you fork it and maintain it in your own project. I tweeted this thing a while back. It got a lot of people on the positive and negative side where I sort of tongue in cheek said that the PR process is more than anything, a transfer of maintainership. That’s all it is. And so if you view it from that lens, it’s kind of like someone bringing you a puppy. And it’s like, why would you not accept this puppy? It’s like, yeah, it’s really cute. And I love puppies, but like, I don’t want to feed it. I don’t want to be responsible for this thing. So I’m going to say no. That’s how I view it. There should be way, way, way more personal force. And actually it makes software so much better because I think it’s so hard to build large scale products because one of the things you have to do is you have to balance how many features You bring in and how impactful they are for how many people and how they interact with each other and how you sort of generalize features. If somebody comes to me and wants like a really specific thing that would be really helpful to them but wouldn’t be helpful to most people, you want to say no to that. Like ideally you want to be like, this is a perfect opportunity for you to do this by yourself and it’s great. So I think it’s awesome. I think there should be way more forks. And I think, you know, the ideals of CMUX and stuff are both awesome from a fork perspective but also from the LibGhostly perspective. That’s like the real mission of Ghostly is to enable stuff like that. (Time 0:26:51)
  • Drop The Chatbot Use Agents With Tools
    • Give AI a fair, measured trial by treating it like any tool: test with agentic tools (AI with tool access) rather than pure chatbots.
    • Mitchell warns evaluating AI by asking it to build everything in-chat is like judging a hammer by hitting a table. Transcript: Mitchell Hashimoto Yeah, it’s basically what you just described. I feel like the internet was too filled with commentary that was either too negative or too positive. It was like too extreme on both sides. And I wanted to just share a more nuanced take because I do feel like I’m very much not a hype-driven person. I’m not attracted by hype. I actually have to actively, I really dislike hype. Like I have to actively, when something’s really hyped up, I know I’m entering it with a negative bias. And so AI was the same. I have to actively work personally, mentally, like to eliminate that bias and try to give it an independent fair shot. Um, and so I wanted to just write something that was more reasonable about how I found value in this thing. That was one side. The other side was I did feel like the negative, um, the people that were against it, uh, were not giving it a fair shot and they were coming at it with not, you know, they were coming at it With not good intentions to begin with. You know, there’s people that’ll be like, okay, I’ll give it a shot. And then they just like open up chatgpd.com or something and try to write out application in their browser and it outputs something. And they’re like, it didn’t compile AI’s garbage. And like, that’s a totally psychotic way to adopt any new tool. Like ignore AI. Like if someone said, this is a hammer, it hammers nails and then you like hit the table and it broke the table. You’d be like, this hammer’s a piece of trash. Like that’s a totally insane way to evaluate a tool. And so I wanted to sort of give, again, a more measured approach to how, you know, just look at it like a tool. And if you look at it like a tool, how would you approach any other tool? And how do you get value out of that? Iury Souza That’s super interesting. And I think one of the first steps you mentioned on the article, like on that sequence on the journey, was like dropping the chatbot. Can you tell us more about that? Because we also made an episode going on this AI coding ladder that you go through multiple steps, right? Mitchell Hashimoto Yeah, yeah, yeah. I mean, people figure this out in 2023, but if you give an AI tools and you give it the ability to use tools, it is so much more capable. It’s not even the same thing. It’s a different category. And so the chat interfaces their place. And every single chat interface today also is using tools in the background. That’s how important they are. You can see that in chatgpt.com. If you search for what is the weather somewhere, you’ll see it pull out a web search tool and things like that. So you can see it using tools. And so programming is the same way. And I think it’s very human in that sense. If you go and ask somebody to, don’t look at the internet, don’t look at any docs, and you just prompt them to write you a full application from scratch in an editor, they’re going to probably Have syntax errors and they’re going to have bugs and they’re going to have issues. Unless this person is like doing that every single day. But yeah, that’s how it’s going to be. And so like you got to give humans access to Google thing. You got to give them access to a shell in order to test their build. AI is the same way. And when you do that, it just performs so much better. So step one for me, for anybody evaluating AI, is use a true agentic tool. And again, people sometimes hear agentic and they’re like, oh, this is some buzzwordy bullshit. It’s a really simple definition. An agent is just an AI that has access to tools. That’s all that is. And so don’t give that more credit than anyone, than it deserves. When I say agent, I’m just being very intentional about saying it’s an AI with tool access without having to continue to say AI with tool access, AI with tool access, agent. That’s all I mean. (Time 0:30:35)
  • Gemini Screenshot To SwiftUI Compiled On First Try
    • Mitchell used Gemini multimodal to generate SwiftUI from a screenshot and it compiled nearly correctly, which was his first ‘oh shit’ AI moment.
    • That success convinced him to explore AI workflows beyond simple chat prompting. Transcript: Mitchell Hashimoto Everyone was talking about how good this new Gemini model was. And I was working on this feature on GoSteave and I was working on UI and I don’t really like working on UI. And so what I did was, I took a screenshot of the UI I want, which was not a Mac app. It was a website. I just took a screenshot. I dropped it at a Gemini. One of the new things about this Gemini model was it was multimodal, which was one of the first times. So I was like, let’s see how good it is a picture. So I dropped this picture and I asked it. This is a chat. This is not an agent. And I asked it to give me the Swift UI code to generate that same thing. And it pooped down a ton of code. I copied and pasted it. And this time it actually did just compile. There was no issues with it. And when I ran it, it was like really close, like really close. And that was my first like, oh shit moment. And that’s what caused me to sort of like get further into like there’s something there i (Time 0:35:20)
  • Train AI By Reproducing Your Own Code
    • Reproduce your own work by prompting agents to match code you’d accept as a PR to learn where AI helps and where it fails.
    • Mitchell did this for weeks to learn prompting patterns, plan/execute separation, and realistic expectations. Transcript: Mitchell Hashimoto Yeah, just prompting. And this was an extremely, I think I said this in the blog post too, this was like an extremely painful period of time. I think I only did this for like two or three weeks because it’s so time intensive and it feels like a total waste in the moment. But yeah, basically what I was doing was I would use something like hot code and I would get a really bad result. And I sort of felt like I was getting gaslit because so many other people were having good results. And I was like, I have to be doing something wrong. Like I have to be doing something wrong. And so it’s sort of like what you said. It’s I saw all these people that I respected that were claiming that they were having good results and I wasn’t having good results. And so I blamed myself and I was in fact wrong. And so the way I decided to give it a fair shot again, I try to give everything a fair shot, is I will do the work myself that I produce and I’m going to challenge myself to find the right sequence Of prompts and tools in order to produce something that is equivalent in terms of quality. Again, I’m not expecting identical code output, but I wanted it to be something that I would accept as a PR. And you don’t always get there. And that’s part of the learning process is figuring out like, oh, if I can’t get it to get there, this is like, this is one of the things a model’s not very good at right now. But then you find stuff where, like I said, one of the first things I said this in this blog, was one of the first things that popped out of that, which is everybody who uses authentic tools Has pretty much accepted as a good thing. It’s starting to be challenged now. It was a good thing for a solid year was splitting out the planning and execution steps. If you actually plan and produce a plan in one session, reset your context window and give it the plan to execute, much higher quality results. Nowadays, agent models are getting much better where in a lot of cases that actually doesn’t give us better results. But those are the types of things you learn just doing it. And yeah, it’s really hard to find this content because there’s so much content out there that is just like hype driven. And like, I just want to find the meat of how I could actually swing the hammer correctly, right? Like I don’t need people gaslighting me about how shit of a job I’m doing. Like I want concrete things. So I’m trying to give some like concrete examples of what I did to actually get better at this. (Time 0:38:07)
  • Warm Start Tomorrow With End Of Day Agents
    • Use end-of-day agents to warm-start tomorrow: kick off deep research or surveys you don’t have time for and review results later.
    • Mitchell runs hour-long research agents (e.g., WebAssembly wrappers) to return organized findings by morning. Transcript: Iury Souza It’s like some work that you get at the end of the day that you want to automate. Can you actually explain this point better and what kind of task would you recommend to have in this kind of workflow? Do you still have this workflow nowadays? Mitchell Hashimoto This is sort of addressing the fact that, especially, again, this is general to any tool but with ai one of the things that is so hyped around ai is how it’s making people the claim is that It’s making people more effective they’re doing more with less and things like that and then there’s a ton of like counter research showing that no actually even senior people are working Slower and all this stuff and i just trying to like ignore that whole thing. Like I don’t even care. Like maybe it makes you more effective. Maybe it makes you worse. If we just agree to just not give a shit about whatever the results are in that, one of the ways I felt I could get value and actually be more effective is, can it do work for me in times when I just wouldn’t be able to do work? Like in that sense, it has to be a net positive for that because like these are moments where I just wouldn’t be working at all. And so one of the challenges I gave myself was the last 30, I put a calendar alert 30 minutes before sort of my end of day, whatever that was for the given day. And you know, you’re coming out of flow anyway. I think all of us as engineers know that at the end of the day, you can’t really get into anything big anymore because you’re going to have to sign off soon anyway. So I was like, okay, let me just like exit that a little bit early. I’m already in the process anyway. And let me just like think of some things that I would love to know when I get back to work tomorrow morning and kick off a bunch of agents to look into that for me. So yeah, I kick off a bunch of research. At the time when I started, it would just be like open AI deep research type stuff. I would just kick off five of them. I would try to do more than one. Nowadays, I’m actually finding other tools. I’m trialing stuff all the time. One I’ve been using recently is a new startup called Spline. It’s getspline.ai. I like it because it does a much deeper analysis. I mean, literally, if you give it a research topic, it might take over an hour for it to produce a result. And it does use a lot of tokens and it does do some crazy stuff. But, you know, stuff like that is what I’m trying to do. I launched one yesterday, for example, where I’m trying to make LibGhosty work better with WebAssembly. It already works with WebAssembly, but I’m trying to make it more ergonomic. And one of the questions I had at the end of the day was, I want to do a survey of all JavaScript wrappers of WebAssembly blobs and understand how they’re making, specifically what I was Looking for, is how are they making C function pointers more ergonomic? And so I started this research task, which was like, build me a list of all projects that wrap WebAssembly bobs that have function pointers, explain and categorize their approach, Explain the background of why WebAssembly is this way, like what are the options for passing a pointer between the host bridge, all this stuff. And yeah, I just launched that off and it was done in about an hour. And I actually, you know, I’m off and like having dinner and stuff like this. So I didn’t read that till I was in bed like four hours later. But it’s like one of those things where it’s like, cool, like I could, it did a shitload of Googling for me that I wouldn’t do, or that would have taken me a long time. And so I call it a warm start. It gets you into the next step. It doesn’t give you the answer. (Time 0:41:52)
  • Let Agents Fix Well Scoped GitHub Issues
    • Outsource slam-dunk issues by letting agents fix well-scoped GitHub issues, then review the PR rather than doing the work yourself.
    • Mitchell often tells an agent to use the GitHub CLI on an issue URL and later reviews and merges passing tests. Transcript: Mitchell Hashimoto I mean, I think one of the things is if you’re trying to be more productive with AI, one you’ve sort of put in the reps and you’ve learned how this thing works, everyone I’ve talked to reaches A point where you do understand certain problems that work really well with AI and certain problems that don’t work well with AI. And when you start getting the sense of what works really well with AI, I just start seeing it in GitHub issues and stuff. And then you just got to ask yourself, do I want to work on this? Is this the best use of my time? I think one of the huge benefits of AI is it lets me work on what I want more than before. Before, you always reach that point where you’re like, okay, I got to do… I know one that nobody likes. Okay, I got to the point where I got to write a bunch of YAML to do GitHub actions or something, and nobody likes this, but I got to do it because CI is important. And now it’s that point where the agent could definitely do 95% of that. And so there’s some aspect of that. But for me, I come up and I look at my issues, and if there’s stuff where I’m like, the agent’s probably going to get this right, that’s the outsource of slam. It’s going to slam dunk this. So just let it do it. It’s not auto-merging. I’m still going to review it afterwards, but I kind of know what it’s going to look like in my head already. And so just let it do it. And if it looks right and the test pass and all that stuff, just send it. And it saves me a ton of time. I just did it 30 minutes before this call. I fixed it that way. Which again, I saw the issue. I knew exactly where we needed to change the code. I knew exactly what tests I had to run. It probably would have taken me 15 minutes to fix this bug. But I had another call to go on to. But I also recognized, and AI is going to get this right for sure. There’s enough reproduction steps, test steps, everything in the issue. It’s going to do fine. So one of my favorite prompts in that case is use the GH, use the GitHub command line tool and I just paste in the URL, look at this issue and fix it. If the issue itself has enough of the context, you don’t need a prompt to do that. You just need to tell it where to find it and it goes. And I did that. My call was half an hour. I came back and I merged it and it’s done. (Time 0:46:45)
  • Use Probabilistic Notifications For Agent Results
    • Default interruption is harmful; prefer per-issue or modal notifications so agents don’t fragment your focus.
    • Mitchell suggests local/cheaper models could probabilistically decide whether a result merits immediate notification. Transcript: Kaushik Gopal Know, you mentioned turn your desktop notifications off in this step. I’m not sure if you followed this. There was this tip people said like, oh, with cloud hooks, you can basically have this peon that says like, you’re done. Like, you know, hey, job complete, like move to the next thing. I’ll be honest. I was definitely on that wagon as well. But I did get to the point where like, yeah, it’s at some point, like the chaos is a lot. You bring up the point about how context changing is still a killer for us as developers, right? Do you still feel that? Or do you think we’ll have to evolve, like the discipline will have to evolve into this world where you just need to be okay with context where in the past, like, you know, as developers, We were like, hey, protect this, no meeting time, give those long slots. Where do you land on that? Do you still feel strongly about context changing being an important thing that you have to protect? Mitchell Hashimoto Yeah, I do. I think that I definitely like selectively turn on notifications for certain things, but that’s how I think it should be. I don’t like the idea that by default, it always interrupts you. My view is I’d rather per accept than be able to right-click something or press a key bind and basically turn on notifications. Be like, this is one I care about. Or I’m in a mode where I’m iterating with you on this, so I want to know when you’re done. I think that what too many people do, I’ve literally seen people in this office that are working on doing this, where they start something in an agent and then they tab over and they’re On social media or they’re on YouTube or whatever. And I think that’s how you’re not working more efficiently with AI. The way you work more efficiently with AI is you hopefully send off multiple on little vision quests and then you yourself are doing something productive. And the problem is even if I’m writing a document, writing an email, I want to finish that email before I get back to the agents. So what I’d rather do is not get notified, be typing up emails, and when I’m done with all my emails, tab over and be like, okay, who’s writing for me? That’s what I think is more important. You’re not ignoring it for hours, but I don’t want to be interrupted every six, seven minutes. Kaushik Gopal I like it. You said by default, you don’t want to be interrupted, which is the powerful piece, right? Which is like, you’re okay if you’re being notified. Mitchell Hashimoto Yeah, and I think there’s a tooling problem. (Time 0:48:53)
  • Run Parallel Hail Mary Agents To Discover Wins
    • Spawn many parallel ‘Hail Mary’ agents across issues to find which ones succeed, then focus on the few that produced high-quality results.
    • Mitchell runs 20 parallel agents, drops garbage ones, and iterates on the promising outputs. Transcript: Mitchell Hashimoto Varies so much, but I definitely regularly have one and I definitely regularly have a bunch. And I think it matters what type of problem I’m working on. If I’m working on a problem that is pretty deep and is pretty design-heavy, then I’ll probably have one. And I’m like, what I like to do when that’s happening is I like having codecs with extra high reasoning working on one terminal tab. And that’s going to probably think for like 20 minutes. And then I like to be doing, as a human, I’m working on the exact same problem. And I’m going to compare notes when it’s done of where we got to, we’re not going to fix it in 20 minutes, this is a hard task. So in 20 minutes, we’re just going to have a sense of what’s going on. And then we guide from there and maybe switch to a more like interactive model, like Opus or something. But like, that’s, that’s how I’ll do deep problems. If I’m in a mode where like, sometimes I get a mindset where I don’t want to think that hard right now. I’m tired. It’s the end of the day or something. Or just like I didn’t sleep well. I have a toddler at home, so sometimes that happens. I’ll just be like, what I’m going to do this morning is I’m going to do that dumb prompt I just told you about. Use GH to look at this thing. That’s a skill now. I have attracted it into a skill, but I’ll prompt it for the skill. And I’m going to be like, I’m just going to launch this across 20 GitHub issues. I call those Hail Mary prompts. I don’t need them to solve the problem. I’m just trying to find which ones actually reach their target. And so then I’ll start 20 in parallel and fix these issues, work in a work tree, do all this stuff. And then, again, I think this is a tooling problem. It’s still, even though they’ve made spawning WorkTrees a lot easier, a lot of these orchestration tools have not made merging all of them easier yet. For sure. It’s still worth it for me to have these 20 that I then look in and see, like, okay, no, you did, that’s garbage work, throw that away. Or it’s reached a point where it needs my input. (Time 0:52:20)
  • Treat Agents As Long Term Collaborators
    • Always-have-an-agent is an aspirational mindset: treat agents as long-term collaborators and iterate by adding skills when they fail.
    • Mitchell tracks failures and creates new skills/agents.md entries to reduce repeated mistakes over time. Transcript: Mitchell Hashimoto Agent always running? It’s a frame of mind. It’s not literal thing. The way I temper it is it’s highly aspirational. I aspire to always have an agent running. And I said this in one of the other podcasts I was in. I think realistically, while I’m not on a computer, I have an agent running maybe three out of the 12 hours that I’m not on a computer or whatever. You know, like it’s hit rate on this is not high yet. But it’s an aspiration. And the frame of mind thing comes into, how could I get there? And how could I get there in a way that provides value? And it’s a challenge of what kind of agent framework do I need for it to do this in a meaningful way? One of the ways is like research every GitHub discussion and issue that comes in. You know, there’s startups that do this for you too, but like that’s a way to have an agent running like warm start stuff. Like instead of me manually kicking all this off, like I would love to come to every GitHub issue and have iSignal in terms of review. I don’t use any of those with my products right now because everyone I’ve tried, I’m not happy with the quality. That’s the key thing. It’s an aspiration. In the same way, another aspiration I’ve had this year is every time the agent produces results that I’m not happy with, instead of me just fixing it by myself, which I still do, in addition To that, critically ask yourself, what could I have done differently? What tool could I have given this agent? What prompt could I have done differently? So it didn’t make that mistake again. So this year, just in my commits, you’ll see I’m much more heavy handed in terms of creating new skills, creating agents.md changes. (Time 0:55:04)
  • Different Models Favor Different Workflows
    • Models are diverging: Opus/Codex-style models differ in personality, tool-calling, and code style, which affects workflow choices.
    • OpenAI’s Cloud Code plugin is a strategic move reshaping Mitchell’s workflow toward integrated tool plugins. Transcript: Mitchell Hashimoto An interesting way, I think that Opus and Codex are diverging so much in such an interesting way. In their personality and the way they do tool calls and the way they write code, it’s so different. And yeah, that’s, it’s so interesting to me because yesterday OpenAI announced their Cloud Code plugin, which I think is like a perfect like 4D chess move. Because that’s exactly, that’s exactly right. That’s changing my workflow quite a bit. Auto research that has been getting a lot of hype recently. I haven’t leveraged it. I’ve played around with it, but I haven’t truly leveraged it yet. But that totally makes sense. And yeah, things are changing. (Time 0:58:45)