Wir stehen an einem Wendepunkt in der Softwareentwicklung. In der Diskussion geht es häufig darum, welche ob KI den besten Code schreibt (Claude oder ChatGPT) oder wo wo diese KI angesiedelt sein sollte (IDE oder CLI). Aber das ist nicht die richtige Fragestellung.
Wenn wir KI als „Vibe Coder“ einsetzen – indem wir die Absicht vorgeben und die KI die Umsetzung ü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 besteht nicht darin, mehr Menschen einzusetzen. Die Lösung ist eine KI-Designinstanz.
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 hochentwickelten KI-Entwicklung ist dieses Modell hoffnungslos veraltet. Es ist zu langsam und zu reaktiv.
Wenn wir auf „Disposable Code“ umsteigen – Software, die wir nicht endlos refaktorieren, sondern wegwerfen und neu generieren, sobald sich die Anforderungen ändern –, verändert sich unsere Rolle grundlegend. Wir sind keine Maurer mehr, die Stein für Stein aufeinanderstapeln. Wir sind die Architekten der Fabrik, die die Wände druckt.
Aber wer kontrolliert, ob diese Mauern gerade stehen?
Eine KI-Designinstanz ist keine Person, sondern eine Pipeline. Ein „Gauntlet“, durch das sich jede Zeile generierten Codes kämpfen muss, um in die Produktion zu gelangen. Dieser Prozess ersetzt das menschliche Code-Review nicht durch nichts, sondern durch etwas Besseres.
Sie funktioniert in drei Ebenen:
1. Die ausführende Gewalt (die Generierung)
Wir bitten nicht eine einzige 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 außerdem wissenschaftlich untersucht und zeigt, dass sich KI-Halluzinationen verhindern und sehr lange Ketten fehlerfrei aufbauen lassen
2. Der harte Filter (das Gesetz)
Hier gibt es keinen Raum für Diskussionen. Der Code muss kompilieren. Linter dürfen keine Beanstandungen melden. Und entscheidend: Die Black-Box-Tests müssen bestehen. Wir testen nicht, ob die Funktion intern funktioniert (das kann die KI manipulieren), sondern ob das System von außen genau das tut, was es tun soll. Schlägt der Test fehl? Dann geht es direkt in den Papierkorb.
3. Der weiche Filter (die KI-Jury)
Das ist die eigentliche Innovation. Die verbliebenen Lösungen werden einer spezialisierten „Voting-KI“ vorgelegt. Dieser Agent schreibt keinen Code, sondern liest Code. Er wurde anhand unserer 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 unserer Microservices-Architektur besser.“
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, worin wir gut sind: 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: Traust du dich, die Kontrolle über den Code loszulassen, um dadurch die Kontrolle über die Qualität zurückzugewinnen?
Lass es mich wissen