3-Schichten-Architektur:So schreibt KI sauberen Code

KI erzeugt chaotischen Code, weil dein Projekt keine Architektur hat, nicht weil die KI schlecht ist. Eine 3-Schichten-Architektur löst das. Gib ihr drei klare Schichten — Komponenten für die UI, Services für die Geschäftslogik, eine Datenschicht für die Datenbank — und prompte eine Schicht nach der anderen, dann liefert dieselbe KI sauberen, testbaren, skalierbaren Code. So habe ich über 3M Zeilen gebaut.

Hier ist das Muster, warum es funktioniert, und die genaue Prompt-Abfolge.

Das Problem: KI ohne Struktur erzeugt Chaos

Du promptest die KI, ein Feature zu bauen. Sie liefert Code. Du fügst ihn ein. Eine Woche später ist deine Codebasis ein Durcheinander: Datenbankaufrufe überall verstreut, Geschäftslogik mit der UI vermischt, Copy-and-paste-Code an allen Ecken, nicht testbar, bricht, sobald du skalierst.

Die KI ist nicht das Problem. Deine Architektur ist es.

Die KI erzeugt, was du verlangst. Aber ohne klare Architektur vermischt sie Zuständigkeiten, schafft uneinheitliche Muster und kann die Struktur deiner Codebasis nicht aufrechterhalten — jeder Prompt erzeugt neues Chaos. Die KI kennt deine Architektur nicht. Du musst sie anleiten.

Die Lösung: eine 3-Schichten-Architektur

Stell dir deine App als Stapel aus drei Etagen vor. Komponenten oben — nur UI. Services in der Mitte — Geschäftslogik. Die Datenschicht unten — Datenbank und APIs. Jede Etage spricht immer nur mit der direkt darunter. Wenn die KI weiß, an welcher Schicht sie arbeitet, erzeugt sie sauberen Code.

• Schicht 1 — Komponenten (nur UI). Was hierher gehört: Darstellungslogik, Nutzerinteraktionen, Routing, Layout. Was nicht: Datenbankaufrufe, Geschäftslogik, Validierung, Berechtigungen. Eine schlechte Komponente holt Nutzer in sich selbst aus der Datenbank und filtert nebenbei nach Status. Eine gute Komponente fragt einen Hook nach „aktiven Nutzern“, zeigt beim Warten ein Lade-Skeleton und rendert die Liste. Das ist die gesamte Aufgabe.
• Schicht 2 — Services (Geschäftslogik). Was hierher gehört: Datenabruf, Validierung, Berechtigungen, Geschäftsregeln, Datentransformationen. Was nicht: alles, was rendert, oder komponentenspezifischer State. Ein UserService kennt die Regeln — eine Organisation ist Pflicht, welche Filter gelten, was bei einem Fehler passiert — und er ist der einzige Ort, an dem diese Regeln leben.
• Schicht 3 — Daten (Datenbank und APIs). Datenbankabfragen, API-Aufrufe, externe Integrationen. Zugriff nur über Services, nie direkt aus Komponenten.

So promptest du die KI mit diesem Muster

Der falsche Weg ist ein einziger Prompt: „Build a user management feature.“ Das Ergebnis ist alles in einer Komponente — Datenbankaufrufe, Validierung, UI, alles vermischt. Der richtige Weg sind drei Prompts, von unten nach oben, je eine Schicht:

1. Zuerst der Service: „Generate a UserService with methods to get, create, update, and delete users. Include validation and error handling.“
2. Dann der Hook: „Create a useUsers hook that wraps the UserService with caching.“
3. Zuletzt die Komponente: „Build a UserList component that uses the useUsers hook. Display loading states and handle errors.“

Ergebnis: sauberer, getrennter Code, jede Schicht konzentriert auf ihre Verantwortung. Alles auf einmal zu prompten ist der Fehler Nummer eins — die KI erzeugt vermischten Code, in dem alle Schichten verheddert sind. Eine Schicht nach der anderen, von unten nach oben bauen.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Funktioniert mit jedem Stack

Dasselbe Muster, andere Werkzeuge:

Schon chaotischer Code? Die Migration in 5 Schritten

1. Alle Datenbankaufrufe finden. Durchsuche deine Komponenten nach direkten Datenbank- und API-Aufrufen.
2. Services anlegen. Verlagere den gesamten Datenzugriff in Service-Klassen — die Abfrage, die in einer Komponente lebte, lebt jetzt in einer Service-Methode mit Fehlerbehandlung.
3. Hooks anlegen. Wickle jeden Service in die Datenabruf-Schicht deines Frameworks, damit Komponenten Caching und Ladezustände gratis bekommen.
4. Komponenten anpassen. Ersetze das Muster „Abruf in der Komponente“ durch einen einzigen Hook-Aufruf.
5. Die KI helfen lassen. Prompt: „Refactor this component to use the hook pattern. Move database logic to a service.“ Die KI migriert jedes Stück.

Der Gewinn zeigt sich sofort beim Testen: Services lassen sich ohne jede UI testen, Hooks als dünne Wrapper, und Komponenten mit gemocktem Hook. Saubere Schichten = einfaches Testen.

Warum das funktioniert

Ohne Schichten erzeugt die KI monolithische Komponenten, dupliziert Logik über Dateien und liefert Code, der schwer zu testen und zu warten ist und beim Skalieren bricht. Mit Schichten erzeugt die KI fokussierten Code für jede Schicht, die Logik ist in Services zentralisiert, jede Schicht lässt sich unabhängig testen — und es skaliert auf Millionen Zeilen.

Ich habe über 3M Zeilen Code auf diese Weise gebaut. Es funktioniert. Das ist genau die Architektur hinter FIKR Space: über 3M Zeilen, 964 Datenbanktabellen, 5 integrierte Produkte, mit Claude gebaut, im Produktivbetrieb. Die zwei Fehler, die du vermeiden musst: Services überspringen („Ich nutze einfach Hooks direkt mit der Datenbank“ — Geschäftslogik in Hooks ist schwer zu testen und unmöglich wiederzuverwenden) und fette Komponenten („Ich packe die Validierung in die Komponenten“ — du kannst sie ohne UI weder wiederverwenden noch testen).

Geh vor dem Launch die Checkliste durch: keine Datenbank-Imports in Komponenten, die gesamte Geschäftslogik in Services, Komponenten kümmern sich nur um UI, Hooks wickeln Services, Services ohne UI testbar, Fehlerbehandlung in allen Schichten. Dieses Muster ist Säule 2 der fünf Säulen produktionsreifer Software — und sobald die Schichten existieren, werden strukturierte Prompts wie die PRP-Methode dramatisch zuverlässiger, weil jeder Prompt ein offensichtliches Zuhause hat.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Häufig gestellte Fragen

Muss ich Code verstehen, um die 3-Schichten-Architektur zu nutzen?

Du musst die Karte verstehen, nicht die Straßen. Zu wissen, dass UI, Geschäftslogik und Datenzugriff drei getrennte Etagen sind — und dass jeder Prompt genau eine anpeilt —, genügt, um die KI richtig zu lenken. Die Architektur ist ein Kommunikationsmittel zwischen dir und der KI, und Lenken ist deine Hälfte der Arbeit.

Sind 3 Schichten für ein kleines MVP übertrieben?

Nein, denn die Kosten sind nahezu null und die Alternative potenziert sich. Drei Prompts statt einem am ersten Tag sind Minuten Mehraufwand; im sechsten Monat Datenbankaufrufe aus fünfzig Komponenten zu entwirren sind Wochen. Das Muster skaliert nach unten auf ein Wochenendprojekt und nach oben auf Millionen Zeilen — ich habe es an beiden Enden betrieben.

Was gehört in einen Service und was in einen Hook?

Regeln gehören in den Service; die Verkabelung gehört in den Hook. Wenn es eine Geschäftsentscheidung ist — was als gültig zählt, wer etwas darf, wie ein Wert berechnet wird —, gehört es in den Service. Wenn es darum geht, Daten auf den Bildschirm zu bringen — Caching, Lade-Flags, erneutes Abrufen —, gehört es in den Hook. Im Zweifel: in den Service — Services sind leichter zu testen und wiederzuverwenden.

Wie bringe ich die KI dazu, die Schichten automatisch zu respektieren?

Halte die Regel in deinen dauerhaften Projektanweisungen fest: Komponenten importieren nie den Datenbank-Client, jeder Datenzugriff läuft über Services, Hooks wickeln Services. Dann lass jeden Prompt seine Schicht benennen („create a service method for…“). Die KI folgt der Architektur, die tatsächlich aufgeschrieben ist — nie der in deinem Kopf.