Why I stopped using AI (as a Senior Software Engineer)

Okay folks, so let's talk about why I stopped using AI as a senior developer. So the last three years I used AI for coding almost every single day. And I probably have written around 150,000 lines of code with AI. I used pretty much every tool, every AI tool and model out there. So I started out with GitHub Copilot, then GPT came, then Claude, Cursor, Windsurf, I used DeepSeek, I used smaller models and I even used Gemini.

In order to really figure out which one is the best, and in the beginning it really felt like magic. I felt like I was just flying through the code, I was shipping MVPs in a tent all the time, that it used to take before that, and I felt like I was achieving in a single week what my full team used to achieve in a month without AI. But then something happened, and so three months ago, I was working on this big feature on one of our applications.

And I was a bit lazy, so I said, well, let me just vibe code my way into it, and basically ask Windsurf in this case to basically solve it. So I pasted literally the uh the ticket description in the Windsurf cascade. But after 15 minutes of waiting and Windsurf going and randomly changing seven files, the only thing it achieved is that it added a new bug, and so I said, you know what, just fix the bug.

And it went into another 10 minutes loop. And so that cycle kept repeating itself for two hours until I just got tired of it. Uh and so I decided to just go ahead and fix it myself. But this is when I realized how bad things were, and I really had to just get rid of all the code it generated, started from scratch and start implementing the feature. And I literally had to do git reset, and this is not the first time.

This happens, so I had this issue a lot in the past. And so it usually starts like this, you know, you start adding some code, you prompt it, it goes ahead, starts thinking, modifying files, and then you keep going, it does more and more. And then it loops itself, finds some errors, tries to solve them, tries to solve them again, and usually in the end you end up with something like this. And that's when, you know, as a human, you need to go in, fix everything, but most of the times I found it is faster to just start from scratch, do it myself and maybe then use the AI to close the gap a bit. And so, this memory that I found in the internet is actually very too, which is that it usually takes 5 seconds to solve something, but people go ahead and just ask Cursor to fix it and that would, you know, you go into another loop. And that was my aha moment when I took a closer look at the codebase that I've been building in the last six months, I realized there was ton of duplicated code. So, there was basically no component reusability and when we had component reusability, it would fall into over engineering. There was a lot of dead code, so you had useless files from previous queries that were left around and committed. You had redundant implementations, so, for example, instead of using low dash debounce, we just coded our own debounce and reinvented the wheel. And the problem with that is that in general, it's better to have as little code as possible and if you can use an external library that's already tested by other developers, that's a lot better because if you add your own implementation for those things that already exist, you also have to add your own test and you're basically running code and developing code that's already out there. There were side effects, so sometimes you'd go ahead and say, okay, can you fix the TypeScript types here? And it would go and change something in a totally unrelated part of the codebase. You had all these useless tests. So yes, we have unit tests, but they don't assert many meaningful things. And most of the times, the test cases are somehow redundant. It feels like a different test, but you're actually testing the same happy path, let's say. There was lack of consistency and coherence and I did that in the style guides and configs for the model and all that. So before people jump in and say, well, it's because you didn't add this where you didn't know how to query it, trust me, it had everything. And actually, the more style guides you add, sometimes the worse the results. And I found myself in this over engineered and bloated codebase. So we had our own custom hooks when you didn't need one. And on the back end, pretty much the same happened, all of a sudden, that middlewares that were not needed, and there was tons of tons of things called. And I estimated that we still have around 60% of the code that had to be refactored.

period and I'm basically in the process of manually, streaming that down, cleaning it up, adding test and eliminating all the clutter. And this is why I stopped using AI because I just got sick and tired of waiting 15 minutes for the model to come up with some buggy solution. The test passing even if there are obvious bugs in the application, but hey, all the tests are passing. And this whole pump and dump mentality that we have with AI coding tools, it feels just like JavaScript frameworks five years ago. where every week there's a new one which is so much better than the previous one. And yeah, remember AGI it's around the corner, it's going to happen any day now and it's been like that, you know, it's the same status with last few years. And I got tired of reviewing so much code for things that could be even avoided or not implemented in the first place. Constantly having to specify obvious details to the AI so it can start rewiring itself and correcting itself. And finally not really knowing what the heck is going on in my codebase. As a quick example, I used D3 for building interactive graphs, and obviously I didn't want it to go to depend to it because it's something you don't use every day. Let's just really quickly get it done with AI. And the result was a disaster and then I stopped, went to the docks, read what the API offers, and I was able to solve the problem. Extremely fast. And I slowly also saw that my technical skills were getting worse, I was getting a lot lazier, and I was just playing this GPT or LLM slot machine where you just kind of query it, get something back, wait again, accept all and keep moving forward. It's almost addictive, you feel like an addict, just give me the next code snippet. And my codebase slowly became a dumpster of the code generated with AI. Because, let's be honest, if you don't want to make the effort of writing the code, you'll also not read it. So a lot of people say, well, oh yeah, code view everything, I'm like, you won't do it. If you didn't do the effort to write the code yourself, how are you going to review now all those files that the AI somehow generated? Most people just run the test, they check the functionality and commit, which is a very bad strategy. Now in this video we'll cover the three lessons I learned from these three years of AI coding. How much

Yeah, I actually still use today, if I'm using any. We'll see at the end of the video. And the big mistakes that I see a lot of junior developers doing these days. And also, you know, be careful because there's a point of no return there that we will see in a moment. Who am I? I'm the folk on the right hand. My name is Bogdan. This is my brother Dragos and we founded the senior dev. In the last five years, we helped over 300 developers, JavaScript developers go to senior level and beyond.

We work a lot with people on getting those senior mental models. Now, the lesson number one I learn is that there's this myth of AI doing the repetitive tasks. So you can as a developer, you'll focus on the most complex ones like, oh, you'll do system design, you'll do architecture and you are going to the deep coding because AI is doing all this boring stuff. Now, that's false. And the reality is that if you want to be able to do the big stuff, if you want to be able to do the architecture, if you want to be able to do the micro front ends, you need to excel at the small stuff.

You need to excel at CSS if you want to do micro front ends. And this is a picture of Steve Jobs and Vozniak and what's very important is when they started Apple computers, Vozniak built the first computers by hand. They literally stitched the computers together in his bedroom with playing sick. So that's the level of engineering excellence that they had where they could build the whole thing from scratch and that's why they get to build Apple in the company that is today and that's what you need.

You cannot dream about doing big stuff if you don't master the fundamentals first. And so there's this idea that devs will do like system design or vibe system design and I think it's flawed at its core. Because you can't build a front end design system if you don't deeply understand CSS, the box model, flex, border, shadows, you just can't even imagine what it has to look like. And so people say, well, it doesn't matter if you don't know how to implement it, you just tell what you want to the AI to the LLM and then it will just spit it out to you.

But the reality is that AI cannot really think and it will just infer from whatever you gave it and the database of knowledge it has and give you something, but that's far away from actually building intelligent design. If you want to get better at the fundamentals and the small stuff, take our free 10 minutes code assessment for JavaScript engineers, we'll build it with interview questions and it will give you a feeling of where your skills are compared to the market, so you know where exactly the gap is and what you need to work on.

Now, lesson number two is that whenever you write production software, less is actually more. You probably know the story of Blackberry, one of the first smartphones companies that was completely crushed by the iPhone. And the big difference, as you see in this picture, is that the Blackberry has so many buttons, whereas the iPhone just has one. And that's the moral of the story, that great design, sophisticated design, it's actually simple, and this is a rule of nature.

You can see if someone is a great engineer when the solution they came up with, it's extremely simple, it's robust. And usually, when we start building our first version of something, it's usually complex, there's a lot of variables, and as we go more and more and we go deeper and deeper, it becomes simpler. So we want simple, easy things, not complex things with plenty of possibilities. And so, there's not a single software company that ever died because they like code, or they didn't have enough features in their software.

It's actually the opposite. If you look at Salesforce, if you look at SAP, the big problem that these big giants have is that they have too many features, too many services. And they don't know how to group them, and they have all this technical depth long around. And so more code, it's actually less productivity. That means you have more technical depth, you have longer code reviews, that you need to skim through all these files.

You have lower quality overall because nobody really takes the time to actually make things simpler. And you have longer builds and a lot more useless features. So no, we don't need more code, and writing code was never the bottleneck when building software. Great engineers, they synthesize and they simplify. And then bad engineers, they got tons of code, and it's mostly redundant, and good luck maintaining that.

So, simplicity, it's the biggest value of great software. Now, another example to illustrate this is the the raptor engine of the SpaceX Falcon rocket. So, when they came up with the first engine. It was very robust. It had a lot of pieces. And they've been iterating it and making it simpler and making it better. And they have now an engine that is almost twice as powerful. But it's also a lot simpler.

It has a lot less moving pieces. It's a lot simpler to manufacture, it's a lot simpler to maintain and it doesn't fail. Because every component you add to a system, it's an opportunity for failure. And the simpler things are, the more robust they'll be and the better. And so this law of design applies to many, many domains and it also applies in the software domain. Lesson number three is that it's just easier sometimes to do the thing than to explain word by word and verbalize how to do it.

And so describing the problems with the level of detail that you need for an LLM to actually give you a good solution, usually takes more work than actually going ahead and solving it. This is because LLMs, they lack this intuitive understanding of the world and then you need to give them all this context. So you need to specify and be very, very both about everything you need. Also, even if you give them all this context, they're not really thinking.

So LLMs, they cannot really do maths, for example. They can fake it, they can do pattern matching and give you the solution. But it's usually very imprecise and flaky, so you might get the right solution now and then you query it again and it totally goes off and hallucinates. And adding style configurations, like people say, or guidelines to keep the AI in place and and telling it exactly how to do something, it usually creates even more unstable queries.

And that's the fallacy of context. Because people believe that the more context you give to it, the better the solutions will come out. But the reality is totally different is that the more context you give it, the more code, the more guides, the worse. Because then it can pick on anything from what you gave it and go go ahead and hallucinate. You got to be careful because more context will not solve the problem.

Now, if you're constantly trying to predict the next token, which is what they do, you might not see the obvious solution. And this is something you'll observe working with LLMs, is that they'll always go back and churn a lot of code. They never just give you a simple answer. Even if I told you all this, you'll still have people at work telling you you need to use AI. So not like you can just stop tomorrow. You need to use it.

you have to use it, you have to put it and you like it, and you have to put it and wow. This is the biggest thing ever, because everybody does that. And sometimes you just have to dance along to the music being played, you can't fight it. And I invite you not to. And so this is how I use AI today. You got to first be careful of the noise vector signal. Probably see yourself forced to use AI by management because now they think is the next big thing.

Remember when compiler came out? They were like oh don't use it, don't use it, it's going to be security issues, it's going to consume our code base. But now they're like oh use it, use it for everything. And the same thing happened a couple of years ago with big data, blockchain, mobile apps, and whatever comes next. Uh they would come in and say, well, we need you you got to use blockchain, blockchain everything, blockchain or big data, you know we need big data, we need predict uh predictive analytics for everything.

A lot of those things never materialized, they were they were wasted investments. Because we are not in an age of innovation. The innovation already happened. We are in an age where they sell somebody innovated and now they just want everybody to to jump on. They are basically copying, which is the opposite of innovating. But you have to ride a wave. So ride it, use AI daily at work. But don't get sucked into it, don't get distracted by it, don't stop improving your skills because of AI.

One thing LLMs are really good at, it's inference. So whenever you have a problem where you already have version one and you just want to copy, like version two, version three. Uh let's say you have an interface and based on that interface, you want to create a couple of mocks for your test, AI is great for that. So I use it especially for that every day. Because it will take a full interface, you know, like a 30 line one and give me, for example, mock data to use in my test.

It's really great for that. You can create test mocks, you can create test cases, classes and interfaces. Pretty easy if you already have the first model. So if you have an MVC pattern in your code base and you have controllers and models, it's relatively easy to create the next one. I use Windsurf for that. It's also really good when the documentation is really bad. So whenever you find a package where the documentation sucks, it's really good to just use the AI to create a documentation rather than reading documentation yourself.

But that's not because AI is great, it's just because documentation is very poor sometimes. If you have good documentation you should go faster if you just get it. The next thing is the auto complete. I do find it pretty useful, although sometimes just it gets ahead of itself. But it's definitely a lot more powerful than the IntelliJ we used to have. However, make sure you review every single line before you accept it, because I've seen people committing code, they don't review it and it always bites them back.

It can bite you back at work and it definitely will bite you back in interviews. Now, remember the simple the problem is, the more likely is that you exactly get the you get the exact solution from the AI. So whenever you have like an array function or something very localized like a component, then it's amazing. Now, if you do want me to make a video about the best practices using AI or AI assisted coding, then drop a comment in this video, say best practices for AI assisted coding.

And if we get more than 10 comments, we'll make the video next week.