The future of Coding and Code Quality
NNeetCodeIO@NeetCodeIO · 352K subscribers
- Views
- 28.4K
- 28,352
- Outlier
- ×3.1
- Median 9.2K
- Length
- 20:56
- Published
- Mar 13
- Friday
- Comments
- 83
- 667 likes
Script
How it's written
- Words
- 4,446
- Words a minute
- 212
- Reading time
- 19 min
- Segments
- 15
The hook
0:00–0:26Um I want to switch gears and talk about the future of coding. And I'm not going to ask you to look inside your crystal ball and, you know, precisely predict the future, but I still want to talk about I think the big thing that I think about is we saw actually Jared I think he made a tweet not too long ago about how engineering is really just about the
Structure
Um I want to switch gears and talk about the future of coding. And I'm not going to ask you to look inside your crystal ball and, you know, precisely predict the future, but I still want to talk about I think the big thing that I think about is we saw actually Jared I think he made a tweet not too long ago about how engineering is really just about the trade-off of like time versus like what you can get out of it. It's really just about that sort of trade-off. And I I think that's not exactly a new idea. I think I've heard it framed as like effort versus impact. Um and I think that really gets to the heart of like what a lot of the discourse and like fear about AI programming is at this point, which is that the trade-off is that you can move much more quickly now and some people might think that there isn't a cost to it. There isn't a cost associated with it. There isn't a debt that you're going to have to pay in the future. And I would say that most serious people will still say that there's some level of debt, but I think the disagreement comes in the sense of like how much is there. And I say that it's not a new discussion because like we've heard the move fast break things argument in the past. Uh even if you go to a lot of like big companies, like big tech companies, at least the ones I worked at, the code isn't exactly perfect. Like there's always going to be sloppy code. There is going to be technical debt. And so how
Watch from 0:00has that changed? Has has something actually dramatically changed recently and how much? And how how do you think about that? Yeah, so this is another thing where I'm like the same dynamics that existed pre-AI are like continuing to be true. So here's what I'll say about this whole trade-off conversation. Um this has always been the case. It's always always been the case. When someone builds something and it wasn't built great, uh oftentimes they use the excuse, well, we had to move quick so I made these intentional trade-offs. But then you ask them, okay, is that objectively true or was that subjectively true for like the moment in time that you were in? So if you were if you were to now go and rebuild the same thing from scratch, would you actually like make would you actually like make all those same trade-offs or was it just that you at your skill level at a certain time could only focus on so much so you made certain trade-offs? And it's almost always the that's the case. Like anytime I built something, no matter how successful it was, I look back at all the stuff that we did badly. Five I I took this recently. Like 5% of that was intentional trade-offs. The other 95% of that was inexperience. It was my first time doing something or we were like overwhelmed with other stuff. The next time I went and did that, I got almost all that stuff right up front.
Watch from 1:31There was actually no additional time cost, no additional anything. It was my own ability and like my own experience that was really limiting everything. Um so this is the case with with AI as that's AI as well. Like people say like, oh, it's okay if it's shitty it's an intentional trade-off to go fast. Not really. Someone better than you didn't have to make those trade-offs and they shipped just as fast. So I think there's like the the truth of this is like, yeah, it helps. It basically elevates everyone. Like wherever you're at, you can do more than what you're technically at. And and and and that's great. But we shouldn't we should have regrets. Like we should look back and reflect on what we did and say next time we can do this better. Or here's how we can do this better. Here's what we've learned. Um if you don't do that, then we're just doing the other thing, which is we're just being lazy and making excuses for it. Uh and I don't think that leads to anywhere anywhere great or or even good. Um I think a lot of the AI discourse, that's kind of what I've been seeing. It's been like, well, we shipped it and it worked so that means we have no regrets and we did everything right. Um not really. Like the situation you're now isn't great and it's okay. Doesn't mean you're a bad person. Doesn't mean you did anything wrong. But like be honest and kind of direct in about that. Right. So like you're basically saying it's a skill issue. That that's what you're saying. Yeah. Like yeah. I mean this has been the case forever where um the previous iteration of this was like using really high-level infrastructure, like something that's really easy to deploy, like one-click deploy type of thing.
Watch from 2:47And you do that your first time and your company's successful and you realize you have to move all that stuff to something more serious and that's in the middle of your company trying to like grow a bot, lot getting a bunch of customers. It's the most painful thing you'll ever deal with. The next company you start, you just start with a more complex thing up front cuz you just want to do with that again and you know how to do it now. So yeah, it's that that same dynamic over and over. Right. And I guess to play devil's advocate for a bit, um based on what we kind of talked about towards the beginning, which is that like in terms of product and like users, at least maybe in the short term, uh positioning can sometimes matter or rather maybe just moving fast can be more important than um than like the quality and you're willing to sacrifice quality. Um along that line, do you think it was for Claude Code, was it a mistake for them to move so quickly or maybe initially it was fine for them to move quickly, but at some point they should have done something differently. And I obviously, you know, you don't work at Claude or Anthropic, but based on what you know, how do you how do you feel about that? I think it's exactly what I said. I think everyone tries to move as fast as possible. We're all make trying to go really fast, making judgment calls on what corners to cut. And depending on your level of experience in the thing you're doing, that kind of looks different. So my understanding of Claude Code, it's exactly that. Like they had this idea and they kind of built this prototype which was which had such good product market fit that it was going to succeed regardless of how shitty the experience
Watch from 4:17was or how how bad it was built. And and that's good and that's a lot and that happens a lot. Um but it's not like a fundamental truth that like nobody could have shipped that same thing at the same speed. Um I'm pretty sure we built Open Code in a similar amount of time. We had the benefit of hindsight like looking at some of what they did and like, you know, we didn't have to like spend as much time figuring out what the shape of the product should be. So that's there. But we also built like a terminal framework from scratch in Zig and then built React and SolidJS bindings on top of that. And then like got all that working and like a compiled bun binary before Claude did any of that stuff, right? So these things just aren't objectively true that the trade-offs are equal for everyone. Uh we were playing in a space where we had more experience with. So we're able to move at similar speeds while delivering something higher quality. By the way, there's people out there that look at our stuff and they're like it's buggy or there's a lot of issues with it. And that's true. And there's someone out there that could have done a better job than us as well. Um so like yeah, I would try to look below us and above us as well and that kind of makes you realize like there's always people 10x worse than you, always people 10x better than you. Um and that's kind of I think that's my explanation of of Claude Code. In the next section, we talk about sacrificing code quality to move a bit faster. Does Dax ever commit code without fully reading all of it?
Watch from 5:48Well, the answer might surprise you and I think now is a good time to talk about our sponsor Greptile. I don't know about you guys, but reviewing code is definitely not my favorite thing and and so I had a really big change adding an entire discuss or forum type section to my site Neat Code and sometimes I do put like some unrelated changes in PRs. I do commit that cardinal sin, but that's where Greptile helps me a lot because we know that reading code, like any programmer knows reading code is completely different than reading a book or reading any sort of text. Usually you can understand some text pretty quickly, but reading code, there's so much context that you have to understand to even know like what a tiny piece of code is actually doing. That's one of my favorite things about Greptile because it's not just like reading your code and reviewing. Yeah, it's doing a lot of deep analysis. It's giving you a confidence score in its review. So there's certain like metrics and heuristics that you can go by, but for me, like I said, I want context. Like what what is the change actually doing? So if you look at the trace diagrams, this is honestly one of my favorite things because you get all of that context so much more easily. But don't just take it from me. There's a lot of companies using it. I'm sure you've heard of Open Claude. Even big companies like Nvidia are using it. Definitely give it a try. It was super super easy to set up. You can actually try it for
Watch from 7:04free, so there's really no reason not to. You can check it out at greptile.com/go/neatcode. Tell them Neat Code sent you. Right. Uh from the standpoint of like code quality, um how are you approaching when when code is generated by AI, which I'm sure, you know, you guys are using as much as you can, uh how do you ensure like that you are finding kind of the balance of like using the tools to speed you up, but also ensuring code quality when it comes to let's say like code reviews? Uh do you ever commit code without reading it? Mhm. Yeah, so the counterintuitive thing here is I think our code bases are now cleaner than they've ever been. Like we're producing like I think some of the best code bases we ever have. The reason for that is I think the downside of not having a clean code base is worse than ever. So before uh the typical life cycle of code bases, we'd start it off, we'd kind of make some initial decisions of how we're going to do things and then like 1 month in, 2 months in, we'll realize like, oh, there's actually a better pattern for doing I don't make something up. Something up. But we're going to do CSS in this way now. Um we just communicate that to the team and everyone kind of understands there's a new way of doing things and we'll just start building new stuff in that new way.
Watch from 8:35We're not going to go back and fix the old stuff right away. Like we'll get to it eventually, but, you know, like people know there's like a new way and there's old way and we kind of ignore the old way. And most codebases have this. There's like layers of different eras of how they how we did things. That's no longer a good thing to do cuz your LLM can't differentiate between the old way and the new way. It's going to look at the old way and be like, "Oh, that's how I do it." And it's going to generate all this crap. So, we are motivated more than ever to like really establish our patterns, be really like articulate them very intentionally, make sure there's not a single file in our codebase that doesn't follow that correctly. Um so, yeah, in a in a in a weird way we care about code quality more than ever cuz we have a bunch of idiots working for us now, like these LLMs that uh are will work very hard and like have like photographic memory, but are stupid in that we can't they can't understand this simple idea that, "Hey, there's like a better way to do stuff and this is how we do things now." Um so, yeah, we spend a lot of times adopting uh tools and frameworks that have like strong opinions and good patterns built in. Um we've always been big like domain-driven design people. We're doing that more than ever now. Uh And to answer your question in terms of do I look at all the code? Um mostly, right? Like I think there's areas in our codebase where the patterns are well established, they're very mature, and when I ask it to iterate, it's very I like I have an intuitive sense that the output is going to be exactly what I'm imagining in my head and I might not review it as thoroughly.
Watch from 9:52I'll do like a quick glance at does this roughly look right? Um other areas I have a sense of, okay, these areas are a little bit less stable. I got to be a lot more diligent making sure the LLM did the right thing. Um and I think most of our team operates in this way. Yeah. I think that's interesting because I know that there's at least going to be some people that are going to hear that and like almost have like an aneurysm and think that how could you possibly like not carefully review every single line of code, but when I think about that, at least I I I look back and even before these tools, and and even at like the biggest tech companies, the safest tech companies, not every single line of code was being read. Like code review Mhm. is probably the most boring day-to-day task, at least in my opinion, that you're well depending on the the context, but it's not the most interesting task. review. Everyone hates doing code review. It's true. Yeah, it's not exciting and like there's already been so much code that's been committed that wasn't carefully looked at. Like I know for a fact I would make pull requests uh at my previous job and I'd get the review like the approval within a couple minutes and I know that they just did a cursory check cuz at some point you kind of just establish trust in a developer and you're kind of saying that you can almost establish some level of trust with like an LLM that uh you know, you've used up to a certain point.
Watch from 11:20Yeah, I I I would say on the spectrum I'm still pretty conservative in that uh I do I say in what you're describing, like even when you're at a big company and no one looks at your PR really, there's still at least one human that knows it cuz you you wrote it. Right. it is a little weird to say like zero people know it know it, but so I think for me it tends to be more like uh there's like a risk feeling, right? Like the last time I did something that I felt was like less reviewed, it was a front-end feature. Uh it was like a front-end in our case, it's a terminal app. Um it was an implementation of like a new like dialogue and I thoroughly tested it from like a user perspective, like does it work well? Um we have so many primitives for building dialogues that I know it used. There's like probably a little bit that it got wrong and I think I do remember cleaning it up later, but I know that if it works pretty well and it's using a primitive that we built, um there isn't high risk. We do need to come back to this and clean it up later cuz it's technically wrong and I don't want this to start poisoning other LLM generations. So, All right. uh yeah, it's the same thing where you cut corners here and there and you like come back to it later. Yeah, I I think that's a really good point about that at least one human knew it beforehand. Um on that note, since reviewing code is largely boring and since that's kind of becoming the job in a certain sense if you're creating a lot of like agentic code, um a lot of people are saying nowadays that it kind of took the fun out of coding for them. That now they're just kind of
Watch from 12:40like at the prompt factory writing prompts and it's not really exciting as it used to be. And I have an opinion on this, but I'm curious to hear yours. Like has it taken the fun out of programming for you? Um this is a thing where like I think the answer is no, but I I actually think I'm in the minority of like the world of programmers because I'm working on my own company, my own product. I can kind of choose whatever I work on every day. If I feel like our company should be exploring something new, I get to do that. So, like these tools just help me do more for me that of the fun stuff, that right? That that like exploring new ideas and trying out new things and uh having an idea and being able to like try it out very quickly versus having to commit like a week to building it. Um that's all awesome and great, but I I don't think that most companies are structured in a way where you have much else that's enjoyable besides writing code. So, I think that might be a a big part of it where if you're sending a prompt and you're sitting there waiting for it, there's like you were kind of assigned a task. There's nothing else stimulating really for you to do. Um so, I can totally relate to why people are saying that. Uh and also like I think it's always been the case where a lot of the code that I have to write is like it is kind of dumb. Like it's not um it's like iterative. It's like building on top of something that exists. These are the things that agents can do. Um so, yeah, like it's not maybe not there's not that often that you actually get something that's challenging enough.
Watch from 14:12Like there's plenty of stuff that agents can't do. Like they can't really design good systems. They can't really do any of that stuff. They can't really figure out what needs to be done. I think that stuff was fun and stimulating, but I can see how that's maybe something you get to do like once a month or once every few months, not not every day. Yeah. Yeah, I think that's fair cuz like you said, it does depend on kind of where somebody's working, but my opinion has been I would say mostly consistent with yours, but I would say I I have a very different background and perspective in the sense that I like being able to, like you said, do a lot of like exploration now. Certain things you can just kind of move faster. You can get into a brand new programming language where you don't really have a lot of context uh provided it's one of the languages that the LLMs are good at that cuz they're not good at every language, but and you can just kind of move quickly. You can kind of just have like a higher level of abstraction. And I was never the type of developer I think that you are where I think you get probably really familiar with your tooling, your languages, your keyboard shortcuts, and like all that stuff. I'm kind of the opposite where I would take pretty much every shortcut that I possibly could. I would just be as lazy as I possibly could. I didn't even want to try open code because cloud code was working for a while and then I just got so tired of the the terminal seizures that it was having, so I just, you know, I had to had to give open code a try. But for the most part, like I have a lot of inertia, but uh I I still like programming. I still like the interesting ideas. For me it's
Watch from 15:40more about like I just don't feel like having to Google this syntax or remember how, you know, what exactly this decorator does. Just like little things like that. I'd like to solve a problem and just focus on the most important stuff. And maybe an analogy is like my brain context is just too small. I just can't focus on all the things, so I I'd like to focus on the interesting things. I think for in that sense it's made programming so much more enjoyable, but uh I think that over time uh someone like you uh someone like you who maybe isn't as disciplined and they over-rely on a lot of these tools. They might end up a little bit more like me where they lose some of their expertise and they kind of their skills diminish. And uh it's fine if the LLMs can still do all the things that you need them to do, but if you if you do lose certain skills and you get to a hard problem and then there's like a mismatch, that's going to be pretty important. Uh how is um how do you see that like over a longer time horizon? Because those are the things that are hard to predict. Like what's actually going to happen in 5 years uh with this? Yeah, I mean, I can speak for some of like the feelings I have personally. Um you know, it feels so much like I remember when I was like a when I was a kid in school, I'd be in math class and like they would write stuff on the board, like, you know, math problems or whatever. I'd really challenge myself to like do mental math and like solve stuff in my head. And there was a point where I was I was very good at it. Like I was like I'm like sharp. I'm like active. I can like really do all this stuff in my head. And at some point I became an
Watch from 17:11adult and I stopped doing that. And now I like can't even add like anything. I can't like if you I feel stupid when I have to add add numbers together or subtract them. Even just like in life, like calculating tip or any of those things, I feel dumber than I was as like a like a 13-year-old. Um and I feel some of that now with coding where uh I don't think it's hit me that hard yet, but I can see how if this continues down this path, there's just some stuff that I don't remember how to do anymore. And sometimes I'm forced to do it cuz the LLM is not doing the right thing or like it's I can't get the LLM to figure it out. I have to like go and intervene manually. And it it it it doesn't feel good. It feels like uh I feel like less capable than I used to feel. Um and there's an argument that like technically me not being able to do math as well has no real impact on my life. I can use a calculator. Uh it's for like pretty trivial situations where it happens. It's not that frequent. That might be the case this as well, so maybe it's fine that we atrophy this skill cuz it's just not as important as it used to be. Um but yeah, like I think the issue is to me it's the the genie's out the bottle type of thing. You give people something that lets them exert less energy, they're going to use it and they're going to want to use it forever.
Watch from 18:42Um so it's just like a fact of life. Like this thing exists, we're all going to use it. Anything that lets people, like I said, exert less energy wins and becomes successful, no matter what. Uh the question is like are people in environments where they're exerting less energy on this and therefore using the energy on something more useful or better or they're just like sitting back and like scrolling Tik Tok while Codex, you know, like does its thinking. Um and I felt the pull in both directions. Like there's times where I'm like super active, there's other times where I'm just like I'm just going to throw on YouTube and kind of like veg out while uh while the AI does something. Um That's like a weird feeling for me cuz I can see this repeated across millions of programmers every single day. And again, I'm in a very motivating environment. I'm like working on my own thing. If I'm at a big company that I don't really care about, it's just like my job that I'm doing to support my family, like why would I try harder than I have to, right? So I I do wonder if the how much net productivity lift this all this all actually has.
Watch from 19:57Full transcript
- 0:00
Um I want to switch gears and talk about the future of coding. And I'm not going to ask you to look inside your crystal ball and, you know, precisely predict the future, but I still want to talk about I think the big thing that I think about is we saw actually Jared I think he made a
- 0:20
tweet not too long ago about how engineering is really just about the trade-off of like time versus like what you can get out of it. It's really just about that sort of trade-off. And I I think that's not exactly a new idea. I think I've heard it framed as like effort versus impact. Um and I think that really gets to the
- 0:42
heart of like what a lot of the discourse and like fear about AI programming is at this point, which is that the trade-off is that you can move much more quickly now and some people might think that there isn't a cost to it. There isn't a cost associated with it. There isn't a debt that you're going to have to pay in the future. And I would say that most serious people will still say that
- 1:04
there's some level of debt, but I think the disagreement comes in the sense of like how much is there. And I say that it's not a new discussion because like we've heard the move fast break things argument in the past. Uh even if you go to a lot of like big companies, like big tech companies, at least the ones I worked at, the code isn't exactly perfect. Like there's
- 1:25
always going to be sloppy code. There is going to be technical debt. And so how has that changed? Has has something actually dramatically changed recently and how much? And how how do you think about that? Yeah, so this is another thing where I'm like the same dynamics that existed pre-AI are like continuing to be true. So here's what I'll say about this whole
- 1:46
trade-off conversation. Um this has always been the case. It's always always been the case. When someone builds something and it wasn't built great, uh oftentimes they use the excuse, well, we had to move quick so I made these intentional trade-offs. But then you ask them, okay, is that objectively true or was that
- 2:07
subjectively true for like the moment in time that you were in? So if you were if you were to now go and rebuild the same thing from scratch, would you actually like make would you actually like make all those same trade-offs or was it just that you at your skill level at a certain time could only focus on so much so you made certain trade-offs? And it's almost always the that's the case. Like
- 2:28
anytime I built something, no matter how successful it was, I look back at all the stuff that we did badly. Five I I took this recently. Like 5% of that was intentional trade-offs. The other 95% of that was inexperience. It was my first time doing something or we were like overwhelmed with other stuff. The next time I went and did that, I got almost all that stuff right up front. There was actually no additional time
- 2:49
cost, no additional anything. It was my own ability and like my own experience that was really limiting everything. Um so this is the case with with AI as that's AI as well. Like people say like, oh, it's okay if it's shitty it's an intentional trade-off to go fast. Not really. Someone better than you didn't have to make those trade-offs and they shipped just as fast. So I think there's like the the truth of this is like,
- 3:10
yeah, it helps. It basically elevates everyone. Like wherever you're at, you can do more than what you're technically at. And and and and that's great. But we shouldn't we should have regrets. Like we should look back and reflect on what we did and say next time we can do this better. Or here's how we can do this better. Here's what we've learned. Um if you don't do that, then we're just doing the other
- 3:31
thing, which is we're just being lazy and making excuses for it. Uh and I don't think that leads to anywhere anywhere great or or even good. Um I think a lot of the AI discourse, that's kind of what I've been seeing. It's been like, well, we shipped it and it worked so that means we have no regrets and we did everything right. Um not really. Like the situation you're now isn't great and it's okay. Doesn't mean you're a bad person. Doesn't mean you did anything wrong. But
- 3:53
like be honest and kind of direct in about that. Right. So like you're basically saying it's a skill issue. That that's what you're saying. Yeah. Like yeah. I mean this has been the case forever where um the previous iteration of this was like using really high-level infrastructure,
- 4:13
like something that's really easy to deploy, like one-click deploy type of thing. And you do that your first time and your company's successful and you realize you have to move all that stuff to something more serious and that's in the middle of your company trying to like grow a bot, lot getting a bunch of customers. It's the most painful thing you'll ever deal with. The next company you start, you just start with a more
- 4:34
complex thing up front cuz you just want to do with that again and you know how to do it now. So yeah, it's that that same dynamic over and over. Right. And I guess to play devil's advocate for a bit, um based on what we kind of talked about towards the beginning, which is that like in terms of product and like users, at least maybe in the short term, uh
- 4:55
positioning can sometimes matter or rather maybe just moving fast can be more important than um than like the quality and you're willing to sacrifice quality. Um along that line, do you think it was for Claude Code, was it a mistake for them to move so quickly or maybe initially it was fine for them to move quickly, but at some point they
- 5:15
should have done something differently. And I obviously, you know, you don't work at Claude or Anthropic, but based on what you know, how do you how do you feel about that? I think it's exactly what I said. I think everyone tries to move as fast as possible. We're all make trying to go really fast, making judgment calls on what corners to cut. And depending on your level of experience in the thing you're doing, that kind of looks different. So my
- 5:36
understanding of Claude Code, it's exactly that. Like they had this idea and they kind of built this prototype which was which had such good product market fit that it was going to succeed regardless of how shitty the experience was or how how bad it was built. And and that's good and that's a lot and that happens a lot. Um but it's not like a fundamental truth
- 5:56
that like nobody could have shipped that same thing at the same speed. Um I'm pretty sure we built Open Code in a similar amount of time. We had the benefit of hindsight like looking at some of what they did and like, you know, we didn't have to like spend as much time figuring out what the shape of the product should be. So that's there. But we also built like a terminal framework from scratch in Zig and then built React and SolidJS bindings on top
- 6:17
of that. And then like got all that working and like a compiled bun binary before Claude did any of that stuff, right? So these things just aren't objectively true that the trade-offs are equal for everyone. Uh we were playing in a space where we had more experience with. So we're able to move at similar speeds while delivering something higher quality. By the way, there's people out there that look at our stuff and they're like it's buggy or there's a lot of
- 6:39
issues with it. And that's true. And there's someone out there that could have done a better job than us as well. Um so like yeah, I would try to look below us and above us as well and that kind of makes you realize like there's always people 10x worse than you, always people 10x better than you. Um and that's kind of I think that's my explanation of of Claude Code. In the next section, we talk about sacrificing code quality to
- 7:00
move a bit faster. Does Dax ever commit code without fully reading all of it? Well, the answer might surprise you and I think now is a good time to talk about our sponsor Greptile. I don't know about you guys, but reviewing code is definitely not my favorite thing and and so I had a really big change adding an
- 7:20
entire discuss or forum type section to my site Neat Code and sometimes I do put like some unrelated changes in PRs. I do commit that cardinal sin, but that's where Greptile helps me a lot because we know that reading code, like any programmer knows reading code is completely different than reading a book
- 7:41
or reading any sort of text. Usually you can understand some text pretty quickly, but reading code, there's so much context that you have to understand to even know like what a tiny piece of code is actually doing. That's one of my favorite things about Greptile because it's not just like reading your code and reviewing. Yeah, it's doing a lot of
- 8:01
deep analysis. It's giving you a confidence score in its review. So there's certain like metrics and heuristics that you can go by, but for me, like I said, I want context. Like what what is the change actually doing? So if you look at the trace diagrams, this is honestly one of my favorite things because you get all of that context so much more easily. But don't
- 8:22
just take it from me. There's a lot of companies using it. I'm sure you've heard of Open Claude. Even big companies like Nvidia are using it. Definitely give it a try. It was super super easy to set up. You can actually try it for free, so there's really no reason not to. You can check it out at greptile.com/go/neatcode. Tell them Neat Code sent you. Right. Uh
- 8:44
from the standpoint of like code quality, um how are you approaching when when code is generated by AI, which I'm sure, you know, you guys are using as much as you can, uh how do you ensure like that you are finding kind of the balance of like using the tools to speed you up, but also ensuring code quality
- 9:06
when it comes to let's say like code reviews? Uh do you ever commit code without reading it? Mhm. Yeah, so the counterintuitive thing here is I think our code bases are now cleaner than they've ever been. Like we're producing like I think some of the best code bases we ever have. The reason for that is I think the downside of not
- 9:26
having a clean code base is worse than ever. So before uh the typical life cycle of code bases, we'd start it off, we'd kind of make some initial decisions of how we're going to do things and then like 1 month in, 2 months in, we'll realize like, oh, there's actually a better pattern for doing I don't make something up. Something up. But we're going to do CSS in this way now. Um we just communicate that to the team and
- 9:48
everyone kind of understands there's a new way of doing things and we'll just start building new stuff in that new way. We're not going to go back and fix the old stuff right away. Like we'll get to it eventually, but, you know, like people know there's like a new way and there's old way and we kind of ignore the old way. And most codebases have this. There's like layers of different eras of how they how we did things. That's no longer a good thing to do cuz your LLM can't differentiate between the
- 10:09
old way and the new way. It's going to look at the old way and be like, "Oh, that's how I do it." And it's going to generate all this crap. So, we are motivated more than ever to like really establish our patterns, be really like articulate them very intentionally, make sure there's not a single file in our codebase that doesn't follow that correctly. Um so, yeah, in a in a in a weird way we care about code quality
- 10:30
more than ever cuz we have a bunch of idiots working for us now, like these LLMs that uh are will work very hard and like have like photographic memory, but are stupid in that we can't they can't understand this simple idea that, "Hey, there's like a better way to do stuff and this is how we do things now." Um so, yeah, we spend a lot of times adopting uh tools and frameworks that
- 10:52
have like strong opinions and good patterns built in. Um we've always been big like domain-driven design people. We're doing that more than ever now. Uh And to answer your question in terms of do I look at all the code? Um mostly, right? Like I think there's areas in our codebase where the patterns are well established, they're very mature, and when I ask it to iterate, it's very I like I have an
- 11:14
intuitive sense that the output is going to be exactly what I'm imagining in my head and I might not review it as thoroughly. I'll do like a quick glance at does this roughly look right? Um other areas I have a sense of, okay, these areas are a little bit less stable. I got to be a lot more diligent making sure the LLM did the right thing. Um and I think most of our team operates in this way. Yeah. I think that's interesting because
- 11:36
I know that there's at least going to be some people that are going to hear that and like almost have like an aneurysm and think that how could you possibly like not carefully review every single line of code, but when I think about that, at least I I I look back and even before these tools, and and even at like the biggest tech
- 11:56
companies, the safest tech companies, not every single line of code was being read. Like code review Mhm. is probably the most boring day-to-day task, at least in my opinion, that you're well depending on the the context, but it's not the most interesting task. review. Everyone hates doing code review. It's true. Yeah, it's not exciting and like there's already been so much code that's been committed that
- 12:17
wasn't carefully looked at. Like I know for a fact I would make pull requests uh at my previous job and I'd get the review like the approval within a couple minutes and I know that they just did a cursory check cuz at some point you kind of just establish trust in a developer and you're kind of saying that you can almost establish some level of trust with like an LLM that uh you know,
- 12:37
you've used up to a certain point. Yeah, I I I would say on the spectrum I'm still pretty conservative in that uh I do I say in what you're describing, like even when you're at a big company and no one looks at your PR really, there's still at least one human that knows it cuz you you wrote it. Right. it is a little weird to say like zero
- 12:57
people know it know it, but so I think for me it tends to be more like uh there's like a risk feeling, right? Like the last time I did something that I felt was like less reviewed, it was a front-end feature. Uh it was like a front-end in our case, it's a terminal app. Um it was an implementation of like a new like dialogue and I thoroughly tested it from like a
- 13:20
user perspective, like does it work well? Um we have so many primitives for building dialogues that I know it used. There's like probably a little bit that it got wrong and I think I do remember cleaning it up later, but I know that if it works pretty well and it's using a primitive that we built, um there isn't high risk. We do need to come back to this and clean it up later cuz it's technically wrong and I don't want this
- 13:41
to start poisoning other LLM generations. So, All right. uh yeah, it's the same thing where you cut corners here and there and you like come back to it later. Yeah, I I think that's a really good point about that at least one human knew it beforehand. Um on that note, since reviewing code is largely boring and since that's kind of becoming the job in a certain sense if you're
- 14:02
creating a lot of like agentic code, um a lot of people are saying nowadays that it kind of took the fun out of coding for them. That now they're just kind of like at the prompt factory writing prompts and it's not really exciting as it used to be. And I have an opinion on this, but I'm curious to hear yours. Like has it taken the fun out of programming for you?
- 14:23
Um this is a thing where like I think the answer is no, but I I actually think I'm in the minority of like the world of programmers because I'm working on my own company, my own product. I can kind of choose whatever I work on every day. If I feel like our company should be exploring something new, I get to do that. So, like these tools just help me
- 14:46
do more for me that of the fun stuff, that right? That that like exploring new ideas and trying out new things and uh having an idea and being able to like try it out very quickly versus having to commit like a week to building it. Um that's all awesome and great, but I I don't think that most companies are structured in a way where you have much else that's enjoyable besides writing
- 15:07
code. So, I think that might be a a big part of it where if you're sending a prompt and you're sitting there waiting for it, there's like you were kind of assigned a task. There's nothing else stimulating really for you to do. Um so, I can totally relate to why people are saying that. Uh and also like I think it's always been the case where a lot of the code that I have to write is like it is kind of dumb. Like it's not um
- 15:28
it's like iterative. It's like building on top of something that exists. These are the things that agents can do. Um so, yeah, like it's not maybe not there's not that often that you actually get something that's challenging enough. Like there's plenty of stuff that agents can't do. Like they can't really design good systems. They can't really do any of that stuff. They can't really figure out what needs to be done. I think that stuff was fun and stimulating, but I can see how
- 15:49
that's maybe something you get to do like once a month or once every few months, not not every day. Yeah. Yeah, I think that's fair cuz like you said, it does depend on kind of where somebody's working, but my opinion has been I would say mostly consistent with yours, but I would say I I have a very different background and perspective in the sense that I like being able to,
- 16:12
like you said, do a lot of like exploration now. Certain things you can just kind of move faster. You can get into a brand new programming language where you don't really have a lot of context uh provided it's one of the languages that the LLMs are good at that cuz they're not good at every language, but and you can just kind of move quickly. You can kind of just have like a higher level of abstraction. And I was never
- 16:34
the type of developer I think that you are where I think you get probably really familiar with your tooling, your languages, your keyboard shortcuts, and like all that stuff. I'm kind of the opposite where I would take pretty much every shortcut that I possibly could. I would just be as lazy as I possibly could. I didn't even want to try open code because cloud code was working for a while and then I
- 16:56
just got so tired of the the terminal seizures that it was having, so I just, you know, I had to had to give open code a try. But for the most part, like I have a lot of inertia, but uh I I still like programming. I still like the interesting ideas. For me it's more about like I just don't feel like having to Google this syntax or remember
- 17:16
how, you know, what exactly this decorator does. Just like little things like that. I'd like to solve a problem and just focus on the most important stuff. And maybe an analogy is like my brain context is just too small. I just can't focus on all the things, so I I'd like to focus on the interesting things. I think for in that sense it's made programming so much more enjoyable, but uh I think that
- 17:37
over time uh someone like you uh someone like you who maybe isn't as disciplined and they over-rely on a lot of these tools. They might end up a little bit more like me where they lose some of their expertise and they kind of their skills diminish. And uh it's fine if the LLMs can still do all the things
- 17:58
that you need them to do, but if you if you do lose certain skills and you get to a hard problem and then there's like a mismatch, that's going to be pretty important. Uh how is um how do you see that like over a longer time horizon? Because those are the things that are hard to predict. Like what's actually going to happen in 5 years uh with this? Yeah, I mean, I can speak for some of
- 18:19
like the feelings I have personally. Um you know, it feels so much like I remember when I was like a when I was a kid in school, I'd be in math class and like they would write stuff on the board, like, you know, math problems or whatever. I'd really challenge myself to like do mental math and like solve stuff in my head. And there was a point where I was I was very good at it. Like I was like I'm like sharp. I'm like active. I can like really do all this stuff in my
- 18:40
head. And at some point I became an adult and I stopped doing that. And now I like can't even add like anything. I can't like if you I feel stupid when I have to add add numbers together or subtract them. Even just like in life, like calculating tip or any of those things, I feel dumber than I was as like a like a 13-year-old. Um and I feel some of that now with coding
- 19:01
where uh I don't think it's hit me that hard yet, but I can see how if this continues down this path, there's just some stuff that I don't remember how to do anymore. And sometimes I'm forced to do it cuz the LLM is not doing the right thing or like it's I can't get the LLM to figure it out. I have to like go and intervene manually. And it it it it doesn't feel good. It feels like uh
- 19:22
I feel like less capable than I used to feel. Um and there's an argument that like technically me not being able to do math as well has no real impact on my life. I can use a calculator. Uh it's for like pretty trivial situations where it happens. It's not that frequent. That might be the case this as well, so maybe it's fine that we atrophy this skill cuz it's just not as important as it used to be.
- 19:44
Um but yeah, like I think the issue is to me it's the the genie's out the bottle type of thing. You give people something that lets them exert less energy, they're going to use it and they're going to want to use it forever. Um so it's just like a fact of life. Like this thing exists, we're all going to use it. Anything that lets people, like I said, exert less energy wins and
- 20:05
becomes successful, no matter what. Uh the question is like are people in environments where they're exerting less energy on this and therefore using the energy on something more useful or better or they're just like sitting back and like scrolling Tik Tok while Codex, you know, like does its thinking. Um and I felt the pull in both directions. Like there's times where I'm
- 20:26
like super active, there's other times where I'm just like I'm just going to throw on YouTube and kind of like veg out while uh while the AI does something. Um That's like a weird feeling for me cuz I can see this repeated across millions of programmers every single day. And again, I'm in a very motivating environment. I'm like working on my own thing. If I'm at a big company that I don't really care about, it's just like my job that
- 20:46
I'm doing to support my family, like why would I try harder than I have to, right? So I I do wonder if the how much net productivity lift this all this all actually has.
Description
SponsorThank you Greptile for sponsoring. Try them out for free here https://www.greptile.com/go/neetcode
The Full Episode:
Spotify - https://open.spotify.com/episode/4pqI...
Apple - https://podcasts.apple.com/us/podcast...
🚀 https://neetcode.io/ - A better way to prepare for technical interviews
🧑💼 LinkedIn: / navdeep-singh-3aaa14161
🐦 Twitter: / neetcode1
For sponsorship & business inquiries mail@neetcode.io
#coding #leetcode #python
