Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#243 - The 70% Problem: When AI Coding Falls Short
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
What happens when software engineers rely too heavily on AI-assisted coding tools? Brian and Zubin (an ex-Google engineer) dive deep into what they call "The 70% Problem" – the phenomenon where AI coding tools excel at initial scaffolding but falter when tackling the crucial final 30% of engineering work.
Drawing from Addy Osmani's insightful article, these experienced developers share their firsthand experiences with tools like Cursor, ChatGPT, and GitHub Copilot. They explore how AI-assisted coding creates a dangerous illusion of competence while potentially masking fundamental knowledge gaps. As Zubin aptly puts it, giving powerful AI coding tools to inexperienced developers is like "giving a Formula One car to someone who's only driven on city streets."
Visit parsity.io to learn how Brian and Zubin are training the next generation of engineers to excel in this new paradigm.
Shameless Plugs
🧠 (NEW) Parsity's The Inner Circle Program - a highly customized roadmap to take you from 0 to hired. For career changers who want to pivot into software.
💼 Zubin's LinkedIn (ex-lawyer, former Google, Brian-look-a-like)
👂🏻Easier Said Than Done Podcast
Already a developer? Check out 👉 Not Another Course
Serious about joining Parsity? Schedule a call with me ☎️
Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network and more. I'm Brian, your host Today on the Develop Yourself podcast. I got my buddy Zubin the other half maybe the better looking half of Parsity, I don't know. Today we're going to talk about an article from a software engineer that we're both familiar with. He actually, I think, works at Google or maybe used to work at Google. Software engineer that we're both familiar with. He actually, I think, works at Google or maybe used to work at Google.
Speaker 1:Addy Osmani, prolific writer, just has amazing takes and information that he writes about software and front-end web development specifically. And he has this article the 70% Problem Hard Truths About AI-Assisted Coding. It really just breaks down these warped expectations. Using AI-assisted coding nowadays and we're all learning this in real time. This is like a really tremendous shift in the way we write software. And on one end of the spectrum we have people like you don't need to write code at all and you can just use AI-assisted coding, and if you're not doing it right, oh, you just need better prompts. And on the other spectrum, we have people say don't ever use it at all and you should just rely on manual coding. And I just want to talk to Zubin. You're a senior software engineer, you've been doing this for a while, so you used to work at Google and I really want to break down my experience your experience with these AI-assisted coding tools, and like what is the reality of using these things nowadays.
Speaker 2:I mean, I will say that the AI is the worst it's ever going to be. Right, it's only going to get better, so it's 100% useful. But look I think I said this in a previous podcast of mine If you give a Formula One car or a superbike to someone who's only ever driven on the streets of some city, there's going to be problems. Right, can they operate it? Yes, yes, can they operate it safely? Almost certainly not, and that's the big difference, right, like there's a reason why even forklifts need training. You know, you need to be trained and licensed to you know. I mean, this stuff is is powerful stuff, and it's not powerful because it could cause you physical harm. It's powerful because it can fool you into thinking you've done something better than you actually have. Yes, or worse.
Speaker 2:And now we come into a problem like so adi actually wrote another uh article, so I think the one about 70 percent, um, you know, problem solving is is from late last year, from memory, uh. And then a couple months ago he wrote another one about, basically titled you know, vibe coding is not an excuse for you know, rubbish work, or you know, is not an excuse for bad quality work. And the point is this, which is, most people who are vibe coding don't know enough to quality control it. It comes down to that.
Speaker 2:Yesterday one of the guys from Taro, he mentioned that the problem that we're now seeing is that when code review time happens, there's so much rubbish code that needs to be cleaned up, so much crud right that needs to be cleaned up. That's the problem it's never been a question about, because software engineering is not about writing code, brian. You know that that's what it looks like. It's not about the writing of the code, right? Just like writing a book is not about writing words down in a piece of paper. It's the craftsmanship, that's the, that's the job, and we're losing that we're losing.
Speaker 1:that's, that's the really scary part to me. And we've lowered the barrier to entry, which is a double-edged sword, because now anybody with an idea can, you know, spin up an app. Is it going to work or be scalable? No, absolutely not. But they can spin up something that looks really, really good and it gives this illusion that we're being super productive. And I'm feeling this in real time because I'm in a company with some younger CEOs who are not technical and they're thinking, oh my God, we've unlocked, like, the secret to productivity with AI. And I actually shared this article with them and my whole team. Because what he addresses is this 70% myth Like, yeah, you can get 70%, some arbitrary measure pretty far ahead, you can scaffold things, you can build it at speed. Honestly, the CEOs made a better looking prototype than I could have using V0 for sales, v0. And but that 30% is where the tool becomes not only less efficient but like almost feels like it's actively working against you, right? Hey, I hope you're enjoying this episode Now.
Speaker 1:You know that I own an anti bootcamp with my buddy Zubin, an ex Google software engineer, if you're interested in not just learning how to code, and you know it's going to take more than three months and you're serious about making a transition into a career in software and you want to work with people that have done it before and are currently working in senior plus levels, join me and zoom in at parsityio slash, inner dash circle. You can learn all about our philosophy, how we approach learning how to code and switching careers in a much different way, and how we have so much gosh dang success. If you're interested in being one of the few people that works with us this year, go and apply at parsityio slash, inner dash circle. And now back to the episode. I've used Cursor. Enough now. Mike, I think you were using Cursor before me. Are you having the same experience where you're like, oh man, I'm flying and then at some point you're like it's just faster for me to write the code, yeah constantly and in fact it's faster If I do the math.
Speaker 2:it is probably better for me as an engineer to have done the research and taken the time to know how to build it from scratch than for me to have relied on it, because when it comes debugging time, I burn all the time I saved. Anyway, I lose it right.
Speaker 1:And just try to fix it.
Speaker 2:And here's the other thing that I think this is my theory right because of the way ai llns need to be trained on data. It's naturally going to be better at anything that is already visible in the browser, which is pretty much all front-end code, right? If it's visible in the browser, that means it's on a website. It's literally part of the text of the website, right, which means it's easily trained, because public data, yeah, challenges all the stuff that happens over the wire and in the backend. It's routinely and I work more on the backend it routinely completely screws it up and sends me down these horrible rabbit holes.
Speaker 1:Rabbit holes yeah.
Speaker 2:And I swear at it Like, I'm like.
Speaker 1:I get pissed. Sometimes I get super pissed.
Speaker 2:Yeah, because it's setting these expectations, not delivering and then costing me time because I plan my day on the basis that it's going to boost my productivity. But I will say, productivity-wise, I don't think. I think it does help and there's a big difference. There's a difference between productivity and there's a difference between quality, right, productivity-wise, no doubt it saves me on research time because I know what I'm looking for, and then it does kind of cost me time when it screws things up and it's really messy and all the rest of that. That's true, but that could have happened even on my own, like that's the reality of it.
Speaker 2:But productivity being you know the fact that I can. So to your point and to Addy's point, if 70% of it can be done and this is the key point for people who think you know it's some sort of fantasy or magic bullet it'll save you a ton of keystrokes, but it won't save you the work that you would have always had to do anyway, which is the engineering work. So there's a difference between writing code and engineering right. The engineering work is the hard stuff. That's the last 30% that you know Addy seems to be talking about. That stuff is not going to save you right now, unless it's completely a toy app, something that's done 100 times. Can I do a shopping cart application from a front end and stylize it 1000%? Can I do a YouTube clone? 1000%.
Speaker 2:How many companies are doing that? Very few companies need to do that.
Speaker 1:That's not the real world, you know and maybe you can help me articulate this, because I, you know, we, we work with tons of people that want to get into software or that have gone to boot camps and they're looking at this and they're like I'm doing a youtube clone, which I'm like, yeah, that's a necessary step to help you build software, like you have to take stepping. But then they're looking at something like but cursor just does it. So what's the point of me doing it If that tool just knocks it out already? And I'm like you don't know what you don't know yet. It's almost like you have to get to a point and you're going to help me articulate this because you're more eloquent that that you understand, you know these, these building blocks, these patterns, so that you can then use something like Cursor. But if you use it too early in the game, now, you're going to miss over these vital steps, these important learnings and debugging and bashing your head against a wall and getting stuck and having to go through documentation.
Speaker 1:You're going to lose all that and then you're going to be not really one, maybe not even hireable Two. If you get hired, I don't think you have a career Totally.
Speaker 2:I mean, we've all experienced this in school. There are practice problems and there are simulations of real life and then there's real life, and we always know there's a big gap between the simulation and real life. Doctors practice in cadavers, musicians learn Beethoven and some know artists or whatever and practice their stuff, and first you learn by copy right. Then you got to close the gap with real life. Like anybody who thinks that, hey, just because I can play beethoven sonata on the piano means that I can go and compose. Music is missing a very big step, which is the trial and error piece. Right, and that's all a YouTube clone is. It is instruction by using an illustrative example of some of the key widgets, right, doesn't mean that when you're having to build that out in your own unless it's exactly the same thing doesn't mean that you encounter the same problems. And the problems with any simulated environment is. It is fundamentally excluding all the wrong parts that you would go down. It just gives you the curated happy path. That's what a simulation will end up doing. But that's not what real life is and that's why real life is so hard to teach. It doesn't matter what it is driving school, whatever it is, there are some skills where, practically, you need to be out there in the field, even if you're a shooter or a golfer. You're out in the range, you're practicing stuff, but then there's no one that's going to tell you that just because you fire a firearm, all in a shooting range, means you can handle a live situation where you know if you're in the armed forces, of the police or something. It's completely different, right, and that's what engineers need to understand.
Speaker 2:Now, interestingly, I'd ask the question for all the people who are excited about vibe coding. It's very rarely actual engineers. The people most excited about vibe coding, if you notice, entrepreneurs, correct, because they save money and they save time and they also have the benefit of thinking here. I can get 80% of their on the prototype. So it's entrepreneurs. It's people who want to be engineers but who feel excluded by the engineering community because they have no cut, understandably bitter about that or, you know, rancid about it, and so they say, hey, vibe coding, I don't need this. Right, they're the ones who most vocal. Actual engineers are very cautious about vibe coding. They're optimistic but cautious as opposed to the others, which is just like this is gonna. This is gonna change everything. It's, it's, it is gonna change everything, but not the way we think oh man, I saw it was on reddit again.
Speaker 1:I gotta stay off reddit and there's a meme on there and it's from. It's one of those vibe coding like uh chat threads, whatever, and it's like one. It's like somebody that obviously was kind of uh dismissed or felt dismissed by the coding community and was, like, you know, asking a question like what happens when you ask a question on stack overflow and people berate you and make you feel stupid and they're like ha ha ha, this is why you need coders and stuff. And now they're like showing that, hey, now I can do that same thing with vibe coding and I don't need you anymore. And I do get that.
Speaker 1:You know, we have kind of created a bit of a snooty culture in some ways within software engineering. Stack Overflow definitely was not what I would consider like a welcoming place for people and a lot of times software engineers can be dismissive and you know, I think the soft skills have obviously become much more important for us to have. But yeah, you're right and I'll take this kind of hot take. I do agree that most entrepreneurs should probably vibe code their way to a prototype if possible and then finally hire some software engineers. I'm not kind of the school of thought like no, you should never touch that code. I've seen how far V0 can get. I tried to have my son, by the way, do something in V0. I said, hey, son, I'm going to show you this. You got to see this. I said what do you want to make A game? I'm like cool, try it in V0. Just breaks. Doesn't work at all, nothing works. And I was so disappointed.
Speaker 2:I was getting excited. I was thinking, maybe Me too. I wanted to sell them on coding no, it didn't just not work.
Speaker 1:We did three different prompts and I'm using the paid version of this. I use the paid version of Cursor. I've used the paid version of ChatGPT. I'm willing to pay for these services in general, and I was shocked that. You know, here I am trying to do what I consider something fairly simple, and it didn't render anything. It just broke immediately a very simple game.
Speaker 1:And then I did actually a video. There's a video that I put out on YouTube a couple of days ago. It's doing pretty well, which is unusual, and it's about me live trying to vibe code my way through a fairly simple feature in a prototype I'm building. It's just a prototype, nothing major, it's less than a hundred files and it doesn't do it. And people are watching it and some people are saying, oh, you know, you should have made a better prompt. The typical kind of defensive answer you should have done a better prompt or you know, no, you got to have this tool on top of it. And that leads me to this other thing we're getting AI SaaS bloat. One person told me, you know, because they're having the same problems with cursor that we're all having and when you say you mean software as a service.
Speaker 1:Here, software is exactly so I you know I have a cursive subscription and I love cursor. I'm not here to diss it or anything. But somebody says oh well, you know that 30 problem where there's another tool now that solves that. I'm like, I don't want a hundred ai tools to write code, because then I'm not doing what I like doing yeah, no.
Speaker 2:And here's the question for you. Right like, how, if all these people who are saying, hey, look how it built this and it's amazing, and all the rest of that, is it possible that they just happen to get a result? Because it's a non-deterministic outcome? Right like, even with the identical prompt, there's no guarantee that the ai is going to come up with the same response. Um, because it's response, because that's what makes AI generated responses so hard to test it's non-deterministic. You know which engineers like us struggle with when we have to test it. That's right. Is it possible that a dead clock is showing the right time twice a day and people are getting excited?
Speaker 1:Yeah, that's a good question. Actually, this is so new it's really hard to know. But what do you think is the future? As far as and maybe when I mean the future sound like the old guy, but I feel like we're bringing up a generation of people that maybe have lost the craft of software engineering and either won't be able to get in the industry and have these strange expectations, or their expectations aren't aligned with reality. And then we're going to either lose a generation of people because we're senior software engineers we're not going to be writing code forever. Who's going to replace us and what do they need to know? Do you think?
Speaker 2:Oh man, so interesting you asked this question. So just on the weekend I finished recording a podcast which will come out middle of this week. It was actually about how recently Microsoft laid off about 6% of its workforce like 6,000 people, 3%.
Speaker 2:And it was all about oh, software engineers, and if you do the math 53% were software engineers, which means 47% weren't software engineers, and so I'm analyzing what Microsoft said in their report late last year I think it was May, no, not late last year, mid-last year, may 2024, about changes at the workplace how I think. I can't remember now, but it's in the podcast about 68% of people are burnt out, 70-something percent of managers are going to hire for AI skills, and I call that that this thing about AI skills is a catch-all phrase. That means nothing.
Speaker 1:It means nothing it means nothing.
Speaker 2:So what it means to a musician is very different to what it means to a software engineer. It's very different to what it means to an AI software engineer. Very different to what it means to an AI software engineer, very different to what it means to a machine learning engineer, very different for what it means to a sales rep. Right, like AI, skills means very different things for different people. So people get excited about all this and they think it's some sort of major, you know, yeah. So I guess, to answer your question, brian, about what the future is, it really comes down to your goals, right? There is no question that AI is going to be part of the tooling.
Speaker 2:I remember a time when I started my career in law, you know, almost a quarter of a century ago, where there were still pools of stenographers and typists in every law firm because the then senior lawyers and partners weren't fast enough right On the typing. They did the one finger typing because they didn't grow up typing, whereas our generation, on the typing, they did the one-finger typing because they didn't grow up typing, whereas our generation grew up typing. And so now most law firms have much smaller, if any, pools of these folks, because people are doing their own typing right Now. That's what's going to happen in terms of the engineer is going to end up having to work with AI to get things done faster. But the judgment layer and this is my terminology for it right, there's a judgment layer involved in any work, whether it's software engineering or being an accountant, there is a judgment layer, and I think people delegate the judgment layer to the AI at their own risk, right? Whether you're looking for a personal psychologist, a chat GPD psychologist, whether you're looking for a chat GPD lawyer, whether you're looking for a chat GPD coder psychologist, whether you're looking for a chat GPD lawyer, whether you're looking for a chat GPD coder, you delegate that at your peril because it is not in a position to judge. Right, if something doesn't know the time of day and day of week it is, it's not in a position to judge. That's just my rule for it. Okay, and it's ridiculous to think that we can delegate.
Speaker 2:So I think what's going to happen is and I think it's already happening actually, and not just in software engineering we're seeing a generation of junior practitioners in any profession where AI is making an impact and there are lots of them lose the ability to make judgment, right To interpret data, make judgment, do the research form an informed point of view. We're entering a habitual copy and paste, without knowing what the hell I'm copying and pasting, sort of environment. Which means in five years or seven years, when they stop being on the tools because, let's face it, over a 30-year career, most software engineers or not most, a lot of them will not continue to be on the tools. Right, they will get into higher level areas of impact. And I'm talking much less today than I did three years ago. Much less right. That's the nature of the job as you rise up. So coding is clearly not the most important thing. Okay, in which case, as you rise up the ranks yeah, it's judgment, it's pattern detection.
Speaker 2:It's that experience that comes from having made mistakes, trial and error. You know, we learn. I talked about this on LinkedIn. We learn the same way. The AI does trial and error. The only difference is the AI does billions of reps in an hour, whereas we take a lifetime to do that. That's the difference, but it's the same trial and error loop, right. So that's what's going to happen we're going to have an entire cadre of generation of young practitioners without the experience to move into judgment into management.
Speaker 1:That's something I didn't even think about, but that's a really important one, because I'm thinking about what you do, what I do, even as a senior engineer now at a small company. I was writing up docs recently about the organization structure or about the Git branching structure and kind of my thoughts. I'm like well, here's how I think we should organize ourselves as a team, here's how I think work should be divided. And we have an internship at Parsity and all the students in it. We ask what the takeaway is. It's never like oh my God, I learned so much new coding standards or anything. It's like oh my God, I've never really had to use Jira or Asana Communication. How to tell somebody hey, I'm struggling with a bug. I can't quite figure this out. When do I use AI? How do I use it? Oh man, is this Git branch? Is this okay for me to push up? Who's going to review it? Oh, this review had way more comments than I expected. It's always about all these things outside of like the writing of the code.
Speaker 2:It's always. I'm having this discussion at the moment where, you know, we're trying to design a basic prototype to see whether it's worth moving into further. And what do it's to do with ai?
Speaker 2:it's to do with, you know, the model, context, protocol and stuff, stuff that you and I've talked about yeah, yeah, it's very cool yeah, and I'm like there's an entire bunch of folks who want to build an API server that will respond to it, which is what most engineers would want to do. And my question is like but why? Because that means there's a whole surface area of rate limiting, authentication, authorization. Then you have to maintain the server-side code. I said if we could co-locate the database with the actual tool, which is a package, and if the database is actually with it, we don't need an API and it's all public data anyway.
Speaker 2:Now that and that's a question that stops people on the tracks because they're like actually why did we go down the Like, do we really need the API? And it prompts the right discussion Do we need an API? Right? Do we need a hosted API for this? And that's the kind of thing that, unfortunately, that takes judgment, you know, and it takes the experience of having gone through building an API server, making it publicly accessible and then defending the darn thing from the attacks of the internet. It's only when you've done that that you're like oh my God.
Speaker 1:I don't want to repeat that pain again. How do I avoid?
Speaker 2:having to expose my flank to that kind of you know surface area of constant maintenance, attack and vulnerability. That only comes from experience, right?
Speaker 1:yeah, that's the thing, because when you hire a senior developer, it's rare, uh, that you're strictly hiring for coding skills alone. In fact, I I just haven't had that experience as a manager or as myself on the market where I've been hired like, oh my god, you passed the you know coding exam and now you're hired. Here's all the money, here's that big bag of money you wanted. It's more about like, okay, we see you fitting in on the team. Oh, you could also lead the team. Oh, you know about product a little bit. We can see you fitting in in all these different areas here.
Speaker 1:Yeah, that is the piece that I think people are absolutely missing from this in general, and those are much more interesting problems to solve, like the one that you had to solve.
Speaker 1:That's a really interesting one. But you're hiring for experience a lot of times and if you just offload all that experience you try to take this shortcut, you're going to end up in a rough position. In fact, there was a tweet I don't know if it's real or not, but the guy said we hired a junior engineer and they worked out really great for a few weeks. They got progressively worse throughout the time because, as the feature they wrote had more bugs, more things to add on top of it. It was very clear that they were working completely using ai and they were a victim of this 70 you know rule that adios money talks about in the article where, like, they got really far but then when they had to go back and refactor it or add more code or work a larger code base, they just couldn't keep up and and it was like obvious that you know, they reached the limits, the rate limits of their AI tools, and they got fired. Yeah.
Speaker 2:So Adi Osmani, I just pulled it up the other article where he talks about vibe coding is not an excuse for low quality work. He's got the screenshot of this tweet by you know, I am developer, so not even developer developer, right, I am developer. And the tweet says five coding where two engineers can now create the tech debt of at least 50 engineers. It's so true, like spot on right. That is so freaking true. That is so funny what's happening. And you know, for folks who are listening to us, like it's all right at a junior level, if you're doing mainly front-end code, like I said, I think, because the internet, the way websites work, all the code is public, it'll learn, it'll be good quality stuff, but, as Brian said, it'll get things wrong. Even v0, which is this vaunted savant AI that does all the front-end stuff, gets things wrong. I've never used AI for anything in my entire careers of and I use it every day where it gets things right, it just doesn't. And I think at the back end and the more obscure sort of work you're doing, the less density of information out there on the internet, it's just not going to get it right, especially with training, windows and stuff like that. Now, of course, there are ways you can fix it. You can, you know, know, add stuff to the context window. You can do, uh, all kinds you know, you can add more context by you know, inside your person, your, your vs code or whatever it is, but it still doesn't have the volume of training data that you can reliably say. This is what's going to happen now.
Speaker 2:Just as an example, um, when I was at google, there were things that I had to do that you couldn't Google for, like that was the irony right, because it is completely internal. It was so niche. Yeah, it was hard, and you have to figure things out from first principle and, of course, it's going to take weeks. It's going to take weeks. There were six people across Google who knew the answer to what I needed, and I had to find them, and that's a skill that people don't talk about now. Is that an absolute, marginal sort of edge case? 1,000%. But that's actually the edge cases, I believe, is where the future engineer is going to have value, because a lot of the other stuff will be taken up by the AI.
Speaker 1:If you're just building a simple form.
Speaker 2:Ai is going to do that for you right, and I love that it does that.
Speaker 1:By the way, ai is going to do that for you and I love that it does that. By the way, I mean, I'm a fan that it does a lot of this stuff. Like I have zero desire to make something look pretty honestly or to use a style from Figma. I don't want to do that. It's just like I want the AI to do that.
Speaker 2:Yeah, and that's the thing I can't stand CSS. I don't know. I don't remember any CSS anymore. Fine, if I had to do a front-end, I am totally going to run it.
Speaker 1:Typical backend developer.
Speaker 2:Typical backend developer. Whatever, who cares if it looks pretty, I just want to bake the pig right 100%. But you know I'll get AI to do that stuff and then I'll tweak it enough to sort of make the judgment call. But then when I actually have to build out the functionality, it's. The problem is when I get stuck. Now what? Now? What If AI is the only tool in my toolkit and I'm stuck? I have a problem.
Speaker 1:Yeah, when all you got is a hammer, everything's a nail.
Speaker 2:Correct Right, and then how do you get unstuck? And then you lose credibility in the team if you can't ask good questions. Before I let you go, man, tell me what are some ways that you've used AI with writing code that works really, really well. So I still go by my original. I think the last time we spoke also we covered it For those who missed that episode, go check it out we talked about some of the rules that I tend to apply when I'm working with AI, which is AI is a team member that I am accountable for, and so I have to put the lens on of.
Speaker 2:I'm working with this AI and I am accountable for the code that it writes. So if it writes it and it's wrong, that's on me because I merged it or I sort of let it enter the code base. On me because I merged it or I sort of let it enter the code base, which means you have to exercise a tech lead mindset with the AI. You've got to know how to review it. If you know enough to review it, then use it as much as you like, but if you don't know enough, such that the AI is telling you things that you have no idea about, you would be hesitant, even unless it's someone on your team that's had five years of proving themselves.
Speaker 2:You would not just blindly say, okay, you're saying that I believe you. You would always want to validate, you know, check the code, test it, et cetera. You want to do all that. So treat it like an employee that you're responsible for, that you're the manager for. Do not delegate things that you do not already know how to do or know enough that you could figure out how to do it right. If you're delegating things that you have no idea how to do, it's kind of you know those, um, those startups, brian, where you have non-technical founders who assuming everything is possible, but just put this thought in some ai video.
Speaker 2:and if you just delegate everything to the AI and then the engineers are like it's not going to work, yeah, not quite.
Speaker 1:Yeah, exactly yeah.
Speaker 2:So you know it's that sort of. If you're delegating to the AI and you don't know how to do it, then you're opening up a real Pandora's box of problems. So I think those are broadly the two principles. I use it every day. But I'm very clear that this is a pair programming exercise. This is not you program a nice lie in a hammock and sip a pina colada. That's not what we're about. This is pair programming. I'm going to stress test.
Speaker 2:There's a reason why I talked about this on LinkedIn. There's a reason why it's called co-pilot, it's not called pilot. There's a reason, right, there's a code. It's meant to be yeah, it's meant to be done with you. And there's also a reason why commercial airliners still require a licensed and trained pilot to be up there, even if they're sleeping. They're required to be up there even when the plane's on autopilot, because, yeah, need would you get on a plane where the pilot wasn't trained just because autopilot is really good or the ai is really good at flying the plane? No, you'd expect the pilot to be trained. Yeah, it doesn't differ. It doesn't differ here at all, you know okay, yeah, I, I like that a lot.
Speaker 1:Yeah, it's funny. We have self-driving cars now, which are also a little scary because, uh, I take them for fun in san francisco they're awesome, but uh, yeah, if I'm in a rush or if I have to go through a sketchy area, I absolutely want a human there, because I do not trust it to make the right decision. Lastly, what is the one AI tool you like using the most for coding?
Speaker 2:I'm a big fan of just in the IDE experiences. So I think both VS Code and Cursor are doing great. So you don't need to hop around between windows and tabs anymore. You just create it um in your in your ide. You connect the ai that you want at the back end. Whichever one you've got the um in the key for, or if you're paying for a subscription, then you know you get some included credits. That's great. Um, I don't really use the chat gpt interfaces very much. Um, I don't use those interfaces at all. I just do most of it in the ai. Sorry, sorry in the.
Speaker 2:IDE directing, yeah, Moving around. By the way, guys developers out there learn to use keyboard shortcuts.
Speaker 1:I cannot tell you how life-changing they are. Yeah, set the key bindings up.
Speaker 2:Do not keep reaching for the mouse all the time. You'll just get so much faster once you get keyboard. Once you start with keyboard shortcuts, you will not go back to moving to the mouse like. You'll just be like oh my god, this is the slowest thing in the world, reaching for the mouse, scrolling across the screen like now that's it.
Speaker 1:I'm putting my vs code shortcuts in this, in this episode, if you go to the bottom of the episode, you'll see, because, yeah, more of you need to know those 100, you know.
Speaker 2:So you can toggle on and off the chat, change the modes. You can do all of that with your shortcuts and that's kind of how I use it. To be honest, brian, I tend to prefer ChatGPT is really good, so I tend to switch and cycle between Cloud, chatgpt and Gemini and I often will ask the same question of all three. Oh, okay.
Speaker 2:Because, as far as I'm concerned, I've just got extra team members and they give me, especially for things where I'm like I don't know. I don't know if this is actually going to help me. This answer is going to help me. I ask them questions. I'm like what have I missed? Review my code and tell me what I could do better, and I can't remember who was a really great article where they said that they used a lot of AI and then they stopped because they felt they were getting really rusty. So what they would do now is they will still go through the effort of writing the code themselves, but get the AI to review it right, so they still maintain their craftsmanship.
Speaker 2:Yeah, I think it's a harder way to do it, but it gives you you know your hands are still very firmly on the wheel, which I think is really important, like I do not want I post on this on linkedin as well.
Speaker 1:I do not want vibe flying.
Speaker 2:I do not want vibe medicine, you know. I do not want surgery, I do not want any of these vibes. So why is vibe coding suddenly okay? I do not want one vibe, lawyering, I do not want vibe judgment. I do not want vibe policing, I don't want, do not want vibe judgment. I do not want vibe policing, I don't want vibe anything Me neither.
Speaker 1:We've cheapened this industry too much. I think We've really cheapened what software engineers do, and I do blame kind of this boot camp era and like the whole like anyone can code thing. I'm like, yeah, I guess Like anyone can be president too or a plumber or you know a neurosurgeon.
Speaker 2:Don't cheap, president too, or a plumber, or you know a neurosurgeon required, yeah, yeah, don't, it's we've made it.
Speaker 1:We've really done a disservice to ourselves and I'm a little bit glad that era's coming to a close, which I, which is why I think that we're we're in a good position.
Speaker 2:If you don't want to be a vibe cutter, if you actually want to be a real software engineer and uh learn how to think through difficult problems, you know, and and that's the thing with with what we're doing with Power City in a Circle is it's like we have students who don't necessarily want to become software engineers, but they want to have engineering-like skills so that they open up this tree of options in front of them. And that, I believe, is the right way to think about your future, because none of us can see more than two to three years out, and if you don't have a mix of skills that makes you fairly unique in the marketplace, if you're going to be a commodity in the marketplace, you're kind of in trouble because the AI will eat up the commodity jobs. It will eat it up. So for those who want to learn to code to get better careers, it doesn't have to be software engineering. There's no end to the kind of careers you can have by learning to code just because you'll be more technically minded. Vital skill right.
Speaker 1:And that's an environment. Yeah, 100%. Learn to code and do whatever the hell you want. Yeah, the most useful skills.
Speaker 2:Exactly and this is the beauty of it, the most useful skill I learned. I would not have gotten into software engineering had I not learned sales and how to sell during my startup years. There is no way I would have gotten into a software engineering job, because sales is about identifying good sales is about identifying the problem, the prospect needs and then solving that problem for them convincingly. How is that different from a job interview? It's literally what a job interview is.
Speaker 1:Yeah, that's the reason number. You know 628. Wise sales people tend to make really good career changes in the software. Well, zubin, thank you so much for talking to me today. I always enjoy speaking with you. I'll speak with you again this week, but it's fun to speak with you on air and going off on this kind of stuff. I have links to all the stuff we chatted about, including the article in the show notes.
Speaker 2:Sounds really good. Thanks for having me, Brian, and in a few weeks let's try and do some episodes on the interview process and what we're seeing as well.
Speaker 1:It'll be a fun one. I cannot wait Good.
Speaker 2:All right, See you later man.
Speaker 1:See you around. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and want to work directly with me and my team, go to Parsityio, and if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.
