Frontend isn't dead, but your focus needs to change

This is a guest post written by Yangshun Tay.

Every week, someone declares “frontend development is dead”. Meanwhile, companies like OpenAI, Anthropic, and Manus, are still hiring frontend and product engineers, some even more than ever.

To claim that frontend development is a dead-end career is to ignore the economic signals showing that the discipline is shedding its historical skin to reveal a more architectural, higher-leverage form of engineering.

I spent years at Meta as a Frontend Engineer, working on web platform infrastructure and led the development of meta.com. I created Blind 75, the OG list of LeetCode practice questions. 

These days I’m working on Cliya AI, an AI-native creative suite, and GreatFrontEnd, an interview preparation platform for Frontend Engineers.

Thanks to GreatFrontEnd, I interact with Frontend Engineers from all over the world on a daily basis. From what I can tell, frontend isn't dead, but it's certainly evolving.

Frontend work is a good candidate for AI

The “Frontend is dead” claims aren’t unfounded. Let’s first understand why people even think that way.

Many software engineers begin their journey into development by tinkering with HTML, CSS, and JavaScript. Introductory programming courses often teach in JavaScript. JavaScript is the top & most popular language according to recent GitHub surveys. As a result, there’s a lot of frontend code available online for LLMs to train on.

On the surface level, frontend is the most automatable layer of the software stack. UI components are highly structured and well-documented. Data fetching, sign in flows, and form filling are pattern-heavy, it’s exactly the kind of work LLMs handle best.

In software systems, frontend code is considered the “leaf nodes” within a complex system graph of components; they are nodes with the fewest dependencies. The cost of breakage on the frontend is usually lower than somewhere deep in the infra stack or payment modules, where there are way more dependents — a wider blast radius, potentially resulting in downtime and huge financial losses.

The combination of abundant training code, pattern-friendly nature, typically non-mission critical work makes frontend code a good candidate for AI. Andrew Ng mentioned that frontend development is the function that has accelerated the most.

Codex, Claude, v0, Lovable, Cursor, they all can generate webpages and entire apps from a simple prompt. Millions of developers use these tools daily. People look at that and ask, "Why do we still need frontend engineers?"

More than meets the eye

Many people who claim “Frontend is dead” confuse the visible layer with the actual work. Frontend development is far more than just rendering pixels on a screen. Modern frontend applications exist across a broad complexity spectrum. 

On one end of the spectrum, you have simpler apps like marketing websites, blogs, internal admin dashboards, customer support, etc. For such software, the frontend is usually just grunt work, glue code that displays data from a database and sends data to be saved back into the database. Most companies need these software and either buy or build.

On the other end, you have complex apps like Figma, Linear, Spotify, or Google Docs that deal with significant client-side logic, messy asynchronous flows, real-time collaboration, offline usage, and plenty of other client-side features. These apps are called “thick clients”, and not all companies are building such software. 

The scope and complexity of thick clients make it hard for products to consistently deliver a performant, accessible, and bug-free experience. In my experience, AI and coding agents start to break down when a system gets too complex. As it stands today, AI is focused on getting the code and functionality somewhat working. It cripples on subtler aspects of building interfaces, such as performance, accessibility, and user experience.

What AI does well now

What AI automates today is the lowest-context and repetitive slice of frontend work:

Boilerplate and glue code. Setting up a new Next.js project, wiring up API routes, CRUD work, and writing form validation. Anything that follows a well-established pattern with lots of training data.

CSS and styling. AI is surprisingly good at CSS, responsive layouts, animations, and getting something to "look like" a reference design. That said, note that AI does not actually “see your app”, it generates based on known patterns and common layouts, and often, the visual result is different from its intended result.

Converting between frameworks. Taking a jQuery component and rewriting it in React, or migrating class components to hooks. Pattern translation where the logic stays the same but the syntax changes.

Writing tests. Generating unit tests, integration tests, and basic E2E test scaffolding. It won't write great tests that catch subtle edge cases, but it handles the repetitive coverage work well.

Truth be told, many companies only need that level of frontend. If that's all you can do as a Frontend Engineer, you need to change that.

Sign up for our newsletter

Want more like this? Get the latest in tech right in your inbox.

What AI doesn’t do well (yet)

On the other hand, AI still struggles with these frontend topics:

Complex state management. There are dozens of pieces of state that interact, like user auth status, cached server data, optimistic UI updates, form drafts, animation states, route transitions, WebSocket events, all happening concurrently. The complexity doesn’t just lie within any one piece; it's in how they combine. AI is great at generating individual patterns but weak at reasoning about the interactions between them.

Coordinating non-standard async flows. AI breaks down when multiple async operations interact in ways that create emergent complexity, race conditions between competing requests, coordinating dependent and independent operations together, handling partial failures in a chain, and rollback logic across multiple state updates. AI relies heavily on pattern matching from training data, but async correctness depends on handling all possible orderings, not just the common ones.

Optimization that requires system-level thinking. AI can tell you to lazy-load images or code-split routes, all the textbook stuff. But real performance work means understanding your specific bundle graph, profiling reflows caused by a specific CSS property on a specific browser. AI optimizes for "does it work", not "does it perform". When AI generates code, it's pattern-matching against the most common way to solve a problem. The most common way is almost never the most performant way. It's the way that shows up most often in tutorials, Stack Overflow answers, and open source repos, which is the "get it working" unoptimized version, not the "serve it to 10 million users" optimized version. You have to specifically prompt it to “identify performance issues” or “fix this performance issue I’m facing”.

Accessibility beyond checklist compliance. AI can add aria-label and role attributes. But really designing for universal access means understanding how a screen reader user actually navigates your app, building keyboard interaction patterns that feel natural, managing focus correctly during route transitions, and handling live regions for dynamic content. It also means understanding who is using your app. For example, thinking about contrast and font sizes when designing for the aging population, or font weights when designing for point-of-sale screens. It's deeply contextual, and AI usually simply pattern-matches against a surface-level WCAG checklist.

These aspects are not limited to frontend code. They apply to other kinds of software as well; they are limitations of the current state of AI.

This list is not exhaustive nor is it permanent, since models are always improving. But just like any tools, it’s important to understand what they are good and not good at, use the right tool for the right job, and know when to step in.

The CRAFT framework

The limitations of current AI models directly define the new areas of non-negotiable mastery for the modern frontend engineer. Beyond technical competencies, frontend engineers also have to reconsider their job scope and responsibility.

To help navigate and master these changes, I've organized them into the CRAFT framework. I believe these frontend engineers should focus on honing these five skills in order to navigate the next generation of software development.

Complexity. Frontend engineers must now master complex systems and the domains where current AI models fail, such as the aforementioned limitations of today’s AI. Focusing on these areas creates a "human moat" against automation.

That said, not every organization is building complex apps. If you have a choice, I recommend working at companies where the frontend matters. Frontend engineers can continue delivering value by taking on full-stack development work and end-to-end responsibility across the entire product development lifecycle. Notably, engineers at Anthropic are shipping features end-to-end without a PM involved.

Responsibility. The new ceiling for frontend developers is complete end-to-end ownership of the system, fundamentally shifting the role into that of a Product Engineer, and being responsible for the outcome of the product. This requires reasoning broadly about the entire architecture, from database to screen, and being the engineer leadership trusts to implement safety guarantees like performance budgets, accessibility, and architectural consistency.

Agentic experiences. In the future, products that are glorified database wrappers could just be exposing MCP servers called by chat interfaces; they might not even need a user interface.

The products that still need an actual user interface tend to be heavy on frontend, e.g., ChatGPT, Claude Desktop, Codex, n8n, Manus, etc. AI is creating an entirely new category of frontend work: streaming UIs, agentic interfaces, tool-calling frontends, and generative user interfaces. Many existing products want to add these AI features. This is a genuinely new design space, and there's huge room for us to define UX and architectural patterns for building agentic products.

Full stack fluency. Engineers must possess deep frontend fundamentals, complemented by sufficient breadth in the full stack to debug issues across the system. Since AI can confidently produce silently broken or unoptimized output, strong fundamentals are required to rapidly debug and fix errors, ensuring that the team can safely and quickly capture the value that AI acceleration provides.

Taste. Product sense is the ability to exercise taste and judgment, and is now a critical professional differentiator. This involves knowing what to build, making good design decisions, and translating ambiguous business problems into technical leverage and high-value solutions. Actively study admired interfaces, develop strong opinions, and cultivate the judgment needed to direct the machine toward building the right product.

Embrace the shift

AI is here to stay, whether we like it or not. The key to navigating this change is to double down on "human moats" such as mastering complex systems, exercising product taste, and taking end-to-end ownership of the product.

Frontend development is far from over; but increasingly, much of the scope of traditional frontend work can be done by AI. Therefore, frontend engineers need to adopt CRAFT, focus on deeply technical aspects, make mindset and behavioral shifts, and assume responsibility in adjacent domains in order to stay relevant and keep delivering value.

Thanks to Phil Zheng for reviews of drafts and providing suggestions.