Is AI causing a repeat of frontend’s lost decade? • Hacker News Board

Re: Is AI causing a repeat of frontend’s lost decade?

#271

Post by ThunderSizzle » Sat, May 30, 2026, 2:59 AM UTC

skydhash wrote: post #151

hombre_fatal wrote: post #104

Earlier quoted context omitted.

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…

> 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…

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.

Re: Is AI causing a repeat of frontend’s lost decade?

#272

Post by greeklee » Sat, May 30, 2026, 3:01 AM UTC

[dead]

Re: Is AI causing a repeat of frontend’s lost decade?

#273

Post by oblio » Sat, May 30, 2026, 3:02 AM UTC

aspenmartin wrote: post #150

oblio wrote: post #107

Earlier quoted context omitted.

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…

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.

Re: Is AI causing a repeat of frontend’s lost decade?

#274

Post by esalman » Sat, May 30, 2026, 3:13 AM UTC

fg137 wrote: post #213

jillesvangurp wrote: post #58

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 comp…

You might be surprised to find out that there aren't that many "interesting things" to build.

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.

Re: Is AI causing a repeat of frontend’s lost decade?

#275

Post by geophph » Sat, May 30, 2026, 3:15 AM UTC

mariopt wrote: post #51

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

Re: Is AI causing a repeat of frontend’s lost decade?

#276

Post by cyberrock » Sat, May 30, 2026, 3:24 AM UTC

coldtea wrote: post #215

x0x0 wrote: post #174

Earlier quoted context omitted.

> 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 c…

> 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 90…

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.

Re: Is AI causing a repeat of frontend’s lost decade?

#277

Post by ElProlactin » Sat, May 30, 2026, 4:17 AM UTC

ai_fry_ur_brain wrote: post #260

ElProlactin wrote: post #25

> 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 mediocri…

You have terribly low standards for quality

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.

Re: Is AI causing a repeat of frontend’s lost decade?

#278

Post by majormajor » Sat, May 30, 2026, 4:33 AM UTC

hombre_fatal wrote: post #104

m132 wrote: post #89

Earlier quoted context omitted.

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…

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

Re: Is AI causing a repeat of frontend’s lost decade?

#279

Post by majormajor » Sat, May 30, 2026, 4:34 AM UTC

mega_dean wrote: post #239

skydhash wrote: post #151

Earlier quoted context omitted.

> 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…

> 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…

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.

Re: Is AI causing a repeat of frontend’s lost decade?

#280

Post by paulhebert » Sat, May 30, 2026, 4:45 AM UTC

ElProlactin wrote: post #277

ai_fry_ur_brain wrote: post #260

Earlier quoted context omitted.

You have terribly low standards for quality

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 pr…

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.