how frontend devs can stay RELEVANT in 2026 transcript

So, for the most part, back in the days, back in the old days, we'll spend some time refining and doing product prioritization, refining, and writing out tickets. That would be the specs. And then, we would start our product increment, sprint, basically implementation phase. And that used to take the longest amount of time. And after that, we do some testing and finally deployment. So, a lot of the front-end work that we used to do before 2024, before 2025, was a lot of implementation.

Basically, writing components, getting the UI from Figma, or whatever the deliverables were, into making functional and releasing. And so, a lot of developers that work to that phase, they probably have a lot of skills building components, making components look pixel-perfect, making them responsive, accessible, and ideally a bit about web performance and whatnot. With AI, what happens is that this implementation phase shrinks.

It's almost instantaneous. It takes minutes to implement your average component. And Cloud code can build features that used to take us 2 weeks in a couple of hours. And so, nowadays, we spend a lot more time defining the specs and doing what we call context engineering. And we'll get that into a wide. And then, there's a lot of testing and verification. Because those models, even if they are great, it's easy really easy for them to go into the wrong direction.

So, you still need a human eye on the output. Now that the implementation phase shrunk and is basically done by AI, what do those front-end engineers do? Let's break it down in pieces. So, number one, you will have to do more across the stack, because the surface of the changes you can own it's much bigger. Now that you don't spend so much time doing the component itself. Number two, you'll have to care a lot about what we call context engineering and guiding the AI, making sure that the output that you get from AI it's of high quality.

And I know a lot of people are talking about skills and how to talk to the AI. That's not engineering, okay? That's folklore. What I'm talking about it's sitting up for example a design system so that the changes you get are visually consistent. Or changing the state management architecture of a specific feature to make sure that you need to make less code changes to get the same output. So you still need hardcore engineering skills, but you don't need those skills because you will write the code.

You need those skills because you'll instruct the machine how to write the code and you need to make sure that the quality that comes out it's good. >> Okay Bogdan, so if I'm a front-end engineer and implementation is now mostly done by AI, it's not so relevant. What should I do? What should I learn? What should I What should I focus on? >> The number one change I would make it start going a bit deeper into the full stack.

Because if you look at job descriptions even front-end engineers in 2026, around 76% of them mention REST APIs as a skill. 60% of them mention AI. So you are expected to own a bigger surface of changes. You are expected to also do a bit of back-end or extend the back-end for front. Number one thing you need to learn a bit about REST API design. You need to learn how to get your changes live with those CI/CD and cloud.

You don't need to become a DevOps engineer overnight, but you should be able to get your applications to production with production grade orchestration and monitoring. And a bit of data modeling. You probably did some data modeling cuz you're doing state in components, but I'm talking about data modeling when it comes to persistence into database, right? Now again, this is for you to be able to deliver on those on that surface, not to be the subject matter expert.

So you're not expected to be the DevOps engineer or the back-end engineer, but you need to deliver across the stack. And if I were to start and in terms of priorities, I would always start at the very top layer which you're probably familiar with the presentation layer and then start getting deeper into okay, now let me learn a bit about API design and HTTP. Finally, business logic which you probably already know because we do a lot of business logic in the front end and when we write components and the persistence layer which is usually for the most part it's relational databases.

Okay, there's a lot more to it but if you know relational databases and you should be more than fine. But you definitely want to be able to go from this presentation layer where you are stuck and kind of make sort of a triangle. Like and that's why you are able because you know a bit of the persistence layer, you know business logic, you can extend the API and that's how you're able to sell yourself as a full stack developer that's very front end heavy.

The second thing and not least important it's front end fundamentals. So as I mentioned a lot of developers, a lot of front end devs were focusing a lot on building components. But when you build components you don't have time to touch the things around your components like web performance or building a design system or getting deeper into the architecture of the whole app when it comes to state management, component state or front end architecture like monorepos or micro front end architectures.

So because you're doing a lot you had to ship things and you had to push out turn out features there was no time to get into this. So when I ask a lot of front end engineers that we work with what were your responsibility most of them get stuck into the ticket farming model where you're just turning out features. And the problem is nowadays you go to interviews most companies will require you to be able to build the whole thing to be able to define the architecture.

And so you want to get deeper in the front end. Okay? Now, instead of doing instead of coding the fifth component or the component number 115 you actually want to look around building components like tooling, code quality measures, all that. Would it be too much if I say that the average let's say the the mid-level front end engineer these days needs to know what was considered senior just a few years ago. >> You could say that.

But, that's only because seniors were faster building components, and they had time to care about these things. Right? And now what happened is we all been displaced there. Every front-end engineer now is fast with AI. As long as you do this specification phase in a high quality, you can just give you the code, which is usually faster. A lot of people complain about code reviews, but let's be honest, in the front-end usually generate a lot of code, but not all of lines are super meaningful, cuz you have a lot of markdown.

So, now you can go much faster. You are in a way a senior because you code these components faster. So, the bottleneck moved to those transversal topics, like architecture and web performance. And then, of course, you need to add AI skills to your skill set. Now, again, you'll never be asked to build a model yourself. So, there's people that I see there like, "Oh, I should learn Python, and I should be able to build a large language model." That's not the case.

But, they should know the basics of context engineering, how to set up an MCP, how to define agent skills. A lot of companies are Most companies actually are defining their own agent skills, and they want you to be able to maintain it. And also, how to do a decent harness design. And harness design is basically building software around the model to make the model more reliable, to make the output more deterministic. And there's different ways to do that.

I'm not going to get deep into it. But, this will allow you to market yourself in today's market. A lot of people are still marketing themselves like it's 2020, and it doesn't work. And then, they go ahead, and they see the market is cooked. It's not cooked, but it definitely changed. >> So, if I understood correctly, Bogdan, the the main skills are context engineering, which is an intact section of different skills.

Then, there is the testing and verification part. But, the biggest change in paradigm, from what I see, yeah, and you can correct me if I'm wrong. The biggest change in paradigm when it comes to front-end engineers is that the code code is not the focus anymore. It's not the center of attention, cuz you you used to build skills around code, the code itself, and components, and now you're building skills around the model that produces the code.

Or not. And the core skill to that is being able to guide and constrain the AI agent, which we call context engineering, which which is actually a sum of different disciplines that come together for you to be able to better guide the AI. Why not? The paradox is to guide the your ability to guide the AI is proportional to your skills. So, even when AI vibe coding, you'll see front-end engineers getting much better results than a back-end engineer.

So, a lot of people are saying it's about creativity. I dare to disagree. I think if you understand the code and you understand how components are built together, how state management works, your first version of a thing will be much better than the 10th version of somebody else. A civilian, let's say, a back-end engineer, let's say they want to vibe code some front-end, they will realize they need to take care of performance, of web performance, where the bundle size way deep into the project.

Whereas a good engineer in the front-end has already solved all those, because they can specify that and verify. So, I don't think code is going away, but I think code is transforming and coding into what we call low-level design. Where you go into a component or a custom hook and you just look at the design of how it works, and then you zoom out. But then, you don't have to write that component 50,000 times. It's going to be the AI that does it.

So, in the best way you can use the AI as a way to scale your judgment. And context engineering and skills is just your ability to really scale yourself using an LLM. If If I start coding tomorrow with AI and you start coding tomorrow with AI, and we have roughly the same goal, to build the same application, to build a senior dev platform, where do I make more mistakes than you? You probably waste more tokens, and your final result will have more bugs, and your design will will have lower fidelity.

Because you are just fighting the spaghetti code with a model. Whereas a good engineer will be like, "Wait, okay, let me define a from these requirements, let me find a design system. Okay, I already solved the visual coherence problem before I get into the implementation phase." It's not because they sit down and they install a skill. We talk about anticipating problems. And pointing the model in the right direction from the beginning.

Yeah, what will happen with you is that you'll probably learn along the way. You'll make a mistake with this shitty software, learn about web performance. Whereas an engineer already knows. And what companies will pay for is reliability and quality. Cuz if not, you're pushing the pressure, you're putting the depth the technical depth now is going to be on the users that discover all this all these bugs and then they send it back to you and you can solve them.

So, the problem is not anymore can you do it? It's how fast can you go to the market and how good your quality will be. So, what would be the difference between a vibe coder and a professional front-end engineer in this case? Well, it's the same difference if you give someone a a camera and you give a photographer a camera. They all have the both technology and the person the random person with a camera might even shoot some good pictures.

But the photographer from 10 pictures they they won't and that great photographers don't press the shutter as often. They would wait, they'll look and then they get one picture that's great. Whereas somebody that's still learning, they're just shooting and shooting and shooting like, "Oh, this one, this one." But they don't really know what they're looking for. They don't really know the rule of thirds. They don't really know composition or color contrast.

And so, there's a difference between going into with intention and just brute-forcing your way into a problem. You can get to the result with both of them, but it's going to take you a lot longer. And you will put the debugging effort on your users, which will probably in most cases you'll end up having some refunds where people will switch ship because your software feels buggy. So, when you think about the front-end engineers of the future, instead of spending their time, most of their time with implementation, right now they spend most of their time in the what we call the contest engineering part and the specs, right?

Where they are able to point the agent, the AI agent towards the best possible solution faster, right? And then partly in that test and verification spot, right? And it's this intersection of full-stack skills and good fundamentals and AI knowledge, the intersection of of these three disciplines that will make you better at contest engineering and much better at testing and verification. >> Exactly. And so, if you think back in the medieval, they would build these cathedrals and none of them were engineers.

So, it was a lot of experimentation. And what would happen is a lot of them would break and demolish. And it'd be trial and error, and then they would pass this verbal knowledge to the next person. Very similar to what people are doing now with skills. They're like, "Oh, today I did this skill." But none of them could really tell you what's going on. And then came the age of engineering. And right now we can build much cheaper than they used to build and much taller because we have mathematics, fluid mechanics, physics.

So, the modern engineer is not going to build skyscrapers skyscrapers and see which one doesn't fall down and then copy that one. It doesn't work like that. They know the principles, they know the physics. Now, do they sit down and calculate every single joint and what the pressure is? No, they'll pass those requirements into a computer automated software and then it kind of does the the the low-level calculations, right?

So, they definitely use a lot of automation. It's not like they sit down there. But when it comes to thinking about how the application, the thing you're building works, they know it in and out. They can zoom in and make the low-level calculation themselves if they had to and then zoom out. And it's pretty much the same transformation. >> Okay, Bogdan, but assuming everybody masters these skills and we have LLMs doing most of the implementation, one good front-end engineer can do the work that 10 front-end engineers would used to do or maybe five, right?

So, will we need as many front-end engineers in the future, I think? >> Yeah. So, I think that's a valid concern where people look at, "Okay, this is the application and we used to have 10 people building it and now one person with AI can do it." But, the reality is what's happening is companies are building projects that they were not capable of building before. So, good companies, the ones that have solid financials, usually are actually hiring more people.

I would say the layoffs came mostly from people that over hired, but the same engineer can now own a much bigger surface. So, you can think of someone that used to be a front-end engineer and they would own a feature, now they can build the whole application with product. Somebody that owned a whole application could actually build a mobile application that maybe they weren't able to building before because the budget wasn't there.

So, what happens when you add AI to the equation is that everything changes. Not only the what were you building before, but also all the new possibilities. There are things that were just impossible or you just weren't worth investing in and we are building today. You will notice in the way we're building a lot of infrastructure that I wouldn't even be able to dream about a couple of years ago because it would take me the the hard work of sitting down and writing everything by hand.

So, I would say a lot of people mention Jevons paradox. There's definitely truth in that, right? And the moment something becomes cheaper, we usually you use more of it and you'll see software expanding into niches and categories where we weren't able to build software before. And the existing software will go deeper and ideally will be of higher quality, at least in the long term. So, for every front-end engineer watching us asking themselves, "What should I focus on for me to stay relevant and competitive in the future?" You should focus on front-end fundamentals, then on full stack engineering, and then on AI agentic coding.

And the best way to know what your gaps are in each of these categories, it's to take the free assessment that Bogdan and I put together. Check it out in the comments. You'll go through a bunch of questions for 10 minutes and it'll give you a full overview of where you stand in all these different skills. And if you also want Bogdan and I to personally help you close these gaps and become an AI native front-end engineer, then check out the free training where I explain exactly how our system works and how you could actually work with us for you to become that front-end engineer that AI cannot replace.

Thank you, Bogdan, and we will see you folks in the next one.