You can argue that abstractions hide consequences that fall on users who didn't choose them, but I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.
The end result is more crunch and a sharp decline in software quality, maybe even job satisfaction in general. As an (unfortunately anecdotal) example, I started to find myself fixing up broken websites or removing elements that get in the way with dev tools and uBlock every once in a while, and have heard from other people on here that they have been doing the same (https://news.ycombinator.com/item?id=47042747). All to restore basic functionality of websites I go on. This was never required back in the day, Flash and early web browsers didn't even have the option to do this.
Another, less anecdotal example from a while ago: https://news.ycombinator.com/item?id=47390945
It gets worse when you realize that most of the money saved through these cuts only benefits the very top of the hierarchy.
Not to mention there are 1000X as many skilled engineers and you are competing with a global market. In the early 2000s there was very little competition. The skills of workers are loosely going to correlate with the demands the market puts on them, and it is extremely competitive now.
This was a small part of a large code base. I am afraid what a fully agent coding would look like. How are other developers handling large code bases with ai. Just accept what its providing?
I can now understand the valuation of AI companies. Once you go in ai its difficult to go back. You need to spend more tokens just to make it work. Ai companies could train to make their code more obtuse, making users very hard to change manually!
Do you really need to go that far back for a comparison? We no longer need human computers to perform tedious calculations, or typists to draft and distribute correspondence.
The simplification of frontend development was never a final state. It has always been continuously evolving through abstraction and automation.
Once you are using AJAX and manipulating the DOM the complexity of asynchronous communication is going to lead to something of a similar magnitude as React. Sure you can write
document.title="A new title"
If there's something wrong with the Reactisphere it isn't that it creates an abstraction which other abstractions live on, but these are leaky abstractions. You could use something like Bootstrap or MUI without understanding CSS if you are making something very simple and don't care what it looks like (don't have a marketing team who cares what it looks like!) but to do pro-level work you can put in front of customers you have to understand HTML, CS, JS and all the the frameworks used in your project.
In the case of frameworks ( and higher level programming languages ) you are operating at a new layer of abstraction with the specific intent to hide the lower level, that's the whole point of the framework.
LLM's don't actually move the abstraction layer. You're still coding in react/python/whatever high level language. Yes you can generate the code using natural language but you still need to understand what's being generated, verify its correctness, and reason about the system it fits into. LLMs don't hide anything they produce the code you otherwise would've written and hand it to you to review.
I've seen people argue that LLMs will just add another layer to the top of the compiler stack: instead of writing code, we'll use English, and run it through a pipeline:
English -> Rust -> ASM -> Machine Code
But what the author says about agents being "undeterministic abstraction" shows why that will never work.
Compilers rely on a concept called observational equivalence[1] to define when two programs are basically the same; this allows them to make changes under the hood like unrolling a loop or targeting another machine. Now, it turns out we know a lot about how and how not to do this, thanks to a logician named Frege who worked out exactly which properties a "definition" would need to have to count as a definition without becoming an axiom. In particular, that it should be "eliminable" and "conservative"[2]. In plain language, that a formal definition should always be able to be eliminated by rote string substitution, and that it shouldn't smuggle in any extra assumptions. When we talk about things like syntactic sugar[3] or hygienic macros[4], we are basically applying Frege's two conditions to programming languages.
LLMs are neither. They cannot reliably or provably go from the prompts they are given to the source code they generate, and they make a ton of implicit assumptions when they do so. There can never be any equivalence between two "prompts" in the same way that two programs can be equivalent modulo some level of abstraction. The whole process of starting from prompts is wildly nondeterministic, which is why the only pattern that works is to generate the code, review it, and test it, and then check it in and use that as the starting point for the next prompt.
Which is not to say that LLMs aren't useful for code generation; they clearly are. But they don't provide an abstraction that lets us get away from the details of actual code, and thanks to Frege we can understand why they never will.
I can say all this with such confidence because I did once write a wild little Python library that used a bunch of introspection to actually do this[5]. And it absolutely did not work in practice beyond toy examples.
[1]: https://en.wikipedia.org/wiki/Observational_equivalence
[2]: https://plato.stanford.edu/entries/frege/#ProDef
[3]: https://en.wikipedia.org/wiki/Syntactic_sugar
I guess some frontend frameworks can abstract it away but most don't and you almost certainly will run into the limitations of those frameworks and then you still need to understand HTML/CSS
What does he mean by this? What skills were lost? Writing HTML templates?
1. Arguments like this seem to be based on the idea that, prior to AI, most of this type of work was being done by skilled artisans dedicated to quality work product. As I think anyone who actually worked in the industry and is being honest knows, this wasn't the case. There was a lot of mediocrity and worse.
2. I'm not sure the work is "lower quality" depending on how you define "quality". AI might result in an uncomfortable uniformity but at the same time, a lot of AI work product is pretty darn usable because the models have been trained against conventions that, love them or hate them, "work" for the vast majority of end users.
SVG+CSS+HTML were hailed as the modern replacement for Flash, but nobody ever made an authoring tool suitable for the masses. LLMs are kind of fixing that, just with a very different interface
It really feels strangely familiar to me: you could get very far very quickly without any real deeper knowledge and have a working web application within a few minutes. It felt like magic. Then you could customize it within the framework by skimming documentation and googling around until... you couldn't, because you had no clue how any of this really worked internally. And just like with vibe-coded web apps, you could recognize the standard framework web app that was patched together in an afternoon from a mile away, but it very much impressed managers.
Amusingly, I sometimes find that developers talk about their go-to frontier model in the same way that GUI developers talked about their favorite web framework ~15-20 years ago. Personification of the tool, even identification with it, frustration that things that worked with version X got worse with version X.1, "I am developing things 10x faster now", "I am going back to writing XYZ by hand", etc.
Modern frontend, or the "tower of leaky abstractions", is finally a common-sense mental model for web development. Supplanted by force on top of an exploding bag of eccentricities that is web standards and conventions. The fact that it works at all and is merely a little leaky is an accomplishment in itself.
Literally just saw startup demo their app and their app which had that “vibe coded UI” look to it.
They were given devastating feedback of “Guys this is kinda cool, but you obviously had AI build this and thus anyone else that wants this can have AI build it for them too very quickly. As such there’s really no value in what you’re trying to sell here.”
It was cold, but accurate feedback they needed to hear.
>What did previous generations of craftspeople do when everyday goods and buildings suddenly could be mass-produced by industrial processes? One reaction was to copy the style of old, and make the industry crank out widgets and buildings that at least looked like they were handcrafted.
Is this a reaction by craftspeople? I don't think it is, I think this was what industry people did?
>Countering this trend of historicism, an alternative approach was developed by the Bauhaus movement of the early 20th century. Instead of pitting factory workers against craftspeople, their stated goal was to have them work together, and redevelop the arts and crafts with industrial manufacturing processes in mind.
From what I understand the Bauhaus movement has/had a huge influence on modern architecture, which people tend to like less than traditional architecture [1]. It feels weird to have that followed by "Caring about quality and the user".
>The industrialization enabled lots of cheap plastic products, designed by people who didn’t take the time to think how they would be used and by whom – yet good industrial design is still a thing.
>And software like Wix and Next.js enabled the creation of lots of websites that load terribly slow and are not accessible – yet there are still practitioners of the front of the frontend out there.
I think the author really really really underestimates how important is it that something is "cheap". I personally like a lot having the option to use cheap and relatively good stuff, or pricier and better stuff, for most things.
This is a bit stretching the definition of "accessibility" but, I think in a way price should be thought as part of accessibility. If we consider that it's important that websites work well on slow networks, partially because not everywhere in the world has access to good network, partially because good networks cost money ; then I think we should consider that while a good website beats a bad website, sometimes a bad website beats no website. Sometimes a "cheap plastic product" means someone that can't buy the well designed product can still buy a product, and get started in a hobby.
This is pretty bad news for craftsmen I think, but as a software engineer that is very happy to be able to get into crochet or photo or cyanotypes or pottery or hiking for relatively cheap, I can't help but try to see the other side of software getting cheaper.
[1]: https://www.sciencedirect.com/science/article/pii/S026427511...
And let's be honest, one of the best changes front-end development has seen is how previously complex problems now have built in, easy to use solutions. Yeah you could say it was harder to code layouts when flexbox and grid didn't exist and you had to deal with floated elements and absolute positioning, but the new setup is just better for everyone.
Customising select menus used to require lots of CSS and JavaScript to remake the element. Now browsers are implementing features to let you customise default select boxes the same way. Having an element expand to auto height use to involve JavaScript. Now it's something you can do in CSS alone. Creating modals used to involve writing CSS and JavaScript. Now an accessible and efficient version can be done with built in tech.
Meanwhile JavaScript frameworks are really just continuing the pattern started by previous tools, like WYSIWYG editors, Content Management Systems, jQuery, etc.
At the end of the day, any tech that gets more advanced will lower the skill floor and reduce the need to care about those minor intricacies. Most people don't need a particularly advanced solution to their problems, so whatever system can automate away most of the work will get used for that. It's not unique to web development or software engineering.
Not to be rude but this person doesn't understand the fundamentals of the topic they're discussing.
Frameworks just give patterns and abstractions to build a front-end, but you still have to actually know how to use those things to build a UI. You still have to know HTML, CSS, and JS (assuming you want to do it well, not just slap some junk together). Even with AI, unless you're comfortable shipping a half-working UI, just like programming: sorry dude, you still need to know your shit.
With Stack Overflow, you got multiple answers from different people with different viewpoints and different approaches, each consistent within itself. You could figure out where the author of each answer was coming from and judge whether they seemed to know what they were talking about. You could weigh the trade-offs and merits of the different answers against each other.
With LLMs, you get a single mushy pile of slop, not grounded in any person's actual experience or judgement. It might pretend to offer different perspectives, but it can't really, so it's much harder to evaluate.
Flash is/was the true time for front end innovation and people making cool unique stuff. html and javascript and usability studies killed all the fun and imagination
At the end of the day, I have to make more architectural and business decisions than before - it’s just higher-level and more complex work.
On the other hand, there’s increasingly little reason to hire someone just to write APIs or work on the frontend, since AI handles most of the routine tasks.
So, this feels much more like the Industrial Revolution than “deskilling.”
It still is!
> To distinguish what they’re doing from what “frontend” has become, practitioners of this arcane art nowadays often refer to it as the “front of the frontend”.
I have never heard this term before, but I'm sure someone will point me to the bullshit influencer who came up with it?
Frontend frameworks are really just for web apps and most frontend devs are familiar with several. If they cannot also write a web page from scratch, they're not really a web dev. This is not up for debate. If you hire someone for the role, you need them to handle the work. AI is not going to help you here when it gets into the testing and bugfix phase.
As someone who didn’t really know that being a front-end dev putatively doesn’t involve thinking about those things anymore, I think that list conflates a couple of different things.
Things like the differences between browsers and CSS/HTML quirks, needed to wrangle a document markup language into creating user interfaces, are accidental complexity caused by particular path dependencies, and if they can be abstracted out, that’s a great thing.
Accessibility, interface design, performance, and other things related to user experience, on the other hand? Those are mostly orthogonal. A UI framework can raise (or in some cases lower) the bottom in the sense of facilitating reuse of (hopefully well-designed) components, but no framework is going to make your UI accessible or well designed by itself.
In the fabled past, frontend development didn’t require you to be highly qualified in these matters – web UIs were simply terrible, mostly. High skill level was not required because nobody expected anything from web UIs beyond the barest core functionality.
There was UI programming before the web [citation needed]. In a sense it was "deskilled" because you used a "framework" aka the OS windowing and widget libraries rather than drawing rectangles manually (except in some special cases like games where very custom UI is desired – but those custom controls invariably have roughly 0% of the UX affordances provided by standard ones). Back then, Visual Basic and other RAD tools (anyone still remember that acronym?) were front line of "deskilling", but honestly WYSIWYG visual design is still one of the best ways to create UIs, it’s just rarely done these days for various reasons.
I’m actually building better UIs just because it became less time consuming to do so.
There is just a super noisy minority that spams the internet with slop so bad that no one can take their product seriously.
This is now officially a pet peeve of mine. I don't write code "by hand" I write code "by brain." A craftsman who does something "by hand" actually needs manual skills to produce that carved wood thing. Even if you know what you want and know what it looks like, you need skill with your hands to make it happen.
Software is not like this. I don't need typing skill, the IDE autocompletes most of it for me. I think about what I want and it becomes reality. If you were using a bare text editor and typing out getters and setters your whole career, sorry, you were just doing it wrong. No wonder you love AI.
But before React, I don't recall frontend as very inspiring and joyful.
It was fun to see your work immediately on the screen. I did apply skills and had to solve some weird situations. I could optimize our CSS with OOCSS approach (later used in Bootstrap) -- only to complaints -- semantics! too many classes! (my trump card was that their commits contained +200 lines of CSS, while mine mostly had 0 -- and our CSS was already bloated into several megabytes).
But this was a dead end. I tried making tools to find out unused styles, to automate some patterns -- like click a button and load some content over Ajax. But the guys, who copy-pasted code with dumb solution to this, got 2-3x more tickets closed. I proposed a tool to make screenshots of pages and diff them to search for regressions, but the response was it's heavy RnD, we're not a research institute, we got to ship the next popup tomorrow, etc.
Nobody gave a shit much earlier.
If LLMs help me never use a front end owned/dictated by a corporation again it'll be no bad thing, regardless of the quality of the code they write.
This idea that quality ever existed on the web is ahistorical at best.
I think the original author has a much stronger thesis around AI devaluing the craft of coding, but his specific examples don't stack up.
Both have been lost; good riddance the former, but I miss the latter.
Only when you have a PR problem does the business switch back to signalling quality, like Microsoft, although it remains to be seen if they still have the quality part. Most of the craftspeople get to say 'told you so' but also it looks like a sinking ship to them. Once the PR problem is gone, it's back to shipping at the expense of quality.
This cycle conflicts with the idea of a craft, which is that you should do it that way all/most of the time. The business will stop caring about quality long enough that your skills will erode, making it a bad mix. Trying to practice a craft where you aren't in control of this cycle is corrosive to the spirit.
Apparently deskilled people are making it look like this is normal and it supposed to be so.
But i can relate to that. Another examples of deskilling would be, of course, Java, and a more modern example - Rust.
That said, i don't think deskilling is solving mass-production problem. It was already solved with open-source software, or with a software as is.
Software is information and there is little to no cost of copying information. So mass-production isn't the problem that is being solved here.
IMO the problem being solved is that business need unskilled labor, that is slop.
You would think that if business is producing slop, it will be replaced with another business producing quality stuff. If that was so, over time, there won't be any slop on the market, but if you open your app store, you are welcomed by all kinds of slop.
Because slop is what they buy. Supply is only following the demand, business need to produce slop because people are buying it.
How many of you guys have Claude subscription? Do you know that 5 years ago i would be asking "How many of you guy have GitHub Copilot subscription"?
This is what people buy, so it is deskilling, but not a mass-production, it's just slop revolution, slop is the new norm.
I'm sorry but that simply does not make any sense. How is increasing the breadth of your skills leading to a deskilling?
I remember this period differently. The frontend work was mostly, sometimes solely, all about turning whatever monstrous PSD came from the designer’s sick mind into HTML, and getting shafted if the result was not pixel-for-pixel identical. When project leads heard the word “semantic”, they had to reach for the dictionary. Upon hearing the word “accessibility”, they would set the dictionary on fire.
Compared to the status quo where people pretty much never consider these things, like accessibility, especially not for an MVP? How many people have never added written aria attribute? I would suspect 90%+ of people touching the frontend.
The difference with LLMs is that (1) they have a latent rigor for things that you weren't going to spend time caring about anyways and, more importantly, (2) you can encode these things into prompts (AGENTS.md) and processes so that they happen even when you weren't going to invest the time with or without AI. For a lot of people this only means collecting some generic "skills" they found online yet it's still much better than what they were going to do pre-AI.
That's why I think AI is saving software in some ways, not leading to worse software.
Or, asserting that AI will botch software might hold more weight with people who have already forgotten how dogshit software was pre-AI.
De-skilling for skills that just aren't that relevant anymore because we've solved the problem (with AI or otherwise) has been a constant in our industry ever since computers were invented.
Move on, learn new skills. And actually effective use of AI is a skill some people seem to be struggling with. Stuff still doesn't build itself. If you can prompt it right, you can get it done. But are you prompting right? Are the tools doing what you ask them to do? How do you know? Did you check? I seem to spend an awful lot of time prompting AIs. I'm definitely getting better at it. But it's still a full time job.
And I'm sure in a decade or so we'll look back on this as a very inefficient way to build software. The tools will get better. The AIs more autonomous, etc. Because if you spend a day doing repetitive things prompting the same things over and over again, somebody or something should probably automate that!
This one, for instance:
> But exactly which details are deemed “unimportant” is a very consequential and sometimes subjective decision. And eventually, the details always leak through.
Right, so you're saying this new technology will still reward deep technical understanding, because there's no way around it. I agree. Why is the whole tone of this thing "AI is making my craft a cheap commodity?"
Websites are largely better, technically, than they were 10 years ago. They're more full-featured, they're faster, SSL/a11y/responsiveness are stronger defaults. Content mills / SEO / news sites are a separate, terrible failure mode of ads and corporate incentives. That's not React's fault!
I still don’t understand this perspective, how is it good when a growing portion of stuff that’s built is straight garbage?
And I'm sure I'm not alone in feeling that the convenience from ignoring the "deep expertise" and piling on hacks and lazy abstractions, all the way to modern multi-MB frameworks and Electron, is a regression.
Of course no one gives a shit about things like the user's computer/memory utilization. Or degraded experience. Or wasted bandwidth. Or the extra energy costs per 8 billion people - and the environmental impact.
>More people building things is straightforwardly good,
Is more people building public infrastructure "straightforwardly good"? If it means worse roads, worse bridges, systems that fail?
The same holds for software. And most things really.
Big corporations behind LLMs are taking it all.
Is it? I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem.
Sure, the browser is slightly more difficult due to maintaining backwards compatibility and multiple implementations, but I’ve yet to see a better UI framework/language that has to deal with the other constraints of the web platform.
No, other people did. They wrote about it, and LLM can sometimes use that. Once they no longer write about it, what then?
> More people building things is straightforwardly good, and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
That I agree with. The more the merrier, all else being the same. And if "AI" trickled into everything because of the undeniable improvements it leads to, the situation and most of the sentiments would be very different, I think.
But even then, people aren't entitled to the knowledge "created" by doing the work. If attribution and compensation were tackled in earnest, if you could only train on the materials of the people you pay to produce those materials, it might be much quicker and cheaper to just learn CSS.
Some people go on a bicycle because they can't afford a car. Should car makers see those people as a problem?
> The end result is more crunch and a sharp decline in software quality
If you have 10 people eating steak and 10 people starving, then giving rice to the starving people would also sharply decrease dinner quality.
AI software is not the difference between good or bad, it's the difference between something or nothing.
The effect of this is that people who never learned those things are working with a limited toolkit both in solving problems and debugging. And every so often I get to blow someone’s mind with an old trick :)
It’s not all bad though! I’m happy to never build a layout with floats again.
Some of us were lucky to have a few periods in our career where this was the case. I would agree that this disappeared prior to AI.
I think this is more of "another brick in the wall." There was already a LOT of pressure to do the bare minimum to fulfill requirements and then declare success. Now, those pressures seem insurmountable.
The author having worked with various technologies over time is also not an example of "deskilling", it's a way of asserting that they have had time to observe the deskilling of the domain (since deskilling means a particular domain requires less specialised skills than it did before, not that the workers are losing skills) happen.
Low accessibility, terrible performance, lack of any fundamentals of html and css, abuse of those awful solutions like Tailwind or using 2016 technologies like React for rendering what should mostly be static websites + some web component, all plagued by memory leaks and very basic usability bugs.
The entire complaint here is that automating this risks that was is encoded is not what you want.
I think I also reject the premise of the article, that frameworks caused frontends dev to de-skill. For sure, that happened to some extent. But it also caused a lot of frontend devs to be incredibly skilled in their chosen niche. (React for instance.)
But the key here is: LLMs don't have latent rigor, nor any other kind of rigor.
If our hypothetical developer hasn't used any accessibility-related tags before, what chance is there that those parts of the website will receive adequate testing?
Please note that that "any designer" should have had at least a fairly decent knowledge of ActionScript because Flash wasn't all just magic and sparkles. I know this because I was one of them. Though I had to learn ActionScript by neccessity, I actually learned HTML/CSS/JS before needing to deal with AS
Hand-waving AS3-driven app development in the 2010s as ‘some slight JS knowledge’ makes me doubt you were actually there. I was there, and that was not what was happening.
I'm doing the latter btw, so I know what they get wrong, but it won't fool me into building an unmaintainable mess. My frontend skills come in real handy every time the agents go off the rail.
Sure, as you pushed it further, like add versioning to objects, things got very tricky and not guaranteed to work, and no way to fix.
But otherwise, yes, the attitudes look similar.
Rounded corners still seems to be the unending trend through that anything that wasn't already well defined gets infected with.
That could be a good thing, or a bad thing.
Maybe it will push more people into medicine, science, art, or other worthwhile careers.
Or maybe they'll end up lawyers, SEO experts, or venture capitalists.
It could go either way.
Unions are, by nature, anti-progressive. They would rather use 15 year old technology, then replace workers and allow efficiency.
This will never work in the tech industry.
Edit: There's not just one lost decade of the web. There's the browser wars and IE stagnant dominance. There's the 2010s with millions of man hours spent on web components and starving other directions of resources or actively hindering them (e.g. scoped css was continuously postoponed because it's highly incompatible with Shadow DOM) while pushing everything into Javascript (and partly breaking JS e.g. with the bolted-on class-based OOP).
It remains to see if Google's complete dominance breaks the web further
<!DOCTYPE html>
<!--[if IE 8]> <html lang="en" class="ie8 no-js"> <![endif]-->
<!--[if IE 9]> <html lang="en" class="ie9 no-js"> <![endif]-->
<!--[if !IE]><!-->
<html lang="en" class="no-js">
<!--<![endif]-->
But again, accidental complexity. The web platform is utterly rotten. So the people we should blame are chrome et al for not providing a standard lib or anything approaching a reasonable UI framework, which forces people to reimplement what a competent platform provides.
Electron is an artifact of the richest companies in the world prioritizing their platform monopolies and trying to increase their stranglehold on businesses by forcing them to write platform specific code, which is hysterically expensive to build and maintain. When I'm confronted with writing for web then reimplementing for mac and win... the answer is electron. I don't think anybody likes building in Electron; it's just it's that or +200% (or more) eng headcount to build 3 apps, one per platform.
That CSS and web never really addressed did they? There's almost nothing in the web platform to build rich user interfaces. You can barely do styled text.
CSS and HTML are literally littered with accidental, ad-hoc, badly thought-out and badly designed one-off solutions, often to problems no one asked for. There's a reason it took until 2026 to animate `height: auto`. There's a reason why `article` "semantic" element has to be used when you display product cards or widgets. There's a reason why CSS scoping has been stuck in limbo for 10+ years. There's a reason...
The web is one of humanity's greatest achievements. But let's not pretend that it's not a textbook study in accidental complexity.
I wrote a similar HN comment around this yesterday, but the short version is that we found for our product that the years of investment in our Docs (which were seemingly never good enough) are now paying enormous dividends in that LLMs seem to understand our product really well. This has manifested in the LLM in our product being highly effective and a few additional clients who found us through AI chats. Turns out the problem with our Docs wasn't so much with their content, but rather that people just weren't looking at them much.
That’s a good question but I suspect when new technologies come out, the normally indecipherable specs released by industry groups (which is why we needed blogs) will be deciphered by LLMs. Not saying this is good or bad (it’s likely both) just saying it.
The AI will no longer be able to reproduce new a11y conventions/guidelines, but if no one is writing about it, do any new a11y conventions/guidelines even exist at that point?
Of course, the requirements aren't always right, but in my experience, engineers/developers are just as capable as business owners of defining requirements poorly.
Contrary to what you seem to believe, cars and bicycles are different kinds of things, not two versions of the same fundamental type, so this rhetorical question doesn't make much sense (consider that also your legs provide the function of transportation but are nevertheless not a kind of car).
There is no break pedal on this stuff, it just rolls down the hill until eventually it doesn't. It's a runaway process that feeds itself.
There is far more to it than all that.
I've interviewed far too many nextjs experts who couldn't do anything else. That's not a skill, that's just knowledge, which at this point is freely available.
You are contradicting yourself. Either its a "minefield...of edge cases..." Or it's a common-sense model. Not both.
I'm convinced we're still in this minefield of edge cases, not in a situation where we've solved all this, and where the tech to build "frontend" is clean, predictable, free of historical baggage etc etc etc.
All we have done, is plaster over these foundational mistakes and invcompatibilities. We haven't solved them. React doesn't solve the fact HTML was never designed to be a UI toolkit. Next.js doesn't solve the fact that JavaScript is full of design mistakes that prohibit it from ever becoming a safe, sane, reasonable (literally) language. Tailwind doesn't solve the problem of CSS being haphazardly introduced to style a markup which was never designed to be styled. Etc.
All LLMs now do, is having the "knowledge" of the horrors under the plaster, in a statistical model that was trained on examples from an era where 99% of the examples are hardly more than plastering to fix the ever reappearing cracks in the previous layers of plaster.
Consider indie games. If there are 10 of them and 5 are great, you don't need any filter. You look through 5 great and 5 not so great games and end up with 5 great ones.
Now go to a world where indie games explode. But only 1 in every 100 are great. There are now 100,000 games, but most qualify as very low quality. There are now 1,000 great games (and a few of these might be the perfect game you dreamt of), but if you don't have a filter and are buried under 10s of thousands of horrible games, things feel worse.
With a filter, you now live in a world where you can easily find most of those great games with only a few lower quality ones showing up. So as long as the filters that exist, whatever they might be, can handle it, more is better even if quality drops.
Unless the quality extremely fast, say my previous example of 100,000 games but only 1 in a million was a great game. I think this level of quality drop is extremely unlikely. Instead, I suspect the real problem is if the filters can keep up, because they depend upon human effort, so it is possible to hit a point where they are overwhelmed and stop functioning properly. That's when things get worse. As long as the filters hold, more building leads to better outcomes even with a drop in quality.
It can read the code? Historical discussions around it? Commit histories?
> But even then, people aren't entitled to the knowledge "created" by doing the work. If attribution and compensation were tackled in earnest, if you could only train on the materials of the people you pay to produce those materials, it might be much quicker and cheaper to just learn CSS.
OSS code and people’s public writings are available to anyone all the time. Common Crawl, the open source web crawl dump, has been around for over a decade. No one had any problem with these systems being developed on them, until they finally started to become useful, so what’s the sort of legal or ethical framework you’re pointing to?
Well there's your problem right there
The former. It’s definitely the former, at least until subsidized tokens run out.
When something goes wrong, no one understands anything.
The status quo with pre-AI Human Written software on a pedestal is that it doesn't work, and it lacks accessibility, polish, performance considerations, UX considerations, tests, and more.
The built-in rigor is trivial to prove. Just put Opus 4.8 in plan mode and tell it to plan something, like a vt100 emulator.
The question isn't whether you can do better than AI, because you'll put your foot on the scale and give yourself infinite time, attention, and energy just so you can say yes. It's whether AI can do as good or better than you with the same time, attention, and energy you would have given a task in the first place.
Please stop doing this. That is not even close to what he said.
"Some people" do that? Not a controversial statement, and pretending otherwise is to argue in bad faith.
Ironically, this goes well with LLMs, where you can nail down the patterns and then the clanker can follow them. There is nothing wrong with using clankers for fast typing.
Just not a correct interpretation. Many skills start that way and even some people make a whole career mastering one thing and one thing only.
Not saying being trapped in React land unable to break out is good. But being able to create something, even if it's just with Nextjs is still a good thing.
We should hate on the businesses that force us to take shortcuts, value quantity over quality. They wanted boot camps with code monkeys.
But situation was exactly the same before the AI. You would still get your wordpress, your React frontend and Java Spring backend.
AI doesn't change anything, it just takes the job of a poor slopper who made a living by coding React frontends. Anthropic just took their job, that's it, and you don't see the difference.
If the goal is a legitimate app that has the lifecycle of an app that you start up and then shut down today the answer is "just write a web application" and then it "just works" on Windows, MacOS, Linux, iOS, Android, Meta Quest, etc.
Mostly people get pissed about Electron because they have 15 Electron apps running in the tray burning up resources all the time and popping up stuff that covers the tray and other tray applications in those (very rare) cases that you want to interact with something in the tray.
It's a tray problem, not an Electron problem. That is, people use Electron specifically because they want to made rude applications which march all over your desktop in muddy boots: Electron is not a framework for writing well-behaved, polite, x-platform applications; you don't need that, you have the web! Electron is a framework for making rude applications that inhabit your tray, pop-up distracting notifications, etc.
Testing is so hard that we'll agree that, e.g., TDD is great (e.g. ensure your tests actually test something, ensure your code is testable from the start) yet we never do it. And when we do write tests, we are on the hook to be eternally vigilant that they are not stale, that they test something real, that they are not redundant. And they often turn into an append-only file that you resent.
Meanwhile, AI is happy to write tests, do red-green TDD cycles, refactor them, prune them, update them, justify and defend them. It will even incidentally write tests for the most aloof vibe-coder by accident because they didn't specify otherwise.
Overnight, I went from never testing most of my side projects (except for, say, maybe unit tests in more straightforward things like a parser) to now everything is tested end-to-end. Every time I make a new directional / architectural decision, the tests the AI writes also encode it at the test level to reenforce the decision.
It's strictly a better world for software because AI can write and maintain tests.
> LLM-assisted codebases, at least these days, only stick together thanks to testing
But tests also help humans and ensure human-written software is robust. We only don't test because they are so costly to write and maintain, and our software has always suffered for it. Or the tests become such an unmaintainable mess that our software is now worse because of it!
other people cant do anything with nextjs, or anything with any front end at all.
its applied knowledge, understanding how nextjs works, and using it to build some application
Mauro Bieg on May 23, 2026
What AI is doing to the jobs of programmers feels very familiar to a lot of us frontend developers – because it has happened to us before.
Let’s first look at the transformation of the frontend and agentic coding through the lens of deskilling, and then look at both changes through the lens of a higher level of abstraction. Finally, we’ll look at previous changes, like the advent of copy-pasta from Stack Overflow, and how the Bauhaus movement reacted to rising industrialization.
Just like AI is deskilling programming now, JavaScript frameworks have deskilled frontend development in the last decade. As someone who started with HTML/CSS and a bit of PHP, later did Ruby on Rails, and then was frontend team lead of a major Swiss newspaper (Next.js at the time), I’ve seen the transformation first-hand. And no need to take my word for it! I’m not the first to say so. Alex Russell called it Frontend’s Lost Decade.
What is deskilling? From Wikipedia:
Deskilling is the process by which skilled labor within an industry or economy is eliminated by the introduction of technologies operated by semi- or unskilled workers. This results in cost savings […] and reduces barriers to entry, weakening the bargaining power of [workers].
Let’s see how this applies to the frontend, and then to agentic coding.
A lot of programmers may not know this, but frontend used to be a highly specialized skill, requiring knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing – to just name a few. To distinguish what they’re doing from what “frontend” has become, practitioners of this arcane art nowadays often refer to it as the “front of the frontend”.
The deskilling of the frontend was the introduction of frameworks and other tooling that treats the browser as a mere compilation target – just like any other app runtime (e.g. JVM or iOS). Then you can just load in the monstrosity that is a Shadcn radio button, and don’t need to understand the underlying HTML, any subtleties involving different browsers, page load performance, and accessibility.
As the Wikipedia quote above points out, this “results in cost savings” for businesses, since they then can easily put any general programmer to work on the frontend. Often, a “full-stack developer” is unfortunately not somebody who deeply understands the frontend and the backend, but a generalist who just knows enough to wrangle a JavaScript framework to do both. This allows businesses to easily switch programmers around between different projects. The same generalist can even also do native apps with React Native and Electron! To finish the Wikipedia quote: this “reduces barriers to entry” (which is something I’ve always cherished), but it also “weakens the bargaining power of workers”.
What’s currently happening to programmers more generally seems very similar to what web developers in particular have been going through already. The skilled job of writing code manually is being “eliminated by the introduction of technologies, operated by semi- or unskilled workers.”
We still don’t know exactly what skillset the workers wrangling agentic AI will need to have at the end of this transformation, and at what price point we’ll arrive at – for both labour, and for local and remote LLMs. But it is already clear now, that businesses absolutely will use this technology for cost savings and weakening of the bargaining power of workers.
Just like artisans and craftsmen that were replaced by assembly line workers more than a century ago, we feel a profound sense of loss. We grieve that a skill, that we spent half a lifetime honing, is not being valued by the market anymore. And we’re saddened that the new process results in lower quality work, and that a lot of people just don’t seem to care.
An alternative way to look at “deskilling” is of course to argue that this is just increasing efficiency using automation. And what engineer doesn’t like automating things? It’s a big part of our job after all!
In this framing, the new technology introduced simply works on a higher level of abstraction, allowing the person operating it to focus on the bigger picture, without having to bother about unimportant details. But exactly which details are deemed “unimportant” is a very consequential and sometimes subjective decision. And eventually, the details always leak through.
It’s common for an abstraction to come at a cost of performance. But since computers are very fast nowadays, we were often willing to trade some runtime performance for increased developer productivity (garbage collection is one example). And for high-powered servers under moderate load, this is a very sensible tradeoff. But mobile phones on slow networks are a different beast.
By using a heavy client-side JavaScript framework like React, and a lot of packages from that ecosystem, you’re abstracting over things like accessibility, and performance on lower-end phones, or on slow networks. In effect, you’re choosing not to think about those things, and you’re choosing not to care about them.
By using agentic AI to code a feature or fix a bug, you’re describing the change at a higher level of abstraction, writing fewer words than writing all code by hand. The AI will fill in the details you omitted by looking at its training data and surrounding context – sometimes guessing well, other times not. Whether you find this useful or not depends to a large degree on your opinions on what’s important when coding.
But compared to previous abstractions in programming, agentic coding is a very leaky abstraction. It’s not deterministic like a compiler, and slight variations in input or model can give very different results. That has led people to compare AI to “junior engineers”, since those are also not deterministic. But one difference is of course that people are capable of learning, without you having to endlessly tweak their AGENTS.md or SKILL.md files.
As such, the best analogy for using LLMs I’ve found so far is how a Google search used to behave. It was a skill all of us had to learn at some point: choosing just the right keywords, so that the right forum post (and later Stack Overflow post) would surface on the first Google results page. Just like prompting an LLM, in order to return the right assemblage of its training data, a fuzzy web search is a lookup in a very high-dimensional space. And just like with LLMs, the lookup used to be very sensitive to slight variations of wording, and changes to Google’s search index.
In recent years, among other things, Google has changed the search to normalize entered terms much more aggressively. For people who were not versed in the dark art of Google-fu, this made the search much easier to use. But for those of us that had acquired that skill, it made Google search much less powerful. Specialized keywords used to bring us directly to an answer. Now they get normalized to a synonym, or to a closely associated word, and we land on a more generic page.
But the advent of Google, and later Stack Overflow, irreversibly changed programming. Instead of reading the f***ing manual, programmers could now just blindly copy & paste answers from Stack Overflow, and surprisingly often got something that kind of worked. Seen through this lens, LLMs are just a continuation of the same trend: tools and abstractions that make people that know what they’re doing slightly faster, and enable people who don’t really know what they’re doing to arrive at something that often kind of works. And you know what? That’s great!
But we shouldn’t fool ourselves: at some point the abstraction will leak. And then somebody has to invest the time to actually deeply understand what’s going on – and fix it. Just like we taught junior programmers to read and understand the Stack Overflow answer before using it, now we need to teach people to read and understand the stuff the LLM spits out, and to understand how it fits into the existing codebase.
Unfortunately, some programmers never progressed to the stage of trying to really understand the Stack Overflow answer. Why bother if it works? And while not publicly acknowledged, a lot of companies were actually happy with this approach. What’s different now is that companies go out of their way to publicly proclaim how much AI they’re using, without even pretending to look at the output.
While there are definitely valid use-cases for LLMs, there are also lots of new ways to mess up your code, and to mess up your organization’s communication and processes. This seems especially challenging to figure out as a team. Just like with code review, there are widely differing views on how to use and integrate LLMs into our workflows (if at all). And if the team is not aligned on what things they value, this can really throw a wrench in the works.
It’s also a sad fact of life that a lot of companies are doing very well, even though they’re churning out abysmal software. Despite what we programmers would like to believe, business success and software quality are very rarely correlated. Usually, other factors simply dominate. Often, software projects are treated as black boxes, known to fail about as often as they succeed, and are derisked in various ways (in the worst case, a different team will have another go at it).
And it’s been the same for frontend development. Unfortunately, a terrible website has a relatively small impact on the bottom line. Does a slow website and lots of cookie banners hurt conversion? Sure, but that effect is relatively small compared to other factors like brand loyalty and pricing. And all the competitors have slow websites as well! Besides, nobody was ever fired for choosing React.
Does that mean we should stop caring about our users and about our craft? No. But it does mean that it’s become even harder to find a job where you’re allowed to do so. Hopefully, the pendulum will swing back a bit, once the hype has blown over, and we’ve a better understanding what tasks LLMs are actually a good fit for and what not. But it’s safe to say that our profession will not be the same as before.
What did previous generations of craftspeople do when everyday goods and buildings suddenly could be mass-produced by industrial processes? One reaction was to copy the style of old, and make the industry crank out widgets and buildings that at least looked like they were handcrafted.
Countering this trend of historicism, an alternative approach was developed by the Bauhaus movement of the early 20th century. Instead of pitting factory workers against craftspeople, their stated goal was to have them work together, and redevelop the arts and crafts with industrial manufacturing processes in mind. The Bauhaus urged designers to go back into the workshops, and work with the materials themselves. Still with the goal of arriving at designs that would then be mass produced. But always keeping the end user and mind, and deeply caring about them. Modern industrial design, as exemplified by Dieter Rams and Johnathan Ive, can trace its roots straight back to the Bauhaus.
How can we translate this line of thinking to software?
Software sits somewhere in-between craft on one hand (the program we write gets shipped “as is” to our users, without first going through a manufacturing step), and industrial design on the other hand (we ship the same thing to potentially thousands of users, who we never get to see interacting with our product).
The need for being able to write code by hand is clear. Just like industrial designers need to know the materials their products will be made of, a web designer needs to be intimately familiar with HTML and CSS.
While it’s great that tools like Google, Stack Overflow, ready-to-use libraries, and now LLMs are making things easier for beginners, this also means that the natural barrier to get anything working at all is continuously being lowered.
While there is a high barrier to entry to a field, it’s difficult to find absolutely terrible pieces of work. Once a craftsman was taught how to build a wooden chair, they invariable were also taught how to not do a terrible job at it.
The industrialization enabled lots of cheap plastic products, designed by people who didn’t take the time to think how they would be used and by whom – yet good industrial design is still a thing. The invention of the word processor enabled lots of terribly formatted documents – yet typography and graphic design still exist. And software like Wix and Next.js enabled the creation of lots of websites that load terribly slow and are not accessible – yet there are still practitioners of the front of the frontend out there. Likewise, AI is enabling lots of AI slop – but this doesn’t mean we don’t still need people who know what they’re doing, and who care about what they’re doing.
But like in other industries, doing things properly will become an ever smaller slice of the pie. But because it’s now easier and cheaper to do so, the size of the pie will continue to grow. It’s very hard to say at this point in time whether the absolute number of people, being payed to do things well, will increase or decrease. If you ask me, there are way too many poorly designed plastic products out there. And it’s a sad fact that designing new type faces is not a sustainable full-time job anymore. But at the same time, there is still so much great work being done in all those domains.
And you know what? Sometimes churning out a quick prototype or MVP is the right thing to do. If you don’t have product-market-fit yet, quick iteration and learning is more important than future-proofing everything. But you need to know what you’re trying to learn, and how you validate those learnings. And when the time has come, it’s usually better to take a step back and do things right from the start. For example, good performance is very hard to achieve in a badly architected frontend later. And it’s easier to start with a simple stack and add functionality later on than the reverse. Both of these, Mastro explicitly encourages.
For any part of the system, you need to know what tradeoffs you’re making, and then decide whether you should buy a service, use an open source library, have an LLM churn it out, or write it yourself. When the hype has died down, the industry will realize it’s just one more tool in the toolbox. But until then, we’re going to see a lot of ugly things: ugly code, broken communications, and awful layoffs under the guise of AI.
Follow us on Bluesky, or add our blog to your RSS reader (feed link).
Mastro is the simplest web framework and static site generator yet.
Just open Steam, PSStore, Nintendo store.
Assume everybody is now using LLM because they're better, and because the people who created artisanal things in their free time out of sheer generosity no longer have free time, or any food at all, or simply no longer feel generous. And the few people who are such specialists that they would be slowed down by them only do proprietary work, for lots of money.
What then? LLM learning from LLM doesn't really work, does it?
This is not intended as some kind of gotcha, to me this is a huge elephant on the couch.
> No one had any problem with these systems being developed on them, until they finally started to become useful, so what’s the sort of legal or ethical framework you’re pointing to?
That it's perfectly fine for people to say "I was fine with that, but I'm not fine with this". They can give you detailed explanations for their individual decisions, every single one of them, but there is no point in discussing them in aggregate because that aggregate is an abstraction. And they're optional, too, it's not like people have to give an explanation, and aren't simply free to change their mind for no or for bad reasons.
And if everyone bunkers up and all that open content dries up starting in 2026, let's say, what happens?
Still doesn't.
I read some AI generated tests and while it looks visually impressive, ultimately it wasn’t doing anything valuable? Why? because of all the mocks and scenarios that didn’t matter. And on top of that, tests are additional code to maintain.
These days, I don’t even bother with unit testing. They are a maintenance burden. I focus on integration test (whole modules) and if I have the time, on a harness to do e2e testing.
theyve already been added to all the big labs' datasets, its not like its going anywhere.
but even moreso, accessibility tools exist because people need them, and will make it known when the accessibility is broken.
the screen reader is still gonna expose an api or have observable outputs.
There's very real forcing functions that will keep making useful content about what people want and need from accessibility tools, and how to interact with existing tools.
you're still building for people and the harness operator as time goes on, will probably be the actual user, and will push the LLM to adjust the code to be great for them
> What then? LLM learning from LLM doesn't really work, does it?
Oh what no that’s exactly how it works, even today. RL with verification is done with synthetic data and rejection sampling. If something can’t get done purely with an agent that needs to get done it’s done with human help, this will always be the case it will just get rare-er.
> That it's perfectly fine for people to say "I was fine with that, but I'm not fine with this".
Agree with you there, but there’s a theme or insinuation (not saying you’re saying this) that these companies “stole work” (which definitely a lot of copyright violations sure), but it’s just unclear to me what principles or legal frameworks these companies or institutions should have used to develop the technology. I don’t really even know whether I mean to imply it’s not unethical, moreso I’m looking for a steel man argument to this. But of course people are entitled to their value systems and judgements and to point out real harm.
Many kinds of technology faced this kind of tragedy of the commons argument in the past and it never bears out. Printing presses copied manuscripts, search engines copied and indexed web pages, open-source software was incorporated into commercial products, Wikipedia repackaged knowledge produced elsewhere.
In almost all cases the total amount of creation increases because the technology lowered costs, expanded audiences, or created new forms of value. The speed of creation of new 'View Source' outpaces the number of people pulling back.
We're not such a smart species. It's not like we managed so far. We're just adding unsolved problems, and distract ourselves with even bigger problems. The world could have been fed and clothed by the mid 20th century and we could have solved climate change by the 1980s (talking out of my ass here but with confidence in my general point with that), but instead we now throw everything into the furnace. in the hopes it will create a deus ex machina, like in that very bad Isaac Asimov story. I think we are absolutely capable of lobotomizing ourselves (as a species) like a toddler playing with an electrical socket shocking itself. I don't say this to be snarky, I honestly think we're that unserious and ignorant about what we do and the environment we do it in.
But I also really should look into what you answered about LLM learning from themselves, I heard it mentioned before but I still have no real clue. I will try to rectify that. I mean, I really, really want to be wrong on this, only a monster wouldn't.
Oh, I'm absolutely one of the people saying that a lot of companies stole a lot of work, and that it would be better to dissolve them and make all their assets public domain, than to stand for it.
The legal and moral framework is to ask for permission, accept "no". The same framework they use against you in an instant, with an army of lawyers, when you do to them what they did to everybody.
None of this in principle, technically, requires slurping up everything and ignoring consent, that just made it quicker and cheaper, that's why they did it. While they did that, I'm sure other labs made progress in the same direction at much smaller pace, in a defensible manner, of which they should get to keep the fruit.
A lot of open-source software was supported by developers having stable well-paying jobs that didn't burn them out and afforded them enough free time to work on passion projects on the side, so that even if their company wasn't directly supporting their OSS development, there was still an indirect link.
Not only is this likely to increasingly change in the future as people need to spend more time navigating the disruption AI will have on labor, it already visibly has been changing over the past year.
One of the top posts on HN today is someone leaving open source and tech completely to work at Home Depot -- while this is an extreme case it isn't wholly unique to what I'm seeing in many places since 2025.
That is not the dynamic with LLM. You see LLM output, but original creator is hidden. And if you write your own, no one will find it. Worst, other people will tell you "LLM could have write it" in reaction ... so people wont bother.
> search engines copied and indexed web pages
Notably, search engines sent people toward web pages. And when search engines stopped doing that and started to copy content, those original pages started to die out.
> Printing presses copied manuscripts
Printing press made dissemination easier. It is an equivalent of early internet, not of LLM.
> open-source software was incorporated into commercial products
Commercial product using open source library had different user then the library it is using. And crucially, it is not hiding that library from the library user.
> Wikipedia repackaged knowledge produced elsewhere
Yes, and we collectively create less encyclopedias. They are not worth writing and checking for correctness anymore, so we don't do that all that much anymore.
But this doesn't lower the cost of learning and writing CSS, it just scoops up some of it and offers that cheaply, and even that only because it's offered below cost. If anything I'd say it increases the cost, because now you don't get paid to get and be good at what an LLM is supposedly good enough at, and have less free time to do it anyway. You may not even have a computer because your current one broke and you can't afford a new one.
Do you think creating the orders of magnitude of content the internet produced organically and which LLM creators are stealing is cheap? If they actually have to pay for content creation while competing with content creators on the you know, content creation front via LLM-generation, the entire business model of LLMs collapses.
You can't have the mountains of data needed for LLMs in the decades to come, if your LLMs put the writers and artists out of work.
I dont think it will be "too late" by any reasonable definition. All those things are learnable and companies that will really need to overcome it, will. But, they wont be open with their knowledge. Learning/training will be expensive and once people acquire it, they wont share it like open sources and programming tech blogs did.