I recently joined my friends Diana, Harj, Garry, and Jared on the YC Lightcone Podcast to discuss coding agents. I had a lot of fun with the conversation, but afterwards I couldn't help but feel like I hadn't gotten into the details of how I'm using the different agents. And ultimately, the details matter a lot!

In this post, I'd like to dive into some more of the nuance around the models.

As quick background: I helped launch the Codex web product, and have worked pretty extensively with Claude Code in the intervening months. I've come to the conclusion that both models have different strengths and weaknesses related to their training mix.

The biggest change to my workflow is that my time is now the biggest consideration. I'm primarily picking my coding agent as a function of how much time I have, and how long I want it to run autonomously (is it better to get a 80% draft done overnight, or try and work collaboratively with the model during the day?). Depending on the type of feature and how mission critical it seems, I'll reach for different tools. I pay for all of Claude Max, ChatGPT Pro, and Cursor Pro+, and it's some of the best money I spend anywhere.

Here's my point-in-time snapshot of what I'm doing today (Feb, 2026). It all changes quite quickly so I don't expect this to stay relevant over time.

Guiding principles

To use coding agents well, you must understand context.

It's easy to fool yourself into thinking that the coding agents are magical models. They have read all of the internet, developed deep levels of intuition for the structure of codebases, and been trained to write extremely correct code.

But at the end of the day, the agent is doing next token prediction. And each token must fit in a context window.

There are a bunch of corollaries that fall out of that...

• Your work needs to somehow be chunked. If the problem you are trying to solve is 'too big' for the context window, the agent is going to spin on it for a long time and give you poor results.
• Compaction is a lossy technique. When deciding what to compact and how, the agent is going to make choices on which information to include and omit. Maybe it does a good job, maybe it doesn't! In my experience, more compaction tends to lead to more degradation in performance.
• Externalizing context into the filesystem (e.g. a plan doc with stages which are checked or not) allows agents to selectively read and remember without filling up the full context of the conversation. This is helpful for resuming tasks and continuing to be context-efficient.
• Stay in the 'smart' half of the context window. It's generally easier to train on short-context data vs long-context data. Results will tend to be better when the context window is 'less full'. Dex Horthy calls this staying out of the dumb zone.
• You don't know what you don't know. If the agent somehow misses a relevant file or package, it might really go in a direction you didn't anticipate. If it's not in the context window, there's no way to know. Your codebase's structure can help this, as can 'progressive disclosure' of parts of the architecture. OpenAI has a nice blog post about structuring many different markdown files to do this well.

As a result, model performance and speed is governed both by the pure performance of the model, but also by how it is able to manage multiple context windows and delegate to sub-agents or teams of agents.

Opus: context whiz, better tool-use, more human

Claude Code is my regular driver for planning, orchestrating my terminal, and managing git/github operations. I'll typically use it for creating an initial plan, scripting against things on my laptop, and also for explaining how parts of the codebase work.

Opus has been trained to work across context windows extremely efficiently, so using it with Claude Code feels much faster than using Codex. You'll notice Opus frequently spinning up multiple sub-agents simultaneously, whether it's to Explore parts of the codebase or handle multiple simultaneous Task calls. The explore tool uses Haiku so it is very fast at processing a lot of tokens, and handing the relevant context back to Opus.

What's more, Opus has been trained well to use the tools on my laptop: gh, git, various MCP servers. Occasionally I will use the /chrome extension to verify a bug, which works pretty well, but can be slow and buggy.

I also find the permission model of Claude Code is easier to understand. There's a bunch of prefixes for commands you can run. With Codex models it's harder to whitelist individual CLI tools because the model will often "script" against these commands in bash (for ... gh).

I've talked a lot about Claude Code being an incredible harness for the model, and there are a lot of small things that it does which make it nice to use: updating the terminal title to be task-relevant, showing the current PR in the statusline, the little status messages.

Finally, a lot of folks talk about "personality" of the model. I don't buy into this too much, but find Opus is more willing to give me human-understandable PR descriptions and detailed architecture diagrams which are easy for me to understand.

If I am asking for an explanation about how some piece of the code is structured, I'll typically use Claude Code.

I also find Opus is a little more 'creative' in terms of suggesting things that I may have forgotten to mention. This is actually a very nice property when creating plans, I'll invariably leave some aspect out, and Opus can help point out areas of ambiguity.

Codex: way fewer bugs

Where Codex shines is correctness of code. Other folks who are pushing the models a lot seem to agree.

I run on GPT-5.3-Codex-xhigh or high, and the Codex code just straight up has fewer bugs. Opus will frequently add a set of React components which pass unit tests, but then the model just straight forgets to add it to the top-level <App> which gets rendered. There's obvious off-by-one errors which don't get caught. Dangling references or race conditions which are subtle and hard to spot.

For a long time, I thought there was a negligible difference between the two models. But after seeing enough PRs with automated reviews from Codex and Cursor's Bugbot, I've realized that OpenAI's model is superior in terms of the code it writes. If you'd like to A/B test this yourself, just check out a branch and run /code-review in Claude Code vs /review in Codex.

Unfortunately, Codex is slow.

The biggest reason for this is that it's not delegating tasks across context windows, though I get the sense that the latency between tokens might also be higher. I have been running with the experimental subagent support (toggle in /experimental) which does manage to do this and it works well, though perhaps not as seamlessly as Claude. The parallelism still isn't there quite yet.

The net result between the two is that I'll start with Claude Code and keep that open as a pane, then flip to Codex when I'm ready to actually start the coding.

Every so often I will still leverage Opus, but it mostly comes down to leveraging tool use (/chrome to debug, make stylized frontend changes).

Useful things

A few caveats: I am working on greenfield codebases. They are much much smaller than any production codebase I've worked in, and are relatively token-efficient.

Repo structure -- all of my repos have a plans/ folder, with numbered plans as I ask the agents to implement things. Typically I'll also have an apps/ folder for different services I'm running. I'm using turborepo to manage monorepos in typescript, and bun for fast installs.

Ghostty -- Mitchellh's terminal is fantastic. Fast, native, and constantly improving. For a little while I was running multiple Claude/Codex instances in tmux, but now I just use multiple panes within the same terminal tab.

Next.js on Vercel, APIs on Cloudflare Durable Objects -- I've mostly been leveraging Cloudflare Durable Objects for APIs and storage. The idea that you can partition your database ahead of time, wake it up on demand, and not have to worry a ton about concurrent writes is a really wonderful property. In a time of agents acting on small pieces of data, I can't help but feel that it just makes sense from an infra perspective. Cloudflare is also leaning into this with their cloudflare/actors library which bundles up compute with small bits of co-located storage.

Worktrees -- since all of my code is relatively lightweight and small, I'm able to leverage parallel worktrees by using bun install and then bun run dev across each one to verify locally. I have a worktree skill which copies any relevant plans, env vars, and other updates, and starts a new branch. I didn't really use worktrees prior to coding agents (I was mostly a branch guy) but having them work in parallel and letting Claude Code manage the syntax is a godsend.

Plan, Implement, Review -- I almost always have the model start with a plan. This is useful for two reasons: 1) it externalizes the context beyond a single context window 2) it allows me to review or interrogate what was done. If an agent stops for some reason, I can always start a new context window and tell it to resume the plan.

Preview deploys -- every branch gets a fresh Web + API deploy. It makes running in parallel and quickly testing branches a breeze. It's way harder to work without this.

Cursor Bugbot and Codex Code Review -- I still spot-check the code, and make sure I understand it from an architecture level, but increasingly I am not reading every line of every PR. I rely on agents to spot subtle bugs (they are far better at it than I am). For awhile I was using Claude Code, Cursor's Bugbot, and Codex. Claude Code didn't seem to catch real issues for me. Since then, I've settled mostly on Cursor as the default option since you can tell when it's working, though I find the results of Codex are good too.

Skills

Today I have a bunch of skills and a shared AGENTS.md/CLAUDE.md defined in a repo I call claudefiles. My rule for adding skills is not to do it prematurely, but only if I find myself settling into a workflow after a few times.

While I find the AGENTS/CLAUDE.md are handy for steering the model overall, skills are for two specific reasons:

1. They let you chain and automate workflows. This is my (and generally?) the most common use case for skills. I'll typically want to start with a plan, then implement in stages, then review. Why not have skills for each of these processes? Then I can have a meta skill which implements them all in order (see below).
2. They help you split context windows -- at least in Claude Code, invoking a skill can happen in a new context window if you set context: fork. This is really handy if you have a single context window for the 'master orchestrator', and then sub-agents which go and do parts of a task. The orchestrator can keep sub-agents working, and process outputs as they finish.

Skills are also great because they are very context efficient. Unlike MCP calls (which take up thousands of tokens), skills tend to be ~50-100 tokens.

Automating with skills

Early on in my journey with Claude Code, I was intrigued by the idea of skills marketplaces. That you could just install great frontend-design / security detail / architecture review.

After working for awhile, I've mostly abandoned skills that anyone else has written. Instead, I start doing things manually, then think about how I want to automate them. Over time, I've ended up building a lot of time-saving automation.

Here's how my use of skills has evolved. I say this not to tell you what the "golden path" for which skills to use, but more as an illustrative example of how you might automate more of what you are doing with them. Here's my journey.

The first skill I added was obvious, rather than tell the model to commit and push (in half a dozen different ways) add a /commit skill which is borrowed directly from Claude Code.

Then I realized if I wanted agents working in separate worktrees, I should probably just rely on Claude Code to manage it. So I added a /worktree skill which creates a new worktree, keyed off the plan's number (e.g. 00034-add-user-auth).

The next thing I noticed myself doing was always doing a plan step, then implement the plan in stages. I'd first clear the context window, and then say "implement the next stage of the plan, then /commit". But it became clear this was a good candidate for a skill: /implement which basically does exactly that.

Of course, just typing /implement in succession is annoying, so I added an /implement-all which looks at the current worktree path, ties it to the plan number, and then implements everything in stages. Sometimes when I'm running overnight, I'll leverage the /ralph-loop just to keep it going until all stages are done. I also added a local /codex-review which basically spawns a codex --review process to run the review.

/implement-all was working pretty well, but I wasn't really closing the loop on addressing feedback from the models in CI. I'd get these bug reports from Cursor + Codex indicating that there was still more work to do, even after each phase of the plan had succeeded.

So I added an /address-bugs skill which looks at the GitHub API, searches for Cursor + Codex comments since the last commit, and then attempts to verify and fix them. Then it will fix those bugs.

Finally I realized this was just working in a loop, so I added a /pr-pass, which runs at the end of /implement-all. It essentially 1) pushes to the remote 2) waits for all CI to pass 3) runs /address-bugs and then optionally goes to step 1 until it's finished.

These were all nice speedups, and I realized they were helping me with a lot of bookkeeping. So I also added a /focus skill which looks at my plans dir, my outstanding PRs, and my worktrees to help refresh my memory and keep me on track.

Importantly, I don't think I would've had any success trying to start with this process. But by building it over time and noticing little areas where I could automate, it's significantly improved my workflow.

Stuff I didn't mention here

I gave the Codex App a shot recently, and I was pleasantly surprised at the attention to detail and the little touches related to it. I have yet to move my workflow over fully from the CLI tools since I appreciate the flexibility of the terminal. Still, I like the idea. I tried giving Cowork a spin as well, and had a hard time getting it to work properly. In each case I think the sandboxing model makes a big difference!

Occasionally I will use the web interface for async jobs, though I find right now I'm more and more tied to the CLI. This is different from what I was doing 6 months ago, where I was mostly using Cursor and the built-in agent or extensions.

I've picked up pencil.dev for working on frontend UI. The deployment model is fascinating if nothing else, it shells out to your local Claude Code (able to re-use your existing subscription).

I'm still feeling like I should be using a more well-defined issue tracker. David Cramer's Dex seems to be promising, in a similar spirit to Steve Yegge's beads. Both feel like a little more than I need, but perhaps I'm just not in the right workflows.

I am not really using Playwright or other automated e2e MCPs.

Free advice to the labs

No one asked, but here it is :)

Anthropic

Model: Like I mentioned before, the Opus models totally shine on feeling human, working with engineering tools, splitting context in the right ways to achieve good parallelism, and taking liberty on things "you might have forgotten". Where they don't is in the code correctness. I'd love to see an 'Opus Strict' mode, where some base model has really been RL'd to achieve better performance. Opus is where I start, but Codex writes all my code. If I was budget constrained, I'd probably pick Codex.

Product harness: This is the one area where I basically have no notes. Boris and Cat have better ideas than I do mostly. My two requests:

1. Adopt agent skills so I don't have to do this dumb symlinking between a bunch of directories. I think Anthropic has little incentive to make this happen, but it'd be nice for those of us who flex between the two CLIs.
2. Publish the output format for --stream-json. I'm probably not alone in terms of being interested in running Claude Code in a sandbox on behalf of users. But I am worried the format will change out from underneath me. Depending on the sandbox, it's also been annoying to setup the right pathing properly for Claude Code, whereas the other CLI tools (Codex, Cursor, Gemini) seem to install without issue.

OpenAI

Model: The number one thing the OpenAI models can do to improve is figure out how to split across context windows and delegate to sub-agents. I'm using the experimental sub-agent version. There's also this "more than what you asked for" concept that Opus manages to accomplish during planning that would be useful.

Product harness: I have a lot of small feedback here that I think would go a long way (and maybe some of this is out of date)...

1. I still don't understand the sandboxing model vs Claude Code's, and because the model often tends to script, I end up needing to give a lot of approvals. Since the models are so determined, I worry a bit about running in --yolo mode.
2. Like Claude Code, add some sort of "user guide" that ships with the CLI so I can ask questions about things like where to put skills, which fields are supported, etc. I'd love to be able to tell Codex what sort of sandboxing model I want and have it automatically configure that without needing to have it fetch the repo and look at the source.
3. Make /review a regular skill rather than the odd sort of packaged command it is right now. I want the model to be able to invoke it dynamically.
4. Nit: change the title of my terminal tab to something related to the task when executing. I frequently lose track of dozens of codex title tabs.
5. Have some sort of training specific to PR descriptions and commit descriptions. I generally like Codex's terse personality, but these could be expanded.
6. Support context: fork in skill definitions.
7. If a link overflows the line in the pane, it should still be clickable.
8. Show my current worktree/PR/branch name at the bottom of the status bar.

Where this all goes

A few weeks ago, a friend sent me the post on Gas Town by Steve Yegge. It's still one of the wildest things I've read.

If you haven't seen it, Steve basically makes the case that you should just always be maxing out tokens. You should have a pool of workers, who are hungry to accept more work, and they should be going 24/7. You should make lots of plans. You should expect to throw them away.

For all your take on whether the abstractions are correct or not, directionally, I think Steve is absolutely correct.

The dream is to have your laptop (or cloud sandbox or whatever) constantly churning on ideas in the background, and have you be able to nudge it in directions, go off and do research, review its output and come back. Working with coding agents has made me feel much more like an engineering manager again when it comes to coordination, but without worrying about motivating the agents or the personalities involved.

Today it feels like we're quite a bit closer to that future. This is over-hyped on Twitter, but I do really try and kick off 3-4 tasks in Codex before going to bed, so they'll be ready for review in the morning. But I'm still not at the point where I feel like I can have agents running 24/7.

I think there are two barriers to more progress here...

1. Context window size/coordination (see above). Agents can't endlessly compact/recycle in the same context window. We need either smarter harnesses or something which provides more delegation.
2. Resistance to prompt injection. Sometimes the agents will only run for a few minutes before asking for an escalated approval. If I'm going to let them run overnight, I don't really trust them to run in --yolo mode, but there's a subset of sane permissions/domains I'd allow.

On the first point, Cursor has been pushing the bounds of what swarms of agents can do across many context windows. I still haven't seen great answers to the second, and it's an active area of research. Running in a sandbox seems like the best workaround for the moment, but this is still more painful to configure than it should be, and if there's privileged data that your agent has access to with open internet access, it's vulnerable to the Lethal Trifecta.

As a solo engineer working on projects, I'm already finding that I am the bottleneck when it comes to the right ideas. More and more, ideas, architecture, and project sequencing are going to become the limiting factors for building great products.

Recently, I've found myself introducing more and more friends to Obsidian.

For those unfamiliar: Obsidian can act as a nice markdown editor for taking structured notes. It's sort of like a local-first hybrid of Notion and Roam Research. Obsidian is local-first and works with markdown files on your laptop, so it has a bunch of nice properties: 1) it's always available 2) it's fast 3) it works remarkably well with Claude Code.

I've been a daily Obsidian user since November, 2021 (I checked my daily notes), and it's gradually become my 'personal operating system' for a lot of my own thinking and writing. In that time, I've become more opinionated about how it should work.

This post serves as a sort of guide for how I work with it.

The golden rule of note-taking

I have one rule of working with Obsidian and other note-taking apps:

The primary goal of the tool should be eliciting thought. Nothing else matters.

It is easy to get caught up in the 'most optimal note-taking setup'. Automations, tagging, etc, etc. I've now come to believe that the only thing that matters is whether your system causes you to have better (and probably more) thoughts.

There are all sorts of corollaries that fall out of this:

• Don't think too hard about where to put notes. If you need to make a decision every time you take a note, you probably are recording fewer thoughts!
• Don't obsess over organizing old notes. It's tempting to want to spend time 'tending to your note-taking garden'. Maybe you want it all formatted the same way or to follow some sort of standard. But I don't think this makes much sense. 99% of the time I never re-visit my notes, and that is fine. The number one goal is to elicit my thoughts. The only time I use folders now is for automations (daily/ or clippings/), where the folder structure is done for me.
• Notes are for you. The other benefit I like from Obsidian is that the state is all local (encrypted if you use Obsidian sync or iCloud). I originally didn't think this would matter that much, but there's something freeing about knowing your notes will not leak.

When in doubt, respect the golden rule. It's almost always better to just start writing.

Systems I use

Daily note - the backbone of my notes is the 'daily note'. I leverage the 'daily note' plugin and make sure to set a hotkey for it (Ctrl+Shift+D). I set a template for it (stored in templates/Daily.md) just to get started, which I refresh every ~6mo or so. Here's what my current template looks like.

Again, the point of this is so I don't have a blank page and I can just get started writing. I'll typically journal in the "What's happening?" section, and then add any goals I'd like to finish to the goals/calendar. I have some standard links I keep to remind myself of longer term projects, but I haven't been using these a ton.

Beyond the daily note, I have a few types of long-lived notes: Projects, Nouns, Lists, and Docs.

Project notes revolve around some sort of longer-lived project. I am pretty free-form with these (see rule #1). Rather than worry about organizing them, I'll typically just come up with a name for the project that's a single word and then add an em-dash (colons aren't allowed) to whatever. If it's some point-in-time doc, I'll typically add a month it's related to (e.g. Dec '25).

Right now, I'm hacking on an app called Tacit so this is what that looks like:

I'll sometimes create a "Captain's Log" doc for running notes. Again, I'm not too precious about structure here.

Nouns typically reference some long-lived thing that I'll come into contact with again and again: people, companies, restaurants, concepts / mental models. I tend to give these their own note and take notes directly there. I have a short meeting template which basically is just a header with the current date which I'll insert whenever I interact with that entity.

Lists are almost always things that I want to keep track of and pretty self explanatory: book recs, goals, etc.

Docs are kind of the 'catch-all' for when an idea seems worth exploring. Rather than fire up an entirely new note, my typical workflow is to add the stub to my daily note as one of my TODOs, then go in and flesh out the doc. I'm not sure why, but something about seeing a stub that needs to be written causes me to want to flesh it out.

Hotkeys + Slash Commands. Using Obsidian well means learning the hotkeys. You don't need all of them, but I do use a handful on a very regular basis:

• Daily notes: ctrl+shift+d, (next: ctrl+shift+n, prev: ctrl+shift-p)
• New note: ctrl+n
• Formatting: bold (cmd+b), italic: (cmd+i)
• Open/Search: cmd+o
• Add/Complete TODO: cmd+l
• Slash command: insert template, insert today's date

MacWhisper. If I ever get stuck writing, I've often found some use in 'changing modes'. Transcription software has gotten good enough that I'll just start speaking and that usually allows me to go from there. I like MacWhisper, which (like Obsidian) works locally and is out of the way. I've configured the right option key to toggle it on and off. I use NVIDIA's parakeet model which I find is both fast and accurate. I like the fact that I control where the voice appears by where my cursor is.

Theme: Flexoki. For the longest time I didn't care much for themes and just used the default. I've recently fallen in love with Steph Ango's (Obsidian creator) Flexoki theme, so I use that. I find it feels a little more personal, which gets me to write slightly more on the margin.

Templates. I use a couple of templates. There's the Daily template which is the whole note (shown above). I have a Weekplan template which I use to plan my weeks. And I have a 'meeting' template which I insert into one of the "noun notes" whenever I have a meeting.

Stuff I use occasionally

Web Clipper. One of the officially supported ways to integrate with Obsidian is the web clipper. Every so often, I'll find myself starting to copy/paste from some website, and then remember I can just click a button and it will create a new note in clippings/. Useful for saving things like recipes or referencing specific blog/reddit posts.

Claude Code. Because it's all markdown, Claude Code is very good at things like Semantic Search or updating parts of your vault. I've also used it to keep track of stuff that I'm doing (e.g. put this in my daily note for obsidian).

Mobile app. If there's one place which I have a slightly mixed bag, it's the mobile app. Don't get me wrong, Obsidian has a great mobile app which is actually really well designed. But the fact that it's local first means that it effectively downloads a bunch of markdown while you're using the app, leading to the occasional skew issues. I wish there were a better way to do voice transcription → notes on the device but everything I've tried is sort of kludge-y due to the way that Apple has setup the ecosystem on iPhone

Then there's stuff I tried and don't really use much anymore: tagging, folder organization, complicated templates, community plugins. I am sure these are great, but I don't find them that useful. I don't use Obsidian for obsessively managing TODOs anymore. I treat each day as a new todo list, and then I keep moving.

Interesting Outcomes

When I first started using Obsidian, I tried to add too much structure. Now I find I just start writing about whatever is on my mind. Daily notes have gotten to the point where they've become a habit, they are pretty much the first thing I start looking at when I start my day.

My friend Titiaan asked me if there were any downsides to using Obsidian. The main one I've found is that I now need to write in order to think. It's sort of hard for me to deal with a complex decision without spending some time writing about it.

As coding agents become more capable and long-running, they don’t remove the human job of thinking. Someone still has to direct the work—set goals, choose constraints, and judge outputs.

Everyone seems to recognize this in the abstract. But nobody seems to talk much about how the product shape fundamentally shifts the type of thinking required to write code.

I'd argue that seemingly minor UX differences between different coding agents end up having a massive impact on how users spend their "thinking budget."

With a remote-first product like Codex Cloud (not the CLI), the product encourages you not to spend time thinking while the agent is working and spend more time thinking about the end result that the agent gave. We intentionally didn't want users watching the agent invoking terminal commands, because the model works very differently than a human might.

With an interactive product like Claude Code or Codex CLI, you naturally spend more time thinking about about specs and the high level approach the agent is taking as you follow the chain of thought in the terminal. But you need some other means of looking at diffs (editor / GitHub), so it tends to be less a part of the workflow vs following the plan the tool has created and the commands it is running to verify as it implements.

With an IDE-focused product like Cursor, you accept most diffs as they come in. Your thinking window is relatively short because you are accepting code (or not). You need to do relatively little thinking to supply the right context, because it's already in your editor. The trade-off is that you have probably broken down the problem ahead of time. You need to spend more time coming up with the plan/approach yourself.

All of these products need to shift the "active thinking" cycles around between...

1. supplying the right context
2. coming up with a plan
3. implementing the code
4. verifying and reviewing it

If I were to guess, the area that LLMs are strongest right now is 3 (implementation) > 4 (verification) > 2 (planning) > 1 (context). Until we deploy tools for doing search across the organization, eliciting info from the user, and understanding the global context of an org–providing the right context still seems to be the area where humans can provide the most value.

Conversely, LLMs excel at taking well-specified plans and implementing them. They handle race conditions, error handling, and complex technical details remarkably well.

If you accept this idea of a thinking budget, it's easy to understand why engineers might have very different experiences (positive and negative) using the different tools.

Some problems require only a clear spec—you know the implementation completely. Others require writing code to "think through" the problem, then refactoring iteratively. Some engineers prefer reviewing a first pass to writing from scratch.

Whatever your preference, different UX requires you to think in different ways. I think it's unlikely that a 'single workflow' will satisfy all users. You still have to think... but the best products will let users choose how they want to do that. ¹

Footnotes

1. The new Codex IDE extension actually does a very good job of this. You can decide to kick off tasks locally, or hand them off to the cloud. Disclosure: I was working on this team, so I am biased. ↩

There's an endless debate around coding agents. What's the best way to prompt? How about reviewing the outputs? Are the results garbage, and do agents really waste more time in the end?

But the one thing that all my engineering friends seem to agree on is that "coding today feels much more fun". And the majority of them point to the same tool: Claude Code. ¹

After working on Codex at OpenAI ², I wanted to do a closer study of Claude Code to understand exactly what makes developers so excited about it.

Initially, I was very skeptical about using a CLI tool to manage coding edits. My entire programming career has been IDE-centric. But after using Claude Code for a few weeks, it's hard not to feel that sense of fun.

I could say many great things about the way Claude Code is built–but the most underrated aspect is the feeling that you can endlessly hack it to your liking.

Using Claude Code feels more like playing the piano than shuffling tickets in Jira. I get the vague sense that by using the tool differently, I could become a virtuoso.

There's not just the game of writing code, but a metagame that we're all playing by using it in weird and wonderful ways.

A retro gaming aesthetic

When I first ran claude, I was quickly struck by 1) the attention to detail and 2) the inspiration from old-school video games.

Here's the first thing I see when I launch Claude Code.

Unlike your average CLI tool, it actually has... UI design?

Small accent colors make the UI playful and interesting. The three shades of text color draw your eye to specific sections (header > input box > changelog). Animated text subtly changes color. There are tasteful unicode icons that feel vaguely reminiscent of the Anthropic logo. There's a fun retro aesthetic. And I'm greeted with a clear call to action: Try "write a test for InboxList.tsx".

The very first screen also tells me how to get more from the tool. It gives me a changelog, a prompt, and a tip of the day. Expanding the shortcut menu shows me how to use the advanced features.

When making a choice, Claude Code gives me a handful of options for things like follow-ups.

I can select option 1, 2, or 3 just like I would in an RPG. The hotkeys all work the way I'd expect.

Claude Code is also partially defined by what it is not–it's not an IDE.

This is important for two big reasons:

1. It feels lightweight. I'm not signing up to learn an entirely new editor. I'm just running a tool in my terminal.
2. It is unique and differentiated. Authoring code outside an IDE feels like a weird new paradigm–but so is writing AI-generated code. Rather than compete with IDEs on their terms, a CLI tool embraces a different paradigm.

The resulting product feels easy to try and also has the freedom to optimize for a future where humans aren't the ones writing code.

Claude Code can devote more screen real estate to things like subagents or hooks because I don't expect to use it to view my folder tree or open files.

Building trust

After onboarding users, the biggest hurdle for any agentic tool is building trust. Users need to answer questions like: "What complexity of tasks can the model one-shot?" and "How should I verify the outputs without needing to examine every single line?"

Vibe-coding apps often struggle with building trust. On the one hand, the user can instantly verify that the behavior works by clicking through the app (great!). On the other, the surface area makes it harder to inspect what is going on when things do go wrong.

When we were building the cloud version of Codex at OpenAI, we didn't want the user checking in on the model and trying to "steer" it.

This tends to be good from a correctness perspective: the model is surprisingly adept at failure recovery, and giving the agent a "longer leash" to execute code dramatically improves performance. But it doesn't do as much to instill confidence in the user that the model is really doing the right thing.

We knew we needed some solution here, so we showed users the terminal commands that the model was executing in its own environment. This felt like a nice compromise, in addition to having the model output the results of tests and lint steps.

The one problem is that terminal commands are far less intuitive than TODO lists—completed TODOs are straightforward, but sed commands... less so.

I'm not sure whether leveraging the TODO list tool actually improves eval scores or is just a courtesy to the user. But it certainly helps the person in front of the keyboard understand what's going on.

There's also the question of context management. In an IDE, it's less clear which files and tabs are being pulled into the context window. Creating a new chat might erase the model's prior thinking, but will it still include the file you're looking at?

Claude Code makes this easier to reason about: everything invoked within the terminal session is included in the context. If Claude Code is compacting the context window, it will tell you that. If you want to run a compaction manually, the docs explain how.

Speed and momentum

A large part of what contributes to that feeling of flow is Claude Code's speed.

Sampling from the models feels fast. When inspecting the network traffic of the CLI, I see it switching between all three models (Haiku, Sonnet, Opus) depending on what the use case is.

Looking carefully at the interface, I also notice a bunch of different small cues which tell me that Claude Code is doing something:

• animated icons and flavor text (Contemplating / Flibbertigibetting / Symbioting); they change as work progresses and the colors subtly 'pulse'
• a current runtime counter that counts up every second
• a token counter paired with an icon that switches between "upload", "download", and "working".

The sum total of all of it is that the interface feels responsive and alive. I know that work is happening as I use it.

An OpenAI friend of mine once remarked "I get stressed out when <INTERNAL_AGENT> is not running on my laptop".

In a time when new SOTA models appear every week and VCs are funding millions of GPUs, not using coding agents feels wasteful. It's like leaving free intelligence on the ground.

Claude Code taps deeply into this mentality. Rather than trying to obscure the number of tokens I'm using, it encourages me to maximize them. And if I pay for the "Claude Max" plan, the tokens I get feel unlimited, even if the per-token cost ends up being high.

The machine that builds the machine

This brings me to the last magic piece of Claude Code: the notion that through dedicated practice, I can learn to become 10x as productive.

When using Claude Code, there are effectively two parts of the loop I can optimize:

1. core agent loop: building the core product I'm working on (adding new features, fixing bugs, etc)
2. product harness: the tools, environment, memory, and prompts that the CLI uses to run the core agent loop

It turns out that optimizing the product harness is almost as much fun as actually building product.

All coding agents involve an element of gambling. When I submit a prompt, I never know where it's going to end up. I can keep spinning the wheel a bunch of times to see how it pans out.

But there's a key difference with Claude Code. Instead of just changing the way that I prompt the model, Claude Code encourages me to change the product harness itself.

That means that whenever Claude Code does the wrong thing, instead of blaming the tool, I find myself asking: "What could I have done better?" Could changes in the product harness give me a better result?

This "metagame" ends up being the #1 marketing tool for Claude Code, because it's something everyone does. It doesn't matter whether you write embedded Rust frameworks or Typescript frontends, you're going to be experimenting with how best to use all of the features of Claude Code.

Because users can "own" their product harness, everyone wants to show off their tips and tricks. My twitter feed is filled with Claude Code automations and best practices.

The product shape helps this too; CLI tools are naturally composable. It's easy to start imagining the possibilities: "Could I kick off tasks from a GitHub issue?", "Could I chain agents together? And have them invoke the CLI in series?", "Could I use git worktrees and run a bunch of sessions in parallel?" ³

The end result resembles an automation game, but when I'm done playing, I've brought something useful into the world.

A feeling of flow

A friend pointed out that what makes Claude Code fun isn't "gamification" in the traditional sense. There are no badges, levels, streaks, or anything like that.

Instead, it's the feeling of flow state and mastery that you get from learning to use the tool well.

There's a low barrier to entry–start by running a command and typing a prompt into the box. The product gradually reveals new ways of using the CLI through daily tips and suggestions. There's a sense of momentum, paired with clear, immediate feedback on what the agent is doing.

And most importantly, there are opportunities to improve your skill by using more advanced features and automations. Claude Code encourages you to keep honing that "product harness loop".

While coding is the perfect Petri dish for these sorts of ideas, these same techniques can be applied to other domains. At the end of the day, most knowledge work still involves critical thinking, resource allocation, and strategic planning. Perhaps enterprise software should borrow more ideas from Minecraft and fewer from 1950s-era accounting.

If coding is any indication, the tools that seem to be winning allow the user to hack their own workflows and optimize for that "feeling of flow".

My biggest takeaway is that it's not just the evals that matter–the product harness matters too.

Does all of this tweaking and customization actually make us more productive or is it just fun to do? There's probably some efficient frontier in between. And we'll need malleable tools to find it.

Footnotes

1. I'm discussing Claude Code in this post since it pioneered the agentic CLI concept. In my (admittedly biased) opinion of my former employer, the Codex CLI team is doing great work and is incorporating a bunch of these same ideas. They have shipped a ton of updates, so check it out if you haven't in a while (be sure to upgrade to the latest version!). Gemini also followed suit here as well, but I haven't had the chance to test it nearly as much. ↩

2. The cloud version, not the CLI. ↩

3. This was actually the "killer feature" bet we made with Codex. The fact that it operates asynchronously means that you can kick off as many tasks as you'd like in parallel, no worktrees required. In the fullness of time I think it will also be the way users want to interact with the models. But it does require some "re-tooling" on the user's side. ↩

I left OpenAI three weeks ago. I had joined the company back in May 2024.

I wanted to share my reflections because there's a lot of smoke and noise around what OpenAI is doing, but not a lot of first-hand accounts of what the culture of working there actually feels like.

Nabeel Qureshi has an amazing post called Reflections on Palantir, where he ruminates on what made Palantir special. I wanted to do the same for OpenAI while it's fresh in my mind. You won't find any trade secrets here, more just reflections on this current iteration of one of the most fascinating organizations in history at an extremely interesting time.

To put it up-front: there wasn't any personal drama in my decision to leave–in fact I was deeply conflicted about it. It's hard to go from being a founder of your own thing to an employee at a 3,000-person organization. Right now I'm craving a fresh start.

It's entirely possible that the quality of the work will draw me back. It's hard to imagine building anything as impactful as AGI, and LLMs are easily the technological innovation of the decade. I feel lucky to have seen some of the developments first-hand and also been a part of the Codex launch.

Obviously these aren't the views of the company–as observations they are my own. OpenAI is a big place, and this is my little window into it.

Culture

The first thing to know about OpenAI is how quickly it's grown. When I joined, the company was a little over 1,000 people. One year later, it is over 3,000 and I was in the top 30% by tenure. Nearly everyone in leadership is doing a drastically different job than they were ~2-3 years ago. ¹

Of course, everything breaks when you scale that quickly: how to communicate as a company, the reporting structures, how to ship product, how to manage and organize people, the hiring processes, etc. Teams vary significantly in culture: some are sprinting flat-out all the time, others are babysitting big runs, some are moving along at a much more consistent pace. There's no single OpenAI experience, and research, applied, and GTM operate on very different time horizons.

An unusual part of OpenAI is that everything, and I mean everything, runs on Slack. There is no email. I maybe received ~10 emails in my entire time there. If you aren't organized, you will find this incredibly distracting. If you curate your channels and notifications, you can make it pretty workable.

OpenAI is incredibly bottoms-up, especially in research. When I first showed up, I started asking questions about the roadmap for the next quarter. The answer I got was: "this doesn't exist" (though now it does). Good ideas can come from anywhere, and it's often not really clear which ideas will prove most fruitful ahead of time. Rather than a grand 'master plan', progress is iterative and uncovered as new research bears fruit.

Thanks to this bottoms-up culture, OpenAI is also very meritocratic. Historically, leaders in the company are promoted primarily based upon their ability to have good ideas and then execute upon them. Many leaders who were incredibly competent weren't very good at things like presenting at all-hands or political maneuvering. That matters less at OpenAI then it might at other companies. The best ideas do tend to win. ²

There's a strong bias to action (you can just do things). It wasn't unusual for similar teams but unrelated teams to converge on various ideas. I started out working on a parallel (but internal) effort similar to ChatGPT Connectors. There must've been ~3-4 different Codex prototypes floating around before we decided to push for a launch. These efforts are usually taken by a small handful of individuals without asking permission. Teams tend to quickly form around them as they show promise.

Andrey (the Codex lead) used to tell me that you should think of researchers as their own "mini-executive". There is a strong bias to work on your own thing and see how it pans out. There's a corollary here–most research gets done by nerd-sniping a researcher into a particular problem. If something is considered boring or 'solved', it probably won't get worked on.

Good research managers are insanely impactful and also incredibly limited. The best ones manage to connect the dots between many different research efforts and bring together a bigger model training. The same goes for great PMs (shoutout ae).

The ChatGPT EMs I worked with (Akshay, Rizzo, Sulman) were some of the coolest customers I've ever seen. It really felt like they had seen everything at this point ³. Most of them were relatively hands-off, but hired good people and tried to make sure they were setup for success.

OpenAI changes direction on a dime. This was a thing we valued a lot at Segment–it's much better to do the right thing as you get new information, vs decide to stay the course just because you had a plan. It's remarkable that a company as large as OpenAI still maintains this ethos–Google clearly doesn't. The company makes decisions quickly, and when deciding to pursue a direction, goes all in.

There is a ton of scrutiny on the company. Coming from a b2b enterprise background, this was a bit of a shock to me. I'd regularly see news stories broken in the press that hadn't yet been announced internally. I'd tell people I work at OpenAI and be met with a pre-formed opinion on the company. A number of Twitter users run automated bots which check to see if there are new feature launches coming up.

As a result, OpenAI is a very secretive place. I couldn't tell anyone what I was working on in detail. There's a handful of slack workspaces with various permissions. Revenue and burn numbers are more closely guarded.

OpenAI is also a more serious place than you might expect, in part because the stakes feel really high. On the one hand, there's the goal of building AGI–which means there is a lot to get right. On the other hand, you're trying to build a product that hundreds of millions of users leverage for everything from medical advice to therapy. And on the other, other hand, the company is competing in the biggest arena in the world. We'd pay close attention to what was happening at Meta, Google, and Anthropic–and I'm sure they were all doing the same. All of the major world governments are watching this space with a keen interest.

As often as OpenAI is maligned in the press, everyone I met there is actually trying to do the right thing. Given the consumer focus, it is the most visible of the big labs, and consequently there's a lot of slander for it.

That said, you probably shouldn't view OpenAI as a single monolith. I think of OpenAI as an organization that started like Los Alamos. It was a group of scientists and tinkerers investigating the cutting edge of science. That group happened to accidentally spawn the most viral consumer app in history. And then grew to have ambitions to sell to governments and enterprises. People of different tenure and different parts of the org subsequently have very different goals and viewpoints. The longer you've been there, the more you probably view things through the "research lab" or "non-profit for good" lens.

The thing that I appreciate most is that the company is that it "walks the walk" in terms of distributing the benefits of AI. Cutting edge models aren't reserved for some enterprise-grade tier with an annual agreement. Anybody in the world can jump onto ChatGPT and get an answer, even if they aren't logged in. There's an API you can sign up and use–and most of the models (even if SOTA or proprietary) tend to quickly make it into the API for startups to use. You could imagine an alternate regime that operates very differently from the one we're in today. OpenAI deserves a ton of credit for this, and it's still core to the DNA of the company.

Safety is actually more of a thing than you might guess if you read a lot from Zvi or Lesswrong. There's a large number of people working to develop safety systems. Given the nature of OpenAI, I saw more focus on practical risks (hate speech, abuse, manipulating political biases, crafting bio-weapons, self-harm, prompt injection) than theoretical ones (intelligence explosion, power-seeking). That's not to say that nobody is working on the latter, there's definitely people focusing on the theoretical risks. But from my viewpoint, it's not the focus. Most of the work which is done isn't published, and OpenAI really should do more to get it out there.

Unlike other companies which freely hand out their swag at every career fair, OpenAI doesn't really give much swag (even to new employees). Instead there are 'drops' which happen where you can order in-stock items. The first one brought down the Shopify store, it had so much demand. There was an internal post which circulated on how to POST the right json payloads and circumvent this.

Nearly everything is a rounding error compared to GPU cost. To give you a sense: a niche feature that was built as part of the Codex product had the same GPU cost footprint as our entire Segment infrastructure (not the same scale as ChatGPT but saw a decent portion of internet traffic).

OpenAI is perhaps the most frighteningly ambitious org I've ever seen. You might think that having one of the top consumer apps on the planet might be enough, but there's a desire to compete across dozens of arenas: the API product, deep research, hardware, coding agents, image generation, and a handful of others which haven't been announced. It's a fertile ground for taking ideas and running with them.

The company pays a lot of attention to twitter. If you tweet something related to OpenAI that goes viral, chances are good someone will read about it and consider it. A friend of mine joked, "this company runs on twitter vibes". As a consumer company, perhaps that's not so wrong. There's certainly still a lot of analytics around usage, user growth, and retention–but the vibes are equally as important.

Teams at OpenAI are much more fluid than they might be elsewhere. When launching Codex, we needed some help from a few experienced ChatGPT engineers to hit our launch date. We met with some of the ChatGPT EMs to make the request. The next day we had two badass folks ready to dive in and help. There was no "waiting for quarterly planning" or "re-shuffling headcount". It moved really quickly.

Leadership is quite visible and heavily involved. This might be obvious at a company such as OpenAI, but every exec seemed quite dialed in. You'd see gdb, sama, kw, mark, dane, et al chime in regularly on Slack. There are no absentee leaders.

Code

OpenAI uses a giant monorepo which is ~mostly Python (though there is a growing set of Rust services and a handful of Golang services sprinkled in for things like network proxies). This creates a lot of strange-looking code because there are so many ways you can write Python. You will encounter both libraries designed for scale from 10y Google veterans as well as throwaway Jupyter notebooks from newly-minted PhDs. Pretty much everything operates around FastAPI to create APIs and Pydantic for validation. But there aren't style guides enforced writ-large.

OpenAI runs everything on Azure. What's funny about this is there are exactly three services that I would consider trustworthy: Azure Kubernetes Service, CosmosDB (Azure's document storage), and BlobStore. There's no true equivalents of Dynamo, Spanner, Bigtable, Bigquery Kinesis or Aurora. It's a bit rarer to think a lot in auto-scaling units. The IAM implementations tend to be way more limited than what you might get from an AWS. And there's a strong bias to implement in-house.

When it comes to personnel (at least in eng), there's a very significant Meta → OpenAI pipeline. In many ways, OpenAI resembles early Meta: a blockbuster consumer app, nascent infra, and a desire to move really quickly. Most of the infra talent I've seen brought over from Meta + Instagram has been quite strong.

Put these things together, and you see a lot of core parts of infra that feel reminiscent of Meta. There was an in-house reimplementation of TAO. An effort to consolidate auth identity at the edge. And I'm sure a number of others I don't know about.

Chat runs really deep. Since ChatGPT took off, a lot of the codebase is structured around the idea of chat messages and conversations. These primitives are so baked at this point, you should probably ignore them at your own peril. We did deviate from them a bit in Codex (leaning more into learnings from the responses API), but we leveraged a lot of prior art.

Code wins. Rather than having some central architecture or planning committee, decisions are typically made by whichever team plans to do the work. The result is that there's a strong bias for action, and often a number of duplicate parts of the codebase. I must've seen half a dozen libraries for things like queue management or agent loops.

There were a few areas where having a rapidly scaled eng team and not a lot of tooling created issues. sa-server (the backend monolith) was a bit of a dumping ground. CI broke a lot more frequently than you might expect on master. Test cases even running in parallel and factoring in a subset of dependencies could take ~30m to run on GPUs. These weren't unsolvable problems, but it's a good reminder that these sorts of problems exist everywhere, and they are likely to get worse when you scale super quickly. To the credit of the internal teams, there's a lot of focus going into improving this story.

Other things I learned

What a big consumer brand looks like. I hadn't really internalized this until we started working on Codex. Everything is measured in terms of 'pro subs'. Even for a product like Codex, we thought of the onboarding primarily related to individual usage rather than teams. It broke my brain a bit, coming from predominantly a B2B / enterprise background. You flip a switch and you get traffic from day 1.

How large models are trained (at a high-level). There's a spectrum from "experimentation" to "engineering". Most ideas start out as small-scale experiments. If the results look promising, they then get incorporated into a bigger run. Experimentation is as much about tweaking the core algorithms as it is tweaking the data mix and carefully studying the results. On the large end, doing a big run almost looks like giant distributed systems engineering. There will be weird edge cases and things you didn't expect. It's up to you to debug them.

How to do GPU-math. We had to forecast out the load capacity requirements as part of the Codex launch, and doing this was the first time I'd really spent benchmarking any GPUs. The gist is that you should actually start from the latency requirements you need (overall latency, # of tokens, time-to-first-token) vs doing bottoms-up analysis on what a GPU can support. Every new model iteration can change the load patterns wildly.

How to work in a large Python codebase. Segment was a combination of both microservices, and was mostly Golang and Typescript. We didn't really have the breadth of code that OpenAI does. I learned a lot about how to scale a codebase based upon the number of developers contributing to it. You have to put in a lot more guardrails for things like "works by default", "keep master clean", and "hard to misuse".

Launching Codex

A big part of my last three months at OpenAI was launching Codex. It's unquestionably one of the highlights of my career.

To set the stage, back in November 2024, OpenAI had set a 2025 goal to launch a coding agent. By February 2025 we had a few internal tools floating around which were using the models to great effect. And we were feeling the pressure to launch a coding-specific agent. Clearly the models had gotten to the point where they were getting really useful for coding (seeing the new explosion of vibe-coding tools in the market).

I returned early from my paternity leave to help participate in the Codex launch. A week after I returned, we had a (slightly chaotic) merger of two teams, and began a mad-dash sprint. From start (the first lines of code written) to finish, the whole product was built in just 7 weeks.

The Codex sprint was probably the hardest I've worked in nearly a decade. Most nights were up until 11 or midnight. Waking up to a newborn at 5:30 every morning. Heading to the office again at 7a. Working most weekends. We all pushed hard as a team, because every week counted. It reminded me of being back at YC.

It's hard to overstate how incredible this level of pace was. I haven't seen organizations large or small go from an idea to a fully launched + freely available product in such a short window. The scope wasn't small either; we built a container runtime, made optimizations on repo downloading, fine-tuned a custom model to deal with code edits, handled all manner of git operations, introduced a completely new surface area, enabled internet access, and ended up with a product that was generally a delight to use. ⁴

Say what you will, OpenAI still has that launching spirit. ⁵

The good news is that the right people can make magic happen. We were a senior team of ~8 engineers, ~4 researchers, 2 designers, 2 GTM and a PM. Had we not had that group, I think we would've failed. Nobody needed much direction, but we did need a decent amount of coordination. If you get the chance to work with anyone on the Codex team, know that every one of them is fantastic.

The night before launch, five of us stayed up until 4a trying to deploy the main monolith (a multi-hour affair). Then it was back to the office for the 8a launch announcement and livestream. We turned on the flags, and started to see see the traffic pour in. I've never seen a product get so much immediate uptick just from appearing in a left-hand sidebar, but that's the power of ChatGPT.

In terms of the product shape, we settled on a form factor which was entirely asynchronous. Unlike tools like Cursor (at the time, it now supports a similar mode) or Claude Code, we aimed to allow users to kick off tasks and let the agent run in its own environment. Our bet was in the end-game, users should treat a coding agent like a co-worker: they'd send messages to the agent, it gets some time to do its work, and then it comes back with a PR.

This was a bit of a gamble: we're in a slightly weird state today where the models are good, but not great. They can work for minutes at a time, but not yet hours. Users have widely varying degrees of trust in the models capabilities. And we're not even clear what the true capabilities of the models are.

Over the long arc of time, I do believe most programming will look more like Codex. In the meantime, it's going to be interesting to see how all the products unfold.

Codex (maybe unsurprisingly) is really good at working in a large codebase, understanding how to navigate it. The biggest differentiator I've seen vs other tools is the ability to kick off multiple tasks at once and compare their output.

I recently saw that there are public numbers comparing the PRs made by different LLM agents. Just at the public numbers, Codex has generated 630,000 PRs. That's about 78k public PRs per engineer in the 53 days since launch (you can make your own guesses about the multiple of private PRs). I'm not sure I've ever worked on something so impactful in my life.

Parting thoughts

Truth be told, I was originally apprehensive about joining OpenAI. I wasn't sure what it would be like to sacrifice my freedom, to have a boss, to be a much smaller piece of a much larger machine. I kept it fairly low-key that I had joined, just in case it wasn't the right fit.

I did want to get three things from the experience...

• to build intuition for how the models were trained and where the capabilities were going
• to work with and learn from amazing people
• to launch a great product

In reflecting on the year, I think it was one of the best moves I've ever made. It's hard to imagine learning more anywhere else.

If you're a founder and feeling like your startup really isn't going anywhere, you should either 1) deeply re-assess how you can take more shots on goal or 2) go join one of the big labs. Right now is an incredible time to build. But it's also an incredible time to peer into where the future is headed.

As I see it, the path to AGI is a three-horse race right now: OpenAI, Anthropic, and Google. Each of these organizations are going to take a different path to get there based upon their DNA (consumer vs business vs rock-solid-infra + data). ⁶ Working at any of them will be an eye-opening experience.

---

Thank you to Leah for being incredibly supportive and taking the majority of the childcare throughout the late nights. Thanks to PW, GDB, and Rizzo for giving me a shot. Thanks to the SA teammates for teaching me the ropes: Andrew, Anup, Bill, Jeremy, Kwaz, Ming, Simon, Tony, and Val. And thanks for the Codex core team for giving me the ride of a lifetime: Albin, AE, Andrey, Bryan, Channing, DavidK, Gabe, Gladstone, Hanson, Joey, Josh, Katy, KevinT, Max, Sabrina, SQ, Tibo, TZ and Will. I'll never forget this sprint.

Wham.

Footnotes

1. It's easy to try and read into a lot of drama whenever there's a departing leader, but I would chalk ~70% of them up to this fact alone. ↩

2. I do think we're in a slight phase change here. There's a lot of senior leadership hires being made from outside the company. I'm generally in favor of this, I think the company benefits a lot from infusing new external DNA. ↩

3. I get the sense that scaling the fastest growing consumer product ever tends to build a lot of muscle. ↩

4. Of course, we were also standing on the shoulders of giants. The CaaS team, core RL teams, human data, and general applied infra made this all possible. ↩

5. We kept it going too. ↩

6. We saw some big hires at Meta a few weeks ago. xAI launched Grok 4 which performs well on benchmarks. Mira and Ilya both have great talent. Maybe that will change things (the people are good). They have some catching up to do. ↩

Every startup founder knows about Geoffrey Moore's concept of "crossing the chasm"–that you have to change your marketing and sales approach as you gain marketshare fit a more conservative buyer. But most fail to internalize what crossing the chasm means when it comes to their product.

I recently stumbled upon Adam Mastroanni's post on strong-link problems, and realized that it's the perfect framework for thinking about this shift.

In essence, Adam says there are two types of problems: strong-link and weak-link problems. Strong-link problems are solved by looking for excellence in a single dimension. When building a startup or doing drug discovery, it doesn't matter how many times you are wrong, you just have to be right once. Weak-link problems are solved by eliminating failure in all dimensions–it's why the FDA puts standards on the internal temperature of your meat or why you might study the p95 latency of an endpoint.

When you have a strong-link problem, you increase variance because you benefit from outliers. You focus on upsides. When you have a weak-link problem, you decrease variance because outliers will destroy you. You focus on downsides.

Early stage startups tend to benefit primarily from solving problems of upside. Early adopters choose a startup because it provides some quantum of utility that no other product does. It doesn't really matter how much downside that startup might have, customers pick it because there is effectively no replacement.

But as a startup matures, new problems come into focus: uptime requirements, security and access controls, audit logging, cost + performance, etc etc. The downside problems.

Many startup teams fail to realize that as they gain marketshare, the problems of their customers shift. The early adopters who once valued variance are replaced by late adopters who care about minimizing risk.

Making this change can be really difficult–revenue stalls at 5-10m, product velocity falls off a cliff, churn is up. All because the new breed of customers care more about the downsides than the upsides.

This model also helps explain why founders from big companies often fail to get off the ground. They don't understand that the early phase of a startup is all about exploration. The downsides don't matter until they begin to find product market fit. The only things to do are actively ship and cut scope.

Balancing upsides and downsides

Where this gets really tricky when a company has matured but still needs to launch another product. Founders need to simultaneously balance the "production-grade" infrastructure needs of their existing customers while incubating the high-variance labs to launch the next big product.

Doing this well takes skill and practice. You can't just ignore your customers when they say "the product doesn't work". But you should still be taking new bets, even as a mature company.

At Segment, we'd think about balancing these needs via the McKinsey horizon's framework:

• 60% core (existing product)
• 30% emerging bets (products which would generate revenue in the next year)
• 10% new bets (more speculative bets)

We'd typically start new bets with a very small percentage of customers who were likely to pay a premium (e.g. only enterprise). They weren't asked to be built with rock-solid infrastructure from day one. It was only once they had some measure of product-market fit that they would start the transition.

There were times where we'd focus a lot more on downsides as well. After a particularly bad few months of uptime, we did a "reliability reset" to double down on improving our core data pipelines. We had some big security up-levels after a handful of scary incidents. But all of those came years down the line.

LLMs and the "upside" phase

The second reason this idea top-of-mind today is because I've been trying a lot of AI-powered products out there.

When it comes to the models themselves, my belief is that most models are still optimizing for the "upside" phase. They are impressive, but don't handle cases of nuanced judgement, adversarial inputs, or uncertainty well enough for a mature business to trust them entirely. Many models will crush various advanced reasoning evals, but you probably wouldn't trust them with a credit card.

The same goes for AI products. In a strange twist, most AI demos nail the "upside" phase, but that's where they get stuck: just a demo, not a product.

There are a handful of products which really manage to make the leap (Copilot, Cursor, Midjourney, etc). My belief is that these tools can cross the chasm primarily because they aren't flakey.

To get a toe-hold, the product needs to be amazing. But to get to mass adoption, it needs to just work.

---

As your product matures, it's worth asking every few months: does my customer care more about the upside or the downside?

If it's the latter, it might be time to shift focus.

Every few weeks I see someone comment on Hacker News: "sure, LLMs are great, but they really couldn't do my job". And I've been trying to square that opinion with all the impressive levels of output that I see everywhere else. What accounts for the difference in perspective between the two camps?

This debate has become top-of-mind for me again as I've been trying out a bunch of new AI coding assistants. I've been doing a lot of what Andrej Karpathy calls 'vibe coding' on various side projects:

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. [...] I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

Coding this way feels a bit like cheating. It's so easy to do, that I just start ignoring the code all together and focusing on the outputs. And it works well. Really well. I can generate full-blown webapps with relatively complex functionality.

Clearly LLMs are doing something right here? So why do we feel retiscent about turning over the keys entirely to an LLM in a production codebase?

Fundamentally, I think a lot of success or failure comes down to exactly how you as an engineer choose to augment yourself with LLMs. And in particular, how much of the task requires being a manager vs a software engineer.

The 'what' vs the 'how'

When I first started managing the engineering team at Segment, an engineering mentor gave me the following advice...

as a manager, it's your job to think about the what, not the how. ¹

The manager should be responsible for clearly describing the problem, setting the team goals, defining guardrails, and being specific about what 'good' looks like. And then the engineering team should be responsible for coming up with the actual tech for how to achieve those goals.

There are a few reasons for this...

1. it's difficult for someone in an engineering leadership position to come up with great technical solutions if they aren't deep in the codebase.
2. from a systems perspective, the individual engineers should have ownership over the codebase. if an engineer is getting paged by a system at 3am, they should be able to change that system.

But more generally, it's just an instance of principals and agents. The principals define the rules of the game and the goals, and then the agents are free to solve them however they see fit.

The tools are getting good enough that while using them, I've been feeling less like a software engineer and more like a manager. I'm specifying the requirements, and the model fills in the details.

I think this is the key to using LLMs well. You have to have some sense for where they shine and where they fall short. And you have to be okay with the fact that you are managing the LLM, not writing code.

The art of managing well

As I've gone down the rabbit-hole in my own side projects, there are a few things that stand out as making vibe coding successful. Tactically, I've been using Cursor with Sonnet 3.5 to build various sites, but I think they'd work in almost any context.

Be clear about what you want

The first, and maybe most obvious thing is that you have to be clear about the behavior you want to achieve. Instead of saying "build me a chat app", it's worth spending some extra time on the prompt to describe the pages and UI elements you want.

I've started writing down a spec doc ahead of doing any coding. I will typically scaffold a few different things just to give the LLM a place to get started:

• what framework I'm using (e.g. running npx create-next-app to give it some boilerplate)
• specs for the data structures I want (e.g. "create the following Typescript types with the following fields")
• what I want the API to look like (or pages for a frontend app)

In areas where I don't have great ideas (e.g. design), I'll give the agent a little bit more leash. I'll give it more general instructions like "add a layout button to the logout" and see what it comes up with. Often it finds a better path than I would have on my own.

Tighten your feedback loops to instantaneous

For all of my projects, having the ability to instantly reload the page is key. It means that I spend less time looking at the code the models are generating, and more time actually just looking at the output.

I'm typically running npm run dev in a terminal and then just reloading the page to test functionality. But asking the models to write and re-run unit tests also works.

While using Cursor, any changes which are applied will automatically go through a lint check, and the model is typically able to resolve them on its own. Having some automated step (like a CI/CD pipeline) that is cheap to run and check will get you a lot more mileage.

Start small, and iterate

Sonnet is remarkably good at following multi-part instructions, but I've still had the most success by starting small and iterating.

For example, if I'm building a webapp, I'll first ask to create the database types and methods. Then I'll ask it to add the API routes. Then I'll ask to add the frontend pages for it. Then I'll critique the styling.

Most of today's models don't nail a "one-shot" implementation. But if they have a starting point, they are much more likely to get it right.

You could probably do this in a different order, but I find working 'bottoms-up' tends to give fairly accurate results and catch errors as they happen.

Give the model a toe-hold

With Cursor + Sonnet in particular, I find that having a good 'toe-hold' makes all the difference. If there are some norms for things like "use shadcn components" or "use tailwind classes", the model is more likely to mirror these when generating new outputs.

Rather than starting with a totally blank canvas and asking the model to do everything, starting with a few opinions on basic styles will help a lot. Sonnet is quite good at matching what is already there.

Make failure cheap

I suspect that the reason LLMs work so well for vibe coding is that making mistakes is incredibly cheap. You aren't writing critical infrastructure or production code, you are just trying out ideas.

This creates a bit of a paradox though... most of the work that software engineers do today isn't try out ideas. It's writing production-grade code. Code that has to work, be debugged, and maintained for years to come.

To use LLMs effectively (today anyway), engineers need to understand the difference between:

• cheap use cases: scaffolding new boilerplate, writing unit tests, fixing small regressions, adding documentation, scripting one-off tasks
• expensive use cases: big refactoring, mission-critical APIs, core data models, database migrations

Note that this is a moving target! And more and more "expensive" tasks are becoming cheaper.

Dictating your requirements

Like Karpathy, I've found that dictating what I want really forces me to think more about the requirements. I was really skeptical about people building software by just recording their voices (isn't voice really lossy?).

But recently I became a new parent, and found a high premium on using my hands. I'm relying on voice a lot more often, for everything from "implement this database call" to "make these two buttons the same size". It works shockingly well, and I find myself relying more naturally on describing the what vs the how.

What's missing?

I painted a bit of a rosy view of how to use LLMs well, but there are a lot of things they won't do...

Image transfer – I haven't had luck uploading an image, and then asking the models attempt to replicate it in code. If this is what you are looking for, you'll have a much better time exporting some base CSS from Figma or describing what you want in your own words. Since there's an intermediate text step for most models, image -> code tends to be lossy.

Refactor on their own – typically LLMs will just spit out more and more code without considering how to consolidate functionality as part of one shared component. You have to explicitly nudge the model to simplify code and pull out pieces of shared functionality.

Sweating the details – My experience with LLMs is that they can implement many small steps in isolation (consider the security implications, improve memory performance, update the API so it's more idiomatic). But coordinating them all at the same time doesn't tend to work so well. It's hard to get a model to simultaneously focus on all of these areas at once. If there are particular features which really require a lot of performance critical work, I think we need to wait a bit for models to improve.

System design – Using a model is no substitute for good architectural decisions. You probably have a better sense of how the system should evolve than the model does. I wouldn't hand off these tasks to a model quite yet.

Implementing complex pieces of functionality – in my experience, most LLMs still lack the ability to think carefully about things like race conditions, advanced edge cases, and really high-performance code.

Understanding the system as a whole – context windows are increasing, but they really aren't enough to include the whole codebase. Cursor + Sonnet do extremely well at searching codebases for the relevant context.

Admittedly, this is a long list–and there are a lot of things here that seem like dealbreakers. But I think it's worth recognizing that a lot of these limitations will go away over time. Reasoning is improving, instruction-following is improving, and context windows are increasing.

The engineering divide

Back to the original question... why do some engineers love LLMs and others don't?

I think this is mostly accounted for by whether you care about what or how. For every engineer, there's some level of comfort with 'handing over the keys' to an agent... and that level depends a lot on what you are trying to get done.

If you don't know any frontend code, you are much more likely to lean on the LLM to produce something that 'looks good' even if it doesn't optimize for a refactor. If you don't know how to fix some random devops on a server, you are probably happy to run all the machine-generated bash you can get.

On the flip side, if you spend most of your time doing performance engineering and know everything there is to know about how Go does memory allocations, you'll probably be unsatisfied with an LLM that generates working (but maybe inefficient code).

If I were just starting out in software and giving advice to my younger self, I'd say there are a few skills that are really worth developing...

1. being able to clearly articulate what you want to get done. thinking more like a PM than a software engineer. understanding at any given time "what's the most important thing to build".
2. being able to architect systems in a way that they are flexible later on. it's easy to lock yourself into a poorer data model or a bad API with an LLM in the loop. if you think clearly about the system, you can use the LLM as a colleague. the outputs you get will be better as the system evolves, because you did some pre-work.
3. understanding how systems work. you get a lot more value from LLMs if you understand at least some of the underlying components and have intuition for how they fit together. in my experience, this subtly changes your ability to prompt and gets you much better outputs. I don't think this goes away even as reasoning + context windows improve.
4. build intuition for what's expensive vs cheap. we haven't begun to explore the capability overhang that exists with today's models. understanding their limits is one of the best things you can do as a software engineer.

As one parting thought... my hypothesis is that a large philosophical divide on using LLMs comes from the enjoyment engineers derive from writing code. Many of us (myself included) originally started coding because it seemed like a fun way to solve puzzles.

As 'solving puzzles' becomes the domain of machines, that can't be the main reason we still write code. Solve problems instead.

Footnotes

1. This was a time before 'founder mode', though I think much of this advice still holds. Obviously this philosophy is no substitute for deep inspection. As a leader, you must still be thinking critically about how the team is doing and diving deep to understand and critique the 'how'. ↩

Over the last few months, Baker and I have been digging in deep on Heat Pumps. I'm putting my explorations here on pause but wanted to write up everything we've learned over the last few months.

Heat pumps are unique in that they are a tool for fighting climate change, where we have the technology today. It's the same tech that we've been using in refrigerators and AC units for decades. Switching to heat pumps would reduce hundreds of MT of CO2 emissions per year. And yet, they are only present in 15% of US single-family homes.

Unlike more speculative areas of climate tech, adopting heat pumps en-masse is more a question of deployment. There are barriers with financing, the purchase journey, the large up-front install cost, and the lack of differentiated outcomes. I'll get to all of these down below.

Overall, it feels like a space which is ripe for disruption, which is why you see a lot of startup founders starting to investigate this space. Every step in the process today is broken, which means that there is a lot to improve.

Author's note: I'm not a grizzled heat pump or HVAC expert, so it's certainly possible I got some stuff wrong. What follows is the result of about six months of research. If you have a correction, please reach out.

Types of heat pumps

If you're totally new to the space: heat pumps are a high-efficiency, climate-friendly option to heat and cool your home. They run on pure electricity, and are 3-4x more efficient than existing electric options. They are one of our best tools in the fight against climate change, and should be deployed in every home in America.

Heat pumps consist of the same set of components...

An outdoor unit which either collects heat from the outdoors to be brought inside, or releases heat collected from indoors. It will typically have a fan to move air across a set of coils (metal) which conduct heat from the refrigerant. there are two primary styles of these: "barrel-style" which look more like a traditional AC unit and "box-style" which are the boxes you see on Heat Pumps, Hooray!.

An indoor unit (or indoor heads) which either pulls heat in from inside the home or disperses it out. think of it as functionally the same thing as the outdoor unit, but it sits inside your house and looks different based on how heat is distributed throughout the home (see below)

Refrigerant lines which exchange heat between the indoors and outdoors. these are metal tubes that carry a substance known as refrigerant which has an extremely low boiling point.

A compressor which is used to modulate pressure of the refrigerant

A reversing-valve which changes the directional flow of refrigerant to either heat or cool your home. when you adjust the thermostat 'mode', it is effectively changing the direction of the reversing-valve.

Sometimes: heat strips / resistive heating: in very cold climates below -5 degrees F, heat pump capacity will go down to the point where it may have trouble meeting the heating load. To combat this, certain heat pumps ship with resistive elements (imagine a toaster oven that generates heat by running through a wire).

Additionally, there are a few other 'flavors' of heat pumps depending on your home setup, but all of these consist of the same core parts.

Heat pump flavors: how heat is distributed

If you want to install a heat pump in your home, you have several options for how that process works.

Option 1: Central-ducted - most US homes have duct-work to move heat (and air!) throughout the house. In these systems, there's a central set of tubes which run air throughout the house, kind of like blood vessels will carry blood throughout the body. Centrally ducted heat pumps are the most popular, since about 60% of US homes already have ducts. If you have ducts, using that ductwork is typically the cheapest and most effective way to distribute heat.

Option 2: Mini-split aka ductless - for homes without duct-work, or cases where you want to condition a specific room (e.g. think of a garage), you can use a mini-split unit. This works in the same way as the central units, but instead of hiding the indoor unit in a basement or closet, they are instead mounted visibly on the walls. Refrigerant lines will run directly from an outdoor unit to an indoor one. Because these can't heat the whole home, they are typically smaller. In some cases, you can route refrigerant to multiple 'heads' inside the home.

Option 3: Mono-block or 'packaged' - there's one other type of heat pump which is generally less popular because it's not as flexible or performant for many housing configurations, the 'mono-block' unit. These combine indoor and outdoor units into a single form factor that sits outside the house, and then moves air inside. It benefits from simplicity of install (no refrigerant lines), but won't be nearly as efficient as a split system and has a bigger outdoor footprint.

Option 4: Air-to-water - for households who have radiant heating, heat pumps (or heat pump water heaters) can exchange heat with water. This is less popular in the US, but a popular way to heat in Europe.

Heat pump flavors: heating sources

In addition to how heat is distributed inside, there are also differences in how heat pumps.

Air-source heat pumps are the most common heat pump variety, that you see everywhere. These exchange heat with the outside air, just like an AC Unit.

Dual-fuel - a dual fuel heat pump setup is basically the same as centrally ducted, but it just means that you don't replace your existing furnace, and have the heat pump installed alongside it. This is a popular route for homeowners looking to gradually transition. With dual-fuel, the heat pump and the gas furnace can never run simultaneously, so it won't save much money on heating. But it can be useful for gradually moving to electric heating.

Air-to-ground (aka ground-source) - in extreme climates (think the northeast), heat pump heating and cooling both become lower efficiency. pulling heat out of the very cold air is hard to do, as is pushing heat into hot humid days. it turns out that if you drill down ~30-40 feet, the soil temperature will remain more or less constant throughout the year. this gives a heat pump much better efficiency.

The market

Today's market participants are split into a few different layers: consumers, contractors and technicians, wholesalers, and manufacturers.

Let's start with consumers. Furnace equipment typically has a lifetime of 20 years, while AC equipment has a lifetime of more like 15 years. When your furnace or AC dies (or perhaps you want to get an AC for the first time), you have a magical window of opportunity to upgrade to a heat pump.

Today, most consumers will either call the number on the side of the unit left by the original installer (an ingenious and basically zero-cost lead-flow technique), or will search on Yelp, Angie's List, or Google to find a contractor. Typically these lead-flow businesses will get ~$60-80 per lead.

Typically the breakdown is...

• 2-4k equipment cost (pure hardware)
• 4-15k labor cost (removing old equipment, running refrigerant lines, install)
• 10-20k (maybe) duct upgrades, panel upgrades

That labor cost has a wide variance. It's mostly a function of supply and demand. In areas where many people have AC, it's relatively easy to retrofit a heat pump and it happens all the time

Most of the time, heat pump upgrades will be done under duress. About 80% of furnace replacements happen during a "break-fix" scenario, where the existing equipment has stopped working and new equipment needs to be installed. It's much more difficult to ask for a bigger replacement (both in terms of time and cost) when the heating is out and your family is cold! Homeowners will call a contractor (also referred to as an HVAC technician) who comes in to investigate the issue.

Contracting firms are typically both small and fragmented. There are 300,000 HVAC technicians in the US, but 145,000 companies! That means many of them are either sole proprietors, or just a few individuals with a truck.

It's a good business to be in, generally speaking. Individual shops may be making anywhere from $500k to $10m per year depending on the size of operations. The mean hourly wage for a technician is $26/hour.

Most contractors that we've talked with indicate that there's a severe labor shortage. Contractors have to be experts at system design, understanding heating and cooling loads, some electrical work, pressure variations, and construction. It’s a skilled trade that takes a long time to master.

New contractors typically learn via the apprenticeship model, but in the last few years, fewer individuals have entered these trades. In some cases, contractors aren't even taking new jobs for months. Demand for contractors spikes twice per year; the first hot day in summer, and the first cold day of the winter.

Over the last few years, there's been an increase in private equity roll-up vehicles buying up these firms. Many of them are trying to centralize and bring technology to key functions (scheduling, financing, invoicing) and allow the technicians to spend more time on their specialized work.

Contractors have not historically adopted a lot of software, though there are companies trying to serve them (ServiceTitan).

Finally there are the manufacturers. These are the only large players in the market, they are a handful of publicly traded companies, like Carrier, Trane, Lennox, Mitsubishi and Daikin. Each of them bring in $1b+ in hardware, and typically maintain a 20% margin.

Many technicians have agreements directly with wholesalers or the manufacturer. As a result, it's tough to buy a heat pump unit even if you really wanted to. Similar to the way car dealerships worked 20 years ago, you have to go through the dealer (aka the contractor or wholesaler) who is a licensed retailer for the manufacturer.

These manufacturers are slightly disincentivized from pushing heat pump adoption for two reasons: 1) many of them also sell furnaces and A/C units, and have whole divisions responsible for those P&L statements 2) they want to maintain a margin on equipment. Rather than provide equipment that is higher-cost but easier to install, they will try and ship the lowest possible cost, and then pass the labor costs on to the end consumer.

There are 77 million single-family homes in the US, and roughly 3 million furnace or AC units installed per year.

Installing a heat pump

Okay, so what's a heat pump install look like? There's a few different pieces..

On-site visit: the purpose of this is two-fold. One part of it is to actually assess the quote and ensure that there aren't any issues. The second is to help sell the homeowner on the desired solution. As part of this on-site visit, the contractor will want to do some initial system sizing to determine what sort of system you need.

In repair cases, the first visit ends up being the most important. When a technician says that the existing equipment is and needs to be replaced, they set the framing for the entire journey.

The output of the system design should include a load sizing report for the home. It should indicate how many BTUs you need to heat your home in the winter, and how many tons of cooling you need in the summer.

As it turns out, load sizing is a surprisingly tricky problem to get right. Design will depend on your room configuration, insulation, and even position of the home relative to the sun. The “gold standard” way to do this is by running a Manual J calculation on the home, and doing a blower door test which assesses the actual leakiness of the home.

Many contractors will skip this step if replacing the existing equipment with a newer version of the same equipment. This is another reason that contractors will prefer to stick with replacing existing systems vs swapping out for a heat pump.

There's a few things that will blow up a quote...

• new ductwork - if you live in a climate where it doesn't get too hot, you might have small ductwork. The ducts don't need to be very big because gas furnaces heat at a high temperature (140F). Heat pumps heat at a much lower temperature (100-110F), which means they need to move more volume of air to work. Getting to this increased volume requires increasing the duct size, which tends to add 10-20k to the up-front cost. In practice, if existing ductwork is insufficient, the installer will instead recommend a ductless system, which also tends to be more expensive (remember, if you have ducts, they are the cheapest way to deliver heat).
• panel upgrade / and new 240v outlets - older homes were wired in a time before we had all these electric appliances (solar panels, evs, etc). A heat pump might require upgrading your panel to accommodate increased amperage. Doing a panel upgrade isn't terribly expensive, but it might add 2-3k to rewire the home. It also increases the end-to-end time for the job, as the utility may have to upgrade service to the home.
• new insulation - insulating a home is expensive, but probably the thing you should do before making any other upgrades. in most cases, insulation will be the #1 thing you can do to make your home more efficient.

Install: a heat pump should be able to be installed in about a day. The technicians will have to remove any old units, and run any new refrigerant lines (aka drilling holes in the walls of your home). If you have an existing AC, the technicians can likely re-use the refrigerant lines already in your walls. The technicians will install the outdoor unit by placing it on a concrete slab and hooking it up to the electrical outlets, as well as the different indoor units. Often, technicians will recommend installing new thermostats as part of this process. Finally, they'll need to "charge" the refrigerants, filling the lines with R-410A (or another refrigerant).

Follow-up / maintenance: most installers offer a 1-year warranty on any work that they do. Callbacks with heat pumps are most frequently due to leaking refrigerant (which also is bad from a climate-perspective, more on that below).

Utilities

There's one other player in this market who we didn't talk about yet: utilities and government funding.

The government has set aside budgets to help consumers drive the adoption of green technology. Typically these budgets are set at the federal level, and then flow down to the 'state energy office'. Each state energy office then works with local utilities (ConEd, PG&E) or NGOs (BayRen) to provide programs for consumers to adopt high-efficiency devices.

While the large budget numbers are set at the federal level, actually dispersing that money is very much a local issue.

I've personally found the way utilities work to be a hard thing to reason about, but in general, here's how people have described their incentives to me...

• utilities charge each consumer a 'fixed service fee' which is something like $20/mo. this costs them basically nothing to service (think of it like the gym membership)
• utilities generally want to decrease peak demand on their systems, while simultaneously keeping customers connected and paying the service fee. the higher the demand, the more expensive it is for a utility to deliver that energy, so utilities will minimize spike and lower-margin "peak load"
• utilities are 'procurement engines', they are very good at funding new capital improvements, if they can show a return on those projects. they tend to build little in-house
• electric utilities will incentivize switching to all-electric. gas utilities will incentivize high-efficiency devices. in some cases, utilities which do both will figure out the cost to serve individual homes, and try and switch load to whatever method is cheapest to serve.

Despite all this, the software and data utilities provide is an area that is ripe for startups to dig into. It's also a slog, the most well-known company here is Opower, but there aren't many others willing to brave the high-touch sales cycle.

Incentives and rebates

A key result of that government funding is that utilities often offer $2k-3k per heat pump install to bring higher-efficiency devices into the home. With the Inflation Reduction Act this number has expanded dramatically for low and middle income families.

There's a lot of problems that exist with these incentives...

Discovery - before they can apply for incentives, homeowners have to know about them! The unfortunate thing is that these incentives are spread across many different sites. In many cases, incentives are "good until the money runs out", which means a consumer might be expecting more money back.

Eligibility - woof, incentive eligibility is a complex thing. Often it depends on a multitude of factors: the exact unit which was installed, the sizing vs existing equipment, the household income, and more. It is difficult for homeowners and contractors alike to wade through to know how much money they are eligible for.

Application - applying for rebates requires an annoying amount of paperwork. In cases of things like EV chargers, consumers can fill out the applications themselves. For a heat pump, it will probably require 2-3 hours of contractor time... which is why many contractors just don't bother!

Financing - the biggest incentives have historically come in the form of tax credits that you can claim off your tax bill at the end of the year. This means that the consumer has to 'float' the cost of the install up-front, until they can claim the rebate months later. More progressive utilities will partner with banks to provide interest-free loans, but there's still a big gap here.

Heat pump economics (am I getting ripped off?)

You might be wondering how money flows as part of this process...

• the wholesalers will typically charge 3-5k per heat pump unit. Higher efficiency units will be more expensive (6-8k). The manufacturer will try and maintain a 30% margin, with higher-efficiency units having a greater margin.
• the installers will pass that cost onto the consumer, and then typically double the cost of the unit for labor. For a 5k system, there will be minimum 5k in labor costs. In certain geos with a more competitive labor market (SF, Seattle), we've even seen labor account for 70-90% of the bill.
• the average consumer with a high-efficiency gas furnace will save something like ~$200/year on fuel costs. the consumers using more expensive forms of energy (e.g. fuel oil) will save closer to $2,000 per year.
• contractors will usually include some buffer room

The net-result is that in a heat-pump popular market with many AC units and mild climate (think Austin, TX), the cost will be something like $8-10k to switch to a heat pump. In a market where AC usage is much rarer (SF), or the climate is more extreme (e.g. Seattle, Boston), a heat pump install might run you $20k.

A word on Refrigerants

While I'm generally bullish on heat pumps and convinced that we must adopt them to prevent climate change, today's heat pumps aren't all sunshine and rainbows. There's one big problem with rolling them out: refrigerants.

Remember, refrigerants are substances which transfer heat from outside in (or vice versa). Refrigerants have a very low boiling point (think -40 degrees F). The low boiling point makes it easy to change the pressure to adjust whether a refrigerant is liquid or gas, which is good for heating transfer, but can create problems elsewhere.

Notably, many refrigerants have a high global-warming-potential (GWP). This number is measured relative to CO2 (which has a GWP of 1), and expresses how much worse a molecule of refrigerant is when it comes to global warming.

There have been thousands of refrigerants categorized over time. They are typically numbered by R-{Ccount - 1}{Hcount + 1}{Fcount} when viewed as pure chains, but when they are combined the numbering scheme changes to be more sequential.

Today's most popular refrigerant is R-410A. It is a mixture of CHF₂CF₃ and CH₂F₂ has a GWP of 1,400. (It should be noted that even with some refrigerant leakage, we still see that heat pumps come out ahead when it comes to GWP)

Over time, we've been steadily outlawing high global-warming-potential refrigerants (remember CFCs and HFCs?). And in 2024, the industry is gearing up to phase out R-410A.

The one problem is that there aren't a lot of other good alternatives that exist. Refrigerants fall into two classes...

• flammable: these are refrigerants like Propane (R-290) or Isobutane. We can't roll them out without updating a bunch of building codes. As an aside, it's sort of crazy to me that we decide to limit propane in building codes, when we pipe natural gas into homes all the time to literally light it on fire.
• high-pressure: among the leading non-flammable refrigerants is CO2. It's not flammable (good!) has a GWP of 1 (also good!) but requires a lot more pressure to turn from vapor to liquid (bad!). This means more expensive compressors.

Finding new refrigerants is an active area of research, and will probably require a sea change. Most of the big manufacturers seem to be heavily investigating this area of research.

Buckets of problems

Consumer awareness - most consumers don't know (or care much) about how they get their heat. Despite being available for many years, heat pumps have only recently entered the popular discourse. Unlike solar or EVs, heat pumps are pretty much invisible, and it's not yet a status symbol in any dimension.

Urgency of problem - most HVAC systems are replaced when the old system has broken. Consumers typically don't have a ton of appetite to do a lengthy heat pump install when they can't keep their home warm! On the flip side, when an HVAC system is working smoothly, consumers have little desire to switch it out and add risk to the process.

Contractor incentives - contractors typically want to avoid any sort of callback. The easiest way to do this is to replace the existing equipment. It minimizes risk, and additional labor hours. You don't have to worry about running into issues which might lead to a drastically higher quote (duct sizing or panel upgrades).

Regional markets - one reason HVAC is tricky for startups to tackle is that it's a highly fragmented, very regional market. The pitch for consumers is actually different depending on geo. In SF or Seattle, heat pumps might be viewed as 'adding an AC for the first time'. In the southeast, it's a way of reducing your electricity bill by 2-3x. In the northeast, heat pumps are best positioned to replace expensive sources of fuel like fuel oil.

Areas of opportunity

Financing. Solar has a rich set of options for financing the big up-front cost. These largely do not exist with heat pumps today (though local utilities may sometimes run 0% APR loan programs). Applying for rebates and incentives is an arduous process, and often still requires that you spend money up-front.

System design. Designing a system for a home is tricky, and often involves a visit to the home. This is both annoying for consumers, and costs the contractor as it requires an extra 2-3h of transit time to prepare a quote that they may not even be paid for! The holy grail here would be working in the same way that solar does: going directly from address -> design. We've built a lot of this modeling into Heat Pumps, Hooray!, but there's still internals of the system which require more work to surface (ductwork, panel, refrigerant lines). There are some companies focused exclusively on system design (CoolCalc, Arch, Conduit).

New heat pumps and refrigerants. There's a number of startups trying to build new heat pumps: Gradient, Stow, Dandelion Energy, and others. A system like Gradient's window unit doesn't require any sort of contractor install and works for multi-family apartment buildings. Dandelion takes a differentiated approach by focusing on ground-source heat pumps, which are more difficult to purchase.

Purchase journey. Right now, it's fairly difficult to get a heat pump even if you are highly motivated and not budget constrained. There's a number of companies trying to help the purchase journey: Woltair in Poland, Lun in the EU. Each of them are working to make buying a heat pump more similar to buying a dishwasher or washer/dryer online.

Additionally there are some other pathways that folks are trying to explore that I'm a little less bullish on, but I thought are worth mentioning here.

Luxury products? A number of folks are investigating whether heat pumps might become a luxury product. I'm personally skeptical here. Heating and cooling are a lot less tangible than an EV or having solar on your roof. That said, if you could find a way to turn a heat pump into a futuristic technological device or a high-status symbol, I think you'd have a lot of luck. Quilt is one such company, applying high industrial design to an antiquated market. For products like an induction stove where you use it daily, I think this approach can work much better (a la Impulse).

Whole-home electrification. It's far more common to upgrade a single component at a time. But there are a few companies trying to do whole-home electrification by providing better hardware and software: Lunar Energy, Elephant Energy.

Thanks

First and foremost, I wanted to thank Baker for being an incredible thought partner throughout all of this and building something really cool and useful.

Additionally, there have been a handful of folks we've had conversations with who fundamentally changed my understanding of the Heat Pump market: Shayle (if you have not checked out his podcast, you owe it to yourself to do so), Andy, and Gregory from EIP, Sam and Josh from Innovation Endeavors, Seth and Alex from 50y, and Vibhor and David from Coatue, Erika Reinhardt

Thank you demo crew: Kevin Niparko and Lauren Reeder for keeping us going with feedback and encouragement throughout.

Everybody has that one friend who's always trying to hack their productivity. For me, that friend is Andy.

Andy is the type of guy who obsessesively logs his meals and meticulously tracks his sleep. He's experimented with keto and intermittent fasting. He loves his Eight Sleep mattress and Oura Ring. And every week, Andy has a new note-taking system.

One day, Andy posted about Roam. I was at an exploratory phase in life and my curiosity was piqued, so I decided to check it out.

I have to say I was pretty skeptical going in–new note-taking apps seem to become 'in vogue' and then fade on a predictable cycle.

But Roam (and now Obsidian) changed my mind. They have completely altered the way I go about my day.

If you're concerned that this will be a puff piece, don't be. This isn't a tools-for-thought fanboy post.

Instead, I'd like to dig into a handful of the little design decisions that make Roam a really novel product.

This is important because we've had the computing power, network stack, and all the software we'd need to build these tools for thought for decades. It's all just files, markdown, and a basic UI.

It's not entirely clear to me why it took so long for us to build these sorts of tools. But what is clear is that we need to do more of it (more on that later).

Judging a book by its cover

I took too long to give Roam a shot because the UI looks... kind of ugly?

Odd typography, uneven spacing, bulletpoints and brackets everywhere. What even is this tool?

But in many ways, Roam is actually quite well-designed. Just not designed to be looked at.

Roam is designed to be engaged with. Each part of the interface silently nudging you to write a little more, and put down a few more connections.

That's no accident. There's a ton of small features that add up to a transformational experience.

Time-based vs subject-based

Most note-taking tools either focus on being time-based (a journal that has one new entry per day) or subject-based (let me create a new Notion page for each project).

Critically, you have to choose which approach you prefer! Most note-taking apps require that you buy into one approach or the other... but you can't do both!

Here's the problem though: I'll often have uncategorized musings that pop up from day-to-day across all variety of subject matter (e.g. I read an interesting blog post on culture, or a friend told me about the obesity epidemic). At the same time, I'll have highly structured 'streams' of projects (what are the next steps on the Heat Pump calculator I'm building?).

With most notetaking apps, before I start writing anything, I have to figure out where my writing should go! Sometimes I lose the thought before I even start a new note.

Roam's default view gives me a new time-based note every single day. It's the default 'homepage' where I'll start cataloging my day.

Down below, yesterday's note is right there. I don't even have to 'reach for the note' to see what I was doing yesterday. It's already right there in front of me.

This does two things:

1. It's easy to see what I was doing on a particular date (I can jump straight to the February 1st, 2022 note)
2. It's easy for me to scroll back in time to get context on what I was just doing recently.

In short, it's the best of both worlds: I can still jump to a particular day, and it feels like it's part of a long-running note. But I can also jump into an individual idea or topic as I see fit.

The nice thing about these subject-based notes is that they feel very free. I don't have to worry about losing them because I can search for them, or find them temporally.

The 'blank page' problem

Most note-taking apps don't do anything to help you start taking a note. Here's what the Apple Notes interface looks like.

It's pretty... bare. There's not a lot here that's encourage me to write.

Roam does a few very clever things to solve this. I already touched on the 'daily notes', but every day there's a new note which is prompting me to start writing. [1]

What's more, any time you write a line and hit 'enter', a new line appears. But that new line isn't so daunting that it's totally free form and blank. Instead, a helpful bullet has appeared waiting for your input.

I used to hate the bullets, until I realized how much new information I was adding because of them.

Something about bulleted writing feels less scary, and more information dense. It encourages work-in-progress thoughts that can be edited later.

Losing context

Another big issue I have with most tools (note-taking, browsers, etc) is that I tend to perform an action that makes me lose context about what I was doing in the first place.

A good example is when I'm going to look up someone's contact info on LinkedIn. I'd guess that about 30% of the time, I'm immediately distracted by the feed and forget for a moment why I'm there. [2]

Roam solves that by letting you open notes "in-context". If you shift+click a given page that you've linked to, it will open up in the 'sidepane'.

What's great about this is that you can edit either pane, and continue to keep the flow of your thoughts. There's no losing flow state as you switch tabs.

Progress

Another area most note-taking tools miss out on is that they don't give you any feeling of 'progress'. There's not a ton of incentive to add more to what you already have.

Contrast that to Roam: there's a view that shows you every single connection you've made. If you've seen any marketing material of the tool, you've probably seen it. Here's my Obsidian graph:

Now, the graph is basically useless. I never look at it on a daily basis at all. But it does give me one thing: a sense of progress.

The more I write, the more intricate and exciting my graph looks. It feels like I'm getting smarter just by writing. Every few months, I can check back in with it.

Connections in Roam and Obsidian aren't just more visible, it's easier to make them too.

Instead of a bunch of nested sub-menus and button presses, it's 4-5 keystrokes (double bracket, some lines of the connection you'd like to make, enter).

Connections are useful in a second way: they make me feel like I'm doing "behavior-driven development".

Instead of going through 2-3 step workflow to create a new note and typing it out, I'll start my day by creating the stubs of all the writing I'd like to do (right in-line of what I'm doing), and then fill them in over the course of the day.

UI makes the difference

I'd like to close with a broader thought around why any of these little UI patterns matter.

Think about text editors writ large. They have existed the dawn of computing. Vi was created 46 years ago. But up until the last few years, these sorts of 'networked tools for thought' had never existed.

What was the limiting factor? Could we have built these tools in the past?

Absolutely!

We weren't limited by computation speed, or size of data. The new "innovation" here is just a curated set of good ideas for interacting with text. It could have happened at literally any time in the age of the personal computer... and it happened today rather than 20 years ago.

Right now, we're on the edge of incredible capabilities that exist with AI: GPT-3, Dall-e 2, Stable Diffusion, etc. There's a lot of research going into these fundamental capabilities (as there should be).

Where I think there's a ton of whitespace is in how we interact with and leverage these tools. We need the layer that sits on top of AI to really unlock the true potential of the tech.

I'm happy to see a number of startups pop up in this space: Everyprompt (disclosure: investor), PlaygroundAI, Midjourney, Lex and more. But it's time for even more.

The future won't come from people typing into the GPT-3 textarea box. It won't from "bolting AI onto an existing product".

The big paradigm shifts will be the ones that design new AI-native interfaces. Those are the tools I'm excited to use.

---

[1]: Dropbox Paper does this as well [2]: My friend Jamie Wong has created dedistract to deal with this problem

---

Thanks to Peter Reinhardt and Lauren Reeder for giving feedback on this post.

A few weeks ago, I had the incredible experience touring the Quaise facilities at Oak Ridge National Laboratory. Unlike other lab tours I've done, the folks at Quaise were actually so kind as to run their machine end-to-end. Thanks to a $30 webcam (that sadly malfunctioned due to high heat in the process), I could watch the whole thing before my eyes.

Disclosure #1: I am a small-time investor in Quaise. I am biased, but what they are doing is incredibly cool.

Disclosure #2: I am an armchair physicist at best. Some of these descriptions may be a little butchered.

What is Quaise?

Historically, geothermal has met less than 0.1% of the US energy needs. And yet, the total amount of thermal energy stored in the earth's mantle is massive, it's over two billion times our annual energy consumption! In fact, Eli Dourado estimates that there is 23,800x the amount of energy in the earth's crust as from coal, oil, gas, and methane combined.

Quaise is a new startup out of MIT which is trying to unlock that extra energy. The goal is to produce cheap, clean (and practically limitless) geothermal electricity.

The tech is still early, but incredibly promising. I think we'll start seeing geothermal generation begin in earnest in the next decade.

How does Geothermal work?

If you haven't spent a lot of time thinking about geothermal, here's the easiest way to think about it:

1. we drill two holes, one for cold water, one for hot water down to an ambient temperature of about ~400 degrees C (enough for water to become supercritical), and we connect them via fissuring/fracking [1].
2. we fill the holes with water (or some other working fluid) and create a closed loop
3. we pump water from the surface down the cold borehole
4. the water absorbs heat as it pushes towards the hot borehole
5. supercritical water rises as steam up the hot borehole, spinning a turbine and generating clean electricity

This process is known as superhot rock geothermal, and it could be one of our best sources of clean electricity.

There are a handful of (mostly volcanic) places where temperatures near the surface are quite high and you only need to go a few kilometers deep: Iceland, Italy, and New Zealand to name a few. But these are very limited in number.

Everywhere else, we need to go deep. Very deep. Deeper-than-the-Mariana-trench deep.

As you might guess, drilling this deep gets really expensive. Most oil & gas drilling rigs use mechanical drill bits to drill down 1-3km. The deepest hole ever bored was the Kola Borehole dug by the Russians, and it took 10+ years to drill down to 12km depth.

For widespread deployment of super-hot geothermal energy, we need to drill to a depth closer to 10km, typically going through crystalline basement rock. This would be cost-prohibitive using traditional techniques from the oil and gas industry. Most of your time is spent pulling out broken mechanical drill-bits and replacing them.

The more we can efficiently drill low-cost, super-deep holes, the more potential sites there are for geothermal. That's where Quaise comes in.

Quaise: throwing away the drill-bit

Instead of having to constantly repair mechanical drill bits working at high temperatures and pressure, Quaise hopes to provide low-cost drilling to 10km depths via a high energy milimeter-wave.

You can think of this as a high-powered energy beam that will melt and vaporize rock (even at great depths). The plan is to then blow the vapor up to the surface using pumped gases.

The beauty of this approach is that it can all be done using energy generation from Earth's surface.

If you'd like to learn more about the mm-wave approach directly from the source, I recommend checking out Paul Woskov's 2015 talk "Into the Bedrock by Full Bore Millimeter-Waves".

Oak Ridge National Laboratory

I arrived Monday night at Knoxville airport, grabbed one of the last rental cars, and then drove from Knoxville to Oak Ridge. After a late-night McDonald's and check-in to the Holiday Inn Express, I woke up and headed out to Oak Ridge National Labs.

Why Oak Ridge?

One reason is that Quaise raised money from ARPA-E and the DOE to demonstrate a live drilling test (more on the milestones below).

The other reason is that ORNL is also one of the few places in the US that has working Gyrotrons. These are high-powered devices that basically drive a stream of resonant electrons. They've been used extensively with fusion research as a way of heating hydrogen into a plasma, and as part of non-lethal weapons research.

Architecture

Quaise's architecture consists of a few parts...

1. the Gyrotron generates a high-energy mm-wave
2. the beam travels many kilometers along a waveguide
3. the guide hits rock which gets it up to temperatures where the rock vaporizes
4. injected gas blows the vapor out of the hole to the surface

The demo we saw consisted of three of these pieces with a ~40ft waveguide.

The Gyrotron

The gyrotron is the device that's responsible for generating the mm-wave energy beam. There's a set of transformers which create a very large voltage differential (80kV in the machine we saw, but it could be up to 1MW) that then drive dc current through a filament. The filament emits electrons which are then focused via a series of electromagnets.

The moving electrons in a magnetic field will generate electromagnetic waves at approximately 100ghz or so. The electrons themselves become coherent due to resonant standing waves in the magnetic cavity (sort of like an invisible laser beam).

Here's a picture of the Gyrotron. Note the three electromagnet bands around it, and the cooling tubes at the bottom. The wave will travel vertically up the Gyrotron. I'd guess this one was about 8ft tall or so.

The voltage is supplied by giant power supplies sitting nearby...

Historically there hasn't been a very large market for Gyrotrons, on the order of tens per year are produced, and each one costs something like 700k-2.5m. The kind Quaise are using today get about 30-35% efficiency on output, but the Quaise team guessed that they could get up to something like 60% power efficiency if they can switch to superconducting magnets.

The Waveguide

Once the energy beam has started from the Gyrotron, it needs to be directed to the borehole. I got the impression that this is a relatively well-understood idea in the lab, but a non-trivial problem drilling at depth. After all, how do you send an energy beam down tens of kilometers into the ground?

Quaise is using 'corrugated' waveguides (see the little ridges in the guide). This helps avoid electric field buildup on the walls of the wave guides. Today's wave guide costs about $1,000/m, which is incredibly expensive. The good news is that these waveguides can be re-used and can pretty easily 'reflect' the waves themselves around corners.

The wave guide will also act as the conduit for the gas, pumping it down into the hole so that the rock vapor can rise to the surface.

The window

Finally there's a window at the end to ensure that the mm-wave can drill into the rock, but that rock can't come back up the tube.

These window are tricky in that they 1) have to let the mm-wave pass through them and 2) have to withstand very high pressures and temperature to avoid damaging any part of the gyrotron with reflected energy or arcing from the plasma.

In Action

The Quaise team were kind enough to test the product end-to-end.

They started by locking up the room. In order to test, multiple people had to unlock their keys from the lockbox. When the team engaged the power supply, you could hear a noticeable "thunk" from the machinery next door.

On the lefthand side (next to Tim) you can see the power controls for the Gyrotron. On the right is the system monitoring, manned by Matthew.

The upper two units you see are to protect against any arcing from the plasma. The minute that happens, these will cut the power and the current flow to avoid damaging equipment.

Here's a closer look at the metrics being monitored:

The most important metrics to watch here are the forward power and rock temperature.

Here's a shot of the first test run with the system fully engaged. On the right you can see the webcam inside the drum. The left-hand monitor is showing off an outside high-speed camera for diagnostics, as well as a bunch of labview charts inspecting the input voltage, forward power, and temperatures of the rock.

We tried 3 attempts. In each one, the power would get to about 12kw, and then we'd have some sort of arc which would kick in and cut the power. [2]

Milestones

Quaise views their milestones in terms of width:depth ratio. Most of the milestones are trying to prove out that the technology is actually able to reliably drill a hole, using nothing more than electricity.

Vaporized hole

Today, Quaise is able to melt rock. The next goal is to fully vaporize a core sample all the way through. You can see the following discarded samples from previous attempts. Each one is about the size of a dinner plate and a few inches thick.

The white-ish surrounding is concrete which is poured to ensure the sample holds its shape. The muted gray is the crystalline form of the rock (Basalt). The shiny pieces are rock in its amorphous form, after it has rapidly cooled and doesn't have time to crystallize.

The next step is to try and apply more pressure (something like 70psi) to see if that will help.

1:10

This is the scale that will happen in the lab. Quaise engineers will keep the gyrotron stationary, and 'feed' rock up into it at a constant distance. The goal will be to drill about 10cm worth of rock.

1:100

Once the vaporization is working in the lab, it's time to move outside.

Right outside the lab, there's a 40ft deep well, about 10in across. The end goal of the ARPA-E funding is to fill the well with rocks and drill all the way to the bottom with nothing more than electricity and a purge gas.

To do this, the Quaise team will keep the Gyrotrons in their main building, but run the waveguide through a separate building and then out to the well site.

1:1000

Once the above milestones are complete, it's time to actually test at a real site. The Quaise team are looking at sites in NM and CO, where there's plenty of crystallized basalt available to test with.

Interesting Problems

Mode

One problem with using old Gyrotrons is that the mode frequency has some skew. What that means is that there are hot-spots in the area where drilling happens, rather than a focused energy beam that is able to channel more of the power directly from the Gyrotron to the rock.

You can see this in the above picture on the right-hand screen. Instead of having a 'single focused beam', there are 4 different hot spots. In order to achieve maximal power output, the team will have to figure out how to consolidate these frequency modes.

Containing plasma

Modeling plasma is notoriously difficult.

Generally speaking, this is a relatively cold plasma (only around 3,000 deg C). It should work sort of like a candle. There's heat which is applied to the rock. The rock starts melting and turns into a liquid. The liquid starts turning into plasma and vapor.

The trouble though is that plasma in practice tends to be very difficult to model and maintain. If not kept as a thin layer, the plasma will tend to just suck up all energy that is applied to it.

Additionally, the plasma has a tendency to 'arc', sort of like lightning where it will fly back up into the waveguide to follow the stronger electric field coming from the Gyrotron. The arc protectors immediately cut the current when this happens, but it's currently an unsolved problem.

Window material

The window which keeps unwanted particles coming up the waveguide have a lot of requirements. It needs to be incredibly strong to resist the pressure, heat, and plasma that are coming up to it. It also need to be made of a material that won't interfere with the wave.

Today, the team is using a mixture of quartz and sapphire windows. There's some talk of using a pure diamond plate... but doing so would easily cost hundreds of thousands of dollars.

Reflective substances

I hadn't really thought about this before talking , but hitting reflective substances can be really tricky. If the substance is too reflective, the energy won't be absorbed, and will instead send the energy back up the tube! It's the opposite of what we want.

Different types of substances also behave differently when exposed to high-energy mm-waves. Limestone, for example, has a tendency to crumble, and won't provide a consistent vaporization.

There's a lot more work to be done when it comes to testing out how various substances behave.

Hole siding

The hope is that as the Gyrotron bores the hole, it will begin to "vitrify" the sides of the borehole, and they turn to glass. These conditions haven't been fully tested as yet, and there's some question of whether the borehole will need additional pipes along the walls of the rock.

Better with pressure?

As the waveguide gets deeper and deeper into the ground, there's some thinking that the additional heat and pressure will actually make it easier to drill into the rock. I get the impression that we don't know a ton about the conditions that deep in the earth.

Tailwinds and thanks

If it isn't clear already, Quaise is doing incredible work. I'm extremely bullish on their ability to make widespread geothermal a reality. There's a few other tailwinds...

• regulatory ease: we're already very used to drilling holes in the ground, thanks to oil & gas. it's a very straightforward regulatory pathway
• abundant land: most of the western US has sufficient ground temperatures and crystalline rock for Quaise to work (see following chart). specialized sites aren't really required
• falling cost of electricity: combined with the falling cost of solar, Quaise's drills will become cheaper and cheaper to power as the cost of electricity falls
• demand for renewable baseload power: there's increasing demand to provide renewable 'baseload' energy at all times of day. only fission and hydroelectric power manage to do this right now. fission is more difficult from a regulatory standpoint (though it should get more support!). hydroelectric is limited in terms of potential sites. geothermal can navigate both.

Personally, I'm quite excited about a future where clean renewable energy is abundant. Quaise's approach seems to be one of the best shots at that future.

Many thanks to Carlos Araque, Henry Phan, and Matthew Houde for organizing the tour, and to Eli Dourado for turning me onto Quaise in the first place. If these problems seem interesting to you, Quaise is hiring across the board.

---

[1]: Technically, Quaise drills three holes, because the water coming out is less dense than the water being pumped underground.

[2]: Carlos tells me they've now hit 20kW