Du bist der Architekt, die KI ist der Baumeister
Du bist der Architekt, die KI ist der Baumeister. Die Aufteilung der Entscheidungen – welche deine sind, welche die der KI – und fünf Momente zum Widerspruch.
Du bist der Architekt, die KI ist der Baumeister – wenn du mit KI baust. Dir gehört jede Entscheidung, die später teuer zu ändern ist – welche Daten existieren, wie sie zusammenhängen, wer was sehen darf, welche Qualität ausgeliefert wird. Die KI setzt diese Entscheidungen in Code um. Verwischst du diese Linie, bricht dein Produkt irgendwann zusammen.
Das ist das mentale Modell, das entscheidet, ob KI-Coding-Tools dich gefährlich oder frei machen. Nicht „die KI ist der Entwickler und ich bin der Product Manager“. Nicht „wir programmieren gemeinsam als Partner“. Du entwirfst. Die KI baut. Ich habe diese Arbeitsteilung auf die teure Tour gelernt – die Vorgeschichte, einschließlich der Drei-Monats-Klippe, an der KI-gebaute Produkte still sterben, steht in der Vibe-Coding-Falle. Dieser Beitrag ist die praktische Hälfte: welche Entscheidungen genau deine sind, welche die der KI, und die Momente, in denen du dich wehren musst.
Was bedeutet „du bist der Architekt“ eigentlich?
Denk an den Hausbau. Der Architekt trifft die Entscheidungen, die die gesamte Struktur betreffen: wo das Haus auf dem Grundstück steht, wie viele Stockwerke, welches Fundament, wo die tragenden Wände verlaufen, wie Wasser und Strom geführt werden. Diese Entscheidungen lassen sich nach Baubeginn kaum noch ändern. Der Baumeister setzt diese Vision um – gießt das Fundament genau nach Vorgabe, zieht die Wände nach Plan hoch. Der Baumeister ist unglaublich geschickt. Aber er führt einen Plan aus; er erschafft ihn nicht.
Sag nun einem Baumeister „bau mir ein Haus“, ohne Baupläne. Du bekommst etwas. Es steht vielleicht sogar und sieht anfangs gut aus. Aber das Fundament trägt das zweite Stockwerk nicht, das du später willst, und die Leitungen liegen am falschen Ort für deine Küche. Du bekommst eine Struktur, die funktioniert, bis du von ihr etwas verlangst, wofür sie nicht entworfen wurde. Das ist, in einem Satz, die meiste KI-gebaute Software.
Die Entscheidungsmatrix: Welche Entscheidungen sind deine, welche die der KI
Hier die Arbeitsteilung, konkret gemacht. Alles links gehört dir. Alles rechts wird delegiert:
| Bereich | Du entscheidest (Architekt) | Die KI führt aus (Baumeister) |
|---|---|---|
| Daten | Welche Dinge in deinem System existieren, wie sie zusammenhängen, die einzige Wahrheitsquelle für jede Tatsache | Den Code, der genau deine Struktur umsetzt |
| Sicherheit | Wer was sehen darf, wie der Zugriff kontrolliert wird, was protokolliert wird | Die Regeln und Prüfungen, die dein Modell durchsetzen |
| Skalierung | Was Millionen von Nutzern bewältigen muss, wo die Engpässe sein werden | Optimierungen, die du geprüft und freigegeben hast |
| Muster | Benennung, Dateistruktur, Fehlerbehandlung – jedes Mal auf dieselbe Weise | Code, der diesen Mustern überall folgt |
| Produkt | Welche Funktionen existieren, welche Regeln gelten, was nicht zum Umfang gehört | Die Implementierungsdetails |
| Qualität | Was akzeptabel ist, was neu gemacht werden muss, wann ausgeliefert wird | Vorschläge – die du annimmst oder ablehnst |
Beachte, was in der Spalte der KI fehlt: eine einzige Entscheidung. Die KI schlägt vor; du verfügst. Und die wirkungsvollste Architektenentscheidung überhaupt ist, deine Daten vor deinen Bildschirmen zu entwerfen – diese Methode hat einen eigenen Beitrag: Database-First-Entwicklung.
Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →Die drei Hüte jedes Solo-Architekten
Hut eins: Systemarchitekt. Du entscheidest über die Form der Daten. Welche Entitäten existieren, wie sie verbunden sind, ob jeder Datensatz dem Kunden zugeordnet ist, dem er gehört, welche Historie aufbewahrt wird. Das sind Geschäftsfragen in technischer Verkleidung – und du kennst dein Business besser als jede KI.
Hut zwei: Product Manager. Du entscheidest, was gebaut wird und, wichtiger, was nicht. Fundamente vor Features. Keine Nice-to-haves in Version eins. Die Prioritäten sind deine: Login vor Analytics, Analytics vor allem Fortgeschrittenen. Die KI baut bereitwillig alles, was du verlangst, in beliebiger Reihenfolge – genau deshalb muss die Reihenfolge von dir kommen.
Hut drei: Qualitätssicherung. Du entscheidest, ob die Arbeit gut genug ist. Folgt sie deinen Mustern? Ist sie sicher? Übersteht sie echte Kunden? Du bist derjenige, der sagt „das schafft Schulden, mach es neu“ – und derjenige, der sagt „das ist produktionsreif, liefere es aus“.
Fünf Momente, in denen die KI dich testet – wehr dich
Die KI schlägt Dinge vor, die klug klingen und deine Architektur verletzen. Fünf Signale sollten einen automatischen Stopp auslösen:
- „Der Einfachheit halber …“ – Übersetzung: „Lass mich technische Schulden erzeugen.“ Einfachheit jetzt ist Komplexität später. Bestehe auf der richtigen Struktur.
- „Für die Performance …“ – verlange Belege. Gibt es kein gemessenes Problem, gibt es nichts zu optimieren. Vorzeitige Optimierung ist, wie saubere Systeme verrotten.
- „Quick Fix …“ – Hacks werden dauerhaft. Sag Nein und frag stattdessen nach der Ursache.
- Optionslisten fest in den Code einbauen. Status, Kategorien, Typen – die KI liebt es, sie fest zu codieren. Halte sie als bearbeitbare Daten, damit du Optionen hinzufügen oder umbenennen kannst, ohne den Code anzufassen.
- Zusammengehörige Datensätze in ein einziges Blob-Feld stopfen. Wenn Daten zusammengehören, brauchen sie eine echte Beziehung – damit sie durchsucht, verbunden und geprüft werden können. Ein Blob kann nichts davon.
Jedes dieser Dinge kam beim Bau von FIKR Space vor, einer Plattform, die auf 964 Datenbanktabellen gewachsen ist. Die KI wollte fest codierte Statuslisten; ich zwang sie, als bearbeitbare Daten zu leben. Die KI wollte Werte „für die Performance“ duplizieren; ich bestand auf einer einzigen Wahrheitsquelle, mit über 90 % vollständig normalisierter Tabellen und jeder dokumentierten Ausnahme. Dagegenhalten war kein gelegentliches Ereignis. Es war der Job.
Wie Architekten mit der KI sprechen
Vergleiche zwei Prompts. Der Vibe-Coder schreibt: „Bau eine Nutzerprofilseite.“ Die KI muss nun raten, welche Daten sie zeigen soll, woher sie kommen, was bearbeitbar ist und welchem Muster sie folgen soll. Sie wird jedes Mal anders raten, und dein Produkt wird ein Flickenteppich aus Vermutungen.
Der Architekt schreibt den Bauplan: welche Datenquellen die Seite speisen, welche Abschnitte erscheinen, was genau der Nutzer bearbeiten kann, welche Berechtigung das erfordert, welche bestehenden Komponenten wiederverwendet werden und wie Laden und Fehler sich verhalten. Dasselbe Feature. Aber nun weiß die KI genau, was und wie sie bauen soll – und das Ergebnis passt zu allem anderen, was du gebaut hast. Der Prompt liest sich wie ein Bauplan, weil er einer ist.
Die drei Ebenen architektonischen Denkens
Ebene eins – Feature-Ebene: „Ich brauche ein Dashboard, also baue ich ein Dashboard.“ Ein Feature nach dem anderen, ohne Gedanken daran, wie Features zusammenhängen. Das ist der Vibe-Coder.
Ebene zwei – Produkt-Ebene: „Ich baue ein Produkt mit Nutzern, Teams und Projekten – wie hängen diese zusammen?“ Besser. Beziehungen werden entworfen. Aber Skalierung und Sicherheit sind noch Nachgedanken.
Ebene drei – System-Ebene: „Ich baue etwas, das die Daten jedes Kunden isolieren, Audit-Trails führen, Wachstum überstehen und neue Features ohne Umbau aufnehmen muss.“ Skalierung, Sicherheit und Konsistenz werden am ersten Tag entschieden.
Auf Ebene drei musst du arbeiten – und dafür brauchst du keinen Informatikabschluss. Du musst in Systemen denken, und genau das tun erfahrene Konzernprofis jeden Tag. Deine Jahre, in denen du Systeme großer Unternehmen gelingen und scheitern sahst, sind die Qualifikation.
12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →Häufig gestellte Fragen
Welche Entscheidungen sollte ich nie an die KI delegieren?
Alles, was später teuer zu ändern ist: wie deine Daten strukturiert und verknüpft sind, wer worauf zugreifen darf, die Muster, denen alles folgt, was in welcher Reihenfolge gebaut wird und die Qualitätslatte fürs Ausliefern. Die KI setzt diese Entscheidungen brillant um. Sie sollte sie nie treffen.
Muss ich technisch sein, um als Architekt zu fungieren?
Nein. Architekturentscheidungen sind verkleidete Geschäftsentscheidungen: welche Dinge in deinem System existieren, wie sie zusammenhängen, welche Regeln gelten, wer was sieht. Du beschreibst sie in einfacher Sprache; die KI übersetzt sie in Code. Fachwissen zählt weit mehr als Programmierfähigkeit.
Was passiert, wenn ich die KI die Architekturentscheidungen treffen lasse?
Es funktioniert – zuerst. Dann driften die Muster, dieselbe Tatsache lebt an drei Orten und widerspricht sich selbst, Kundendaten sind nicht sauber isoliert, und jedes neue Feature wird schwerer hinzuzufügen. Irgendwann baust du neu. Die Entscheidungen des Architekten sind genau die, die die KI wegoptimiert.
Wie wehre ich mich gegen einen Vorschlag der KI?
Sei konkret, nicht vage. Benenne, was falsch ist, erkläre, warum, sage genau, was du stattdessen willst, und lass es dir umgesetzt zeigen. „Das ist falsch, behebe es“ lehrt die KI nichts; eine präzise Korrektur bringt dir Produktionsqualität in einem Durchgang.
Wie gefangen bist du wirklich?
Mach den Corporate Suffocation Index – die kostenlose Einschätzung, ob du bereit bist, Solopreneur zu werden.