I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people. I understand that there's a good living to be made from knowing browser quirks, hand-rolling accessible components, mastering CSS specificity, but this is largely accidental complexity. 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.
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 problem is, mastering accessibility, intuitiveness, compatibility, responsiveness, scalability, architecture, performance, and all those other less immediately visible, "forward-thinking" parts of UX/software development has always been difficult. Ultra high-level frameworks and now LLMs have, on the other hand, made it even easier to botch all of these and quickly roll out a half-baked MVP. The gap between "acceptable" and "decent" has thus been widening. As a protagonist of "decent", you have it increasingly harder competing against those pushing for "acceptable". And the push is understandable as well, it's MVPs that make money and details only "increase customer satisfaction" at best (and these days, who even cares about customers?).
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.
> LLMs have, on the other hand, made it even easier to botch all of these and quickly roll out a half-baked MVP
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.
I can somewhat see your point, but it is generally accepted that a wrong ARIA is worse than none, and LLM-assisted codebases, at least these days, only stick together thanks to testing, the more decent ones heavily emphasize in-depth human code reviews.
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?
Testing is an even more powerful subject here since we barely do it.
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!
I've gotten a lot of value out of LLM tools but without extensive feedback and direction I've found even the newer version of Opus pretty bad at writing good tests. First drafts are full of tests with some of these characteristics:
- good test, wrong layer, would turn into a mess of "wait why'd tests over there blow up for changes over here"
- mostly-good test, subtle issue (yes, this is the status quo with most human-written tests, but the risk of not being careful is that you (or the agent you throw at crap) now is overconfident in your future changes)
- weird silly test like "assert that calling the six statements in this method in the right order do the right thing" without... actually calling the method itself... so don't protect against changes to the method?
For non-greenfield work I've recently been much more happy with their out of the box code change quality then their attempts at adding coverage for those changes!
I think this is an area that has remained hard because putting directives in CLAUDE.md or whatnot for tests is generally gonna be so generic to be useless, like "put tests in the right place" without more module-specific context. Whereas if I'm making a non-greenfield change, I'm thinking much more in my prompt about constraints on the code itself, and much less about the current shape/state/organization of the tests or what to direct it on.
Properly used it's great. Definitely improved my test coverage a lot.
But it's entirely still in the world of "people who'd care to write good code before will write good code faster; other people will just write mediocre code faster."
a11y testing is non-trivial. axe-core can automatically detect many types of issues. However, enough compliance (to avoid being sued) needs end-to-end testing and human judgement. e.g. keyboard traps, focus restoration, alt-text, etc.
> 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.
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.
Many humans do the same thing. They write tests that mock so much of the actual code, the "test" is not testing much at all, except perhaps the developer's ability to basically turn the code inside out. It's often just a large volume of crap that has to be maintained (or eventually deleted.)
I agree integration tests are best, with some e2e testing for common scenarios.
I worked at a place that required unit tests for every new method or function. Arguments like "this other (integration) test already covers that. why do I have to add another test?" wouldn't fly. PR reviews would often degrade into arguments about testing and how all database access needed to be mocked...
> I read some AI generated tests and while it looks visually impressive, ultimately it wasn’t doing anything valuable
I just saw this comment yesterday about one of the tests from Bun’s rust rewrite: https://news.ycombinator.com/item?id=48314311 It reads in the raw source code and uses a regex to assert that “unsafe” is used.
> These days, I don’t even bother with unit testing. They are a maintenance burden
I’ve come to the same conclusion, but that’s only because I’m working on solo projects. I think they are probably worth it with multiple devs on the same project.
IMO with multiple devs the focus on integration (module-level) instead of unit (lower-level/helper-function-level) is even more important than on single-dev projects.
My instructions and steering is to force the LLM agent to focus on mocking only system boundaries and outside in unit testing. I've found these two make verbose but good tests that actually prove behavior pretty well.
But that was my testing strategy already, but writing one of those tests could take legitimately hours with how many columns and crazy rules our area has.
With the right harness/agent/skill setup and requirements work, this (any specificity) can become part of the workflow from early stages.
Setting that up and making sure it works, at the early stages, is not what LLMs do best, today. This sort of work is possibly incredibly valuable in the next 12-36 months, depending on what LLMs can be designed to do out of the box.
An Agent that can deliver the correct legal review process for a patent and is correct often enough to validate the savings vs real humans, or at least the speed increase + manual review ala code reviews, is incredibly valuable.
Are we there yet? Maybe this is where current groups like FNCR are trying to go.
I would much rather have software that works but lacks accessibility features than software that's broken but also has some broken accessibility features sprinkled in. The former is useful to many people, while the latter is useful to no one.
But the key here is: LLMs don't have latent rigor, nor any other kind of rigor.
But software was already in a horrible state before AI, so your dichotomy doesn't work.
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.
A couple months back, I had Sonnet build me a browser-based VT-100 terminal emulator. I then had it build me a websocket-to-telnet gateway for connecting some old retro systems to it. Both worked pretty well.
Could I have done it on my own? Yes, eventually. The problem is I would've lost interest and moved on to some other useless project before getting that far.
In practice, you would use an already written implementation, maintained by somebody else. An option that is often ignored by LLM (copy-paste galore).
For example, imagine if textual-serve author would reimplement xterm.js What effect it would make on quality.
LLMs increase technical debt rapidly. It is unclear whether they can deal with the mess they create. But we'll know soon (no need to wait years, to get immovable mess).
The positive side of LLMs is that they confirm experimentally the usefulness of many software engineering practices (testing,docs, adrs, design, formal specs etc)
I think higher up in the thread it was already argued and agreed that the rigor is generally already present, and can be doubly sure to exist in agents.md.
You get a lot of things for free with LLMs. You program an input box that goes to a form, handle the backend, make sure the variable names match the box, the API, the data structures and the database columns. All the brain matter making sure that flow works is mastered by an LLM since even with GPT 3.5 (not that I am advocating using that anymore). But the point is, since that's taken care of, why not also let it handle aria, input hints, mouse effects, state storage, animations since most of it's handled by putting "handle aria, input hints, mouse effects, state storage, animations" any time the front end files are changed." in agents.md
I would say that's rigor. Now you go a step further and have another LLM in your QA cycle that double checks it.
>asserting that AI will botch software might hold more weight with people who have already forgotten how dogshit software was pre-AI.
You're responding to an assertion with an assertion. It has been empirically proven that SOTA models can create more dogshit software than pre-AI software. It is also trivially known that the user is unable to predict when and how the AI will introduce dogshit into the software. We literally had a study posted on this forum claiming models give more accurate answers if you're mean to them. This is the shit we're dealing with. Stuff you couldn't make up in a dystopian Douglas Adams novel.
>you can encode these things into prompts
Is this satire? SOTA models randomly disobey rules in prompts all the time.
When a dev drops a production db I can warn them. If they do it multiple times during their employment I can change their roles or fire them.
I can count the number of companies providing SOTA models with the fingers on my hands. Imagine having an employee pool of only 5 savant coders with dementia to choose from to hire to your company. That's it. Thats the entire applicant pool. You can only fire one of them by hiring one of the other four to replace them with. And you can't really fire them for dropping production dbs if you can't prevent the other ones from making the same mistake. This is the current AI-first hellscape as it stands.
Personally the biggest conceptual problem with HTML/CSS is that it's incredibly unintuitive with mapping to real-world concepts, and not low-level (or straightforward) enough so that the low-level primitives are easy to manipulate.
For example, WPF programs can have great accessibility - this comes from the fact that programmers can manipulate primitives which are semantically meaningful (buttons, lists etc).
In HTML its just a sea of divs which lately have become an implementation detail to hang classes on to, and sometimes not even exposed directly to the developer, if you use a SPA framework.
There's not a snowballs chance in hell you can build a quality accesibility solution on top of that.
HTML's main idea was that HTML was a document model, that described the content in a semantically meaningful way, and CSS was the 'rest' which kind of allowed to make the whole thing pretty - the idea going as far as separating content from looks should allow people to 'theme' their websites and completely redefine layout.
That idea has been completely abadoned. I'm not a frontend dev - although I can make a competent webpage by myself, I don't have deep insights into what's going on in the field - maybe Web Components will allow people to create semantically meaningful pages in a standard way?
Maybe there should be another layer of abstraction on top of what we have - which is truly semantic, this time for real?
I don't have the same rosy memory of the history as you do. I remember very regularly having to wrestle with flash or java applets reinstalling and doing all kinds of voodoo I could to get sites to run, sites I used fine the day prior. Figuring it all out on my oh so slow connection and hoping no one calls the landline lest it stops all the progress.
Not saying it wasn't a fun period of chaos and I everyday wish for internet to become the wild west it once was.
It was acceptable in the sense that I didn't know it could be better, I was used to OS hanging and crashing regularly on my oh-so-fancy dual core system as well regularly so it was all acceptable.
Today I find myself having less patience for it all, because things just tend to work a lot more often than they don't.
With AI, I find so many small businesses and others I deal with which have their own websites have started to have better design, better performance and while I don't know if they are really accessible but they tend to have more prevalence of aria labels.
Not to take away from your experiences, just sharing my anecdotes.
This is why the 'craft' should be left to open source for most commercial software. The business reality just doesn't care for it.
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.
> Some people go on a bicycle because they can't afford a car. Should car makers see those people as a problem?
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).
AI consistently places animated objects behind a blur object which causes the browser to constantly repaint. Google's ai mode introduced one, some other websites clearly vibe codes included them too.
At first it confused me why my GPU usage spiked and fans started blowing harder, but now I see it is a common mistake that AI makes but no one tests properly. It is possible a human can make this mistake but I sheldom experienced this ever in my life until now.
I run 240hz monitors, and that meant the browser was trying to do 240 repaints per second. Blocking it with unlock origin is the only way. Ridiculous
Totally. Every "we're losing our craft" article has the same gloomy shape. That's enough of a bummer, but they also argue against themselves halfway through.
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!
A craftsman's pride is an industrialist's nightmare! Software has been transitioning from a craft into an industrial process for the last two decades or so, and the software craftsmen of all stripes understandably do not like this!
> Software has been transitioning from a craft into an industrial process for the last two decades or so
This seems like a good insight and it feels true to me as well.
My guess is the absolute number of people who treat it like a "craft" is higher than 20 years ago, but as a fraction of all developers it has shrunk dramatically.
I am not joking when I say that software craftsmen lost the war when tabs vs spaces was obviated as a point of contention by CI enforced formatting and linting around broader community standards.
> Websites are largely better, technically, than they were 10 years ago.
That is not remotely the case. All software, not just websites, is a lot worse than it was 10 years ago. Bloated, slow, buggy messes that resulted from the industry hiring a bunch of people who just wanted to do the bare minimum and make fat stacks, rather than hiring people who actually care about good engineering.
It's just not what I wanted. I got into software because I liked coding, deep technical understanding only excited me because it would help me code better. I don't want to get too "woe is me", there are far worse things in the world than having a vaguely unsatisfying job, but there are life choices I would have made differently had I known coding would be automated in 2026.
> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.
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.
> No, other people did. They wrote about it, and LLM can sometimes use that. Once they no longer write about it, what then?
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?
> It can read the code? Historical discussions around it? Commit histories?
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.
> What then? LLM learning from LLM doesn't really work, does it?
It does work, it is called RLVR, reinforcement learning from verified rewards, is is based on testing code by execution. It's become a major area of improvement in the last year. But you are also forgetting the amount of steering and problem solving going into coding agents today, and the huge logs they create which can feedback into training. We automated stackoverflow, LLM learns from usage and self play.
Presuming that conventions, standards, best-practices will continue to evolve as people do this work - whether with or without AI - I can't see any reason why the resulting advancements wouldn't be published in a way that builds a record for the future.
My documentation tends to be more thorough and well-maintained when I'm building software with a coding agent. A million tokens of context tends to be better at that kind of thing than my own brain when I'm neck-deep in solving a difficult problem.
And presuming the best practices are adequate and don't need to evolve (which seems unlikely) - then the current public historical record is also adequate.
> 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?
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.
> 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.
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.
still though, whats causing the old code to disappear? the old discussions to disappear?
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
It won't happen, for two reasons. One is that great deal of open-source software and hobbyist knowledge sharing has never been driven by financial reward anyway and people will continue to do it anyway. Finer grained controls over opt-outs would be great (the equivalent of a search engine 'nofollow' would be great and will hopefully come with time).
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.
> great deal of open-source software and hobbyist knowledge sharing has never been driven by financial reward anyway and people will continue to do it anyway.
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.
I'm personally was fine with contributing to open-source without any financial reward. But I'm reluctant to release anything in public now because it will be eventually incorporated into the training set for the technology which will (or at least can) lave me without a job and chances to find one.
> In almost all cases the total amount of creation increases because the technology lowered costs
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.
It will happen and it already started to happen. It started to happen even before LLM, when google started to hide smaller personal blogs in its search result. Expectation of the monetary reward has nothing to do with it, discoverability does. Culture of creating content does not exist when people cant see what others created and know no one will see what they created. A lot of smaller open source was monkey see monkey do thing - we have seen other open source projects and wanted something like that. Likewise with tutorials, we have seen other people write cool tutorials and felt like creating own and showing it out.
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.
The centralized choke point of web search is getting relaxed now. Unlike search engines and social networks, you can download a LLM and run it. A small one, but capable of using a library of search stubs to directly fetch information from hubs, feeds and other search engines. You can own the agent who can solve the web search part for you.
Imagine you have a 4B model and keep an equal size corpus of search stubs, small MD documents linking to hubs, feeds and search engines for millions of topics. You can use the LLM to read the stub and perform the search for you, all orchestrated locally, with greater privacy and independence. You can dis-intermediate the search chokepoint now. You can set the criteria for what to include, exclude, how to rank and present the results.
This works because good entry points for any topic change slowly over time. The construction of search stubs is trivial with existing AI agents, and can be shared as open source. A few GB for the model, a few for the search routing layer, and you got a sovereign local agent.
If this holds, access control shifts from whatever Google thinks maximizes profit to whatever the community thinks has value.
Well that historical content and code still exists right? Are you just saying “what if we’re in a world of walled gardens now that OSS dies because people don’t want their work stolen” in which case: these companies will get data and they don’t need OSS anymore. It’s already webcrawled or licensed or commissioned, they pay people to generate novel traces when they need it or at the very least sets of prompts and tests for verification. Then synthetic data gets added to the training set, the ones that are verified.
That sounds like it would reduce the blazing progress of the last decades to a snail's pace, some twilight where software is just average, as it always was and always will be. That people will always do the thing the opposite of which is now incentivized doesn't convince me, basically. If just using the LLM gets you ahead in a time of severe pressure, then most people will do that, and by the time anyone realizes they kinda need a FEW people to actually be able to reason about something from start to finish, it might be to late.
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.
> by the time anyone realizes they kinda need a FEW people to actually be able to reason about something from start to finish, it might be to late.
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.
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.
It’s literally how these models are trained today. They of course use open source data but that’s no longer the most important source, it’s high quality prompts and verifiable tests and a lot of inference compute. They also have massive flywheels from users from which they can mine good data or at the very least again good prompts which can be just as important.
And everything we know about these companies points to unsustainability, before we even get to very high impact content lawsuits which haven't even been settled. Let alone lots of data sets being pulled out of public view and being moved to anti LLM licenses (with explicit licensing for training).
We will see how this shakes out in the coming years, as Anthropic, OpenAI & co file for IPO or run out of private funding. Grok is already on the ropes as seen from the SpaceX IPO.
The successful standards, platforms, libraries, tools, etc. will be the ones that LLMs can understand. Like a good GitHub readme, or website, or Discord community, I strongly feel that making sure you've (perhaps personally) written enough about your offering for AI to understand it will be an important factor in how successful it can be in markets or communities.
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.
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?
> They wrote about it, and LLM can sometimes use that. Once they no longer write about it, what then?
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.
>I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people.
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.
> feeling that the convenience from ignoring the "deep expertise" and piling on hacks and lazy abstractions
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.
>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.
And yet we could build native apps a plenty in the 90s and 2000s, with 1/100 the resources (tutorials, third party libs, native GUI frameworks, IDEs, etc) available, and 1/10th the target user base.
It's not about "platform specific code, being hysterically expensive to build and maintain". It was more expensive in the 1990s and 00s too, but people built it and maintained it just fine.
It's companies chosing convenience.
Especially since it's not poor programmers and small software shops going for Electron. It's the biggest multi-billion to trillion dollar companies.
Facebook uses this crap, Slack uses this crap, Adobe and Google use similar web-based UI crap (in what used to be native apps), and so on.
Building is not the same as maintaining and updating. As long as Apple wants to take a week to review every change and occasionally rejecting client versions (insert similar complaints about Microsoft, Google, Linux here), there will still be a case for these technologies.
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.
Right - but those constraints are inherent to the medium. Like basically unconstrained screen sizes from large desktops to mobile, with the user free to resize anywhere in between (and can't be constrained in the way that 'real' apps often are). Input methods of both fine mouse control, and course touch.
> 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.
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.
> 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.
Let me guess, you stopped reading web standards documents because Facebook told you it didn’t matter, since you could just ship 10MB of javascript with every request
It is a hard problem. That is why in the pre-browser days a small number of entities did the hard work and gave the rest of us mere mortals tidy APIs to make use of their efforts without everyone having to painstakingly duplicate what they created each and every time.
But then CSS came along and threw out the baby with the bathwater, returning us back to the bare primitives, forcing entities to redo all that work again. Except this time CSS didn't offer a good mechanism to wrap up that hard work in a nice API bow, so everyone ended up getting pushed into having to redo that same hard work every time they started a new project, leading to a bunch of poor, inconsistent, and often downright wacky implementations.
To be fair, the problem isn't CSS per se, it is just that it is much too low-level for all but the small number of entities focused on the aforementioned hard problems and browsers failed to offer anything higher-level for the rest of us. Javascript has tried taking on a stand-in role for the lack of the higher-level abstraction being natively offered by the browser, but that comes with its own limitations so it isn't always a viable choice, not to mention that having to resort to using a full programming environment completely defeats the purpose of having CSS.
CSS gets all the hate because it is more often than not the wrong tool for the job but the only tool available at hand.
> 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.
I dunno, seemed easier 20+ years ago when in high school we were taught how to use Delphi than now.
HTML/CSS is just terrible way to build interfaces. It was made to build basically resizeable documents, not applications, and it shows in every crevice
I used to make a living doing frontend development, and quirks and knowing idiosyncrasies is a burden to your craft. Yes, it meant there were higher barriers to entry, but it also resulted in a lot of broken websites, and I can tell you it was never fun nor rewarding.
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.
"Frontend's Lost Decade" has nothing to do with a11y or semantic HTML. The original talk argues performance went to hell because of React and friends, which is why we have electron CRUD apps that consume 2GB+ RAM.
The bit that goes unsaid about Electron is... why?
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.
The resource burn is an Electron problem. I member using HTML as "Active Desktop" in the Windows 98 era. You could drag an Internet Explorer widget into VB6 applications if you wanted (OLE, COM and ActiveX, damn that was an era of powerful technologies!). But it was one shared runtime across the OS which meant it did not have anywhere near close to the performance impact that even one Electron app has today.
People think they are upset about new technology, but what they are actually upset about is the general consensus being that the new technology has a better value prop.
And the irony is that the author of that talk spent that same decade busy shoving as much Javascript into browsers as possible. After all he's the originator and the main promoter of web components where every single thing including built-in browser functionality like form participation has to be done in Javascript.
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
The points the author made simply aren't good arguments. Yes, frontend development was harder during those days, but not harder in a good or rewarding way.
Sharding, buffering, caching, load balancing are mostly issues 99% of devs will never have to work on. It gets relevant on high load pages, but most stuff out there wont ever need it.
That’s not what accidental complexity means. Accidental complexity comes from design errors that could have in hindsight been avoided, meaning that if those errors hadn’t been made (made by accident, literally), there wouldn’t be any accidental complexity. The items you list aren’t accidents that could be avoided, they are necessities in achieving relevant goals.
Less of an accident than a byproduct of the unique ecosystem the web lives in (which is a positive!) Compare to say, backend development. If I said database indexes are deeply inconvenient and that I shouldn't have to make them I'd get laughed out of the room and justifiably so. But by comparison when a developer says "I don't care to learn CSS" folks nod their heads in agreement.
> More people building things is straightforwardly good
Why is that straightforward? As an example, right now every year on Steam there are thousands of games released. A lot of them are just shovel ware that nobody ever plays, but it does end up hiding actual quality stuff in the noise. Same thing happens in app stores. Gatekeeping that limits opportunity is bad. But gatekeeping around quality is very good. Wanting your software to be written by someone who cares about software and has expertise is, to me, more straightforwardly good.
Right now people are blaming vibecoding for decline in a lot of mature software products, whether that's fair or not (I think it's frequently unfair). I think there's a possibility that's going to morph into "AI First" companies being seen as poor quality brands. Already we see in games that when listed they have to disclose if AI was used or not, and if it was, it damages the credibility quite a bit.
While I strongly agree that heavy LLM usage in industries that actually collect customer data, or make important decisions is INCREDIBLY harmful (with quite a bit of unfortunate regularity), democratizing coding “for all” especially in small, narrow niches, is similar to democratizing art, singing, music, general creating.
As long as it’s “for you” or “small time”, there really isn’t a problem at all.
The only real downside so far to LLMs (ignoring environmental concerns) is when they’re heavily used and left unrestrained to go play with financial data, healthcare data, PII, anything with real consequences when it breaks. If a person is using it to automate their life. If a father is using it to help their kid with accessibility issues speak. If an artist is using it to help them write code so they can make a game. These are all good things.
You might think it’s shovelware; but the creator of those things is now super excited that their vision was made or their niche issue was helped, when no one else would.
They can, in theory. But when the signal to noise ratio gets too low, it becomes prohibitively difficult to filter out the garbage. Thus I don't think it's true that more people creating things is a pure benefit. It may not even prove to be a benefit at all, on net.
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.
Suppose the choice is between software that does what you want, but isn't very optimized, and the software not existing at all, rather than between shoddy and beautiful software that both do what you want, and maybe it will make more sense to you.
So apply a false dichotomy and it will all make sense? Still not buying it. Not everything needs to be solved with software, and brushing off negative externalities as “not very optimized” is irresponsible
It's not a false dichotomy at all. There wasn't a lot of junk clothing in the ancient world -- everything was made to last. The downside was it was very expensive and most people didn't have much. The episode with the guards casting lots to see who can have Jesus's robes in the gospels is rather difficult to understand for a modern audience.
It doesn't seem to me that the author is saying 'AI bad, abstraction bad, knowing browser quirks GOOD'. Looks to me like someone making a specific claim about a trend where having an easier time getting off the ground can lead to a lower ceiling.
I'd read it kind of like 'The man and the butterfly' story. Or the Kant passage about how doves might wish air didn't exist, without realising that friction is exactly what permits them to fly.
That's all true - I taught myself how to code from 2009-2012 so I remember what it was like. However, around that time there was also deep focus on architecture, an obsessive focus on rendering performance and page weight. Everyone could recite the loading sequence that HTML pages used, we knew how many requests could be downloaded in parallel, how to best bundle assets for the fastest time to render, etc. So it was a mix of both pain and frustration on one hand, and a pride in one's work on the other hand.
Both have been lost; good riddance the former, but I miss the latter.
Exactly. Nobody wants smalltalk programmers or IIS whisperers. You just have to embrace the idea that your skills become worthless every five years and move on.
> More people building things is straightforwardly good
Is it? More than a decade ago there was a Cambrian explosion of software, Flash alone was the defining force of indie gaming industry. And now what? We have so much shit/shovelware that nobody wants to touch with a ten-foot pole.
>...and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
It depends. My country (Germany) introduced accessibility laws recently which enforces you to build everything public with accessibility in mind. If a page doesn't meet the expected standard you can get extremely high fines.
I tend to agree. I believe most of these arguments, whether consciously or not, are rooted in sour grapes.
If AI were already the norm, and someone came along and said, "hey! I've got a great idea! Instead of AI building all this stuff, what if we did it by hand?" and talk about all these amazing benefits to hand crafting code, people would largely say no thanks.
As far as the abstraction argument goes, well, we've been creating higher order abstractions for a long time and called it good. I don't see why we should suddenly be against abstraction.
That's an argument from assumption. The issue isn't whether AI is "building all this stuff" but how well it's doing it, how well the people using it are doing it, how expensive it really is, and whether there are observable objective benefits at the end - not just a subjective sense that some work is taking less time.
The reality is probably bimodal. The people who are benefiting are benefiting a lot, but they're likely in a minority. The majority will be tokenmaxxing at great expense and spinning their wheels in real terms.
But there's no hard research to prove that.
Considering the huge sums involved, the absence is interesting.
Calling that an argument from assumption is fair. I am basing this on where I think the puck is going, but I don't think I'm wrong. The issues you mention are not unsolvable problems, and AI is very good at independently iterating and improving on an observable objective metric.
Reality is certainly bimodal today, but that's because as an industry we're lagging behind capability. We're in the early days of the innovator's dilemma S-curve.
Yes it's still bad there's no viable headless UI in browser one can really style and it has all the a11y etc. but need extra library for selects that work etc. Invented work for no good reason. The real complexity is in diversity of devices though nowadays in the frontend.
> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.
Only because you've not invested time[1] to learn a11y, but that is par for the course: LLMs are pretty good at impressing people without a deeper understanding of a field with its statistically average outputs.
My hot-take: one shouldn't oversee an LLM task whose output they are unable to evaluate.
1. And you don't have to! We have limited time, accessibility is broad, there are numerous standards, and screen readers can be unergonomic, to put it lightly. But a human has common sense, and can care. I doubt there's enough a11y training data to match a caring human testing and thinking through interactions. Sadly, human software QA is now threatened with extinction.
> the "deep expertise" OP laments was actually deeply inconvenient to many people
This reminds me of the Upton Sinclair quote: “It is difficult to get a man to understand something when his salary depends upon his not understanding it.”
LLMs feel threatening to anyone who had an edge by knowing how to navigate domains with a lot of weird and complex behavior. It’s nice to feel like businesses need you if they want to solve a problem. It’s scary when a cheaper solution arrives that does 70% of that deep knowledge navigation at 1% of the cost.
Yesterday we saw on the frontpage that LLM’s can’t even accurately assess if California produces literally all the almonds in the world.
The really weird gaps and inconsistencies just make it to untrustworthy. I spend so much time vetting all the outputs that it often cancels out the time it saves me, and I find enough errors that I don’t have an incentive to streamline things/not vet it.
That's not what I said, I said I likely understand it less than a 635B parameter LLM, and that using the LLM as a shortcut to that knowledge is something I'd consider perfectly acceptable. I might even become better at it through using the LLM.
You need a certain understanding to be able to judge whether the output is adequate. I think the argument is against people who lack that understanding.
How are you supposed to learn without doing? Who sets the bar for when you have achieved understanding?
And finally, in specific instances of creating front ends that are inclusive for users, I would argue that being willing to receive feedback and improve is vastly more important than getting it right on the first try.
So I used to hand code async http request based UIs when this feature first appeared, write cross browser css, etc. before moving to work on distributed systems backend. These days I think a blanket ban on browser scripting would be a lesser evil.
There are, roughly, 3 tiers of developers with regard to any such labor saving tech (js libraries etc.)
People who could do a good job low level and can do it faster with libraries. People who couldn't, or couldn't be bothered, before the libraries, but can now accomplish things. That is the good part. And then there are the unwashed masses, who couldn't dream of accomplishing anything on low level but now can, and who at least in case of JavaScript far outnumber the previous category. Like when I messaged a webmaster whose side would download an uncached 3mb script blob on every page load (it was their script, not ads), to render few paragraphs of text, and they responded that it was by design and the script couldn't be cashed because some variables in it changed based on time, and that is so large because it contains features necessary for other pages that have more than text. I think we'd all be better served if these people pursued a more appropriate career, for example in the roadside trash pickup.
It remains to be seen how it goes with llms, but personally I'm not optimistic.
> More people building things is straightforwardly good
No it's not, its the opposite actually its very bad and leads to far far more noise in the system to sort through to find value as someone who's competent.
Making UI less accessible is specifically not a trade off people are entitled to make. Accessibility is a legal requirement. This is like arguing it's ok to use robot construction workers who forget to install wheel chair ramps because "gotta go fast".
It really depends, up until recently (January) reading all the Temporal doc and doing the courses allowed me to frequently suggest to the current frontier model things they didn't remember. I don't know if this changed recently.
being able to increase both a11y and i18n even if imperfect are definitely a LLM value add; the problem is simply business. This doesn't make the heat->cash register bling.
Each time you say that an LLM "understands" something better than you do, you also say that you're not actually qualified to judge the LLM's understanding.
The "frontend skills" whose growing irrelevance are bemoaned in this article consist largely of navigating a minefield of unintuitive edge cases, browser incompatibilities, historic baggage, exceptions to exceptions to exceptions.
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.
I'm not an expert, but I do ship frontends that muggles (the public) get to see, and my understanding is that frontend is like the yellow brick road in the Wizard Of Oz - if you don't veer of a small set of okayish best practices, then you can deliver a pretty good experience with a small set of boring and established libraries. But if you start interacting with FOTM amazing frontend frameworks of today (or even worse, of yesterday), have to cater for the weird quirks and preferences of other devs who do things in a very particular way, or 'ingenious' hacks and weird stuff held together by hopes and dreams and duct tape, the complexity and the number of ways these worlds can interact rises exponentially.
> a common-sense mental model for web development.
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.
No, they are saying that the frameworks and tools discussed in TFA have made it look coherent. For the most part we have not worried about compatibility for a decade. All abstractions leak a bit but in practice it holds up quite well, well worth the cost savings and flexibility for many apps.
This is wrong. The underlying runtimes, HTML/CSS/ES implementations got much better, they constantly fight incoherences that old timers remember and at the same time add new powerful features.
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.
That being entirely unfair. It is still a skill. They still learning stuff. It does not help them to be trapped in a bubble. But nothing is not transferrable. Things we learn, even if they are only a React can't write vanilla JS, it's still unfair to say they have no skill.
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.
Libraries come and go, but understanding the web means mostly html, js (in the form of web APIs), and css.
I've also been using react professionally since 2015 and I've yet to see a nextjs application in the wild. It seems to mostly confined to the startup sphere.
Agreed, TFA is lamenting the loss of a golden age that never existed. I was there. IE6-only plain JS was replaced by buggy jQuery which was replaced by unmaintainable Angular SPAs which was replaced by monstrous React codebases.
Yet, understanding which tower, level and room that leaky abstraction is in is still a very valuable skill that LLM-s might not see. Just because something is not designed perfectly from the ground up by a committee does not mean it's okay to just forget everything, shut the book and let the machine calculate.
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.
modern front end is still an absolute cluster. ask claude to use react on a greenfield project: brings in tanstack, mui, tailwind, shad something or nother, all kinds of stuff. Then when you run into an issue and ask AI to fix it, you watch AI argue with itself in real-time about potential bugs in browsers and in these libraries has opened my eyes to the absolute mess that is modern UI.
> 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.
This would give the previous generation of frontend developers (aka C/C++ developers) a good chuckle. The web was viewed as a massive lowering of the barrier to entry and a "deskilling" of the craft. Assembly programmers probably thought the same of C/C++ developers.
Every layer thinks they're the most important, most highly specialized, most highly skilled layer. Every layer is wrong because every layer is built on top of the abstractions of the layer beneath. Take it all the way down to the physics and the math and you'll notice that even the set theorists assume some axioms (no one knows what the logicians are doing...)
> 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.
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.
>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.
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.
If your requirements are reasonable and serve the needs of end users and the business, doing "the bare minimum" isn't such a bad thing. "I just remove everything that is not David."
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.
I believe that anyone who has actually worked in this industry for any length of time and is being honest will acknowledge the fact that a lot of human-produced websites/web applications are mediocre at best.
The idea that every website or web app was being built by skilled artisans dedicated to the finer arts of their craft before AI is not realistic. AI didn't create spaghetti code, for example.
A lot of AI work product leaves a lot to be desired, but the realistic comparison is not to the best of what existed prior. Frankly, a lot of vibe coded apps are more functional and usable than web apps I've seen built by cheap outsourcing firms based offshore.
The big change I've seen is that before if you knew what you were doing you had two options:
- Make something crappy fairly quickly
- Make something good a little slower
AI has introduced a third option:
- Make something really crappy at light speed
A lot of companies are very excited about this and it makes it hard to advocate for "make something good a little slower" (even though AI can help speed that up.)
It feels like a race to the bottom. Companies were already prioritizing speed over quality. With AI a lot of them are doubling down.
Except that AI also allows people to make something half-decent at light speed.
Yes, the average vibe coded app might not scale to millions of users, might not be perfectly secure, etc. but let's be honest: the freelance web developer you would have paid $25,000 to build your app a decade ago was in most cases not going to deliver a highly-scalable, highly-secure product either.
AI can allow companies to prioritize speed over quality, but it has also enabled lots of small businesses and entrepreneurs to actually build things that they wouldn't have if they had to pay a developer $xxx/hour.
It still makes it a tougher sell to deliver high quality more slowly
Side note: when it comes to front end I’m thinking less about scalability and security (though they apply) and more about performance, accessibility, reaponsiveness, quality UI, maintainability, basic design sense, etc.
This is something that recently also crossed my mind. I haven't really done frontend developing for at least 10 years know, but I am already old enough to remember the time in the late 2000s when suddenly everyone stopped developing web GUIs by hand and used frameworks, and anyone still writing HTML, CSS, JS and database queries by hand was ridiculed. Job offers suddenly stopped asking for PHP / HTML / CSS / SQL / JS skills and demanded Ruby on Rails and Django and Spring and GWT, later Angular skills.
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.
On the other hand, using frameworks later on was a good attempt to standardize things. Having some homegrown GUI nobody knows how to work with isn't an advantage either.
Personally I refuse things that "feel" too big (Nuxt/Next), but like Vue... Currently though, I want to get rid of most Javascript so I'll work my way to HTMX or Alpine type solutions with server side templates.
Personally the less tech I use the better, there was a time where you had all kinds of bullshit in a web app prior to even adding a single line of custom code.
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.
I must say that already in the early 2000s web developers were tired of hand-coding everything, and many sought some sort of automation -- a framework, a CMS. Already in 2004 I made a site with barebone approach -- put a txt in a diretory tree and let PHP simply add tags instead of linebreaks and insert it into HTML. The alternative those days was a heavy content management systems. And I came to Django after two awful PHP frameworks, written by lead developers at the workplaces. So, frameworks like Django were a more gradual transition, and they were much more pleasant to work with.
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.
We're in the software industry. The whole point of that industry is automating things that are very repetitive. Frontend projects are very repetitive. And now AI is doing that for us. Fantastic, fees up a lot of time to build more interesting things.
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 opinion should only come from a CS grad who is accustomed to building CRUD apps and allergic to any real world problem domain.
At my work in insurance solutions we're solving perabyte scale problems. We do not have a Rust developer in the team, but taught ourselves with the AI and now automating workflows which took days to under a minute now.
Instead of giving up on frontend the new efficiency to AI should free resources push the frontend further, the same for backend. The world needs lots of more software than we currently can create.
Frontend developer here, frontend projects are incredibly repetitive. It is still wild to me that a complete set of UI controls that you can customize isn't native to all browsers. I can't count how many sortable / filterable tables I've implemented. I would much rather 99% of web UIs I work on that are essentially a series of forms be automated away to work on much more interesting things.
While AI coding helps a ton in building product prototypes, it also results in products that folks spot as AI from a mile away.
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 is funny about that is if you setup a basic design system, css and such, The AI generated front end code will fit right in nicely but most don't even go through that basic amount of care.
Rounded corners still seems to be the unending trend through that anything that wasn't already well defined gets infected with.
This sounds like a fantasy in your head rather than something that actually happened. No competent VC would give meaningless feedback like this- if it's good, it's good; who cares if AI built it? If it's the same quality product but wasn't obviously vibe coded, then it would be fine? Only someone ideologically opposed to AI would care.
Sometimes I think the techniques we used to build complex user interfaces in HTML without AJAX or DOM manipulation back in the early 2000s are effectively lost, like the techniques used to build the pyramids: insofar as younger full-stack developers have been "deskilled" many of them think you need Javascript to, say, validate forms.
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"
and not have to bring in <Helmet> but even if you think of front end as "just" updating the UI when data comes in from the server a complex application may need to update several bits of the UI and at some point you need to create some kind of communication or state management bus that handles that. Could it have been done differently? Sure.
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.
I often think that especially on HN React is just a four-letter word proxying some broader complaint about the interactive web and that most people complaining about it don't actually understand what problems it solves. In general if you show me the source to any sufficiently complex web app that doesn't depend on React, I'll dig through it and find the analogue to React you built inside it.
I don't agree that running a frontend application with NextJS SSR, lazy loading, etc. is "easy" compared to the days where you just wrote HTML, JS and CSS. The level of complexity and the expectations of users are in totally different places.
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.
IMO odd to frame this around the frontend and not all of software development. "The Cloud" and middleman products on top in various iterations over the last fifteen years has deskilled literally all backend work, going back even further to like, Wordpress. The remaining challenges are operating at scales that most software businesses would be wasting time optimizing for, and taste. LLMs are very good at making computers talk to each other, but taste describes the fuzzier boundary where computer meets people, and people are much more finicky and challenging to integrate with than computers.
What is a bit missing in this discussion is that many frontends are very bad, user hostile or non-intuitive. This has nothing to do with LLMs or frameworks in my opinion just bad decisions of the designer. It is not only web apps or websites filled with e.g slow cookie warnings, terrible navigation, or dark patterns. Also the UX of Android, iOS, MacOS and Windows became at most average but not at all better (many things are just worse, buggy and inconsistent). If I had thought in the early 2000s how we interact with devices in the 2020s I would never have imagined thr mediocrity that those market leading billion dollar companies release and get away with it. LLMs obviously don’t help here since they are trained on all of this.
Especially elderly people who rarely use devices suffer from this (and their relatives who do IT support :-))
Frontend web development has always been particularly vulnerable to changes in technology. The role has mostly been responsible for translating the vision of the designer into code. You could say FEs dive into things like TTFP metrics, but arguably these are all things designers care about too, and if you give AI a metric it can measure on its own it is very good at optimizing it.
If FEs want to keep working in this area, I highly encourage them to become excellent designers. Many think they are, but can't quite fly solo without a designer and soar to the same heights.
Agree and disagree. When did designers become the gatekeepers in what a page should look like and how it should behave? I never liked the pattern of leadership and design throwing a Figma over the fence and the saying “now make it”. Have seen plenty of it in agency work. If anything, AI has leveled the playing field - the onus can fall on both of them to do the doing or fess up that they need the other.
> When did designers become the gatekeepers in what a page should look like and how it should behave?
Since...forever? You may not like the waterfall model, but unless you're at a small startup this is how most software gets made. Even the more collaborative shops where FEs give input on designs, it's just that...input on designs owned by a designer. That AI leveled the playing field is my point. It's now much easier for designers to subsume the responsibilities of an FE than the reverse. You know this is true because if it weren't, designers would never have been a thing to begin with.
Isn't a lot of this complexity going away for good reason? Browser compatibility was only an issue because browsers didn't stick to the standards closely enough. It's something that's not supposed to be noticeable at all.
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.
You talk about deskilling. But are these skills even relevant to the ultimate goal of producing a web page according to the design specification? Should we have been worried about the "deskilling" that happened when we transitioned from punch cards to high level languages?
We already had a phase of "deskilled" frontend development: Adobe Flash. Any designer could open it and create interactive websites in it, no CSS or HTML knowledge required. Some slight JS knowledge (rebranded as ActionScript) you could get full interactivity, and animations were fully editable in UI. Sure, all of this came at a terrible price: no accessibility, no SEO discovery, huge loading times. But it also created some of the most innovative and artistic front ends. And a lot of things that should have never seen the light of day
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
> Any designer could open it and create interactive websites in it, no CSS or HTML knowledge required.
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
“Some slight JS knowledge (rebranded as ActionScript)” is laughably inaccurate - the was a deep familiarity with AS and all its quirks to make a performant, durable, responsive GUI in Flash. There were layers to consider when shipping a self contained executable ala Adobe Air - there were other alternative IDEs and compilers apart from Flash proper - fonts, frames, bitmaps vs vector graphics, how audio and video embedding were handled - it was a complete platform, every bit as complex a battlefield as the browser wars.
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.
Right. And Flash wouldn't end until Jobs won't come out on stage and say that Flash is eating the battery and Apple won't support Flash in their next iPhone, then Flash just ceased to exist. Apparently nobody needed innovative frontends anymore ¯\_(ツ)_/¯
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.
A very, very long time ago, at my first job, the people who used anything other than C were considered 'fake' developers and were resentful that everything was shifting away from C for most things. I felt that :)
My humble opinion: “deskilling” is an illusion. Sure, I don’t write code by hand anymore, but I spend most of my time using the knowledge and “sixth sense” I’ve developed throughout my career to control what AI is doing.
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.”
> Just like artisans and craftsmen that were replaced by assembly line workers more than a century ago
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.
Anyone who cares about the "craft" and "quality" of frontend or any other domain of programming should LOVE all the LLMs because it actually enables high code quality at very low cost. You can enforce best practices, do full code refactors, write as many tests as you want and you can do it without telling management that you need to stop writing code for 2 weeks for "tech debt". All you need is one guy with a lot of tokens to stay up with a lot of caffeine one night.
This is not the lament of the code getting worse (it's not) but the coders losing the knowledge of how to do it by hand without LLMs. If people really wanted to learn how to do things by hand, they can. In fact the AI is probably going to be infinitely more patient and knowledgable than any senior dev if you really wanna do this by hand. Just turn off the AI's ability to modify the code and just have it give you advice on the side.
The reason why nobody does that anymore is because most engineers work for capitalists not artists. It's the same reason I don't know how to farm my own food or make my own clothes like my ancestors did. Most people do programming because it's a job - not because it's an artistic passion. And that's OK.
Amen. I feel like I live in a different world than many of the commenters here. AI has made it such that most code “vibe coded” follows our root architectural practices by default. I couldn’t be more thrilled, and watching how enabled people are with this in their hands is amazing! I feel for the people in the thread who aren’t getting or feeling that experience.
My previous employer fired all front-end developers a few years ago, we went back from tons of frameworks (Vue/jQuery/Ruby/Nextjs) to simple HTML and CSS. Turns out dedicated front-end developers aren't really needed, at least not where I was employed.
I'm not entirely convinced the framework comparison holds.
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.
A generic answer to "Something is causing problems" articles: if more people have food, shelter, family, and happiness, it's good. If they have less, it's bad. I can't really tell, from inside my bubble, which is doing fine.
"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”."
that "knowledge" we held was to combat the absolute shit that was the browser ecosystem 20 years ago lol. you could argue it was a time of great experimentation and creativity, but no unified ui/ux patterns, adding in css hacks and doctypes blah blah to try to catch all these weird edge cases, if you're still reminiscing that time not sure what to say. today's tooling while also messy in it's own way is 1000x bettter. also i've never in my life referred to it as "front of the frontend".
> 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
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.
And knowing the differences between various browsers meant negotiating whether the layout being 3px off on Internet Explorer was acceptable, or whether we should ship different CSS files for different browsers to fix this discrepancy
I think there might have been two overlapping periods, but it definitely started out as you said. What I wonder is, will AI increase frontend churn, or calm it down? (More churn would be, new frontends because of new frontend frameworks, AI accelerated, less churn would be, because AI is trained on what existed before)
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.)
Web has always fucking sucked, and it fucking sucks today. The only way to make the web technologies not suck is to use them to power a vacuum cleaner.
I have a slightly different take on deskilling argument. I don't think AI is going to deskill. Someone who has spent 10 years working in any field before AI is not going to get lose too much. Yesterday I sat down to solve a medium hackerrank problem without any assistance (code complete, AI etc) and it took me 10-15 minutes to get into that mode but i was able to do it comfortably just like how i used to do it pre-chatgpt. AI might unskill the younger workforce which will enter the field, aka they will never learn the way we did.
The term applies to the skills required from workers, not to how the skills of an individual evolve over time. The argument is that AI lowers the skill requirements for software development, and therefore less skilled workers will displace the more skilled ones because they are cheaper, as (allegedly) happened in front end over the past decade.
I had recently needed to build a dashboard builder. Simple one. Copilot created it within minutes. A working even though simple looking one. Several more inputs later i had a working usable one.
Came back to it later but my tokens are finished :(. So i had to manually review the code and make changes. Code was around 3k lines in one single file and another 500 of css code. Took me a long time to understand the code and make changes.
A few days i had to make another change which changes the way it supposed to work But now without tokens it was very difficult since need to make changes in several areas which kept on breaking. Finally i re-wrote it to my understanding.
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!
You handle large code base by enforcing best practices that should have always been enforced. Proper up to date documentation, strict adherence to conventions and coding guidelines, cross review of deliverables, TDD, and so on. Just whispering "make me a dashboard" into the machine's ear is not how you drive agents to create maintainable and understandable code.
I don't think we should blame the LLMs, frameworks and the libraries necessarily. In my own experience, it feels like the real problem is a lot of companies (especially start ups) like to talk about "rapid prototyping", but are quite keen to just keep the prototype as the final product. Bootstrap, Rails, Tailwind, Nextjs and now LLM generated code... great for getting something up quickly with a semi-polished look to demo a thing. The real problem is that we're selling prototypes as products.
I don't agree that you don't have to know CSS/HTML when you use a frontend framework.
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
> knowledge of semantic HTML, CSS, the differences of various browsers, accessibility, progressive enhancement, network performance, interface design and user testing
Sorry, but developers from 2012 didn’t have proficiency in most of these skills any more back then than they do today. I would argue frameworks introduced a lot of welcome debate and discussion of these things and actually helped disseminate these skills far beyond the “old guard”, not to mention the pressure put on browsers to normalize behavior and the huge improvements to the JS language born out of the induced demand of the huge rise of web apps that were all but unmaintainable in the before-times. Obviating the need to know about browser quirksmodes is a good thing and we have frameworks, in part, to thank for that.
I just vibe code the html and css. I review the JS, but I figure if the flow of data is correct, I can just verify the html/css code through manual testing
Are we getting some real data in any industry really where AI eating jobs? I was kinda expecting those to kick in by now, but don't think it's happening.
kinda funnily I think front end died right when all the folks say that the golden age began, at least for craftsmen.
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
I reject the core assertion that there was a "lost decade" at all. I was deep in the frontend industry during that time, and many "use the platform" purists completely missed the reality of what people were building with better abstractions: much more complicated and ambitious frontend apps. These apps heavily used new browser APIs and features, they just did a lot of it in frameworks like React, which these purists despised. I think the era we're in right now is fundamentally different.
> Just like AI is deskilling programming now, JavaScript frameworks have deskilled frontend development in the last decade.
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.
Great UI cult could be an early pre-ai phenomena , not a lost decade.
you will need 100 times less of front end , if any action can be asked or explain in voice, text or video or slides always custom to your request. you don't need navigation complex forms to structure. just text, animation to wait, and a few way to embed more complex structures, like text and basic html with charts.
this sounds like "almost ui" but in reality it's not. this is text + some custom visuzalizations adhoc.
> 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.
What does he mean by this? What skills were lost? Writing HTML templates?
Understanding the DOM. Understanding performance. Understanding closures. Knowing how an event bubbles. Understanding CSS… at all.
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.
Very interesting, i didn't know that frontend developers experienced deskilling before. I thought that slop was the usual way of doing things in frontend (or backend).
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.
Everyone had a chance to learn vanilla js from the mozilla docs but using jquery was much much simpler. Concede that jquery is more difficult than prompting. The issue for me is that prompting a front end and everything looks exactly the same. More cookie cutter than what wordpress and wix offered
Right. So we are stuck with the jquery and wordpress forever. Because this is THE cookie cutter and it's good enough.
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.
Oh don't me wrong, it's bad and we're going to suffer through terrible web apps for the foreseeable future spat out in the 1000s per day. Like all slop songs, images, videos and articles. Hardly a reward for building something artisanal in the digital space
I think it's more likely to cause a lost Decade of people not going into CS or tech due to lack of entry-level jobs. Maybe next time there's a boom and the pendulum of the power dynamic between management and labor swings more towards the workers, tech workers will unionize or organize better. I think overall it will benefit the industry because these boom and bust cycles for employment are just not healthy.
There is no guarantee that there will be a boom again. Some jobs disappear. Maybe we'll really only need a handful of elite engineers who continue advancing the foundational tools we use (kernels, databases, hyperscale low level cloud products, drivers, etc.) and the rest of "programmers" and "software engineers" will be replaced by "prompt engineers". With a new generation mostly unable to read and reason about source code.
There will always be some nerds left with brains so big they only scratch their itch if they are advancing performance critical v8 code in pure assembler. But the bar will rise for that to be something you get money for…
Frontenders took a relatively simple problem and inflated the complexity to astronomical scales by wrapping it in ridiculous unnecessary functional programming concepts. And just when it felt like it couldn't get any more arcane or complicated they introduced the hooks API.
The period 2015-2025 was a decade of frontenders fooling their managers into letting them build their own job security into their web UI.
I'm going to say something that is a bit out there, but to this day web frontend still feels like a downgrade in some ways to basic things Visual Basic had in 1998.
I was having similar thoughts about building UIs back in the late 90s and a few years thereafter. There were a number of tools, I remember using Tcl/Tk to create a GUI scheduling program that was relied on for many years. Later on we had Delphi and numerous others. I suppose building for the web was so much more complicated because the HTML/CSS/JS infrastructure was ill-suited as a basis for comparable GUIs.
I worked mostly on frontend in 2012-16, in plain HTML+CSS, and then quit, because React was required everywhere, and I tried and hated it.
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.
> 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
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.
The article compares LLMs to Stack Overflow and calls it "a continuation of the same trend", but I think there's a big difference.
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.
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
What's one more layer, right?
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.
The part on the Bauhaus movement is weird, and I'm not sure I agree about how the author thinks about users.
>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.
IMHO Bauhaus was about design for functionalism and 'getting the job done' efficiently. When viewed in this sense, a Bauhaus frontend might be gopher, an old Nokia phone, or the unix command line.
A modern tent is arguably the evolution of the Bauhaus spirit applied to structure. Tents do suck in comfort compared to pre-Bauhaus European buildings, but if you're going to carry a building to the top of a mountain, they're not a bad option!
ie. Pre-Bauhaus = It costs what it costs. Tradition reigns. Bauhaus = Mass manufacturing and material properties in-scope for design, resulting in often better design when holistically considered.
I mean, maybe it was a "lost decade" from the perspective of frontend developers, but I can't say I'm nostalgic for an age where everyone is handrolling everything from legacy browser support to responsive designs and I'm hoping they have a good understanding of all these things because the average page would be much worse than it is with everyone using these libraries.
I’m using AI to create UIs and I find myself having more time to think about UX rather than CSS. It actually gave me “time” to quickly test design ideas an implement minor details.
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.
Yeah coming from the backend world using AI for UI tweaks can really unlock me to have a decent looking app with reasonable UX in a much shorter amount of time. Maybe the code is “slop” but usually I can spend just enough time to take away the cognitive debt and still feel like I’m ending up in a better place
There is a difference between a run of the mill CRUD React app and solving specific, complex UI problems.
I have been a programmer for a long time and CSS is still the hardest language to master. There are countless quirks and APIs most people have never heard of that solve extremely specific problems.
For example, using @starting-style with allow-discrete to use display: none on CSS transitions. Knowing that you would need to use this API, what it does, and how to debug your CSS is a skill that will be hard to replace with an LLM because of the fine grained detail needed for CSS. If you do not know how this API works and you need to use it for whatever reason, and then need to adjust your transitions later, it's probably faster to have real CSS skills than to constantly have to prompt an LLM for you.
I'm allegedly a fullstack dev, often working on fullstack features, but I haven't had to think deeply about much on the frontend all year. 90% of my thought/work goes into backend work. The AIs just handle the FE stuff easily based on our existing patterns. Not saying it's perfect or can't be improved, but it pretty much always "just works" perfectly well enough.
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.
> 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.
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.
Honestly I think what is missing is not developers but designers. Or, I should say, designers hired to create competent designs that serve people well and not to instead manipulate users. If you want better front ends - get more and better designers! As for front-end code, I don't expect to ever write a line of that again in my life.
> 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
I'm sorry but that simply does not make any sense. How is increasing the breadth of your skills leading to a deskilling?
Read in context. He's referring to the evolution of skill at group level, he even puts out the definition of deskilling and mentions 'skilled labor'. He then explains how frontend used to be a 'highly specialized skill', and how modern devs use Frameworks to consider browsers almost hidden compilation targets.
The article explains at length what they mean by "deskilling" and it does not mean that individuals lose their skills.
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.
Just watch the terrible soup produced by MIT-bred Leetcode ninja "engineers" in money raining startups and FAANGs.
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.
Opening with this claim of ‘Front end’s Lost Decade’ then not explaining what that is is infuriating to me, a front end developer - which decade was this supposed to be? How/Why was it ‘lost?’ How did I miss it?
People don't use web tech because they care about quality, they target it very specifically because its one of the places where quality doesn't matter. If your native app crashes, your users will curse your name. Webpage or Electron slop freezes? They'll shrug and restart.
This idea that quality ever existed on the web is ahistorical at best.
They target it because it's the best distribution platform we have, the tech stack is unified, and managing native apps has only gotten less attractive over time. Chrome, the only native app that matters to most users, re-opens your tabs on the rare occasion it crashes. Most native apps are much less reliable than that.
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.
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.
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?
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!
- good test, wrong layer, would turn into a mess of "wait why'd tests over there blow up for changes over here"
- mostly-good test, subtle issue (yes, this is the status quo with most human-written tests, but the risk of not being careful is that you (or the agent you throw at crap) now is overconfident in your future changes)
- weird silly test like "assert that calling the six statements in this method in the right order do the right thing" without... actually calling the method itself... so don't protect against changes to the method?
For non-greenfield work I've recently been much more happy with their out of the box code change quality then their attempts at adding coverage for those changes!
I think this is an area that has remained hard because putting directives in CLAUDE.md or whatnot for tests is generally gonna be so generic to be useless, like "put tests in the right place" without more module-specific context. Whereas if I'm making a non-greenfield change, I'm thinking much more in my prompt about constraints on the code itself, and much less about the current shape/state/organization of the tests or what to direct it on.
Properly used it's great. Definitely improved my test coverage a lot.
But it's entirely still in the world of "people who'd care to write good code before will write good code faster; other people will just write mediocre code faster."
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.
I agree integration tests are best, with some e2e testing for common scenarios.
I worked at a place that required unit tests for every new method or function. Arguments like "this other (integration) test already covers that. why do I have to add another test?" wouldn't fly. PR reviews would often degrade into arguments about testing and how all database access needed to be mocked...
I just saw this comment yesterday about one of the tests from Bun’s rust rewrite: https://news.ycombinator.com/item?id=48314311 It reads in the raw source code and uses a regex to assert that “unsafe” is used.
> These days, I don’t even bother with unit testing. They are a maintenance burden
I’ve come to the same conclusion, but that’s only because I’m working on solo projects. I think they are probably worth it with multiple devs on the same project.
But that was my testing strategy already, but writing one of those tests could take legitimately hours with how many columns and crazy rules our area has.
Setting that up and making sure it works, at the early stages, is not what LLMs do best, today. This sort of work is possibly incredibly valuable in the next 12-36 months, depending on what LLMs can be designed to do out of the box.
An Agent that can deliver the correct legal review process for a patent and is correct often enough to validate the savings vs real humans, or at least the speed increase + manual review ala code reviews, is incredibly valuable.
Are we there yet? Maybe this is where current groups like FNCR are trying to go.
But the key here is: LLMs don't have latent rigor, nor any other kind of rigor.
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.
Could I have done it on my own? Yes, eventually. The problem is I would've lost interest and moved on to some other useless project before getting that far.
For example, imagine if textual-serve author would reimplement xterm.js What effect it would make on quality.
LLMs increase technical debt rapidly. It is unclear whether they can deal with the mess they create. But we'll know soon (no need to wait years, to get immovable mess).
The positive side of LLMs is that they confirm experimentally the usefulness of many software engineering practices (testing,docs, adrs, design, formal specs etc)
You get a lot of things for free with LLMs. You program an input box that goes to a form, handle the backend, make sure the variable names match the box, the API, the data structures and the database columns. All the brain matter making sure that flow works is mastered by an LLM since even with GPT 3.5 (not that I am advocating using that anymore). But the point is, since that's taken care of, why not also let it handle aria, input hints, mouse effects, state storage, animations since most of it's handled by putting "handle aria, input hints, mouse effects, state storage, animations" any time the front end files are changed." in agents.md
I would say that's rigor. Now you go a step further and have another LLM in your QA cycle that double checks it.
You're responding to an assertion with an assertion. It has been empirically proven that SOTA models can create more dogshit software than pre-AI software. It is also trivially known that the user is unable to predict when and how the AI will introduce dogshit into the software. We literally had a study posted on this forum claiming models give more accurate answers if you're mean to them. This is the shit we're dealing with. Stuff you couldn't make up in a dystopian Douglas Adams novel.
>you can encode these things into prompts
Is this satire? SOTA models randomly disobey rules in prompts all the time.
When a dev drops a production db I can warn them. If they do it multiple times during their employment I can change their roles or fire them.
I can count the number of companies providing SOTA models with the fingers on my hands. Imagine having an employee pool of only 5 savant coders with dementia to choose from to hire to your company. That's it. Thats the entire applicant pool. You can only fire one of them by hiring one of the other four to replace them with. And you can't really fire them for dropping production dbs if you can't prevent the other ones from making the same mistake. This is the current AI-first hellscape as it stands.
So far the way AI is making software better is mostly checking for common bugs and acting as review/pair programming buddy, not the code.
The code is bad. At best okay. But you can make a lot of it. And it's not bad enough to not be good enough.
For example, WPF programs can have great accessibility - this comes from the fact that programmers can manipulate primitives which are semantically meaningful (buttons, lists etc).
In HTML its just a sea of divs which lately have become an implementation detail to hang classes on to, and sometimes not even exposed directly to the developer, if you use a SPA framework.
There's not a snowballs chance in hell you can build a quality accesibility solution on top of that.
HTML's main idea was that HTML was a document model, that described the content in a semantically meaningful way, and CSS was the 'rest' which kind of allowed to make the whole thing pretty - the idea going as far as separating content from looks should allow people to 'theme' their websites and completely redefine layout.
That idea has been completely abadoned. I'm not a frontend dev - although I can make a competent webpage by myself, I don't have deep insights into what's going on in the field - maybe Web Components will allow people to create semantically meaningful pages in a standard way?
Maybe there should be another layer of abstraction on top of what we have - which is truly semantic, this time for real?
Today I find myself having less patience for it all, because things just tend to work a lot more often than they don't.
With AI, I find so many small businesses and others I deal with which have their own websites have started to have better design, better performance and while I don't know if they are really accessible but they tend to have more prevalence of aria labels.
Not to take away from your experiences, just sharing my anecdotes.
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.
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.
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).
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.
At first it confused me why my GPU usage spiked and fans started blowing harder, but now I see it is a common mistake that AI makes but no one tests properly. It is possible a human can make this mistake but I sheldom experienced this ever in my life until now.
I run 240hz monitors, and that meant the browser was trying to do 240 repaints per second. Blocking it with unlock origin is the only way. Ridiculous
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!
This seems like a good insight and it feels true to me as well.
My guess is the absolute number of people who treat it like a "craft" is higher than 20 years ago, but as a fraction of all developers it has shrunk dramatically.
That is not remotely the case. All software, not just websites, is a lot worse than it was 10 years ago. Bloated, slow, buggy messes that resulted from the industry hiring a bunch of people who just wanted to do the bare minimum and make fat stacks, rather than hiring people who actually care about good engineering.
Holy shit, no, they are not. What world do you live in?
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.
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?
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.
It does work, it is called RLVR, reinforcement learning from verified rewards, is is based on testing code by execution. It's become a major area of improvement in the last year. But you are also forgetting the amount of steering and problem solving going into coding agents today, and the huge logs they create which can feedback into training. We automated stackoverflow, LLM learns from usage and self play.
My documentation tends to be more thorough and well-maintained when I'm building software with a coding agent. A million tokens of context tends to be better at that kind of thing than my own brain when I'm neck-deep in solving a difficult problem.
And presuming the best practices are adequate and don't need to evolve (which seems unlikely) - then the current public historical record is also adequate.
> 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.
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.
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
And if everyone bunkers up and all that open content dries up starting in 2026, let's say, what happens?
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.
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.
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.
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.
Imagine you have a 4B model and keep an equal size corpus of search stubs, small MD documents linking to hubs, feeds and search engines for millions of topics. You can use the LLM to read the stub and perform the search for you, all orchestrated locally, with greater privacy and independence. You can dis-intermediate the search chokepoint now. You can set the criteria for what to include, exclude, how to rank and present the results.
This works because good entry points for any topic change slowly over time. The construction of search stubs is trivial with existing AI agents, and can be shared as open source. A few GB for the model, a few for the search routing layer, and you got a sovereign local agent.
If this holds, access control shifts from whatever Google thinks maximizes profit to whatever the community thinks has value.
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.
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.
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.
We will see how this shakes out in the coming years, as Anthropic, OpenAI & co file for IPO or run out of private funding. Grok is already on the ropes as seen from the SpaceX IPO.
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.
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?
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.
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.
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.
And yet we could build native apps a plenty in the 90s and 2000s, with 1/100 the resources (tutorials, third party libs, native GUI frameworks, IDEs, etc) available, and 1/10th the target user base.
It's not about "platform specific code, being hysterically expensive to build and maintain". It was more expensive in the 1990s and 00s too, but people built it and maintained it just fine.
It's companies chosing convenience.
Especially since it's not poor programmers and small software shops going for Electron. It's the biggest multi-billion to trillion dollar companies.
Facebook uses this crap, Slack uses this crap, Adobe and Google use similar web-based UI crap (in what used to be native apps), and so on.
And 1/100th the feature footprint.
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.
Well there's your problem right there
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.
Let me guess, you stopped reading web standards documents because Facebook told you it didn’t matter, since you could just ship 10MB of javascript with every request
Try again.
But then CSS came along and threw out the baby with the bathwater, returning us back to the bare primitives, forcing entities to redo all that work again. Except this time CSS didn't offer a good mechanism to wrap up that hard work in a nice API bow, so everyone ended up getting pushed into having to redo that same hard work every time they started a new project, leading to a bunch of poor, inconsistent, and often downright wacky implementations.
To be fair, the problem isn't CSS per se, it is just that it is much too low-level for all but the small number of entities focused on the aforementioned hard problems and browsers failed to offer anything higher-level for the rest of us. Javascript has tried taking on a stand-in role for the lack of the higher-level abstraction being natively offered by the browser, but that comes with its own limitations so it isn't always a viable choice, not to mention that having to resort to using a full programming environment completely defeats the purpose of having CSS.
CSS gets all the hate because it is more often than not the wrong tool for the job but the only tool available at hand.
I dunno, seemed easier 20+ years ago when in high school we were taught how to use Delphi than now.
HTML/CSS is just terrible way to build interfaces. It was made to build basically resizeable documents, not applications, and it shows in every crevice
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.
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.
The resource burn is an Electron problem. I member using HTML as "Active Desktop" in the Windows 98 era. You could drag an Internet Explorer widget into VB6 applications if you wanted (OLE, COM and ActiveX, damn that was an era of powerful technologies!). But it was one shared runtime across the OS which meant it did not have anywhere near close to the performance impact that even one Electron app has today.
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
Big corporations behind LLMs are taking it all.
Less of an accident than a byproduct of the unique ecosystem the web lives in (which is a positive!) Compare to say, backend development. If I said database indexes are deeply inconvenient and that I shouldn't have to make them I'd get laughed out of the room and justifiably so. But by comparison when a developer says "I don't care to learn CSS" folks nod their heads in agreement.
Why is that straightforward? As an example, right now every year on Steam there are thousands of games released. A lot of them are just shovel ware that nobody ever plays, but it does end up hiding actual quality stuff in the noise. Same thing happens in app stores. Gatekeeping that limits opportunity is bad. But gatekeeping around quality is very good. Wanting your software to be written by someone who cares about software and has expertise is, to me, more straightforwardly good.
Right now people are blaming vibecoding for decline in a lot of mature software products, whether that's fair or not (I think it's frequently unfair). I think there's a possibility that's going to morph into "AI First" companies being seen as poor quality brands. Already we see in games that when listed they have to disclose if AI was used or not, and if it was, it damages the credibility quite a bit.
As long as it’s “for you” or “small time”, there really isn’t a problem at all.
The only real downside so far to LLMs (ignoring environmental concerns) is when they’re heavily used and left unrestrained to go play with financial data, healthcare data, PII, anything with real consequences when it breaks. If a person is using it to automate their life. If a father is using it to help their kid with accessibility issues speak. If an artist is using it to help them write code so they can make a game. These are all good things.
You might think it’s shovelware; but the creator of those things is now super excited that their vision was made or their niche issue was helped, when no one else would.
I still don’t understand this perspective, how is it good when a growing portion of stuff that’s built is straight garbage?
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.
Just open Steam, PSStore, Nintendo store.
Still doesn't.
I'd read it kind of like 'The man and the butterfly' story. Or the Kant passage about how doves might wish air didn't exist, without realising that friction is exactly what permits them to fly.
Both have been lost; good riddance the former, but I miss the latter.
Is it? More than a decade ago there was a Cambrian explosion of software, Flash alone was the defining force of indie gaming industry. And now what? We have so much shit/shovelware that nobody wants to touch with a ten-foot pole.
It depends. My country (Germany) introduced accessibility laws recently which enforces you to build everything public with accessibility in mind. If a page doesn't meet the expected standard you can get extremely high fines.
If AI were already the norm, and someone came along and said, "hey! I've got a great idea! Instead of AI building all this stuff, what if we did it by hand?" and talk about all these amazing benefits to hand crafting code, people would largely say no thanks.
As far as the abstraction argument goes, well, we've been creating higher order abstractions for a long time and called it good. I don't see why we should suddenly be against abstraction.
The reality is probably bimodal. The people who are benefiting are benefiting a lot, but they're likely in a minority. The majority will be tokenmaxxing at great expense and spinning their wheels in real terms.
But there's no hard research to prove that.
Considering the huge sums involved, the absence is interesting.
Reality is certainly bimodal today, but that's because as an industry we're lagging behind capability. We're in the early days of the innovator's dilemma S-curve.
Only because you've not invested time[1] to learn a11y, but that is par for the course: LLMs are pretty good at impressing people without a deeper understanding of a field with its statistically average outputs.
My hot-take: one shouldn't oversee an LLM task whose output they are unable to evaluate.
1. And you don't have to! We have limited time, accessibility is broad, there are numerous standards, and screen readers can be unergonomic, to put it lightly. But a human has common sense, and can care. I doubt there's enough a11y training data to match a caring human testing and thinking through interactions. Sadly, human software QA is now threatened with extinction.
This reminds me of the Upton Sinclair quote: “It is difficult to get a man to understand something when his salary depends upon his not understanding it.”
LLMs feel threatening to anyone who had an edge by knowing how to navigate domains with a lot of weird and complex behavior. It’s nice to feel like businesses need you if they want to solve a problem. It’s scary when a cheaper solution arrives that does 70% of that deep knowledge navigation at 1% of the cost.
Also reminds me of that episode of Star Trek TOS 'The Ultimate Computer'
And the STTNG episode 'The Game'
Einstein was correct, the only thing in the universe that is infinite is human stupidity.
That is why I feel threatened by LLMs.
The really weird gaps and inconsistencies just make it to untrustworthy. I spend so much time vetting all the outputs that it often cancels out the time it saves me, and I find enough errors that I don’t have an incentive to streamline things/not vet it.
To make the obvious counterargument, “then you shouldn’t be creating websites at all”.
I don’t actually believe this, but I know people who do. Some would add “shouldn’t be allowed to”.
It's debatable if the same should apply to the vast majority of software that is less critical.
How are you supposed to learn without doing? Who sets the bar for when you have achieved understanding?
And finally, in specific instances of creating front ends that are inclusive for users, I would argue that being willing to receive feedback and improve is vastly more important than getting it right on the first try.
Some people are writing the Netflix homepage (where an outage costs millions of dollars), and some people are writing a blog for three readers.
There are, roughly, 3 tiers of developers with regard to any such labor saving tech (js libraries etc.)
People who could do a good job low level and can do it faster with libraries. People who couldn't, or couldn't be bothered, before the libraries, but can now accomplish things. That is the good part. And then there are the unwashed masses, who couldn't dream of accomplishing anything on low level but now can, and who at least in case of JavaScript far outnumber the previous category. Like when I messaged a webmaster whose side would download an uncached 3mb script blob on every page load (it was their script, not ads), to render few paragraphs of text, and they responded that it was by design and the script couldn't be cashed because some variables in it changed based on time, and that is so large because it contains features necessary for other pages that have more than text. I think we'd all be better served if these people pursued a more appropriate career, for example in the roadside trash pickup.
It remains to be seen how it goes with llms, but personally I'm not optimistic.
No it's not, its the opposite actually its very bad and leads to far far more noise in the system to sort through to find value as someone who's competent.
The users are also entitled to hate your website or app. At what point do you admit you're just making excuses for cheap and sloppy work?
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.
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.
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.
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.
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
I've also been using react professionally since 2015 and I've yet to see a nextjs application in the wild. It seems to mostly confined to the startup sphere.
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.
This would give the previous generation of frontend developers (aka C/C++ developers) a good chuckle. The web was viewed as a massive lowering of the barrier to entry and a "deskilling" of the craft. Assembly programmers probably thought the same of C/C++ developers.
We've moved the comment to the right thread.
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.
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.
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.
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.
The idea that every website or web app was being built by skilled artisans dedicated to the finer arts of their craft before AI is not realistic. AI didn't create spaghetti code, for example.
A lot of AI work product leaves a lot to be desired, but the realistic comparison is not to the best of what existed prior. Frankly, a lot of vibe coded apps are more functional and usable than web apps I've seen built by cheap outsourcing firms based offshore.
- Make something crappy fairly quickly
- Make something good a little slower
AI has introduced a third option:
- Make something really crappy at light speed
A lot of companies are very excited about this and it makes it hard to advocate for "make something good a little slower" (even though AI can help speed that up.)
It feels like a race to the bottom. Companies were already prioritizing speed over quality. With AI a lot of them are doubling down.
Yes, the average vibe coded app might not scale to millions of users, might not be perfectly secure, etc. but let's be honest: the freelance web developer you would have paid $25,000 to build your app a decade ago was in most cases not going to deliver a highly-scalable, highly-secure product either.
AI can allow companies to prioritize speed over quality, but it has also enabled lots of small businesses and entrepreneurs to actually build things that they wouldn't have if they had to pay a developer $xxx/hour.
It still makes it a tougher sell to deliver high quality more slowly
Side note: when it comes to front end I’m thinking less about scalability and security (though they apply) and more about performance, accessibility, reaponsiveness, quality UI, maintainability, basic design sense, etc.
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.
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.
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.
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!
At my work in insurance solutions we're solving perabyte scale problems. We do not have a Rust developer in the team, but taught ourselves with the AI and now automating workflows which took days to under a minute now.
The entire complaint here is that automating this risks that was is encoded is not what you want.
I’m sorry, what? This is such a shit take, I don’t even know where to start. What’s repetitive about them? That all UIs contain buttons or what?
If this is something that people actually believe, I can understand why UX has went to shit and then got even worse since the 90s.
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.
Rounded corners still seems to be the unending trend through that anything that wasn't already well defined gets infected with.
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
and not have to bring in <Helmet> but even if you think of front end as "just" updating the UI when data comes in from the server a complex application may need to update several bits of the UI and at some point you need to create some kind of communication or state management bus that handles that. Could it have been done differently? Sure.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.
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.
Especially elderly people who rarely use devices suffer from this (and their relatives who do IT support :-))
If FEs want to keep working in this area, I highly encourage them to become excellent designers. Many think they are, but can't quite fly solo without a designer and soar to the same heights.
Since...forever? You may not like the waterfall model, but unless you're at a small startup this is how most software gets made. Even the more collaborative shops where FEs give input on designs, it's just that...input on designs owned by a designer. That AI leveled the playing field is my point. It's now much easier for designers to subsume the responsibilities of an FE than the reverse. You know this is true because if it weren't, designers would never have been a thing to begin with.
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.
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
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.
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.
Often - the people who are replaced don't recognize the inherent skills of the people who operate the machines that do their work.
But there are often non-obvious tradeoffs.
Having Ikea means we can have vastly, vastly more selection and choice in the things we put in our homes.
And the 'quality' is usually fit for purpose (just because it's not made of Oak, doesn't mean it won't last a very long time).
But when you see a winding staircase or those custom moulds .... well you realize 'what we've lost'.
There's always a trade-off even if the net positive is there.
That 'externalized craftsmanship' sure does add up though ...
It's not so much the people who _operate_ the machines as the people who _build_ the machines.
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.”
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.
This is not the lament of the code getting worse (it's not) but the coders losing the knowledge of how to do it by hand without LLMs. If people really wanted to learn how to do things by hand, they can. In fact the AI is probably going to be infinitely more patient and knowledgable than any senior dev if you really wanna do this by hand. Just turn off the AI's ability to modify the code and just have it give you advice on the side.
The reason why nobody does that anymore is because most engineers work for capitalists not artists. It's the same reason I don't know how to farm my own food or make my own clothes like my ancestors did. Most people do programming because it's a job - not because it's an artistic passion. And that's OK.
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.
that "knowledge" we held was to combat the absolute shit that was the browser ecosystem 20 years ago lol. you could argue it was a time of great experimentation and creativity, but no unified ui/ux patterns, adding in css hacks and doctypes blah blah to try to catch all these weird edge cases, if you're still reminiscing that time not sure what to say. today's tooling while also messy in it's own way is 1000x bettter. also i've never in my life referred to it as "front of the frontend".
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.
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.)
The former. It’s definitely the former, at least until subsidized tokens run out.
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!
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
https://www.youtube.com/watch?v=JOcz-H5u3Rk
Sorry, but developers from 2012 didn’t have proficiency in most of these skills any more back then than they do today. I would argue frameworks introduced a lot of welcome debate and discussion of these things and actually helped disseminate these skills far beyond the “old guard”, not to mention the pressure put on browsers to normalize behavior and the huge improvements to the JS language born out of the induced demand of the huge rise of web apps that were all but unmaintainable in the before-times. Obviating the need to know about browser quirksmodes is a good thing and we have frameworks, in part, to thank for that.
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
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.
you will need 100 times less of front end , if any action can be asked or explain in voice, text or video or slides always custom to your request. you don't need navigation complex forms to structure. just text, animation to wait, and a few way to embed more complex structures, like text and basic html with charts.
this sounds like "almost ui" but in reality it's not. this is text + some custom visuzalizations adhoc.
What does he mean by this? What skills were lost? Writing HTML templates?
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.
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.
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.
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.
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.
The period 2015-2025 was a decade of frontenders fooling their managers into letting them build their own job security into their web UI.
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.
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.
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.
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:
What's one more layer, right?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
[4]: https://en.wikipedia.org/wiki/Hygienic_macro
[5]: https://github.com/olooney/fourth_gen
>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...
A modern tent is arguably the evolution of the Bauhaus spirit applied to structure. Tents do suck in comfort compared to pre-Bauhaus European buildings, but if you're going to carry a building to the top of a mountain, they're not a bad option!
ie. Pre-Bauhaus = It costs what it costs. Tradition reigns. Bauhaus = Mass manufacturing and material properties in-scope for design, resulting in often better design when holistically considered.
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.
I have been a programmer for a long time and CSS is still the hardest language to master. There are countless quirks and APIs most people have never heard of that solve extremely specific problems.
For example, using @starting-style with allow-discrete to use display: none on CSS transitions. Knowing that you would need to use this API, what it does, and how to debug your CSS is a skill that will be hard to replace with an LLM because of the fine grained detail needed for CSS. If you do not know how this API works and you need to use it for whatever reason, and then need to adjust your transitions later, it's probably faster to have real CSS skills than to constantly have to prompt an LLM for you.
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 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.
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.
I'm sorry but that simply does not make any sense. How is increasing the breadth of your skills leading to a deskilling?
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.
When something goes wrong, no one understands anything.
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.
This idea that quality ever existed on the web is ahistorical at best.