コンピュータが（時に）人間より優れていても構わない

Hello and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we are on the floor at the LDX3 conference. We're talking about cattle, not pets, but for code. And my guest for that today is Charity Majors, co-founder and CTO at Honeycomb. So welcome to the show, Charity. Thanks for having me. My pleasure. So, top of the show, we'd like to get a little familiar with our guests. Can you give us a little TLDR on how you got into software and technology? It was an accident. I went to school for piano when I was 15, 16. I grew up in rural Idaho, and the only thing there was to do was read books and play piano. And I went to college and pretty quickly realized that all the music majors who had graduated were still poor in their 30s and 40s, still hanging around the music department. And I was like, no.

And that's about the time they were wiring the dorms for Ethernet. And I started playing around with computers. And now I'm here. Well, you're still in orchestration, right? I'm still in orchestration. And you could argue just swapping one keyboard for another. There you go. You gave a talk yesterday that was really interesting. And it was sort of an idea that I haven't heard. We're taking the idea from infrastructure, where we went from individual servers as pets, to moving to disposable infrastructure as cattle. But you said we should do this for code. Yeah, and I have to give so much credit to Chad Fowler here. Chad is the one who actually coined the term immutable infrastructure back in 2013. And he's written a lot about this blog post on the Phoenix Architecture site, and he's writing a book for O'Reilly on it right now. But it was one of those things that as soon as I saw him make the case, it just clicked in my head, and I was like, oh, yeah. I am just barely old enough that my first job title was sysadmin. I barely remember this, Dosh. But I do remember the sense of crisis that everyone was in.

I was 17 years old and on call for the first time. I was surrounded by these people who were just wizards. They knew everything about Linux internals, FreeBSD, HPX, Sun, like the operating system and the networking stack. And they knew everything. And every server was like handcrafted. Like, you would SSH in and be like, which type of memory do I need to fix the hardware? Like, they knew so much. And it seemed unfathomable to me that we could just destroy this. Yeah. And yet, by around, you know, early 2000s, it became very clear to everyone that this was better. It was better because, you know, one of Chad's great lines is, mutability is the sworn enemy of understanding. Anytime you're going, just changing, you lose the provenance. You lose the history of what's come before, and it's not repeatable. And the whole way to make technology boring in a good way is to make it so that you don't have to understand it all the way down to the device drivers, so that you can work at a slightly higher level because you know how to revert to something that's known to be good.

And so Chad started laying out this argument, and it made so much sense to me. And a lot of this does hinge on what is the definition of the word spec, because it's a catchy phrase, But I think the definition of spec is changing a lot. And I just feel in my bones that there's a better way. The cost of software is defined by maintenance. Yes. So I want to tap on the immutability because I think for a lot of people would look at the server and that being like, that's the immutable infrastructure, right? Once you start defining infrastructure with a YAML file, you never know exactly how many nodes are up. That seems like that's kind of mutable. That's kind of like, I know less about what's going on. Is that mistaken or is that just, like you said, another layer of abstraction? I think there are parallels here that history isn't going to exactly repeat itself. That's just moving up the stack, you know, like going from assembly language to C to JavaScript. And I think it's notable that there have been many movements in the past who have low code or no code, and they've all kind of failed.

Which is why I think it was very reasonable for us to be very skeptical of ChatGBT's claims right up until about last November. Right. And you were skeptic for a while. I was skeptic for a long time. And last year, it's here. And at its root, this is almost more of an economic argument than a technical argument, because code has always been hard and time-consuming and expensive to produce. Right. And we've always been rate-limited by some human has to understand this before we can move forward and iterate on it. And if you think like I do, that in the past year, AI got to the point where it can generate snippets of code that are roughly at the same level of quality as the median software engineer, which means that while one software engineer can output a piece of work that works, AI can generate a thousand of them, 10,000. We can see which one is the best. It makes you think very differently about code itself. It's interesting where we spin up all these nodes, now you can spin up all these versions of that feature and compete them against each other, right?

That's one of the building blocks, I think, because it's pretty clear to me that in the same way, we don't expect every software engineer to understand how to debug types of RAM or how many CPUs or if there's a device. We just don't expect them to understand that. Right. You know? We used to. Right. We don't anymore. And I don't think it's an exact analogy, but I do think that when we talk about cost of software as defined by its maintenance, we're talking about the cost of having to understand everything. And I think that if we re-architect our software so that we can understand it at the level of functions instead of lines. Right. You know, if you re-architect it so that there are bounded parts that can be cut. And, of course, the most durable part of this system would be the evals, not the code itself. Right. describe what must be true for this to be defined as good and then yeah we can we can generate 10,000 diffs and see which one is the best you know yeah yeah and for those evals are you thinking like the llm as a judge sort of evals or do you have a deterministic eval well both and i mean a lot

of these tools actually already exist conformance testing but they're all in the realm of ops and and qa which are historically like the cost centers they you're not quite as cool as software engineers. But they're aimed at describing the world as it is instead of the world as it should be. And there are some types of code that will never be replaced by this because they too sensitive There a lot of code that very high in the stack and it a feature You should be able to say these are the contracts that our code has made These are the systems that depend upon it. And right now, the fact that we don't know those things, we don't know. The way that we replace old code is through strangler-fig architecture, where we just intentionally break one thing at a time. This is terrible. That's why it's so hard. To regenerate the architecture. Yeah. Jez Humble had a talk yesterday, sort of specifically targeting the Strangler Fig architecture. Ah, I'm going to have to catch that. Yeah. It was interesting because it's like that's a really inefficient way to do it. Yeah. It's just screen tests all the way down. It's no fun. The worst engineering times of my life have all been rewrites. But I talked to a QA engineer that had built a sort of proof of concept, agentic SDLC,

and it was all based on evals and QA mindset. And I was like, oh, engineers are going to need to be a QA person. Yes, and ops. One of the things that I'm excited about in this era is software engineers have historically lived so much in the land of how things should be. If the tests pass, my job is done. Right. You know, as much as we say the lob it over the wall doesn't exist, it still exists, right? They're used to living in this world of, well, it is correct on paper. But that's not reality. The code has never been the actual source of truth. The source of truth is the system. What matters is the system and its ability to keep on running in all situations. You mentioned that the nature of specs has to change. Talk to folks who are thinking about spec-driven development and what that spec actually is, whether it's a sort of functional spec languages or plain English. This is not really my area of expertise, and I think it's just a really exciting time to be thinking about those problems, if you're someone who likes those problems. One of Chad's recent posts said something like,

don't assume that spec is a document. Like, there are probably going to be bits of code in it. There are probably going to be, like, depends on the type of system you're trying to describe. There might be benchmarks. There might be a lot of different things. And the tools don't really exist to do this type of development today. Sure, yeah. But they're starting to be built. Yeah. And it is very exciting. I briefly ran into somebody and mentioned this sort of regenerative code. And it's like, well, it works for infrastructure because you have that deterministic thing, that YAML file that generates the same thing every time. Do we need the thing that generates the same thing every time? Oh. You're sort of talking about like this code Thunderdome. We need our AI to generate deterministic system that meets the specifications. Yeah. But I think that it can change. This is part of the challenge and the promises, right? What can change and what can't? If you've got a web app and the latency on the payment's endpoint goes from two seconds to three seconds, probably fine. It should be fine. We don't know until we try it, but that kind of variance happens all the time for a lot of different reasons.

And you need systems that are flexible enough to absorb some variance. Something that is much lower on the stack. Like if you had a router that went from taking 0.1 seconds to taking 3 seconds to take a bit of hot, that would be catastrophic. It would be terrible. Right, right. Right? But like part of architecture and part of building resilient systems is trying to make them flexible so that things can flex. Right. You know? I'm sure a lot of devs listening to this will be like, oh, the spec is never a deterministic thing. The requirements shift over time. Exactly. Yeah. So at what point do we need to get the final final, right? Like, how do we stop product managers from changing things along the line? You know, I think it will be great if we can get to a world where we trust our spec and our evals enough that anyone can just chip code. That is not the world we live in now. And it's not one or two hops away from the world we live in now.

Right. But for some types of systems, you can see how it might be three or four hops. One of my favorite blog posts of all time was the one about boring software. Yeah. You know, boring doesn't mean bad. Boring software runs the world. It means that its failure conditions are well understood. It may fail, but we know what to do. In the same post, he talked about innovation tokens. You know, how you need to limit the number of... Every startup gets two innovation tokens. You know, spend them wisely. And none of this stuff is boring right now. But a lot of the technology that we would use it for is boring. And I think that's where we would start. How do we make AI boring? Ooh, that is a topic that really starts to come down to governance really quickly. And I was thinking the other day, five, six years ago, there were plenty of large language model research companies out there that were doing research on their models and following the law when it came to copyright. Sure. And fair use and everything. Yeah. And they were making progress not as fast.

Right. And then OpenAI came along and was just like, just go. And how different would the world have been if the changes since 2022, 2023, 26, has happened over 10 or 15 years? And what kind of precedent does it set for all of the presumably law-following companies out there? Sure. So something that I've been thinking about a lot lately, this is not necessarily technical, but it's just like how do we catch up from a governance perspective? How do we catch up? There's this upsurge of rage at data centers and it's happening throughout the country right now. But how do we channel some of that into organizing to, I don't know, compensate the people, have funds for the people who want to move because they can't sleep at night? It feels like this is the question of our generation right now in so many ways. I mean, it does sort of feel like AI is just feeding society into a woodchipper to get this amazing product, right? There's a Cal Newport just like, why are we letting these folks act like oh it might kill everything but we're going to build it

anyway right like this is a product that's broken like if your product was out there like putting people out of work and would you feel okay building it developers have a different view on ai because they can engineer solutions to their problems this is how you can well and this is the thing i am very much of two very strong minds on it because as an engineer i'm like oh my god it's christmas morning This is so cool. And I really do think that software will turn out to be the killer app for large language models because it's logic in language. It's what it is. The LLN are getting so good at, you know, if you give it a task, it does the task. They're not getting any better at the higher level systems thinking. And I don think they will because of the nature of the thing Like it still just sort of predictive text It trying so hard to be helpful You know we had an article from Chelsea Wolf that was like data-driven thinking is not innovative thinking. And this is LLMs or data-driven thinking. Yeah. Right? A lot of the rhetoric about how we're all going to be out of jobs and everything,

I think is, I wish people would calm down. I don't think it's going to be true. But on an individual level, if you don't embrace the new technology, yeah, you will be out of a job. Yeah. So like both of these things are true. And back to your question about how do we make AI boring? There are individual levels, there are company levels, there are societal levels. And I think none of us can afford to lean out on all three. You know, sometimes when I lay awake at night thinking about climate change and the government and everything, I do find myself thinking, well, when it comes to AI, I can have more of an impact than on anything else. And it's small, but I'm in it. And you're in it. And we have voices. And the game is not over. So there are things we can do. Right. And we should be super actively leaning into that opportunity. For folks who want to lean into it, what is the thing that the IC listening, what can they do? The first thing, I know not everyone thinks this, is become an expert. Become someone worth listening to. It's so much harder for people to discount your voice if they need you.

Become indispensable. Master the tools. Develop your opinion. And become indispensable is a great way of summing it up. Because not only will you be needed and you'll be listened to more for social animals, you know, but also you're more likely to come up with interesting ideas. You'll know the weaknesses. You'll know where it shouldn't be used. You can make the case. It's credibility. Yeah. The other things I've heard that will make you indispensable are things like taste. And there was a talk yesterday that said it's wisdom and charisma. Intelligence is a commodity. I've been thinking about that a lot. I just finished reading this book by Benjamin Labatton. I read it, I got to the end, and I turned around and started over from the beginning. I've been thinking about the Move 37, where it is this entirely unpredictable move. It looks innovative, but it's from the simulations and the data. Like, the computer can do all of the moves forever. For those who are listening, it's sort of about von Neumann's life.

I was watching an interview with the author, and he was asked about his process, and he said it's very research-heavy. He starts with research. He tries. It's shelved under fiction, but very little of it is fiction. Most of it is taken from the data, taken from history books. And it's sort of like a dark origin story of artificial intelligence. Yeah, yeah, yeah. It's interesting, you know, the personality. Like, Von Neumann was very good at solving problems. He would just have these people come by and just like chat with him and be like, hmm, solve their problem. And he worked on the Manhattan Project. He worked on computers. He worked on the hydrogen bomb and the nuclear bomb. He built one of the very first computers. Yeah, like anything that happens like the first few decades of the 20th century, like his figures are probably in it somewhere. What about that book struck you for this moment? So many things. But it's written as sort of a triptych. The last section is about Alcego. basically and to go players and the guy I remember his name the go champion who played and and he

quit the game after a couple years after losing and just being like ah there's no point and I kept thinking about that no like yet if your entire life is oriented around being the best and the smartest this is very threatening right but most of us are not the best and the smartest. Most people are all average in some way. And I feel like... Embrace your mediocrity. Intelligence is overweighted on. It has been dramatically overweighted on for the past few decades at least, if not longer. There are so many things about being a person are not about how smart you are. And the more obsessed we get with our intelligence and with being the best, the more we really lose out on the journey and the joy of the... Like, There's so much more to life than smarts. Yeah. We all have become knowledge workers, right? Our power in the labor market is our knowledge. And with AI, I mean, with computers, one of the other things I liked about this book was that it showed how much it scared people,

the advent of quantum physics. Yeah, when we still understand the world. Yeah, and he was just like, they really lost their s**t. Like these mathematicians and physicists were like, we can no longer model how the world works. and it's math instead of intuition, some of it actually went insane. Yeah, it was kind of a mystical experience. Yeah. And now we're all just like, well, yeah, quantum theory exists. That's fine. And there are so many other types of AI that are so much better than humans at so many things. Driving. It doesn't have to threaten us. I think we need to have the time to adjust. The speed of this is so destabilizing to everyone. Yeah. The speed of it and the fact that people seem to be gunning for terrible things with big grins, just like with leaders, They're just like, we're going to put you all out of work. Isn't that great? It's just like, do you trust these people? No, I don't trust anyone who says that. It's a terrible thing. But I don't think it needs to or should be intrinsically terrifying or threatening to our sense of self. The computers are better than us. Any more than it should threaten me that someone else is a better CTO than me. I can want to be like them.

I can make a lot of stuff after them. But it doesn't threaten me. Because I am who I am. I can still love my family and cuddle my cats. and there are so many things that are not intelligent-based. And I wonder if that's kind of been the point all along. I mean, maybe. I don't know. It's an interesting take to say that, if I'm understanding, AI will sort of re-humanize us. I hope so. I hope so, too. So I have a sort of spicy, provocative question that I think you're the right person to ask. Oh, no. Yeah. What is the line between observability and monitoring and surveillance? Off the cuff, I would say observability and monitoring are pointed at machines and surveillance is pointed at humans. Well, like you said in your talk yesterday, the software is a system and that system includes users. Which is why we have things like PII and types of data that we're supposed to scrub so that any old person off the street can't come in and just like see where I was at a given time of day. right but in theory

I think we've seen don't want to name names but some data gathering operations have the NSA leaks all the way back to what his name who now in Russia and Russia and Edward Snowden and Facebook in the early days the way anyone could just log in as anyone and look at their stuff There's carelessness, and there's maliciousness, and then there's governance. Yeah, I don't know what to say about it, man. Yeah, I think it's a hard line. It's something I'm sort of freshly thinking about. It's very hard to build and run these systems without feedback loops to let us see what's happening with some precision. Yeah, you need to understand the system, but how far does the system extend? I would love to be like, well, that's why the government makes laws and we can't blah, blah, blah. But I'm not going to try and do that with a straight face. Yeah. I don't know. Where is your head? I think the engineering mindset has the sort of data gathering and observability built into it. I think what becomes dangerous is when you take the engineering mindset into society.

outside of machines, outside of rocks and metal. Yep. But, you know, engineers are smart people, and they think that they can solve things that are outside the domains. A lot of smart people do that. Oh, yeah. The smarter you are, the more you're like, well, this is just like that other thing I did, that Dunning-Kruger effect, which AI is making worse than ever. I mean, law really can do good here. And I've been thinking recently about the effect of HIPAA. Yep. Before that, doctors regularly just told someone's parents or their partner or... Right. I just told them things, sometimes instead of the person. Right. That was incredible having laws and then making sure that you had access to your own. It was genius. We needed that. We had consequences, right? We had consequences. Right. What do you think we should do, Ryan? Don't turn the mic on me. Come on. I think laws will be great. You know, we're finding the faults in the legal system right now.

So maybe an engineering mindset on the legal system would be... I've been seeing all these news reports recently about lawyers using chat GPT and having filing briefs with errors in them and getting shut down. So I do think that the limitations in large language models are numerous and kind of baked in. And I think the future of software is determinism and non-determinism, and we use them both, but it's not magic. And I think that, I mean, I really would want to be a teacher right now, but I think the education system is where we're finding a lot of the edges on this stuff. And I think everybody is figuring out, like, oh, we have to change kind of everything. I had a conversation yesterday about SaaS, and it's like a lot of this you can just write in-house now. Yeah, yep. But I think what's going to shift is that, you know, the SaaS that is indispensable, the stuff that's like, you know, a glorified database. Yeah, there's lots of types of software where you get a lot more value in having it be the same everywhere

or in being able to share data. Right. Or SaaS is going to change, but not everyone wants it. Again, maintenance is what makes software cost what it costs. Right. I'll briefly mention Paceplayers, which is the Stewart brand, which is the idea that there are like this applies to all complex systems whether it's society or technical systems or whatever but there are some layers where innovation is great and things can move very fast and there are some layers where you need it to move more slowly for stability. I think we run into a lot of trouble when we forget those and when we try to mingle them because it stifles innovation if you're at a slow pace layer. It creates a lot of instability if you introduce a lot of change into a lower level. Like you said earlier in this conversation about boring software, innovation tokens, right? Yeah. You know, don't change too much. And be conscious of where you're changing it. Somewhere where it's easy to revert. Usually persistence is a lower pace layer. Non-persistent stuff is much easier to, like, try and revert

and move fast and break things because it doesn't... It's wherever bits meet the world of atoms that things need to slow down a bit because whether it's humans in their interface or it's storing bits on disk, it just becomes a lot harder to revert from. Yeah. Speaking of move fast and break things, I know you spent a lot of time at Meta. I did. What would you say your biggest takeaway on moving fast and breaking things there was? Well, by the time I got there, we were all told that era had ended. And I think it had. I learned a lot of things at Facebook. None of them are technical. none of them were things that I think I would have said I wanted to learn but they were all good lessons a lot of good people worked there but it was a one man show it was the Zuck show what he said went to this day no one can eject him it's written right in he has total control of that company and for a long time I think that that was a huge asset advantage because it allowed them to have some single minus

Zuck has great product sense Yeah. He's a smart man. And now I think we're really starting to see several years of compounding what the weakness of this, with this equal player, the sort of monarctic model. No one can check him. Yeah. I mean, you're a CTO and a founder of a company. I wonder, like, how do you think about running the company differently? I'm probably in the opposite type of leader where I am not willing enough to be like, this is the way it goes. If it was easy, if there was a clear path to winning, you know, it's hard. Well, thank you for listening, everyone. I've been Ryan Donovan. I edit the blog, host the podcast at Stack Overflow. If you want to reach out with comments, questions, topics to cover, email me at podcast at stackoverflow.com. And if you want to reach out to me directly, you can find me on LinkedIn. I am Cherry Majors, co-founder and CTO of Honeycomb.io. So I write at charity.wtf.

I just put up a blog post called Confessions of an Unrepentant Slop Hater or something like that. We just finished posting a bunch of stuff about AI norms and values, which is on the Honeycomb blog. You're welcome to look up either. If you email me, I will probably not respond. Thank you for listening, everyone, and we'll talk to you next time. Thank you.