An audit I ran on my own product's front end found four editable lists that tracked rows by position over arrays changed in place. It compiled, and nothing in the build complained. Removing a middle row made the framework reuse the deleted row's DOM node for the next item, so per-row input and focus state could attach to the wrong row until a full re-render. A review focused on style would approve that diff. I fixed all four and added a spec that pins the behavior. Catching that kind of bug is a bigger part of the job now.
Netguru writes that senior front-end work in 2026 looks less like writing components and more like directing a system that writes them. The first part matches what I see: producing a component is no longer where the value is. I would describe the rest differently. Directing sounds like management, and the work feels more like reading, deciding and making the wrong thing hard to do.
I build my own product, MailHive, with Angular 21 and an AI-assisted workflow, and until August I was the sole front-end developer on a five-developer team at BMO. In both, the component was never the hard part. AI just removed the cover that typing it used to provide.
Read for Behavior, Because Style Stopped Being Evidence
Generated code looks clean. Good naming, tidy structure, comments in the right places. Those used to be weak signals that the author had thought things through. They are much weaker evidence now. You have to read for what the code does when the state changes.
Whether a person or a model typed them makes no difference to the reviewer. The trap is the same in both frameworks I work in:
<!-- Angular. Position is not identity when the list mutates. -->
@for (condition of conditions; track $index) { ... }
<!-- Follows the object while its reference is stable. Prefer condition.id if you have one. -->
@for (condition of conditions; track condition) { ... }{/* React. Same trap. */}
{rows.map((row, i) => <Row key={i} {...row} />)}
{/* Follows the item. */}
{rows.map(row => <Row key={row.id} {...row} />)}A concept like this travels between Angular and React. A list of tool names does not.
Own the States Nobody Asked About
Ask for a screen and you get the screen. You get the happy path, rendered well. The senior job is the list the prompt did not mention: the empty account, the slow network, the failed save with half the form changed, the permission revoked mid-session, the screen reader, the French label much longer than the English one. If you have worked from Figma to production, you know this list is most of the real work.
My UX background helps here. Those states are a product decision before they are code. What should the user see when this fails, and can they recover? A model will happily invent an answer. Someone has to notice it was a decision at all, and take it to the person who owns it.
Turn Your Taste into Constraints
Reviewing the same mistake twice is a sign the check should be automated. The first time you see it, ask if a machine can catch it from then on. Here is some of what lives in MailHive's repository now, several items from a repository audit and not from a single bug:
- Lint rules that enforce module boundaries, so a new import from one feature into another fails, with existing violations baselined.
- Accessibility template rules on every template of ours, with existing violations baselined so that only new ones fail.
- A check that all four language files carry the same keys, so a missing translation key fails the pipeline and not the user.
- Project instructions the AI reads, plus a record of past bugs it must not repeat, where each entry has to reference a real incident.
- Decision records that explain why an architecture choice was made, so neither I nor a model reopens it by accident.
Each one makes the next thousand generated lines a bit safer. Google's DORA research calls AI an amplifier of an organization's existing strengths and weaknesses. At the scale of one repository, the constraints are what get amplified, or the lack of them.
Say No Early, Because Code Is Too Easy to Add
When adding code costs almost nothing, the temptation is to add it. Every generated abstraction, helper and service still has to be read, tested and migrated by someone later. Deleting code and refusing to generate it both count as work. MailHive has a CI job, knip, that fails on unused front-end code, because volume alone will bury a small product.
It goes the same way with big rewrites. A model will happily plan and draft one, and it will not be there to explain the regression to the customer. Someone has to weigh the risk against what the business gets, and say out loud when the answer is no.
Keep the Skill That Lets You Judge
This is why directing does not describe the work for me. You can only judge a finding like those four lists because you understand how a framework reconciles a list. You judge generated code with knowledge that came from writing and debugging code. If you stop building that knowledge, your reviews get weaker, slowly, and nothing warns you.
I do not have a clean answer to that risk, especially for people earlier in their careers. Stanford's Digital Economy Lab finds employment of 22 to 25 year olds in highly exposed jobs about 19% below where it would be had it kept pace with less-exposed peers, with no comparable gap for experienced workers. The authors call that descriptive, not causal. It still worries me, because today's juniors are where the next seniors come from. What I try to do myself: go deep on purpose in the areas I am accountable for. Write the difficult part myself when I need to understand it. Treat an AI explanation as a starting hypothesis, then read the framework docs and the failing test.
What to Show in an Interview
A Stack Overflow blog post from October 2026 gives employers one sentence worth keeping: hire for judgment, not for a list of tools. Tool fluency matters, but it is the easiest part to show, and most candidates list Copilot or Claude Code now. These are the stories I would prepare instead, with a real example for each one:
- A time you caught something that looked right and was wrong. What gave it away?
- A guardrail you added after a mistake, and what it has caught since.
- A state or flow that nobody specified, and how you got the decision made.
- Something you decided not to build, and what that saved.
- How you decide which AI output gets a close read and which gets a quick one.
Each of those is a story about judgment, and judgment is what the role now asks for.
References
- Netguru. Is frontend development dying? https://www.netguru.com/blog/is-frontend-development-dying
- Stack Overflow Blog. Is AI really reshaping the developer market? October 2026. https://stackoverflow.blog/2026/10/22/is-ai-really-reshaping-the-developer-market/
- Brynjolfsson, Chandar, Chen. Canaries in the Coal Mine, Stanford Digital Economy Lab. https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/
- DORA. 2025 State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/
- Angular. Track expressions in @for blocks. https://angular.dev/guide/templates/control-flow
- React. Why React needs keys. https://react.dev/learn/rendering-lists
- knip. https://knip.dev/