Lenny's Podcast: Product | Career | Growth
00:41:12 · Marc Andreessen
In coding, the tasks are going to change. Product management, the tasks are going to change. Designer, tasks are going to change. And so, the job persists longer than the individual tasks. And then as the tasks change enough, then that's when the jobs change. And so at the level of individual, you want to think of like, "Okay. I have this job, the job is a bundle of tasks. I need to be really good at making sure that I can swap the tasks out. I can really adapt, use the new technology." Get really good at AI coding, for example. And then you want to add skills. "I can also get really good at design. I can also get really good at product management because I've got this new tool." So, you want to pick up more and more scope as you do that. And then 10 years from now, is your job title coder or coder/designer/product manager? Or is it just, "I build products"? Or is it just, "I tell the AI how to build products"? It's like whatever that job is called, who even knows what it's going to be, but it's going to be incredibly important because the people doing that job are going to be orchestrating the AI. And so that's the track that the best people are going to be on, and I think that's the thing to lean hard into.
00:42:17 · Lenny Rachitsky, Marc Andreessen
[00:42:17] S1: I think people aren't fully grasping just, specifically, software engineering and how much that is changing. It's pretty clear we're going to be in a world soon where engineers are not actually writing code, which I think, a year ago, we would not have thought. And now it's just, clearly, this is where it's heading. It's like there's going to be this artisanal experience of sitting there writing code, which is so crazy how much that job is going to change. [00:42:39] S0: Yeah. So again, here, I go back. And again, pardon maybe the history lesson, but I go back coding. So, the first... Do you know the original definition of the term calculator? Do you know what that referred to? [00:42:50] S1: No.
00:42:50 · Marc Andreessen
[00:42:50] S0: It referred to people. So back before there were like electronic calculators or computers or any of these things, the way that you would actually do computing, the way that you would do calculating... Like the way that an insurance company would calculate actuarial tables or the military would like calculate, I don't know, whatever troop logistics formulas or whatever it was. The way that you would do it is you would actually have a room full of people. And by the way, these are like big rooms. You could have hundreds or thousands or tens of thousands of people doing this. And you would actually figure out... Somebody at the head of the room was responsible for whatever the mathematical equation was. And then, they would parcel out the individual mathematical calculations to people sitting at desks, who were doing them all by hand. And that job title was those people were calculators. And so, we've gone from a world in which you literally have people doing mathematical equations by hands. Then, we got the first computers. The first computers, of course, didn't have programming languages. They only had machine code. So, the first computers were programmed with 1s and 0s. And so the task of the programmer became, "Do the 1s and 0s," and then that became punch cards. And you can still... There's still people, kicking today, whose job as a programmer was to build the punch cards. And then you got, actually, this big breakthrough, which was called assembly language, which was basically the way to do machine code but with some level of English added to it. And then the best programmers did assembly language. And then when I was coming up, it was higher level languages like C, that compiled into machine code, and that's what programmers did. And then I still remember when scripting languages... We developed JavaScript at Netscape, and then Python took off, and Perl, and these other scripting languages. When scripting language took off in the 2000s, there was this big fight in the technical community, which is, "Scripting, real programming or not?" because it's like it's kind of cheating. Because real programmers write code that compiles to machine code, and real programmers do memory management themselves, and they do all of this whole craft of writing a C code.
00:44:43 · Marc Andreessen
And these JavaScript or Python programmers are just doing this kind of lightweight things. Does it even really count as coding? And of course, the answer is yes, it very much counted. And now, most coding is done with the scripting languages, which have... You see my point. The scripting languages have abstracted away, like, five layers of detail underneath that, that people used to do by hand, and they don't anymore. And then to your point, AI coding is the next layer on that. AI coding actually abstracts the way the process of actually writing the scripting code. And so in one sense, this is a really big deal for all the obvious reasons. But on the other hand, it's like, "Okay, this is the next layer of the task redefinition under the job of programmer." Now, what's the job of the programmer? To your point, it's not necessarily to write the code by hand. But what it is now is, all right, if you talk to the world's best programmer of yesterday, what they'll tell you is, "Oh, my job is I'm sitting there and I'm orchestrating 10 code bots, coding bots that are running in parallel." And literally, they sit there and they shift from browser to browser, or terminal to terminal. Their day job now is arguing with the AI bots to try to get them to write the right code, and then debug it and fix the problems, and change this back, and do all of these things. And so now, the job of the programmer is to argue with the coding bots. But if you don't know how to write the code yourself, you don't know how to evaluate what the coding bots are giving you. And so, you asked about the 10... Our 10-year old is super into computers and super into programming. He's using Claude, and ChatGPT, Copilot, and all of these things. And what I'm telling him is like, "Look..." And by the way, he loves vibe coding. He's on Replit all of the time doing vibe coding, doing games. He's sitting there. It's hysterical because he's sitting there. It's a 10-year old basically, who spends two hours at dinner arguing with an AI for fun. But what I'm telling him is, "No, look, you need to still fully understand and learn how to write and understand code, because the coding bots are giving you code.
00:46:32 · Marc Andreessen, Lenny Rachitsky
If it doesn't work, or if it's not doing what you expect, or it's not fast enough or whatever, you need to be able to understand the results of what the AI is giving you." In the same way that somebody who's writing scripting language code does need to understand ultimately how the microprocessor works. And so again, it's kind of this up leveling of capability where you actually want the depth to be able to go down and be able to understand what the thing is actually doing, even if you're not spending your day actually doing that by hand. And again, I look at that and I'm like, "Okay. Now, programmers are going to be 10 times or 100 times or a thousand times more productive than they used to be." And that is, overwhelmingly, a good thing. The tasks are definitely changing. The nature of the job is changing. But are human beings going to be involved in the coding process and overseeing the AI coding and all of that? And the answer is, of course, absolutely 100%. No question. [00:47:22] S1: So you're in the camp of still learning to code is still a valuable skill?
00:47:24 · Marc Andreessen
[00:47:24] S0: Oh yeah, totally. Again, if you want to be one of these super... Look, if you just want to put yourself on autopilot, and like, "I can't be bothered. I'm just going to have AI write the code, and it's going to generate whatever it does and that's fine. And I'm going to be..." If the goal is to be a mediocre coder, then just let the AI do it. It's fine. The AI is going to be perfectly good in generating infinite amounts of mediocre code. No problem. It's all good. If the goal is, "I want to be one of the best software people in the world, and I want to build new software products and technologies that really matter," then yeah, you, 100%, want to still... You want to go all the way down. You want your skillset to go all the way down to the assembly, to assembly and machine code. You want to understand every layer of the stack. You want to deeply understand what's happening at the level of the chip, and the network, and so forth. By the way, you also really deeply want to understand how the AI itself works, because you want to... If people understand how the AI works, they're clearly able to get more value out of it than somebody who doesn't understand how it works. You're always more productive if you know how the machine works when you use the machine. And so the super-empowered individual on the other end of this that wants to do great things with the new technology, yes, you 100% want to understand this thing all the way down the stack because you want to be able to understand what it's giving you. And when something doesn't work or when something isn't right, you want to be able to really quickly understand why that is. By the way, again, this goes back to education. AI is your best friend at helping you learn all of that because it's like, "Oh, I need to understand. I don't know, this isn't fast enough." I need to figure out... As a coder, I need to figure out how to do a different approach to memory management or something. And you can be like, "Well, shit. I don't quite know how to do that. Okay, AI, let's spend 10 minutes. Teach me how to do this. Teach me what this all means." So all of a sudden, you have this incredibly synergistic relationship with the AI, where it's also helping you get better at the same time that's doing a lot of work for you.