Wir stehen an einem Wendepunkt in der Softwareentwicklung. Die Diskussion dreht sich oft um welche KI, die den besten Code schreibt (Claude vs. ChatGPT) oder wo wo KI leben soll (IDE oder CLI). Aber das ist nicht die richtige Fragestellung.
Het probleem is niet het genereren van code. Het is de validatie ervan.
Wenn wir KI als „Vibe Coders“ annehmen – wobei wir die Absicht vorgeben und die KI die Ausführung übernimmt – erzeugen wir einen enormen Strom neuer Software. Ein Schwarm KI‑Agenten kann in einer Minute mehr Code generieren, als ein Senior‑Entwickler in einer Woche prüfen kann. Der Mensch ist zum Engpass geworden.
Die Lösung ist nicht mehr Menschen. Die Lösung ist ein AI Design Authority.
Traditionell ist die „Design Authority“ eine Gruppe von Architekten, die sich einmal pro Woche oder Monat trifft, um ein Design zu genehmigen oder abzulehnen. In einer Welt von hochgeschwindige KI-Entwicklung ist dieses Modell hoffnungslos veraltet. Es ist zu langsam und zu reaktiv.
Wenn wir zu „Disposable Code“ – Software, die wir nicht endlos refaktorisieren, sondern wegwerfen und neu generieren, wenn sich die Anforderungen ändern – wechseln, ändert sich unsere Rolle grundlegend. Wir sind keine Maurer mehr, die Stein für Stein legen. Wir sind die Architekten der Fabrik, die die Wände drucken.
Aber wer kontrolliert, ob diese Wände gerade stehen?
Eine KI-Design-Authority ist keine Person, sondern eine Pipeline. Ein „Gauntlet“, durch das jede Zeile generierten Code kämpfen muss, um in die Produktion zu gelangen. Dieser Prozess ersetzt die menschliche Code‑Review nicht mit nichts, aber mit etwas besseres.
Es funktioniert in drei Schichten:
1. Die Exekutive (Die Generation)
Wir fragen nicht nur eine 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. Das verhindert Tunnelblick und durchbricht die „Trägheit“, unter der LLMs manchmal leiden. Dieser Ansatz ist auch wissenschaftlich untersucht und zeigt, dass man KI‑Halluzinationen verhindern und sehr lange Ketten ohne Fehler bauen kann
2. Der harte Filter (das Gesetz)
Hier ist keine Diskussion möglich. Code muss kompilieren. Linter dürfen nicht meckern. Und entscheidend: die Black-Box-Tests müssen bestehen. Wir testen nicht, ob die Funktion intern funktioniert (das könnte die KI manipulieren), wir testen, ob das System von außen das tut, was es tun soll. Schlägt der Test fehl? Direkt in den Papierkorb.
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: "Lösung A ist schneller, aber Lösung B ist sicherer und folgt unserer Microservices-Architektur besser."
Der Gewinner geht in die Produktion.
Dit model dwingt een scheiding der machten af die in veel teams ontbreekt.
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.
Het bevrijdt ons van de tirannie van syntax-fouten en laat ons focussen op waar we goed in zijn: Systeemdenken. Waarheidvinding. Structuur en besluitvorming.
De vraag is niet of AI onze code kan schrijven. Dat onderwerp is al afgesloten. Code wordt grotendeel een wegwerp product.
De vraag is: Durf jij de controle over de Code los te laten, om daarmee controle over de Qualität zurückzugewinnen?
Lass es mich wissen