So, for the most part, back in the days, back in the old days, was spent sometime 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 the 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, whatever the deliverables were, into making it functional and releasing. So, a lot of developers that worked 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 what not. Now 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 two 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 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 shrink and is basically done by AI, what do 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. Make sure that the output that you get from AI, it's of higher 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 setting up, for example, 80 designs.
system, so that the changes you get are usually 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 hard core engineering skills. But you don't need those skills because you will write the code. You need those skills because you will instruct the machine how to write the code and you need to make sure that the quality that comes out, it's good.
Okay, so if I'm a front end engineer and the implementation is now mostly done by AI, is 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 of 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 backend or you extend the back and for front end. Now one thing you need to learn a bit about rest API design, you need to learn how to get your changes live with the CI CD in cloud. You don't need to become a dev ops 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 because you're doing stating 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 backend 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 frontend and one-way right 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, 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 persistent layer, you know business logic, you can extend the API. And that's how you are able to sell yourself as a full stack developer that's very front and heavy. The second thing, and not least important, it's front and fundamentals. So as I mentioned, a lot of developers, a lot of front ends, we're 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, not just component state. Or front and architecture, like monorepos or microfrontend 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 have time to care about these things. Right? And now what happened is we've all been displaced there. Every front end engineer now, it's fast with AI. As long as you do the 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 because 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 that 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 into 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 say the market is cooked. It's not cooked, but it definitely changed. So, if I understood correctly, the the main skills are context engineering, which is an inter section of different skills. Then there is a 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 is not the focus anymore. It's not the center of attention because you you used to build skills around code, the code itself. Then components and now you are building skills around the model that produces a code, or not.
The core skill to that is being able to guide and constrain the 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 the vibe coding, you'll see front end engineers getting much better results than a backend engineer.
It's a lot of people are saying that 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 everything will be much better than the 10th version of somebody else. A civilian, let's say, a backend engineer, let's say the one of vibe codes I'm fronted. They'll realize they need to take care of performance or web performance where the bundle size way deep into the product.
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. Well 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. In context engineering and skills, it's 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 the 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 this spaghetti code with a model. Whereas a a good engineer will be like, wait, okay, let me define it from this requirements, let me find a design system. Okay, I already solved the visual coherence problem before I get into the implementation phase.
is not because they sit down and they install the 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 the mistake, read this shitty software, learn about what 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 tinkle depth now, it's 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. What will be the difference between a vibe coder and a professional front end engineer in this case?
You can see 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 the random person with the camera might even shoot some good pictures. But the photographer from 10 pictures, they'll they won't great photographer is done press the shutter as often. They would wait, they would look and then they take the one picture that's great.
Where as somebody that's still learning that's just shooting and shooting and shooting and 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 it 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 the implementation, right now they spend most of the 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 towars the best possible solution faster, right? And then and verification spot, right?
And is the intersection of full stack skills and good fundamentals and AI knowledge? The intersection of of these three disciplines, they are that will make you better at context engineering and much better at testing and verification. Exactly. 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 would be trial and error, and then they would pass this verbal knowledge to the next person. Very similar to what people are doing, you know, with skills. They're like, oh, try 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 three 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 you sit down there. But when it comes to thinking about how the application the thing you are 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 used to do or maybe five, right?
So, will we need as many front end engineers in the future? So I think uh 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 the 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 play people. The lay of came mostly from people that overhired. 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 own a feature, now they can build the whole application with product. Somebody that own a whole application could actually build a mobile application and maybe they weren't able to building before because the budget wasn't there. So what happens when you add AI to the creation 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 just weren't worth investing in. And we are building today. Even at the senior, they were 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 Jevon's paradox, there's definitely truth in that, right? And the moment something becomes cheaper, we usually use more of it. And you'll see software expanding into niches and categories 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 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 and 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 Bug and I put together, check it out in the comments. You'll go through a bunch of questions for 10 minutes and it will give you a full overview of where you stand in all these different skills. And if you also want Bug 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 Bug and we will see you folks in the next.
next one.