Vibe Coding Is The Future

Andrej Karpathy recently coined the term “vibe coding” to describe how LLMs are getting so good that devs can simply “give in to the vibes, embrace exponentials, and forget that the code even exists.” In this episode of the Lightcone, the hosts discuss this new method of programming and what it means for builders in the AI age. Apply to Y Combinator: https://ycombinator.com/apply

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Jared Friedman?

  It's like somebody dropped some like giant beanstalk seeds at night. We woke up in the morning. There is like, whoa.

• 0:06Garry Tan?

  What's going on? I mean, I think our sense right now is this isn't a fad. This isn't going away. This is actually the dominant way to code. And if you're not doing it, like you might just be left behind.

• 0:27Garry Tan?

  Welcome back to another episode of the Light Cone. I'm Gary. This is Jared, Harge and Diana, and we're partners at Y Combinator. Collectively, we funded companies worth hundreds of billions of dollars, right when it was just an idea and a few people. So today, we're talking about vibe coding, which is from a Andre Karpathy post that went viral recently. There's a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

• 0:59Harj Taggar?

  Yeah. So we surveyed the founders in the current YC batch to get their take on vibe coding. And we essentially asked them a bunch of questions. We asked them, what tools are you using? What work? How has your workflows changed? And so generally, where do you think the future of software engineering is going? And how the role of software engineer changed as we get into a world of vibe coding? And we got like some pretty interesting responses. Anyone have any favorite quotes that jumped out from the founders?

• 1:27Diana Hu?

  I think one of them that I can read verbatim is, I think the role of software engineer will transition to product engineer. Human taste is now more important than ever as code and tools make everyone a 10x engineer. That's from the founder of Outlet.

• 1:43Jared Friedman?

  I got one. Abi from Astra said, I don't write code much. I just think and review.

• 1:50Jared Friedman?

  This is like a super technical founder who's like last company was also a dev tools company. He's like extremely able to code. And so it's fascinating to have people like that saying things like this.

• 2:00Harj Taggar?

  There's another quote from a different RB, RB from Copycat, who said he's, I am far less attached to my code now. So my decisions on whether we decide to scrap or refactor code are less biased. Since I can code three times as fast, it's easy for me to scrap and rewrite if I need to.

• 2:15Garry Tan?

  And then I guess the really cool thing about this stuff is it actually paralyzes really well. So Yoav from K60, he says, "I write everything with cursors. Sometimes I even have two windows of cursor open in parallel and I prompt them on two different features."

• 2:31Garry Tan?

  Which makes sense. Why not three? You know, you could do a lot, actually.

• 2:35Diana Hu?

  And I think another one that's great is from the founder of Train Loop. He mentions how coding has changed six to one month ago. 10x speedup one month ago to now is 100x speedup, exponential acceleration.

• 2:49Jared Friedman?

  And he says, "I'm no longer an engineer, I'm a product person."

• 2:52Garry Tan?

  Yeah, that's super interesting. I think like, that might be something that's happening broadly. You know, it really ends up being two different roles. You need, I mean, it actually maps to how engineers sort of self-assign today, in that either you're, you know, front end or back end. And then back end ends up being about actually infrastructure. And then front end is so much more actually being a PM. You're sort of, almost being like an ethnographer going into the obscure, underserved parts of the pie of GDP. And you're trying to extract out, like, this is what those people in that GDP pie actually want. And then I'm gonna, you know, turn that into code. And then actually evals are the most important part of that.

• 3:36Harj Taggar?

  When I was running Triplebyte, this was actually one of the things we noticed. It was almost as important as a technical assessment of engineers, when trying to figure out who's a good match for a specific company, is there's a certain threshold of technical ability you need. But beyond that, it was, do you actually want to talk to users or not? Like, some engineers are actually just very, a lot more motivated by working on things where they know who the users are and they get to like, communicate with them and they get live feedback and they can iterate, essentially being a product engineer. And other engineers really don't want to do that at all. Like, they find it annoying having to deal with users and they want to just like, work on like, hard technical problems and refactor code.

• 4:12Garry Tan?

  That's a back-end engineer.

• 4:13Harj Taggar?

  Yeah, that's what we call a back-end engineer. Yeah, sure. And that's only a theme that came up in the survey responses, right? This idea of, sort of, the LLMs are maybe going to push people to choose, because the actual writing of the code may become less important. It's about, are you really, do you have taste and you want to solve product problems? Or? Are you an architect and you want to solve systems problems?

• 4:34Garry Tan?

  Oh, and interestingly, I guess one thing the survey did indicate is that this stuff is terrible at debugging.

• 4:40Harj Taggar?

  Yeah.

• 4:41Garry Tan?

  And so you still, the humans have to do the debugging still. They have to figure out, well, what is the code actually doing? Here's a bug. Where's, you know, spot the bug. Where's the code path that, you know, we have someone's, you know, logic error, you know, just didn't figure this out. Right. There doesn't seem to be a way to just tell it debug. You were saying that you have to be very explicit, like as if giving instructions to a first time software engineer.

• 5:07Jared Friedman?

  Yeah, I have to really spoon feed it the instructions to get it to debug stuff. Or you can kind of embrace the vibes. I'd say Andre Karpathy style is just like ignore the bug and just like reroll. Just like, just like tell it to try again from scratch. Like it's, it's wild how your coding style changes when actually writing the code becomes a thousand X cheaper. Like as a human, you would never just like blow away something that you'd worked on for a long time and rewrite it from scratch because you had a bug. You'd, you'd like, you'd always fix the bug, but like for the LLM, if you can just like rewrite a thousand lines of code in like six seconds, like

• 5:42Garry Tan?

  Doesn't cost anything.

• 5:43Jared Friedman?

  Why not?

• 5:44Garry Tan?

  That's kind of like writing, you know, taking the approach of, uh, you know, how people use mid journey or playground when you're trying to generate images. Like if there are artifacts or things that I don't like, sometimes I don't even change the prompt. I just click reroll and I do that five times. And you know, sometimes it just works. I'm just like, oh, I can use that now.

• 6:04Diana Hu?

  Which is a very different frame of building systems because you're not building foundationally step by step. You're really doing it from scratch because fundamentally what's going on is like all these tools today are coming from the world of a generated code. They're in this latent space hidden somewhere and you have to do it from scratch to find like a different gradient and not get stuck. And then you want to like add a bit of randomness, get it to regenerate. But I do think maybe, I don't know, whatever next generation of O5, maybe we'll get to the point that actually is able to build upon. I mean, as of right now, I think most of it is you need To reroll and rewrite, but it doesn't build upon it yet. But we haven't seen any of the coding tools right now work well with reasoning. I think we have.

• 6:48Jared Friedman?

  Well, oh, three is infinitely better debugging than 3.5 sonnet. So like, it definitely feels like we're headed in the direction where this may not be true in, you know, six months, the next time we do this episode. Diana, do you want to talk about like the models that people are using, the IDEs that the people are using? There's some really interesting trends there.

• 7:04Diana Hu?

  Yeah, I think as we mentioned a couple of episodes ago, we already saw this in the shift started happening. The vibes started to shift back in summer 24, when Cursor was being used by a big portion of the batch. And now by far is the leader. But the other thing that's happening, this is a very fast and moving environment. Windserve is a fast follower. It's starting to be a very good product as opposed to Cursor. And I think Jared, you have some first experience with why Windserve is like better than Cursor.

• 7:35Jared Friedman?

  Yeah, I think the number one reason that people are switching is that Cursor today largely needs to be told what files to look at in your codebase. So if you have a large codebase, you can tell what to do, but you have to tell it like where to look in the codebase. Windserve indexes your whole codebase and it's pretty good at figuring out what files to look at on the zone. There's, there's other differences too, but I think, I think that's the most important one at the moment.

• 7:56Diana Hu?

  Notable, Devon does get mentioned, but the drawback of Devon not really being used for serious features is that it doesn't really understand the codebase. It's being used mostly for small features and barely, it's like barely mentioned. The other one, people still use ChatGPT. And the reason they use it is because they want to actually use the reasoning models. So it does get posted. People post some of the debugging questions to, to figure out the, use the more powerful models for reasoning. Because right now Cursor with serve are still in the old world, I mean, old world less than six months ago, pre reasoning models, not in the test time compute. So founders are using that. And there's some founders, some of them are self-hosted as well,

• 8:39Diana Hu?

  self-hosting models, because maybe they have more critical sensitive IP. They do that. And now, talking about the shifts in terms of models. The thing about Kojan, the big game in town that we saw six months ago was Claude Sonic 3.5 is still actually a big contender. Most are still using it, but O1, O1 Pro and O3, meaning all these reasoning models are starting to see a, it's almost like getting neck to neck now close with a Sonic 3.5. The other one is Foro, virtually no use for Kojan. And the other interesting thing is DeepSeek R1 is getting mentioned. It's been used, it's like a viable contender as well.

• 9:24Diana Hu?

  And Gemini, not really mentioned.

• 9:26Jared Friedman?

  The one thing I've heard from Gemini is because it has like the longest context window, I've heard from a couple of founders that they do use it. And the way that they use it is they put their entire code base into the Gemini context window and they just like tell it to like fix a bug. And it doesn't always work, but like sometimes it can just like one-shot fix stuff because it's the whole thing in the context window.

• 9:47Diana Hu?

  It will be interesting to see as people get more adoption on the newly released reasoning models with flashback 2.0. I don't think people have tried it yet. But the long context window plus reasoning could be a good contender. What is the estimated code that's being written by LLMs in the current badger?

• 10:05Jared Friedman?

  This is pretty crazy. So we explicitly asked this question. What percent of your code base do you estimate is AI-generated? The way I interpreted the question is like, like of the actual characters in your code base, not including any libraries that you imported, like a percentage of like the characters were like typed by human hands versus like emitted by an LLM. And the crazy thing is one quarter of the founders said that more than 95% of their code base was AI-generated.

• 10:31Diana Hu?

  Wow.

• 10:31Jared Friedman?

  Which is like an insane statistic. And it's not like we funded a bunch of non-technical founders, like every one of these people is like highly tactical, completely capable of building their own product from scratch. A year ago, they would have built their own product from scratch, but now 95% of it is built by an AI.

• 10:48Garry Tan?

  Except for, you know, maybe it sounds like we have one or two examples of people

• 10:52Jared Friedman?

  Yeah.

• 10:52Garry Tan?

  Who they're so young that they learned to code in the last two years. So they actually don't know a world where Cursor didn't exist.

• 11:02Jared Friedman?

  Yeah, this is one of my best companies, Dispatch, actually is exactly this. The founders are extremely technical minds, but they're not classically trained in computer science and programming. And they are incredibly productive and able to produce just a ton of like really amazing product and AI is writing almost the entire thing.

• 11:24Diana Hu?

  It kind of makes me think a lot of the discourse around sort of Gen Z's are the first digital native that grew up with the internet. This is like the generation that grew up with native AI coding tools that they skip the classical training of a software engineer and they just do it with the vibe. But they are actually very technical minded. I mean, they have degrees in math and physics. So they have that raw, let's call it more like system thinking type of mind that you still need. Maybe we should talk a bit about that. It's like what's still the same and what has changed?

• 12:00Jared Friedman?

  I think this vibe coding will enable people who have those kinds of technical minds, who come from other technical disciplines like math and physics, to become highly productive as programmers much faster than it was in the past. Like I remember there were like coding bootcamps, like back in the day, they would try to like retrain physics people into programmers. And then like it didn't work that well because it just takes too long to learn all of the syntax and all of the libraries and all the stuff that you have to know to be really productive. But like now, now it's a new world.

• 12:28Harj Taggar?

  The coding bootcamps are also very specifically focused on getting you hired at companies. And I think there was, it was during this around like 2015 era where just companies themselves were rethinking how to evaluate software engineers and their hiring processes. And it was moving, there was a real shift away from like, we want to hire classically trained computer scientists, whiteboard algorithmic problems towards, we actually want people who are just really productive and write code quickly. And some of these are. Arguments are like evergreen eternal, right? Like, I remember when Rails first came out, there was just like a real sense of, oh, like, I don't know, like, active record as a way to like interact with your database was seen as a great abstraction, but like, there was still the same flavor of argument, right?

• 13:11Harj Taggar?

  Like, I don't know, like, if you don't really understand the internals, like, you're just gonna write like crappy, low-performing web software.

• 13:18Jared Friedman?

  How do you feel those arguments have aged if you look back on it now?

• 13:23Harj Taggar?

  My feeling is that many of the most successful companies, I would say Stripe, Gusto are just two that really spring to my mind as ones that really heavily leaned into the, actually, we just want people who are really productive with the tools, and we're gonna change our whole hiring process to just select for people who are good at, like, the interview shifted from, teach us how you think, to you've got three hours on a laptop and you need to build a to-do list app and build it as quickly as you can. And those companies have had tremendous amount of success. It does, it does seem like at some point as they grew and they scaled, then the bottleneck did actually become having people who are classically trained in systems thinkers to sort of scale up and architect things.

• 14:04Garry Tan?

  It does seem like how people are hiring engineers is changing, but maybe not changing fast enough yet. The results of the survey are relatively surprising to the four of us here. Probably pretty shocking out there. Even, it's just like this thing that popped up in our backyard only in the last six to nine months. My guess would be engineering hiring, period, has not actually caught up to this. People are still standing at whiteboards and doing that kind of thing, as opposed to what can you get done? And so it sounds like the stripes of the world, they were ahead of the game and everyone has to hire engineers this way now.

• 14:41Harj Taggar?

  I mean, I wonder if actually even that's gonna be sort of the old meta. But I mean, something that stood out from the survey responses was this idea of two themes we talked about, right? Like, one is, okay, we're all just product people now. Like, actually, the thing that you need is really great taste and understand what to build. And the second was the idea of, actually, now what's really valuable is to be like a systems thinker and an architect and to really sort of understand the bigger picture, in which case. Actually, like, maybe being a really productive coder, because that's definitely something that always fit my definition of when you're talking about who are great engineers you know. And like, one of the dimensions are they're just really, like, they can write code really fast.

• 15:22Jared Friedman?

  Yes.

• 15:22Harj Taggar?

  Like, maybe that's outdated, like, maybe that's not, if the LLMs are actually really good at writing code quickly.

• 15:29Jared Friedman?

  Right.

• 15:29Harj Taggar?

  And to your point, like, now it's actually just cheaper to, like, reroll and just, like, write everything from scratch than try and debug. Like, the skills might just be completely different.

• 15:38Garry Tan?

  Problem is, there's like two different stages. There's zero to one, which, in which case, speed is the only thing that matters. And then, to your point about active record and rails, that battle was actually fought to a standstill. Because of course, using active record or rails allowed you to go from zero to one very quickly. But then, what happened at Twitter, it became the fail whale, right? Like, basically, once you get to one, like, one, you know, that architecture

• 16:02Jared Friedman?

  Yeah.

• 16:03Garry Tan?

  will not get you to a billion, or 10 billion, or 100 billion dollars in valuation, or users, or whatever. Like, it's just not going to actually work. So I think you're gonna see a, the same thing. And then, there's nuance in what you just said, right? Like, getting zero to one quickly and then being able to scale to a billion users are two totally different sets. And then, I think that that might be irreplaceable for now around people. And one of the things I discovered as we were scaling one of the biggest rail sites, I mean, you scaled one of the biggest rail sites too, is that there aren't that many people who have to do it. Getting to one is so rare.

• 16:41Jared Friedman?

  Yeah, that's true.

• 16:42Garry Tan?

  That, did you reach this point where how you got to zero to one very quickly was like, you used lots and lots of open source? And then, at some point, like, maybe two years into this, maybe a year and a half into the startup even, we could not use random gems anymore.

• 16:55Jared Friedman?

  Gems anymore, because they were just never designed for companies that had our scale.

• 16:58Garry Tan?

  Like, you deploy it and it fall over. It would just fall over, right?

• 17:02Diana Hu?

  This very good example is what you're saying, Gary. I think, maybe to summarize a bit more, zero to one will be great for vibe coding where founders can ship features very quickly. But once they hit product market fit, they're still going to have a lot of really hardcore systems engineering. You need to get from the one to N and you need to hire very different kinds of people. And to that, I think there's very good historical example, like Facebook as well. I mean, they got.

• 17:28Jared Friedman?

  PHP.

• 17:29Diana Hu?

  Yeah, they got away with PHP, which personally is a terrible language.

• 17:31Jared Friedman?

  Yeah.

• 17:32Diana Hu?

  Maybe I got flamed, but I think it's a bad language.

• 17:34Jared Friedman?

  I'm with you. I did never liked it. Sorry, guys.

• 17:38Diana Hu?

  It was very bad, but you could ship things very quickly. But at some point, it became such a big bottleneck for them to ship features that they had to hire the hardcore system people to build a custom compiler.

• 17:49Jared Friedman?

  Yeah, yeah.

• 17:51Diana Hu?

  That it would run fast on bare metal because it's just too expensive to replace all the code.

• 17:55Jared Friedman?

  Yeah.

• 17:55Diana Hu?

  And that kind of people that did that are not the vibe code people are sort of this hardcore systems people that, based on our survey, current tools are not good at that low level systems engineering.

• 18:07Jared Friedman?

  Hard. I'm not sure everybody who's listening knows what Triplebyte is, but it's actually very relevant. Do you want to just describe for everybody what?

• 18:15Harj Taggar?

  Yeah, Triplebyte is a company I started in 2015 and our we were essentially building a technical assessment for engineers. Like our goal was how can you use software to automate evaluating software engineers? And the way we did it was pre all these code gen models, which is we built all of our own custom software to interview engineers, have humans interview engineers, and then essentially just like label the data like in.

• 18:38Jared Friedman?

  And interview them by like asking them to write code. They, they, they're highly tactical.

• 18:43Harj Taggar?

  Yeah, it was a high tech. Yes, like it was asking to write code. We did actually include algorithmic problems.

• 18:48Jared Friedman?

  And is it true that you and your co-founders have done more tactical interviews than any other people on the planet?

• 18:53Harj Taggar?

  I think so, like in terms of just like pure hours. Because that was just like the early days of it were like all day, every day, just like.

• 18:59Jared Friedman?

  Like thousands, thousands and thousands of them, right?

• 19:03Harj Taggar?

  And then we scaled up and we had like a team of about like a hundred engineers contracted just that we would pay per interview completed.

• 19:10Jared Friedman?

  And so you're exactly the right person to ask this question. You've literally spent more time thinking about this than anyone else on the planet.

• 19:17Jared Friedman?

  If you were starting Triplebyte again today and you had to design like new tactical assessments for engineers, what would you have them do?

• 19:26Harj Taggar?

  The big takeaway I had with Triplebyte and the screen that in particular is just people want different things. And so you kind of need to know upfront like what exactly it is that you're evaluating for and then design your technical screen. Around that is kind of what I'm getting at with where Stripe and Gusto and these companies just knew that they didn't care if someone had fundamental CS knowledge. So it didn't make sense to screen them on that. They wanted to screen for the thing they they're actually going to do in their job. And then our product was more trying to screen for everything company, trying to get a taste of everything companies might want and then figure out what someone's max skill was. And then send the people with the max skill to the companies that would value

• 20:10Harj Taggar?

  that max skill. And in today's world, I think I would actually have a screen that at least accounted for just how well people knew how to use these tools. Like, and I'm sorry, again, it's maybe contradictory what I'm saying earlier, but it might be the case of maybe how product, how quickly you can code and you can build product is actually something to explicitly screen on and just set the bar much higher.

• 20:34Jared Friedman?

  You probably have to ask different questions because I'll bet if you go back to the original triple byte assessment, I bet a lot of those questions, you could literally just copy and paste the question into chat GPT and it would spit out a perfect answer. In which case you're not really proving that much competence if you're just copying, like the questions probably have to be like a hundred times harder.

• 20:51Harj Taggar?

  I mean, this gets to the deepest stuff, right? Not necessarily, because if you have someone else, it depends on like what conditions you're going to put on the screen, which I think is interesting. So I don't know, classic question was like build tic-tac-toe. Yes, of course. If you do that unsupervised and you just let someone like come back with their tic-tac-toe solution, that's going to take like two seconds, right? If you want to watch them code it and force them to not use an LLM.

• 21:16Jared Friedman?

  Well, I guess that's a question. Do you force them to code it without an LLM with like the old questions? Or do you let them use an LLM and now you need new questions because the other, the old ones became trivial?

• 21:28Harj Taggar?

  That I think is what everyone hiring software engineers right now should be thinking about and trying to figure out. Yeah, I'm not sure I know what the correct answer is to that.

• 21:36Jared Friedman?

  Interesting.

• 21:37Diana Hu?

  I think that's going to be probably you're going to test for different things because I also did a lot of engineering hiring. I think one key skill that's going to, I think, remain that's constant. I do think skills of reading code and debugging are maxim. It's like, you have to have the taste and enough training to know that the LLM is spitting bad stuff or good stuff. So like, bad code or good. And I think you can see it clearly sometimes if a candidate is using the tools and. There's actually a reasonable solution at the LLM outputs. And then they can't decide, oh, this is actually bad. That is a sign. So I think knowing kind of more the high level thinking to know what is good versus bad. In order to do good vibe coding, you still need to have the taste and you still need

• 22:21Diana Hu?

  that kind of classical train, maybe not necessarily classical train, but enough knowledge to judge what's good versus bad. And you only become good with enough practice. I think that will be one that will be constant. That would be my opinion.

• 22:34Harj Taggar?

  Yeah, that's interesting. Just code it sort of like more like code review as the interview versus like actually like producing code.

• 22:40Diana Hu?

  Yeah, I mean, you could have a some form of system design. You want to know how good they can put a product out there. So then it's testing for taste. So we're going to test for debugging and then taste. But then how do you get to? I guess this is a question going to these kits that you have that we call it AI coding natives.

• 23:00Harj Taggar?

  Yeah.

• 23:01Diana Hu?

  How do you develop taste? When you don't come from a classically trained world? Which would be interesting for next generation founders.

• 23:10Garry Tan?

  Well, you have to, because if you don't, the startup dies, right? So let's say this founder, they go off, they have 95% written by AI. The proof is in a year out, two years out, they, you know, have 100 million users on that thing. You know, does it fall over or not? And then one of the things that's pretty clear is these systems, you know, in the first realm, the first versions of reasoning models, they're not that good at debugging. So you actually would need to descend down into the depths of what's actually happening.

• 23:42Harj Taggar?

  Yeah.

• 23:43Garry Tan?

  And if you can't, then you got, I mean, let's hope that they can go find another architect.

• 23:48Harj Taggar?

  Yeah.

• 23:48Garry Tan?

  They're going to have to hire someone who can.

• 23:50Diana Hu?

  I think there's going to be a generation of software engineers that are like good enough, because it's so easy to retool there with, with all these Cogen tools, like the barrier is so low. You're going to be good enough engineers, there's going to be tons of those. But to be exceptional, like the top 1%, I think you're going to need to get into deliberate practice. I mean, the analogy we're talking about is Mark, Mark Glattwell popularized this concept of 10,000 hours of practice to become an expert, which came from this research from, what was his name?

• 24:22Jared Friedman?

  Anders Ericsson.

• 24:23Diana Hu?

  Anderson Ericsson, right? Which it wasn't just, the research was very specific. It was about how do you find world-class violinists? And it wasn't about just putting the time, but deliberate practice. It's like hours that are actually planned and thought, and it's hard work. You could become an extra business hours. So I think what's happening with now co-gen tools is that it's very cheap to put in the hours because the output is just so quickly. You can get to good enough. But to become the best in the world and the best founder, you're going to need that deliberate practice to go into the details. And you're going to have to peel the onion and understand the systems and get to, again, to some extent, being classically trained. I mean, a good example is, maybe we go back to history, is like Picasso, one of the greatest painters.

• 25:07Diana Hu?

  He was amazing at drawing lifelike pictures.

• 25:10Jared Friedman?

  Which is not what he's famous for, of course. When you imagine a Picasso, you imagine the opposite of that.

• 25:14Diana Hu?

  Yeah. There's this famous sequence of drawings on how he got to an abstract ball. It starts from being lifelike to iterations until he gets to the essence, to kind of the abstract art that he's very well-known for. But he could only get to be the best in the world because he was actually a very good painter and classically trained and could draw super well. But that's not what he's known for. So I do think we'll see these two classes of engineers. You'll still have like a very fat class of like good enough. You need engineers for those. But the best in the world, the founders that become outliers, are going to need to put in the deliberate practice.

• 25:53Garry Tan?

  Yes and no. I mean, I think there are lots of really amazing examples of great systems-level and world-class engineers who ended up being CEO and CEO of the biggest public companies in the world. I think of Max Levchin. I think of Toby Lutke from Shopify. I mean, these are people who just like actually that great. And the thing is, there are lots of other people who are not that great, but also still CEO or co-founders of companies. And then it kind of goes back to link up what we were saying earlier. It goes back to hiring.

• 26:26Harj Taggar?

  I mean, I keep thinking about the Twitter analogy that you brought up. So I think it's a really interesting one. Like if you compare Facebook and Twitter, in both cases, they went very quickly from zero to one in sort of a scrappy move, fast break things way. Facebook was able to solve the scaling technical challenges in a pretty impressive way. I think most people would would agree.

• 26:47Garry Tan?

  I mean, Mark Zuckerberg was by far way more technical and way more in the weeds, probably.

• 26:52Harj Taggar?

  Maybe, but I don't know, like.

• 26:54Jared Friedman?

  I think Twitter scalability challenges were also harder based on the usage patterns. Like, the thing about the usage of Facebook is that it grows. It's like, it's pretty smooth throughout the day. Like, people just use it all the time. The problem with Twitter is that the usage is incredibly spiky. You get like a Super Bowl or like a, you know, like, like a world event. And all of a sudden, you have like 10 times as much usage. The way the fan out of the feed works is, I think, like fundamentally a very difficult computer science problem.

• 27:17Harj Taggar?

  Okay, that's fair.

• 27:18Garry Tan?

  Though I also think that they were like really hamstrung by their tools. Do you remember using this terrible queue system called Starling?

• 27:26Jared Friedman?

  Absolutely.

• 27:27Garry Tan?

  I used it because I thought, oh, Twitter's so much bigger than us. They're so smart. They wouldn't use something that's crap. No, they totally use crap. And then I use crap and I couldn't make it work. It was like, it was dropping jobs on the floor. Like, it's just like, all these crazy bugs happened. And then I was like, finally, I was like, I'm not using that anymore. I have to switch to Rabbit MQ or whatever the heck the the actually correct thing to use was.

• 27:49Jared Friedman?

  Yeah, and like Ruby is an incredibly slow language, even like 10x slower than PHP, which was already too slow.

• 27:55Garry Tan?

  So I don't know. I mean, basically, you should be so lucky to get to one.

• 27:59Harj Taggar?

  Yeah. Is there an advantage for a technical founder to be classically trained and be a really deep systems thinker?

• 28:05Garry Tan?

  Well, I mean, you just, I mean, a Toby or a Max Levchin is not going to get bullshitted by people.

• 28:11Harj Taggar?

  Patrick from Stripe is the same.

• 28:13Garry Tan?

  I mean, I'll tell you a crazy story. When I was at Palantir, you know, I sort of burnt out there after a couple of years after I designed the logo. And then I actually, between that and going to start my YC startup, I spent six months as an interaction designer. And I was, it was this like terrible venture backed company that ended up going in the ground and it was like credit card software. It was the worst. I spent six months building, like, basically just interaction designs, which was really fun. That's what allowed me to work on my startup in my spare time because I had a lot of spare time. But I remember designing, you know, this faceted search thing for like rental cars or something like that.

• 28:56Garry Tan?

  And then I go into my meeting with my dev manager and engineers who were going to implement it. And they were like, oh, yeah, it can't be done. We can't do it that way. Oh, like, and I was like, what are you talking about? Just make the indexes like this. And they were like, whoa. What do you mean? Like, and then they looked at my resume.

• 29:13Jared Friedman?

  Didn't expect to hear that go, that from the interaction designer.

• 29:15Garry Tan?

  Yeah, basically, they're like, how did you know that? And I was like, you fucking lied to me. And that's the thing, like, what founders and like, you know, when, when you're hiring people, like, that, that was like, the wildest thing to me. But it was like, sort of, the ultimate lesson, where it's like, when you're in the workplace, you sort of assume that the people you bring on, like, they're not gonna lie, they're not lazy, like, we're all for the goal and the mission, right? And I was like, no, like, people who hire you, hire, like, they totally will lie to you if you cannot tell that they're lying. And then the worst part is like, you kind of have to call them on it. Like, you know, sometimes you have workplace cultures that are so polite, that people are like, oh, like, I'm gonna let that pass, and then I'm gonna talk shit about them behind their back. And it's like, no, you should fire them.

• 29:59Jared Friedman?

  The AI agents, incidentally, will do exactly the same thing. They will absolutely, like, the AI agents will bullshit you, just like a human employee will, if you don't, if like, if you're not tactical enough to like, call them out on their bullshit and be like, like, no, like, you didn't make the change that I.

• 30:15Jared Friedman?

  It goes back to your, to your point about like, why being classically trained is still hubble. Like, you, you have to be able to call out all the people working for you, whether they're human or not. Being tactical enough to be able to do that is, is a superpower.

• 30:27Diana Hu?

  So just to wrap up, basically, what's going on with all these tools giving superpowers to the best engineers and making the bad engineers also worse, is, this is a quote from the founder of Train Loop, "How coding has changed six to one month ago, 10x speed up. Now, one month ago, 100x speed up. Now it's exponential acceleration."

• 30:48Garry Tan?

  Sort of crept up on us, actually.

• 30:49Jared Friedman?

  Yeah, it was like, somebody dropped some like, giant beanstalk seeds. At night, we woke up in the morning.

• 30:55Garry Tan?

  What's going on? So, I mean, I think our sense right now is, this isn't a fad, this isn't going away, this is actually the dominant way to code. And if you're not doing it, like, you might just be left behind. This is just here to stay. And, you know, vibe coding is not a fad, it's time to accelerate. And so with that, we'll see you guys for the next Light Cone.