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.
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.
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)
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.
It depends on the software. But, generally speaking, I try to use and write the best software available that solves my problem, even if it's one of a kind; it doesn't really matter if the other 99.9999% of the software in the space is broken.
Given 1000 hours to work on a problem, an LLM will continue to yeet out mediocre variations on a theme. Give me 1000 hours to work, and my product will keep getting 1% or 2% better until it's much better than any shit an LLM would spit out.
Similarly, I would much rather use someone else's emulator that they spent 1000 hours on than have AI yeet out some mediocre shit that kinda works, but is really just a mindless exploitation of something that someone else wrote that was actually good.
Then, you follow that with, "Yeah, but AI just allows you to iterate faster and skip the boring stuff, so that you make your product better even faster."
And then I follow that with, "The part where you take it apart piece by piece and study each piece and get kicked in the head by the realities of your lack of understanding is the part that's actually valuable, and it's precisely what you're skipping with an LLM"
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.
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.
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.
