Comment by m132
3 hours ago
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=47390945
It gets worse when you realize that most of the money saved through these cuts only benefits the very top of the hierarchy.
> 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!
1 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.
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.
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.
> 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.
> 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).