Engineering video
15:15 · 7 July 2026
Focusing on frontend architecture rather than backend concerns to establish clear boundaries, modular services, and well-defined interfaces that reduce token usage and make AI-generated extensions maintainable.
Watch section from 0:00 →The mechanical process of turning UX/UI deliverables into working components has largely been automated by AI, transforming it from the backbone of frontend work into a task overseen by a single engineer using design systems.
Watch section from 2:00 →While performance problems with clear success criteria like core web vitals can be handled well by LLMs, deep knowledge of browser mechanics and the critical render path remains necessary to diagnose whether an issue is a system design or optimization problem.
Watch section from 4:03 →LLMs excel at repetitive testing tasks such as creating mock data and mounting components, drastically cutting down the time required to achieve high test coverage.
Watch section from 5:38 →Unsupervised AI agents often introduce code smells like hardcoded non-relative CSS values, inline component declarations, and heavy duplication, resulting in significant technical debt and high code duplication if left unreviewed.
Watch section from 7:09 →Accessibility requirements like semantic HTML, ARIA labels, and tab index ordering can be efficiently implemented by instructing AI agents, shifting the effort toward building accessible design systems and performing soft checks.
Watch section from 11:03 →Applying the single record principle and collapsing redundant local states into essential, minimal data structures prevents isolated component creation from causing duplicate backend requests and bloated application state.
Watch section from 12:12 →If you're a frontend engineer afraid of AI, there are three core frontend skills that you want to focus on for you to become AI proof. Let's dive straight into them. Yeah, so the number one skill you want to invest in when you're a frontend engineer, it's system design. And I'm talking about frontend system design. You don't need to go into database sharding and load balances, but focus on the frontend. And the thing with frontend system design is that if you use an AI agent to write code, it will give you a very beautiful UI. But most of those models, including the latest all post models, they've been heavily optimized from prompt to UI. So they will ignore everything else. And your frontend will look more or less like this, where you have different entities, not very well defined, interacting with each other, and at the end it kind of works and it's apparently no bugs, but it will be extremely expensive and hard to maintain and to extend. But a great frontend application looks more like this, where we have clear boundaries, we have different services with different responsibilities. They hide a lot of the implementation details throughout the outside world, and they present clear interfaces, and the other entities they program to interfaces. They use only those interfaces to be extended, you have clear boundaries, and that also makes it easier to use AI agents to extend the code. Because in terms of context engineering, you'll use a lot less tokens to add the same value. But in order for you to be able to set this kind of architecture, to be able to divide your code base in modules and really implement an architecture, you need to be great at frontend architecture and system design. And I will not dive deep into it in this video, because it's definitely out of our scope. But make sure you check out this video on our channel where I do exactly that. Now, going back to our original frontend system design. The second problem with coding with LLMs is that every time you implement a new feature, you will overfit your architecture to that feature. So basically, instead of having a stable architecture, you will change things too much, because those models are made to give you great visual results. They are made to...
do so at the expense of everything you've done before. And so a good architecture never overfits to a specific feature. You never turn everything around to point to that single goal. Usually, what you do is you compromise and your final front-end architecture looks like the line in between. It's a combination of all these different features in its common ground. That's a lot easier to extend, it's a lot more stable, and it's a lot easier to explain. And so you need to make sure when you code with AI, that you avoid this code smell and that you're able to set the right guide rails that are able to debug and review AI code. If not, you'll end up with a bunch of spaghetti that, yes, looks good for the users, but it's impossible to extend, it's slow, and it's very hard to maintain. So we saw how frontend system design is one of the main skills you to focus on. But now let's talk about another skill, and this one is designed to code. Basically getting from that UX UI deliverable that your design gave you to an HTML or a working component. This skill is the one that was affected the most by AI, you will have to only pretty much review AI input. But AI models right now are very big and they have all this context and they're pretty good at this kind of constrained problem. Uh, now we will see in a second that when it comes to code quality, it's a whole different story. But when it comes to design to code, which was 80% of what we used to do in the front end, it kind of disappeared. And this is why a lot of front end engineers are afraid. That front end disappeared, but in reality it's front end didn't disappeared. It will just change massively, and if you position yourself well, you'll have a head start in this new world. If I understood correctly, it's kind of the mechanical part of front end engineering that's going away. And I remember a lot of developers in the development teams I worked in, where the only thing they were doing is kind of get some work from the designer and paste a button here and there, change some styles. And I feel like that kind of work is completely done. If your job is doing that, or it was only doing that, you are going to have a little to show for it and you're competing with LLMs head to head almost. Exactly, so maybe you used to have five people doing that and now you're going to have one person and that person will use an AI coding agent. And they'll have a design system so they can scale themselves, so yes, there will be one person that has to go very deep and do that on a daily basis, but it's not going
to be the backbone of front end development anymore, as it used to be. Moving on to web performance. So, this is one of those topics where people say, well, making a performance website, it's a different story and AI cannot do that. I've been working with the latest models for the last year and trust me, whenever it comes to one of those problems where they have a clear objective, get the core web vitals under this mark, they're pretty good.
And a lot of people were saying, well, but they take shortcuts, but it turns out they got a bit better, they prompt your architecture decisions. So, whenever you have a clear way, like you have a very well defined criteria of success, LLMs are pretty good. So, I'm going to put this web performance great out also, it's important that you know web performance, you want to go deep into how the browser works, critical render pad and all the web engineering, but it's not going to be a differentiator anymore, right?
What I want one understand, Bogdan, is the reason why knowing web performance and is it still worth it to know web performance? But I think it thinking about it now, I think it goes back to the system design side of things, where the knowledge you have about web performance will help you understand, is this a design problem or is it an optimization problem? So I can point my AI agents towards, I know, do a lighthouse analysis, look at the core web vitals and optimize on that, right?
Which is something that as I just said, elements can do pretty well, or because I know about web performance, I can understand whether it's a system design problem or not. But the knowledge itself, it's building into your system design knowledge is not the core differentiator anymore, right? Yeah, the thing with web performance is that you used to spend 5% of the time diagnosing the problem, and 90% of the time implementing the solution, which tend to be pretty tedious, going to a code base, resize your images, and kind of refactor some components, maybe memorize them.
And you can do that with a single prompt once you have the direction. So you do need to get good at it, as you mentioned, the system design kind of low comp field, but you're not going to have to do this on a daily basis going in and so on. Moving on to automated testing, so basically writing test. I think this was one of the biggest things that got automated. And so I'm going to put this in great, because as long as you know what you're doing and you know the test coverage you want to have and the bit about the testing pyramid, you will be much, much faster.
You'll finally have software that is covered by tests. And I can tell you everything that I built these days has a much higher test coverage. then they used to have. And you just give you kind of the specifications for those test and it's pretty amazing then. So that's one of those things where I'm very happy that we have large language models in AI coding. But what about the argument where people are saying, hey, AI is writing useless test or it's like it's writing tests that are not writing anything or tests that are very like very obviously stupid, right?
What do you say again? Say yes, but still, you only have to give you the test. You only have to give you what it's testing for and a lot of the heavy work creating the mock data, mounting components. That was very tedious, you have to write it, people would copy paste it all the time. And a lot of that you could do with large language models. And so the surface of how much you need to do to have your code coverage it's a lot smaller now and you basically scale that with an LLM.
Whereas like in the days you'll be like, I want to test this, I know how to mark it, let me give me 10 days, I'll come back to you when I finish. Now it's like give me a couple of hours. Yeah, and let's be honest, we weren't doing a lot of automated testing, people were saying, we're interviewing you for getting the tinkle interview. But we weren't doing much of it because there was never enough time.
And I feel like there's some part of hate towards AI and LLMs in coding that's not justified, right? Because they are pretty good at those repetitive tasks and they give us more space. Well, they help us do a bit more in that context. Exactly. Moving on to code quality, this is one of the biggest thing that LLMs don't do well, unless you specify it. And so just to give you a few examples from code IB writing with the latest model, that's basically I use fable from Antropic that's the latest and most powerful model.
It's not even sustainable from a cost perspective. And this is an example of a component extracted from a code base and there's two big problems and these problems are general when it comes to front end code written by AI agents. The number one is this number one code smell, which is high coded non- relative CSS values. So what these models do a lot is you go in and you tell it, hey, here's the screenshot, can you build this UI?
And it's going to try to use your design system or whatever. Like in this case, I'm using Tailwind, but then all of a sudden, because it has to satisfy whatever you gave it in, is going to use high coded values. Here it's used text 20 pixels. The problem with that is that number one is thing responsive. It's going to be very high to make that thing responsive. We usually have to use relative sizes, like a gram, that will adapt to all devices. And number two is that is not cohesive with the rest of the application. The reason why we have things like text to Excel or TXL. We have these predefined atomic classes in CSS is to show some consistency to the user. And going back to using interaction and so on, the reason why you want consistency is that when users see a consistent UI, their brain works less. There's less cognitive load if things don't change all the time. And the only things you need to focus on is the change. So that's number one, code smell. And again, this comes from the first thing I mentioned, which is they are built to hyper optimized over the target you gave them. So they're going to go in and kind of go for that goal. And the second one is nested components. And so this is the one they do a lot. We see this text component is basically created every time you re-render the function Spotlike. Normally, you want to take this out. You could just memorization. You could take it in another file and have some unit tests on it if it's if they are needed, but they just declare it in line. And the problem with this text being declared in line is that it's also not reusable. So you end up with a lot of code duplication. Every time you need to solve a small problem, it will solve it locally. And a lot of few might say, well, why don't you tell the AI to look at the whole code base if that functionality is already implemented there and then come back and implement it. Well, that takes a lot of context and you go into the dumb zone and context route, and then you get worse results or you spend a lot of tokens. And then you get into the front end engineering aspect, which is, okay, what if we put our usable functionality in libraries that are shared between modules and then you talk about modules and then you need a front-end engineer. So if you ask kid about AI taking your job as a front end engineer, you need to do two things, I know, right? We've spoke about system design, but then going very low level and going very granular, and being able to inspect what is the code base made of. And, just to jump in here, if you do that, you'll also be able to pass interviews. So because a lot of developers I talk to, they tell me, yeah, I've been told I don't sound or I'm not seeing it. I don't come across as a senior enough. And if you're able to have this high level system design view, but at the same time go very deep into the details of the browser of React or whatever framework you're working with of JavaScript itself, then you're going to nail it.
interviews. Natoly, you're going to be more productive with AI, but you will also be able to not worry about the charm market as much as other people, other software engineers are doing right now, right? Exactly. So you want to really go into the extremes. There's not going to be a lot of repetitive frontend work to do, but there will be a lot of frontend work to do. And finally, this is what happens when you vibe code or you work with AI and you write a lot of code without checking the components.
This is a summary of one of our systems pretty big and as you see here, we see there's a 9% application in in in our code base. And this is static analysis. This means that those snippets, they look exactly the same. I'm not even talking about functions that do not that have, you know, 90% shared functionality. No, this is exactly what they do. They do the same thing. And there's 153 unused fights.
And that's extremely bad for your context management, it's extremely bad for the results you get from AI. So as you let agents work unsupervised and you don't take a look at the code or the code quality and you don't optimize for that, you might have an app that looks like you want it, you're basically sitting on a pile of technical death. The moment you want to move a little piece, it all come down together.
Now, let's talk about accessibility, which looks like it stays in, but it's one of those things that again, it's pretty well defined, and you can instruct your agents to use semantic HTML, and whenever you have something more complex, you have to go into it. But you can also use AI to help you make things more accessible, and it's again one of those granular component work level, which was for the most part, also can be automated with AI.
And again, it's a non-functional requirement, so it's not core to the business value, so business will push you to just get it done and move on to the next thing. So, when it comes to accessibility, you can instruct your agent to use number one, semantic HTML. Whenever you're using an element that cannot be used in a semantic way, like you kind of need to take a shortcut or use a lot of diffs, then use area labels to signal their role.
And also make sure you know that the order of the elements in the tab index matches the order of the elements on the screen. And that's for the most part, you can do that with an agent and go really fast and back in the days we used to spend have an accessibility sprint where you spend two weeks just doing a accessibility right now, the person that's building the platform, the person that's building the design system for the whole company, can make sure that's already accessible and then AI can learn from that and you use it and you don't need to care about.
You just kind of do a soft check. And finally, the last skill, which is state and data. And this is one of the most important low-level skills when you're building components. It's basically being able to look at the UI and then what is the best data structure to model that UI? To kind of collapse that into its essential state. We talk a lot about the essential state in this channel, there's a lot of videos about it, make sure you check those out.
But basically, if you use AI, you'll have kind of local state all over the place and a lot of it would be redundant. Because people are building components in isolation and unless you communicate and you know about architecture, you'll end up fetching the same thing from the back end to render it in two different places. So you end up having two requests. And in a design application, state is much more ordered and it's what we call the essential state.
You don't want to have any redundant state, you don't want to have derived state, state should be as minimal as possible. And I like to use this metaphor of the Picasso ball. So Picasso starting starts drawing a ball, it do all the detail and then he starts collapsing it into the minimum representation, which would be this one. So basically, you this spaghetti, a genti coding UI will have a lot of state will be very heavy, but if you do it well, you'll condense that into this, which is the main abstraction of a ball.
And you want to apply for that the single record principle, which means that every piece of data must be stored exactly once in a system. And if you worked on vibe coding application, an application that gets really big, even with AI, this is a task that takes a lot of time. It takes a lot of context, it takes a lot of engineering work to make it happen. And so it's a lot better if you as a front end engineer, when working with AI, you already know these principles and you can apply them on a high level.
A few questions before we wrap it up. Number one, if I'm a front end engineer and I have all these skills in mind and I know now that, hey, I need to get better at system design. I need to get better at code quality and I need to get better at state. Which one should I pick first? It very much depends on the system you're working on, I advise if you want to learn as much as you can from production.
If you are working on a system that has micro front ends, that has a bit of scale, you definitely want to invest in system design. But I know a lot of people are working on features, you don't have, maybe you don't own such a big place part of the system. So that's why I go very granular and focus on state and data and code quality, which is you go in and whenever you're doing something with an agent, you take a look at that pull request and you start really doing code review.
Not any AI code review, but you really look at the code that comes out of the machine, because that's the only way. Like you have this industrial factory that's making cakes and the only way for you to know if it's good, got to go in and taste it. And by the way, folks, if what you want is to become an AI proof, front end engineer and senior engineer and full stack engineer, then the first step is for you to know what you're lacking and to do that, put together this free tinker assessment for JavaScript engineers.
where just you're going to invest 10 minutes, answer a bunch of questions and it will show you roughly your gaps to get to that senior level. And if you want to learn more about this three major skills that will dictate the future of the front end, system design, code quality, state and data. There is a lot of content here on the channel, on the senior dev channel. And if you want to dive deep in any of those skills, just let us know in the comments.
Even if we don't always answer, we always read them. And we will add it to the list. Thank you, and we will see you folks in the next one.
