upvote
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.

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.

reply
> 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.

reply
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?

reply
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!

reply
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.
reply
0% if by testing you mean "somebody who uses a screen reader regularly was able to use the product successfully" because nobody seems to do that.
reply
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.

reply
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.

reply
> As a protagonist of "decent", you have it increasingly harder competing against those pushing for "acceptable".

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.

reply
> 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).

reply
> 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.

reply
> 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?

reply
> 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.

reply
> 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.

reply
> 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.

reply
> It can read the code? Historical discussions around it? Commit histories?

And if everyone bunkers up and all that open content dries up starting in 2026, let's say, what happens?

reply
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.

reply
> 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.

reply
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.

reply
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.
reply
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.

reply
> 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.

reply
This is super hilarious :-)))

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.

reply
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.
reply
> Once they no longer write about it, what then?

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?

reply
> 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.

reply
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!

reply
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!
reply
Ya it's definitely been an ongoing process. LLMs have just accelerated it.
reply
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.
reply
>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.

reply
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.

reply
> this is largely accidental complexity.

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.

reply
>that has to deal with the other constraints of the web platform.

Well there's your problem right there

reply
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.
reply
> 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.

reply
"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.
reply
You could argue that most users do not notice or care about this at all so it's a completely reasonable sacrifice to make to have rich applications.
reply
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.

reply
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.
reply
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

reply
Most of software engineering is accidental complexity. Sharding, buffering, caching, load balancing, contention, async, functions, classes, recursion…

Big corporations behind LLMs are taking it all.

reply
There's a huge difference between everything you mentioned, and dealing with 'browser quirks' like:

  <!DOCTYPE html>
  <!--[if IE 8]> <html lang="en" class="ie8 no-js"> <![endif]-->
  <!--[if IE 9]> <html lang="en" class="ie9 no-js"> <![endif]-->
  <!--[if !IE]><!-->
  <html lang="en" class="no-js">
  <!--<![endif]-->
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.
reply
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.
reply
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.
reply
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.

reply
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.
reply
> More people building things is straightforwardly good

I still don’t understand this perspective, how is it good when a growing portion of stuff that’s built is straight garbage?

reply
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.
reply
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
reply
I will pick the software not existing at all every time. Easily without a thought.
reply
Depends upon the filtering system.

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.

reply
>...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.

reply
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.
reply
> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.

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”.

reply
I wonder what went so wrong that "if you don't understand [thing] you shouldn't be building [thing]" is now considered a controversial statement.
reply
If you're building bridges, this shouldn't be a controversial statement. Same if you're building cryptography software.

It's debatable if the same should apply to the vast majority of software that is less critical.

reply
Keep in mind these are two different things. Not all websites need to be accessible.
reply
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.
reply
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.
reply
Well, there's degrees of understanding, as well as degrees of seriousness of the project. You can also learn a lot by building something.

Some people are writing the Netflix homepage (where an outage costs millions of dollars), and some people are writing a blog for three readers.

reply
> 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.

reply
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.
reply
> 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.

reply
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".
reply
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.

reply
> that's a tradeoff people are entitled to make

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?

reply
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.
reply
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.
reply