Die KI-Design-Autorität
Wir stehen an einem Wendepunkt in der Softwareentwicklung. Die Diskussion dreht sich oft darum, welche ob KI den besten Code schreibt (Claude vs. ChatGPT) oder wo wo diese KI leben soll (IDE oder CLI). Aber das ist die falsche Diskussion.
Das eigentliche Problem ist nicht die Generierung des Codes. Das eigentliche Problem ist die Validierung davon.
Wenn wir KI als „Vibe Coder“ annehmen – wobei wir die Absicht vorgeben und die KI die Ausführung übernimmt –, erzeugen wir einen enormen Strom neuer Software. Ein Schwarm von KI-Agenten kann in einer Minute mehr Code generieren, als ein Senior-Entwickler in einer Woche überprüfen kann. Der Mensch ist zum Engpass geworden.
Die Lösung ist nicht mehr der Mensch. Die Lösung ist eine KI-Design-Autorität.
Vom Handwerker zum Fabrikdirektor
Traditionell ist die „Design Authority“ eine kleine Gruppe von Architekten, die sich einmal pro Woche oder Monat trifft, um einen Entwurf zu genehmigen oder abzulehnen. In einer Welt von High-Velocity AI-Entwicklung ist dieses Modell hoffnungslos veraltet. Es ist zu langsam und zu reaktiv.
Wenn wir auf „Disposable Code“ umsteigen – Software, die wir nicht endlos refaktorisieren, sondern wegwerfen und neu generieren, wenn sich die Anforderungen ändern –, dann ändert sich unsere Rolle grundlegend. Wir sind keine Maurer mehr, die Stein für Stein setzen. Wir sind die Architekten der Fabrik, die die Wände druckt.
Aber wer kontrolliert, ob diese Mauern gerade stehen?
Der „Gauntlet“: Ein automatisierter Härtetest
Eine AI Design Authority ist keine Person, sondern eine Pipeline. Ein „Gauntlet“, das jede Zeile generierten Codes durchlaufen muss, um in die Produktion zu gelangen. Dieser Prozess ersetzt die menschliche Code-Überprüfung nicht durch Nichts, sondern durch etwas Besseres.
Es funktioniert in drei Schichten:
1. Die Exekutive (Die Generierung)
Wir fragen nicht eine einzige KI nach einer Lösung, wir fragen drei. Wir lassen Gemini 3, GPT-5 und ein Open-Source-Modell (wie Llama) parallel an demselben Problem arbeiten. Dies verhindert eine Tunnelblick-Mentalität und durchbricht die „Trägheit“, unter der LLMs manchmal leiden. Dieser Ansatz ist auch wissenschaftlich untersucht und zeigt, dass Sie KI-Halluzinationen vermeiden und sehr lange Ketten fehlerfrei aufbauen können
2. Der Harte Filter (Das Gesetz)
Hier ist keine Diskussion möglich. Code muss kompilieren. Linter dürfen keine Beanstandungen haben. Und entscheidend: die Black-Box-Tests müssen erfolgreich sein. Wir testen nicht, ob die Funktion intern funktioniert (das könnte die KI manipulieren), sondern ob das System von außen das tut, was es soll. Schlägt der Test fehl? Sofort in den Papierkorb.
3. Der sanfte Filter (Die KI-Jury)
Dies ist die eigentliche Innovation. Die verbleibenden Lösungen werden einer spezialisierten „Voting AI“ vorgelegt. Dieser Agent schreibt keinen Code, sondern liest Code. Er ist auf unsere Architekturprinzipien, Sicherheitsanforderungen (OWASP, ISO) und Compliance-Regeln (EU AI Act) trainiert.
Er stimmt ab: „Lösung A ist schneller, aber Lösung B ist sicherer und passt besser zu unserer Microservices-Architektur.“
Der Gewinner geht in die Produktion.
Die Gewaltenteilung der Software
Dieses Modell erzwingt eine Gewaltenteilung, die in vielen Teams fehlt.
- Die Legislative (Der Architekt): Der Architekt schreibt die „Verfassung“. Die Prompts, die Architektur-Dokumente (
project-description.md, rules.md en principles.md), die harten Anforderungen. Der Architekt bestimmt was Wir bauen und warum. - Die Exekutive (Die Coding Agents): Sie führen aus. Schnell, kostengünstig und unter der Schirmherrschaft menschlicher Entwickler.
- Die Judikative (Die Design Authority): Eine unabhängige KI-Schicht, die die Einhaltung von Gesetzen prüft.
Fazit: Die neue Rolle des Architekten
Es befreit uns von der Tyrannei der Syntaxfehler und erlaubt uns, uns auf das zu konzentrieren, worin wir gut sind: Systemdenken. Wahrheitsfindung. Struktur und Entscheidungsfindung.
Die Frage ist nicht, ob KI unseren Code schreiben kann. Das ist bereits entschieden. Code wird größtenteils austauschbar sein.
Die Frage ist: Traust du dich, die Kontrolle über die Umsetzung loszulassen, um dadurch die Kontrolle über die Qualität zurückzugewinnen?
