Wir befinden uns 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 laufen soll (IDE oder CLI). Aber das ist nicht die richtige Fragestellung.
Wenn wir KI als „Vibe Coders“ annehmen – bei denen wir die Intention vorgeben und die KI die Ausführung übernimmt –, erzeugen wir eine enorme Welle an 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 Flaschenhals geworden.
Die Lösung sind nicht mehr Menschen. Die Lösung ist eine KI-Design-Autorität.
Traditionell ist die „Design Authority“ eine Gruppe von Architekten, die sich einmal pro Woche oder Monat trifft, um einen Entwurf zu genehmigen oder abzulehnen. In einer Welt der KI-Entwicklung mit hoher Geschwindigkeit ist dieses Modell hoffnungslos veraltet. Es ist zu langsam und zu reaktiv.
Wenn wir zu „Disposable Code“ übergehen – Software, die wir nicht endlos refaktorisieren, sondern verwerfen und neu generieren, wenn sich die Anforderungen ändern –, verändert sich unsere Rolle fundamental. Wir sind keine Maurer mehr, die Stein für Stein legen. Wir sind die Architekten der Fabrik, die die Wände druckt.
Aber wer kontrolliert, ob diese Wände gerade stehen?
Eine AI Design Authority ist keine Person, sondern eine Pipeline. Ein „Gauntlet“, durch das sich jede Zeile generierter Code kämpfen muss, um die Produktion zu erreichen. Dieser Prozess ersetzt das menschliche Code-Review nicht durch Nichts, sondern durch etwas Besseres.
Es arbeitet in drei Schichten:
1. Die Exekutive (Die Generierung)
Wir bitten nicht eine KI um eine Lösung, sondern gleich drei. Wir lassen Gemini 3, GPT-5 und ein Open-Source-Modell (wie Llama) parallel am selben Problem arbeiten. Das verhindert Tunnelblick und durchbricht die „Trägheit“, unter der LLMs manchmal leiden. Dieser Ansatz ist zudem wissenschaftlich untersucht und zeigt, dass man KI-Halluzinationen verhindern und sehr lange Ketten fehlerfrei bauen kann
3. Der harte Filter (Das Gesetz)
Hier ist keine Diskussion möglich. Code muss kompilieren. Linters dürfen nicht meckern. Und entscheidend: Die Black-Box-Tests müssen bestanden werden. Wir testen nicht, ob die Funktion intern arbeitet (das kann die KI manipulieren), sondern ob das System nach außen hin tut, was es tun soll. Schlägt der Test fehl? Direkt in den Müll.
3. Der weiche Filter (Die KI-Jury)
Das ist die echte Innovation. Die verbleibenden Lösungen werden einer spezialisierten „Voting-KI“ 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 entspricht besser unserer Microservices-Architektur.“
Der Gewinner geht in die Produktion.
Dieses Modell erzwingt eine Gewaltenteilung, die in vielen Teams fehlt.
project-description.md, rules.md, skills.md en principles.md), die harten Anforderungen. Der Architekt bestimmt, was wir bauen, wer es baut, wie und warum.Es befreit uns von der Tyrannei der Syntaxfehler und lässt uns auf das konzentrieren, was wir am besten können: Systemdenken. Wahrheitsfindung. Struktur und Entscheidungsfindung.
Die Frage ist nicht, ob KI unseren Code schreiben kann. Dieses Thema ist bereits abgeschlossen. Code wird größtenteils zu einem Wegwerfprodukt.
Die Frage lautet: Wagst du es, die Kontrolle über den Code loszulassen, um dadurch die Kontrolle über die Qualität wiederzugewinnen?
lass es mich wissen