Honest conversations about fear, uncertainty, and what it means to build things when the ground keeps shifting.
Season One is sponsored by WorkOS and Augment Code.
I'd like to thank Augment Code for sponsoring this first season of Still Burning. I can remember my excitement when I saw my first IDE. You could find anything, you could
change any code, and I was just so excited. But the era
of making changes to code like a watchmaker is gone. Most of the changes now are going to be made by the Genie, and Augment
Code is helping go beyond the IDE with their new intent product. Programmers stay oriented, they
keep learning, they see what's happened, they make strategic decisions, and meanwhile, agents go and do the detailed work.
The gap between an idea and a running system has never been narrower, and that's exciting. The gap between a running system
and a mature,
fully running system is the same as it ever was.
And the difference is not feature set, the difference is trust. Security, auditability, identity, the list of items a CISO
hands you before your system will run in their system. Teams try to tackle this themselves. How hard could it be? It turns out that this is both a very important problem and a very complex problem.
That's where WorkOS comes in. Single sign-on, identity providers,
role-based access management. WorkOS gives you the infrastructure to trust the systems that you're excited to have built.
Keith Adams, welcome to Still Burning, where we talked to geeks who still care and are still doing something about it. And I can't think of anybody geekier than you who cares more and is still doing so much about it. Thank you.
It's a huge pleasure being here with you. You know, like, we have a little bit of history and this isn't the first time... Not the first time we've talked... Not the first time we talked in front of a fire at dusk about software either. And we'll see if we can keep it PG-13 this time.
So when did you first know that you were a geek?
Oh wow. Well, so I wasn't exposed to GeePaw Hill. I was brought up in Reagan's America, so like for me, geek was, you know, term of abuse. And so I probably found out I was a geek from all the people telling me I was a geek as I was being sort of shoved into lockers and being held upside down by my ankles and so on. And then all those kinds of experiences you might know from coming of age movies from the 80s. So I think it was a little bit thrust upon me. My attention was called to it if I'm not going to wear it. But I think... Was that high school, junior high? Yeah, more like junior high. Okay. Yeah. My high school people were sort of a little bit more civilized for the most part. But
I mean, I guess like I've liked computers ever since I knew that they were kind of thing that was around. I think in hindsight, I come by us a little bit honestly. My dad was an officer in the Marine Corps. He was a career officer the whole time, my whole childhood. And I can go back, it's all matters of public record, but he bought an Apple IIe in 1983, I believe. We're still in DC. And at that time, the take-home pay for his grade in the U.S. Marine Corps was $30,000. And the sticker price for an Apple IIe is $3,000. So this was a major investment. And if you're an artillery officer, there's not that many things Apple IIe's in 1983 really do for your job. You know what I mean? There's spreadsheets and there's like a little bit of stuff. But honestly, you just kind of saw the potential of these things and were excited about them. And as soon as that thing was in the house, I kind of wanted to know everything about it.
It seemed like this kind of portal that directly connected the world of things, because it's obviously this hot object that makes noise in the room and does stuff. And the world of ideas, right? Because the software part of it was obviously kind of almost the pure stuff of thought in a strange way. And I guess it's always like a kind of a remain fasting with that hardware, but
there's different flavors of computer people or whatever. And I kind of temperamentally ended up being a systems person for most of my career as a computer guy.
Talk a little bit about what you're doing now and how that transition happened.
Yeah, that's amazing. So I am about four years into a career transition into venture capital. I had a career. I was really fortunate to visit all my dreams as a software guy in many ways. I was a relatively early person at VMware. Was there a 2000, 2009, got to do a bunch of cool hardware software interface stuff there about the PC and it's 86 and everything.
Was relatively early at Facebook where we met in the early teens. Built HHVM there, which is the JIT compiler that was running the application for the big blue site at the time. And then was part of the generation of computer people that got fired up about deep learning in 2013 because of what was going on in the ImageNet competition. So for those of you, the first sort of rumblings of the AI revolution we're living through and that we'll probably be talking about a lot today, for me at least were when computer vision stopped being a sort of aspirational term. Like, circa 2013 or so, computers didn't do much that you organically called vision. There were a few things that kind of could work if you set the problem up in favorable enough way. But in most ways, your computer was as likely to think a leopard was a motorcycle as it was to think it was a house cat.
And that got me really fired up and I made a little demo along with a couple of other engineers and we brought a little bit of time on Zuck's calendar. And to his credit, he understood what we were doing and was really excited and gave us a ton of resources, a ton of his time to go out and hire a crack team, and built the lab with Yann LeCun, who ultimately took it over and built it out over the next three years with him. And I was chief architect at Slack for a bunch of time. that the Slack guys in 2015 at a mutual friends dinner party thought they were amazing, thought the product was amazing, thought Cal and Stewart were incredible guys. And they're just like different,
they're smart and broad and interesting in different ways than many other founders I'd worked with. And they were having some tech problems that rhymed a little bit with tech problems we'd had at Facebook because they were an overgrown LAMP stack too and so on. So I was at Slack for about four years, kind of did everything that I hoped they're honestly,
Slack went public and prior to it getting rolled up into Salesforce actually, I left thinking it was time for me to figure out what was next. And that happened to be a couple of weeks before the pandemic, before San Francisco locked down for the pandemic. It was like February 2020 or whatever. And that kind of interfered with my job hunt as I was framing it, but what I ended up doing instead was spending a lot of time with the early state, with founders who were at relatively high points. And me being, I guess your definition of geek, the kinds of folks I found myself working with a lot of times, what they were doing had something to do with some kind of technical insight, that's something to do with some connection they've made between fields or like some trick they've figured out that nobody else did or some problem that's important, but maybe a little nuance to understand why it's an important problem that they had an inside track on in some way.
So this was not
just copying the SaaS playbook, LTV, CAC, blah, blah.
Yeah. I mean, so this is, we're probably dating ourselves already with the SaaS talk, right? Because you'll forget that this happened, but the last business cycle for startups was kind of dominated by these software as a service startups where the business part of them was sort of so legible and so repeatable and so structured that there was, it was just kind of the right way to business. It was like, find some vertical that had some itch, scratch that itch,
you know, build a software product, harvest 80% margins on it, loudly rinse, repeat.
And there were certain metrics that you just knew,
if this plus that was greater than 40, then you would get the real 40 stuff.
Yeah. Yeah. There was, it's true that to a surprising extent for SaaS, the business is so you can kind of like have six to nine figures of merit that like pretty accurately characterize the health of one of these businesses.
So like the CAC Joe, this customer acquisition cost, where it's good if it's cheap to get customers, it's bad if it's expensive to get customers, like,
you know, your churn, you're gonna have dollar retention, your bulb, like there's a handful of them that kind of pretty thoroughly characterize it because it's really easy to read out, right? Like the business just is, you know, we have a bunch of AWS machines over here. We've got a, you know, a market over there of people that are, you know, we've been an accounting package for the construction industry or whatever.
The construction industry has, you know, so only so many firms and only so many needs for these kinds of accounting packages or whatever. We're capturing this much of that market. Therefore, it was all relatively straightforward in terms of that.
And in that world, by the way, if you're like building a accounting package for the construction industry, like taking a bunch of technical risk in the way that I'm describing is probably kind of dumb, to be honest, right? Like you don't have to. Yeah. Why do it? Right? Like it's a bunch of unrewarded effort.
You know, you're going to get out competed by somebody that just did the straightforward thing.
So that was kind of the previous generation of what like savvy, you know, business entrepreneur types who are building software businesses were doing. And I was just sort of a little bit sick of it. I mean, like, for what it's worth, Slack is kind of an exemplar version of this. Slack is a SaaS business. It is software as a service, but involved a bunch of sort of product invention and sort of kind of invention of a market that wasn't obviously there before. It wasn't clear there was a need for like real-time communication in all these businesses before.
And it, you know, its ability to compete involves sort of like geeky or more enjoyable competences than just sort of like, oh, there's, you know, low-cac and low-churn and high in a dollar retention or whatever, though it had all those things too. And when I sort of started working with these early stage founders who were maybe trying to do something with AI, this is sort of before chat GPT, right? So this is like a,
that's when it was not cool yet. Right.
So it's difficult to articulate to investors why they should care about machines that think because the machines don't think yet. The machines just sort of sit there and turn through stuff or,
you know, it wasn't super clear like that there was going to be huge demand for this or that the models were going to get a lot better or any of this stuff. So I was excited about working with these kinds of technically ambitious founders. And I also had a hunch that they were tired of having their investors be kind of low context finance pros. There's a lot of self-deprecating humor in the venture capital industry. Like you're kind of required to like make fun of how we wear vests and, you know, pay our fin reduced.
Yeah, I noticed you.
Yeah, I wear the Patagonia puffer, for instance, because like, you know, the union dictates that I wear it. Okay.
No, but there's lots of self-deprecating humor there because like part of it's partly true that a lot of what venture capitalists do for their companies is like provide resources, right? Like if, you know, to some extent that part's fungible and like, yeah, I can dress it up in a brand and like sound smart when I talk about my venture capital firm and that's, you know, maybe reflects well on your company and that's, you know, there's some social signaling there or something. But a lot of what we do is like get people the resources they need and try and get out of the way when possible. But it's still kind of an intimate relationship. And we're one of the few people in these folks's lives where I'm not their employee. I'm not their co-founder.
I'm not their competitor. And there are things they can tell me and that they want to be able to tell me that they can't tell too many other people. And we had this hunch that people wanted their counterparty in that relationship to be one of them, right? To be their people, to be somebody whose values were sort of technology values. And he's going to understand what you're saying too, right? You're not going to have to get out the sock puppets every time if you're like, okay, a model is a big bag of floats that, you know, these parameters somehow describe a function and then we teach the function. What function does it really know? Yeah, I get it, man. It's a model. It's okay. We could get
straight to it. I never understood that until that moment. Thank you. And of course, like
this, we could be done. Do you need? No, no, no, no, no. I'm not accusing you of being low context finance bro here to be clear. I'm aware. But like, and this is like leaked out by the way into the, like every random BC now, we'll sort of be like, well, are you, you know, are you doing some L2 regularization? Like, are you, you remember these dropout or like, they've got a few things from like a Coursera course or whatever that they can bust out.
So it's an addition to watch that happen. But anyway,
it took us a while to figure it out, but myself and my partners, Tammy Sue and Pam Vigata eventually realized that what we're talking about here was like a different kind of venture capital firm. And since all of us are builders too, and, you know, our geeks and the definition that you're, that you're putting forth here, we also implicitly ended up making a technology company too, right? So Pebblebed views itself internally as a tech company. We do the things that tech companies do. We build, we try and sort of
view ourselves as a machine that improves from every, you know, deal we lose and every deal we win and every contact point we have and every sort of signal that we're able to harvest out there.
And I think like they're that sort of talk about that is cheap, but I think being able to build software is still a little bit of a rare commodity for, for, for venture firms. So it's called Pebblebed.com. You know, if you, if you're a geeky friends or looking for investors who understand what you're doing, not as a spherical cow that is parameterized by the power law or whatever, but actually cares about like what computer program you're writing. What goes inside this? Exactly. Exactly. Because I go to the innards of the spherical cow.
You know, we might be an interesting firm for you to talk to.
Well, that's an example that, that transition from the SaaS playbook to the, to the venture world is one of my themes, which is that software development as a whole has had a playbook for about 20 years. It's been remarkably stable. It has. And you need more
reliability. Here's five ways to write tests. And if you need the, the, and you can get better at applying that playbook because our tools have transformed so fundamentally all the trade-offs that we were used to, all shifted, like
writing code is free, not exactly free, but sometimes you can treat it as free. And then sometimes it comes back to bite you. So that playbook that we had, people kind of mid-career who are used to being good at the playbook and knowing those answers, they turn to the playbook and it's blank now.
Yeah. Yeah. And we're talking by the way, just for future viewers, right? We're talking in spring of 2026. The revolution we're referring to, I claim started in undeniable terms, at least in November of 2025 with the release of Opus 4.5. I think prior to that, you still saw people that were kind of resisting the use of coding agents and sort of were saying, Oh, I spend so much time reviewing the code by hand. I might as well have just written it by hand and so on. Whereas I think for people of a serious disposition of these tools, if you're ignoring those tools entirely post November of 2025, I think you're fooling yourself and you've got your head in the sand or you're overly attached to this kind of old way of doing things. And I think
everything's moving so, so fast that I don't even know how legible this moment's going to be in a year or two. Yeah.
Yeah, absolutely.
But right now, I think we're in a moment in the profession where the perspective that these tools have already changed everything is pretty, pretty digested. I think most people have their heads around not including people that don't think it's good news. I think they still accept that these tools are permanent part of the workflow. And as you said, like it's a thousand flowers are blooming out there in terms of like how people actually build teams and how people make this work. That's actually been a little bit of a, yeah, this is a
moment while we cough and blink. This sounded like such a good idea. Like still burning cinematics here.
Awesome. Burning. Yeah. And then he is flawless.
Yeah, exactly.
Anyway, I'll share my life for this fricking podcast, man. Thank you. That's worth it. How many is my gotta do?
Sorry.
Playbooks, playbooks. Right. You used to be a playbook. You used to be a playbook. And like, there have been
maybe a year from now we've settled on a playbook. Like Steve Yegge is right. And it's all about beads and fricking weasels and whatever. Yeah. And strange metaphors. I don't understand.
I'm a little skeptical personally, but like, Hey, he's out there trying and he's doing stuff. So like full respect, right?
So maybe things have settled, but right now it feels very fluid. It feels like it could be anything. A lot of brilliant people I know are trying different conceptually incompatible things. Yeah. And to be honest with you, I don't know from first principles, which of them are going to meet with success. It seems like there might be more than one
way to do it. Yeah. Multiple attractors in the space. Yeah. Yeah. So
I think a lot of, but there's a lot of fear. There's absolutely a lot of fear. Yes. I hear from parents of college sophomores, my kids, you know, second year CS student, he's thinking of moving to something more commercial like medieval history. Right. Right. And
excuse me. And
I don't,
and part of that fear is nothing like this has ever happened before.
Right. So I'll date myself a little bit here too, by the way, if you feel like if I can have a softball here.
Oh yeah.
So I started my CS undergrad CS degree in 1995. And one of the I remember that date is just because 1994 is when Ed Yourdon, who was mostly an OOP like advocate, right? He mostly wrote books about how to do various things about object oriented methodology, which was like a new topic in the mid nineties, right? We were trying to figure out what to do with all this stuff or felt like a new topic to the vast majority of us unwashed masses, writing C code and stuff. He wrote a book called The Decline and Fall of the American Programmer in 1994, which was a provocative title because it was seen as sort of a prestige profession or somewhat up and coming. And I mean, I should say, by the way, like a joke I used to make in my undergrad CS that you can't make anymore was like, yeah, I got into CS for like the women and the money. Yeah. Right. And it's funny because there's no women, but it was also funny because there was no money. Right. Like it was like being a dentist or something. Like you kind of like have a decent upper middle class existence or whatever, but there weren't these like kind of sports star style outcomes that are, that are now sort of very heavily publicized. Right. Anyway, Yourdon writes this book. What could he possibly be on about in 1994? Well, he observed two macro trends, right? And one of the macro trends, which required real vision in 1994, or record real imagination was, was just globalization. Right. So why would I pay Kent Beck to sit on his duff in San Francisco for a hundred thousand dollars a year, right? The astronomical fees that these crazy entitled American programmers want.
When I could literally have some cracked kid in Estonia, write the same software for $10,000 and I could email him the specification and he could email me the tarball of the software back. Again, that's how he's going to happen. Right.
And you know, I, I, why in the world would there be American programmers in a loop when that's going to happen? And you might say, well, there's just going to be so much software that we'll need all hands on deck. And, but no, no, no. The other trend he identified was arbitrary programming and arbitrary and program. I know that you're familiar with this technology, but
for those falling along at home, it's kind of hard to capture the amount of bullishness about this paradigm
that was just in the water. But like every sane thinking computer programmer that was vaguely future looking and vaguely excited about technology just thought he was going to change everything. Yeah. And you know, he basically was like, this is going to make software so cheap to write, so easy to reuse, so easy to plug and play, and so modular and so safe that we're only going to need like 10% of the programs that we have to satisfy the demand for software. So between the sort of, you know, 10 X deflation from everybody's in Estonia and the 10 X deflation from, we don't need as many of you. There's just going to be like 1% as much money being spent on programmers and all you Americans who are like getting CS degrees and so on. You better get real jobs because this is going away. Right. And this was enough. This is sort of a tightly enough argued thesis that on day one, the lecture, the first lecture of my intro CS class, I remember the professor pulling this book out a little bit and being like, Hey, everybody, enjoy your liberal education in computer science. It will train your mind. It's an interesting way to view the world. You know, these problems have intellectual value of their own and the life of the mind has is satisfying in its own way, but you should not expect there to be jobs waiting for you upon graduation in 1999 because you know, pop pop. So Jordan was right about these two things, by the way, right? He was right about globalization. In fact, he was like incredibly right about globalization. If you think about it very early, while maybe he was a little bit on the bullish side of the curve with object-oriented programming, like broadly tools, like, like the things that we use to make programs did get a lot better. We get a lot more productive. I'd offer as evidence that that was at least like a hundred X in deflationary factor. Even before a coding agents came along when he was writing that book in 94, writing a strong chess playing computer program was like a masterpiece. Do you remember this? Like if you could do this, you're basically like a senior staff engineer or whatever. Like you were at sort of a terminal career position because like you had to know so much about data structures, algorithms, how to squeeze performance out of the machine. It was a relatively complicated program to debug with the languages and tools at the time.
It just was not that accessible. Whereas now we teach it as a learning task for early students, right? Sometimes first year computer science students. So like
it's gotten easier to accomplish fixed tasks with the tools we have. And yet there are many more computer programmers in Aeron chairs in San Francisco, caching way larger paychecks. So what was the disconnect here? And I'm like, I'll pause here. I'm sure you've got your view of this disconnect.
Well, I mean, Jevons' paradox is the
classic where when you're spending too much on something and you make it more economical, more efficient, you open up so many more uses for that thing. So light bulbs, if you go from incandescent bulbs to led bulbs, you're actually going to consume more electricity because people find so many more uses for light bulbs than they had
before. If you're computing in terms of demand for light, it's going to, you're going to be making the wrong decisions. And yeah, so software's like roads, right? Like when the roads get better, people drive more and people solve problems with transportation that they wouldn't have solved the transportation before. And the same thing happens with software. Software gets better. We want more software and we'll solve more problems in the software domain because it has a network of ducks and everything else.
But that 30 years later, the same professor is probably there holding up a cloud code and saying, enjoy your liberal arts education. That's right.
In computer science. Tapping the transcript of Darjwama Dei saying, life, we're going to replace all these overpaid software engineers sometime in Q3 or Q4. But you know, it's starting to come due on that one. He's been writing about a lot of stuff, but we'll see if he's right about that one.
Yeah, yeah, exactly.
I tend to think that to try and spoil it here, it does feel like
while these models have like, you know, I got excited about AI 12 years ago, it's been sort of my primary professional preoccupation since then. I'm an AI bull, I'm not a tourist to this space, right? I think machines that think are going to be some of the most important kind of industrial changes that we're able to make as a civilization, I've still been really surprised. It's still good goosebumps, honestly, sometimes when something that you know would have been a month of your effort, you know, just kind of gets one shot or whatever and it happens more and more often. So I don't want to be glib about the role that humans play here or say like, oh, sure, they can do this, but can they do that? Can they be truly creative? Do they really understand the code that they write? Like, I don't know, man, whatever. It's a big bag of floats. The big bag of floats has gotten really good at writing code. Yeah. And really good at fixing bugs in code and really good at like doing a lot of the things that used to be, you know, me staring at a pair of curly braces and a blinking cursor being like, I don't know, it looks right to me. I don't understand how this could ever fail, but it did somehow. So,
but all of that said, everybody I know, myself included, like the more you use these tools, the busier you seem to be.
Yes.
And that's interesting, right? That sort of suggests that there's not a lump of software out there that we just need to churn through.
Fixed demand. Right. Yeah. Yeah. My career arc, at first, you don't know what would be cool to have as a software effect. And then you start building stuff and you realize, you know, it'd be really cool as if we had a thing that generated a thing and we, oh, we also should be able to render this. And then that means to automatically lay out the, and you, you start building up these things and, and you don't know any better. So you start building everything you think of.
And then you realize, oh, a lot of these are more trouble than they're worth. So that's the junior to senior. Now you know what you'd like to build. And senior to staff is when you realize it's not worth building most of that stuff. Right. Right. And then those ideas keep popping up, but they end up in the back of your head. And the magic that I've enjoyed is all of a sudden 30 years worth of, yeah, it's probably not worth it. Is all in play again.
Yeah. Let's see. Let's find out the flagpole for everything. Yeah. Realizing how ossified that circuit of my own brain is, like how like pre-verbally, right? Like before I even fully formed the thought of the thing I'd like to try that restricting loop. That's like too hard. You're never going to even feel it would take you a thousand hours to even find out. Don't even worry about it.
Like realizing that you can relax that muscle and actually just try for so many things has been incredibly liberating. I know like different people, you know, we've both had careers that are like multiple decades in software. It's natural that we're somewhat attached to, and our professional reputation are probably associated with like different methodologies and sort of ways to get things done. You know, you especially, right? Like you, you probably had a more influence on the way that we build software prior to coding agents than anybody else on earth.
But I think like once you get through the Kubler-Ross grief stages around the fact that like that's gone and it's gone, like it's not coming back. We're not going to reframe it. We're not going to anthropomorphize the agents and have little standups with them or pair program with them or anything. We shouldn't just, yeah, just yeah. Yeah. Exactly. Exactly. The agent can't drive. You're not, you know, just leave those metaphors alone because it's not clear the constructive metaphors that come from a world where software scarce, where change happens slowly, right? Where your code base absorbs a few diffs a day
and we only have to deliver that much change a day. We're going to need a different world. Change is going to be cheap. You're going to be able to do population-based things. You're going to be able to try it a hundred different ways or try a thousand different ways. And we need different metaphors, different paradigms, different ways of working. But once you like work through fact, that's sort of a bunch of your expertise and your ability to like, you know, know what a functional software team smells like and kind of just walk in the room and tell like, oh, these guys need to do blah, blah, blah. Like once you realize that ship is just completely sailed,
I think it's incredibly invigorating to realize like we get to live through a time where all of this stuff I wasn't sure whatever be built is going to be built for sure.
And we get to, we have a blank sheet of paper collectively as a profession right now to figure how we do business. Right. And I think the people that I know who are senior, who are sort of over those stages of grief and are busy playing right now are just having the time of their lives.
It's so much fun. I mean, but it does erase two of my books.
That's got to be a little rough. Yeah. Should we have a little book burning there? A ceremonial. I think that sends the wrong political message.
Yeah, I guess that's sort of the wrong image. If someone of a certain political persuasion wants to burn my books, I'm great with that. But I'm not going to do it. But I spent a lot of hours thinking about how do you craft the details of programs to communicate to other human beings. And it's just like horseshoeing. Yeah. You know, it was a craft. It was really important. And there's just no leverage being a better horseshoeer. Even the world's best.
Yeah. Yeah. So there's a little bit of nuance there, which is,
I was having a great conversation with a mutual friend, Jay, I'm fairly good. He was a great language designer, a design hack. I worked with him really closely when he was designing hack, and I was building the VM that ran hack at the time. And one of the interesting points of view he and I share a little bit about programming language design is that at least historically, it's actually applied psychology secretly. Yeah. That sort of programming language design is actually about the ergonomics of the human mind and how you sort of marry what computers can actually do to what humans can actually think about. And I think it's still true that it's applied psychology in a sense, but it's now for these alien minds. It's now for these minds that are different than ours and that you almost can study as if it crashed on a spaceship, right? Because if you look at the entire kind of
research program in mechanistic interpretability, they treat these things as if they landed from Mars. They don't claim to know anything, not priori at least. They only believe the things that can actually prove and measure about how these things work internally, right? They don't view them as engineered artifacts. They view them as almost natural artifacts. And I think there's something to be said still about
code bases that are legible to agents or legible to LLMs. I don't think we know much in a quantitative sense about what that looks like or how it differs from ones that are legible to humans. I think that's like a whole interesting direction where I could probably spend this whole time talking about just this view of things.
Yeah. The mental exercise I went through is if we invented a programming language that
humans couldn't read, but the agents were really good at manipulating. So we could never again code and predict what it was going to do. But we say, I want this feature and that feature would appear much more quickly, more reliably. Would we give up the ability to read the code? And then the second part of the experiment is why is that called APL?
Yeah, well, so APL, I
wasn't sure that that was where you're going, but there's a sense in which... So compilers used to be thought of as AI, like the people who worked on compilers were working in departments that had artificial intelligence or neurosymbolic systems or something in their name. And it turns out they're formal languages, but we didn't use to hold that against them. There was a paradigm that said, well, maybe human language was actually formal in the same way. It turns out it isn't.
But
we've given this up in certain ways. For the vast majority of C++ programmers, if I show them a bunch of LLVM IR, or they show a bunch of intermediate representation that LLVM uses, they've never seen it in their lives. They have no idea what it means. That is the coin of the realm on the inside of LLVM, like inside your compiler tool chain, it doesn't care about it in your curly braces and your templates and whatever. It triggers all that stuff away right away. All it's thinking about is this little graph and can serialize that graph into text, LLVM IR, that looks like assembly language for a weird virtual computer that has infinite registers. And that's all it thinks about.
For most humans, it's a bizarre implementation detail, unless you're in a compiler implementer, unless you're building a compiler pass for LLVM, in which case you care a lot about LLVM IR, because that's your input format and your output format.
So there's ways in which we've detached ourselves from this already.
I think that we can... And then we...
Unless you're a compiler writer, you never look at that intermediate.
Yeah, if you think you know what that is, I actually would challenge you unless you've done a compiler for a living for a while. Even if you conceptually grasp what it's supposed to be, if you actually try to find a bug in it, try to find a bug that is like, "We made the wrong LLVM IR for this," or whatever the SSA IR is for your thing. But that is kind of a specialized thing. Whereas going with this is that there are places where we've detached from that. And one of the reasons we detach from it is because C++ is still a formal language. And so as long as I can read the C++ and write the C++,
there at least exists in the mind of God some mapping from that C++ to that intermediate representation that's correct. And so maybe there's bugs in the compiler, but we've gotten good enough of compiler engineering that Rookaday programmers are sweating that on an hour to hour basis.
And we haven't gotten there yet with LLMs. You specify what you think they're supposed to do, and oftentimes it doesn't work.
I think until November or so, until Opus 4.5 or so, there was a contingent of graybeards who kind of would try that once or twice and then be like, "Ah, it's still nonsense. It's still all bullshit. It's still all hype. I thought it'd do the thing. It didn't do it."
But of course, if you instead get curious about like, "Well, okay, why didn't it do it? And what would I have to do to make it be able to do it?" And if you keep turning the crank on that and you find yourself developing an intuition for how you set up guardrails for these things to be able to more reliably stay in tuned with your will,
then we're starting to get somewhere. And I have a belief too that we'll eventually, for a lot of these things at least, we may never see the source code, but maybe it's proof carrying in some way. Do you know what I mean? Maybe we can say like, "Here are a bunch of formal properties of this thing you asked me to code that feels like you should care about them. And here is some formal reasoning that suggests that these properties really do hold." So I don't know what I'm asking for. I'm just like, "Give me a key value database. It needs to support arbitrary size transactions. Go." And then it would be like, "Well, okay, so serializability is defined as this. The database I wrote for you is serializable. And here's the proof that it is. And you can at least check it with a machine."
That might be better than you'd have done by trying to read the code and debug it yourself.
I'm sorry, we're starting to get into some of the details of how these harnesses might be in the future.
But you know. Well, you get two geeks in front of a fire.
Yeah. Yeah.
Stuff's going to happen. Exactly.
Exactly.
You have a son.
What are you telling him about this?
Yeah. So I have a son. He's just finished his freshman year in college.
And this is sort of often used as a rhetorical question. Like, "What do you tell your kid that just started college to go study?" It turns out he doesn't care about computers as a professional field. It's funny, because it makes this a little bit simpler. He wants to be a lawyer. And as far as I can tell, lawyers are fine. Because like the SLMs are good for legal tasks. It's just that lawyers are mostly not there because they can understand written words better than other people. Lawyers have a different social function. Hold that thought. If I had an arbitrary sort of geeky son or daughter who is excited about computer science, I would say just keep going with it. Actually, it's not super obvious to me,
at least so far,
that the fundamentals about who is able to excel at this have changed very much. And I think that's one of the things that has surprised me the most about this revolution from first principles. I kind of expected we'd get AI that can code somewhere maybe in my lifetime if I was lucky, but certainly in the history of this technology. But what I expected the effect of that to be would be to democratize and raise the floor. I mean, actually, the Apple IIe didn't do very much. And if you sort of asked employees at Apple what you're supposed to do with it, it'd be like, "Yes, you bought it. What do you mean? What do you do with it?" There's a program that's got AppleSoft Basic. There's a book about how to read and write AppleSoft Basic. There's 6502 assembly if you can't do things with the AppleSoft Basic. And you just do whatever you want. But it's a general purpose computer. What do you do with it? You do everything with it. And for like one-tenth of one percent of the population that's autistic enough, that was like all the guidance they needed. But for almost everybody else, that was not a lot of help. So what I expected to happen with this revolution was that it would be the fulfillment of that dream. That we sort of get personal computing finally. So now I can wake up every morning and have my own operating system just because I feel like it or make myself some bizarre version of Doom or all the monsters have Kent's face because I'm upset with you that day or whatever. And that's what computing is like now. And it seems like if anything, it's almost the opposite. The people who I know who are most engaged in a creative loop right now
are the people who are virtuoso creators already. They're the people who are incredible builders in the before times as well.
And it seems like if anything, this has been more of an amplifier of differences in facility than a leveler. Like expected to be a compressor instead of
spreading out the frequencies. But there's
a new foundation layer, a new bottom layer people who wouldn't have dreamed of writing a program before. No, for sure. So do you have a sense, is that like the same size as the previous bottom layer? Is it 10 times larger?
No, it's a really interesting question. And I think this is the time when people would say, my non-technical uncle, like vibe coded a CRM for his lawn care business or whatever, I'd be like, oh, you know, like something's going to break with that eventually. And he's going to want to be able to figure out who his customers are and be able to phone them and stuff. So I'd be a little nervous about that. But then after those ones, I was like, yeah, it's going to break. But like Opus for a second is going to fix it when it breaks, at least like people to recover it or something when it breaks. You know what I mean?
And, you know, there's some things about operations and like data and stuff that I think is still like meaningful
professional topics, by the way.
Stuff that's grounded in the real world and how databases work and where backups go and what happens when you drop a table and everything.
But I think, yeah, you're probably right that there is, there's undeniably been this democratization act thing that sort of moved a lot of people from zero to one. But the people who are already at a thousand are like at a billion now, it seems like, or at least have ambitions to be there. Maybe they're deluding themselves in some way or aren't as productive as they think or something.
One of the most fascinating, this is like a side tangent. I don't really believe this to be clear, but I still think it's like an intellectually interesting exercise. One of the more interesting suggestions I've ever heard was from, you know, one of the more safety pills people, people's like more concerned about sort of like rogue AI and how it might sort of, you know, cause civilizational scale harm. And their suggestion was that if you are an AI safety team or a team that does mech and terp, you should have at least one person on the team who doesn't use LLMs, just does not. I don't mean just a code. I mean like in your life does not have contact with this technology. And you might be like, okay, what are we getting at here exactly? And the idea there is like, it is at least possible that there's a slow con. It's at least possible they sort of insinuate themselves into our mental framework as like, these things are friendly, they're reliable, they're on my side, I should trust them. And then disaster ensues eventually. So there should be somebody who's like, you know, who's sort of innate immunity to being galled by these things should be intact instead of being dissolved over time by them. And then the thought there is like the relevance to people in our seat is like, we're six months into this sudden, you know, productivity. I think tornado of productivity that was unleashed, right? I feel enormously overpowered compared to how I used to feel sitting in front of a computer trying to create software. And a lot of people I talk to feel that way.
But where's all the magic fricking software? You know what I mean? Like here I am, like my phone crashed yesterday, you know, like it's still, we still seem to have kind of mortal problems with our software. And more in some cases. There's an argument that some, yeah, that it's made people overconfident in certain ways that have harmed safety. I think there's some demonstration, there's some case studies that suggest that. Well, I
see more bugs,
nitty bugs, bugs in software that was rock solid before. And I'm quick to jump to say, oh, you know, and it's just like,
this button shouldn't be highlighted now because this.
I know what you mean. Yeah, the ones that are like gooey things where it's like, this would never pass sort of human QA. But like, if you wrote 75 prompts in a row, like eventually this weird crummy behavior would sort of emerge.
Yeah.
Yeah.
And so I can feel some of that creeping in. Um, when does that hit something load bearing?
I mean, the argument would be, uh, you know, people who are complaining about GitHub up times would say it's happened, right? Or at least it's happening in some companies. Um, I think there are some forensics that suggest that like GitHub up times have suffered a bunch and, you know, they very aggressively use CoPilot and other all in product. But that probably is a better, is a better place for us to transition like, how the heck do you use these things? Right. Okay. So, so let's say that, that we take that at face value, like something about some use patterns of these things are leading to worse outcomes or leading to outcomes that were worse offers less safe or it's buggier. It doesn't work as well. Some figure merit is going down. My inclination is that that's actually unlikely to be a fundamental characteristic of these things as code writing genius, right? That we can probably set up guardrails that protect whatever it is we care about.
If we're able to quantify what we care about and able to explain it in a way that the genie is able to respect. You right. Um, and I think that's the, that's the tricky part. That's where I see a lot of creativity. Um, and, and the creativity is often being drawn more from sort of social science inspirations or biological inspirations or psychological inspiration and spiritual inspirations than they are from sort of, you know, hardcore computer science, which has been fast and to watch. Um, I have a good friend who's, uh, kind of a genteck workflow for getting architecture changes into a project he cares about is, uh, is modeled after formal debate is monitored after the way that like people score debate in high school or whatever. Um, I've seen you've told me a little bit about the,
the, the Freudian architecture.
Yeah. Yeah. Yeah.
Where you've got an id that's just going, making changes, grooving. And then there's a super ego who's
been back off. Yeah. But here's a test. I bet you can't pass this and, you know, here's some duplicates. You got to get rid of that before I'll let you go. And then there's an ego that, uh, navigates between the two of them says, okay, a little more you little less you back and forth and back and forth.
Right. Right. And I mean, I think we're going to,
by the way, software methodologies have always been hard to quantify, right? You're sort of on the wrong side of the Turing test, right? You, you have this problem that, uh, the counterfactuals are never easy to measure. You know, quite have a perfect, uh, perfect control for your experiment. So it's some extent, I think we're stuck as, as kind of practitioners and crafts people just sharing experiences, talking about first principles, you know, what is it fundamentally that made TDD work say, and what makes sense to apply in this environment that is, does not have the same constraints and assumptions that TDD was developed for and that for every other practice we care about.
And if, yeah, is that even a good idea? Yep. My contention is nobody knows. And even if you knew today, you wouldn't know tomorrow. Right. Right. So the best we can do is to experiment,
which implies that you experiment cheaply and then that you share your result in community.
Yep. And I don't know how seriously to take this by the way, but like they're pretty radical reimaginings of the software ecosystem that are possible right now. Oh yeah. Um, like I've talked to a machine learning researcher who claims it might've been like, obviously might've been putting them into context, but like the claim was that it doesn't use PyTorres, doesn't use Jax, doesn't use people's frameworks or whatever. He just prompts the darn thing. And it's just like writing CUDA kernels and writing C++ and writing data loaders and, you know, slurping stuff out of S3 and doing everything.
And that's it. And it's a whole self-contained thing. He doesn't have to worry about anybody else's versions. And like, if it's faster, if it needs something to be faster, you can like talk to worry about this kernel or whatever. Um, but the, the sort of entire premise of libraries is that reuse is important, right?
What code is precious. It's much cheaper to load it in
and, and use it.
Yep.
Which may require some adaptation on your part.
And libraries are what operating systems evolved from by the way, right? If you're going to run one application on a computer, it's not as obvious that you care about all the other fancy things operating systems do. You just care about them as sort of reliable, reusable pieces of functionality. Like it knows how to drive the disk. It knows how to talk internet, it knows how to manage memory and do a few other things. And if that all becomes, uh, just something you link into a binary, because like, why not just link it into my binary? It's not so precious that I can't have it in there.
That could be a real, like it'd be a real possibility. Now this, this is like an interesting one that I think has been made in, in, in a direct and indirect way by a couple of different people. The first time I think this was pointed out to me was actually by our, our intern. So we, one of the, one of our pretenses as a venture capital firm is that we do do AI research and we have interns that help us with it too. Um, and Jenny Chu was with us, uh, starting in Q1 of this year and just entered an InfoSec and sort of AI applications InfoSec. Actually, it actually started out by like trying to like pre-train models from scratch and stuff and try and like, you know, make bug detectors and things like that. But eventually kind of like ended up in this vein. A lot of people ended up in, which was just jailbreak retail models. So that they will do white hat and black hat security stuff for you and see what you find. And she actually found a bunch of like CVEs in the Linux kernel. Well, this way found three of them in a firm or a brewery.
But the interesting thing was, you know, we're a mom and pop venture capital shop. You don't have the biggest token budget in the whole universe, but it wasn't clear to us that there was like a point of, of even diminishing returns, let alone zero returns to this process. So like, if you just computed more, you found more bugs, roughly. So if that, if we live in that world, then in some sense, software starts to become kind of proof of work like, right? If software quality and security is kind of one dimension of software quality, we can imagine that she was looking for bugs or looking for performance problems or whatever, like imagine sort of software quality writ large, that's the feel like proof of work. Then you'd want to be on the vein of the highest resourced software as possible, right? Because the software that's had the most compute port into it is going to be the software that performs the bugs, the few security problems, et cetera. That's a huge problem for the story we were just telling about custom world, right? About this world where every plumber, you know, custom builds their own CRM that knows exactly which parts of the stock are inventory and exactly how many vans they have and exactly why Carlos can't take lunch or money on the west side of town or whatever. So I think you can make first principles arguments for a lot of really radical eventualities right now. And I find that really interesting. I don't know which of these I take at face value, But it means
we need to be flexible. We need to be maybe.
Yeah, there's this, is open source dead? Cause you can just copy their test suite.
Yeah.
Tell the genie, make something that passes this test suite. And now you have your own copy with no copyright restrictions and away you go.
Or just go straight from the source, right? As far as I know, that's, you know, if I take your C++ program, think about it really hard and write it in Go, I have a copyright on that Go program as far as I know, either. I'm not an IP lawyer, you know, but do your own research here, but.
So what you're suggesting is there is a moat and it's gigawatts.
That is one of the concerning, that's definitely like the,
if you want to know what's sort of going unsaid, I suspect in the strategy of the frontier labs, this is sort of what they know,
is that there's an expectation that more and more problems can be solved through that kind of brute force and that kind of concentration of resources.
But if you could present the receipts, I have a B-tree implementation and I've got 400
gigawatt hours. Yeah, here's my $10 billion worth of compute that proves this is really high quality and really fast.
Fast, insecure and blah, da, da, da. Then I can charge people based on
that. And the plumber could also create a B-tree implementation, but he can't afford the 400 gigawatt hours.
Well, and the attackers of that plumber might not have more resources as the other thing, right? So there's a little bit of an adversarial situation with the security one that's, you could imagine sort of Bizarro open AI is somewhere in Moscow or something that is, has their compute budget, but they use it to find both. Is it to exploit? Yeah, yeah, exactly. Dumb question for you. How much time do you spend, as a proportion of your time sort of programming, whatever that means to you today, how much of it is like watching a cursor blink in an editor as I would recognize it?
Very little, because I'm multitasty. Okay. I'll have multiple projects going at the same time. I have tried to keep up with the feedback from the genie. And I find that exhausting.
So this is actually one of the things I think is, as though I'm still having a little bit of grief about actually is not so much my self-worth as a person who can write C++ or something, but is the fact that programming doesn't have the flow state that it used to have anymore, right? Like one of the things that used to draw people to this profession in our era was like, there was a sort of ideal state that you could get into, which is, you know, kind of communion with the problem, a kind of deep emergent in it, a sense of sort of really using all of your faculties on this narrow domain and making progress.
Yeah. And as soon as you looked away, you'd lose it. And you'd take you a while to build it back up.
And if you had to go somewhere, cause you were going to a meeting and blah, blah, blah, like it would get destroyed and you'd be cranky. And that's probably like why programmers have the reputation they do of being irascible and difficult is because you'd like tap them on your shoulder and be like, Bob, what's going on? And Bob, you're like,
Cause it took Bob two and a half hours to get to the unit.
Yeah.
So I miss that state. And honestly, like the agent world feels more like being an air traffic controller. It feels more like I'm like, yeah, I'll rate this terminal. No, no, not that. You know, there's these, you know, and it feels a little bit more like,
you know, very interrupt driven,
trying to get productivity through breadth instead of through that kind of deep immersion.
Yeah. I do these genie sessions where I'm streaming a live coding session, but I'm also reading the comments and trying to keep up with that conversation. That feels very plate-spinnery. Right. Cause I'm, and after an hour, I'm just, okay, I need to sleep for the rest of the day. Yeah. But when it's just me and the turkeys flying outside,
yeah, I am going back. I can't just do one thing. Yeah. I can't keep up with the feedback that comes up.
Cause most of it is like around the mechanism of the genie and not about my problem at all. Yep. Yeah. Spinning up an agent to do da da da da. Very. Waiting for the timeout from the shell that's computing the blah, blah, blah.
Yeah. I escaped this thing wrong for the shell. I'm just trying to get it. Yeah.
That I don't need to see. So
now maybe there's a, I've talked to you about this idea of the code feed where you, it presents you with interesting deltas in some larger code base that you're sharing with a bunch of people. Oh, that's a whole top multiplayer is the topic. We haven't touched at all. That's I really want.
Yeah. Anyway.
I would like, I would like a rollup of what all of my agents are doing that's in some kind of either like the front of a front page of a newspaper or a ticker. Right. Right. It says here's what you're interested in about what's going on.
Have you played at all with Intent by Augment Code? Yes. Yeah. What do you think?
Cause it has that sort of coordinator persona. Is that do that for you or is it not quite right?
No, no, it's definitely not right for this kind of, Parnas has this beautiful paper, "A Rational Design Process: How and Why to Fake It",
which says you design some software and it's in some messy sequence of things with backtracking and dead ends and whatever. And then when you go to write the documentation, you say to build a database, it's really simple. First we do this, then we do this, then we do it. So you act as if you'd made a sequence of inevitable rational decisions. That's the way you present a top talk. Right. And that's how you present. That's the view I want. I don't want to know all the agent plumbing. I see. I want to know, oh, I tried this. Okay. I did this thing, but I thought of this other test case. Oh, that test case didn't pass. So then I had to make this other, and that caused me to back track on this decision. And now I have three test cases broken. Nobody is presenting that kind of sequence that I can consume and feel oriented. Part of what I loved about that flow state is I just felt so oriented. I had a sense of mastery and
control is not too strong a word. Like I knew what was going on. And I could predict if I make this change here, here's what's going to happen over there. And I guess-- Calling your shot.
It's a mental-- Yeah, yeah, the deployment.
Yeah, yeah. Where you say, okay, now the tests are going to fail.
Now it's going to get a null pointer exception. I'm going to make this change. Now I'm going to get a array index out of bounds. And if you're tracking, you can predict exactly what's going to happen to the computer. And you have the sequence of changes you make that add up to the emergent property of, okay, now this software does something that I really want it to do. And I think both emotionally it's a loss, but also I think practically speaking, when you're working with fiddly enough software, it's practically a loss as well. Yeah, yeah, yeah.
I mean, one of the things that I want to be not too glib about, but people are still good at certain things that these agents aren't good at. And some of this does have to do with the way that they're constructed. And the sort of stochastic parrot talking point about how LLM is right code is factually false, right? They're not actually strictly predicting the next token, first of all. Secondly, coding is a closed domain. So it's like susceptible to reinforcement learning. So people are able to, the parts of program that you're able to make like a chess game, you can make superhuman agents at because they can self play the way that a chess playing program would become superhuman. There are parts that I think are probably past human capability forever now that they're gonna go further and further over that horizon, right? That part of the arms race is lost to us. Let's say the software industry continues on in a changed, but continuous with previous practice way, right? Most of the money that's spent on software is spent on maintenance. That's been true sort of forever yet. And
by mass, you're much more likely to find yourself maintaining a million lines of 10 year old code. Then you are to find yourself maintaining the vibe coded CRM out of plumbers or
that your AIS startup, that your YC startup just wrote a quarter ago or whatever. And for those things, first of all, the data to train an AI system is more scarce, right? We don't have as many publicly available trajectories of a decade plus of the evolution of software systems that we can look at, right? We've got the Linux kernel, and then maybe GCC, like a few other things, but there aren't that many economically important things that have had a long life in public that way. So your sense, like when you parachute into a code base and there's a million lines of code there and people are having trouble accomplishing what they're trying to accomplish with it. And in the future now, it's a people and agent centaur or something, but they're having trouble accomplishing it. That sense is still, I don't think very present in a robust way in these models is my impression. I still think that there's kind of a moat as it were, being a human whose judgment is grounded in like the actual purpose of the software, how software systems evolve, the kinds of architectural choices you make that like make you feel smart this year that you regret next year and so on. I think that stuff is still a little bit in short supply.
So it's not all gloom and doom. We don't have to mourn everything at once.
Final question. Let's go.
What scares you enough to keep you up at night?
Hmm,
not a ton. I'm a little bit temperamentally optimistic in large scale terms. I think the thing about, a lot of AI safety stuff strikes me as sort of reaching these really extreme conclusions from like experiments of pure thought. And since intelligence is not on a technical term, we don't have a, it just isn't a mathematical definition of it. It seems to resist mathematical definition in fact. I'm suspicious of people who have sort of closed form arguments that say, okay, a smart enough thing will inevitably need all these job losses, yeah, end of our species, et cetera. The one I worry about it, I would say is biosafety. Like it seems like there's like a relatively,
maybe I couldn't get through it tactically, but like I feel like I could learn a little bit of biology and in a quarter or two, be in a place to do kind of real harm with existing technology on the bioterror side of things. And so I do worry a little bit about,
groups with relatively modest resources and a like nihilistic agenda, being able to do kind of really large scale harm that way. People who know better than me, who are at these foundation lab companies, assure me that they're doing things that are not all publicly discussed to make this safer. I hope they're right.
I hope the hope and source models are doing it too.
How about you? Yeah.
Our society, we have a bunch of big problems to address and I don't worry about those. I worry about the meta problem that we have lost the ability to address big problems, regardless of what it is.
There are people who are willing to make a buck on the continuance of the problem, right? Instead of saying,
I've made enough money off of,
pick your issue, right? And maybe that's enough and I can just let the rest of this go.
I remember in the Save the Whales Day, there was, the economic argument was, yeah, these Chinese whaling ships, they're not fully depreciated yet. It's economically more valuable for them to just kill off the rest of the whales, process them and then jump the ships, than would be to stop right now. And so the economic incentives were
leading to irreversible consequences. And yeah, I guess that's the best summary I've ever given to that. The economic incentives are leading to irreversible consequences.
And we've lost the ability, whether through social shame, responsibility, religion sometimes had that purpose, a sense of community, a sense of legacy, all that's gone, all those things that would stop people from creating irreversible harm, just to make another buck. Those mechanisms are now broken and I don't know how we get them back. Interesting.
Yeah, maybe this is old age talking, but I think one of the things that happens sometimes in the second half of the 20th century was like the most desirable social characteristic became sort of cool instead of seriousness or formitability or gravitas or whatever. The impulse to distrust authority, which is important and which is kind of part of our civilization or intellectual tradition, that impulse sort of became reflexive to the point where any exercise of authority seems illegitimate. And so if anybody exercising power in any context is sort of subject to infinite critique, it does make it really hard to
have people who are saying, I'm going to amass power to solve this problem because it's bigger than
the power that is normally given to an individual. Yeah, that's what keeps me up at night. Yeah, that's a pretty good answer. That's an abstract answer, I gotta say. There's not like a super concrete scenario there. Which incentive are you worried about or is it?
Fossil fuels and climate change. There you go, sure.
The incentives are basically burn all the oil, burn all the, fix the carbon problem later in a technologically advanced future. Correct, yeah.
At the same time, it's an interesting case where the economics of fossil fuels are getting worse relative to solar and wind. Yeah. Which of those trends are we gonna end up, they're pulling in opposite directions in which way are we gonna end up that one? I'm not gonna call and I probably won't be here to find out.
Is this the podcast where you announced that you're gonna go to SpaceX to work on the data centers in space?
No, that's the next one.
Got it, got it, okay, sorry. Spoiler alert here, I did that one out.
Keith, it's great talking to you. Such a pleasure, man. All right. Take care, buddy.
All right.
Thank you.