Vor einigen Wochen durfte ich eine Szene miterleben, die ich so schnell nicht vergessen werde.
Ein Kunde von mir, Fachexperte durch und durch, kein Entwickler, keine einzige Zeile Code im Lebenslauf, sitzt in einem Termin mit einem großen Konzern seiner Branche. Auf dem Tisch liegt ein Thema, das die Branche seit Jahren beschäftigt. Es gab Arbeitskreise, Workshops, Fachkonzepte und Angebote etablierter Softwareanbieter, und keine der Lösungen hat je wirklich gepasst.
Mein Kunde hört eine Weile zu, öffnet dann seinen Laptop und beginnt zu tippen. Keine Folien, kein Konzeptpapier, ein Prompt. Zehn Minuten später dreht er den Bildschirm um und zeigt einen klickbaren Dummy. Masken, Abläufe, Begriffe, alles genau so, wie es die Menschen brauchen, die täglich damit arbeiten. Im Raum wird es erst still, dann passiert etwas, das in solchen Terminen selten passiert: echte Begeisterung.
Zehn Minuten. Für etwas, woran technische Experten der Branche mehrere Jahre gescheitert sind.
Warum zehn Minuten schaffen, woran Jahre scheiterten
Die Antwort ist unbequem einfach. Zum ersten Mal wurde die Lösung nicht von technischen Experten entworfen, die die Domäne aus Workshops, Lastenheften und Interviews kennen, sondern von einem echten Fachexperten und Anwender, der jeden Ablauf und jeden Sonderfall selbst erlebt hat. Er musste niemanden fragen, was gebraucht wird. Er ist derjenige, der es braucht.
Dass die neue Programmiersprache Deutsch ist und Fachexperten sie fließend sprechen, habe ich bereits beschrieben. In diesem Termin habe ich zum ersten Mal live erlebt, was das bedeutet, wenn es auf eine ganze Branche trifft.
Die Softwarebranche predigt seit Jahrzehnten Nutzerzentrierung, veranstaltet Design Thinking Workshops und malt Personas an Whiteboards. Und trotzdem ist die einfachste Lösung von allen, einfach mal ernsthaft mit den Anwendern zu sprechen, erstaunlich selten wirklich passiert. Zwischen dem Menschen, der die Arbeit macht, und dem Menschen, der die Software baut, lagen immer drei Übersetzungsstationen, und an jeder davon ist Wissen verloren gegangen.
Jetzt braucht es diese Stationen nicht mehr. Der Anwender wartet nicht mehr darauf, gefragt zu werden. Er baut selbst.
Vier Wochen im Rausch
Der Klickdummy war erst der Anfang, denn mein Kunde hatte Blut geleckt. Schlau, neugierig und mit unendlich vielen Ideen, was ihm in seinem Geschäftsalltag helfen könnte, nahm er sich vier Wochen Zeit und promptete Tag für Tag. Das Ergebnis kann sich sehen lassen. Funktionierende, wirklich nützliche Software, die lokal läuft und Arbeitsschritte automatisiert, für die es am Markt nichts Vergleichbares gibt.
Und dann kam der Moment, in dem die Software live gehen sollte. Sie ließ sich nicht deployen.
Das LLM war extrem kreativ darin, alles umzusetzen, was gepromptet wurde, auch dann, wenn es so nicht sinnvoll möglich war. Statt zu sagen, das geht in dieser Form nicht, hat es Wege gefunden. Diverse Docker Container hier, lokal installierte Werkzeuge dort, und obwohl in Ubuntu unter WSL2 gearbeitet wurde, liefen am Ende Teile unter Windows und wurden aus Ubuntu heraus verwendet. Auf dem Rechner des Kunden funktionierte alles. Auf jedem anderen System nicht.
Das ist kein Vorwurf an den Kunden. Er hat mit fachlicher Präzision ein Ergebnis beschrieben und gnadenlos aus Anwendersicht getestet. Das Modell hat geliefert, was verlangt wurde. Niemand hat verlangt, dass es auch deploybar, wartbar und nachvollziehbar sein soll, also war es das auch nicht.
Als die Software fertig war, sollten sich die Techniker das Ganze ansehen. Und hier stießen wir an eine Grenze, die mich seither beschäftigt: Tausende generierte Codezeilen lassen sich manuell nicht mehr qualitätssichern. Der klassische Code Review, das sorgfältige Lesen jeder Zeile, das Nachvollziehen jeder Entscheidung, skaliert schlicht nicht mit der Geschwindigkeit, in der ein Modell Code produziert. Ein Review, der annähernd so lange dauert wie die Entwicklung selbst, würde den gesamten Geschwindigkeitsvorteil wieder auffressen.
Da lag er also vor uns, ein Rohdiamant. Fachlich brillant, funktionierend, nachweislich wertvoll, das hatte der Konzern in zehn Minuten bestätigt. Aber ungeschliffen, und in dieser Form nicht verkäuflich. Die Frage, die uns seither beschäftigt, ist nicht mehr, ob dieser Diamant etwas wert ist. Die Frage ist, wie wir ihn schleifen, ohne ihn dabei zu zerstören, und vor allem, welche Werkzeuge wir dafür brauchen.
Was Uncle Bob dazu sagen würde
Die erste Antwort: Wir können zum Schleifen technische Werkzeuge verwenden, und zwar dieselben, die uns die Branche seit Jahren bereitstellt, nur eingesetzt auf eine neue Art. Den ersten Hinweis darauf liefert ausgerechnet Robert C. Martin, ein Urgestein der Softwarebranche und Autor von Clean Code. Er hat in einem aktuellen Interview beschrieben, wie er mittlerweile mit Coding Agents arbeitet. ¹ Auch er hat anfangs erlebt, was wir erlebt haben, der Agent war schnell, aber die Qualität des generierten Codes entsprach nicht seinen Erwartungen.
Dann kam sein Aha Moment: Weil Agents schnell sind und sich für langweilige Arbeit nicht zu schade sind, können sie Qualitätswerkzeuge einsetzen, die immer schon gute Ideen waren, für Menschen aber unpraktikabel. Er nennt zwei Beispiele. Der CRAP Score kombiniert Testabdeckung mit zyklomatischer Komplexität und bewertet damit, wie schlecht eine Funktion wirklich ist. Uncle Bob hatte das einmal auf ein Projekt losgelassen und aufgegeben, weil das händische Beheben aller Funde viel zu lange gedauert hätte. Und Mutation Testing verändert gezielt Operatoren im Quellcode und erwartet, dass die Testsuite fehlschlägt, was bedeutet, dass eine Logik ungetestet ist, wenn die Mutation überlebt. Früher liefen solche Analysen über Nacht, heute erledigt sie ein Agent nebenbei.
Diese Werkzeuge sind sein Quality Gate geworden, eine Prüfschranke, durch die jeder generierte Code hindurch muss, bevor er als fertig gilt. Nicht ein Mensch liest den Code und bildet sich ein Urteil, sondern messbare Kriterien entscheiden, ob die Qualität reicht, und der Agent bessert so lange nach, bis die Werte stimmen. Damit ist genau das gelöst, woran wir mit unseren tausenden Zeilen gescheitert sind, denn eine solche Prüfung skaliert mit der Geschwindigkeit des Modells, ein menschlicher Review tut das nicht. Bleibt die Frage, warum Uncle Bob auf harte Messwerte setzt statt dem Modell einfach gute Anweisungen mitzugeben. Die Antwort darauf ist die eigentliche Erkenntnis.
Prompts werden als Richtlinien behandelt
Uncle Bob hat es zuerst so versucht, wie wir alle es versuchen. Er hat dem Modell ein mehrseitiges Dokument mitgegeben, so schreibst du sauberen Code, so strukturierst du Funktionen, so benennst du Dinge. Das Ergebnis: Die Modelle behandeln solche Regeln eher wie unverbindliche Richtlinien. Ein Teil davon ist der bekannte Lost in the Middle Effekt, alles, was nicht am Anfang oder am Ende des Kontexts steht, wird gerne ignoriert.
Seine Konsequenz ist radikal einfach. Den initialen Prompt minimal halten und Qualität stattdessen mit Werkzeugen erzwingen, die nicht vergessen werden können, indem man den Agent so lange in einer Schleife laufen lässt, bis der Prüfer grünes Licht gibt. Er tauscht damit bewusst Geschwindigkeit gegen Qualität und hat nach eigener Aussage den Punkt noch nicht gefunden, an dem sich dieser Tausch nicht mehr lohnt.
Fast zeitgleich bin ich über eine Demo aus der Laravel Community gestolpert, die dieselbe Erkenntnis von einer ganz anderen Seite erreicht. ² Der Vortragende baut dieselbe Anwendung zweimal, einmal mit einem nackten Prompt, einmal mit Leitplanken. Der erste Durchlauf liefert eine funktionierende App, aber ohne Typdeklarationen, mit N+1 Problemen, mit einer handgestrickten Authentifizierung statt eines Starter Kits und ohne jede statische Analyse. Seine wichtigste Beobachtung dabei: Er hat denselben Prompt mehrfach ausgeführt und jedes Mal ein anderes Ergebnis bekommen, nicht nur im Design, sondern in den Qualitätsentscheidungen. Mal ein Starter Kit, mal nicht. Mal Enums, mal nicht.
Varianz im Design ist erwartbar und in Ordnung aber Varianz in der Codequalität und Konsistenz ist es nicht. Konsistenter Code hilft übrigens auch dem Modell selbst, weil es sehen kann, wie Dinge in diesem Projekt gemacht werden, statt es jedes Mal neu zu entscheiden.
Im zweiten Durchlauf ergänzt er den Prompt um eine einzige Zeile, die auf ein offizielles Konventionsdokument verweist, und verdrahtet anschließend Formatierung, statische Analyse und automatisches Refactoring zu einem einzigen Kommando, das lokal, für den Agent und in der CI bei jedem Push läuft. Das Ergebnis ist technisch besser, durchgängig typisiert, mit fertiger Zwei Faktor Authentifizierung, mit Enums, mit Qualitätswerkzeugen, die Regeln nicht nur anmahnen, sondern Code automatisch umschreiben. Sein Leitsatz bringt es auf den Punkt: Prompts sind Vorschläge, Leitplanken sind Garantien.
Zwei völlig unterschiedliche Welten, ein Urgestein der Softwareliteratur und ein Framework Praktiker, und beide landen beim selben Schluss. Anweisungen im Kontext werden aufgeweicht oder ignoriert. Qualität muss in deterministischen Werkzeugen leben, gegen die das Modell in einer Schleife arbeiten muss.
Die KI prüft, was die KI gebaut hat
Zurück zu unserem Kunden und seinen tausenden Zeilen. Wir haben aufgehört, den Code manuell lesen zu wollen, und setzen stattdessen die KI selbst darauf an. Sie erklärt uns die Struktur, sie findet die problematischen Stellen, sie zeigt uns, wo Abhängigkeiten kreuz und quer laufen und wo die Windows und Ubuntu Welt unheilvoll verheiratet wurde. Das Modell, das die Probleme produziert hat, ist erstaunlich gut darin, sie zu finden, wenn man es explizit danach fragt.
Und wir gehen einen Schritt weiter. Wir sammeln die typischen schlechten Muster, die dabei immer wieder auftauchen, und benennen sie konkret. Aus dieser Liste verbessern wir die Instruktionsdateien, die dem Modell in jeder Session mitgegeben werden. Nicht als seitenlanges Clean Code Manifest, das im Kontext untergeht, sondern als kurze, projektspezifische Konventionen, ergänzt um Prüfwerkzeuge, die diese Konventionen erzwingen. Genau die Kombination, die beide Quellen empfehlen: wenig Prompt, viel Leitplanke.
Lösung Nummer zwei: Der Prozess ist nicht neu
Die technischen Werkzeuge sind aber nur die halbe Antwort. Die zweite Hälfte ist unspektakulärer, und vielleicht beschäftigt sie mich gerade deshalb am meisten: Die Organisation von Softwareprojekten hat sich nicht geändert.
Softwaresysteme sind nach wie vor die komplexesten Systeme, die Menschen je erschaffen haben, und daran ändert auch ein Modell nichts, das Code in Sekunden erzeugt. Der Schlüssel, um diese Komplexität zu beherrschen, ist derselbe geblieben wie in den letzten fünfzig Jahren: Kommunikation im Team. Zusammenarbeit statt Alleingänge.
Wenn ich zusammenzähle, was hier eigentlich passiert, dann steht da: Ein Fachexperte mit tiefem Domänenwissen treibt die Entwicklung, weil er am besten weiß, was gebraucht wird. Technische Menschen sorgen dafür, dass das Ergebnis wartbar, deploybar und sicher betreibbar ist. Beide lernen voneinander und passen ihre Werkzeuge und Regeln laufend an. Kurze Zyklen schlagen große Pläne. Plan, Do, Check, Act.
Das ist kein neues Paradigma, das ist ganz einfach ein Team mit unterschiedlichen Fähigkeiten, das iterativ arbeitet.
Auf den ersten Blick wirkt das teuer, weil in Meetings scheinbar nur geredet statt gearbeitet wird. Aber die Rechnung wird am Ende gemacht, nicht am Anfang. Die vermeintlich einfache Alternative, einer promptet alleine los und die anderen schauen später einmal drüber, sah bei unserem Kunden vier Wochen lang nach maximaler Effizienz aus. Bis am Ende die teuerste aller Positionen auf der Rechnung stand: funktionierende Software, die niemand ausliefern kann.
Uncle Bob kommt im Interview zum selben Schluss, ausgerechnet der Mann, der jahrzehntelang für strenge Disziplin in der Softwareentwicklung stand. Er hält nichts von Spec Driven Development, bei dem man vorab eine perfekte, riesige Spezifikation schreibt und die Agents dann loslaufen lässt. Das scheitert aus demselben Grund, aus dem Waterfall gescheitert ist, man hat eben doch nicht an alles gedacht, die Agents rennen mit halbem Wissen los, und man darf zurückrudern und neu schreiben. Er bevorzugt eine agile Schleife, eine oder zwei Stories umsetzen, anschauen, reorganisieren, weitermachen. Seine Analogie dazu ist, wenn jede Änderung an einem Haus einen Euro kosten würde, würde niemand einen Architekten für den perfekten Plan bezahlen, man würde einfach iterieren. Agents haben die Änderungskosten nahe null gedrückt, genau die Beobachtung, die ich im Beitrag über die neue Programmiersprache am Beispiel meines Geschäftspartners beschrieben habe.
Aber billige Änderungen machen den Prozess nicht überflüssig, sie machen ihn schneller aber die Schleife bleibt dieselbe.
Fazit: Der Boomerang
Zehn Minuten haben bewiesen, dass ein Fachexperte mit KI entwerfen kann, woran technische Experten jahrelang gescheitert sind. Vier Wochen haben bewiesen, dass daraus wertvolle, funktionierende Software entsteht und die gescheiterte Deployment Phase hat bewiesen, dass das allein noch kein Produkt ist.
Wir brauchen weiterhin Teams mit unterschiedlichen Fähigkeiten, fachliche Köpfe, die wissen, was gebaut werden soll, und es mittlerweile selbst prompten können, technische Köpfe, die dafür sorgen, dass daraus betreibbare, wartbare, sichere Systeme werden, und die diese Qualität nicht mehr durch das Lesen jeder Zeile sichern, sondern durch Leitplanken, die kein Modell ignorieren kann. Software zu bauen braucht weiterhin Zeit, nur eben deutlich weniger und kurze iterative Zyklen sind weiterhin der einzige Weg, der funktioniert, weil niemand, weder Mensch noch Modell, vorab an alles denkt. Waterfall hat vorher nicht funktioniert und funktioniert auch mit KI nicht. Wir müssen agil bleiben, in einer Welt, die sich verändert hat, deren Grenzen aber dieselben geblieben sind.
Damit revidiere ich auch ein Stück weit meinen letzten Beitrag, in dem der Alleingang des Fachexperten noch wie die ganze Antwort aussah. Das gehört dazu, denn wir stecken mitten in einer Lernphase, die sich so schnell bewegt, dass Erkenntnisse von vor wenigen Wochen heute schon nachgeschärft werden müssen. Eine Aussage von damals bleibt aber uneingeschränkt stehen: die Warnung an die großen Softwarehäuser. Kleine, schlanke, lernende Organisationen, die den Mut haben, Dinge einfach auszuprobieren, profitieren gerade enorm. Behäbige große Häuser, die bürokratisch denken, statt zu handeln, werden es in nächster Zeit schwer haben.
Denn für sie steckt in dieser Geschichte eine unbequeme Pointe. Die vermeintlich einfachste Lösung, einfach ernsthaft mit den Anwendern zu sprechen, wurde jahrzehntelang durch Prozesse, Gremien und schlechtes Management ersetzt. Jetzt holt sich der Anwender selbst die Lösung, mit einem Laptop und zehn Minuten Zeit.
Die Frage, die jahrzehntelang niemand gestellt hat, stellen die Anwender jetzt selbst und sie beantworten sie gleich mit.
Uncle Bob hat im Interview einen Satz gesagt, der hängen geblieben ist: Die Regeln, die du heute wegwirfst, wirst du in einem Jahr vom Boden aufheben, abstauben und dich erinnern, warum du sie gebraucht hast.