LO
Frontend developer — tasks, one by one
The unit of analysis is the task, not the job title. Each one below carries its direction, whether the judgement rests on evidence or on platform inference, the reasoning, and what it does not establish.
Every task on this page#
Turning a design into a working interface
Automating✓ Evidence-backedTaking 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. Teams do not count how much of their frontend code is edge-case handling, so there is no figure to check this against, 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.
The direction here rests on the shape of the requirement rather than on a measured outcome, and what would settle it is an enforcement action that names a specific interface and what was wrong with it. Requirements differ by market and by whether the product is consumer-facing.
Owning the components everyone else uses
Still human-led✓ Evidence-backedThe 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 how many teams staff it deliberately is not something anyone counts.
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.