The frontend developer in ten years

When people ask whether I'm afraid for the profession in the face of AI, I answer that I'm afraid for a specific form of the profession, not for the profession itself. The frontend developer as the role took shape over the last fifteen years — the person who translates a mockup into code — really is going away. But not into nothing; into a different role. I think in ten years it'll be the UX/UI engineer: someone who holds both the interaction and its implementation in one head.

What's disappearing

The mechanical layer is disappearing. Translating a finished design into markup, building a form from a description, laying state out along a standard pattern — that's the part of the work AI already does faster than a human today, and will only do better. You won't be able to take pride for long in "being good at markup": it's like taking pride in nice handwriting after the keyboard was invented.

Remove the mechanical layer, and a question is laid bare: what, exactly, of value is left? And the answer, to my mind, is uncomfortable for many: what's left is understanding what to build and why, not how.

What gets more expensive

If the mechanical layer is devalued, the value flows into what AI can't do yet: understanding what and why to build, choosing the right boundary, noticing that a plausible solution is actually wrong. That's not "hands" work — it's the work of judgment.

And here an old pain of development is exposed: meaning is lost at the seams. By the time a requirement makes it from idea to screen, it gets reformulated several times and each time slightly distorted. AI hits exactly those seams: when one person with a good tool walks the path from hypothesis to a working prototype themselves, the long hand-off turns from a help into overhead. The winner is whoever holds more adjacent layers in their head at once — the interaction, the implementation, and the product meaning.

The UX/UI engineer

That's exactly the person who holds these layers together. Not "a frontend developer who can also do Figma". It's an engineer for whom the interface and its meaning are one whole. They reason just as freely about what the user should feel and about how to express it honestly in code; they see where the line runs between a UI task and a backend task; and they take on the whole product, not their stretch of the conveyor belt.

Value shifts from execution to judgment. Framing the right problem, choosing the boundary, noticing that a plausible solution is actually wrong, and being accountable for the result — these are the skills that get more valuable as code gets cheaper. It's not about a specific framework, and so it doesn't grow obsolete along with one.

The book that becomes a tool

One particular case of this work is close to me. You can take an anemic book — just text — and turn it into a working instrument for exploring the knowledge the author offered. Invent interactive widgets through which the reader doesn't just follow the thought but lives it: masters something new, cements it, and discovers new knowledge and new meanings themselves. That's the engineering of meaning, not of markup — the value here is not in the code but in the experience of understanding you designed. For me this isn't theory but an ongoing experiment and inquiry: I'm turning a book on financial ML into a set of exactly such interactive islands. And it no longer matters at all what this tool is written in — React, Vue, Svelte or Elm. The framework is a consumable; the intent is not.