Cell by Cell
AboutRings

TechEssay

Frontend Is Dead

I never systematically learned JavaScript, yet in one week I rebuilt or created five personal websites with Claude Code and Codex. Frontend has not disappeared from the web, but it is changing from work that requires a dedicated profession into a set of capabilities anyone can invoke through an agent.

  • Published
  • Reading time9 min
  • LanguagesENZH
  • AI
  • Frontend
  • Claude Code
  • Codex
  • Agent

For the past few years, I have relied on NotionNext and HugoBlox to maintain several personal websites.

They are both excellent projects. Without them, I might have given up on building websites long ago. But a project made to serve many people and a website that exists only for me are ultimately not the same thing.

Upstream updates are not always predictable. Project structures occasionally shift in small ways. Themes retain plenty of machinery that I do not need because they have to accommodate many different users. Changes to the Notion API can also suddenly ripple into my own pages. None of these problems is insurmountable on its own. Together, however, they create a persistent unease: the websites are ostensibly mine, yet much of what determines how they work remains outside my control.

So I thought I would let an agent try.

I did not begin with much ambition. I merely asked it to make a static HTML demo, to see whether the page I had described could work at all. The result genuinely astonished me. It was not ready to ship, and its details were nowhere near perfect, but for the first time I realised that an approach I would never have considered because I knew no frontend was at least possible to begin.

Over the next week or so, I used Claude Code and Codex to rebuild or create five static sites, gradually migrating their old content and workflows as well.

I had never systematically learned JavaScript, and I still cannot claim to know much frontend development. The five sites retain plenty of rough edges. Some responsive details need more work, and some implementations may not look particularly clean when I revisit them. Yet their visuals, content organisation and build processes have begun to grow around my habits, rather than around the slots a general-purpose theme happened to leave for me.

Stranger still, I am quite happy with the results.

I did not learn frontend, but the websites got built

Building a personal website used to involve a straightforward trade-off.

With a mature theme, I could avoid most of the development work, but I had to accept its structure, aesthetics and release cadence. By building from scratch, I could gain control, but only after acquiring an entire stack of skills in design, frontend development, build systems and deployment.

Agents have not eliminated that trade-off, but they have compressed it.

I still have to decide what a website is: whom it serves, what the homepage says first, how articles are arranged, how much space a cover should occupy, how Chinese and English coexist, which automations are worth keeping and which apparently convenient features merely create noise.

Once those decisions are made, however, I no longer have to cross every implementation barrier myself. An agent can read an existing project, find similar files, modify styles, migrate content, run a build, check tests and continue revising in response to the results. It makes mistakes. It also produces things that I can tell at a glance do not feel like me. But most of those mistakes can be identified, redone and rolled back.

This has not made me a frontend engineer.

More precisely, it is the first time I have not needed to become a frontend engineer before earning the right to have a frontend made for me.

Two years ago, people still seriously debated whether frontend would die

Over the past two years, a few familiar arguments appeared again and again.

One side said that AI would profoundly disrupt the software industry, programmers would be replaced and frontend developers would probably be among the first to go. The other replied that models could only produce impressive demos. Put one inside a real project and it would get lost: it did not understand requirements, had no taste, wrote unmaintainable code and could never take responsibility for a product that had to keep running.

Both sides treated the question as a future that was still approaching.

This year, however, I have seen far fewer heated arguments about whether AI will replace frontend developers. That is only an observation about my own feed, not an employment statistic. Frontend jobs did not vanish collectively on some particular morning, and the complex systems a good engineer can build remain far beyond what a single prompt can reliably produce.

Yet my five websites are sitting right there.

They do not prove that frontend knowledge is no longer necessary. They reveal a different change, one that job counts have difficulty capturing: some work that once could be done only by a frontend engineer can now be initiated, reviewed and delivered by someone who does not understand frontend development.

A profession does not have to change through everyone losing their job at once. Tasks can detach from it first: a landing page, then a component set, followed by content migration, responsive adjustments, build configuration and deployment. Websites still require all this work. They simply no longer require, in every case, a person called a frontend developer to perform each part.

Frontend has not disappeared from the page.

It is changing from the exclusive labour of a profession into a collection of capabilities that many people can invoke.

Design and code have lost their order

If AI were still only a model inside a chat box, these five websites would probably not exist.

Commands, MCP and skills allow agents to call tools and enter projects, but that is last year's story. What has truly loosened this year is the once-clear order in which products were made.

Website production traditionally followed a recognisable pipeline: discuss requirements, prepare a design, then hand it to frontend engineers for implementation. However often the work travelled backwards, design and code remained separate stages, giving designers and engineers correspondingly distinct positions.

I did not follow that process at all. I did not finish a design and then translate it into code. I began with a static HTML demo and only gradually decided what it ought to become after the page was already running. Design was not an image produced before development. It was something revised back and forth alongside the code.

This year, Claude Design and the connection between Codex and Figma have been turning that experience into products. An idea can begin as a prompt, a design file or already-running code. Nobody has to decide first whether the present moment belongs to the design stage or the development stage.

When design and implementation can travel around the same loop, the first thing to disappear may not be a particular skill. It may be the handoff between them.

The first version is no longer treated as the answer

AI-generated frontend used to be exceptionally good at creating amazement, then equally good at exposing itself once the amazement passed. Enter a sentence and a beautiful page appeared within seconds. Click around and the buttons did nothing, the layout collapsed under real content, and the supposed features were only shells.

The most important advance now is not that the first version looks better. It is that the first version is no longer treated as the answer.

One agent generates while another opens the real page, clicks through it like a user, takes screenshots, checks the functionality, writes a critique and sends it back to be rebuilt. The same page moves through this loop repeatedly until no obvious fault remains. Even “this looks unmistakably AI-generated,” once something only a person could complain about, is beginning to be decomposed into items that can be checked one by one.

Taste has not been solved, of course, and models still produce vast numbers of mediocre pages. But aesthetic criticism is beginning to take a form resembling software tests: counterexamples, checklists, an independent evaluator and a loop that continues whenever the result fails.

This looks remarkably like the most ordinary part of frontend development: write a little, open the browser, notice what is wrong, then go back and change it. Models used to replace only the “write a little” part. Now they are beginning to consume the whole loop.

I should add that I used none of these frontier techniques during my week of building. I had only ordinary Claude Code and Codex. I played the evaluator inside the loop myself, repeatedly opening the page and saying, “This part is wrong.” The barrier does not have to wait for the best tools to become commonplace before it falls.

That is also why frontend stands at the head of the line. A page is immediately visible. Code can run, builds can be tested and deployments can be rolled back. Even without understanding every line, I can tell whether a button appeared, whether text overflowed and whether the website resembles what I wanted. The easier a result is to observe, the easier it is to close the loop of generation, evaluation and correction.

Design has entered the same loop. Medicine will move more slowly, not because it is immune to AI, but because a mistake cannot be refreshed and rolled back like a webpage. The real timetable for different professions may depend less on how sophisticated they are than on whether they can create a sufficiently cheap and reliable feedback loop.

What died was the barrier

People are still here, of course.

I still decide why these five websites exist, what they should present and which results are acceptable. An agent does not know why a particular design does not feel like me unless I articulate that dissatisfaction.

But the presence of a person cannot preserve the old division of labour.

During that week, I simultaneously played the client, product manager, editor, design reviewer and tester. Claude Code and Codex moved among those roles, turning my judgments into files, pages and build results. Work that once had to pass between several people was compressed into a conversation between one person and several agents.

Professional expertise will not disappear. Truly complex products still need people who genuinely understand frontend engineering, and high-level design and engineering judgment will remain scarce. But “expertise remains valuable” and “the profession will not contract” have never meant the same thing. On the contrary, precisely because one knowledgeable person can do more with agents, fewer people may remain.

To say that frontend is dead is not to say that no frontend jobs remain, or that frontend knowledge has become worthless. A profession does not need to wait for its last practitioner to leave before it dies. Once it is no longer the necessary entrance to completing this kind of work, the barrier has already fallen.

For someone like me, who merely wants to own a few personal websites, frontend as a barrier is already dead.

I crossed it in one week and five websites. They are not perfect, but they are enough to make it impossible for me to keep treating the impact of AI as a debate about the future.

A few days ago, I saw someone on X wonder why hardly anyone talks about “frontend being dead” anymore.

One reply read:

Dead people do not talk.