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
#238 - My Experience in Vibe Coding Hell
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
A rant on the myth of developer productivity with AI and my experience in vibe coding hell with a team of senior engineers.
- Why Vibe Coding is great for prototyping and terrible for real software
- Why we still need junior developers
- Why you should be wary of loud expert beginners online
- What skills you ACTUALLY need as a software engineer in the AI era
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. So this weekend I wrote an article about vibe coding and I sent it out. I wanna tell you a little bit of a story about my personal experience with vibe coding, hell and a lot of the really, just to be honest, idiotic stuff that I am reading from people who are commenting on some of my posts about what they think about AI and job displacement and automation and the silliness and the fear-mongering around this which I thought had died down. But apparently there are people that are centering their whole personality, perhaps their career, on the idea that AI is just going to replace all developers and you should never learn to code and the job market sucks and give up and all this kind of stuff. I can't stand this for a couple reasons. One, I'm a senior software engineer. I've worked at many companies throughout the Bay Area, one of the hottest tech markets in the world, and I've seen firsthand the limitations of AI, how it's going to expand and change the landscape of what we do and change our jobs. But also I've just seen that the demand for engineers that know this stuff is rising. We're at a two-year high for software developer openings. This may shock you. You're thinking the job market sucks. Right, it sucks. It's got to be terrible. It's not easy, it's really weird and it's different than it used to be. Got to be terrible. It's not easy, it's really weird and it's different than it used to be. That's how things are. They change. It's down from a big high from 2020, obviously, in the 2020 pandemic hiring spree, we hired more developers than we ever should have. Then we fired them all and now we're gradually hiring them back. We're at a two-year high as far as tech job openings. Anecdotally, I'm seeing more people at Parsity get offers. I'm seeing more people at Parsity get offers and actually turn some down. I'm seeing more people get interviews. Now we're focusing on how to pass interviews, not how to just get to the interview. The problems are changing, things are changing, the landscape is developing.
Speaker 1:But before I get into some of these things, I wrote this article right on the weekend and I posted it on LinkedIn. This guy gets in there and starts spamming the comment section with all sorts of junk about how you know software engineering is dead. Here's an article that proves it. You know, everything you wrote that you said you couldn't do with AI can be done with a senior developer that knows AI. And I'm like maybe this guy knows something. I don't, maybe I'm just dumb and this person's some super senior developer and maybe they've cracked the code about how to use AI.
Speaker 1:I look up this person because I'm petty like that. Right, I look them up. Look at their GitHub Basically no commits for five years, no indication that they've ever really worked as a software engineer. I look in some of the repos the few that they have. The code is junior, you could say. At best Anybody at Parsity would code circles around this person. Then I start to wonder hmm, this person has a lot of opinions on AI and productivity and how it can replace them, but doesn't seem to have ever worked as a software engineer.
Speaker 1:We're in some dangerous territory, my friends. We have people out there with microphones, essentially on the internet, telling you not to learn to code because they don't know how to code at a professional level, and they think because they can't find work and because the game seems rigged against them, because they went to some boot camp for three months and made some clones of some different apps that they can't get hired. They think this means that you cannot get hired. I have big news for you, my friend Vibe. Coding is not the way, so I just joined a company, right? This is the third company I've joined in the last 12 months, not exactly a strategy or a path that I was happy to take, it's just the path I ended up having to take. Anyway, that's a whole other story in itself. I've had three different jobs, all senior level in the last year, one at a director level pretty crazy. So here I'm on this team.
Speaker 1:The CEOs were introduced to Vercel V0. Basically, it's this prompting tool you can use on Vercel to make a full stack application. Here's where the danger sets in. Ceos want to believe this myth of AI, want to believe this myth of AI. They think that, oh my God, now I can build an app and I don't even need a developer team. And I encourage you to go use Vercel's vZero. I'm using it. Use Lovable, use whatever. In fact, the CEOs that we're working with in the internship at Parsity are using Lovable to construct their like prototype. Right, it looks amazing. It looks really, really cool.
Speaker 1:I saw the whole thing and I asked the guy straight up. I asked the CEO in an episode that I'll release, I think, this week. I said hey, if you can build this whole thing with lovable and like AI, then why do you even need interns and why are you going to hire developers? They're expensive, right? And he's like well, yeah, like, obviously we can't really build the app with it. This guy is a developer himself. Do you think he wants to spend money on developers to build stuff?
Speaker 1:Do you think any company wants to do that, like just because they what? Love developers? No, they hire us because we're just a necessary evil. I mean, we're overpaid, we take a lot of vacation, we job hop all the time. We're not fun to work with. Let's just be honest. Developers are a weird bunch. We're kind of like oh great, we had to pay these people a bunch of money. They're probably not going to stay very long. They tend to kind of work on their own schedule. They don't usually work mornings. They're kind of like divas in many ways at many companies. Do you think companies want to hire us? Probably not. There's a lot of incentive to replace us and yet, and yet, somehow we're at a two-year high as far as job openings in tech. And the companies like OpenAI or Lovable or name a company, anthropic Claude they're all hiring developers at scale. They're not hiring one or two developers and just saying, hey, let's use our tool to build. They're hiring a bunch of developers.
Speaker 1:But back to my story about these CEOs right, so the CEO is very non-technical. They built this really amazing prototype. Looked way better than anything I could make. Honestly, built this really amazing prototype looked way better than anything I could make. Honestly, like it looked so much better than anything I could make.
Speaker 1:Now they said, wow, if we could do this in a day or two days, what can our development team do? And they basically said you know, here now, in a week, you can build this. And we're like okay, let's try this out. You know we're basically building a prototype. We said, well, can we use fake data? Because obviously this won't work with real data. We had to explain why that wouldn't work. Okay, hey, now we're going to need a day or two to deploy it. What does that mean? It's already here. And when they said here, we're like what do you mean? And they're like well, I can access it right here. Like, well, that's like within Vercel's vZero interface, that you can't share that with the world. Yet we need to deploy it right, and the more things you add on, the more difficult it becomes. So you can keep adding prompts to then generate more and more code, but as soon as little tweaks happen and as soon as the data needs to change and as soon as you want to bring in real data, things start to break really quickly.
Speaker 1:And this is with something like a 20 page app. I mean this is something really really small. I mean, I'm sorry, 20 files, more like five pages, three to five pages, super duper, small app. We have a small team all of very senior and lead engineers working on this very small, very experienced team. One woman has a PhD. Like these are not like junior developers, right, like, and we're all working on this trying to make it look cool. None of us are designers. We're adding real data. We're trying to use it with fake data. We're trying to like, mimic and mock what it would feel like, and it says breaking all the time at this point, so we're getting 80% of the way there, that final 20%, even in a week, even working eight hours a day, even with Even with five developers with basically a fake app.
Speaker 1:We barely got it across the finish line for the demo and we had to tell the CEOs this is a great way to prototype, and if one person does this and you want to deploy it like crap out to the world, that's fine. The deployment process is going to be janky at best. It's not going to be real data and we really can't connect to third-party APIs and things like that. We don't really have a way to do that in a really fast way yet, or a scalable way at all. Right, in order to do a scalable version of this, it will take literally months, maybe a full year, and they're like whoa, what do you mean?
Speaker 1:So we're in a very interesting position now, where I think a lot more developers are going to come across this issue, where you used to not have to explain what you did as a developer. You say, hey, this is going to take X amount of days or X amount of months, and they would just kind of say, oh well, you know, damn, that sucks and okay, you know, what can we do to speed it up? Now I think you're going to have CEOs and leaders that don't know anything about code, generating code really quickly and being like, well, if I could do this, then you should be able to do it in a day. And you're going to now have to explain. Well, what you've done is create a thousand-line long file and then explain why that's bad. And if you don't know why that's bad, then maybe you need to learn a little bit more about how to write scalable, extensible code.
Speaker 1:You say, well, this works, okay, right, and we can keep feeding this to our little AI helper. But our little AI helper eventually is going to either get confused, the context is going to grow too large. And even if the context doesn't grow too large, when you're adding more code in a thousand line long file, it's really hard for any other developer to make heads or tails of it. And at some point the AI code can't just generate exactly what you're trying to describe, and you're going to need a real developer to do it. Code can't just generate exactly what you're trying to describe and you're going to need a real developer to do it. And the moment you add real data, we're going to need to then kind of rip out lots of this and put it back together to then use real data. And that's the problem. And if you don't know how to do that with prompting which they obviously won't know how to do we're going to need to do a lot of things like how do we hook up our database and set the security permissions so that we can actually interact with it, and then how do we then consume that data, replace the fake data and then make this whole thing work?
Speaker 1:And also, you know, you add really resource-intensive things, like a map, for example, which looks great in v0. Once you deploy that, though, that map may have some lagginess, it may not work as fast as you expected. We saw that issue when we were deploying the app. We said, wow, this map looks great on this person's machine, but once we deploy it and if you're on a slower browser, well, it doesn't look so good. And no one's thinking about that. What about slower browsers? What about mobile devices? What about just making it safe? What about our API keys? Originally, the app actually had our API keys exposed in the front end. Imagine if somebody got to those things and just ran up our bill through the roof. There are too many things that can go wrong. And this is just one week. Can you imagine trying to do this at scale. It does not work. It cannot work at this point. And if you're a person that does think this can work, I would love to hear some proof.
Speaker 1:In fact, there's a really funny article out there. There's a post from this CEO he fired his entire dev team. He's like I'm firing the dev team, I'm a team of one. Now I'm using lovable cursor anthropic. Two weeks later he's on LinkedIn saying I think I have some work for a few web developers that may want to work on this really awesome app I'm building. People saw it. They called him out and said hey, aren't you that idiot that fired your whole dev team and now you got to hire him back? Yeah, not very bright. So what was the point of this whole rant that I'm on right here?
Speaker 1:One I'm a senior software engineer working with smarter people than me. We can't really figure out how to vibe code our way to anything past a prototype, and when I say vibe coding, I mean literally just prompting and like spitting out some junky code that works to make something that appears to be real. The last 20% or maybe 50% or maybe 60% of the code we got to write cannot be completely AI generated. It has to be thought through. We have to think about all the other systems we're going to interact with. We have to think about security. We have to think about our customers and the kind of devices they'll be using, and also testing, maintainability, observability, all the common software engineering practices the boring stuff that CEOs don't want to hear about but is part of deploying scalable web applications. And forget the backend. We haven't even touched that part yet. We didn't even touch what goes on in the backend at all.
Speaker 1:This is a simple front-end app, my friends, and this alone is really, really difficult. You have five people vibe coding that may not know the framework or the language very well, spitting out junk, creating a big house of cards that will eventually just fall on itself. And just be cautious is my big takeaway here. Be very cautious, not only of people that are believing the myth, but of believing the myth yourself, because I wanted to believe this myth. I thought, you know, maybe I'm just old, maybe I'm getting too old and maybe this really is the future. Maybe I need to embrace this vibe coding thing and just like stop writing code at all. And no, I want to slap myself a little bit for being that naive. Somebody called me naive for thinking that vibe coding wouldn't replace software engineers. They said that's a naive take. I'm like no, I think it's actually the most naive take to me, which tells me that you've probably never built software or worked on a team of more than like.
Speaker 1:Two is that, if you do believe that vibecoding can really actually be a one-to-one replacement for you and a team of developers, I think that's naive and shows that you probably haven't worked on anything that's even moderately complex, even just basic complex stuff just shows me you probably don't know much, or you'd like to produce really junky code, that you probably produce code that is really subpar, which is okay for a junior developer. So maybe you're wondering hey, I'm a junior developer, I don't really know what's good code. If this thing can do basically what I'm doing, but faster, well, what am I going to be doing? This is an interesting question. What I'm doing, but faster, well, what am I going to be doing? This is an interesting question because I still see a big value in junior developers. One they're necessary. They are necessary because what's going to happen if we only what hire senior developers? Does anybody think about where this leads to? Right, if you only hire senior developers. Who's going to replace the senior developers? So, as a junior developer one, we need a fresh talent pipeline. Honestly, even if AI is as good or better than junior developers, we still need them, because how else are we going to replace the senior developers?
Speaker 1:Now, if you're a junior developer, I'd say that the bar has risen. We're seeing this at Parsity. We're teaching this and we're making sure that we give people the skills they need to actually succeed in the current job market. So what you're going to need is well beyond just front-end React stuff that is, table stakes at this point. What you need to develop is really the ability to learn fast how to work with back-end systems, how to integrate APIs, how to think at a systems level, how to design applications and not just write code that does a simple thing how do you think through an entire application, how do you make a suggestion on what to build and why, and think about all the different things that you'll need to question and build out in order to build it. So you need to really be more of an engineer. I mean, just to be honest, like this is just kind of going back to the old school. There's nothing really new we're going to teach you. That's going to make you incredibly better. It's going back to really first principles. We got to a point with boot camps where we said, oh, you don't even need first principles anymore, they're hiring for React developers. This is a gold rush. So let's just teach people React and how to make basic, basic web apps and just simple, simple backend functionality and that's enough. And companies are like you know what? Screw it, we'll hire for that. We're desperate, and now they're not. And so what does that mean for you? That you need to step back in to doing what a lot of CS grads are doing learning how to think and solve complex problems.
Speaker 1:Now, what is a complex problem? How to deploy an app safely into the web, into the cloud. Perhaps that's a non-trivial question. How do you do that? What is the get strategy? What is the deployment strategy? How should you do things like branching? Why? What kind of framework are you going to use? Why, what kind of security are you going to use? And why? What kind of backend system are you going to use? And why? Have you thought about scalability? Is this app for one person? Is it for a million people? Okay, well then, how does that define what we're going to build right. All these different questions you should be asking, even if you're building a fairly small app, like, okay, what am I using, why am I using it, how's this going to work and what is the purpose of this?
Speaker 1:And thinking through problems that aren't completely wrapped in a nice little box for you. Look at something like Spotify's playlist, like when Spotify does the year-end wrap-up and they show you all the things that you played the most. Think through a problem like that. How do you think they solved that? Think through it yourself before you ask AI, by the way. Think how would I solve that? I have a music app that people can play stuff and like it and do things like that. How would you solve the problem of creating a playlist, a year-end wrapped version of that, that tells people here's the songs you like the most, here's the songs you like the most, here's the songs you play the most, here's the number of hours you played a song. Think through a problem like that. These are interesting problems to solve, not how to build a UI with Tailwind right, that's a fun thing to do, but that's not a super valuable skill in this day and age. It's still valuable, it's just not as valuable as it used to be.
Speaker 1:Anyway, I'm coming to the end of my rant here and I just want to reiterate that, yes, we 100% need junior developers. We need them to think like software engineers instead of just thinking like code monkeys. That is not a viable career path and it never really was. A lot of the people that got hired during the pandemic spree are having a really difficult time getting hired now, and I don't say this to be mean or to discourage them. It's just that the level of talent, the expectations, are rising right and that's fair. Let's be honest. It's fair that companies said, hey, we went overboard in hiring at a time in history that has never occurred, in a dramatic turn of events that will hopefully never happen again, and we made some big mistakes. And I'm not excusing companies or whatever. You know, companies are big evil corporations that will fire you at a moment's notice. I have no real remorse for them, but I understand, hey, it's a business decision, so we need to adapt to the times.
Speaker 1:I say this stuff because I ultimately want to see you win. I obviously own a coding mentorship program, which is a business. I'm also a senior software engineer in the industry doing this stuff and living it daily and I hate the junk I read from people that have no business even talking about it and have these really strong opinions. I'm like I don't have strong opinions on I don't know how to cook like food, like a chef, I wouldn't go to a five-star Michelin restaurant and tell the guy hey, man, you know what I heard? That you should cook in this kind of fat, and I think the way you're doing it is stupid. It's pretty naive that you're doing it like that. And the guy's like, oh really, what are your credentials? Well, I cook at home sometimes. And he's like, oh well, cool man, you know we'll get the hell out of my restaurant. You know what I'm saying. So I want you to take some of this stuff out there with a grain of salt. Look up me, see, like hey, should you listen to me? Look up the people that are saying these idiotic things online. I'm so pissed off, honestly, hearing this stuff. I'm a little more spicy than usual today. I don't know what happened. I had too much coffee this morning perhaps. Anyway, I hope this was helpful. I hope this rant was somewhat helpful for you.
Speaker 1:I'm coming out with a program, by the way, to be free for Parsity students and it's going to be very not free for people that aren't in Parsity about how to actually integrate LLMs with web applications. The whole purpose of me building this course if you want to call it that it's going to be a hands-on project. More than anything, the whole purpose is I have a very simple goal here. I want to make you, if you know TypeScript if you're a full-stack software engineer with at least one to two years experience If you know TypeScript, if you're a full-stack software engineer with at least one to two years experience I want to make you the go-to person in your organization for integrating large language models into your web applications. I've done this now at two different companies.
Speaker 1:I've learned a ton and I think that it's a really interesting thing to learn generation how to observe your LLM usage in the cloud, how to write the correct kind of prompts and a little bit about prompt engineering, not much how to integrate it with things like Nextjs, how to use vector databases, a little bit of the fundamental linear algebra that you need to know in order to actually understand what you're doing, and all the little gotchas and tricks like what models to use, how to fine tune a model when you should fine tune versus using RAG Basically like how to scrape the web and feed your hungry large language model, the whole life cycle of building an actual application that will use an LLM in a full stack web application. It's very, very specific. It's not for everybody, but I guarantee you if you do this and you learn the stuff that I'm showing you, you're gonna be the go-to person. You're gonna say, oh, I know exactly how we're gonna do this and you're gonna avoid all the common pitfalls that me and the teams I've been on so far have made with integrating this stuff.
Speaker 1:It's such a new field that there's on this. I haven't found anything like it, so I'm really excited to put it out there. I'll have the link in the show notes and, yeah, if you find this helpful, great. If you think I'm an idiot, then just please unsubscribe. Anyway, I'll see you later and I always hope that's helpful. 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.
