5 things every Developer needs to stay relevant in the age of AI

If you go fully AI and you ignore the fundamentals, you'll most likely not pass. All the interviews that a real software engineer needs to pass because they still want you to know what you're doing. They still want you to be able to code by hand. And if you only know the fundamentals, you won't be able to market yourself in today's market. A lot of people say you can think of AI as a junior engineer, that's not true.

AI can do things that not even seniors can do. So the difference between a skilled engineer and a very skilled engineer, it's with AI is that they can both build the thing, but the engineer that's skilled will build it in a lot less iterations. Their first version would be as good as the 10th version of someone that's just vibe coding. Which is number one, whenever I hear developers talk about staying relevant in the age of AI, there are basically two different camps.

The first one says, you have to learn AI and AI skills. And then there is the other camp, which is saying, you actually have to deepen your engineering fundamentals. And my question is, which camp are you leaning towards and why? Is if I were to choose between the okay, learn AI skills, whatever that is, this day, this is because it's always changing and going deeper in my fundamentals. Well, I think they both miss something, which is, yes, you do need to learn AI skills and how to use models and agents, but that's not the replacement for your software fundamentals.

And at the same time, the people learning the fundamentals, that's okay, you will get better and you'll be a better software engineer if you go deeper in the fundamentals. But from a marketing your software perspective, you need to have AI in your skills. So all to be very good, people won't care because you're expected to use AI on your day-to-day job and you're expected to talk about it. And companies, you know, in the end, they hire the person that tells the best story and that story needs to contain AI right now.

There's also a third thing, which is fundamentals are great, but you also need to become more end-to-end oriented. And a lot of developers in the last 10 years, the industry was all about building features fast. So we were spending 90% of our time just coding components or endpoints or doing kind of the low level work. is great and you still need to be proficient at doing it today. But that will be today only 10% of your job. So you do need to look at the end to end, that means being able to deploy things, observability, and front end and back end architecture and system design. So I would say both are partially right, but each one of them has their weakness. If you go fully AI and you ignore the fundamentals, you'll most likely not pass all the interviews that a real software engineer needs to pass because they still want you to know what you're doing. They still want you to be able to code by hand. And if you only know the fundamentals, you won't be able to market yourself in today's market. And just to follow up on this bug then, one of the software engineers I was chatting a few days ago asked me, okay, and based on this analysis, which kind of companies should I be interviewing with if I want stability in the next coming years? Look, in general, you get more stability if the company, it's more traditional. They have a secure income, they build logistics, transportations, energy, those things won't go away and they won't change. Also, it depends how long they've been in the market and how big their team is. A company that's been in the market for a while, they plan their headcount very well. So they are less likely to just hire people and fire them the next day, whereas startups would make a big promise to investors. They don't have a clear idea, they don't even have customers. And you'll find yourself looking for another job 3 months from now, without any real explanation on what you're for what you've been doing. If you get laid off from a startup like that, just say it was a contract. You can also go around like, let's say, they hired you and then they the work was over. But in general, if you what you want is stability, you've got to look for more traditional industries. Question number two. Now that AI is automating more and more of the coding, people saying developers have to move towards high level system design and develop an architect mindset. Do you agree and if you agree, what does this architect mindset actually means? I agree to some extent, but again, it's like saying that an industrial engineer or an architect, they don't need to know about concrete. Or they don't need to know about the details on how you can mix different materials together or how much they weighed. They will just vibe code, hey build

and he just needs to know how do you assemble this higher level picture. That's definitely a big mistake people are doing, which is high level design, it's not different from low level design. The only difference is the boundaries and the mindset. And my advice to everybody would be you need to develop both. Because one of your responsibility will be, yes, designing services and expanding the system.

But AI can do that very well, too. Like the other day I extracted two microservices from our monolith. And AI was pretty good to give me a rough idea of what the boundaries would be. So it's not like AI cannot do system design. The the only difference is the level of quality and the number of iterations that you need. So the difference between a skilled engineer and a very less skilled engineer, it's in with AI is that they can both build a thing.

But the engineer that's skilled will build it in a lot less iterations. Their first version would be as good as the 10th version of someone that's just vibe coding. And that's because they can think ahead. Now, for that, you need both low-level thinking, which is fundamentals, right? Understanding how components are built, how do you manage state? And high level system design, like scalability, where do we deploy it, what database we will use, how do we start?

So, I think you need both, right? It's just a lot of developers spend a lot of time coding, so they probably feel like the biggest gap is system design. But again, you cannot have 15 people doing architecture in a company. Somebody would have to build features. So what companies expect right now is that you are end to end. And talking about mindset, Bogdan, question number three. What's the biggest mindset change software engineers should make in the age of AI coding?

And I'm very interested in what's the main difference with 5 years ago when most of the coding was done manually. So, because AI brings implementation time to almost zero. You can print out components and functions almost immediately. The the time kind of switch and right now you spend a lot more time making decisions. About how should we write our CSS, how should we host our design system? Whereas back in the days you'd make that decision and then you disappear for three months and kind of manually run through the change.

So, for example, if today you want to migrate from client side rendering to server side rendering. You can do that in a day or two with a powerful model like Fable. As long as you have tests in place. So, the engineer now becomes more like a chef where you have all these lined cooks that they're cooking. And you define the menu, but then you also go and check that the quality of what comes out is exactly as you need it. And if the quality is not as you need it, you know the root cause effect. Hey, they are not they overboiled, whatever, the potatoes, or they overcook the meat, and you can immediately go in and adjust and give them better instructions. Because you got to think of them as a lot of people say you can think of AI as a junior engineer. That's not true. AI can do things that not even seniors can do. It's just a more a a robotic executor. So, you will be responsible for both the low-level quality and the high-level assembly of those two. Whereas, in the past, we were working more kind of in the middle. So, if this was your average day, you would do a bit of thinking, design, okay, like what do we need to build? The scope was very small, so you didn't need to spend that much time. And then maybe you'll do a bit of QA testing and rewriting, and a lot of it was just implementation, right? Whereas now, with AI, it's pretty much the other way around for very good engineers, where this implementation time kind of shrunk. But if you're if you want something with quality, if you want something reliable, you do a lot more thinking, a lot more analysis, and a lot more review. And I know, you mentioned that right now you're not building the software, you are building the software factory. Exactly. So, even if you're doing just front end, you will be automatically. owning a lot more systems. A lot of people think the work will disappear and we'll do the same thing that we were using, the same thing we were doing with five deaths, we're going to do with one. Yes, but the product requirements also change with AI. Users expect a lot more. And to deliver on that, you need engineers. So, I don't think that companies, companies that have a solid business plan are not laying off. People are actually hiring. But they want people that own a surface that's much bigger than what we used to own before, just because now you're not

limited by the implementation time. On to question number four, with AI, pull requests are getting so much bigger. I'm talking 10k or 100k lines of code. Do you still read the code in those cases and what's the best way to code review in the age of AI and massive pull requests? So when I think about pull requests, back in the days we used to review code, but right now, a lot of the code it's there's too much code. So the number one thing you want to look at it's uh interfaces, that means pretty much any API you might have. But also low level things, like types between modules, then you want to look at module boundaries. Kind of a higher structure of how code is organized to understand the blast radius of changes. So, most of the times if you're just changing something in a small module, you don't need to go so deep with the review. If that module exposes a clear API and you have unit tests on it. Um and finally, I pay a lot of attention to the data and in this case it's all about the schema because data it's probably the most important thing. You can always change the UI and how you show that data, you can iterate on that after a whiles. The blast radius of a model not opening well, it's limited, but if you mess up something in the data or data persistency or your caching layer, then things can go very wrong. So the attention kind of switch to the quality gates and boundaries between the actual business logic and the code that that runs. So if I understood correctly, before doing an in-depth code level code review, let's say, you first check these things. You check the interfaces, the API, types, like module boundaries, data, probably the testing as well, the tests, and then you decide whether it deserves a more in-depth human code review or it's good to go. Exactly, and a lot of people are throwing around numbers about lines of code. But it really depends on the application you're building. If you're building with React, it's very easy to change a lot of declarative JSX code and it looks like you made a big change. But you go to the back end and sometimes two lines of code can destroy the whole functionality. So lines of code I never a measure of impact or important.

ordans, or even the size of the change. You could make a one-line change that's more impactful than some bad thick lines of code. And now that we talk about interfaces, question number five, right? With AI, generating code, it's a lot easier, but generating quality code in the first prompt or second prompt, it's a lot harder. Right, so what kind of tools and frameworks are you using to generate quality code without getting lost in endless loops and burning tons of tokens? Well, there's a lot of talking about how you should prompt on the model and prompt engineering, which part of prompt engineering, it's what they call agent skills, which are just reusable prompts at the end of the day. But in reality, the biggest quality differentiator, if it's if you give the model or the model with the agent, because nowadays models work recursively, if you give them a good thing to work against. So usually, that's either your test or your API definition. If this API is good and they have a good database schema, the model is really good at interpolating between these two. So you need to give them what we call the the verifier, right? Okay. Now, there's different skills. I usually recommend to use a skill that is released by the official applications. So for AWS, I use AWS skills. For React, in this case, I use Vercel just because they own nextjs. So, whenever I'm coding, we're done with those, I do use the the the specific skill and I usually prefer user invoked skills that they can control. If you use model skills, the problem is your token spend will go through the roof. Uh, also keep in mind that a lot of those skills, if they're very any good, they are already added into the harness, cloud code. I integrated a lot of that. But again, the biggest difference, it's always the verifier it works against. That's why we always work at the interface and that's why you want to have uh tests. Now, a quick note, a lot of people are saying that you should do TDD with agents. But the reality is that models are very good at writing code without unit test. And what I've been doing lately, it's you write the test at the end. So when you are iterating, you spend a lot

lose tokens in a lot, lot less time. If you have models writing tests every time they make a change and then doing it again, but you're maybe you're not sure of how things should look like in the end and you're changing them around, you're just spending a lot of tokens. So also be careful because models are not, LLMs are not humans, and how we code as humans is not necessarily going to be the same thing on how you code with an LLM.

And TDD, I believe it's one of those examples where people are like, oh, TDD is going to improve your quality when you do AI coding. I'm like, no, it it used to improve your quality as a human, yes, but not as a necessarily as a model. End-to-end test on the other hand, that might be better. And for the folks watching us, if you want us to make a more in-depth video about any of those aspects, like testing in the age of AI coding or proper code generation or proper techniques of working with AI, just let us know in the comments.

Also, if you are looking to become an AI native senior engineer, which we believe are the engineers that are going to stay relevant and competitive in the age of AI coding, check the link below and see if you qualify for the mentorship Bogdan and I offer, which will help you achieve exactly that. And we will see you folks in the next one.