AI coding agents are reshaping frontend development education
A frontend developer and browser-performance writer opens by noting that many of the educators they admire in the frontend web space are stepping back: Axel Rauschmayer, Salma Alam-Naylor and Josh W. Comeau are, in the author's words, either bowing out or dialing back their efforts, and other well-known figures, Kent C. Dodds, Addy Osmani, Rachel Nabors and Lydia Hallie, have pivoted from talking about frontend development to talking about something else the post leaves unstated ("take a wild guess"). The author says they never made a living from writing about web development, but have run a blog, given conference talks and done podcasts about it, most recently about CSS performance topics like how the shadow DOM and the browser's style engine work.
As a test, the author asked Claude Sonnet, instructing it not to search the internet, how it would approach a Chrome performance trace showing repeated spans of high Style cost but relatively low Layout cost, a brain-teaser they say even experienced web developers routinely get wrong. They call Claude's answer "a perfectly admirable answer": it correctly explained that high Style cost with low Layout cost points to expensive selector matching and invalidation rather than geometry changes, and it named specific things to check, overly complex or broad CSS selectors, a class or attribute toggle high in the DOM invalidating large subtrees, per-frame style reads and writes that force repeated recalculation, and inherited or custom-property changes applied at a high level, along with Chrome DevTools' "Selector Stats" panel as the tool to confirm which. The author goes further: these days, despite having written about browser performance for years and having worked on a browser performance team, they say they would probably just hand a slow-loading site's Chrome trace to Claude Code and let it suggest the fix, and say they have actually done exactly that in their day job with good results.
Looking ahead, the author names several trends working against continued investment in frontend expertise. First, frontend code is lower risk to hand an agent unsupervised than something like a database migration: an agent-written database migration typically gets several rounds of AI code review, personal scrutiny and a staging run first, while an agent-written React component typically just ships, because frontend code is more ephemeral and replaceable than other kinds of code. The author expects many AI coders will feel comfortable letting an agent handle frontend work unsupervised, for better or worse, while stressing the risk isn't zero: an agent can still break accessibility or introduce an infinite loop that hangs the page for users. Second, developer experience is mattering less than what the author calls "agent experience." Pre-LLM frontend discourse, they note, citing Alex Russell's essay "The 'developer experience' bait-and-switch" as an example, weighed ergonomics against outcomes, and frameworks like Svelte and Solid have long argued their ergonomics produce better outcomes than React: less code, better performance. Yet Cursor and Viget have each blogged about migrating their codebases to React, from Solid and Lit respectively, and the reason, the author says, is simply that "the agents know React": a point Cursor states explicitly and the author suspects applies to Viget too, since React is heavily overrepresented in AI models' training data. Third, on standards, the author calls this part "pure speculation," having been out of the web-standards world for a couple of years, but expects less emphasis on ergonomic syntax proposals, better CSS shorthands, terser JavaScript, and more on capabilities that make the browser itself more powerful, since an agent barely cares whether it writes three lines of CSS or one. They predict that even as the emphasis shifts toward capabilities, the resulting body of standards content will be much smaller than what syntax-ergonomics debates used to generate, since capability proposals are rarer and more contentious for standards bodies to agree on. The author traces this back to a conversation at TPAC some years ago, before the AI coding boom, when someone on the Chrome team said they weren't interested in the web-component standards work the author was doing at the time, because APIs like shadow DOM and custom elements only change developer experience rather than making the browser itself more capable, citing Project Fugu as the kind of work that does; the author calls it a fair point, since such APIs give developers no new capabilities, only a different way to author the same thing.
Turning to what frontend education can still offer, the author names three directions. Agents still need to be taught the big picture: coding agents and harnesses default to writing React single-page apps even when a simpler multi-page framework would do, so the author suggests something like Astro or Eleventy for, say, a marketing site instead of a bloated SPA whose back-button, focus-state and performance bugs then need fixing. They guess that even if a framework like Astro is a little harder for an agent to work with, since it superficially resembles React without being React, writing roughly half as much code overall will make that friction not matter. Building sites that work well for agents is another direction, and the author points to Vercel's "is-agentic" as an example, though they note this really just means doing the same fundamentals (server-rendered content, proper accessibility, page speed) that public sites should have had all along. The author is less confident about this second direction and wonders whether the web survives in anything like its current form once agents, not people, do most of the browsing: they would rather ask an agent what a Seattle-to-Paris flight costs than click through a slow site's buttons themselves, and the only reason they can't is that such sites tend to block bots or skip offering an MCP interface, a gap they expect several startups are eager to close, though they doubt the current setup is sustainable. Third, the author sees a consulting opportunity fixing "vibe-coded" messes: a huge amount of AI-generated frontend code is being produced right now, and some of it will certainly become "load-bearing," a phrase the author credits to Claude; when a resulting site turns out slow, non-compliant or riddled with security holes, saying "fix my website pls" to the agent that built it won't be enough, and real expertise can step in, especially where money is on the line and the original vibe-coder's own understanding of web development doesn't go past "websites are apps hosted on the internet."
The post ends on a personal note the retrieved text only partly preserves: the author recalls an earlier decision, not detailed in what is available here, that turned out to be a good call, since covid went on to dominate their life for the next few years, "at which point yes, I did finally get tired of talking about it!"
Key facts
- Several well-known frontend educators, including Axel Rauschmayer, Salma Alam-Naylor and Josh W. Comeau, are bowing out or scaling back, according to the post's author, and others, Kent C. Dodds, Addy Osmani, Rachel Nabors and Lydia Hallie, have shifted focus away from frontend topics to something the post leaves unstated.
- Asked, with internet search disabled, to diagnose a Chrome trace showing high Style cost and low Layout cost, Claude Sonnet gave what the author calls "a perfectly admirable answer," correctly pointing to selector complexity, broad invalidation scope and unbatched DOM mutations as likely causes.
- The author, who says they have written about browser performance for years and worked on a browser performance team, now says they would typically just hand a slow site's Chrome trace to Claude Code for suggested fixes, and say they have done exactly that in their day job with good results.
- Cursor and Viget have each blogged about migrating their codebases to React, from Solid and Lit respectively; Cursor states explicitly, and the author suspects for Viget too, that the reason is "the agents know React," since React is heavily overrepresented in AI models' training data.
- The author expects agents to keep defaulting to complex React single-page apps even where a leaner multi-page framework would do, suggesting Astro or Eleventy instead and guessing that writing roughly half as much code overall would outweigh Astro being a little harder for an agent to use.
Why it matters
This is a first-person account, from someone who says they have written about browser performance for years and worked on a browser performance team, arguing that AI coding agents are changing both how frontend code gets written and why frontend-specific content and education are drying up. It matters because the claims are not just personal impression: Cursor and Viget have each publicly described migrating their codebases to React, and the stated reason, "the agents know React," points to a concrete mechanism, AI training-data bias toward one framework, already steering real engineering decisions rather than just developer sentiment. The same piece documents a visible shift among admired frontend educators (Axel Rauschmayer, Salma Alam-Naylor, Josh W. Comeau) and well-known figures (Kent C. Dodds, Addy Osmani, Rachel Nabors, Lydia Hallie) away from frontend-specific content.
Who it affects
Frontend developers whose day-to-day framework and workflow choices are increasingly shaped by what agents handle well rather than by ergonomics or performance; frontend content creators and educators, several of whom the post names as stepping back or shifting focus; companies picking a framework, illustrated here by Cursor and Viget both moving to React; and web-standards bodies, whose ergonomic-syntax proposals the author expects to matter less relative to browser-capability work. More broadly, it speaks to anyone maintaining a public-facing website, since the post argues such sites should now be built with "agent experience" in mind alongside human users.
How to use it
There is no product or price here: this is an opinion essay, and its practical content is the author's own recommendations. Favor a leaner multi-page framework such as Astro or Eleventy over a heavyweight React single-page app for a suited project, a marketing site for instance, on the guess that writing roughly half as much code offsets any extra friction working with an agent. Build public sites for agent readability, not only human readability, citing Vercel's "is-agentic" as one example, though the author frames this mainly as the same fundamentals (server-rendered content, proper accessibility, page speed) that sites should have had all along. And if the work is fixing a "vibe-coded" site that turned out slow, non-compliant or insecure, the author sees a consulting opening, especially where money is on the line and the original builder's own web knowledge runs no deeper than "websites are apps hosted on the internet."
How solid is it
This is one practitioner's personal essay on a blog, not a survey or study, and it says so in places: the standards-related predictions are explicitly labeled "pure speculation," and the claim that Viget migrated to React for the same reason as Cursor, "the agents know React," is the author's own suspicion, not something Viget stated. The stronger evidence is more concrete: a first-hand test of Claude Sonnet on a specific, checkable Chrome-performance question, and named, checkable claims such as Cursor and Viget's own blogged framework migrations and specific educators' names. The educator-departure observation is presented as a few examples the author personally admires or follows, not a systematic count, so it documents a pattern the author has noticed rather than measuring its scale. The post drew substantial engagement on Hacker News (100 points, 112 comments), which speaks to resonance, not to whether the underlying trend claims hold up.
Risks and caveats
The author is explicit that handing frontend code to an agent unsupervised is only "typically" lower risk, not risk-free: accessibility regressions and agent-caused infinite loops are named as real failure modes. They are also candidly unsure whether the web survives in its current form once agents do most of the browsing on people's behalf, given how many sites block bots or skip offering a machine interface. Read this as one experienced practitioner's early reading of a fast-moving shift, built on anecdote, a handful of named examples and self-labeled speculation about standards, rather than as a measured industry-wide study.
“For better or worse, React is heavily overrepresented in the training weights, and "agent experience" is starting to matter more than developer experience.”
— the post's author