Computers, Coffee, and Beer

We Built the Internet. Here's Why AI Can't Replace You.

• Keith Adams & Julien Verlaguet • Season 1 • Episode 4

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 1:10:44

Is learning to code still worth it in 2026 — or has AI and vibe coding made programming obsolete?

Two veteran engineers who helped build the modern internet settle the debate. Keith Adams (built the HHVM JIT compiler at Facebook, employee ~80 at VMware, early Slack engineer) and Julien Verlaguet (CEO of Skip Labs) share their unfiltered take on whether you should still learn to code — or if vibe coding with LLMs is enough.

In this episode:
🖥️ How Keith and Julien both learned to code at age 6-8 — on an Apple IIe and an Amstrad
🧠 Why having a "mental model of the machine" matters more than ever
🤖 Why LLMs are "amplifiers for experts" — not replacements for novices
💥 The problem with vibe coding: "you still have to read the code"
🧘 Why programming teaches humility (the machine tells you you're wrong — every day)
🎓 The massive challenge facing CS educators in the AI era
🔮 Julien's "Turing Test" for when AI actually replaces programmersThe verdict: "Should you learn to code? My god, yes. First of all, because it's wonderful. Secondly, because it's going to make you better at your software engineering job — which isn't going anywhere."


⏱️ Timestamps:
0:00 — The TLDR: Yes, you still need to learn to code
2:48 — Keith's origin story: an Apple IIe at age 6
4:23 — Julien's origin story: copying games from an Amstrad manual
25:00 — Why LLMs amplify experts but don't replace them
30:20 — The "mental model of the machine" — and why it's the key skill
39:00 — Programming teaches humility (and it's healthy)
44:12 — Vibe coding: what it is and why it fails
51:54 — Julien's AI Turing Test for programmers
1:01:00 — The final verdict: learn to code, it's "f***ing awesome"


🎧 Full episodes on YouTube + your favorite podcast app.
 @ComputersCoffeeandBeer  

📩 For Business Inquiries: don.broida@gmail.com 


=============================

Channel About: 

Computers, Coffee, & Beer is hosted by Keith Adams and Julien Verlaguet — two engineers who helped shape the modern internet and have the war stories to prove it. 

Keith built the HHVM JIT compiler at Facebook, helped virtualize the world at VMware (employee ~80), and went on to Slack before founding Pebblebed, an early-stage VC firm for technically ambitious founders. 

Julien created the Hack programming language, spent years writing safety-critical compiler software for Airbus and nuclear plants, and now runs Skip Labs. 

Together they dig into the systems, languages, and decisions behind the technology that actually runs the world — told by two people who were in the room when it happened.

=============================
#learntocode  #ai  #vibecoding #coding  #softwareengineering  #aicoding  #programming  #techpodcast #ShouldYouLearnToCode

SPEAKER_00

So welcome to Computers, Coffee, and Beer. I'm Keith here in Conversation as always with Julian Verligay. And today we're going to be talking about whether you should learn to code. TLDR, the answer is yes. You still need to learn to code. We get there's these coding genies, they're amazing. You're still not going to be able to use them that well if you don't know how to code. And then how to, uh, because both of us had kind of weird on-ramps into computing. And uh we think that there's something to learn from that.

SPEAKER_02

So, first of all, how how did how did you learn how to code?

SPEAKER_00

Yeah, I have a relatively concrete like first experience with writing code memory, which because it was like when I was a little kid. So I grew up in a Marine Corps household. My dad was a career officer in the US Marine Corps. Uh, and so it's a matter of public record that in 1983, when he brought home an Apple IIe, uh that device cost 3,000 US dollars. And those are 3,0194 US dollars, right? Um, and also, since he's a public servant, I got curious about this, is also a matter of public record that his salary that year was $30,000 US dollars. So this is a meaningful investment. This was like a big, this was probably my parents probably had fights about this that I wasn't in the room for, right? And, you know, what's the Apple IIe for in 1983 if you're an artillery officer, right? Which is what he did. Not much, to be totally honest with you. Like there's a bunch of pencil and paper calculation you do, like, you know, to figure out where the shell's gonna land or whatever. And he wrote little basic programs for that stuff. But you know, it's this big thrumming piece of hardware. It's not, you know, we haven't had don't have laptops yet. The Apple IIC, the luggable Apple II, uh had not been developed yet. Um so he had this thing. And in hindsight, like he must have just sort of thought computers were cool. You know what I mean? Like in hindsight, I'd probably come by this interest in computers a little bit, honestly. But I was six years old. Um and we, like, you know, like a lot of other people, I guess, explored this device with like the books that it came with, right? So it came with sort of a little book that was like, you know, a manual about like like electronic level stuff and to some extent the 6502 and like what the memory map stuff on Apple IIe was. I was in no position to understand that, neither was my dad. But there was also this book about AppleSoft Basic. So it came with this programming language, burned in a ROM, called BASIC Beginner's All-Purpose Symbolic Instruction Code, which is one of those tortured acronyms from middle uh 20th century computing. And of course, like this was supposed to be uh a software language that was so easy that mere civilians could be able, you know, would be able to write it because uh there weren't these complicated control structures and complicated notions of modularity and all these other things mucking things up. There were just little lines of code and you could jump around the lines of code, and that was that. Um go to And so I exactly, yeah, go to and there were for loops and so there's a little bit more than that. But yeah, very close to sort of not a ton of resources there for structured programming. And there were also like enthusiast magazines, right? So there were places, there were these magazines like Byte and whatnot, where you could buy them at the newsstand, take them home in your sweaty little hands, uh, right, and and open up their glossy print. And in their pages, there'd be these programs that were supposed to do neat things. There'd be like a game or something you could play. Um, we never got one of those to work. Like we'd sort of like type it all in and just like never get it to the point where we didn't make a mistake somewhere and and not be able to run the game. Um, but it was like an experience trying to get a computer to do something. Um, and it made a kind of big impression on me. I think I didn't I don't I don't know if this is really the time that the bugging that the coding bug took for me, right? Like I didn't sort of immediately go out and seek other mentors and find other resources and learn more and like consume things at the library or something like that. Again, I was six. But it was a very memorable impression. It was kind of like a cute father-son memory as well. I think the the bug bit me for real in high school. I think that was when I uh had exposure to um to a computer actually at at my high school in Portsmouth, Rhode Island, um, PHS, Go Patriots, which had a PDP-11 still. It had a PDP-11 that was actually running RSTS, which was like DEX operating system for the PDP-11. Uh, it was also one of the early machines that ran Unix, but it wasn't running Unix there. And they had little PT100 terminals set up in the computer lab. And I could write little Pascal programs uh using a bizarre editor that I now know was Tico, one of the predecessors of Emacs. One of these bizarre editors where it's like all crazy keystrokes and stuff. Um, and that was kind of when it really the when the pill really started to dissolve into my bloodstream, I think. But how about yourself, Julian?

SPEAKER_02

So it's actually funny, we never talked about this. Like my story is very, very similar to yours. Uh almost identical. So uh my parents bought an Amstrad back in the days, and it came with a book, and in this book there was BASIC uh and how to program in Basic with little games at the end of the book that I tried to copy on my computer and never quite got them to run, but actually forced me to debug what was going on, and that's when I started to make sense of what the program was doing. But I was a little bit older, I wasn't six years old, I was I would say seven or eight or something like that, but still very young. And but same thing back then what I was really trying to do was to get that thing to play a video game for me. So I wasn't really interested in the code whatsoever. And then in high school I learned Pascal when I was like yeah, 14, something like that. And then that's when I really got more interested in true software and and things got more serious. But I would say, and I think that's probably different from you, so then I learned C. But I would say the revelation.

SPEAKER_00

Same so far, believe it or not, but yeah, I keep going.

SPEAKER_02

So um the revelation for me was uh scheme and functional programming. That was an eye-opening moment because I stayed in the realm of uh, you know, the classic programming languages, more more mainstream things, up until the age of 20. So I got exposed to functional programming really late. Um and then and then OPAML, that was another another one that was an another eye-opener for me. Um, but I would say what where I really caught the bug was with Pascal.

SPEAKER_00

This is the prescription so far, right? Start when you're six, learn learn basic to try to you know copy somebody else's program.

SPEAKER_02

Yeah, but I mean that's a bad prescription because today, how I mean to be honest, I don't even know what basic is. I would have never done that in today's world. Never. Because all I wanted to do was play video games, and today you can just play video games on pretty much anything you can get your hands on. Anything with a screen has games in it. So I don't think I I I'm wondering if it would be a good idea to build a device that you can give a six-year-old that only has you know the same things we had, so that they they actually have to write down the programs to get the. Maybe that's what we should do. I don't know, but I think this is not gonna fly in today's world, right? Like where video games are everywhere. Um, and so so I I don't think that's a good starting point. And then so what's your take? So have you ever been exposed to functional programming? Or when how when did that happen?

SPEAKER_00

In 1998, I spent one year in Oregon. And I was at a place called Oregon Graduate Institute. Oregon Graduate Institute is this bizarre grad school that used to exist, it doesn't exist anymore. Um, for that Nike and Intel dreamed up, because those are the two major sort of consumers of graduate degree employees in in Oregon. And so it has an exercise science department, an exercise physiology department for Nike, and a computer science department for Intel and nothing else. And it grants PhDs, Oregon Graduate Institute, right? So I went there and there was um not that big a CS department. One chunk of the CS department was busy doing some system stuff. There's a project called Quasar by Dylan McNamy that was oriented around like doing quality of service stuff in in operating systems. So it was like hacking up the Linux kernel so you could play video. By the way, the the mid-1990s to late 1990s, it's still arguably a research topic how you like reliably play video on a personal computer. It's still sort of a little bit like, yeah, it works a little bit, but the sound and the video get chunked up and you like drop frames and whatever. So making something reliable there was like still kind of a research thing. I got started porting uh Linux to a machine called the i960 until it had this process.

SPEAKER_02

When the FFM peg came out, do you know?

SPEAKER_00

Oh no, I don't off the top of my head. Do you?

SPEAKER_02

Because um, no. I it was written by Mid Ach, right, who's one of my favorite uh programmers. But anyway, keep keep on going.

SPEAKER_00

It was one of those crazy things where it's like so many things had to happen before YouTube could have happened, you know what I mean? One of them was just like this had to be commoditized that you can just play video, right? It hadn't happened yet anyway. So we were uh I I was doing a research project where I was porting Linux kernel to this new CPU called the I-960. The I960 is like a weird risk processor that Intel dreamed up on. Not super important right now. But across the my cubicle barrier was a bunch of people working on GHC. Like by by sheer coincidence, OGI had a bunch of Haskell people in it. And Oregon, by the way, still has a bunch of Haskell people in it. A lot of the people that were in that office with me ended up working on like security enhanced L4 and like other kinds of, you know, formal methods y type stuff that's that's sort of downstream of the Haskell mindframe. Um, so you know, I I was busy kind of being one of these, you know, dirty, grubby, let's write a million miles of C code and debug it later, kind of people that I was at this time in my life. And then there are these other people right next to me having this very different experience where it seemed like once they got their program to compile, it worked. And I was like, well, tell me more about this.

SPEAKER_02

Yeah. To ask them how much memory it's allocated. So actually, for early stories, just a small parenthesis. So while while I was uh at Facebook, you know, um I was one of the few uh writing functional code back in the days when Facebook was still small, like 2010, something like that. And so all the interviews for functional programmers were sent to me. And so that meant all the Haskell developers were sent to me. And um, so you so I I've seen a lot of funny behavior with with uh with uh developers, because some of them basically they pretended to know to know Haskell, but it was just a show off, and really they didn't know that much. So some of them would ask, um, is it okay if I finish it if I write this in Haskell? I said, sure, go ahead. And then they'll go back yourself out, buddy. Well, uh become what you wish for. Then you'll switch to by you know so you you know I used to do this this go ahead. So you had the people who are uh faking it, like they pretend they know Haskell, but really they don't. And then there are those who actually know Haskell and who did a good job. But then at the end, my favorite question was uh was always like, so you ask them first, you know, what's the what's the complexity? They do a really good job. And then you go like, what's the complexity in space? And then you watch them, you know, sweat and go like, uh, how much does this actually allocate? Do you know? Right, right. And and so that was so I mean one big caveat with Haskell is well, which you don't have Widow Campbell, so that's my rant against Haskell, and Haskell people are gonna hate me for it, but that's okay. I can take the hate. The the one thing that you know, when you whenever you say the program just works, yes, but you don't know if it's going to terminate or how much memory it's going to allocate. If you don't care about these two things, then fine. You know, whenever it compiles, it actually works. The main difference is that you can actually debug O'Campbell, like you debug C. You know, there's no problem. Okay, well, let's uh this is what Hashtag is.

SPEAKER_00

This is a rabbit shell that's worth exploring. Yeah, yeah. So those are rabbit holes worth exploring. Is that just laziness? Do you think it's like the fact that Haskell's lazy? It uh that doesn't matter. Definitely laziness.

SPEAKER_02

Laziness by default. The fact that there's laziness that's totally fine. You can have laziness. The the big problem is that laziness is the default. And so they they did that because they're obsessed with expressiveness of the language, and from the perspective of uh theoretical computer scientists, expressiveness is de defined as how many lambda terms actually normalize. And in that world, well, the the evaluation strategy that makes the most term normalize is the lazy evaluation strategy called by me. So that's that's what it boils down to, but it's a completely impractical choice. And so my favorite rant about this is actually uh the one from uh Greg Morriset. So I I I spoke about him in another episode. He's one of my favorite guys, and so he, you know, he was ranting about Haskell. He's saying, so the Haskell people they're obsessed with having everything in the type, right? So they don't want you to be able to have a function write to a file or log something, because you know, it has to be part of the type. It has to be a monad that shows that, whoa, whoa, this function could write to a file. That we really need this in the type, right? And so these are people who are really obsessed with having all the information in the type. But the one thing they don't seem to care about is is this value actually a value? They don't care about that, that's totally fine. And when you think about it, it doesn't make any sense. If laziness was not by default, then you would see it in the type. You would see in the type that it's a lazy thing, which means that when you try to force it, maybe it won't terminate. You know, something could happen, an exception could be thrown, whatever. So the type would be more precise if laziness was not the default, right?

SPEAKER_00

So those are just the kind of like terms that that might be a little bit more democratically accessible these days. It's as if sort of everything were a future or a promise or something, uh in as if like that were the default thing.

SPEAKER_02

Yes, exactly. Yeah, that's right. So yeah, it's a so so for the for those who come from JavaScript, it's as if every single value in your language was a promise. And then whatever you want to do with it, it's whatever whatever you compute, whenever you compute anything, you create a promise. So try to imagine what is actually going down when you execute that thing and how much you actually allocate. Um and the way this thing is actually computed is a graph reduction algorithm. So it doesn't use a stack. So you know, we like to think about program executing line by line, and then that's how we like to debug, right? We will print before, print after, or use GDB if you don't use printf debugging. You know, that's you're not supposed to, but whatever. We're old school. Um, and and you're not able to do that because the whole thing is a graph reduction algorithm that could, you know, evaluate things in an order that you you you you don't understand. And so for me, that's absolutely it. What what was the the one big bad design decision that Haskell made was laziness by default.

SPEAKER_00

I I'd had this experience in X98 where it seemed like there were these like people who were way smarter than me and were saying stuff about category theory I didn't understand at all, having this amazing programming experience writing Haskell. I started messing around with it a little bit, and it's sort of in a toy context, it does that, right? Like if you're taking a physics textbook and you're trying to make a little physics package that like embodies the stuff in the textbook, you write these little Haskell expressions. They're kind of like taking a little tech from the physics textbook and making it Haskell, and it like kind of works, you know, and you're like, wow, this is kind of wild. This is really different than my C life or whatever, right?

SPEAKER_02

And um, yeah, but nobody wants C life, you know?

SPEAKER_00

Yeah, well, uh that's another like we'll get we'll get to the C part of things.

SPEAKER_02

I mean, when you're at the bottom of the barrel, you know, anything better.

SPEAKER_00

But to be clear, like I always identified as a C programmer first and a C programmer by like sort of professional necessity or whatever, but hang on for a second. Um we uh when I was at VMware, we were working on this system called V probes, and it was basically a passive instrumentation, kind of machine-level instrumentation system, right? So the idea is you've got this, like you're running Windows or something in a VM. You want to be able to say like how often did I do this kind of system call in Windows and you know which processes are running and blah, blah, blah. And we basically built this little framework that could like safely instrument Windows underneath it. We called it v probes. We needed it to be like a little bit programmable. We need it to be sort of uh not Turing complete, right? Because we didn't want you to run an infinite loop in the middle of you know an interrupt handler in Windows or something and break your VM. We want to be reasonably safe. So we did this kind of thing that in hindsight, I didn't know uh about VPF and these other systems that sort of build this, but it's like very similar to a Berkeley packet filter and these other systems that have similar constraints, where there's this little tiny VM, it can like run your little bytecodes. Um, you know, you only have so many ticks of the of the virtual machine clock before we time you out and so on, and then a few primitives that make it easy to like gather stats and a couple of other things, right? So we built this thing, we need to be able to program it a little bit. And the way that we decided to program it a little bit was going to be this like subset of C that we were that I was calling Emmet at the time, um which is my first son's name, by the way. And the compiler for Emmet needed to be like needed to basically include the type system of C. We wanted to be able to pound include like kernel header files, for instance, so that we know what a proc structure looked like and things like that. And but then the actual instrumentation code had to be something else, right? And so it was kind of like this mild, you know, good-sized compiler project in a way, right? And uh I decided to do it with like Parsec and Haskell and all these like other like night, you know, power tools that that community has for language processing. And we got to work and shipped it and stuff. And then as soon as I handed that uh that project off, as soon as I like, you know, uh, I think pretty soon after that is when I started at Facebook, actually. Um, the team, you know, when I caught up for a coffee with the guy who took it over, he's just like, yeah, we just rewrote it all on OCaml, like first thing. We just and it was OCaml, by the way. It was like it's about you'd get a kick out of this. Uh so you guys you guys won one, at least like in in my limited footprint of attempts to ship Haskell. Yeah, it was more or less just like nobody could figure out what it was doing, right? Nobody could figure out like why it was so slow or why whatever was going on.

SPEAKER_02

Exactly. So that's the thing. So I think it's Haskell tends to produce correct code, and there are a few people who can write efficient Haskell code, but they really know the compiler inside out. And I think others who don't who write efficient Haskell code are those who are cheating. They basically write everything in a monad. And then if you do that, you're writing uh you know procedural programming using you know a functional language, so then I really don't see the point. But if you don't do that, you really need to know how the compiler is going to work things out. And it's incredibly brittle, right? Because you know, there could be a compiler optimization that kicks in, sorry. And if it does kick in, uh it's going to um in place modify a data structure and it's going to be very fast and very efficient. But now, you know, for some reason you change something that seemed completely unrelated, and this optimization optimization doesn't kick in anymore, and all of a sudden you're allocating a gate of memory, right? So it's memory that will be collected, don't get me wrong, because there's a garbage collector. But so that's my experience with Haskell. It's uh on small programs, it feels magic because it works and uh the output is good. But when you're trying to ship something professionally, managing the performance and predictably, like you know, in in a way that you know that uh is just always gonna work. Um it's reasoning about the performance in Haskell is is a nightmare, is basically what it boils down to.

SPEAKER_00

And it's really because you don't know um how much it's going to allocate and why. I think one of the reasons that this is still not like popularly well understood, by the way, Julian, is like unless you are implementing novel lock-free data structures, like just don't do this. Does it make any sense? Like, like unless you have unless you're building your own kind of you know, multiprocessor immutable structure, um, or you're implementing a garbage collector or some some other kind of exotic systems thing, um, I'm not sure you need to know this stuff. And understanding this stuff is an interaction of both like compilers, like a compiler level abstraction, right? Like release release semantics and acquire semantics is like a language level abstraction that hides real diversity in different CPUs. Like like ARM has a different memory model, actually, than x86. X86 does some of this stuff for you kind of automatically in a way that's hard to reason about. And it means if you just kind of write this code in a sloppy way at C or C and it runs on an x86, it might not work on other processors, even though you've got a perfectly good C compiler for that other processor. So I mean this is really kind of like I I understand like your frustration, and I also understand why people are like, what are you talking about, Grandpa?

SPEAKER_02

I think you should you should know these things if you want to write efficient code.

SPEAKER_00

And so I think I I tend to agree, of course, by the way, and I think we we did skip over an obvious thing in 2026 that we probably should not skip over if we're talking about uh how to learn to code, which is should you even learn to code? Right? We've we've got you know we've got these genies. You you say, hey, make me a CRM, don't make any mistakes, write lots of unit tests, go, and it can do it. So why do I need to know all this crazy stuff about where the curly prices go and when I want to acquire semantics and release semantics and what a load is and what a store is.

SPEAKER_02

Yeah, so I mean, if we are operating under the assumption that uh an AI is going to be able to program better than any human being on any given task, then learning how to program becomes purely basically intellectual curiosity, right?

SPEAKER_01

And and that's true, but

SPEAKER_02

I don't know that this is gonna happen anytime soon. So I go back and forth on this, you know. On Monday I think, oh my god, AI is amazing. And then on Tuesday I'm like, wow, I can't believe you got that. This is so wrong. So it's um so yeah, I don't know. I don't know where we're gonna land on this, but I don't think it's going to work out.

SPEAKER_00

I don't think uh so if I and and I've been wrong. This particular exotic corner of computing that we're dwelling on, which is like kind of lock-free data structures and whatever, this is like has been one of my kind of Turing tests for for coding genies for a long time. Is like, write me a lock-free hash table that will accept any key and any value, you know, a template a templated C23 lock key hash table, lock-free hash table. Um, don't make any mistakes, right? And it does seem like that's gotten better over time, but it's also sort of clear that it's sort of debugging it, you know, in a sequential, like it's sort of thinking about a sequential execution model. It's hard to describe exactly, but like it hasn't internalized the message of like Morris Rulia, he's the art of multiprocessor programming, or like other people that sort of have thought about this stuff in a in a deep way for a long time. It just doesn't have that model. But it could be like that, that's one RL data set away from having that ability, right? It could be that like, you know, they they hire me to write 20 of those things or something, and like now it works and that's all over.

SPEAKER_02

Well, the other thing is whenever you're going to you know test an AI like that, you have to remember that it has read all the code of a gazillion lock-free hashtags, right? And so, and it it understands all the comments and and so that that is a bit of a problem, right? Where you have somebody, let's say you have somebody, a smart human being, who has no understanding about computers, doesn't understand how the code runs, or doesn't have a good mental model about how the code runs, right? Uh but that person has, you know, read and and memorized all the lock-free hash tables that there's ever been implemented with all the comments and what they say.

unknown

Right.

SPEAKER_02

Don't you think that this person would be able to bluff you in a test like that? Probably. Sure. Right?

SPEAKER_00

Sure, sure.

SPEAKER_02

So and and that's very worrisome because the hash table is not the interesting thing, right? What you want to see is what happens when you ask something it has never seen, right? And how how does it do then, right? So I I don't know, man. I I keep on going back and forth.

SPEAKER_01

Yeah.

SPEAKER_02

I think AIs are fascinating, but I right now I don't see it.

SPEAKER_00

And I don't see it- I mean, I'm tempted to draw an analogy with the Haskell compiler in some ways, right? Which is like I, you know, it's nice when I'm able to get Haskell to work the first time on a toy problem, and especially if it's like a domain I'm not that familiar with, and I just want to get it done with, and and I'm happy that it works. Um, but if I care about resource utilization, I need a robust model of like what computers are and how they do what they do to even know what to ask for. And I think that like one of the things that I've been that I've found most surprising about these models so far, and I think it's still true with Fable, I think it's still true with GPT-5.6, is it seems like they're almost more like amplifiers for expert programmers than they are, you know, floor raisers for people who don't know how to program. And though I I don't know exactly what it is that went into expert programmers. It makes them so much more effective at like prompting these things and getting good behavior out of them over time.

SPEAKER_02

I know.

SPEAKER_00

Some of it's knowing how to code and knowing how computers work, though.

SPEAKER_02

Because you know, whenever you're writing code, a lot of it is boring and repetitive, right? And the the interesting part is actually really small. And so what these LLMs do is they get all the boring part away, but done. And then the f you you read, you you understand the few mistakes they made, and and then the places where you actually need to do something else, either you tell them or you do it yourself, right? And so that really what what your job is now is to make design decisions and review code carefully. Um, except in some places where whenever I'm writing something, which is rare, very rare, but that is very dense and very complex. Like there's 20 lines of code I really need to get right. Then I usually don't use an LLM. But other than that, it's basically saving you a ton of typing. The problem is I've had 25, well, it depends how you count, but 20 years of professional experience and 30 years of experience writing those programs and building that intuition. And so now imagine you don't have that intuition yet. It's because how how do you build an intuition, right? You write code, that code ends up uh biting you in the ass, coming back with a vengeance, and then you wake up at two in the morning, you know, because of a silly mistake you made, and then you learn. And then the next time you come close to something like that, I'm gonna add tests for this, I'm gonna do this, and because you know you've got those scars, and those scars cost you, right? Now, imagine you were 20. I mean, I I'm trying to imagine myself when I was 20. And so one thing you need to know about me is I'm incredibly lazy. And that's why I got into programming, because computers do things. That's like exactly.

SPEAKER_00

Yeah, computer people are sort of too lazy for mathematics or whatever.

SPEAKER_02

Exactly, yeah, exactly. And and so I know exactly why I would do 20 years old with an LM. I would try to get it to write pretty much every program that I want to work, and you know, frenetically um you know, shake it until it produces something that that seems like it's working. And then once it's not working, I would go back to the LM and say and shake it frenetically, saying, well, look, this thing has a burn. You need to, you know, you need to fix this, right? And and because I'm lazy, I think it would take me a very, very long time to come to the realization that, oh my God, this is not gonna work. I need to actually understand what's going on and write it myself. But I would have probably wasted a ton of time. And frankly, for the level of quality that was asked for me at university, I I would have probably gotten away with just LLM LLMizing everything, you know? And it would have been perfect, but I wasn't looking for the perfect grade. So it's like, oh, it's gonna be good enough. Um I'm lazy enough. So that's probably what I would have done. So, how do we prevent that? Because we're not going to go back to a world where kids are not gonna have LLMs. They're gonna have LLMs.

SPEAKER_00

Well, so I have a theory about this, and I want to run this past you a little bit too, actually, because we skipped over a couple a few steps in like my adolescent computer upbringing and yours too, because both of us apparently went through a C phase, right? So uh when I was trying to do Pascal stuff in in uh as a junior in high school, because I needed to take the AP test and I was excited about computers or whatever. This is a period in my life where I didn't have a computer at home. Like the Apple IIe had been sold, we were between computers. Um, there was the PDP 11 at school, but I didn't like actually have unfettered access to that. I had like, you know, a computer lab at lunch if I brought my lunch into the to where the VT100s were. Um, so I actually wrote a lot of code, pencil and paper, at this time in my life. I've wrote I had like little books about C. I'd read them, you'd flip them around. There's little 3D objects that we used to have. They're called books. They were like thin pieces of paper stacked up in a Z-axis.

SPEAKER_02

Never heard of them.

SPEAKER_00

Um yeah. And uh and used to learn a program this way. And so I'd have my little book about C and be like, oh, okay, cool, and not really understand pointers or whatever, but be starting to get it a little bit as it had weirder things with arrays in it. And I'd write these little programs out longhand in like a notebook, and then I'd have my chance to key them in, right? And you'd get to the computer and like, you know, try to get them to go and it wouldn't compile, but then the next day I'd be able to compile and so on. Um, but I think one of the things that uh that that ingrained in my brain that is really hard to get any other way that I know of anyway, is like a mental is the the sort of robust mental model of executing the machine, right? The robust mental model of kind of like line by line, okay, first it does this, then it does that, then it does that, then it does that. Um because like I know I can't just like interactively be like, well, does this work? Well, does this work? Well, does this work? Keep slopping things at it. And so a little bit like how um, you know, I I have a my son is a rising sophomore in college, right? And every college in the world has this crisis now of like, how do we do writing assignments? And one answer is because basically, like you can, you know, slop your way through darn near anything and like write a way better than undergraduate level essay about almost anything with a one-line prompt now. I mean, yeah, there's like cheating detectors and stuff, but it's a whole arms race. The uh and one answer is just to like give people pencil and paper and a notebook and sit them down and say, like, you're gonna write this out longhand and then we're gonna read it and grade it the old-fashioned way. And I think that's a might have a place if you really care about learning how computers work and learning how to code well these days. Um, and I think they're I think you should, but that also is like an insanely monastic thing to say out loud now. Does that make any sense?

SPEAKER_02

Like Yeah, but I mean I I remember I had a taste of that. So I had access to a computer in high school. So I was able to program directly on a laptop. Uh, but um the exams at university were done on pen and pa with pen and paper. And uh ton of um uh work, homework at university was pen and paper. And so I wrote an insane amount of code using pen and paper as well. And that's how actually you were graded. So you actually had to be pretty good at writing, you know, code with pen and paper because that that's what was graded, you know. The the project um being graded directly, project that you would write with a computer, that came in my fourth or fifth year. So almost all my studies I was I was using pen and paper. And I'm with you that this was um a very useful experience because you you have to have a mental model of what's going on in the machine. But I don't know that uh somebody using Emacs doesn't have that model. I think the pen and paper is just a pain in the ass. I think uh it's but uh the LLM is a step further because the LLM Yeah, you can just not understand what's going on at all and have you know a level of understanding. So let's let's put it this way. I think somebody who learned how to program directly with computer with Emacs, running Emacs instead of a pen and paper, I don't know that this person doesn't understand as well the C model than somebody who used pen and paper, right? Um so I don't know that we have to go as far as back to pen and paper, because back then it was just for logistics. But what we should definitely do is use computers that don't give you access to LMs or the internet or anything, and then you have to actually, you know, read the docs, you know.

SPEAKER_05

Yeah, yeah.

SPEAKER_02

And that was that was a big one, right? Like man, you know, you were reading docs.

SPEAKER_00

Yeah, I remember like yeah, getting good at using the documentation tools was a was a whole thing. I was told you my crazy, like uh my crazy keyboard attestation idea before. Have I been over been down this rabbit hole with you? No. So, you know, like you you've got these manufacturers like Apple who are like making keyboards, right? You could have them um imagine, you know, they've got they've got this magic button that you touch with your fingerprints already, right? So they've got that one magic button. Imagine there's a new magic button. And what the magic button does is like sign a digest of the keystrokes from the last 30 seconds with Apple's private key, or with the with a key that's on the keyboard anyway. Um this would be the basis of a technology that would let you say a human wrote these characters, right? This would be the basis of a technology that lets you say like this got typed by a person instead of by an LLM. Um and I think there's analogs with like cameras and stuff too, if you're worried about like AI propaganda and things like that, right? Can imagine having a doing a similar thing with like, hey, a photon sensor actually captured this from a real physical light cone modulo encryption working, right?

SPEAKER_02

So why couldn't an LLM use the same key to generate?

SPEAKER_00

It's a secret. Because Apple doesn't give their keys to OpenAI and doesn't give their keys to Anthropic. They put them in a you know secure enclave on your keyboard that they ship. The same way your phone has these things.

SPEAKER_04

Okay.

SPEAKER_00

And this is like a the this is like a weird you know standard that I that I think could be you could imagine proposing. It takes like a little bit of coordination, right? Because like once you have a keyboard that can produce this, you need something that can kind of consume it, and you need to like ship it around somehow, and you need to like decide how the little JSON blobs are laid out and blah, blah, blah. But you can imagine a world where I can basically have a Google Docs, except only humans you know, hitting the springs on keyboards are able to populate the characters in the Google Doc. Um, or at the very least, I can go back and see which keys I hit, right? And if I suspiciously pasted in, you know, 5,000 characters that have lots of M dashes in it or whatever, you might say, huh, this looks suspicious, right? Um this is like kind of a crazy, like that's a good idea. And I we're gonna want this eventually, right? We're gonna want to be able to say, like, hey, this was you know, not only am I did I just sort of run some pangram defeating adversarial thing over AI slot output. This actually wasn't AI slop output. This actually came out of my my keyboard and my my joints. Um I want this now, right? Like I wish I wish I could prove this to people sometimes. Like I wish I could like the emails that I actually write by hand because I'm like, I want you to pay attention to this, because I paid attention to it. Like it would be lovely if I could like stick some hard to fake thing on the side, being like, Keith actually wrote this. I'm sort of building a little um a list of the things that we're losing, I guess, from like the the era where like you sort of you know would sit in Vim raw dogging characters, like or Emacs, if you're, you know, as your preference may be. Um the the end of that world. And I think like because as a programmer, you're always trying to do something, you know, you're you're trying to do something new, right? Because if you're just doing what you did before, you just run that program. You wrote it already. Um so you're always kind of trying to get the computer to do something new. That sensation of like, I want this very simple thing to work. Like, why doesn't it work? Why am I not smart enough to get the machine to do what I'm trying to get it to do? That sensation sort of never goes away. And I think one of the things that took me almost like 25 years or something, you know, part of my entire professional career as a programmer to realize is like I got good at this somewhere along the way. Does that make any sense? Like, there was never a moment where I like felt like, oh, now I'm an expert, because I always imagine that experts were just like that, you know, John Carmack or someone would just sit there and like his mind would like reach tendril-wise out into the CPU and like deposit the right bytes on disk or whatever. Yeah, exactly. Just deposit like the correction.

SPEAKER_02

All the time.

SPEAKER_00

Yeah, yeah, exactly. And um I mean, you know, like it turns out he's mortal too, and so is every human programmer. And you actually spend your whole life kind of just sitting there being like, why am I not smart enough to get this freaking box to do this stupid thing I'm trying to get it to do? It turns out that like in year 20, it's a more complicated, more ambitious thing that you're trying to get it to do, um, and probably closer to sort of some margin of what's been done before than than when you're just getting started. But you never actually feel that great at it. Does that make any sense? Like you never sort of like, oh man, I really nailed this whole programming thing now. I don't need to get any better at this. Um and that is uh, I don't know whether that remains in this world with like the coding genies.

SPEAKER_02

I think like well, I think there's another thing.

SPEAKER_00

The thing about the the margin of like you still need to do the hard part a little bit, right? You still need to sort of like boil it down to some kernel of like, okay, this is the tricky part. Um, and that still involves some intellectual effort. But go ahead.

SPEAKER_02

So so yeah, I think that there are a couple of other things that uh I've I've witnessed with pro programmers. So the first one is because programmers are constantly um you know, have constantly to face the fact that they were wrong, because the machine has shown them that what they what they had in mind was not true, was not working. It's it teaches them humidity. So there is there's two kinds of programmers. There are those who to whom it teaches humidity, and they're like um, you know, when whenever they approach another problem, they're like um, well, I might actually be wrong about this, because you know, I was absolutely sure that this function I wrote 10 minutes ago was correct, and yet here we go again, it's incorrect. And and so when you realize how sloppy your brain is, normally, you know, it makes you question, you know, how how opinionated you should be about something, because you know that your brain can be wrong and can be sloppy about complex things, right? And so most programmers I know that actually translates in their everyday life, right? They've programmed for a long time, they know that they can be wrong. So whenever you ask them to think about something complex, whether it's related to programming or not, they will um they will have a tendency to think, well, maybe I'm wrong about this, and you know, be cautious, right? But there's another class of programmers, and I would say they're a minority, but they exist, who approach the problem in a different way. So the way they do things is they write their program, and as they write their program, they're absolutely certain they're right, right? It's it's correct. Of course it's correct. Oh, yeah, yeah, okay. Until the machine says, uh-uh, uh-uh-uh, not working. And then they get used to the fact that basically the way they operate is of course I'm right, I'm 100% right, until something irrefutably proves that I'm wrong. Right? And the problem is if you operate this way in pretty much anything other than maths and computer science, basically you're going nowhere, right? Like if you're talking about design and you say, I'm absolutely sure the button has to be blue. And and until somebody proves to me that this button doesn't have to be damn blue, I'm I'm going to assume I'm right, then that leads to, you know, a kind of toxic behavior. So I think I would say overall, spending your days having a machine telling you you're wrong is healthy and it leads to healthy behaviors, you know, outside of, you know, in in the rest of your of your life, um, outside of a few exceptions. And yes, I think that's part of what uh LLMs are probably going to change. Also when it comes to maths, because maths is a is a lot like that too, where you have to be you have to be precise, you know, and and part of mathematics was of course the interesting part was you had to be inspired, you had to have ideas and how to connect things and how to model things. But there was the grunt work of actually writing down the proofs and when you had to be meticulous enough to make sure that you know you were not making any mistake, right? And now that part is probably going away because you'll probably give it to an AI and say, well, use this and that theorem, go go prove this, and it's probably gonna work, right? So that's probably going away too.

SPEAKER_00

Yeah, it's wild. We had a uh, you know, at Pelobot we had a conference of sort of working mathematicians a couple months ago, just like a three-day kind of discussion about AI and math. And it felt like sort of 18 months ago for programmers. It felt like sort of the, you know, the way that the programmers were when it was first becoming clear that this was sort of important, that was going to change the way that we operated. And the the whole set of reactions kind of ran the gamut from like, you know, people who are in an academic department where they model the profession of mathematics as the production of new theorems. And if there are machines that do this, like why do we still have math departments and how do I get funding, right? Versus people who are all the way on the other side who are like, hey, I got into this because I was curious about the the universe and curious about these intellectual questions, and think about all the amazing, you know, chunks of the idea tree we're going to be able to unlock once we, once we're able to answer some of these long-standing questions. Um, and I think they're they're kind of both right in a certain way. I think it's probably true that that mathematics ends up getting reframed if you ever did frame it as just sort of the construction of new theorems. I think it's they're they're having a little bit of an analog to what we're talking about with coding agents too, which is like you need to know what to build and you know what makes sense to build and what's interesting to build and know what actually sort of is useful and what connects you know to the real world in a grounded way. And they don't know that yet. And I think there's a similar thing, oddly enough, with mathematics. You think of mathematics as being this kind of pure crystalline structure in the space of ideas, and there's a perspective where it is, I guess. But the theorems that we find interesting are very, very sparse, right? Like the parts of mathematics that we actually care to explore are really, really sparse in that sort of vast galaxy of kind of little trivial changes on things we already know. Um, and you still need somebody to sort of say, like, no, you know, Riemann's data function, this is a really interesting object.

SPEAKER_02

Or yeah, but you could also have an LLM say that too, right? You can have an LM say maybe an LLM or something else, an AI that says this is actually a really interesting figure. Um If I was 20 years old today, well, 20 maybe, maybe a bit younger than that. Let's say when I started serious programming seriously, let's say 14 years old, I would be a vibe coder today. I would be a vibe coder because you know, I was lazy. I was very, very lazy, and I still am. And that's what got me into programming. Like I wanted computers to do things for me. So when I was 14 years old, I would have become a vibe coder, which means I would have frenetically asked, prompt the you know, the computer to do things for me.

SPEAKER_03

Yep.

SPEAKER_02

And so just so that the old Is following what I call vibe coding, and I think smarter people have defined this before me. But what I mean by vibe coding is you write a prompt, it generates a program, and you never actually look at this program or try to understand what it does. The only thing you do is you run this thing and you see if the behavior is what you want, right? So for example, you write, write me, you know, um an app that tracks my categories, right? And so then the LLM produces something, you run the app, and then you say, oh no, I want the button to be there, not there, and you you keep on prompting, and basically the LLM keeps on iterating on the on the program that you're trying to build. That's vibe coding in my book. And I think back in those early days, given that the kind of things I was trying to do was simple, I would have probably never gotten out of the LLM of the vibe coding jail, if you will. I would have kept on, you know, and so one of the challenges for educators is going to be that. It's going to be you you now have a new generation that's coming. They need to actually understand things, whether it's in mathematics or you know, or computer science. And how do we and so I like your idea of um the keyboard that actually signs the fact that keys were pressed. That's actually pretty neat because now you actually have to press it with your fingers. Of course, there will be people who cheat and who will have an LLM that another computer that produces the code and they then they they copy that code um with with their little fingers. But at least they're writing something.

SPEAKER_00

I mean if there's a if there's a secure enclave, if like you if you kind of imagine that hardware encryption works, or if you kind of imagine that there's a tamper resistant store that like can sign stuff that I can slap on a keyboard, which you know there this there are hardware products based on this today, like HKMs or whatever. Um I think you can actually do this in a way that's like not easy to cheat on, right? Maybe we should make up a maybe we should make a hardware go fund me. Maybe this should be the theory.

SPEAKER_02

Well, the the only thing, the only way to cheat at this point is to have a second computer that is connected to an LM and that produces the code or produces the text, and then you have to copy the text.

SPEAKER_00

Well, so remember that second computer would need to either know the secret that's in the hardware key or robotically produce it, right? So so there's the analog hole, right? Like I could have robot hands type on this thing, right? And then the robot hands really would look like they they typed it. But that's a pretty expensive analog hole, right?

SPEAKER_02

Exactly, exactly. So you can still cheat, yeah, but it's expensive.

SPEAKER_00

It's just like I can put an iPhone camera with a screen that's playing an AI slob video or whatever, and then like you'd have a you know, iPhone camera.

SPEAKER_02

Well, I mean the other thing you could probably do is hijack the signal that sends it because you know the hardware that signs the keys is listening to the device. And so you can probably hijack the key. No, no, the hardware that it's on device. You buy the you buy the keyboard. No, I get it. I get it. Sorry. You buy the keyboard with with there's a little thing on the keyboard.

SPEAKER_03

Yeah.

SPEAKER_02

And so every time I press a key, there's a signal that leaves the key that goes to the thing that's signs, right? And so all you have to do is hijack the key.

SPEAKER_00

So if I have a J tag or something and I electronically mess with the switches, yeah, that's true. You could make this sort of switch array of the keyboard, uh, you could you could instrument that and and cheat that way. That's true. But yeah, yeah, I mean you're talking about sort of like attacker hardware at that point or whatever, right? Um and the market for that's always gonna be smaller.

SPEAKER_02

It's still much slower because you could easily add something that says that if the if the keys are coming in too quickly, then it's not it's faster than you can.

SPEAKER_00

Yeah, if it's if it's more than like the actions per minute of like a championship World of Warcraft player, then like you don't believe it, right? Yeah. Yeah, exactly. I really think there's sort of something here, by the way. Uh this would be this would be fun to try to start doing things. And then then you could like make web browsers that have tech century fields that like require that you use one of this thing, and then blah, blah, blah. Um, I I really think there's sort of something interesting here. Um, it's tricky because you have to, you know, you have to coordinate lots of parts of the software stack, right? This is not a problem that we've had to worry about until right now, basically. Um, and so the software stack kind of assumes that like input devices are input devices. But this also comes up with uh like people with all the sort of countermeasures on websites for for bots, right? Like you could imagine a website that like wants a mouse that's like this and and wants a keyboard that's like this. And if you know there is not a key attesting that like some rollerball moved the XY wheels on a mouse the right way, then I refuse to sort of take this like clawed computer use, you know, trying to scrape my website thing. Like that could work, you know. Um that that idea of like how we get back to the econom like AI right now has sort of broken the economics of the internet that like you and I grew up with and and it hasn't reacted yet. Like we're not at equilibrium yet. So there still isn't internet out there where there's lots of like free content that people put up there. But like the economic motivations for doing that aren't really there anymore. If I actually like have a bunch of like amazing technical content, unless that is also marketing for something I'm selling, there's not a lot of reason for me to put that up for free anymore. It used to be that like, okay, Google will like help me to sell advertising against it. Yes, that's true in concept, but what's actually gonna happen now is I'm just like making the products of anthropic and open AI and whoever else much stronger, and I have no way to participate in that. And so, you know, the the thin end of this wedge is that the arms race of people trying to prevent scrapers and trying to prevent sort of uh people from mechanistically accessing the data on their website is getting ratcheted up a little bit. So maybe those are the people who end up applying the pressure for for this to show up in input devices.

SPEAKER_02

Yeah, I I mean the the bigger problem that I'm actually worried about, I'm actually worried about this, is what's going to happen to the next generation of coders. So, okay, there's a future where we don't need that. All right, fine. And then you shouldn't be learning how to do that. Do you try to believe that by the way?

SPEAKER_00

Like seriously, like tough. I don't believe it at all. Okay.

SPEAKER_02

I don't believe it at all.

SPEAKER_00

I kind of don't either, and I don't know why exactly, but I but I'm with you. So keep going.

SPEAKER_02

So but the thing is, what plans to doubt in my mind every single time is when I talk to super smart people, you know, who work on top, you know, in one of these top companies who I'm friends with and who just are completely convinced that yeah, it's a done deal. You know, like top, top, top engineers in those top companies building those frontier models, they all tell me, yeah, yeah, I mean in two years, soft engineering dumb, you know. That's every time stops me in my tracks, and I'm like, whoa, like that and and if that person thinks that, and that's not you know, that's not somebody who is you know super enthusiastic about everything and uh who believes in the in and in every threat the internet you know has produced, this is somebody who's actually critical of a lot of things, so that always stops in my tracks, but at the same time, the dissonance with my experience with those LLMs is just so big every single time. So here's uh uh here's a way I see it. If we had an LLM where you could say, design me a piece of uh engineering, a piece of software, you know, that is actually really hard to design. And it doesn't have to be full-fledged, doesn't have to be the full thing, but you know, something that a graduate student would design and write and get right if you you gave them enough time, right? So let's say you told an LLM, hey, design me a database that has this and that property, right? And if it was actually able to produce something that works, then I would say, oh shit, you know, you know, time's up, it's it's happening, right?

SPEAKER_00

And or or a database of something else, you know, could be what would your threshold so dumb dumb uh it so happens I'm in the middle of such a project, by the way, and it's literally a database. Uh like what's your threshold for how one-shot-ified that needs to be, I guess, right? Because like it's still very much a project, to be clear. Like my experience so far is it's still very much like that. That's a that's the big thing.

SPEAKER_02

For me, it would have to be a one-shot, yeah, yeah, yeah. And it would have to be different enough from something that exists. So let's say here's my here's my my take. It would have to be one shot, it would have to be different enough for from something something that exists that you know it's it's uh it clearly it was not by copying, you know, another program or translating another program. And it would have to be uh sophisticated enough that you know the complexity uh you know is non-trivial. So to give you an idea, Postgres from Postgres from 30 25 years ago would be enough. You know, if if you were to say, write me an implementation of SQL that had this and that property, and that does this, this, this, and that, and you test this and that property, and it actually able to do the whole thing by itself, that means it was able to design the whole thing and was able to test the whole thing, and it was because so far the things that I see are things that don't have one of those three things, right? So either it's there's a gazillion of those on the internet. So you say, all right, write me a lock-free hash table. Well, how many lock-free hash tables are there on the internet? A lot of them. So if you read them all and if you, you know, you you you will be able to put something together without understanding what makes a hash table, a lock-free hash table, or a lock-free hash table. The the number two thing is, you know, it has to be by itself. Because if there's a human who's how hand holding and saying, oh no, do this and then don't do that, then okay, but then the human has you know help with the design decisions and who really made the design at this point, right? Right, right. And the third thing is that it has to be big enough, right? It cannot be something small where you keep on, you know, brute forcing the thing, you'll eventually get to something that works. So, you know, something the bar for me would be hey, write me a clone of Unix that has this and that property that no other Unix system ever had. Interesting. And um actually make it work.

SPEAKER_00

Yeah, yeah. Yeah, it boots on a PC and it like yeah.

SPEAKER_02

It boots on a PC, and if you can do that, and it doesn't have to be at the level of performance of Linux, it could be like Minix or something like that. You know, I I don't expect the full professional thing, but but if you can actually write that, that's the moment where I say, oh shit, shit, you know, we're fucked. Um that's it.

SPEAKER_00

Like this is my drop. If I can try and like close the circle here a little bit about learning to code too, like a pretty influential book in my journey here was discovering uh the Lions Book, freshman year in college, which is um there was a University of New South Wales professor in the 70s uh named Lions, and he basically produced this little book that was the source listing of Unix version 7, so like 1977 era Linux, or Unix rather, which was like 10,000 lines. Very, very comprehensible, like you can understand this program, it's not that crazy. And then uh a bunch of text that's about the same size, that sort of has cross-references to uh to lines and page numbers in the source code that explains how it all works. And if you kind of like read this short, this kind of like novella, it's it's 75 pages or something. If you read this novella, at the end of it, you kind of understand how Unix is. You understand like what the abstractions are, you understand how the machine, you know, how those abstractions map to machine facilities and so on. And it's an archaic machine and it's like there's nuance and it, you know, all the multiprocessor stuff we talked about that weren't multiprocessors yet. There's lots of stuff that's very uniprocessor and blah, blah, blah. There's still lots of stuff of work to do on Unix. Um, but that actually inspired me freshman year to uh to take the operating system class uh that Brown University had at the time, which at the time was was um based on a bunch of kind of ideas and operating system research that were that were au courant in the late 90s, right? So it was a microkernel, it was object-oriented, it was in C, uh, lots of other things about it that were kind of hard. And I took the class, failed the class, took the class again, passed the class, uh, and then wanted to rebuild the project for it. And so me and three other uh folks, like Michael Castell, Dave Powell, and Jason Lango, built Winix, which is like our attempt to bring the Lions book into the early 2000s, right? It was like our attempt to bring, you know, a 10,000 line or so comprehensible. You can get your head around in a couple of weeks, maybe a couple months of study, Unix implementation of the modern era. As far as I know, this is still the operating systems lab course at Brown University. Um, Tom Deppner, the professor, like actually wrote a wrote a textbook about it. And, you know, the property that this one had was basically like tractability, it was just sort of like make all the decisions in like a relatively simple way. But it's still, there's still a file system, and the file system still has you know permission bits on it, and there still are, you know, um, you know, there's still virtual memory, there's still fork, you still like care about inefficient implementation of fork and all these things. And there's a lot of nuance there that like I think is is pretty rich and pretty satisfying. And you're right, that'd be fascinating to see. And and while we're and while we're on this, by the way, you mentioned before about like sort of the life cycle of programs. It's a it's a fact about the software industry that the vast majority of economic activity and software is in maintenance, right? The vast majority of sort of where the money goes, yeah, whether you're in sort of like a fang company or opening out or whatever, yeah, um, is not you know, and that's usually a big problem. Yeah.

SPEAKER_02

Because the the people who are in charge of the company, they need those maintenance people. And what they don't realize is those maintenance people are very good at maintaining the system in place. They're very bad, horrible people to ask, should we should we do this new thing? Right, right. And that's how big companies become basically, you know, frozen. Like nothing new happens because every time there's a new idea, the boss thinks, Well, I'm gonna ask my guys what they think about it. Well, I can tell you what you guys think about it. And I mean, some of the teams that you were involved in, I've seen them evolve. Yeah, yeah. They've seen go from you were the new kids on the block, you know, full of new ideas and dah, dah, dah. And you come 10 years later, and whenever you ask that same team, well, shall we do you're not able to finish the shall we do this with a single thing? No, nothing's possible. No, no, go away. Go away, leave it, leave the room now. And so and so that's a problem for companies, right? Because they need people to rely on that that they trust, because of course what matters to them is a system that is actually running, right? And that's how they make the money. So they don't want to upset the existing ecosystem. So a natural inclination of the leaders of a company like that is going to be like, well, let's ask the people who are actually running my stuff what they think about this new thing. And what they don't realize is that the people who are maintaining things, they love that mindset. They want to keep on maintaining whatever they're maintaining. If you come in, come in with something too drastic, too novel, they don't like it. And it's not because they're evil spirited or you know, they're bad people, none of that. It's just that it's not in their temperament to like new things.

SPEAKER_00

Can I try and like get through a couple of takeaways here that are hopefully useful? So, for one thing, right? Learn to code. Like that was one of the preliminaries. It's like the there's the people are asking the question is knowing how to code a depreciating asset? I think it's an appreciating asset. It seems like it's providing more leverage, not less, over time as these agents kind of take over some of the grittier work. Um, how do you learn to code? You learn to code by coding, right? By writing a lot of it, including probably writing a lot of it without the aid of LLMs, which I have to admit seems to require a superhuman amount of discipline. I don't have a perfect solution to that right now. You know, we've we've talked a little about long hand and magical keyboards that that force you to do it, maybe. Um maybe other pedagogical tools are part of it. And you also need to read the code. Like I think neither of us think that the era of vibe coding, at least for ambitious software projects, maybe you can vibe code your CRM or your recipe book or your you know, your exercise diary, things that have been done a million times before, but doing something new at the boundaries of software, which is what Red New Software is for, right? If you're not doing something new, just use the old software. Um if you're not if you're doing something new at the boundary of software, you still have to read it. And the more you know about how computers work and the more you know about how code works, the more expert you're gonna be at reading it and uh at exercising editorial control over what these agents are doing. What are some other big takeaways that were missing here?

SPEAKER_02

It's just fun. You know, it's funny because it's fun. You know, it's like, you know, it's as if somebody was telling you, you know, why should I read poetry? Well, because, you know, it's fucking awesome. You know, that's that's uh that's the other thing with science and computers and maths and all that stuff. It's fucking awesome, you know, an LLM can do it. Yeah, an LM can do it, fine, but I mean, it's true that now we're professional software developers, so we think like professional software developers, which is like at this level you're expected to write things that are new, that's true. But remember, for a long time we were not professional developers, and we're just writing things that were not new. Like, I've written a MADOC, and you know, Jason would probably laugh at my implementation, you know?

SPEAKER_00

Well, but I guarantee you Jason started off by just writing, you know, by writing a free list or something, by just writing some malloc that you'd yeah.

SPEAKER_02

Exactly. And so I think that's the other thing. Like, you know, it's just awesome. You know, understanding mathematics, understanding computers, understanding science is awesome, and it will, you know, open your mind to so many other things that you know that's the missing takeaway for me. Like, yeah, it's just part of a birthright as humans, right?

SPEAKER_00

It's just a part of intellectual culture now. It's like this is a thing you can do, and it's rad.

SPEAKER_02

It's rad, exactly. And you'll understand things in ways that you know will change the way you see the world and how you think about things. So, for example, in mathematics, what's really good when you when you're good at maths, which is not my case, but what maths it brought to me is the ability to formalize, right? So you have a problem, and I still do it today, you know, like whenever a problem gets a little bit complic complicated, even you know, for mundane things, I still find myself going like, okay, x plus two equal y. And I'm basically formalizing whatever, you know, in that particular situation, whatever, you know, the the problem, how it should be formalized, and then I apply the rules of mathematics to solve the problem, even in mundane situations, right? And for software, I think, and I I think I've said that before, but I'll say it again. What is the difference between, and that's why so many people are good at Excel and not so good at programming? The difference for me between a programmer and on and a non-programmer is that the programmer is able to simulate the the machine, what the machine is doing, especially what's happening in memory in their mind, right? And so that the for loop is really, or the non-trivial while loop is really where where for me the difference happens, right? Where you take somebody who knows Excel, they never have to think about state. They just have this thing is equal to that thing, which is equal to that thing, and then I do plus this and plus that. The moment you have to maintain a state in your mind, that's the moment you become a programmer in my book, which is ironic because I like functional programming, and in functional programming, you're not supposed to reason in terms of states, but you know, I'm gonna leave the irony at that. Uh but you know what? This ability to simulate things will help you. There are many, many cases where you'll have to do that. You know, in your life, um, you're running, you know, anything. You're running, you're trying to make a decision, you know. Shall I take this job? You know, and you're running a simulation. You're like, well, if I take this job, I have to go and work at this place. Is this place close enough to where I live? And then if I do this, then this will happen and that will happen. You're running a simulation, you're maintaining a state in your mind, and that's just one example, but there'll be many others. And so even if you know the AI takes over the world and programming is completely useless in terms of you know getting dollars out of it and making a living out of it, the fact that you still went through that mental exercise has a ton of value in my book.

SPEAKER_00

Yeah, yeah. NC. Awesome. Yeah, yeah. Old Man Yells a cloud, eat your Wheaties, learn the code, kids.

SPEAKER_02

Okay. Exactly. Learn to code, it's also it's learn to code, it's awesome.

SPEAKER_00

We recently had a guy start at a pebble bed, a young man named Bology Dagupati. Who's a grandmaster of chess? And he's he's very young, he's 20 or early 20s anyway. And uh he's only lived in a world where computers are dominant at chess, right? He's only lived in a world where this is an activity humans still do, but computers are dominant at it. And the way that they use computers is non-trivial, right? They still rely on these tools, right? These tools help make them better at playing other humans. Um, and it's interesting how they do that. And I think like that's a thing that still is waiting to be discovered and figured out is like, okay, you still need to learn how to do all the things that programmers do, but you also have these weird little kind of superhuman assistants, and and can we use them to develop our intuition and and strengthen faster than writing things in notebooks and banging our heads against the keyboards the way Julian and I did, because that's what worked for us. Um that's interesting.

SPEAKER_02

Um But there's a difference. The the the big difference is that chess is against an opponent, uh programming is against yourself.

SPEAKER_00

Yeah, chess is an entertainment activity, right? We do it, we always did it for the other.

SPEAKER_02

Well, and and there's an opponent. There's an opponent, right? Yeah. And so what's different with programming is that it's against the battle is against yourself. You have an idea in mind, and you're almost certainly going to get it wrong. And you think you're right, but your reasoning is incorrect, incomplete. And that's where the value of letting that go through, you know, and letting that play out, and you know, pay the price for that bad reasoning down the line, that's invaluable, right? So, which is a little bit different than your pl when you're playing against another another uh an opponent, right? Then you only need to be better than your opponent. You don't need to be right in absolute terms. So you're not really playing against yourself, you're playing against somebody else, which changes, I think, the dynamic.

SPEAKER_00

Yeah, I mean, but if we viewed, if we try to view programming as like a solitaire game or something, I'm not sure it's so intrinsically different, right? You're um when you're bad at chess, you lose a lot and you learn from that losing experience and you you know improve. And um when you're very good at it, you start to think of yourself as as playing against yourself in the sense of like, you know, it might not be that I'm that I'm facing a bunch of opponents that are way stronger than me.

SPEAKER_02

But that's kind of my point, which is that if you are playing chess and you're playing a ton of chess against humans, then your mistakes you will have to own that or own them at some point, right? And so that is the nice feedback loop, which is like, well, if you suck at chess, you're gonna lose tournaments and you're gonna try to improve, you know, a chess because you don't want to lose, right? And the problem with with with programming, because it's solitary, solitary, am I pronouncing this right? I don't know. Yeah, um you don't have that experience, meaning when something goes wrong, you you don't have that feedback loop that tells you this this was wrong, you shouldn't do things this way. There and and so that's why I think it's gonna be much harder for programming or for maths, you know, or anything that doesn't require another human being, as long as you can compete compete with an another human being or compete in a place where you cannot cheat, where you cannot use the computer, you're safe.

SPEAKER_03

Yep, yep.

SPEAKER_02

You will improve because you have that feedback loop. You will remember the times where you lost, it will be painful, and you'll remember to do better next time. But if you don't have that feedback loop that tells you you are wrong and it's gonna cost you, it's gonna be tough.

SPEAKER_00

Thank you for listening to another episode of Computers, Coffee and Beer. We had the computers, we had the coffee, we had the beer. If I may crudely summarize, should you learn to code? Oh my god, yes. Absolutely. First of all, because it's wonderful and you're gonna love it. Secondly, because it's actually gonna make you better at your software engineering job, which isn't going anywhere. How do you go about doing it? To some extent, the old-fashioned way. Yeah, there's lots of things, there's lots of crutches out there that make it hard to do it the old-fashioned way. Figure out how to tie your hand, tie yourself to the mast and learn it anyway. Um, and you're still gonna need to read a lot of code, almost even in a world where it's only computers writing the code, the fact that you know how programs work and know how computers work is gonna make you way more overpowered as a user of these coding genies than uh than people who are just vibe coding in today's parlance. Um, Julian, thank you so much, and thank you for listening. And we look forward to talking to you on another episode of Computers, Coffee and Beer. Um, remember to smash like and subscribe. Uh, and have a good one. Thanks, Keith.