I hear the same sentence in almost every project I join. “We have a frontend team and a backend team.” Nobody questions it. It is just how software is built today.
But this split was never a technical decision. It was a hiring decision. And with AI agents in the loop, the reason behind it is gone.
The first half of this argument works for any stack. The second half depends on how you render your UI, and there I will use what I know best.
Where the split came from
Building a good user interface and building a solid persistence layer used to need different skills. Few developers were good at both. So companies hired two groups. One group did TypeScript, CSS and a component framework. The other group did Java, SQL and transactions.
Then Conway’s law did the rest.
Two teams cannot share one codebase for long. They need a contract. So you get a REST API. Then you get a BFF layer, because the API does not fit the screen. Then you get two backlogs for one feature, two definitions of done, and a ticket that moves back and forth for three weeks because nobody owns the whole use case.
The architecture followed the org chart. It always does.
What changes with an agent
An agent does not care about this split. It writes the React component, the endpoint behind it, the query and the tests for both in the same session. It has no preference for the frontend or the backend. It works on the feature.
So the skill reason for splitting the team is gone. What is left is a feature team that owns a vertical slice from the screen down to the database. That is exactly the shape you want for self-contained systems. One team, one use case, one deployable unit.
Some people call this a reverse Conway manoeuvre. I would be careful with that term.
It is not a reverse Conway manoeuvre
A reverse Conway manoeuvre is a deliberate management decision. You change the team structure on purpose, so that the architecture you want becomes the natural one.
An agent does not do that. It does not change how people report, who owns which budget, or which chapter lead approves a pull request. It only removes one constraint that made the split look necessary.
If your company still has a frontend chapter and a backend chapter with separate managers, you will still get a frontend and a backend. The agent will happily produce both sides of a REST API that nobody needed.
So the manoeuvre is still a decision someone has to make. AI just made that decision cheaper.
The one boundary that is left
The usual objection at this point is security. Client code is public, server code is not. That boundary is real, it has nothing to do with staffing, and no agent can merge it away. One team can own both sides, but the two sides stay two sides. You validate twice. You design an API that assumes the caller is hostile. You keep rules out of the bundle.
But look at where that boundary comes from. It is not a law of software. It exists because you decided to ship code into the browser. Change that decision and the boundary changes with it.
Server-side UI never had this problem
Server-side rendering is not a new idea and it is not tied to one language. HTMX, Hotwire, Blazor Server and Vaadin all follow the same principle. The UI logic stays on the server, and the browser gets a rendered result instead of a program.
Vaadin is the one I use every day, so I take it as my example.
With Vaadin Flow, the UI logic stays on the server. The browser runs a generic engine that renders the component tree it is told to render. No business rules leave the JVM. No validation logic gets written twice. There is no public API surface that someone can call with curl and a bit of imagination. Vaadin also rejects requests for components that are not visible or not enabled, so the server stays the single source of truth.
The code boundary is gone. What is left is a data boundary, and it is much smaller:
- Everything you put into the component tree goes over the wire. A hidden Grid column still transfers its data. A bound entity with a salary field still transfers the salary.
- If you write your own client-side component or add custom JavaScript, that part is public again.
- View access still needs server-side rules.
@PermitAlland@RolesAllowedare not optional, because the client can ask for any route it wants.
That is a review habit. It is not an architecture.
What does not go away
I do not want to sell this as free. Three things stay, whatever tooling you use.
Review capacity. An agent increases how much code you produce. It does not increase how much code a human can understand. If one developer owns both sides of a feature, that developer still has to be able to read and judge both sides. This is the real limit, and it is the reason I keep specs in front of the code instead of behind it.
Design and interaction. Agents write CSS well. They do not decide what a user needs, how a workflow should feel, or what accessible means for your customers. The frontend specialist does not disappear. The role moves from writing components to making decisions.
Domain knowledge. Nobody writes a correct invoice calculation from a prompt. That still comes from people who talked to the business.
The point
The claim is not “AI makes full-stack possible”. Vaadin developers have been full-stack for fifteen years without any AI at all. The tooling removed the reason for the split long before agents showed up.
The claim is this: AI removes the last excuse for teams that do ship client code. And if you use server-side UI, you never needed the excuse in the first place.
So stop splitting frontend and backend. Split by use case instead. Give one team the whole slice, from the screen to the schema. Then your architecture follows your product, not your hiring history.
