AI Is Not Killing Frontend. You Are.

The AI coding discourse has it backwards. Everyone says AI is causing a new “lost decade” for frontend development — more framework churn, more abstraction fog, more cargo-culted complexity. The opposite is closer to true: AI is exposing the lost decade we were already living through.

The original “lost decade” argument, which surfaced again this week in a widely-shared post, is that the JavaScript ecosystem spent roughly 2012–2022 producing enormous quantities of tooling with questionable net output. Webpack, Babel, a dozen state management libraries, component systems built on component systems. The criticism is real. But the argument that AI is reprising this era conflates cause and effect. The tools proliferated because the underlying economics rewarded complexity. More frameworks meant more conference talks, more consulting contracts, more resume keywords, more hiring leverage. The incentive gradient ran straight toward indirection.

What AI vibe-coding actually does is make that complexity legible as waste. When a model can generate a working React component in four seconds, the question you can no longer avoid is: why did that used to take a sprint? The answer, uncomfortably, is that a lot of it didn’t need to exist in the first place. Not the work itself — the ritual around the work. The scaffolding. The architectural astronautics. The mandatory three-hour meeting to decide whether to use Zustand or Jotai.

Vicki Boykis wrote this week that “we should be more tired than the model” — meaning humans need to reclaim cognitive depth from an AI workflow that, if left unchecked, turns engineers into prompt jockeys who never read the output. She’s right. But the exhaustion question runs in two directions. Yes, you should be doing hard thinking that the model cannot do. The other implication is that if you’re equally tired after a day of model-babysitting as you were after a day of writing Webpack configs, something has gone wrong at the process level, not the AI level. Fatigue is not automatically a proxy for depth.

The “lost decade” framing also makes a structural error: it treats AI-generated complexity the same as human-generated complexity. They’re different failure modes. Human-generated complexity is sticky. It accretes because people have careers attached to it, teams organized around it, codebases where deleting the abstraction means owning the political fallout. AI-generated complexity is cheap to generate and — critically — cheap to throw away. A model that scaffolds a bad architecture for you costs you an afternoon, not a decade. The error bars are asymmetric. You can iterate out of an AI mistake faster than you can deprecate a beloved framework.

None of this is a defense of sloppy AI-assisted development. The risk Boykis identifies is real: engineers who outsource their judgment to the model eventually lose the judgment. The craft atrophies. You end up with production systems nobody fully understands, owned by developers who can describe the system’s outputs but not its internals. That’s a genuine catastrophe in slow motion, and it’s happening in some organizations right now.

But the solution isn’t to slow down AI adoption to preserve the frontend status quo. The status quo was already bad. The solution is to be deliberate about which cognitive tasks you delegate. Write the architecture yourself. Write the tests yourself. Let the model generate the boilerplate, then read the boilerplate — not to rubber-stamp it, but to confirm it matches your mental model. The discipline isn’t “use AI less.” It’s “use AI for the work that doesn’t compound, and save your attention for the work that does.”

The developers who will thrive in the next five years are not the ones who generate the most code the fastest. They’re the ones who can tell the difference between a component that works and a component that belongs. That judgment is human. For now, it can’t be prompted out of a model. Protect it like the scarce resource it is.

The stakes are real. If the frontend community defaults to AI-generated complexity as a replacement for human-generated complexity, we don’t get a cleaner decade — we get the same lost decade running at five times the speed. But if developers use the productivity surplus to go deeper on the things that matter — systems thinking, domain modeling, user experience that isn’t an afterthought — the next decade could be the most productive in software history.

You don’t get the latter outcome by accident. You get it by deciding, deliberately, to be more tired than the model.