1. Using AI for Everything
Relying entirely on AI agents without understanding the generated code creates a paper tiger skill set, leaving engineers unable to explain choices or debug basic problems.
Watch section from 0:31 →Engineering video
14:21 · 3 November 2026
Relying entirely on AI agents without understanding the generated code creates a paper tiger skill set, leaving engineers unable to explain choices or debug basic problems.
Watch section from 0:31 →A career built on knowing just enough to get by leads to ticket farming and superficial knowledge, causing engineers to blank out on deeper conceptual questions like web performance.
Watch section from 4:43 →Siloed company structures prevent developers from handling the full software lifecycle, restricting their ability to see code from the ID all the way to live production and observability.
Watch section from 7:08 →Staying at the same company for too many years can make developers hostages of a single tech stack and domain, limiting their ability to transition or pass outside interviews.
Watch section from 9:47 →Engineers often internalize past rejections and fall into passive ticket farming, whereas true seniors operate proactively at the border of the possible and allowed.
Watch section from 11:59 →If lately you've been told in a technical interview or a technical discussion that you are not senior enough or if you feel like you're just a senior on paper like you have the senior title and you have a senior engineering salary but somehow you don't feel that senior level confidence to lead technical initiatives architectural meetings to deliver end to end when your team needs you. In this video together with BDON we will go through the five reasons why you feel like you're not senior enough and how to fix them quickly. Barton, so what's the first reason why even experienced engineers feel like they are not senior enough? So
the number one reason is using AI for everything. And so a good example would be front-end developers that ship fullstack features, but they don't really understand the code they are shipping. They cannot explain why they took a specific choice. So if you open the pull request and you walk through the files, they are completely buzzled by the code. They don't know what's going on. And that's why we say that their skills are a paper tiger because the moment they'll go back to the market or they try to interview and they get asked any false question and that's where you see the reality of where they
are at. And so what you don't want to become it's as they call it a mid proxy to the AI. You want to bring real expertise to the table. You want to be able to drive the AI and maybe use it but you are the engineer making a choices. You can guarantee the outcome and you are the one ensuring quality. Bordon, this is not easy to do at all, right? And because number one, companies are pushing developers to use AI as much as possible. Like we have some mentees right now and they're going to interviews and they're being told, hey, you cannot code. Like that's number one. Number two, I talked to a lot of developers who learn how to code after
2022. And these people, they've never done the manual coding, you know, they jump straight into JPD and cloud code and whatever. So for them, there is no development without AI. They have such a dependency that they developed with these systems. And number three, I think these systems, AI agents are very good at making you feel smart and at filling your gaps because when people deliver something with AI, they're like, I delivered it. You know, they make you feel like you were working with the AI and finding your path, but in the end, AI has been writing like 99% of the code, right? And you would not be able to do that without the system. So, how
can these software engineers kind of say stop, you know, I'm going to use AI, but I need to get back to hands-on coding, which some of them maybe they never did. So to answer question number one, yes, it's a subset of companies that are asking you to use AI for everything, but it's usually startups and it's usually smaller companies. The vast majority of companies, even in today market, they will make you code live before they hire you because it's the only way to guarantee that you know what you're doing. You need to make sure that even if you're not writing code every day to deliver features, you are writing code every day to build your judgment. Now, you don't need to necessarily go in and build a feature. You can just review the code. But you want to set aside 30 minutes every day and solve a simple coding problem by hand. It can be a lead
code style. It can be a simple JavaScript problem where you build a couple of promises or you implement debounce, but you want to use coding to keep your reasoning sharp. And to answer your second question, how do I get better if I've been writing code with AI? Well, again, it's pretty much the same. you want to remove the wheels. It's like when you start riding the bicycle, it gets to a point where you want to remove the wheels. And as a senior, you'll get to the point where you'll see that the wheels even slow you down. So, it will get to a point where there are certain things you'll start doing by hand because you will end up with a better solution faster than if you back and forth it with AI. If you feel like the outcome you get from AI is really good, it's usually because you're tackling something where you're not an expert in. So the outcome feels expert
level. But as soon as you get proficient at something, you start seeing how AI makes mistakes. And as you mentioned, that's why people think AI does such a great work because they usually use it for things where they're not a subject matter expert. So it feels like, wow, look at that. That looks really good because they lack the judgment to really tell where the cracks are. And so the solution is to make sure you do code every day. Even if you are not doing it on the production codebase, you do have some focused drills. You can do that by solving algorithm or lit code style problems. If they're very intimidating, start with the easy ones. But make sure
you are on the keyboard every day. You are not detached from writing code because as an engineer, even if you don't have to write code every day, that's how you build your judgment. The resistance, the fact that you go a bit slower, it's a good thing. It allows you to think and it allows you to learn. And that's exactly what you want to be investing in. A lot of people don't do that. then they find themselves in the market and they need to compress six months to one year in a couple of days because they have a live coding interview and they cannot even write a for loop by hand anymore. So make sure you code every day even if you're not
doing it for the production application where you have the agents writing the code and you are more of a reviewer. The second reason why even experienced engineers feel like they are not senior enough, it's weak fundamentals. And this is very obvious back then when I talk to selftaught engineers who learned just enough to get their first job and then in the first job they learned just enough to do the second job and then you know 10 years go by and they had a career that was built on knowing just enough to get by and they've been accumulating huge gaps in their fundamentals that they never faced. So exactly a lot of people know just enough
to get by and it's usually enough to deliver features and do what we call you know ticket farming. Especially with AI, you can get even faster. You can do more. You can ship more while doing less, which feels really good. But at the end of the day, your knowledge doesn't really grow. And the usual symptom here is that people find themselves knowing only the superficial level of things. They know how to do certain things in React, but you ask a specific question about JavaScript or the event loop and they'll blank out. They know how to use these higher level libraries that we use on a day-to-day basis, but they cannot really go in
depth. And what happened lately in the market is that because everybody's claiming to be senior and everybody has years of experience, what companies are looking for is depth. So when they interview you, they will go deep. A good example is in a typical front end interview, they'll ask you about web performance. A lot of people know the core web vitals and they'll be like, well, there's like the LCP and the IMP and the CLS. But the interviewer won't stop there. They'll dig deeper and they'll ask you, okay, can you define the CLS? Can you tell me why it happens? and can you tell me what can you do in
order to prevent it? And if you've been just using AI and just doing enough to get by, you will just blank out or you'll give a halfass answer. So, in order to fix this, you want to really look at your knowledge and find those gaps because everybody has different gaps and then you can be strategic and execute exactly on those. Now, there's a lot of information out there and there's a lot of people saying, "Hey, you should learn the fundamentals and learn this and that, folks." And that's why Bogd and I put together a free technical assessment for you. You can just check the link in the comments. It's 10 minutes. It will give you a full overview of what your gaps are on the
full stack, not only on the fundamentals. And then the first step would be to look at the fundamentals and understand, okay, what are the questions I'm struggling with and what are the concepts behind those questions. So feel free to go and check it out. The third reason why even experienced engineers, senior engineers feel like they're not senior enough, it's red tape in their own company. And that means uh companies are very seoed sometimes. In many companies, for example, if you're a front- end engineer, you don't get the chance to set up any kind of deployment infrastructure. >> Exactly. So most people do not get end
to end exposure because they are not responsible for the deployment all the way from your ID from your code editor to being live in production and being able to debug that. Usually you just merge to master and there's some magical steps and then it's in production and if you need to roll it back, usually you need to talk to someone that's more senior and help you out. uh in many companies there's also like a devops team or a platform team that already build all those things up. Maybe you need to change one line here and there. You might have changed the configuration of your CI/CD pipeline uh 6 months ago.
But you then get this end to end filling where you should be able to intervene in any software life cycle phase. You should be able to change your CI/CD pipeline or have an opinion about what are the code quality measures you use and then when you get it to production you should be able to understand what kind of artifacts you deploy to production how do they run in the cloud environment what kind of cloud services you're using so that's the exposure you need and you need to consider yourself almost like a CTO where you are the ultimate person that has to know every single thing has to be able to run the
system and very important like senior engineers don't wait for permission sometimes to go and grab things and get them done, right? They operate at the border of the possible and allowed. Exactly. So, you really want to try and bite as much as you can chew and expand your knowledge. Look for bread. Look for the things that usually you're not allowed to touch. And it all starts with product. What I would recommend everyone is to try to get bigger features or try to be the one responsible that's actually deploying and getting things in production because that will force you to really go into the observability and monitoring platform and really get the whole knowledge. So you want to make sure that you can get in a room with a product manager and a couple days later there's high quality production software running and you are responsible for
every single step. Would you recommend um people in this situation to switch teams for example if they get the chance in a big company? I think switching teams helps if it also comes with the switching position. If you're a front end dev and you get another front end def position and the APIs you're consuming are pretty much the same you won't learn much about end to end but if you get more on the full stack or you get to start a specific feature from scratch that's when it's really good. So you want a bit of variety especially after you're pretty solid. Let's say you've been at what you're doing for a while and it's getting kind of boring. Instead of staying there and coasting,
you want to use that time to expand, to become more broad. Reason number four why even senior developers feel like they're not senior enough. This reason can feel very similar to the third reason which was too much red tape. But this is about company specific knowledge. So even if you know everything about the tech tag that your company is running, you know, after 5 10 years of experience, you might need something else. Exactly. So the problem here is you'd only learn one way of doing things and so people go to interviews and they get asked different questions and the references they give always come back to the same company or they only have one reference and they only know one text tag. They know how to do it with Noode.js and React but they cannot give an opinion for something that's outside of what their company is using every day. Uh the other problem is whenever they go to the market they will
talk in terms of the deployments in their own company or their product. So it's also a domain knowledge problem. You only know the domain knowledge of your company and a lot of people end up being hostages of the company because it gets to a point of no return where you've been there for 9 years and you're not good enough to get promoted but you're also not good enough to get another job at the same level and that's a position where you don't have a lot of options. So that's why as a solution I would propose everyone to either switch companies once you've been there for five to seven years. You either get promoted which is almost like a company switch or a job switch or or you try to
get that experience from outside your company either by going to a meetup or participating in some sort of an open source project or you can even do volunteering where you look for a nonprofit and you build a website for free and maintain the infrastructure. It usually doesn't take too much work per week, but it will allow you to get more references. And as a rule of thumb, right, we tell the software engineers we mentor that after five to seven years in the same company, even if it's a good company, you might have to think about switching with 7 years being the maximum time you should stay in one company. And
I know a lot of folks are saying, "Yeah, but the market is bad. I don't want to go into the market. I I would rather stick to what I've got." Um, yeah, but there's a price attached to that, right? And there's an invisible price attached to just being in the same place for a long time. And finally, reason number five why even senior engineers don't feel like seniors. It's because sometimes engineers are afraid to take the lead. And this starts at a very early level when you're a junior and you join a company and you're just fluting everybody with proposals. Let's do this, let's do that. And you just get told no, no, no. Because of course you're a junior, you don't know a lot of different things. But what happens is
engineers interiorize kind of those nos. And as they move towards the senior level, they just kill the productivity. They forget about being proactive altogether. >> Exactly. And the problem here is that they fall into just ticket farming and coasting. So that means I just execute on whatever the product backlog is and that's pretty much it. And over the long term, what usually happens is there are some layoffs or you find yourself again on the market and you pretty much forgot how to do your job. And the solution there is to really take initiative. And so for example, one of the things that we tell all the engineers we mentor is if someone comes in and they're like, well, I don't know testing because we don't write any unit test. The reality you can start unit testing your features tomorrow, you can set up the testing infrastructure for end to end testing tomorrow. You can use AI to go faster
while you still understand every moving pieces. Once you have the fundamentals of testing and the mental models, there's nothing stopping you for improving your production systems. And most of the times you don't need to ask for permission. You then need to go to your manager and propose it and try to get a budget. You can do that on the Friday afternoon when you have enough time. Just pick something that's broken and fix it. And if you do that every single week, you won't even believe where you are in 12 weeks. And that's something that a lot of the developers that come into our mentorship program struggle with. It's understanding that technical knowledge alone will not make
you a senior, right? It might keep you at the mid level uh for a very long time, but a senior has initiative, right? technical initiative, product initiative, organizational initiative and you have to get into the habit of building that kind of initiative, right? And that's why we tell people, hey, your success, it's yours. Your career, it's yours. You cannot expect the word to give you what you have to go out there and take yourself. And for the software engineers watching us, if you want to learn more about how to become a proper senior engineer in this AI age, then check out the free training in the comments where I go much deeper into the exact steps you have to be taking for you to become that AI native senior fullstack engineer. With that being said, Balden, thank you so much and we will see you folks in the next one.