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

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.

i wonder if you’ll still feel the same way in two years. knowledge decays slowly and the suddenly, at least for me.

> undeterministic abstraction

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.

[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

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.

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.