Removing Next.js Taught Me Why Frameworks Are Still Essential Even for AI

"Do we even need frameworks anymore?"

I stopped in my tracks while browsing a Hacker News thread.

"Coding agents have replaced every framework I used"

The comment section was buzzing. "React isn't even necessary when I leave it to Claude Code," "Plain HTML and Vanilla JS are enough," "Frameworks exist to compensate for human cognitive limits, but AI doesn't have those limits"—.

Honestly, I totally get it.

Recently, while working on personal projects with Claude Code, there are moments when I think about Next.js directory structures or App Router conventions and wonder, "Who am I even following these for?" If agents can write everything, aren't framework "practices" just overhead?—

Introduction

To jump straight to the conclusion: after actually stripping away Next.js and rewriting in plain HTML, I reached the exact opposite conclusion—that "frameworks are necessary precisely because we are in the era of agents."

This is a record of that experiment, and perhaps a story I want to share with those currently wavering on the "no-framework" theory.

Stripping away Next.js—The beginning of the problem

The trigger was simple. While considering a replacement for an internal tool (a dashboard system) I manage personally, it occurred to me.

"If I have Claude Code, isn't plain HTML + Vanilla JS enough?"

I decided to experimentally "de-framework" an existing project built with Next.js.

Here’s what I did:

• next/router → Calling the History API directly
• next/image → <img> + lazy loading attribute
• getServerSideProps → Custom API with Express + fetch
• File-based routing → Custom routing table
• CSS Modules → Plain CSS (BEM notation)

I proceeded while providing context to Claude Code. "Convert this Next.js page into HTML/JS/CSS without a framework," I said.

The agent converted it smoothly. It certainly worked. It worked, but—.

The first anomaly occurred on the third day.

When I tried to add routing, the location where the routing was defined differed between the code generated by Claude Code and the code I had written the day before. I had consolidated it in routes.js. The agent had written it inline within the script tags of each HTML file.

"Well, I can fix it if I give instructions," I thought, and requested a correction. It was fixed.

But the next day, the same thing happened in a different place. This time, the location of the API client was scattered. I had intended to centralize it in utils/api.js, but in the new page, fetch was being called directly.

That's when I started to realize.

The moment the framework disappeared, the rules for "where to put the code" vanished.

Public Reaction—The "Anti-Framework" vs. "Pro-Framework" Camps

On this topic, there are two major factions on the internet.

The "Anti-Framework" camp argues like this:

"In an era where AI writes code, the learning cost of a framework is a waste. Plain HTML/CSS/JS is enough. If you leave it to an agent, you can generate boilerplate in an instant."

In the aforementioned Hacker News thread, this was the mainstream opinion. Indeed, looking at demos of Devin or Claude Code, the footage of them quickly creating prototypes with minimal code without being bound by framework conventions is persuasive.

On the other hand, the "Pro-Framework" camp counters like this:

"Frameworks prevent 'reinventing the wheel.' Don't underestimate the cost of ensuring security, performance optimization, and accessibility yourself."

On Zenn, articles like "I tried doing everything Next.js used to do for me by myself" have gone viral, and real voices saying "It was hard after stripping it away" are gaining sympathy.

I think both are valid points.

However, frankly, both were slightly off from my actual experience.

The anti-framework claim that "It's fine because AI writes it" is true if you only write it once. But the story was different in the operational phase. The pro-framework claim of "reinventing the wheel" is also true, but that wasn't the essence of it.

The problem I felt was somewhere else entirely.

The Third Way—Frameworks Were "Instructions for AI"

After operating with plain HTML/JS for about two weeks, the hardest part wasn't "reinventing the wheel."

It was the accumulation of "perceptual gaps" with the agent.

For example, in Next.js App Router, there's a rule: "Create a folder under the app/ directory and place page.tsx there." To humans, this looks like a "convention you have to memorize."

But for the agent, it's different.

This is a clear set of instructions on "where to put what file and with what name when creating a new page."

In plain HTML/JS, these instructions don't exist. Therefore, the agent makes its own judgment on file placement every time. That deviates from my judgment. As the context grows, the frequency of these deviations increases.

Specifically, let's compare.

When Next.js is present:

app/
  dashboard/
    page.tsx        ← Page goes here
    loading.tsx     ← Loading UI goes here
    error.tsx       ← Error handling goes here
  api/
    users/
      route.ts      ← API endpoint goes here

If you tell the agent to "Add a user list page," it creates app/users/page.tsx. There is no room for hesitation.

In the case of plain HTML/JS:

Where to put what?
  pages/users.html?
  views/user-list.html?
  public/users/index.html?
  Add routing to routes.js? Or write directly in app.js?
  API client in utils/? Or in services/?

This happens every time. Even if you write conventions in .cursorrules or CLAUDE.md, project-specific rules don't have as much "enforcement power" as framework conventions. The agent refers to them, but doesn't follow them 100% of the time.

At this point, I realized.

I thought framework conventions were things to "help human cognition." But that was only half right.

Framework conventions were a "common language for everyone involved in the project—both humans and AI—to operate under the same rules."

Realization—The Value of Frameworks has "Inverted"

Through this experiment, my perception of the value of frameworks has changed.

In the era when development was done only by humans, the value of frameworks mainly consisted of three things:

1. Preventing the reinvention of the wheel (routing, state management, etc.)
2. Enforcing best practices (security, performance)
3. Unifying conventions in team development

Entering the agent era, the value of 1 and 2 is indeed thinning. Claude Code can write routing and state management from scratch, and it knows security best practices (likely better than the average human).

However, the value of the third—"unifying conventions"—is actually skyrocketing.

This is because development teams in the agent era are hybrid teams of "human + AI."

Between humans, we can infer from implicit understandings, thinking, "Oh, so this project is structured like this." But AI agents cannot follow rules that are not explicitly stated. Framework conventions function as the "explicitization of implicit knowledge" for the AI.

When I resumed development after switching back to Next.js, the experience changed significantly.

"Create app/settings/page.tsx and fetch/display user settings in a Server Component."

With just this, the agent generates code in the correct location, in the correct format, and consistent with other pages in the project. Thanks to the framework acting as a "constraint," the variability in the agent's output has decreased dramatically.

For example, consider form processing using Next.js Server Actions:

// app/settings/actions.ts
"use server"

export async function updateSettings(formData: FormData) {
  const name = formData.get("name") as string
  // Validation, DB update...
  revalidatePath("/settings")
}

// app/settings/page.tsx
import { updateSettings } from "./actions"

export default function SettingsPage() {
  return (
    <form action={updateSettings}>
      <input name="name" />
      <button type="submit">Save</button>
    </form>
  )
}

Just having rules like "Write Server Actions in actions.ts" and "Page components are in page.tsx" stabilizes the agent's output. The fact that framework conventions are acting as a substitute for prompt engineering—this was my biggest discovery.

Conclusion—Frameworks Are Not Dead; Their Roles Are Changing

"Coding agents will kill frameworks"—my answer to this proposition is as follows.

Frameworks will not die. However, their raison d'être will change.

From "providing convenient tools for humans" to "a common protocol for human-AI collaboration."

Routing implementations can probably be left to agents. AI will likely soon generate optimal code for image optimization logic as well.

However, "place pages here," "define APIs like this," "use this pattern for state management"—these "design constraints" are necessary whether team members are human or AI. In fact, with the addition of AI—a member prone to "forgetting context"—the value of explicit rules has only increased.

So, if you currently feel that "frameworks are unnecessary because we have agents," I want you to give it a try. Try developing with an agent using plain HTML for two weeks.

I think you'll arrive at the same conclusion as I did.

Frameworks weren't "training wheels for humans." They were a "common language for the entire team." And now that AI has joined the team, the importance of a common language will only grow, never diminish.

—By stripping away Next.js, I understood its true value. It's ironic, but I think this is the kind of insight you can only see by actually getting your hands dirty.

References

• Coding agents have replaced every framework I used - Hacker News
• Next.js App Router Documentation
• GitHub Trending