LO
Frontend developer
Builds the surface people actually touch — and is left with the parts a generated screen does not survive: real devices, real networks, and the legal requirement that it work for everyone.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
Written for engineers who build web and app interfaces. It cuts by layer rather than by seniority — the junior and experienced software pages cut the other way, and a senior frontend engineer sits on both. Design itself is a separate occupation; native mobile and games diverge.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Turning a design into a working interface
Automating≈ Platform inferenceTaking a mockup or a description and producing the markup, styles and component structure that render it.
This is the single most exposed task in software engineering, for a mechanical reason: the input is visual, the output is text, the correctness is immediately checkable by looking, and the training data is the public web. Tools that generate a screen from a picture or a sentence reached usable quality before tools that generate a backend service did.
A screen that renders is not a screen that ships. It says nothing about whether the result is maintainable, whether it matches an existing design system, or how it behaves in the states nobody drew — empty, loading, error, half a list.
The states nobody drew
Still human-led≈ Platform inferenceEmpty, loading, partial, offline, error, slow, and the one where the user pressed the button twice — deciding what each should do and making it happen.
Generation works from the happy path because that is what a mockup contains. The other states are where most of the actual code lives, and deciding what each should do is a product judgement about this specific product rather than a pattern to retrieve.
This is a judgement about where the work sits, not a measurement of it. We hold no record of teams counting how much of their frontend code is edge-case handling, and the balance differs enormously between a marketing page and a trading screen.
Making it survive real devices and networks
Being augmented≈ Platform inferenceThe old phone, the slow connection, the browser two versions behind, the screen reader, the bundle that got too big.
Tools measure and suggest here better than people do — budgets, audits and profiling are exactly the kind of mechanical checking software is good at. What they cannot do is decide which trade-off to accept, because that depends on who your users actually are, which is a fact about the business and not about the code.
Nothing here says how many hours this takes or whether teams do it at all — a great deal of shipped frontend work never gets this attention, and the tools existing does not mean they were run.
Making it work for everyone, because it is required
Still human-led≈ Platform inferenceKeyboard paths, screen-reader semantics, contrast, focus order — and, increasingly, being able to show that you did it.
Automated checkers catch a minority of real accessibility failures and cannot judge whether a flow is usable by someone who cannot see it. This task is also the one moving from good practice toward legal obligation in several markets, which changes who is answerable rather than how hard it is.
This site holds no verified record on frontend accessibility enforcement yet, so the direction here rests on the shape of the requirement rather than on a measured outcome. Requirements differ by market and by whether the product is consumer-facing.
Owning the components everyone else uses
Still human-led≈ Platform inferenceThe shared library: deciding what belongs in it, what a change breaks, and who has to be told.
Cheap generation makes this more load-bearing, not less: when anyone can produce a screen in minutes, the thing that keeps a product coherent is the constraint layer, and somebody has to hold it. The work is refusal and versioning rather than authorship.
Whether this is a job or a side duty depends entirely on team size, and we have no evidence either way about how many teams staff it deliberately.
Building interfaces for things that answer back
New task≈ Platform inferenceStreaming responses, uncertainty, citations, stop buttons, and what the screen does when the model is wrong or slow.
This is work that did not exist before generative features shipped into products, and it has no settled patterns — every team is currently inventing how to show that an answer might be wrong. It lands on frontend because it is a question about what the user sees, not about what the model does.
New work appearing is not the same as new headcount: this is being absorbed into existing roles, and nothing here says anyone was hired to do it.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
The steepest software curve on this site, and the mechanism is specific rather than a judgement that the work is easy: the most visible task here takes a picture as input and produces text as output, correctness is checkable by looking, and the training data is the public web. The 2024 jump is generation reaching the point where a whole screen arrives at once rather than a component. It flattens at a high level because what is left does not have that shape — the states nobody drew, the devices nobody tested on, and an accessibility requirement that is becoming a legal obligation rather than a practice. Read the height as exposure on the visible half of the job, not as a measurement of the job.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
No verified events recorded yet.
This section will fill from the monitoring pipeline as events are collected, de-duplicated, graded and linked to the tasks above. An empty list here means we have not verified anything — it does not mean nothing is happening.
"We found no news" is not the same as "you are safe."
What this means for you#
The task you would previously have been hired to do first — turning a design into a screen — is the one most exposed here. That is worth knowing before you spend a year getting fast at it. The parts that hold are the states nobody drew and the requirement that it work for everyone, and neither is taught by building portfolio pages.
Your leverage moved from producing screens to constraining them: the design system, the states, the performance budget, the accessibility obligation. That is less visible work and harder to show in a portfolio, which is a real problem when you next change jobs — start keeping a record of what you refused and why.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Own the constraint layer
When screens become cheap, the scarce thing is the person who keeps a product coherent — the component library, the states, the performance budget.
It is low-visibility work that is easy to be taken for granted, and it needs a team big enough for consistency to matter.
Take one screen in your product and list every state it can be in. Then check how many of them actually exist in the code.
Become the one who can prove it is accessible
This is moving from good practice to obligation in several markets, and an obligation needs a named person who can demonstrate compliance rather than assert it.
Requires learning to test with assistive technology rather than with a checker, which most engineers have never done.
Turn on a screen reader and complete one flow in your own product without looking at the screen. Write down where you got stuck.
Move toward the product decision
Frontend engineers see what users actually do more directly than almost anyone, and that observation is the raw material of product work.
Requires giving up being the person who knows the code best, and learning to argue with numbers rather than with taste.
Find one feature you built that nobody uses, and go and find out why. The answer is almost never what the team assumed.
Common questions#
No number here would be honest, and the question is better asked task by task. Producing a screen from a design is already largely done by machine; deciding what the screen does when the data is missing is not, and neither is being answerable for whether it works for someone using a screen reader. A signal you can check yourself: how much of your last month was spent typing markup versus deciding behaviour. If it is mostly the former, the exposure is real and the move is toward the latter.
On its most visible task, yes, and the reason is mechanical rather than a judgement about difficulty: the input is visual, the output is text, correctness is checkable by looking, and the training data is the public web. But most of a real frontend codebase is not that task — it is the states nobody drew, the devices nobody tested on, and the constraints that keep a growing product coherent. Exposure on the visible half is not the same as exposure on the job.
Breadth is not automatically protection, and that is the framing worth dropping. Two shallow exposures are easier to replace than one deep one; what protects is being the person who can be trusted to judge, and judgement is domain-specific. If you cross over, cross for a reason — the states and the data model are genuinely connected, and understanding both makes you better at the boundary, which is where most bugs live.
It is still asked for, and it is a weakening signal for the same reason the first task on this page is: a reviewer now knows what a good-looking screen costs to produce. What has not weakened is evidence of judgement — a component you removed and why, a state you handled that nobody specified, a performance budget you held against pressure. Those are harder to assemble and much harder to generate.
Method and sources#
- Assessment date
- 2026-09-12
- Basis of the task judgements
- 0 evidence-backed · 6 platform inference · 0 not enough evidence
- Verified events
- 0