Ich höre den gleichen Satz in fast jedem Projekt, in das ich komme. „Wir haben ein Frontend-Team und ein Backend-Team.“ Niemand stellt das in Frage. So baut man heute Software.

Aber diese Trennung war nie eine technische Entscheidung. Sie war eine Personalentscheidung. Und mit KI-Agenten im Spiel fällt der Grund dahinter weg.

Der erste Teil dieser Argumentation gilt für jeden Stack. Der zweite Teil hängt davon ab, wie ihr euer UI rendert, und dort nehme ich das, was ich am besten kenne.

Woher die Trennung kommt

Ein gutes User Interface zu bauen und eine solide Persistenzschicht zu bauen brauchte früher unterschiedliche Fähigkeiten. Nur wenige Entwickler konnten beides. Also stellten die Firmen zwei Gruppen ein. Die eine Gruppe machte TypeScript, CSS und ein Komponenten-Framework. Die andere Gruppe machte Java, SQL und Transaktionen.

Den Rest erledigte Conway’s Law.

Zwei Teams können nicht lange an einer Codebasis arbeiten. Sie brauchen einen Vertrag. Also entsteht ein REST-API. Dann entsteht eine BFF-Schicht, weil das API nicht zum Screen passt. Dann habt ihr zwei Backlogs für ein Feature, zwei Definitions of Done, und ein Ticket, das drei Wochen lang hin und her wandert, weil niemand den ganzen Use Case besitzt.

Die Architektur folgte dem Organigramm. Das tut sie immer.

Was sich mit einem Agenten ändert

Ein Agent kümmert sich nicht um diese Trennung. Er schreibt die React-Komponente, den Endpoint dahinter, das Query und die Tests für beides in der gleichen Session. Er hat keine Vorliebe für Frontend oder Backend. Er arbeitet am Feature.

Damit fällt der fachliche Grund für die Trennung des Teams weg. Was bleibt, ist ein Feature-Team, das einen vertikalen Schnitt besitzt, vom Screen bis in die Datenbank. Genau diese Form wollt ihr für Self-Contained Systems. Ein Team, ein Use Case, eine deploybare Einheit.

Manche nennen das ein Reverse Conway Manoeuvre. Mit diesem Begriff wäre ich vorsichtig.

Es ist kein Reverse Conway Manoeuvre

Ein Reverse Conway Manoeuvre ist eine bewusste Management-Entscheidung. Ihr ändert die Teamstruktur absichtlich, damit die Architektur, die ihr wollt, zur natürlichen wird.

Das macht ein Agent nicht. Er ändert nicht, wer an wen rapportiert, wer welches Budget besitzt oder welcher Chapter Lead einen Pull Request freigibt. Er nimmt nur eine Einschränkung weg, die die Trennung notwendig erscheinen liess.

Wenn eure Firma weiterhin ein Frontend-Chapter und ein Backend-Chapter mit getrennten Vorgesetzten hat, bekommt ihr weiterhin ein Frontend und ein Backend. Der Agent produziert bereitwillig beide Seiten eines REST-APIs, das niemand gebraucht hätte.

Das Manoeuvre bleibt also eine Entscheidung, die jemand treffen muss. KI hat diese Entscheidung nur billiger gemacht.

Die eine Grenze, die bleibt

Der übliche Einwand an dieser Stelle ist Sicherheit. Client-Code ist öffentlich, Server-Code nicht. Diese Grenze ist real, sie hat nichts mit Personal zu tun, und kein Agent kann sie wegräumen. Ein Team kann beide Seiten besitzen, aber die zwei Seiten bleiben zwei Seiten. Ihr validiert zweimal. Ihr entwerft ein API, das davon ausgeht, dass der Aufrufer feindlich ist. Ihr haltet Regeln aus dem Bundle heraus.

Aber schaut, woher diese Grenze kommt. Sie ist kein Naturgesetz der Softwareentwicklung. Es gibt sie, weil ihr entschieden habt, Code in den Browser auszuliefern. Ändert diese Entscheidung, und die Grenze ändert sich mit.

Server-seitiges UI hatte dieses Problem nie

Server Side Rendering ist keine neue Idee und nicht an eine Sprache gebunden. HTMX, Hotwire, Blazor Server und Vaadin folgen alle dem gleichen Prinzip. Die UI-Logik bleibt auf dem Server, und der Browser bekommt ein gerendertes Resultat statt ein Programm.

Vaadin ist das, was ich täglich einsetze, also nehme ich es als Beispiel.

Mit Vaadin Flow bleibt die UI-Logik auf dem Server. Der Browser führt eine generische Engine aus, die den Komponentenbaum rendert, den man ihr vorgibt. Keine Geschäftsregeln verlassen die JVM. Keine Validierungslogik wird zweimal geschrieben. Es gibt keine öffentliche API-Oberfläche, die jemand mit curl und etwas Fantasie aufrufen kann. Vaadin weist zudem Requests für Komponenten ab, die nicht sichtbar oder nicht aktiviert sind. Der Server bleibt damit die einzige Quelle der Wahrheit.

Die Code-Grenze ist weg. Was bleibt, ist eine Daten-Grenze, und die ist deutlich kleiner:

  • Alles, was ihr in den Komponentenbaum steckt, geht über die Leitung. Eine versteckte Grid-Spalte überträgt ihre Daten trotzdem. Eine gebundene Entity mit einem Lohnfeld überträgt den Lohn trotzdem.
  • Wenn ihr eine eigene Client-Komponente schreibt oder eigenes JavaScript einbindet, ist dieser Teil wieder öffentlich.
  • Der Zugriff auf Views braucht weiterhin Regeln auf dem Server. @PermitAll und @RolesAllowed sind nicht optional, denn der Client kann jede Route anfragen, die er will.

Das ist eine Frage der Review-Gewohnheit. Es ist keine Architektur.

Was nicht verschwindet

Ich will das nicht als geschenkt verkaufen. Drei Dinge bleiben, egal mit welchem Werkzeug ihr arbeitet.

Review-Kapazität. Ein Agent erhöht, wie viel Code ihr produziert. Er erhöht nicht, wie viel Code ein Mensch verstehen kann. Wenn eine Entwicklerin beide Seiten eines Features besitzt, muss sie beide Seiten auch lesen und beurteilen können. Das ist die eigentliche Grenze, und das ist der Grund, warum ich Spezifikationen vor den Code stelle und nicht dahinter.

Design und Interaktion. Agenten schreiben gutes CSS. Sie entscheiden nicht, was ein Benutzer braucht, wie sich ein Ablauf anfühlen soll oder was Barrierefreiheit für eure Kunden bedeutet. Die Frontend-Spezialistin verschwindet nicht. Ihre Rolle verschiebt sich vom Schreiben von Komponenten zum Treffen von Entscheidungen.

Fachwissen. Niemand schreibt eine korrekte Rechnungsberechnung aus einem Prompt. Die kommt weiterhin von Leuten, die mit dem Business geredet haben.

Der Punkt

Die Behauptung lautet nicht „KI macht Full-Stack möglich“. Vaadin-Entwickler arbeiten seit fünfzehn Jahren Full-Stack, ganz ohne KI. Das Werkzeug hat den Grund für die Trennung längst beseitigt, bevor die Agenten auftauchten.

Die Behauptung lautet so: KI nimmt Teams, die tatsächlich Client-Code ausliefern, die letzte Ausrede. Und wer server-seitiges UI einsetzt, hat die Ausrede nie gebraucht.

Also hört auf, Frontend und Backend zu trennen. Trennt stattdessen nach Use Case. Gebt einem Team den ganzen Schnitt, vom Screen bis zum Schema. Dann folgt eure Architektur eurem Produkt und nicht eurer Einstellungsgeschichte.