how AI ruined software development

So, this is how AI is ruining software engineering. First, by allowing companies to scale micro-management and replacing assistance, what they promise, with surveillance. Second, by creating what we call metastatistic code bases. Code bases that are kind of zombie-like. And third, by leading to zero trust technical interviews, which feels more like FBI interrogating you actually than just applying for a job and trying to get a job. Let's dive into number one, micro-management at scale. Well, just like this developer has noticed, many developers are realizing that their jobs are slowly becoming unbearable due to AI. In this case, this particular developer did not resign already because they have bills to pay or family to support, right? Because what's happening? Well, their micro-managing CEO is passing code from the GitHub repo and telling them, hey, why did you guys did not came up with that already? And the problem is that 50% of the suggestions that the CEO is recommending are actually hallucinations, as you can imagine. But the overall result of this is that for them, logging into Slack each morning seriously wants to make them puke. Again, this is not a specific episode, but we've seen this happening in the developer teams of developers we coach, and this is starting to become a very common scenario. So what's actually this micro-management at scale all about? Well, managers are using AI to double guess developer's work and micro-manage, and it's not managers only, it's all kind of stakeholders. It can be product managers, it can be CEOs, as you've seen in that case. Also, we've seen next-generation developer tracking, aka surveillance software that's being released, which results in software engineering becoming some kind of an assembly line job, right? Instead of this creative problem solving, you suddenly have all these tools that were supposed to support you, but right now they're becoming constraints and kind of they're becoming control tools. Which creates an even bigger disconnect between what we call the programming class, right, the software engineers and the business

class, the stakeholders on the other sides. And developers are being seen as a redundant cost center, which is nothing new. But what's happening is that this generative AI technology, it's actually promising a full elimination of the developer for the first time in history. Yeah, so we already had our Jira burn charts and uh sprint metrics, and all these dailies that feel kind of, uh, you know, constraining you into this assembly line kind of routine where you wake up, you look at Jira and you tried to uh make sure that you are not on on rating any of those metrics.

But we've seen a lot of new software being developed on top of tools like Jira where they can see exactly, you know, how many lines you've committed and estimate the quality of your code in a very arbitrary way. So it's really getting next level. And I think you uh really stressed point number four, where it's always a good idea to move as a developer towards business or company where you are not seen as a cost center, but rather as an asset, where they see the relationship with you as a partnership rather than a transaction.

And that's where you'll do your best work because you'll be appreciated, and that's where you'll also get better pay. Yeah, Bogdan, you're a software engineer, if you had to work in this kind of environment, you know, how would you feel about it? Well, Darsh, as you mentioned, micro management, it's nothing new. I had CEOs and product managers uh questioning my estimates in the past, and now they are even questioning the solution itself, the code.

Of course, you feel very disrespected, you feel very anxious. And there's this whole feeling of I need to prove my worth all the time, so you're always showing up to work, trying to do your best, which never feels like enough. This micromanagement and disregard towards developer work, it's nothing new. And I think the biggest problem is the lack of motivation to get anything done. You really apply the carrot and the stick here, but you only have the stick.

And it's in the form of AI plugins to Jira, AI generating or reviewing your PRs or snippets of AI generated code that come to you and that you have to implement. From all those stakeholders. So, what can you do about it as a software engineer working in a team where you are being micromanaged using AI? Well, first of all, you got to understand your own value. And you got to understand that AI can write code, but it cannot actually build software.

Exactly, there are. So we see AI tools generating a lot of code. But they are very far away from having workable code, they are very far away from finding the right solutions. The illusion of AI generated code, it's sort of a very good illusion. Because when you create these tools, the suggestions you get on the surface are extremely good. But very few people talk about the effect of doing this at scale.

And we are very, very far away from that, you can check the other videos we have on the channel where we deep dive into the actual effectiveness of those coding models. But as of now, AI can write code, they can generate code, but it can't build software. And a good question that you can ask yourself, if you really think AI can replace you, it's, if you leave tomorrow, how expensive would it be to replace you?

Can your company get things done by using AI instead of your skills? The answer will probably be no. Secondly, remember that giving in to this uh demands, it's really a race to the bottom. Because first they ask you to implement their AI suggestions, then they ask you to fix them. Then they ask you to stay over the weekend and make sure you deploy them. So you got to stop at some point, which brings us to the second point in this video, you got to set boundaries and teach people how to treat you.

And the best way to to do that, it's of course to use AI tools and to ride the wave, but do ride your own code. You don't want to come across as this grumpy developer who doesn't want to learn anything new. You want to know the AI tools your CEO or the people around you use, the AI coding tools better than they do. And to also, very important, understand their limitations. So when people come and approach you and ask you, hey, we could do this, you can actually make them see the flaws in their solutions.

One thing you can do here is to really call AI by its name. So when people refer to it with AI, always make sure you bring in the view of a large language model that it's statistically generating code and that has a very limited context window. Not only in the terms of the context of your code base, but the non-linguistical understanding of the world. And when you embrace those tools, but bring this new perspective of an expert and an engineer that knows how to use these tools, it will be extremely hard for them to push you or tag you as someone that's opposing change or not flexible. The second thing you can do is to put the responsibility on them, right? If someone comes to you with a code snippet that they got from Chat GPT, then invite them to push it themselves. Exactly, you want to really give it back to them in a way, in a very polite way, because once you say yes, it will be on you to make that code work. And I can promise you that no matter how good that looks like, and even if it works, tomorrow you'll have them again at your table, second guessing everything you're doing and creating extra work for you. So you need to gently remind them that you are committed to the code base, it has to be reviewed, it has to be checked on how it integrates, it has to be tested, and sure, we can use AI for suggestions, but there's a difference between a suggestion and the actual implementation. And if they really want to implement that solution that GPT gave them so brilliantly, you can invite them to check out from the master branch and give it a shot to production and live with the consequences of their choice. And remember that your problem is not AI, your problem, it's probably your manager and your lack of options. Which brings us to the third point, you got to build leverage, and if you can, you have to switch companies. If you cannot switch companies because you struggle with tangled interviews, like a lot of developers do, you have to upgrade your skills. Yeah, exactly. The other also necessary something that we advice people to do regardless of AI or in AI, which is focus on yourself, built valuable skills and make sure you're always in a very good position.

you are getting paid well, not because you are afraid you won't do better. You know, people that have been into the market and they're telling you, oh, the market is not good. You really want to always operate from a position of power and of abundance, not scarcity. Maybe it sounds a bit nihilistic, but you have to need your company less than they need you. They need your skills more than you need their money because you've got options.

And if you're looking to improve your skills, the best way is for you to understand your technical gaps first, which is why Bogdan and I at the Senior Dev created this free 10 minutes technical assessment for JavaScript engineers. I invite you to go ahead and take it. It's about 15 minutes and you will get a clear overview of what your gaps are on the full stack as a JavaScript engineer. Finally, keep in mind that if AI can do your job, maybe it can also replace your CEO.

Just like this New York Times column claims, chief executives are also vulnerable to the same forces buffeting their employees. Onto point number two, metastatic code. What do we actually mean by this? Well, we are seeing all this performance benchmarks where AI is really good at solving code forces or lead code style of problems and even close some issues on Python repositories from Git. But very few people talk about the long-term effects of adding generative code with large language models to a code base. And what we see is a cancer-like effect where code starts going exponentially, but the value of the overall code base decreases. You get a lot of repeated code, you get a lack of coherence in the style of how code is written.

And really, it feels like tumors that are growing and growing in your code base, and all of a sudden, you need a lot more code to do the same or even less functionality. And remember, the number of bugs, it's proportional to the size of the code base and so is the debugging time it takes to fix those bugs. So having a big code base, it's something developers work very hard to avoid. because it's extremely hard to manage and it's only getting worse with AI.

We've got a good example of this where a developer it's tired of hearing co-pilot suggested this at work. It seems here that it's becoming frustrating when they are looking into a PR and when they ask the developer who wrote it, they say, hey, it's because co-pilot suggested that. And of course, the suggested code it's garbage and this is very funny because it's not even only juniors, it's people who have about 10 to 15 years of experience.

Those are seasoned developers who are actually defaulting on GPT to write the code. Very funny because this developer was not expecting LLMs to make their life miserable so quickly. And now it's not because they are afraid of being laid off, but because their colleagues think that LLMs are much more useful than they are in practice. And as Bogdan suggested, we have this metastatic code that's being created mainly due to breadcrumb coding and prompt to prompt development.

Where developers almost fully delegate the coding to AI, blindly following what it spits out, resulting in pull requests that become literally hell. full of AI generated code where you basically don't know what's AI and what's not? Exactly. And so it's so much easier to write a lot of code, especially when you have the context around it. That, of course, some developers are tempted to just outsource their job to GPT and use GPT to create the PRs.

Now, to an experienced developer, that kind of AI code, it's very easy to spot. In the same way, AX is easy to spot if an article was written with GPT or not. It's usually very, very both, it's usually off point, or it's way too complex. or Google claiming that 25% of their code was written by AI, which is a very dangerous thing, because a lot of the AI generated code, it's redundant, and it gets exponentially more expensive to keep writing your code with AI.

The more tokens you feed to the model, the more expensive it is to get an answer back, and the more tokens you're getting back, and so you get into this vicious circle of more code, more bugs, more need for regression testing, harder to separate boundaries, no modularity, and so on. And remember, it's all because it's extremely easy to generate code with AI, but it's extremely hard once you have a certain code base to make sure that you can extend it in a healthy, high-quality way that avoids bugs and delivers value.

And we are getting what we call to a Babel Tower effect. If you remember this ancient tale where supposedly God changed the language of people and nobody could understand anybody, and that's why the whole city and the whole tower went down. And that's exactly what's happening in development teams where you start having no coherent view of the system, you start accumulating tech depth, you have a lack of uniformity in the coding standards and the code itself.

Do not repeat yourself, dry does not apply anymore, and you see people trying to reinvent the wheel. As a result, your bug density increases, you see frequent rollbacks, and you've got more customer complaints. Exactly, and this is nothing new, you used to have a lot of difficulties in development teams because everybody will join and they have their own opinions on how code should be written. That's why we have things like the linter or prettier in TypeScript, trying to set some discipline on how we write code and reach consensus.

Because we reduce the scope of decisions that we need to make as a team. The style of the code it's already decided, the type checking it's already in place. And so this is what best practices try to do. They try to take everybody's effort and make sure they work with each other, not against each other. But because everybody now it's using this echo chamber for code writing that amplifies whatever you feed to it, itself where you see AI generated conflicts in the team.

Developers cannot tell if their colleague was the one actually writing that piece of code, or if it was actually AI and they just copy paste. And finally, the developers who have to check all the work, because someone has to check when defects appear, what happened here, are getting into a burnout because they have more code to review than ever. And the other ones are falling into passivity where it's just, hey, let me use AI and not be very proactive about the job itself.

This is coasting to the square, powered by AI. So, what's the solution to this? And what can you do if you find yourself in such a team that's creating metastatic code? First of all, you got to break the cycle and you do so by enforcing responsibility. So, regardless of whether the code is AI generated or not, if it's your pull request, it's your code. Exactly the gger session. I think we will see a lot of development on all the observability tools where you will be able to relate a certain bug with a certain commit which traces back to a specific person.

And I think there will be a lot more transparency and visibility, but also a lot more responsibility at individual level because if you break production, it will be very visible that it was your commit. And if the other engineers see that you did broke production with AI generated code, I think your reputation in the team will evaporate. So, kind of using AI without thinking will be somehow penalized.

Then this brings us to the second point, which is encouraging public live code reviews where people have to basically explain their code in front of their peers, which automatically like enforces responsibility. Yes, so imagine you are a CTO or an engineering manager, you really need a good engineer to help you out with a real project, with a big project, you'd really want to know that that person can code live.

And as an engineering manager, if I'd be an engineering manager today, the first thing I would add would be public live code reviews where we gather as a team and we review some PRs together live. And I'm sure people will be a lot more careful about what they commit to the code. code base, when they have to explain why they did it to all their colleagues. And finally, you have to limit, if you can, the size of your PRs. Exactly, so when you limit the PR size, and at the same time you enforce responsibility, sure, if someone could go and try to prompt GPT for a more for a smaller solution, for a more implicit solution, but usually those solutions are very complex. That's why it's a lot harder to understand, for example, what a functional programming snippet does, it's a lot harder to explain React hooks because they are implicit. And so it's this combination of you are responsible and we need to write elegant, small code that actually solves the problem, that will actually leave people with no other option than write high quality code. Which also brings us to the second point, and that is get insanely good at debugging. This means get to know the good old IDE debugging, browser debugging, logging, monitoring and alerting techniques, as well as logging, monitoring and alerting techniques. Exactly, because bigger code bases will result in a lot of bugs, unskilled developers that committed code they didn't actually wrote, will be not capable of solving it, and that's when you can actually shine, because when these bugs happen in production, you really need someone that knows what they're doing. And guess who will be able to jump into the code, figure their way out around all these files of code and actually find the problem fast. That will be not someone that's working with GPT and prompting it, or generating their code with co-pilot. It will be someone that really knows what they're doing. And finally, you have to learn proven problem solving principles and fundamentals. It's so easy to generate code these days, that it is crucial for you to be able to identify what is bad code and what is good code. And for that, just like in philosophy, we have the Ocam razor, for example, we have thinking, we have reasoning principles.

AI generated nonsense. Exactly, and this goes back to what we already mentioned, which was the breadcrumb coding, the prompt by prompt coding. If you use mental models and principles, you will be able to find your way very quickly to dozens of modules or even microservices and be able to come up with solutions very quickly. And that's something that AI cannot do, and this is by design, again, those models are always predicting the next token.

It's extremely hard for a model to think in terms of systems. Even if the model developers like Open AI are trying to prove differently, and so if you invest in those mental models, fundamentals, and then you get really good at debugging, and you're really responsible for the code you push, you will see an increase of your effectiveness. So maybe you don't commit as many lines of code as your colleagues, but you're much faster and you deliver higher quality.

On to point number three, zero trust technical interviews, which feel more like an interrogation. And why is this happening? Because AI it's simply ruining a lot of companies hiring efforts, just as we see here, this software engineer, it's working for a large company and they are interviewing for contractors. They encountered a lot of interviews cheating during the interview, likely with AI. Any questions they ask were answered with a word of salad buzzwords, sounds like AI to me.

These people were building the wrong thing during the exercise and they couldn't really talk through a leak of their code. These zero trust technical interviews are leading to anti fraud resume need picking, where you are guilty until you are proven innocent. The reason for that, it's because every job posting these days what was this about? What do you mean? Exactly, and on that point, because there's just so many candidates and nobody really knows if they are good or not, companies are moving a lot more of the technical questions to the pre screening.

So you have now this uh online screening tests that they would send over that they're using those more and more. And you also have recruiters sometimes asking technical questions on the phone, which was not the case three years ago. Nobody would ask you on a screening call if they were an HR manager, how do you do an SQL left joint or can you tell me what closures ask are? Because first of all, they don't know the answer.

And second of all, it was a screening call, it wasn't a technical interview. But we are seeing that becoming almost a standard in 2025. And the problem there is that these people, they can sure ask questions, but they don't have the competency to judge your answer and most times the answer to such questions are not binary, right? So you see actually false positives where genuine good resumes, like real resumes are getting tagged as GPT written and otherwise good engineers are getting passed just because it's hard to distinguish the real from the fake.

Which brings us to the next point, all interviews will converge towards live coding. Given that companies don't trust your submissions, the easiest way is to make developers code live in front of you and see if they can actually code. And we've seen cases of people submitting a take on task that they did with AI and then having the lead developer or senior engineer go into the code asking them exactly why did you do this?

What are the drawbacks here? How would you do it differently? And they blank out because the code was generated with AI. And so you got to be very careful when you're sending these things over and if you use the AI to write part of it, make sure you review every single line and you can explain it and you have at least one or two ways in your mind on how you could do that one thing differently. The second trend we see is that system design to layout the endpoints of a REST API.

They want to know you know the HTTP protocol in depth. It's not enough to give this high level view we used to give because they really want to know is this person really an expert? Do they know what they are doing and they cannot trust your resume. They cannot trust the code you submitted and they want to see you solving that problem. In real time with them. And it feels like companies and candidates are getting entrenched in zero sum arms race.

Where developers are using AI to build resumes and companies are using AI to detect those fake resumes. The net sum of this it's actually zero. Nobody's actually winning, just the whole market is getting worse. And what we anticipate, it's more extreme anti AI cheating measures, such as screen and camera recording, system monitoring, eye tracking, like anything that companies can use to make sure that the person is not committing fraud.

And that they are actually assessing their real skill set. Instead of just their ability to use AI in order to cheat on the technical interview. And how can you deal with this zero trust technical interviews? Well, first of all, you have to make live coding your second nature. So as we mentioned, take home tasks are now involving live coding, they will want you to live code. More and more companies are doing live coding as the default interview and I do not think you'll be able to get a developer job a year or two years from now.

Unless they see you writing live code. Because again, anyone can submit the solution to a problem, anyone can generate some boiler plate with the AI and pretty they build it. Companies that really value the developers and the software they building. They'll want to hire people that can actually write code. Now, we will see more and more live coding in the interview processes. And what we advise you to do is every once in a while, try to write code without any AI assistance.

You need to practice those skills. So just go to your cursor or windsurf or VS code and disable copilot or disable all the AI assisted code. Try to do it plain, use the old IntelliJ. questions that are really good. And try to write code from scratch without any noise. Try to really focus on that one single problem you're trying to solve. Secondly, master the fundamentals. Start with basic control functions, the four and while loops and core data structures. Secondly, you have to make sure that you write your resume yourself. Yes, and I mean all of it. Same with your LinkedIn profile, same with the emails that you're sending to recruiters. You want to be human, you want to be concise, you want to be you. The best way to stand out, it's by not doing what everyone is doing and by not using AI. And we see a lot of people generating this three pages emails where they could tell you the same in two lines. And it's so unflattering to receive one of those because you feel like the person didn't really put any effort into it. It really feels like one of those old corporate jargons to the square, where it's all, you know, this generated paragraphs by GPT that don't make any sense. And you have to read all of it to actually see, okay, this could have been a one-liner, yes, no, let's move this forward, cheers, see you later, that's it. One last word, I think most people are playing a very dangerous game where they're kind of externalizing and outsourcing basically their thinking processes to these LLMs, right? So, what will happen in a few years? It's a lot of people will start falling behind. The hype behind the lamps will be gone. We will see how they are not actually able to reason, they're not actually able to think. And the people and the software engineers who did not give in to the illusion and are able to actually do the thinking, to actually build the things themselves will easily stand out. You want to be on this second category. So be aware of AI zero sum games. Think critically about these tools and their effectiveness, which despite what Big Tech wants you to believe, it's very limited. Don't give in to the mass hysteria and despair, become the best developer you can be. These tools are not as good as Big Tech wants you to believe. And that's exactly what we proved to you in this next video. We'll see you in the next one.