how to get to Senior Engineer in the age of AI (step by step)

What is a senior engineer in the age of AI? Well, the definition of seniority in this new age of AI is how much can you push back on AI code or solutions. And to clarify that, this does not mean seniors don't use AI, but it means that they use critical thinking when they evaluate AI code. They don't just auto accept and push that to production. They know that there's different ways to do a certain problem and they know that there's a lot of gaps in the AI reasoning. So they can see those gaps and they can work with AI towards much much better solutions than somebody that's maybe at the junior level and they just take the AI output for granted. >> Can you give me an example of that? >> Well, a very good example I could give you is the other day in one of the coaching calls that we have with senior dev with our mentees, I somebody was

presenting what they did around end-to-end testing. So they basically had a front-end application. They're complaining that there were a lot of bugs in productions and they couldn't catch them. And I told them, okay, let's cover your whole application with tests. They wrote around 750 end-to-end tests with AI. And the next week they came and presented it to me and they were super excited. And I asked them, well, okay, how are you marking your back-end services? Because this was a front-end application. So basically whenever you have your front-end and you run end-to-end test, you need to somehow call into a back-end. And those end-to-end tests are either in your local machine or you're in the CI/CD

pipeline. And they couldn't answer that question. They told me, well, I would need to look that one up. And the thing about how do you mark your services in the tests is that it's one of the first questions that a senior would ask. And the reason behind that is because if you just hard code mocks, let's say you add hard coded JavaScript objects and whenever you're you were calling the fetch API, you return instead those objects, the problem there is whenever you change your back-end, you need to refactor all your mocks, which makes what we call your test brittle. The second alternative would be that you visualize your whole back-end. But that means you also need to visualize your

back-end database. And that means you also need to visualize your whole authentication system. And it's complex and it's takes memory and CPU and you need a good authorization strategy. So I was very surprised when they were fast, and that's why I asked those questions. And so the level of depth that you can go into and the way you can design solutions with AI really depends on your expertise. For me, it's very funny because before AI, being a senior dev meant mainly having certain knowledge in different areas, like it was in your own domain, whether you're full stack or front end or back end, right? And then kind of generic software knowledge. But

now with AI kind of being able to retrieve that knowledge, right? LLMs can answer, you know, they have all the knowledge that was ever created about software engineering. It's about how can you actually use that knowledge and turn that knowledge into wisdom. But I guess the most important question is, okay, now that a senior is someone who can push back against AI code and AI solutions, what are the skills that allow senior devs and how can I learn them if I'm someone who wants to be a senior or if I'm a senior and I want to stay relevant in the age of AI? What should I focus on for me to become that engineer who can push back against AI?

>> Sure. So I will divide this into three buckets. And the number one skill that I feel like everybody it's underestimating, it's what they call low-level design. Now back in the days, uh we used to call this coding because it was about coding, writing components, writing functions. But nowadays with AI, you could as a JavaScript developer write Python code. And if you have a good understanding of your low-level design principles, you could evaluate that code. You could understand what are the boundaries of a function. You can understand if they applied solid principles. You could apply a a design

pattern and have the machine help you without the details, the syntax. Now there's a small parenthesis here. Different programming languages implement certain things differently. So the way, for example, Node.js would implement parallelization is very different than the way in which Java implements it. In general, however, a lot of the coding skills now move towards low-level design. That means looking at a piece of logic and being able to see through the cracks. And the only thing that changed with AI is that you can now switch programming languages. You can now switch platforms. So for example, if you are a front-end

developer, you could all of the sudden build a mobile app. But when it comes to the state of a component, the same mental models apply. When it comes re-renderings, if you use component framework and component caching or data fetching, the same mental models apply. So that's what we call low-level design. So I guess in this bucket of low-level design, for example for a JavaScript TypeScript like front end full stack engineer, it would be things like knowledge of JavaScript itself as a language, knowledge of the browser, then knowledge of programming patterns like object-oriented programming and solid principles, even some DSA, right? It's

kind of different buckets and that's why I guess makes it all confusing. It's like even within this low-level design category, what should I focus on first, right? And if you're asking yourself this, folks, bug then I created a free technical assessment. It's like 10 minutes. You just add your email and your name and you go to the questions and you're going to get in your email a full breakdown of how you're scoring on all the different dimensions including low-level design and fundamentals, right? And some guidelines on how to fix them. So go ahead and do it. Link it's in the comments. So first step to become a senior in the age of AI is to master low-level design.

What's the second step? >> Second step is being able to think in terms of systems, particularly software systems. So being able to understand what we call traditionally system design, system thinking and software architecture. And so the problem with those AI systems it's that if you build a feature with it, many times the solutions that it proposes are suboptimal. Now the reason why a lot of people accept the solution is because [clears throat] they couldn't build one either way. They didn't have a mental model of what that feature would look like, what are the three different ways you could build

that. And just as I mentioned before with the mocks, the reason why some people don't question certain choices is because they don't know any alternative. They don't know there's like five different ways to deploy an application. There's three ways in which you can mock data. There's different ways in which you can structure your test or what kind of tests you write. And so it's very easy to accept something if you don't have any other reference. So it's very important that number one, you have the low-level design mental models. You can read code really fast even in different programming languages, but then you can zoom out and you can look at your architecture and you can understand

what's going on here. The problem you'll see a lot with AI is that whenever you push back on a certain choice, it will either try to disagree harder with you or agree, but it's extremely hard for the models to really pay attention to the right things. And you mentioned before that there's a difference between knowledge and wisdom, but there's also another difference between information and knowledge, which is knowledge it's applied information in a certain context. Now, AI does a good job at giving you the impression that it has knowledge and wisdom. It will be very convinced and it will tell you, oh yeah, we're going to do this option and this option is going to be really good. But most of the times it will either fall into over engineering or giving you a very sub optimal solution that will not work and break in an XPI. So that's when the new engineering mindset comes in and really understanding why do we have

things like event even architectures? When should you build microservices or when should you consolidate your services back to a monolith? When do micro front ends make sense? And being able to have clarity on those decision will create a lot of speed because right now a lot of people are pushing PIs and everybody's talking about speed as a measure of PIs, but the best speed in software it's not building the wrong thing. Is that your first version doesn't need to be reworked next week with another 15 PIs. So in a way the way we measure productivity, it's also very flawed. I see a lot of people throwing

around pull requests and talking about lines of code which are extremely irrelevant. And if you're making, you know, 20 PIs a week, but you're not delivering new features and you look at your user engagement and they don't use the application more, you're actually working against yourself. How can a developer who's mostly a meat, maybe they have the senior title, but they are kind of this feature oriented developer go from thinking in features towards becoming more of a system thinker? What would you tell them to do? What I would do is to try and gradually increase the scope of your work. So the fact that

you're competent at mid level usually means you're really good at building a certain application, you're really good at building components here. I would delegate that to AI as much as possible, building quality guidelines around it and then use the time I have at hand to start building across the stack, start making end-to-end choices. And there's this trick that you want to make, which is always ask the five whys. And so one of the things you can do with models, and you can see the limitation of models, it's when you start questioning their choices. And like, okay, why would you do that? And why do we need that? And most of the times you end up with a

much simpler solution. So those would be the the quick wins. We do have a lot of videos on our channel about system design and architecture, so make sure you check those out because you need the mental model in order to be able to make decisions. Finally, because most people are using these skills that are actually asking the five whys to the developer, and basically the model will just throw questions at you until you get brain fry, and the solution might be the opposite where instead of depleting human energy, you attack the model and you kind of make it question its own premises. And the model is the suspect here. Okay,

Bogdan, and what would be the next step for senior engineers in the age of AI? >> I would say the last one is being able to think in what we call second and third order consequence. And so what happens a lot with junior developers or people that are just vibe coding is they would take whatever the model tells them as face value as well. This is amazing. Look at it. We already fulfilled the functionality. But when it comes to software, whenever you're building software, if you want something that's scalable and maintainable, you want a lot of simplicity. And simplicity in an implementation is the result of very hard thinking. The first solution is usually the most complex you'll ever build. A lot of what you do as a senior with AI, it's trimming down the solution, simplifying, removing unnecessary edge cases, removing

unnecessary over engineering. And you can only do this if you understand what is the consequence of adding more code to your codebase. What is the consequence of adding more features? And you understand that you need to maintain that. To give you a quick example, back in the days there were a couple of CEOs of very big companies bragging about the fact that they would not use JIRA anymore. They'll vibe code their own JIRA. And that's a natural tendency. You're frustrated with the software product and you're like, we're going to replace it. We're going to build our own. And that's really cool until you realize 6 months later, instead of building a product, engineers are busy fixing bugs on their ticketing system, which you could have poked at a fraction

of a cost that it cost you to have those engineers working on it. So, that person, for example, he got really excited about that first version of something which tends to be really good with AI. I really feel like they optimized the model for the first prompt, but then they didn't think in the terms of, okay, now we're going to integrate this, we're going to have to maintain it. Is this really worth it for us? Is this what we're getting paid for?

And that's where I believe a lot of things I've been turned around. A lot of people are saying why you just need taste with AI, like you know, you just need to understand color theory and that's how you're going to build great software products with AI. And I think when it comes to taste and what they call taste, it's actually intelligence and intuition in all the different domains and software engineering is one of them. For the folks watching us, if you are a front-end or full-stack engineer and you want to level up to senior or if you are a senior engineer already and you want to stay relevant in the AI age and you want to master low-level design, you want to think in systems, not features, and you want to

understand the second and third-order consequences, then check the link below. We have a free training that shows you exactly how to do that. And if you want Bogdan and I to personally help you get to that senior level with a in-depth technical assessment, a custom roadmap, and direct mentorship from him and I, then book a call with me and let's see if it's a fit and if we can help you. Thank you so much, Bogdan, and we will see you, folks, in the next one.