CODE IN TOKYO

Is Frontend/Backend "Separation" Already Outdated? The Paradox of "Re-integration" in the AI Era

Working with React and Next.js lately, I sometimes catch myself thinking:

Back when we built everything together in PHP or Rails, wasn’t development actually more natural?

To be clear, I have no desire to go back. I’m not romanticizing jQuery hell or tangled PHP.

But since I started building seriously with AI, my faith in “cleanly separating frontend and backend” has wobbled a little. Not collapsed — wobbled.

And this isn’t a “separation is dead” piece. The honest answer changes with context.

When “separation” was justice

There was a time backends emitted HTML directly.

PHP, JSP, Rails, ASP.NET — all in one repo, touching DB, templates, and server logic together. By today’s standards, very tightly coupled.

Then came the SPA era.

React and Vue rose, and the frontend ballooned.

UIs got richer. State management, component design, async I/O, SSR, CSR — browser-side responsibility exploded.

The result: a “modern” split.

Talking over APIs.

This had genuine rationale: at scale, specialization is more efficient. Independent deployment, separate team ownership, clearer contracts.

But AI is shaking that, at least at small-to-mid scale

Using Claude Code and similar AI agents, I keep noticing something.

AI tends to struggle in “separated worlds.”

Fixing a login feature used to mean:

Tedious for humans. And when you hand it to AI, the context fragments. Different repo, different language, and the model loses the thread.

“It fixed one side and forgot the other” is common.

That said, I do not want this to be misunderstood.

This does not mean “separated architecture is bad now.”

Even if frontend and backend are separated, AI can follow the flow reasonably well if they live close together in the same codebase, types are generated from OpenAPI, and updates and tests can be run with a single command.

The problem is not separation itself.

The problem is that the path of change gets broken halfway through, both for humans and for AI.

If tooling reconnects those gaps, the friction gets much smaller.

So the inconvenience I am describing here is not proof that separated architecture is wrong. It is a developer experience problem that can still be improved.

AI also shines when “everything is visible at once”

AI tends to do best with:

So today’s Next.js App Router gets interesting. Looking at Server Actions and RSC (React Server Components) as used in App Router, it does look like the frontend is moving back toward the server.

Remix points in a similar direction, in the sense that screen logic and server-side handling live close together.

Rather than “strictly separating the API,” you write the flow as one thing.

Technically, this is nothing like old PHP. For example, RSC is not just a mechanism for assembling HTML; it is a framework-managed system that decides which parts run on the server and where the handoff to the browser begins. But philosophically, there’s a small rhyme.

Still, the case for separation is strong

Let me be fair here. Not keeping separation isn’t nostalgia or inertia. There are concrete reasons:

So I don’t expect the old “everything-in-one monolith” to fully return.

For small-to-mid projects with one team and one client, “TypeScript everywhere, AI walks through end-to-end” can be remarkably fast.

But once you’re at real scale, the separation costs you said yes to weren’t arbitrary. They were paying for something.

Probably we’re mid-swing

History tends to oscillate.

Over-separate. ↓ Operational cost rises. ↓ Want to re-integrate. ↓ Re-integrate too far, it breaks. ↓ Separate again.

AI is shifting the equilibrium, not flipping it.

The old axis was “what’s easy for humans to divide work on.” A new axis is creeping in: “what’s easy for AI to reason across.”

A new axis appearing doesn’t make the old one disappear. Both apply at the same time.

Finally

Honestly, I still do not know whether frontend/backend “re-integration” will really become mainstream.

In a few years, a completely different architecture may be in vogue again.

One possible future is that AI simply gets much smarter, and understanding both frontend and backend becomes the default.

But at the very least, I feel that this premise is starting to loosen:

“Separation is modern, therefore correct.”

When using AI, I have definitely seen more situations where “everything is connected and visible” feels easier.

On the other hand, for systems with multiple clients including mobile, multiple teams, or strong security boundaries, separation still pays for itself.

Twenty years ago, when we wrote everything in PHP:

HTML inside PHP, and JavaScript that called jQuery inside that HTML. Honestly, that world was chaos.

I have no desire to go back there.

But when I look at Server Actions and RSC in Next.js today, even though the shape is different, I feel that the good part of that old sensation is returning in a different grammar:

“I can write the whole flow as one thing.”

Leave the chaos behind, carry back only the flow. That’s probably what this swing actually is.