Introduction
The transformation happening in software development today feels eerily familiar to those who lived through the frontend’s „lost decade.” As AI tools become increasingly capable of generating code, many developers experience a profound sense of loss — not just for their expertise, but for the craft itself. This article explores the parallels between what happened to frontend development and what’s happening now with AI-assisted programming, examining whether we’re witnessing deskilling, progress, or something more nuanced.
The Deskilling of Frontend Development
To understand the present, we must first understand the past. Frontend development was once a highly specialized skill requiring deep knowledge of:
- Semantic HTML and accessibility
- CSS and browser compatibility
- Progressive enhancement
- Network performance optimization
- Interface design principles
- User testing methodologies
Practitioners of this craft referred to themselves as „front of the frontend” developers to distinguish their work from what frontend development has become.
The Framework Revolution
The introduction of JavaScript frameworks fundamentally changed this landscape. Frameworks like React, Vue, and Angular treated the browser as a mere compilation target — just like any other app runtime (JVM, iOS, etc.). This abstraction had profound consequences:
- Reduced Barrier to Entry: Any general programmer could now work on the frontend
- Cost Savings: Companies could easily move developers between projects
- Reduced Bargaining Power: Specialized frontend knowledge became less valuable
- Quality Decline: The nuances of web development were abstracted away
The Wikipedia definition of deskilling captures this perfectly:
„Deskilling is the process by which skilled labor within an industry or economy is eliminated by the introduction of technologies operated by semi- or unskilled workers. This results in cost savings and reduces barriers to entry, weakening the bargaining power of workers.”
This is exactly what happened to frontend development. The „full-stack developer” became someone who knew enough JavaScript to wrangle a framework, not someone who deeply understood both frontend and backend systems.
AI is Deskilling Programming
What’s happening now with AI feels like a continuation and acceleration of this trend. The skilled job of writing code manually is being „eliminated by the introduction of technologies, operated by semi- or unskilled workers.”
The parallels are striking:
- Reduced Barrier to Entry: Anyone can now prompt an LLM to generate code
- Cost Savings: Companies can reduce headcount and still maintain productivity
- Reduced Bargaining Power: Deep technical knowledge becomes less valuable
- Quality Concerns: The details that matter are abstracted away
However, the outcome is uncertain. We don’t yet know:
- What skillset workers wrangling agentic AI will need
- At what price point this labor will stabilize
- Whether local or remote LLMs will dominate
- How the market will value different types of expertise
A Profound Sense of Loss
Just as artisans and craftspeople were replaced by assembly line workers over a century ago, developers today grieve the loss of a skill they spent years honing. This grief is real and valid, even if the broader trajectory of technology is positive.
The question isn’t whether AI will make some things easier — it clearly will. The question is: at what cost to those who built their careers on deep technical expertise?
Operating at a Higher Level of Abstraction
There’s an alternative framing of this phenomenon: rather than deskilling, we’re simply operating at a higher level of abstraction. Engineers have always automated things — that’s part of the job. New technologies that let us focus on bigger pictures without worrying about implementation details are generally positive.
But this framing has a critical flaw: exactly which details are deemed „unimportant” is a very consequential and sometimes subjective decision.
The Tower of Leaky Abstractions
Joel Spolsky’s „Law of Leaky Abstractions” states that all non-trivial abstractions leak. Modern frontend development is a perfect example:
- By using heavy client-side JavaScript frameworks like React, developers abstract over accessibility
- They abstract over performance on lower-end phones and slow networks
- They abstract over the complexity of managing state across distributed systems
- In effect, they choose not to think about these things
The result? Websites that are slower, less accessible, and more fragile than they need to be.
Agentic Coding: An Undeterministic Abstraction
Agentic AI introduces a new problem: it’s an undeterministic abstraction. Unlike a compiler, which produces deterministic output, AI can produce different results based on:
- Slight variations in prompts
- Model updates
- Temperature settings
- Context window variations
This is more like working with junior engineers — unpredictable, requiring oversight, and sometimes producing surprising results. The difference is that junior engineers can learn and improve, while LLMs require endless tweaking of prompts and configuration files.
LLMs as an Extension of Stack Overflow Culture
The best analogy for using LLMs is how Google search used to work. It was a skill to choose the right keywords to surface the right Stack Overflow post. Prompting an LLM is similar — it’s a fuzzy lookup in a very high-dimensional space, sensitive to wording variations.
In recent years, Google normalized search terms more aggressively, making it easier for non-experts but less powerful for those who had mastered „Google-fu.” Similarly, LLMs are making it easier for beginners while potentially reducing the value of deep expertise.
The Copy-Paste Culture
The advent of Stack Overflow irreversibly changed programming. Instead of reading documentation, programmers could blindly copy and paste answers. Surprisingly often, something kind of worked.
LLMs are a continuation of this trend:
- Tools that make people who know what they’re doing slightly faster
- Tools that enable people who don’t know what they’re doing to arrive at something that often kind of works
This is genuinely great! But we shouldn’t fool ourselves: at some point the abstraction will leak. Someone has to invest the time to actually understand what’s going on and fix it.
Just as we taught junior programmers to read and understand Stack Overflow answers before using them, we need to teach people to read and understand LLM output and how it fits into their codebase.
Does Quality Matter?
Unfortunately, some programmers never progressed to the stage of understanding Stack Overflow answers. Why bother if it works? And while not publicly acknowledged, many companies were actually happy with this approach.
What’s different now is that companies go out of their way to publicly proclaim how much AI they’re using, without even pretending to look at the output.
The Business Reality
While there are valid use cases for LLMs, there are also many new ways to mess up code, communication, and organizational processes. This is especially challenging to figure out as a team.
The uncomfortable truth is that business success and software quality are rarely correlated. Other factors dominate:
- Brand loyalty
- Pricing
- Marketing
- Network effects
- First-mover advantage
A slow website with poor accessibility might hurt conversion, but that effect is small compared to other factors. And if all competitors have slow websites, there’s no competitive disadvantage.
As for frontend development: a terrible website has a relatively small impact on the bottom line. Does a slow website hurt conversion? Sure, but that effect is small. Does everyone have slow websites? Yes. Nobody was ever fired for choosing React.
The Bauhaus Movement: A Historical Parallel
When everyday goods and buildings suddenly could be mass-produced by industrial processes, craftspeople faced a choice. One reaction was to copy the style of old work and make industry crank out widgets that at least looked handcrafted (historicism).
A better approach was developed by the Bauhaus movement of the early 20th century. Instead of pitting factory workers against craftspeople, their goal was to have them work together and redevelop arts and crafts with industrial manufacturing in mind.
The Bauhaus urged designers to go back into workshops and work with materials themselves, with the goal of arriving at designs that would then be mass-produced. But always keeping the end user in mind and deeply caring about them.
Modern industrial design, exemplified by Dieter Rams and Jonathan Ive, traces its roots directly back to the Bauhaus.
Caring About Quality and the User
How can we translate this thinking to software?
Software sits somewhere between craft and industrial design:
- Like craft: the program we write gets shipped „as is” to users without a manufacturing step
- Like industrial design: we ship the same thing to potentially thousands of users we never see
The need for being able to write code by hand is clear. Just as industrial designers need to know the materials their products will be made of, web developers need to be intimately familiar with HTML and CSS.
While tools like Google, Stack Overflow, ready-to-use libraries, and now LLMs make things easier for beginners, this also means the natural barrier to entry is continuously lowered.
The Quality Paradox
When there’s a high barrier to entry, it’s difficult to find absolutely terrible work. Once a craftsman was taught how to build a wooden chair, they invariably were also taught how to not do a terrible job.
Industrialization enabled cheap plastic products designed by people who didn’t think about how they’d be used. Yet good industrial design still exists.
The invention of the word processor enabled terribly formatted documents. Yet typography and graphic design still exist.
Software like Wix and Next.js enabled websites that load terribly slow and aren’t accessible. Yet practitioners of the „front of the frontend” still exist.
Likewise, AI is enabling AI slop. But this doesn’t mean we don’t still need people who know what they’re doing and care about what they’re doing.
How Will It Shake Out?
Like in other industries, doing things properly will become an ever smaller slice of the pie. But because it’s now easier and cheaper to do so, the size of the pie will continue to grow.
It’s very hard to say whether the absolute number of people paid to do things well will increase or decrease. There are way too many poorly designed plastic products out there. Designing typefaces is no longer a sustainable full-time job for most people. But there’s still so much great work being done in all those domains.
When to Use AI, When to Do It Right
Sometimes churning out a quick prototype or MVP is the right thing to do. If you don’t have product-market-fit yet, quick iteration and learning is more important than future-proofing everything.
But you need to know what you’re trying to learn and how you validate those learnings. And when the time has come, it’s usually better to take a step back and do things right from the start.
For example:
- Good performance is very hard to achieve in a badly architected frontend later
- It’s easier to start with a simple stack and add functionality than the reverse
- Technical debt compounds over time
For any part of your system, you need to know what tradeoffs you’re making, then decide whether to:
- Buy a service
- Use an open source library
- Have an LLM churn it out
- Write it yourself
When the hype dies down, the industry will realize AI is just one more tool in the toolbox. Until then, we’re going to see a lot of ugly things: ugly code, broken communications, and awful layoffs under the guise of AI.
Conclusion
The parallels between what happened to frontend development and what’s happening now with AI are striking. Both represent a shift from craft to industrialization, from specialized expertise to generalist tooling.
But this isn’t necessarily bad. The Bauhaus showed us that industrialization and craft don’t have to be enemies. They can work together, with craftspeople using industrial tools to create better things.
The question isn’t whether AI will change software development — it clearly will. The question is whether we’ll use it as an excuse to abandon quality and care, or whether we’ll use it as a tool to amplify the work of people who know what they’re doing.
The answer depends on us. On whether we continue to value deep expertise, on whether we continue to care about users, and on whether we continue to invest in understanding the systems we build.
The frontend’s lost decade wasn’t inevitable. It was a choice — a choice to prioritize speed and cost over quality. We can make a different choice with AI. But only if we’re intentional about it.
The tools are neutral. The outcomes depend on how we choose to use them.
In case you have found a mistake in the text, please send a message to the author by selecting the mistake and pressing Ctrl-Enter.
Nuoroda į informacijos šaltinį
