Vibe-Coding an Attention Firewall, w/ Steve Newman, creator of The Curve

Steve Newman, once the creator of what is now known as Google Docs, now author of the Second Thoughts Substack, and founder of the Golden Gate Institute for AI, makers of the Curve conference, welcome to the Cognitive Revolution.

Really excited to be here.

Yeah, I'm looking forward to this. I think this is going to be a fun session. We're going to cover a lot of ground, and some of it's going to be a little bit of show-and-tell.

One of the things I've been thinking a lot about lately is that people are so excited about going down the Claude Code and AI-agent rabbit holes, and all these various rabbit holes, that a lot of people are probably coming up with very interesting ways of working and not sharing them as much as they probably could because it's just so much fun to do, and it's so bespoke. At least for me, I've had on my to-do list, “I should do an episode about my setup,” and I keep thinking, “Well, I want to do this one more thing before I actually get it done.”

So I finally cornered you and said, “All right, I want to see what's going on.” And then there's plenty more stuff beyond that to talk about as well. Maybe for starters, tell me what you're building. You've been programming since I was able to see on LinkedIn, as far back as 1985, with multiple companies that you started and exited, including Writely, which became Google Docs. What are you building today?

This is all on the side because my day job is at the Golden Gate Institute. Some of what I'm doing relates to that, but mostly it's just personal tools. On the side, evenings and weekends, I've got something like 15 different projects going, mostly under the heading of personal productivity.

The theme has been that, like so many of us, I've just been drowning over the last couple of years, trying to keep up with everything that's going on in the world in general and in AI in particular. I now know—I wouldn't have known this statistic until I started building these tools—that I get something like 50 Substack posts, other blog posts, newsletters, and other big information items in my inbox per day, plus everyone I follow on Twitter, plus a bunch of WhatsApp groups I'm in.

I was spending I don't know how many hours per day just trying to read, just keep up, let alone synthesize, let alone do anything else. The theme of most of what I've been building is managing that workload.

The first thing I built—and this is something I'd been dreaming about and muttering about for a long time—was something to just summarize. Not because a summary is as good as the original, but more to tell me what to read. I don't know how many posts I'm going to get over the next few days about Opus 4.7, and I don't need to read all of them.

The first thing I built was just an RSS reader that takes all the Substack and other newsletters and podcasts and a couple of other things, and precomputes a summary for each one. Actually, two levels of summary for each one. Every morning, I can glance through the summaries and decide which of these I'm actually going to bother reading. Is this a new take on 4.7, or is it basically the same as what I've already read?

It's especially helpful for a podcast, where there can be an interesting topic, and it may or may not have an angle on that topic that I haven't seen before. The summary can be really helpful for that.

The second theme, which took me a while to figure out, was giving myself focused time back. I probably get a few hundred emails, Slack messages, WhatsApp messages, and so forth every day. Only a fraction of them really need my prompt attention, but a few of them do.

I was in the habit of, probably 30 times per day, every time my brain came up for air from a task, checking my email, checking my Slack, checking—I had about 5 apps I would rotate through. That gave me lots of opportunities to get distracted by seeing something I actually didn't need to see for a few hours.

A much bigger and more complicated project—it's really about 5 subprojects—is something that pulls in all the email, Slack, Signal, WhatsApp, and so forth. Pulling them in is a big, complicated mess with lots of integrations, including some services that didn't really want to support that, like WhatsApp.

Then there's 1 line of code to hand each message to an LLM and say, “Is this urgent or not?” I've accumulated about a 1-page rubric, gradually, exception by exception.

And then the timely ones pop up on a second monitor that I purchased for this. I've gone 40 years of engineering without a second monitor, and I finally bought one to have a rolling view of my calendar and this list of urgent messages. The idea is that those are the only things I need to look at other than whatever I want to be focusing on right now. So it's sort of an attention firewall.

I like that phrase, and I love the idea that you had a very practical and experiential sense of what you were trying to accomplish. For me, it's less time in the chair, more time exercising, and more time outside. But also, I need to square that with not losing track of what I'm doing as well. So I think that's really helpful to try to get concrete in envisioning, “How is my life going to be different if this project is successful?”—lest we fall into optimizing the agent setup for the agent setup's sake, which I think is obviously very alluring.

Well, I've forgotten, because this was weeks ago—or probably a couple of months ago—but there was a period where I was spending a lot of time on Claude Code skills, and that, somewhat to my surprise, has settled down. I'm sure it will unsettle again, but I'll also say I was probably 3/4 of the way building this attention firewall thing before I understood what I was building. I was very much fumbling in the direction of something and had to do a lot of iteration before I was able to crystallize it.

I think that's a lot of what we're all doing collectively. We're all fumbling our way; there's no playbooks here, right? I think you said something about this a minute ago: we're in the middle of a Cambrian explosion. We're all doing our individual components of the Cambrian explosion and making things up as we go along, and only understanding in hindsight or mid-flight what we're doing.

I would say that won't settle down for a long time, except, of course, actually it will never settle down, because by the time it would, there will have been 5 new inputs, and we'll be in the next round of chaos.

One other question I have on both of those projects is: how are you handling context? With the newsletters, there's a question, I guess, of, for any individual newsletter, you could say, “Will this be of interest to me?” Here's my interests; score on that basis. So how are you handling context?

There are obviously multiple dimensions or layers to that, but at least 2 that jump to mind are: how do you make sure that the information's being filtered effectively against what it is you care about, want to learn about, et cetera? And the other is, when you have so many things coming in and there's so much duplication, how are you managing to cross-reference these things against each other to try to tease out what is genuinely new from each bit?

Yeah, it's interesting: I'm not. It's the dumbest possible thing. This tool literally just takes the full text of each Substack post or podcast transcript, dumps it into an LLM, and says, “Summarize this.” I've done a little bit of iteration on the exact prompt—what kind of information I want it to surface and what I don't—but it's completely static, with no context at all.

Last year, I had been sort of envisioning this a little bit, and I was thinking in terms of, “I want it to know everything I've already read so it can identify what's new,” and so forth. I didn't bother with that in the first iteration, and I haven't been motivated to do anything about it. So it just gives me the summary, again with a little bit of finesse in the prompt. I think the prompt says things like, “Surface any novel ideas,” but that's going to be novel against the LLM's training data and what the LLM, from first principles, thinks is novel.

Obviously, it would be better if it could contrast that with what it knows I've already read. And, to my surprise, it just hasn't been a problem. I know what I've already read. I can skim a 1-paragraph summary in about 10 seconds, and that's efficient enough.

You know, there's a whole other side of this—the road a lot of people are going down, at least seemingly, and I've not gone down at all—which is actually responding to emails or just acting on the content of my, at least, digital life. I haven't gone down that road at all. I know a lot of people are, partly because it just feels a little daunting, both in the complexity of the project and the security concerns it brings in and so forth. I'm sort of conservative by nature: I don't like to use a tool unless I really know I can trust it and I understand what it's going to do.

So that does feel like that's a pull I'm going to have. I feel like it's going to be so worthwhile to jump into that I will eventually find myself forced to, but I haven't gone there yet.

I'm not conservative by nature in general. I'd say my attitude on computer security has historically been borderline negligent, but this has changed my mindset. I've always been like, “Do I really have anything that valuable?” or “I'm not a big target. Who cares?” But now it's like, I don't know. As I give an AI access to not just everything that I've ever written, but everything anybody's ever sent me, I feel a certain kind of duty of care to guard the information that they trusted me with. I never really thought that it was going to be going into some AI that hadn't even been contemplated at the time that it was sent. I've had my same Gmail account for 20 years.

So that definitely has caused me to slow down and take a more deliberate approach to try to figure out under what circumstances I give how much access, and when I want the thing to draft something for me versus when I think it might be more helpful for it to try to play the role of an assistant. I'm definitely still feeling my way through a lot of that stuff as well, but it is striking that I feel compelled to take my time, when usually I would just sign up and let it rip on just about any other software experience in the past.

Yeah, and I hear you, and it's a great point about your data also being other people's data. The trade-off between security and utility is really biting, right? OpenClaw—or I don't remember what we're supposed to call it now—and I keep waiting for a shoe to drop there. I keep waiting for the stories of people really regretting their life choices around it. There have been 1 or 2 anecdotes that circulate, but hardly anything.

You have to think those are juicy stories, and if people were really getting burned by prompt injection or whatever, or just bots deleting production databases, deleting your email history, whatever, again, there are 1 or 2 stories, but I've only seen a couple. So it's hard to explain why there haven't been more problems, other than maybe it's harder to exploit this stuff than you'd think.

You don't have to have malicious problems. You can also just have over-eager bot problems. I think probably part of it is the model developers and the tool developers are working on it—they're adding classifiers and whatever. I haven't followed it closely, but it feels like every new model report card says, “We've reduced prompt-injection susceptibility by another X percent,” or whatever. Somehow, we're keeping ahead of the curve, and yet at the same time, everyone agrees that, fundamentally, this whole system is totally insecure and broken if you trust it with anything.

And so I don't understand how that tension is going to resolve. I think this is going to be very interesting to keep following. But meanwhile, I kind of feel like the guy in Raiders of the Lost Ark: “Asps. Very dangerous. You go first.”

Yeah. Even this is happening at every level, right? At the model level, obviously, with models: greater utility, greater security concerns. When you give access to tools, it's the same thing. Even upgrading software has suddenly become this weird damned-if-you-do, damned-if-you-don't situation, because there are supply-chain attacks that are starting to get scary.

I've seen people say, “Don't update anything until the package is 7 days old,” but the flip side of that is, if we're patching critical vulnerabilities that just got discovered, you want those patches fast. So now do I have to keep track of all these dependencies? What a nightmare.

I don't know. It is weird. I think you put your finger on something there that I very much associate with you: coming at these core questions from both perspectives. It's in the title of your Substack, Second Thoughts, as well. A lot of times, seemingly, we end up kind of confused. There aren't great answers, but we can probably touch on a number of those things as we go.

Are we just in a—are you personally just in a total state of confusion when it comes to it? I mean, I think the security vulnerabilities are pretty real and pretty obvious. We've even talked about this a little bit offline, in terms of why we aren't seeing more phishing scams. I feel like I've seen an uptick recently in a couple of sophisticated, seemingly scammy emails coming my way, but not nearly as much as one might have thought. The same thing is true with election deepfakes; that didn't really happen. Do you have a story for any of that, or are you still kind of confused about it?

I'm mostly confused. I think you could argue that there's a lot of precedent suggesting that bad guys can be just as slow to innovate and adopt as anyone else. It's easy to point back to—I think it was in the '80s. Do you remember the Tylenol scare?

There was this incident, I think in the early '80s, where someone, if I'm remembering correctly, put cyanide in a couple of pill bottles, or a small number of containers of cyanide, on store shelves. I don't remember whether they were tampering with them by walking into the store and tampering there, or exactly how it happened, but a handful of people fell ill. I think there were a couple of fatalities. To this day, that's why so many products you buy have the safety seal on the little plastic wrap or whatever.

Anyone could have done that at any point in the last however many hundred years. It didn't happen until the '80s, and then it happened once. It could still happen. There are plenty of things you buy at the store and put in your mouth that don't have that safety seal, whether it's produce or whatever. In every walk of life, there's so much low-hanging harmful fruit that I don't entirely understand why most of these things don't happen. I'm glad that they don't.

One theory is that whatever complex sociological factors are going on there continue to apply here. That's a little hard to completely believe, because we also have a lot of opposite case studies in cybersecurity. If a server is vulnerable to a well-known attack, some script kiddie or some bot is going to get in there. There are definitely systematic bad things that happen on the internet.

Going back decades, I think the statistic was that if you took an unpatched installation of Microsoft Windows and connected it directly to the internet, it would be owned within 5 minutes or something. That goes way, way, way back. I don't know how to reconcile those 2 patterns of the world, and if anyone can shed light on this, I think it's a very important question to ponder. But I don't actually have any insight into it.

One AI-specific story that I find at least somewhat compelling is simply that if you're good enough at AI to scam people effectively with LLM-generated phishing attacks, you could probably make honest money in a similarly easy way, because there's obviously a ton of demand from legitimate businesses for people who can make it work reasonably well. I find that at least somewhat persuasive for the moment. That might be a lot of it, and it will still remain a mystery overall, I think.

How would you like to show us some of your stuff? I think the extension, or the corollary, of my intro is that people should watch other people use computers more. In particular, folks who started programming in an era where there were very classic editors and lots of command-line and cron-job-type stuff seem more likely to have a kind of advantage, or a little bit of a different paradigm, that now suddenly becomes more relevant again as we're all using command-line tools. Most of us, myself included, have very limited familiarity with or attraction to that modality.

I'd love to peek over your shoulder for a minute, if you wouldn't mind, and learn a little bit about how you actually use AIs and, I guess, even more generally, how you use the computer.

Sure. Let's go for it. Okay, share screen. I thought I'd start by showing off a few of the applications I was talking about before. I've got them all lined up in tabs here.

So, this is that feed reader I was talking about. This is the current live view, and there’s very little to it. This is basically the only screen I use. It’s the dumbest possible thing: it’s just a list of posts.

It looks like we’re getting demo disease because the last few posts must have broken something. They should all get summaries within about a minute of coming in, but for the last hour they haven’t. The older ones have them, though. This is the summary I was talking about.

My workflow here is that whenever I have a little idle time and want to distract myself, I run through this. I might go through in order, or I might jump around, and I look at whether something is worth reading. I can either click on it, which opens the original, or the main thing I’ll do is go over here and hit Archive.

This is an example of an iteration: something I thought I would want to do and almost never do. This icon opens a Claude session with that article in context so I can ask questions about it. I actually forgot this feature was there until just now because I haven’t been using it, but it’s something I’ll do sometimes.

Overview is also precomputed. It’s a simple LLM prompt—“Summarize this post”—but it’s a different prompt that generates a longer, one-page summary. It specifically says, “Tell me the novel ideas here. Tell me the notable evidence.” I gave it prompts that correspond to these section titles.

Mostly, I either look at the first summary and decide whether I’m going to read the article or not. But if I’m on the fence, or I feel like it’s not worth reading but maybe it’s worth getting a little more context, this is my 80/20 alternative to reading the post.

That’s pretty much it. There’s a bunch of other stuff in here, all of which is infrastructure to keep the tool working, almost none of which I would have bothered to implement if I had to do it instead of an AI.

Every day, it dumps a backup of the whole thing into D2, which is Cloudflare’s version of S3. You can view the backup. I would never in a million years bother to implement a pretty-printed backup viewer, but that was one sentence in one of my prompts. This helps reassure me that the backups are really working.

There’s also a bunch of machinery for importing all of my Substack subscriptions. That involved vibe-coding a bookmarklet to rip apart the HTML of my Substack subscriptions page because there wasn’t another good way to get the list of my Substacks. The feature set is much longer than I would have bothered to implement myself. That’s just one of the interesting things I’ve found.

Basically, this is the whole tool. The one thing I’m going to show you with screenshots instead of the live version, because the live version can be sensitive, is the attention firewall. I named it Radar, after the old M*A*S*H character Radar O’Reilly, who was always there the moment you needed him, with the information you needed before you needed it.

This is the 3-hour view of my calendar. This is what’s on my second monitor. Another theme here is that you can customize everything. This isn’t actually my entire calendar. I’ve given it rules for things that are just blocks of time—not things I’m going to do, but warnings to others not to book that time—or things like my wife’s calendar that show up in my Google Calendar view.

This is the idiosyncratically distilled and filtered version of my calendar, with a bunch of shortcuts. If I wasn’t missing this call to do the podcast, I could go right here and, without even opening the calendar entry, use that button to join the Google Meet. This is the button to open my private notes about what I would discuss in the meeting, and this is the button to open the shared document that the team and I would all be in during that meeting.

These are all just little vibe-coded rules. It knows that if the calendar entry has this title or subject line, it’s a recurring meeting we have internally, and this is the document I always want to have in front of me when we’re on that call. There are lots of little idiosyncratic things like that.

The other half of it is the attention firewall. These are the classifications of events. A lot of them, like Urgent and Midday, are at zero because it’s easy for me to stay on top of those now. For each one, you get the kind of inbox view, but with a summary on each item.

If I click on one of them, I get this ugly little toolbar full of keyboard shortcuts. Again, they’re idiosyncratic. Forward means forward to my wife because we’re on a lot of shared Amazon, PayPal, and other accounts, and I’ll get notices that she would care about. So, there’s one button for forwarding and archiving.

Another theme here is that I’m pretty fast and loose in the way I develop this stuff. I don’t have a staging environment. Everything is based on whatever automated tests my exhortations have caused Claude to build. I don’t know what that means, but it says it has a lot of tests, and it says it runs them. I kind of believe it.

I just push to production all the time because I keep the stakes low on all this stuff. All my messages really live where they’ve always lived—in Gmail, WhatsApp, and Slack. If I want to reply, I can do lightweight replies here, but if I want a rich-text-formatted reply or anything even slightly complicated, this means “Move it to my Gmail inbox.” It’s always been in Gmail; this is just a label change in Gmail.

If this totally falls down—if Claude has the bright idea to delete my production database or whatever—everything is still where it’s always been. I just lose the nice interface to it. That’s never happened yet in the couple of months I’ve been working this way. It feels much longer. Knock on wood.

And you can see that every one of these tabs is some other part of the toolkit I’ve built. I don’t know how much of this we want to go through, but it’s so easy to build tools that I just keep adding to the pile.

I’m interested in going through some more, at least, because I do think people benefit from seeing what other people do and getting inspiration from it. Maybe a couple of questions to prompt you as you go a little deeper: When you’re coding, is it all Claude? Is everything Claude? Is there a place for Codex in your workflow?

When you talk about all the originals still being in their place, is there a sort of shadow database that you’re pulling them into and storing them in as well, or are you just making a runtime call to get the most recent stuff? And I had one other question. Oh, and why Cloudflare? What is it that you like about Cloudflare specifically?

I’ll answer the last one briefly because I know I’ll forget. I think I basically had some long conversation about it. This was a key decision at the beginning: where to host.

I’m pretty sure I hit Gemini, ChatGPT, and Claude and said, “I want to build a set of web apps. I’m an experienced developer, but I don’t want to get my hands dirty, and I’m kind of rusty. This is the kind of stuff I want to build, and I don’t care too much about cost because it’s only one user.” I gave them a whole bunch of context and asked what stack I should use—hosting provider, programming language, front end, back end, CSS library, whatever.

I let all 3 of them give me answers, then pasted each output into the others and had them critique it. That’s a level of effort I don’t normally bother with. More recently, I built a skill to automate that, which I had forgotten I’d built, and I need to use it more. We have such an embarrassment of riches now, both in the tools other people have built and in the tools we’ve built for ourselves.

Basically, that rose to the top. I also had the idea in my head that anything Cloudflare does, they probably do pretty well. I wouldn’t defend that; it’s just my Spidey sense from things I’ve read on Hacker News over the years.

I’ve been happy with it. There’s enough of a toolkit there that it has server hosting, cron jobs, queues, databases—whatever it is, just enough of a toolkit to do everything I want. But it has much less complexity than something like AWS, and it’s mostly pretty cheap for small-scale usage.

Why don’t I speed-run through the suite here and then talk about the development process? This is a tool I very specifically pointed at a Hacker News comment thread. It has this whole workflow where it reads the article, reads all the comments, and identifies themes in...

These are themes that emerged in the Hacker News comments: people complaining, as people always do, about an existing model getting dumber. You can see this here. I haven't read them. It identifies themes and gives a summary of the article and a summary of the overall comment thread.

Then I can click on one of these themes and see all of the comments that fell under that theme. A comment can be tagged under multiple themes. I don't use this all the time, but sometimes it's handy because those threads can be very heterogeneous. There'll be a section that's really interesting and another whole section that's about something I don't care about, and it's hard to find the part because it's all entangled together.

By the way, again, it's idiosyncratic. There are all kinds of integrations that I've built because they're so easy to do. Here, I'll open up Hacker News and click on something. I don't know whether you can see this; it looks like you can. This is a Chrome extension where I can— it says “Save to Notion,” but the word “Notion” there is kind of out of date.

This takes the current page, and I can add it to my to-do app that I'm going to show you in a moment. I can add it to the Reader app that I just showed you, or I have certain sections of my Notion tree whitelisted into here. Mostly, I have a page full of subpages of notes on blog topics I might write about someday. There's a whole little set of heuristics for what gets shown here, and I can type and filter and whatever.

If I throw this into Reader, then there's a special rule that says if I put a Hacker News discussion thread into the Reader queue, it will feed it into this tool. This takes a few minutes, so in the background now it's building a summary.

Okay, speed run. This is a view of my Gmail spam folder sorted by recent. I actually don't remember the sort order, but it's not by date; it's by these columns in some order, which I find is super handy for skimming through it. For whatever reason, I get a lot of emails that are addressed to me at AOL.com, which, spoiler alert, is not my actual address. This is just a little idea I had one day: it'd be easier to plow through my spam if it were sorted. So I implemented that.

This is the other thing that goes on the second monitor. It's the status of each of my coding agents. Blue means it finished a task. There's like 8 different pieces to this, held together with bailing wire and whatever. There's a little web app that's running this web page, and there are Claude Code hooks that report to the web app when the status changes.

If I click on one of these buttons, it will open that terminal tab, which involves AppleScript and something called Hammerspoon, a macOS utility that I don't even know what it is, but Claude told me to install it and I believed it. That somehow glues these things together. There's a Chrome extension in here somewhere, too, so that I can do screen shortcuts.

I hit Control-J, and—you can't see it here—this only works in Safari, which is not the window you're looking at. But there's a Command key I can hit, and then these light up with numbers 1, 2, 3, and 4. If I type that number, it'll open that terminal tab. The red ones mean there's no active agent, but in my to-do list app that I'm going to show you in a moment, I have to-do entries for that app. So it's also integrating with the database from that other app.

There are other statuses for the agent: it's busy working, or it needs to ask me a question. So that's that one. There's not much to this. That's my entire agent-management toolkit. It's just this one little thing with the color-coded buttons, but again, it's sort of the attention-firewall thing. I don't need to look in on my terminals all the time. I can glance over at this on my second monitor, and my brain has already internalized the color coding. I know whether anything needs my attention or not.

Just to make sure I understand the structure of that, because that might be something I want to do: I don't really use hooks much at all. I think hooks and cron jobs and these various things are not instinctive for me. Tell me a little bit more about the hook. It's sort of when Claude finishes, it reports to this app in the cloud what its status is?

Exactly. This is the only use of hooks I'm making that I can remember, and I don't understand much about it. I basically had a little conversation with Claude at some point: “I want a view of which agents are busy and blocked. Let's brainstorm ideas.” I don't remember whether it suggested hooks or I did, and it said, “Yeah, I can do this with hooks.”

It's not perfect. The hooks don't quite get enough information to do a perfect job of this, but it works well enough. The short version is that I've got this cloud app. It exposes an API, so the hook just runs curl or something to hit the API. In real time, there's a server-push notification from that web app down to this web page, so I get real-time little color updates as the agent starts and stops.

Is this a bunch of different repositories? I assume this code lives on GitHub as well. How do you organize it into repos?

Yeah, so there are about 15 projects. Each app I've been showing you is its own project. By the way, I deliberately broke it down into projects to keep the context manageable for the coding agent. It's not like I tried different approaches and found that this was the right one; this was just my gut. My gut was basically microservices: keep each project as small as possible so the context is manageable, which was probably more important in the ancient days of January, when I started this, than it is today.

Each has its own GitHub repository and its own database back end, and its own little project or whatever in Cloudflare. So they're somewhat isolated from one another, but they talk to each other and invoke each other's APIs a lot.

I hadn't really planned this, but it turned out they're all on my hard disk on my Mac. All of the Claude Code is in a Docker container. I run Claude in dangerously-skip-permissions mode, but it's in a Docker container. All of these projects have their repository directories next to one another under one home directory in the Docker container, so they can see each other's code.

At first, if there needed to be an API update, I would ask one agent to tell me what I should tell the other agent, and I would manually copy it. But then I realized I can just reach over into that other app, give it the API, and use the API or whatever.

That's interesting. I think I'm following a fairly similar pattern, although probably in keeping with my generally less structured personality, I kind of start with everything in one repo. Then over time, especially if I want to share something, I'll split it out into a separate repo. Anytime I want to just try something, it kind of goes into the personal private monorepo.

How big is that? How big is that monorepo?

I mean, the big thing for me is context exports, because I've gone basically 5 years back into all these different channels. That has added up to roughly 1 gigabyte.

Oh, so you have a lot of content in that repo.

Yeah, and I'm not sure if that's quite the right way to do it either, but I did want to have some backup. I was like, where should I back this up? It could be Google Drive or something. I just decided to go with actually putting it into GitHub. It's like Git LFS or whatever that's called.

Aside from that, it's not that big. I would have to run a script to know how many lines of code or how many tokens or whatever it is, but it's manageable besides the—I call it the deep-context database.

Yeah, my GitHub repositories only have code. All the data is in Cloudflare databases.

People talk a lot about agents really understanding how to look at file systems, and that does sound like a good approach, but I just haven't tried it. I actually have it—it's a SQLite database that just runs locally. So it's probably similar in terms of being a query action for the agent.

Another thing that I do that's kind of similar is I have the top-level CLAUDE.md file point to other CLAUDE.md files, so that if it doesn't need to know what's going on in another project, it can still go see that. I'm trying to make that mostly one-directional, because some of the projects that I split out are ones I want to collaborate on.

Say one is tools for the production of the podcast. That started off intermingled with my personal email and history and communications and all that stuff. I was like, “Okay, well, I want to share this with a couple of people so we can work together on it.” I was like, “I don't want to share my entire email history,” not because I don't trust anyone, but because that's what the people who sent me those emails would want me to do.

So, after splitting them off, I'm like, “Okay, how do I want Claude to—” I don't think this is robust security, to be clear, but if I start Claude in the main one, it has pointers to the other one.

But if we start it in the other one, it doesn't have obvious pointers up. It could look around and get outside of its immediate view, but it's at least not instructed to do that. If somebody else clones that separate repo, they're not going to have the main one anyway. So, on their computer, it just wouldn't have that kind of access.

Okay, cool. And then, yeah, so then you asked them, like, “Am I mirroring data?”

So, yeah, I built one of the projects called Mirror, by the way. I'm only just now realizing that everything I've been talking about, the listeners will only be listening and not seeing, so I'll describe a little more.

This is just listing all of the different data sources I've integrated with to pull data out of. It's pulling my Google Contacts, Google Calendar, Gmail, WhatsApp, Slack, Twitter, Google Docs, Signal, and SMS messages off my phone. This is, again, the kind of thing I would never have built myself. There's this whole status dashboard of how many records have been imported, how that's going, and so on.

I don't even look at this much. I only used it briefly when I was first getting it working. The idea is that now I'm building up this rich database of all that content that I can use for context. I haven't actually done much with it other than driving the real-time inbox view, but there's a whole web UI for searching and viewing backups, and all this toolkit, which, again, I used briefly while I was troubleshooting to begin with.

Is that real-time view, by the way? Is it polling? I've done some of these integrations, and some of them have been quite painful. I use Beeper Desktop to try to aggregate a half-dozen or so of them. That's also kind of painful. I feel like Beeper Desktop is a good idea, but it crashes a lot for me. I haven't gone as far as getting pings in.

If I want to take inspiration from this and I'm thinking, “How do I get to a real-time view?” when what I currently have is a batch process that I run a couple of times a day to update my database, what have you found in terms of what actually works well for getting closer to real time, if you got fully to real time?

This has been far and away the hardest part of everything I'm presenting, and a lot more grief—far and away the biggest time sink. There are 8 different solutions, and each one was different. It is generally pretty real-time, and I pushed to get that because I wanted to have this attention-firewall inbox view.

Gmail has great APIs. They're painful to use, but that's Claude's pain, not mine. So, yeah, there's some kind of real-time sync. I think the calendar is also—Google provides a sync API for the calendar. I don't even remember about contacts, but that doesn't need to be real-time.

WhatsApp has a bunch of bad solutions, as it sounds like you found. There are lots of bad solutions for WhatsApp, and it's hard to find a good one. It turns out—and I hope that no one from Meta is listening to this, but what I'm about to describe is not a secret, or I would have never found it out—if you install WhatsApp Desktop on your Mac, and I imagine on Windows, it is obviously syncing down all of your messages. It turns out it stores them in an SQLite database. It's not encrypted, so you can read it.

I'm just piggybacking off of WhatsApp's own real-time sync. There are a lot of WhatsApp integration solutions out there that actively talk to some internal WhatsApp API, and there are a lot of stories about people getting their accounts banned, as well as other stories from people saying, “I don't know what you're talking about. It's fine.” I don't know exactly how dangerous it is to use those kinds of hacks, but I didn't want anything dangerous. There's no way for WhatsApp to know that you're looking at it; it's read-only access to its database file.

I have a cron job that runs probably once a minute—I don't remember—and this is on my Mac. Again, there are parts of this everywhere: inside the Docker container, outside the Docker container, up in the cloud, and on my phone. This one is running on my Mac outside the container, looking at the WhatsApp SQLite database. Slack is another API integration.

Twitter is the worst, hardest one. I found some very shaky, fly-by-night—“fly-by-night” is an exaggeration—but some very shady, borderline-looking service that will let you query Twitter. I don't know how they do it, and I don't want to know. It's not like reading my feed, which would be nice. I have to manually pull every individual person I follow, but that's only about 80, so this is the slowest one. It probably rotates through them about once an hour. It would start to cost noticeable money in API fees if I were pulling more often than that.

This was glitchy to get working, but they're all working now. It's not like they break every day. Google Docs, again, is an API. Signal, I don't remember. [laughter] SMS is an Android app that's watching notifications on my phone. Signal might be similar.

The new Twitter API, I think, is going to be probably a big hit for them, inasmuch as it is quite painful to try to make work. I had a version of Twitter that was basically using a headless browser with my login, and it would sort of try to use the cookie that I had most recently logged in with for as long as possible until it expired. Then you'd have to re-authenticate or whatever, and that worked okay. It wasn't terrible. It certainly wasn't super reliable.

But now I might just sign up for the paid API. Even though it's going to cost me a few cents to do a few things, I didn't realize they had an official API that would work for this. That didn't come up in my research. Maybe not.

I think maybe it was in the last 2 or 3 weeks, and I'm not even sure if it's fully GA yet. The big difference between their previous version and now is that there's not a big fixed cost to enter. It's kind of priced—I think it's honestly pretty effectively priced for them—where it's not super cheap, such that you're going to want to go really mine data, or, if you do, you're going to have a pretty good reason for doing it.

But it's also not so expensive that if you want to get your own feed a couple of times a day, you'll be afraid to do that. I think they've landed at a pretty good spot that will allow people to have access without having to fear that you're going to run off with the entire fire hose or what have you.

Yeah, yeah, that makes sense.

Yeah, so if I were doing this again, I would use that, and I may switch to it the next time this one breaks. Then just run through the to-do list. There's stuff in here—repeating events, repeating reminders, and all kinds of things—but they're idiosyncratic to me. At the end of the day, it's not that complicated.

This is just a little detail. I talked about wanting to put myself in a position where I can be cavalier in the development and just move fast and break things, knowing that there's nothing too valuable to be broken. The to-do app would be the one where I'd be most sad if I lost the database.

This generates a backup every 5 minutes if there's been a change. Unlike all the other backups, which are just dumps into D2 file storage, this is live-synced to GitHub. I wouldn't even need to do a restore. I can just open github.com, navigate down, and see my to-do list—a static version of it—if the to-do list app ever glitches.

This is the payload for the Twitter integration. It's just a feed reader with a bunch of little details, like deduplicating retweets and other things to make it work. It auto-expands everything, so instead of only showing the first 140 or 280 characters, it expands the whole thing. Those are little fit-and-finish things that I prefer relative to the default behavior of the Twitter app.

There's some infrastructure under this. By the way, I looked at this this morning, and it was broken, so I just told Claude to fix it. Let's see if it worked. Yes, it did.

All of these apps feed into a logging service. Part of how I support development velocity is that everything logs there. I found commercial services annoying enough to configure that I just had Claude build its own dumb little logging service. This is just an SQLite database hosted on Cloudflare.

All of the backends log there. All of the browser frontends—the JavaScript code—log there. All of the Android apps log there. Everything logs there. There are massive exhortations and code-review rules about this in my `CLAUDE.md`: “Thou shalt log errors. Thou shalt log every time you modify the database,” and so on.

Virtually 100% of the time—remarkably close to 100% of the time—if there's something wrong, like, “This event is on my calendar, but it didn't show up in my calendar mirror view,” or, “How come none of the new blog posts that have come since noon have a summary?” I can just tell it, “Debug this,” and it has the data to figure out what went wrong.

I use a very popular Claude plugin called Superpowers by Jesse Vincent. One of the skills in there is—I’m pretty sure this is his—called “systematic debugging.”

I just tell Claude, `/systematic-debugging`, and give it a one-sentence description. From my `CLAUDE.md`, it knows that it has logs. It's been very loudly instructed to look at the logs, not to guess, but to look for evidence. It works so well.

If I had one concrete piece of advice about how to agentic-code well, especially for personal projects as opposed to a professional software development operation with production practices and so forth, it would be this: if you're going to do anything more than just type prompts into Claude, and you're going to do one infrastructure thing to make it work better, have everything log, including the front end. All of the moving parts should generate logs in one place.

It's annoying to have to build that place yourself, and there's probably a better off-the-shelf answer, but I'm just not sure what it is. Then vigorously remind Claude that it doesn't have to make guesses about what's going on. It can go look.

Yeah, cool. There are—I mean, there are quite a few.

There's more. This is a summary that one of the cron jobs gives me—a daily summary of everything in the logs. But, yeah, those are some of the high points.

So, when you're actually sitting down to code, how many agents are you running in parallel? I'm getting the sense that it's all Claude.

It's all Claude. In some ways, it's a very simple, vanilla setup. I'm using the built-in macOS Terminal app. I basically have one window with one tab per project. I open the tabs when I need them and close them if I haven't been working on that project for a while.

If there's anything going on in that project—either the agent is working, the agent is blocked on me, or I have an entry in the to-do list for that project—it has a bubble here. When I'm coding, which is not all that often these days, although I went through a period of about a month or two when it was pretty vigorous—maybe 15 or 20 hours a week, mixed in with other things and mostly pushed to the weekends—nowadays it's more like half an hour a day.

When I'm doing it, I'll be bouncing anywhere from 0 to 5 parallel agents. I'll look at my to-do list and think, “I have active to-dos for this app. I made a note about something that annoyed me in this app, I've had a long-standing idea for something I wanted to add to that app, and I just noticed a bug in that one.” I'll tell one, “Systematic debugging—fix this bug,” and I'll tell another, “Here's a small feature.”

I have another skill—I don't even remember whether I wrote it or whether it's part of Superpowers—that's basically, “Here's my description of what I want. Figure out how to do it, deploy it, commit it, and push it to GitHub, end to end. Don't ask me any questions unless you really need to.” I have a different skill for, “You should probably have a conversation with me about the best way to go about this.” I can get 4 or 5 of those running.

One process change I went through halfway through this journey was that everyone talks about how you have to keep your agents fed—token-maxing, if the agent is waiting for you, you're wasting time. I went down that rabbit hole for a while, and it's very stressful. Then I realized, “Wait a minute. The agent's not important; I'm important.”

That wasn't true at first, because when I first started Claude coding, I had trouble using more than one agent at a time. I was initially only doing one project, and I didn't want all the complication of worktrees, three different things going on in the same codebase, and whatever. There really was a sense that I had a long list of things I wanted to do and was mostly sitting around waiting for Claude.

When my brain was in coding mode, I was mostly waiting for Claude, so it was a real shame to let Claude be idle. Once I worked my way around to breaking things into multiple projects, I didn't spend much time waiting for Claude anymore. Either I have another project I can tell it to work on, I can start preparing its prompt, or I've gotten good enough at thinking, “Okay, while it's working, I'm going to read my RSS queue,” or whatever.

Now I think in terms of optimizing my time. I'll give Claude its next prompt when I'm good and ready, when it's not an interruption to my mental workflow. Having this little status bar, having a view of my inbox and whether there's anything urgent I need to look at, and having all those tools makes it easier for me to put my attention where I want it to be—whether it's giving Claude its next prompt, figuring out Claude's next prompt, or doing something else.

Do you mind sharing your token budget these days, or your token spend?

I don't know, which means it's small enough that I don't have to know. I'm on the $200 Claude plan. I recently signed up for the $200 ChatGPT plan, mostly because I wanted ChatGPT Pro. I tried Codex once about a month ago and gave it one coding prompt. It behaved abysmally, and I said, “Nah, that is not at all a fair test. Take that as a Bayesian update of 0.002. There's no update there.” Claude was working well enough that I wasn't motivated to push harder.

I'm really loving ChatGPT Pro. I signed up for it for some meaty research question, but I'll abuse it for things like, “I'm driving up the San Francisco Peninsula to meet a friend. My friend's taking public transit over from Berkeley. Where should we meet for lunch?” I'll have ChatGPT Pro do a whole investigation into that. It's pretty handy, actually.

In terms of coding spend, it's all fitting within that. I have Claude set to purchase credits in $30 increments, and I've been getting the “You just purchased another $30” message more often recently—maybe 2 or 3 times a week—which is enough that I should look at it. I think that's mostly generating all these summaries and stuff. I'm very profligate; I'm using Opus to generate these dumb little summaries and whatever, because why not? It's not that much money.

I do have it set so that if I hit my Pro subscription limit, it flips to burning API tokens. Maybe that's some of it, but I don't think so. Long story short, I think all of my coding fits in the $200 plan.

Yeah, got you. Cool. Any other tools you would shout out? You mentioned Superpowers, which I've heard of but haven't used, so that goes on my to-do list coming out of this conversation.

Superpowers is a very nicely designed, very elegant little package of Claude skills. It might be ported to Codex as well; I'm not sure. That's the only set of skills I've really installed. Nothing else comes to mind.

There are all these weird little utilities that Claude has grabbed on my behalf, like that Hammerspoon thing, which is some deep Hacker News geek labor of love. Having glanced at it for 3 minutes and not really knowing what it is, I think it's one of these incredibly arcane toolkits that has 9,000 integrations through AppleScript or something with anything you can automate using a macOS API. Claude installed this entire giant thing just so I could click a button on the Juggler app and have it open a Terminal tab.

Hmm. I was wondering how you did that. I'm not sure what they are.

But in terms of things I interact with directly, it's really bare-bones. It's the built-in OS Terminal app, Claude Code, and Superpowers. I feel silly about that. There's such a wealth of tools out there, but I keep not encountering reasons to try anything more.

What I do these days, when I see something people are excited about or whatever the viral thing of the moment is, is ask Claude to dig into it and see what about it, or what ideas in it, might be useful to us. Rather than a direct install, it's kind of a scouting action first. Rarely is it, “Actually, yes, let's pull that in.” More often it's, “There are a couple of good ideas here, and we can apply them to our own tower of Jell-O in our own way and probably get 90% of the benefit of the core ideas.”

Yeah.

I feel better about that from a security standpoint, too, which is so out of character for me—to even be thinking about that at every turn—but I do feel like running things through that filter gives me confidence that I'm not doing something totally crazy.

Yeah, that's a great point about security. That seems like a very good approach. I have a whole document—a list of links piling up of things like that to look at—and I never get around to looking at it.

What's still hard? You mentioned some of those gnarly integrations with things that don't want to be integrated with it. That's hard on the level of being borderline hacking software that doesn't want to be hacked. I don't know—WhatsApp sounds like it's kind of open to being read that way, but it's not, like, it sounds like that's not even documented, right? So that's definitely a—

Yeah.

Yeah, definitely. Claude was doing a lot of spelunking in the database schema to figure out what’s a reply versus an original message, how to go from a user ID to a username, and so on. The integrations were far and away the worst part. I have to think that’s where a lot of value is going to be, because there are all these solutions for this: first-party providers are building MCPs and other APIs, and there’s Taskade, Claude Cowork, and all these other services out there. Everybody’s building integrations.

If you’re just coding your own solutions, that’s been the hardest part for me, as someone with a lot of software engineering background but who is rusty and has no specific experience with the details of everything that’s going into these apps. There was a lot I did to set up a player and hosting, and to understand how to connect an Android app through a Docker container to a web app, which wasn’t hard because I know how all that stuff works. I don’t know how it would have been otherwise.

I think the main thing that’s hard is not getting complacent. There’s always the next level of productivity. It’s so hard to unlearn the habit that the world is the way it is and your tools are the way they are. Every now and then, maybe there’s a new release, or you might look into a new tool, or even switch from Google Docs to Notion or whatever, but mostly your tool set is static. Unlearning the idea that you have to adapt your workflow to the tools, rather than the other way around, is difficult.

Then you have to figure out what to do with it. Another thing I’ve always assumed I would do, but haven’t, is something that works more with the details of what’s coming in. I’ve got this sort of unified inbox, but one email I get every day is the San Francisco Chronicle daily newsletter. It’s this long, scrolling thing full of news items and ads, and I don’t want to see the ads, the food updates, or the sports articles unless they’re about the Warriors. I do want to see certain other things, and I’d always assumed I would write some filter to show me just those parts.

Multiply that by 50 other examples of email that I get regularly, and I haven’t gotten around to doing it. Maybe that’s a good choice, and I’m subconsciously deciding that it would be more trouble than it would be worth. I think probably not. I need to motivate myself to do it, but it’s a little like I don’t want to have to build 50 features. I have to come up with some conceptual framework where I can just say a sentence or two about each one to Claude, and Claude can figure out what to do with it in a way that I trust will still show me the information I need to see.

I just haven’t motivated myself to take a step back. I’ll probably need to dive in, fumble around, and do it wrong the first time, and then eventually settle on a good way of doing that. So it’s that push to actually take advantage of all the new opportunities and do the exploration. Another habit I’ve had throughout my software engineering career is that I always worked very hard to think things through and understand the problem up front—measure twice, cut once.

I would really understand the problem, make sure I had pulled out all the details of the use case, go and talk to the person who wrote the spec to find out what they forgot to put in, and think through the 4 different ways I could structure the code. I would do all that work up front so that, when I had to do all the long, tedious work of writing, testing, and debugging the code, I would get it right-ish on the first try. I think that’s totally wrong now. Just dive in, do it wrong, throw it away, and redo it—that’s so much the better approach now. It’s not at all my nature, so relearning that has also been hard for me.

Do you have thoughts on when to revert? This has changed for me, and it’s probably going to change again. We just got 4.7 in the last few hours, so I recognize that it’s a moving target. I don’t know—6 months or more ago, I would have told people that it’s often easier to get the thing to work once, or in one shot, than to have it fail and then figure out how to fix it.

I used to advise that if it wasn’t working and you were stuck, or looping at all, you should revert to the last known good state. Try that prompt again, maybe say, “Here’s a bit of what went wrong last time,” and you’d probably have a better chance of getting it to work that way rather than trying to get out of that stuck state. These days, I don’t feel like that’s as big of a problem. I haven’t found myself doing that recently. Do you have rules of thumb or best practices for when you would press on versus fall back?

It’s interesting. I almost never find myself falling back, which is kind of shocking, and I don’t particularly understand it. Some of that is probably good prompting. In the Superpowers package, I forget the names of the individual skills, but one of the main themes is that there’s a skill that basically gets Claude to run big decisions past the user before it moves forward.

Some combination of the models getting really good and the fact that I didn’t even start vibe coding until Opus 4.5—and then pretty soon it was 4.6—means that I’ve been working with very recent, good models. That’s my experience. Between recent models, the Superpowers plugin, and the fact that I never look at the code, I almost never end up giving up and reverting.

All this code is TypeScript. I don’t know TypeScript. I literally never look at the code, but I do think about the high-level decisions that Claude is making. Somehow, between the models being good, the prompting, and me helping it avoid a few false paths, I almost never end up giving up and reverting. I definitely think it has happened, and I can’t remember specific examples. A model can definitely wind up thrashing down a bad path, and then reverting is a good idea, but it just doesn’t happen very often.

Also, these days I’m mostly making incremental changes. There was a big push a month or so ago when I was building all those integrations, importing from WhatsApp, and laying everything out. These days, I’m mostly just adding a new feature, then adding another new feature. I’m not making architectural changes, and it just doesn’t go that wrong.

Maybe one last practical question, and then we’ll zoom out and try to take stock of what all this means. Any voice or mobile strategies? For me, again, I want to get away from my desk. I want to be on my feet instead of on my butt. How do I do that? It’s still a work in progress for me, for sure. Any tips in that direction?

I see people talking about the remote control or whatever in Claude, and terminal emulators on their phones, and stuff. Those articles go in the pile of really good ideas for improving my vibe-coding skills that I pile up and never look at. I’ve realized that, like I was saying, I don’t want to optimize Claude’s time; I want to optimize mine.

When I’m out for a walk—and I do that too, because I get out for walks a lot—I’m not trying to get 5 more prompts in. I think walking is really good for both physical and mental health, and it gives you brain space for deeper thought. I’m a big fan of that idea. I go out for a walk so I can be in a different headspace.

What I’ve settled into, and what I really like, is that the work-ish thing I’ll do while I’m out walking is to have some project I’m working on. Maybe it’s the next blog post I want to write, the next piece of analysis I want to do, or the next app I want to build in Claude. It’ll be percolating in my head while I’m walking, and then I’ll pull out my phone and dictate a brain dump of ideas about whatever it is.

If it’s an app, I’ll ramble out feature lists, design decisions, design questions, and whatever else—a brain dump of high-level thoughts about it. I read somebody talking about this simple trick, and it worked really well for me. You take that brain dump, paste it into whatever LLM you’re using, and say, “Organize this.” You can pretty much literally say, “Here’s my brain dump. Turn this into a Claude Code prompt.”

I usually won’t even bother to read what came out. It’s usually good enough that I would rather wait and then say, “Hey, you did this wrong. I wanted this to work this other way,” rather than rereading its 3-page cleanup of my brain dump. It’s more efficient for me to let it go through all the work and then tell it that it misunderstood my brain dump.

So that’s what I do remotely. What I’ve said feels ridiculous, but the actual tool chain there is that I open the Gmail app on my phone, click Compose, type my own email address, click in the mail body, and click the dictation button on the built-in keyboard.

And I am sure this is not the best way to do it, but it’s always there and it always works. I don’t have to worry about whether the recording got saved. So that’s my process.

Cool. One thing I’m going to do after this is take the transcript, run it through a planning session, and say, “Go figure out all the good ideas here that can apply to our setup.” I definitely think there are going to be several, at least.

I’m struck by the fact that I’ve built almost no custom UI for myself at all. I have a lot of skills, but basically nothing that presents things to me. I’m realizing now that that’s a gap and a half. Even in terms of producing the podcast, I’ve started to do more.

This is one of the classic paradoxes I find with AI: I wanted to be more efficient, but what I ended up doing was more in maybe the same amount of time, or maybe even a little more time in some cases. One thing I’m doing now that I do get some positive comments on, but mostly nobody cares about, is making a custom song for every episode. There’s a time factor there because I have to listen to the song to figure out which version I like, so it’s definitely not a time-saver. I do enjoy it.

I make art, YouTube-thumbnail-type stuff, and video clips to help promote the thing on Twitter. I realized I should have a UI where I can go look at what’s been produced. I’m still digging around file systems, and sometimes I’m scrolling back in the terminal to find the links that it printed out above. Looking at your setup, I’m thinking, boy, was I dumb for not thinking of something a little more like that sooner.

This is why I wanted to do this, because I was pretty sure there were going to be a few—not even technical unlocks, because there’s almost nothing we’ve talked about here that Claude can’t figure out how to implement for me without even needing to get into the details of what you’ve done—but the conceptual, scales-falling-from-the-eyes moments are quite useful.

Building your own UI is really powerful, and I feel like most of the energy is not there. There’s Claude Code, Cowork, Codex, and Gemini Antigravity, so there are all these different tools for coding and, more generally, agentic workflows. But they’re all things you throw commands at.

That works really well for a big task: “Go write this app,” or “Go reformat these 800 PDFs,” or whatever. But it doesn’t work very well for tiny actions, like you were just talking about: “Go find this one file,” or whatever. It’s annoying for you to have to open the file directory, navigate down, and find the file, but it’s not really going to be any faster for you to prompt Cowork or whatever to do that.

When you’ve got all the little, tiny, fine-grained things that we all do every day, it’s hard to get value out of agentic tools, whether they’re command-line tools or otherwise. But where you can get value is in a UI. I think that’s the other thing: we’re all leaning into these tools for verbs—go do an action—but an app is sort of the noun side of it, and that’s less explored.

A Chrome extension is another thing that jumps out at me. Mine is probably different from yours, but there’s definitely something there. I took this note from Zvi, but I still haven’t acted on it, because he also has a Chrome extension that he uses to collect notes, reformat them, and move things around.

Yeah, I mean, his is probably more sophisticated than mine. You can imagine exactly what he’s doing from the format of his newsletters, and I’m sure that’s a big time-saver.

I have a bunch of little Chrome extensions. Every time I join a Google Meet, I need to switch accounts because it always opens on the wrong account. Then I always want to hide my own window, and you need to acknowledge that your video is still being sent. There are just 5 buttons I have to click every time I join a meeting, so I built a Chrome extension that clicks the 5 buttons for me. It saves me 15 seconds 3 times a day. It took a couple of minutes to write. It’s awesome.

Let’s zoom out. I don’t know this story too well, but your last company was acquired in 2021. Correct me if I get any of this wrong. You had basically created better under-the-hood technology that a bigger company with more customers wanted to use to rebuild its product for the future on the new and improved technology that you had developed. Then you became responsible, within the acquiring company, for actually making that happen.

These projects—I’ve never done one personally, but they’re legendarily excruciating, right? You’ve got a zillion features. It’s like having a 100-year-old house. I try to use a light touch around this house because the second you peel back one layer, you don’t know what you’re going to find underneath, and a lot of it is better off left alone. I’m sure that was maybe a rewarding slog, but I’m sure it was quite a slog in many ways.

How would that be different today? Would it be very different or a little different? All the stuff we’ve talked about is stuff we wouldn’t have done before. But if you were going to go back and do something you actually did before, something that was a big priority, how would you expect that to play out differently now?

Yeah, it’s a great question, and the thing I can say most for sure is I don’t know. I’m sure that if I tried to talk about it now versus actually doing it, I would find more ways that it would be different if we were actually doing it.

The thing that comes to mind is that it was very much a “Don’t move too fast. Please don’t break anything” kind of project. We were swapping out the data storage and query engine from the flagship product of a company that was getting ready to IPO. If there was one thing they did not need, it was disruption in the production service.

They were a security company. Very briefly, they had an endpoint agent installed on millions of customer laptops, servers, and other computers, ingesting data from all those things and integrating with a bunch of cloud services that their customers were using. It was pulling in massive streams of data—I think trillions, certainly many billions, probably trillions, of events per day—and needed to store those for months and be able to query them rapidly and so forth. It was a serious piece of distributed-systems engineering that had to work with high reliability and accuracy. We were swapping the query engine out from under it.

What we would not be doing today is vibe-coding the actual implementation of that. In a year or 2, I wonder, because things are moving really fast, but not today.

A huge part of that project, exactly to your point, was that there was just so much we didn’t understand. There were 2 different teams: our team, which had built the new engine, and the acquiring team, which had built the old engine and the product—or rather, suite of products—on top of the engine. No one had a full picture.

The existing product, the acquirer’s product, had accumulated a lot of cruft and arcane knowledge in parts of the system that no one understood very well—walls that hadn’t been opened up in a couple of years, and whatever. For example, one of the things we were being asked to do early on was come up with a budget estimate. We were going public and had to provide forward-looking financial projections, so the question was: How much should we plan to spend on AWS the next year after we had done this port?

We were like, “I don’t know. How much data and how many queries?” We needed a lot of details on that. A query that looks at 1 day of data is very different from a query that looks at 30 days of data. A query from a huge customer with a lot of data is very different from a query from a small customer. A complex query is different from a simple query.

We couldn’t get that information. No one really had it. Maybe there were 1 or 2 senior engineers who understood that stuff, but they were really busy and couldn’t take time to answer our questions. There was a lot of trying to get access to the right systems, manually poking around, looking at logs, running queries, and understanding what was even going on. What was the shape of this data? What were the query patterns? There were lots of detailed questions underneath that.

It would have been so amazing to throw Claude Code at this and say, “Here are 100 questions I have about the data. Go write 100 tools, run 100 separate investigations, and give me 100 reports. Then give me a distillation of those 100, look at all of them, and tell me which of the 100 reports I should probably read. Come up with a cost estimate, explain to me how you arrived at it, and let me poke holes in it.”

None of that work touches production, right? If it goes wrong, it’s our responsibility not to trust it, but it’s not going to take the system down.

So you can much more just let Claude try—or whatever agent. I keep saying Claude; whatever tool. Let it try things for data gathering.

This is a theme I’ve seen come up: there are so many things around the production system—internal tools to let you look at your own logs, look at your own data, see what’s going on, look for bugs, look for patterns—that are not production-critical systems, because they’re just informing you, the human user, who can still apply judgment. That would have saved us a lot of time there, and we would have done a lot more of the investigation. It’s just hard to do that stuff manually.

How would you hire differently today if you were trying to build a software team for the Opus 4.7+ era?

Yeah, and this is another—I’m sure I don’t know, and we’re all sort of iterating and learning very rapidly. But there’s one high-level theme, and 2 things I’m going to point out. One is, you really—I suspect what you really want now are people who can think outside the box, because there’s no box anymore.

The box is established practice. There are a lot of engineers who’ve made their careers—I’ve read the Design Patterns book. I’ve read the manual, the style guidelines for React or whatever. I know this is a good database design pattern, and that’s a bad database design pattern. We have decades of industry experience telling us this. I’ve learned when that pattern is good and when that pattern is bad. I’ve seen it all before, or I’ve read from people who studied from people who have, and I know the right way to do things—the established way—and I’m going to do that. And that’s all out the window.

You can keep doing that today, but then you’re not taking advantage. We’re all figuring it out. We’re all doing new things. We’re all downloading, telling Claude to install Gestalts, extract Gestalt summaries of whatever everyone else is doing. It’s all new. Oh, I should build—I should start building custom UIs. I hadn’t been doing that.

There’s no best practice that I’m aware of, and certainly no established best practice with a history behind it for how to vibe-code your own UI tools to your custom workflow. So we’re all making it up as we go, and it’s all kind of idiosyncratic to us. No one’s distilled the big patterns yet.

What makes sense for me isn’t going to make sense for you, because you have different tools, different needs, different situations, different skills, and different preferences. There may be some pattern that’s going to underlie a lot of what we all want, some set of design principles, but no one knows them yet. People are posting things, but then they’re all obsolete a week later, and they’re not at the sort of level of depth, quality, and universality of what’s gradually emerged over decades of more traditional software development. So, yeah, being able to think outside the box and being comfortable navigating without a map, I think, is really important.

And then—and this is just a guess—communication skills are really important, because I don’t know what it feels like to be doing professional production, running a software company today, because I’m not doing that right now. But what I hear from the people who are is that what used to be a team is now a person, and what used to be 3 teams is now 3 people. Because everyone’s running their own suite of agents, the amount of coordinating with other people each person needs to do is a whole team’s worth of coordination with other people. My guess is communication skills are important, and that may also overlap with—there’s some overlap between being a good communicator with another person and being a good communicator with an agent.

Yeah, I would think quite a bit, certainly in the software domain in particular. So, what do you think? One thing you’ve written about notably is the importance of threshold effects and phase changes. It seems like we’ve passed some important thresholds if we’re already at a point where what used to be a team is now a person.

I’m looking back at all the tabs that you showed, and in some sense, that seems bullish for infrastructure. It’s bullish for GPUs. It’s bullish for Anthropic. It’s maybe bullish for Cloudflare. It’s probably bearish for the app layer broadly, because one thing you didn’t see is any SaaS app in any of that. It’s all just your own stuff.

Do you think we’ve passed thresholds where the software engineering job apocalypse is inevitable, or do you think there are still thresholds to come? Or maybe we’re just somehow going to have so much demand for software? I have a hard time seeing that one, given how easy it is to create one’s own little nest. But what do you think the future of the industry looks like, and are there any key moments or key unlocks that you’re still looking for before you would change your expectations?

Yeah, great questions. I don’t know. This is one of the big questions, right? The number of engineers we need per line of code is plummeting. The number of lines of code is soaring. Does that add up to more jobs or fewer jobs today? In 3 months? In a year? In 2 years? I don’t know.

I do believe we are going to be building so much more software that it’s possible that Jevons paradox is going to maintain its strong track record, and the number of coding jobs will go up, not down. The nature of the job will certainly evolve, almost to the point where maybe a few years down the road, the accurate statement will have been that, just like in the transition from horses to cars, the number of transport-related jobs increased, but they were not at all the same jobs.

Maybe software engineering is dead, and full-stack product manager is the giant new job market or something. Maybe they’re different jobs, and it may not always be the same people doing them. I don’t know, but I think it’s very plausible, maybe even probable, that the number of jobs isn’t going to go down, at least until we get to a point where all the jobs—or at least all the nonphysical jobs—start going away because AI is just better at everything. Short of that, I wouldn’t be surprised if there are still lots of human beings involved in software development.

But what does that mean for SaaS companies or whatever? You didn’t see me running any SaaS apps, partly because I didn’t bother to show that part. People have seen Slack before. So I’m still using Gmail. I’m still using Slack. I’m still using WhatsApp. But I’m mostly using them as a backend service. I spend less time in their UI, and I care less about their feature set.

This is another tug-of-war that’s going on right now, and we’re seeing this play out. A lot of companies are flirting with cutting off API access. Slack has talked about this. Companies don’t want you using it—they don’t want your agent, your Claude, or whatever third-party agent in their app. They want you in their app. Amazon restricting shopping agents and whatever. So there’s a real tug-of-war here.

It’s in the service provider’s interest, probably, to keep you in the app, because then you’re more locked in. You’re getting deeper value out of the app. You have more of a relationship with the app. But it’s in the user’s interest to be able to use the best agent for the job, whether or not that’s a first-party agent or a third-party agent.

I don’t know how that tug-of-war plays out. Salesforce may decide to really lock down API access to Slack, so your Claude can’t talk to your Slack. My vibe-coded app can’t talk to my Slack. And if they do that, their customers may roll over and spend time in Slack, or they may move off of Slack. I have no idea how that’s going to play out, and it’s going to be different in a lot of different domains.

Until several revolutions from now—until things have really changed a lot—we’re not going to be vibe-coding our own private infrastructure. There’s going to be a need for Amazon S3 and Google Spanner and the big data-backbone apps, and probably the next level up from that: Slack and Salesforce and whatever. Maybe not Salesforce as a UI, but Salesforce as a place where data lives. Or, if not Salesforce, then at least certainly the broad database level.

That stuff is not going to go vibe-code until everything is—until you have Jeff Dean on the command line. And that’ll be a while. I’m being very vague because, at least theoretically, that’s not the next shoe to drop.

How close is Mythos to Jeff Dean, though?

I only know what they said in the model card and whatever. I think it’s still not very close.

Actually, let me come back to—I want to talk about threshold effects for a second, then I'll come back to that.

I don't know what specific next thresholds I'm looking for. I can't guess what it's going to be, but I was thinking about this a little bit. We all talk about it like AI agents—or, sorry, AI capabilities—and o4.7 just dropped. What's the new thing it's going to be able to do?

But all of us, in our day-to-day, as we're engaging with these tools and living through the impact of these tools on the world and the environment we're in, we're not really engaging with model capabilities. We're engaging with a whole complicated ecosystem of what the model could do if you prompted it well, how well people are prompting it, who's using it and who isn't, and what second-, third-, and fourth-order implications that has. I think this is where the threshold effects come from.

ChatGPT's launch was a moment. Multibot was a moment. Not because that was the day the scaling curve crossed some threshold, but because that was the contingent moment when capabilities had gotten far enough, and then someone happened to do something in a way that caught people's attention.

It's a little bit like there have been coronaviruses circulating in bats that have an R of 0.9 in human beings. Every now and then, one will cross through a human being and maybe infect 2 or 3 more people, then peter out. Then, one day, there happened to be one that had an R of 1.1, and it infected a couple more people and a couple more, and then it was evolving and getting better at spreading in humans.

That was a threshold effect where suddenly COVID exploded through the human population, but only because of the dynamic effect. It wasn't about what that virus did in one person. It was about the way it went from person to person to person. It was the co-evolving system of people and virus that had tipped over into a new domain.

At a more complicated level, that's what's happening with AI. I'm part of a big cohort of people who started Claude coding in December because 4.5 was out and we had the December break. A lot of this wasn't just because of a specific new capability. I was reading other people saying that 4.5 was worth trying.

So, going back to Mythos and Jeff Dean, and maybe generalizing the question a little bit, either we haven't seen Mythos or we're sworn to secrecy about our access to it. I haven't seen it. You may be sworn to secrecy.

Here's another quote that I pulled from “Second Thoughts”: “AI's impact is the product of 8 separate factors: pre-training, post-training, inference compute scaling, agent scaffolding, app design, user aptitude, workflow refactoring, and adoption. All 8 are advancing, some quite rapidly. They will multiply out to a blistering pace of change.”

It's a little silly to be speculating too much about a model that we haven't seen, but the thing that stuck out to me the most, and that had me thinking, “Jeez, I don't know, maybe it is entering Jeff Dean territory,” or at least could be a major Jeff Dean multiplier, was Nicholas Carlini's statement that he had found more bugs in the last few weeks with Mythos than, I think, he said he had found in the entire rest of his 15–20-year, storied career combined.

Maybe I was asking the wrong question, because it's less of a substitute and more of a complement, or more of a multiplier effect. But, to juxtapose that quote, I've also felt at times, in other things that you've written and in some conversations, that you've been skeptical of the most singularity-near kinds of takes.

Where are you now? Are there places where you still see reason to be meaningfully skeptical, or are you thinking, “Yeah, we're headed to Jeff Dean territory at some point. It's just a question of exactly how many generations and how many months that may be”?

Yeah, we haven't seen the model, and so I'm going to talk about why I still have some skepticism. Before I forget, it's getting a little harder to maintain the courage of my convictions here.

The way I think about it is that the tug-of-war in the conversation is: either, “No, these things still aren't that capable. Singularity is really far off,” or, “Are you kidding me? Mythos found vulnerabilities in everything, Nicholas Carlini said that, and look at all these amazing things they're doing.” So, it's as if you either have to say the models are amazing and we're basically at AGI, or the models have all these flaws and we're so far from AGI.

What I think is that the models are amazing, and we're still far from AGI. The point is that the term has gotten so useless. But something that's Jeff Dean and Terence Tao—you know, pick your example—something that's all the smart at all the things and in all the human ways, I still think we're quite a ways from that.

As someone said—I think it was Helen Toner—“Long timelines aren't what they used to be,” and quite a ways might only be 5 years now, which is a remarkable thing to say. But I still think it's some distance away.

The depth and range of human capability—the kinds of discernment and judgment and depth of pattern recognition that go into human expertise in whatever field—I think we're still quite a ways from. It's hard to remember how much that encompasses.

We see Mythos, which is an absolute beast at identifying certain categories of security flaws and—ooh, big, scary new step—actually piecing together working exploits for many of them. Score a point—put 300 points on the board for models. But I think “all the smart at all the things” is 50,000 points. We forget how far off that still is.

In part because, on all the easy things, you ask it a question and it has an answer, it's hard to dig down deep enough into the model now to get to the point of lack of capability. You're not going to get there in a chat session. You're only going to get there in some really serious work.

I think there's a little bit of a blind spot. We don't ask it to do the things it can't do because it can't do them, and so we don't see people talking about it doing them. I find it harder and harder to articulate what I mean, but I have a strong sense that there are whole categories of things that AIs still really can't do that we don't even think about when we think about AI.

AIs couldn't have a dinner conversation with my wife for me, obviously, for 100 reasons. Some of that is just dumb reasons, like it doesn't know the history. But I think we therefore also don't think about all the really subtle capabilities that it's probably missing.

That was kind of a silly example, but I find it frustratingly hard to come up with good examples of what I'm talking about, which makes me worry a little bit that I'm full of it when I say this. But that is my gut. I find it harder and harder to come up with reasons not to think some sort of singularity is near.

Obviously, the physical world is lagging. That's one massive category. Although, you look at some of these things, and it's hard to evaluate. We don't typically get our hands on the actual humanoids in the same way, but some of the videos are starting to look pretty impressive.

I think they're probably still ways away from coming in and doing plumbing in my 100-year-old house, but they can handle rough terrain at this point. That's pretty clear.

I'll tell you a few specific questions I have, because, again, it's getting harder and harder to confidently say that we're not on the cusp of some kind of recursive self-improvement takeoff. Three specific things I think about. Let's see if I can remember all 3.

The first is that, clearly, the models are roaring through software engineering and into other AI R&D—experiment design and so forth. One thing I just don't understand is: How deep is that rabbit hole?

What I would love is for someone who really knows—there are probably about 1,000 people in the world who could do a good job of this, but most of them are in a position where they can't do it—to explain what really goes into making the models better.

We know there's a lot of coding. We know there's thinking about ways to tweak the learning algorithm or the data curation or whatever. We know there's designing RL environments. But what do you really need to know? What's the set of skills you need to build an RL environment?

What's the difference between a junior developer and someone who's been building RL environments since the beginning of the project that became o1 and has several years of experience at it? What taste, judgment, and discernment go into making a useful RL environment that's really going to push the models' capabilities? What kind of subtle judgment do you need there?

What other things are there? Is there some other big aspect to it, like knowing how to manage the process? Is it still important to have 10,000 human experts weighing in on a bunch of different subjects? Is there some very high-level skill in knowing what questions to ask the human experts and how to manage that? How much is feedback from people using the models, and what are the high-level skills in making use of that?

What is the list of capabilities that have to be checked off for the models to really automate their own improvement? And are there sections of that that don't look very much like continuing to get better at coding? I don't have a feel for that.

And I wish I did. I wish we knew more about the higher-level and more obscure corners of making models better. So that's one question. You could tell a story that we're within a year of automating AI R&D. You could tell a story where, somewhere in that ramble I just went through, there are some pieces that are going to take significantly longer. I don't know which.

Then, supposing that hill gets climbed, we're going to have agents that are superhuman at coding, superhuman at math, and superhuman at all the easy, objectively gradable stuff. How easily does that generalize to being superhuman at marketing and business strategy, managing a team, teaching a class, and a lot of softer and fuzzier skills? What about product design, physical and mechanical engineering, and all these other things that aren't physical-world tasks but bleed into the physical or social world?

When we automate AI R&D, are we then going to slam to the top of all those other skills, or is there some AI-as-normal-technology factor that's going to get in the way? And then the third is robotics. I hear a lot of people say, “Don't get too impressed by the videos,” because there's a very big gap between a robot that can be scripted to do a predictable thing once and a robot that can incorporate tactile feedback, have real-time reflexes, and deal with a messy task over and over again in its messiness.

But does that mean we've got another Rodney Brooks—30 years or 50 years of whatever? I'm not sure I'm characterizing him accurately, but do we still have a long, long, long way to go, or is the superintelligence we were just speculating about going to slam through the rest of those tasks as well?

Yeah. Certainly, robotics at a 50% success rate on tasks will not cut it in one's home, nor will an 80%. But we do see self-driving working at a level where the thing I say to my dad, who's a skeptic of self-driving, is: when the insurance companies start offering you discounts for using it, now you kind of have to believe the hype, right? They are very, very incentivized to be very skeptical about it.

I'm a big believer. I feel like Waymo, at least, has arrived. I'm less clear about the other providers, but certainly Waymo has, and that's a very solid existence proof. It's clearly safer. There are edge cases where it maybe isn't, but on balance, I would much rather Waymo be driving than me driving. I would much rather Waymo be driving than the people around me.

But again, that took decades and decades. There were over and over again overly, dramatically overoptimistic predictions. We're still not all the way there. Waymo is still not in public service in the snow, and there are all kinds of edge cases that haven't been crossed yet.

One story is, “Okay, we've got another 30 years to go on robotics,” if you go by that example, or something. I don't know if it's 30 years, but a long time. The other story would be that, by the way, this is still a fairly limited domain, and one where “Okay, I give up. I'm going to pull over and stop” is a button you're allowed to push. You can push that button more than once.

In some ways, it's still a relatively controlled, limited domain. There's only about 2 degrees of freedom on a car: fast or slow, left or right, as opposed to the number of degrees of freedom in one finger. So you could tell a story that robotics is hard, or you could tell the other story: robotics is hard, but we're going to have superintelligence, and it's going to plow through the hard. I can't rule that out, but I don't feel like it's demonstrated.

One little aside, just to check in on, is the relationship between AI and climate. I actually just learned in preparing for this conversation that, prior to focusing your sense-making abilities on the AI space, you were focusing on trying to make sense of the climate questions. One of the posts from the climate era of your writing was basically saying it seemed like AI was not going to be a big deal for emissions. I did an Andy Maseley episode, basically trying to make that argument from a bunch of different angles.

Have you seen anything? This could be a very simple “Yep, no big change” answer, but has there been any change to your worldview about the intersection of AI and climate?

I don't follow this as closely as I used to. My sense is I was a little bit wrong because I didn't anticipate just how rapidly data centers were going to scale. I think I over-indexed. Two things have changed for me. One is just that electricity usage from AI has increased substantially and seems poised to keep increasing. We're in an exponential, and every year the exponential is much more dramatic than the year before.

The other thing I did not see coming is that, in the land rush to get more gigawatt capacity for data centers, the hyperscalers are, to my understanding—I’m not following this closely—really backing off on their climate commitments. There was a lot of really good talk and action. Microsoft, Google, and a lot of the hyperscalers were doing really good things for climate. They were early purchasers of various forms of clean power and real hard offsets.

Again, to my understanding—I’m a little fuzzy on this—there are certainly examples like xAI opening the classes data center and trucking in the quickest, least-efficient gas turbines they could find. I think the other hyperscalers are also doing that. They're getting whatever power they can, even if it's gas or something. It certainly seems like there's some of that going on.

Those add up to AI using a lot of power, and a lot of it isn't clean power. That's not good for the climate. I still think that, even from a climate perspective, that's not the main story. The main story is that AI is going to reshape the world, and the broader effect is either going to lead to advances in materials science and other things, and we're just going to solve batteries, find ways of turning all of our messy petrochemical-based chemical processes into clean or cleaner electrochemical processes.

If AI increases emissions from electricity production by 20% globally, which would be huge, you could also see a world where it's making the overall planetary industrial base 20% more efficient: micro-targeting, robotic agriculture, using robots to kill insects instead of pesticides, more carefully targeting fertilizer, and all these things. It would be easy to see the reduction in emissions from the rest of the economy outweighing the emissions from generating electricity, especially because, in the long run, solar primarily and various other clean technologies are going to make economic sense at scale.

We're not going to be building a terawatt of gas-generation capacity for the terawatt of data centers someday. That's going to be cleaner. The technologies that are going to make economic sense at scale are going to be clean, it still seems to me.

In the big picture, in the long run, I feel like it's probably going to be good for the climate. But also, just generally, AI is going to roll the dice on the whole world, and climate is going to be along for that ride, whatever direction it goes. In the short run, we may be burning more fossil fuels to power more data centers.

Cool. Thank you. Great answer. That whole note on rolling the dice with the whole world is maybe a good segue to the last section I had for you, which is basically: what's going on with the Golden Gate Institute? I've had the good fortune of being able to attend The Curve the first 2 times that it's run. That's been a well-loved and much-discussed event, but it's certainly not the totality of what you guys are up to.

So tell us what the mission is, the range of activities, and how people can support or find ways to get involved, get on The Curve waitlist, or whatever the case may be.

Yeah. The Golden Gate Institute for AI is a nonprofit I co-founded last year. Basically, our mission is, as you said, as we get ready to reroll the dice on the whole world, AI is moving forward so rapidly and having impacts and promising further impacts, and we're all having to navigate this—individuals, consumers, business leaders, policymakers, civic organizations, civil society.

Everyone either has or is going to have some role to play in how AI plays out, and certainly is going to have to prepare for, react to, and steer through a lot of changes, direct and indirect.

So there’s a lot we all have to collectively figure out, and it’s really hard. You and I just had a 2-hour conversation about how much trouble we’re having keeping up and predicting what’s going on, and that’s sort of both of our jobs. It’s really hard to make sense of all this, and our mission at Golden Gate is to try to contribute to that collective sense-making project.

The main way we do that is by addressing the problem that there are so many different pockets of knowledge, expertise, and viewpoint. Understanding what’s happening with AI is a computer science and machine learning question. It’s an economics question, a cybersecurity question, a biosecurity question, a labor market question, a political question, and an education question. No one person and no one group has all the information, let alone all the perspective, let alone all the answers.

There are all these isolated pockets of people in a particular field, people in San Francisco versus people in Washington, D.C., or people on the political left and people on the political right. All these groups are figuring it out on their own and not necessarily engaging with the other groups. Our mission is to bridge those gaps.

We do that through publications like my blog, Second Thoughts, but a lot of it we do by getting people together in person. You mentioned The Curve, which is our flagship activity. It’s a conference we’ve been running annually where we get together about 350 people from every one of those communities, from every walk of life and certainly from the broader AI multiverse.

We’ve found that when you get people together face-to-face—it’s trite, but it’s true—it really changes things. People who have been yelling at each other on Twitter, or more often just ignoring each other, will have a conversation. They’ll find things they have in common. They’ll remember that the other person is a human being with reasons for their viewpoints or whatever.

We really see things coming out of this. We’ve seen projects come together and new working relationships develop, but also more engagement and a breaking down of some of these barriers between the groups. I should have a better answer to what’s helpful off the top of my mind, but we’re about to announce the date for this year’s conference. It’ll be October 2–4.

A big part of what we’re able to do is a function of our network. The more people we’re connected with and the more directions we’re connected in, the more we’re able to do. For example, it’s been hard for us to really connect with some of the communities outside of the U.S., first and foremost in China, but also in every other part of the world. We’d like to build our network more there, and we’re not as connected as we’d like to be in the robotics industry, just for another example.

We’re very small, but we’re expanding. We’ve been growing the team, and we’re running The Curve again this year. We’re hoping to run it twice next year. A year is a long time in AI. My colleague Taran was joking that we probably need to double the number of Curves every year going forward. We’re going to be doing more, and there are going to be more opportunities to get engaged, so if you follow us, we’ll be talking about these things.

Cool. This has been excellent. I’m already looking forward to adding many enhancements to my personal productivity setup based on all your examples. Is there anything I should ask, or anything you would want to leave people with before we break?

No, that was great. I was just going to say this has been a ton of fun. I love the podcast, and it’s been really fun to get to be on this side of the microphone because you ask really great questions and you’ve got me thinking about a lot of things. Thank you.

Thank you very much. That’s very kind. Steve Newman, thank you for being part of The Cognitive Revolution.