Frontend in the AI Era: What's Getting Cheaper, What's Getting More Expensive
This article has no new frameworks, no source code analysis — it discusses a much more critical question: as AI gets better and better at writing code, where exactly does our value as frontend developers lie? I've organized a few things I've figured out during this period, trying to keep it plain-spoken so that even newcomers can understand. Note: This article contains AI-assisted generation
1. First, Admit It: The Anxiety Is Justified
No need to comfort each other. Open an AI coding tool now, drop in a design mockup, and in a few dozen seconds you get a working page that looks pretty decent. Three years ago, that was an afternoon's work for a junior frontend developer.
So the question "Is frontend dying?" gets asked every day.
My take: The anxiety is justified, but most people are anxious about the wrong things. To figure out a way forward, you first need to figure out exactly what AI is devouring.
2. AI Is Devouring "What You Can Learn by Following Tutorials"
First, a question: How did AI learn to write code?
The answer is simple: it studied all the publicly available tutorials, documentation, open-source code, and Q&A posts on the internet. In other words, AI is a colleague who has already learned everything that can be learned from public materials.
Flipping this statement around reveals a particularly sharp dividing line:
- Anything you can learn by following tutorials, documentation, or a bootcamp, AI already knows and is more proficient at than you. Writing a standard component, recreating a design mockup, wrapping a request layer, configuring a build setup — the common thread of these tasks is "there are tons of existing examples online," which is precisely where AI is strongest.
- Anything not found in tutorials, AI still doesn't know. For instance: Should this requirement even be built? Why did the user hesitate for three seconds on this page and then close it? Given our team's current manpower and legacy baggage, which of these two approaches should we choose? Who steps up and takes responsibility when there's a production incident?
I like to imagine frontend work as a circle: the large central chunk is "the part you can learn by following along," which AI has already covered entirely. The remaining crescent at the edge is judgment, taste, understanding of users, the ability to get things done across teams, and the accountability to "own the outcome."
The brutal part is this: the center of the circle is most people's comfort zone. It's comfortable because there are standard answers; having standard answers means anyone can learn it; and anything anyone can learn has never been valuable — AI has simply settled this account once and for all.
3. Your Salary Was Never a Reward for Hard Work
Here's a truth that's not pleasant to hear, but the sooner you understand it, the better:
A salary measures not how hard you work, but how hard you are to replace.
Carrying bricks is harder than writing code, but pays less — not because society disrespects physical labor, but because "there are too many people who can do that job." The same goes for any skill: when many people have it, the price drops. It's like a popular bubble tea shop on a street corner; a second one opens right next door, and soon neither makes money.
The high salaries in frontend over the past few years were essentially because "few people knew it, and many people needed it." Bootcamps increased the number of "people who know it," cooling the market a notch; now AI has pushed the supply of "people who can write standard code" to near infinity, so the price of that skill collapsing is inevitable — it's not a targeted attack on frontend.
Once you grasp this, the way out is already written within it: Stop putting effort into "what anyone can learn," and move yourself to "where few people can go." More on how to move later.
4. AI Is an Amplifier — First Ask If You're "Worth Amplifying"
Looking at it from another angle, this might be the greatest gift this era has given to programmers.
You can roughly think of a person's output as a multiplication:
Output = Judgment × Tools
AI hasn't touched your "judgment"; it has overnight amplified the "tools" factor by ten times. In the past, one decision of yours drove your own ten fingers; now, one decision of yours drives a tireless army of code.
But multiplication has a characteristic: it doesn't distinguish good from bad — it amplifies indiscriminately. If your direction is right, AI helps you amplify the right thing tenfold; if your direction is wrong, AI helps you produce garbage at ten times the speed. I've seen people use AI to pile up a bunch of pages no one uses in a week, and I've seen people use AI to validate a product idea in a week — same tool, the difference is the judgment holding it.
So the divergence among programmers in the AI era isn't about "whether you can use AI" (soon everyone will), but about "whether your judgment is worth amplifying."
5. Day Job: Upgrade from "Translator" to "Owner"
So what exactly does "judgment" refer to? Let's start with the daily job.
Many frontend developers work with this posture: "Give me the design mockup, give me the requirements doc, and I'll translate it into code." Unreasonable requirements? That's the product manager's problem. Poor data? That's the operations team's problem.
Here's the issue: "Give me input, I'll give you output" — that is precisely AI's working posture. Working like a translator means you're competing with AI for the same position, and you can't win that race.
Conversely, the people commanding the highest premium in the market right now are a different type: they receive a vague business problem, figure out what the user actually needs on their own, define the solution, pull in resources, launch, monitor the data, and step up themselves when something goes wrong — the boss doesn't need to supervise them; handing things over to them brings peace of mind.
Why are these people expensive? Because the management costs, rework costs, and risk of incidents associated with "people who need to be supervised" are all deducted from their salary in advance; while "people who don't need supervision" save all these costs, and the money saved becomes their premium. The more capable AI becomes at handling chores, the scarcer this kind of "person who dares to own the outcome" becomes.
By the way, frontend developers actually hold a card that is severely undervalued by their own kind: in the entire R&D chain, frontend is the closest to the user. Backend sees interfaces and logs; you see living, breathing people every day getting confused, hesitating, and giving up on the page. "Understands tech + understands users + can execute" is the most sought-after combination right now, and you naturally possess two of those — don't play this card as "I just slice PSDs."
6. What to Learn So It's Not Wasted: Layering Your Skills
Frontend's most famous anxiety is "I can't keep up with learning." Today this framework, tomorrow that build tool — there's no end to the chase.
My solution is to layer skills into three tiers and invest differently in each:
Surface layer: Framework and tool APIs. The specific syntax of a framework, build tool configurations, component library usage. This layer changes roughly every two to three years — think about how many generations of frameworks frontend has cycled through. What you "can't keep up with learning" is really just this layer, and it's precisely not worth heavy investment: first, it expires; second, it's all public documentation, exactly what AI excels at. The correct posture for this layer is "learn just enough, look it up and ask as you go."
Middle layer: Platform and engineering principles. How the browser renders a page, what the event loop is, HTTP and caching mechanisms, approaches to debugging performance issues, what problem state management is actually solving. This layer barely changes in a decade — frameworks have changed many generations, but the browser is still the browser. More importantly: AI-generated code doesn't know if it's correct, someone needs to be able to spot what's wrong, and that "spotting" relies on middle-layer skills. This layer is worth deliberately digging deep into.
Bottom layer: Things unrelated to technology, but never expire. How humans use interfaces, what constitutes "good-looking and easy-to-use," how to explain something clearly (writing and expression), how to think from the user's perspective. As long as interfaces exist, these abilities will be valuable. This layer is worth a lifetime investment.
Why is the bottom layer ultimately the most valuable? Let's break the craft of frontend down to its root and ask: What does frontend actually do?
The essence of frontend is not "writing pages," but "translating the capabilities of computers into experiences that ordinary people can understand and use."
Frameworks are just temporary scaffolding for this translation, constantly changing; what remains constant are the two ends — on one end, the technical realities of browsers and networks; on the other, the realities of human eyes, human hands, and the human heart. AI can erect scaffolding for you, but it can't understand those two ends for you.
7. Make Yourself "One of a Kind": Intersect, Don't Be a Single-Subject Champion
Above I mentioned "move to where few people can go" — how specifically do you move?
Competing on a single dimension against top experts is the hardest path: to push one technical skill into the top 1% nationally, you have to compete with geniuses and grinders. But there's a much easier path: take two or three things each to the top 25%, and then stand at their intersection.
Top 25% in a single area is achievable for anyone who's serious. But at the intersection of "frontend + data visualization + finance industry," there might be only a handful of people nationwide; similarly:
- Frontend + motion design + brand marketing
- Frontend + AI applications + real workflows in a specific industry
- Frontend + developer tools + technical writing
At an intersection, there are no competitors, so the price is no longer determined by cutthroat competition. Which direction to choose? Here's a selection criterion: At least one of the three should be something that feels like "play" to you — the kind of thing others find a chore but you genuinely enjoy. The reason is practical: you can persist at this kind of thing for years without feeling tired, and others can't out-grind you — they're at work, you're at play; stretch the timeline, and the winner is decided.
8. After Hours: Don't Just Rent Out Your Time — Accumulate "Things That Lay Eggs"
Let's talk about an even bigger ledger.
Earning a salary at work is essentially "renting out time": you sell one hour and lose one hour; today's time is sold, and tomorrow you have to sell it again; your income is zero while you sleep. No matter how hard you try in this model, you're just swapping one hourly rate for another, with a clearly visible ceiling.
There's another kind of thing: something that remains after you've made it and continues to work for you. A technical article that solves a real problem, still being found by search engines three years later; an open-source component that people are still using while you sleep, bringing you connections; a small tool, a mini-course — the cost of selling the second copy is zero.
I call these things "bricks that lay eggs." The same two hours in the evening: take a low-paying side gig, and the money is gone once the job is done; write a good article, lay an open-source brick, and it will keep standing there.
And the biggest dividend of the AI era is precisely this: the cost of laying bricks has plummeted. A side project that used to take three months can now take shape in three weekends. Frontend also has a unique advantage — your work comes with its own display layer: a backend developer writes a library, outsiders can't see or touch it; the components, animations, and small tools you build can make someone go "wow" with just a link. In an era that runs on attention, this is a natural distribution advantage.
These experiments also share a great characteristic: the worst outcome is that no one sees it — treat it as practice, you lose almost nothing; but if one of them succeeds — an article goes viral, a tool gets widely used — it could bring job offers, industry reputation, even income while you sleep. Downside is capped, upside is uncapped; this kind of thing is worth doing consistently.
After doing it for a long time, a curious shift happens: at first, you're everywhere looking for opportunities; later, opportunities find you through your work. Every brick you leave publicly is taking on work for your future self.
9. Install a "Stop-Loss Switch" on Every Attempt
When building things on the side, the biggest risk isn't failure — it's pretending you haven't failed: a small product polished for two years, "almost ready, almost ready," never daring to put it in front of real users.
The antidote is simple: before you start, write down the failure conditions in black and white:
"Eight weeks after launch, if there aren't 100 real users, or if not a single person is willing to pay, this project stops."
When the deadline arrives, execute honestly. By the way, "whether someone is willing to pay" is the most honest test in the world — friends will cheer you on, colleagues will be polite, likes are free, only paying money doesn't lie.
Quickly admitting failure isn't shameful; it's about moving your limited spare time from something destined not to work to the next thing that might. The faster you test, the more times you test; the more times you test, the greater your chance of hitting that one that "succeeds."
10. Finally, a Few "Don'ts"
Having said so much about "what to do," "what not to do" is actually more important — because the ways to mess up are just a few recurring patterns; dodge them all, and whatever path remains won't be too bad:
- Don't bet everything. Don't quit your job to go all-in, don't borrow money to start a business, don't sink all your savings into an opportunity you can't even explain clearly yourself. Keep a few months' worth of emergency funds — its purpose is: when life throws a curveball, you don't have to sell off things that are growing, don't have to interrupt things you're accumulating. The scariest thing for something you've built up over years isn't slow growth — it's being reset to zero midway.
- Don't spend all your spare time on low-paying side gigs. That's still renting out time, and at a lower rate.
- Don't go all-in on the surface-level usage of any single framework. Frameworks are fast-moving consumer goods; your career is not.
- Don't fight industry changes with brute force. Working overtime won't bring back skill scarcity — the problem of oversupply has never been solved by working harder, but by changing positions.
Final Words
Condensing the whole piece into one paragraph:
AI devours the part that "you can learn by following tutorials" — that part was destined to get cheaper anyway. Your way out is to relocate: during the day, transform from "someone who translates requirements" into "someone who owns the outcome"; in learning, chase surface-level less, dig deep into principles, and invest a lifetime in abilities related to people; in direction, use two or three decent skills to intersect into a one-of-a-kind position; at night, rent out time less, accumulate more work that continues to work for you; install a stop-loss on every attempt, and never bet everything.
This era isn't gentle on frontend; it has burned away the premium on "standard work" completely. But from another angle: for the first time in history, an ordinary engineer, without needing anyone's approval and without much capital, can simultaneously possess the most powerful tools, a position directly reaching users, and channels to publish work to the entire world.
The ticket has never been this cheap — only the entrance has changed.
Keep pushing forward.