Transcription
Front-end engineering is dead, but front-end composability is not. In the next few minutes, I want to lay out why front-end engineering is falling apart. And so many engineers I know are worried about that if you're on the front end, and what the future looks like, what it looks like to move from a front-end engineering role to a front-end composability role and why that's shifting the skill sets we need when we craft UX's for users.
So, let's set the context. For the last decade, front-end engineer meant something pretty simple, right? You take a Figma file. You often open up a React project or similar. You're going to wire up the state. You're going to wire up the routing. You're going to mess with the CSS. You're going to push the pixels until the UI exactly matches the design. That work was labor intensive. It was bespoke. Every company re-implemented similar looking tables and modals and forms and dashboards with slightly different code. And you know we focused on that as craft because it took humans to build it.
But this is part of the larger shift in our AI systems. We are moving from a world where static defined UXs that presume the user will employ the UX to get a job done are starting to disappear. And we're moving toward a world where what we're selling is the full workflow and the solution itself. If we're in a B2B context and if we're in a BTOC context, we're selling the full experience and empowering users to create. And so this just looks very different than the hardened up websites we created with front-end engineering in the past.
If you look at the stack now, all you're trying to do is figure out how to take things like next.js JS or similar tools and compose them using LLMs so that you get to a read write experience that is consistent that is role appropriate for that user but is also bespoke to them. Fundamentally we're moving toward componentizing everything. So systems like Shad CN and others give you accessible production-grade Lego blocks, right? Building blocks, menus, dialogues, forms, and you can literally begin to compose with them using AI. And you want to think of that as a jump from a foundation design system, which we've had for a long time, to a foundation composability system that can be composed on the fly by AI.
In certain cases, the world I I've got a hard news for you, right? The world no longer needs armies of engineers to rebuild the same UI primitives. That's just not happening anymore. And AI is just accelerating that. Something like 41% of code is going to be generated by AI this year. Everybody has AI coding assistance. Everybody's got cursor installed. And these aren't just toys, right? AI-driven workflows are emerging that take Figma designs and output complete component trees output usable app shells where in agentic coding scenarios where your agent can learn your UX and design run against evals until the UX passes and then ship it.
So where does that leave front-end engineering and the craft of front end? What we're moving toward is a world that has front-end composability. You need to be really good at your primitives, right? The FEGO bricks that enable you to reliably assemble experiences so that buttons and inputs and dialogues become something that are branded but also highly reusable and headless so that you can put them together in ways that are appropriate for the customer at that request at that moment in time on that screen. Comet is obviously a great example here. You can compose a UX in Comet and it will literally just spit out what you need in that moment to take action.
I feel like we are just scratching the surface though. I think low code platforms, even though they're composability engines, they build something on the fly for you when they ask for it, are just the beginning. I don't believe in a world where the low code editors are really the ones that are shoving front-end engineers into different roles. I think that low code editors point the way toward a composability world. But at the enterprise scale, what I see in practice is that it's agentic workflows driving off of composable building blocks that are actually shifting where front-end engineers spend their time.
And so you might wonder, sure, I've heard about all of this, but where do front-end engineers start to focus? And how do they start to think differently than they did before? I want to suggest a few mental model shifts that I am observing in the front-end engineering discipline and we'll talk about their implications.
So number one, we're moving from a world where we have to think about data schemas to a world where we think more about screens. As the data schemas start to stabilize underneath and as it gets easier to query them, you should be able to be in a world where you can change the underlying data retrieved and the form will just follow and evolve. And so your job in that world is to think about the mutability profile of the UI schema, the different ways it can change and what is the allowable range and what is the queryable range against different data schemas. So instead of just shephering one view into production as a front-end engineer, you're thinking about this profile of hundreds of different views that you can understand as a range and build for overall as a system of composable engineering blocks rather than a single view.
The second one is you should stop thinking about whether you have got the exact right spacing and typography and move toward a world where you think about the brand as a series of promises made through the front end. And all you're doing is making sure that the brand system is expressed reliably across those hundreds of pages we just talked about. And so you're looking and working with designers to say, are we fulfilling the brand promise in this range of use cases? This is going to require even more close collaboration between front-end engineering and customers. We've always talked about like I've worked with front-end engineers, right? Like the sitting with customers is a really common activity, but we need to do it even more because we need to see the use cases that work and the use cases that don't across a much wider range. You're not building the page for the one use case and asking that the others just be put on different pages. You actually are thinking of the page as the query box as the place where the customer can compose an interface and then your job is to understand the range of those use cases so that your system can respond appropriately across that range that requires like x more customer conversations.
You should also move from thinking in terms of design patterns to thinking in terms of workflows. Think of it as recipes. Right? You have recipes to get workflows done and your job is to enable as many good recipes as you can based on your data in brand compliant ways so that you can enable the user to compose those on the fly. Will we still see cases where there are core pages that are static? I believe so. People don't like change, right? We're going to see some static stuff. And I also think there's a case for simplicity here. If you have the simplest possible cancellation form, there is no reason to reinvent it on the fly. You may want to as a front-end engineer cache that pattern and call that pattern when the user asks for it. And so I think we need to step away from this idea that buttons and tables and forms are infinitely composable and think about it more as patterns in our workflows that we can start to call for when we have a user request. And that's different because in the past, like if I wanted to cancel my mobile phone, it's like you go through their website, it's six different clicks and good luck and you'll probably have to talk to a person. Now, if you want something that would be considered an edge case by the company, it is possible to have a very simple flow that is just invoked and displayed right where you need it. I think we're going to see a lot more of that in 2026. And I think front-end engineers need to think more about those workflows which again requires sitting and thinking with the customer.
One of the things that I I think is critical is shifting where we think about roles based access controls. This gets a little nerdy but the front end should no longer be in the business of deciding what a user can or cannot do. And in many systems we've had the idea that you can read your capabilities from the back end or from policy and that's great. I am am really going to call out that if you have a system that is composable, you have a system where you have to assume agentic users, you have to assume human users and we need a layer that enables us to bake row security and auditability into the platform assuming different users are employing the system for different purposes and it's going to be a sort of composable experience. This is going to impose new challenges because traditionally with roles-based access control, even if you did have like a central policy engine for arbac, you would still assume a static site that it was driving. Well, now you need to have a dynamic site. You'll need to have a ability to maintain role security and consistency of data access even though the site is dynamic. And I think ideally you want a degree of auditability. Like you want something that lets you say the agent has this level of access. The agent did this on the screen. This was the composed view the agent saw and the agent took this action. I think we humans are going to expect that. But we don't really have a way to do that today. Most of the replay tools are designed for marketers who are trying to understand how human users behave. We don't have the idea that we need to have audit trails for composable workflows and UIs. And I think we're going to need that in 2026.
And this points my sort of way to the the fifth thing I want to call out, which is that you need to think about AI as a consumer, not just something that helps you generate all of this. So AI agents are really going to be 99% of the attention on your tool, and they are going to have different needs. You need to think about whether they want to consume via APIs, whether you're going to have computer use agents, whether you're going to allow composability only within certain patterns for AI agents, whether you are going to have a different set of roles and permissions depending on the users role, the human user's role, or depending on the agents role. So, do do agents inherit permissions from humans but at a lower scope? All of this stuff needs to be thought about because you need to frame AI as a consumer of data. And this means, by the way, that if you want to deliver on the promise of AI agents for your business, you need to figure out how to make your brand promise real, even if the customer only interacts with your site through the AI agent. That's new for us, too. We're used to having a site that the people can see and we're not going to necessarily have that in 2026. You may have agents browsing the site and coming back with the data the person needs because the person doesn't want to look at your dashboard. They just want the outcome and go. How can you think about how to deliver information headlessly and a brand promise headlessly so that you can make that promise real and give the user what they're looking for.
So what does this mean for the front-end engineer? What what is your job become? First, you're you're a system designer yet. You're not a ticket taker. Your your leverage is going to lie in choosing and shaping the primitives and components, right? You you should decide what is an acceptable button variant range. You should think about the vocabulary of your interface across both an API state and a visual state.
The second big thing is you should think about how you model workflows. So instead of just hand coding your fields, you should sit with your customers and think about how you drive dynamic flows, tables, forms so that it's not just I'll build you a new page. It's let's extend the schema so the system can produce that class of page to get your work accomplished maybe through an agent.
Third, you want to integrate the tools that you need to use to allow AI to generate or modify your UI on the fly. Yes, you're going to have guardrails and you need to be the one that thinks about that as the front-end engineer. You need to think about where AI can generate UIs and where you want to lock it so it can't. How you design the system so it generates them in brand appropriate ways every time.
Finally, you need to think about UX instincts on a different level. Someone is still going to have to care about whether your layout is thrashing around, about whether you have massive input latency because you're generating a UI on the fly, about whether you have keyboard accessibility if you have a thousand different variants of the page, about whether you have an ability to give a user something that they find inherently predictable, even if you're generating it. Tool chains can't solve those kinds of things. You need to start thinking about those kinds of things as patterns, as primitives, and build so that downstream users can inherit them by default.
You might wonder, are there places where classical front-end engineering will still happen? I believe there are. If you have high polish consumer products, they will often need custom rendering, very intricate interactions, careful performance tuning. You're not going to get that with composability. I think we're headed toward a two-class world where you have kind of the Dlers and the Bentleys of the world and websites that are handcrafted and beautiful and polished and you have a lot of composable sites that are very utilitarian but can still deliver the brand promise.
You're also going to probably handroll pages where you have extremely high traffic, right? If you need extremely mission-critical surfaces that have high traffic loads, you want someone that reads every single line of that page before it hits your DOM and you want to have bespoke attention to all of the components, error states, semantics, your keyboard flows. You can't screw it up if it's a healthcare site, if it's a finance site, if it's a very large high-traffic site. And like that reminds me if you have a heavy regulation safety-critical kind of domain you need to think about auditability from day one. I know I called out auditability but that is something that you have to build in to ensure that whatever you put out there whether it's a static page or dynamic flow is going to give you clarity on what the user actually experienced.
But these are exceptions. The default experience is shifting toward composability. So when I say front-end engineering is dead, what I mean is that the era where most of the front-end engineers job was hand implementing pages, that's ending. We're moving to a world where you have AI coding assistants and frameworks and schema-driven UIs that collapse that work into something very cheap and repeatable. And what replaces it is this idea of composability where you're designing the primitives, schemas, the contracts that make it possible for an org to ship new interfaces. Imagine a world where you are enabling your PM to do shipping of interfaces, right? We're getting into a world where the whole org should be able to write that code.
And so, you know, we're moving from a world for engineers and and interviews where it's not can you build a beautiful React UI, please show me what you did. It's help me think about how you design a front-end ecosystem where designers and product teams and low code builders and AI can all compose beautiful UIs without reinventing the wheel, without wrecking the experience. While providing auditability while ensuring that agents can access in role and permission appropriate ways. And so yes, front-end engineering is dead, but long live front-end engineering, right? It's grown up. AI is simply reshaping the tools we have and changing the demands on our skill sets. So, as much as I think there's a huge transition ahead, I also think there's a lot of excitement coming because we have never had the ability to be this dynamic about front-end engineering. Good luck if you're a front-end engineer. And if you're not, thank your front-end engineers and ask them how you can deploy front end to production.