Wer hätte nicht gerne einen „Bob der Baumeister“ für die eigenen vier Wände, der sofort auf den Plan tritt, wenn hier mal was bröckelt oder da mal was schimmelt. Solche Macher sind schwer zu kriegen und selbst die Band „Das Lumpenpack“ besingt ihre Enttäuschung darüber nur Pädagogen, statt Handwerker im Freundeskreis zu haben.
„IT-Teams will become HR departments of AI.“
Egal ob Jensen Huang recht behalten wird oder nicht: es ändert sich genug, um sich einer recht alten Frage auf neue Weise zu nähern, die auch den ein oder anderen Häuslebauer sicherlich schon beschäftigt hat:
Modernisieren oder Abreißen?
Metaphern sind wie Piraten – sie hinken, tun aber ihren Job
Wenn wir über digitale Produkte sprechen, dann wir tauchen wir gerne in Analogien wie die eben bemühte „Hausbau-Metapher“ ab.
Gute Software besticht durch “sauberen Code”. Sie läuft “smooth” und hat ein aufgeräumtes User Interface mit “shiny“ User Interface Elementen. Umgekehrt bezeichnen wir digitale Produkte, die ihre beste Zeit hinter sich haben als verstaubt, verworren und schwer zugänglich.
Yoder und Foote, die sich intensiv mit dem Thema einer guten Software-Architektur auseinandergesetzt haben, bezeichnen schlechte Software simpel als “Big Ball of Mud”, also einem großen Schlamm-Knäuel.
Ein „Big Ball of Mud“ ist ein planlos strukturierter, ausufernder, schlampiger, mit Klebeband und Bindedraht zusammengehaltener Spaghetti-Code-Dschungel. Derartige Systeme weisen eindeutige Anzeichen von ungehemmtem Wachstum und ständigen Behelfsreparaturen auf. Die in diesen Systemen enthaltenen Informationen sind wahllos über die entferntesten Elemente verteilt, oft bis zu dem Punkt, wo fast alle wichtigen Informationen global oder dupliziert sind. Die Architektur derartiger Systeme wurde vielleicht nie richtig definiert, und wenn doch ist sie bis zur Unkenntlichkeit erodiert. Programmierer mit einem Fetzen architektonischer Sensibilität meiden derartige Sümpfe. Nur diejenigen, die sich nicht um Architektur scheren und vielleicht sogar gerne Tag für Tag mühsam Löcher in undichten Deichen stopfen, arbeiten gerne mit solchen Systemen.
— Yoder und Foote, Big Ball of Mud
Dieses bewusst abscheuliche Bild legt die Versuchung nahe, solche Alt-Systeme sich selbst zu überlassen und auf der vielzitierten und ebenfalls metaphorischen „grünen Wiese“ einfach neu zu bauen. Wenn wir jetzt sogar KI-Agenten – quasi fast gratis – für den Neubau zur Verfügung haben, warum sollten wir uns dann überhaupt noch mit diesen Altlasten abgeben?
Anforderungen, Baby
Die Antwort liegt mal wieder sehr weit vorne im Entwicklungsprozess – bei den Anforderungen. Ein Altsystem mag ohne Architektur oder Planung entstanden sein, aber gewachsen ist es immer entlang von: Anforderungen.
Will heißen: keiner baut nur so zum Spaß eine Software über Jahre hinweg zu einem „Big Ball of Mud“ aus! Es wollten einfach zu viele Anforderungen in zu kurzer Zeit umgesetzt werden, ohne dass es ausreichend Zeit für deren Verifizierung, Priorisierung und Konsolidierung gab. Manche dieser Anforderungen haben sich sogar widersprochen und im Endergebnis dann zu Features geführt, die „weder Fisch noch Fleisch“ sind.
Jeder kann coden!
Ein gutes Anforderungsmanagement zu betreiben, ist seit dem Siegeszug von agilen Ansätzen wie Scrum oder SaFE durchaus nicht mehr so en-vogue wie eint. Statt gute User Stories zu schreiben, schreibt so manch kreativer PO lieber ein paar Lösungsideen ins Backlog und hofft, dass das Team diese im besten Sinne umsetzt. Nach dem Sprint kann man ja immer noch schauen, ob das Ergebnis taugt oder nicht. Und wenn die Software Engineers schneller programmieren könnten und nicht so viel kosten würden, dann bräuchte man ja auch viel weniger Zeit und Geld, um zur perfekten Software zu kommen.
KI-Agenten können untereinander kommunizieren, digitale Werkzeuge bedienen, Code generieren und gemeinsame Entscheidungen treffen, was sie letztlich dazu befähigt, Software-Entwicklungsteams zu bilden. Das von DeepWisdom.ai initiierte „Multi-Agenten“ Framework MetaGPT beispielsweise hat ein solches Team aus KI-Agenten umgesetzt, und lässt es als KI-Team gemeinschaftlich Software entwickeln.
Bot der Baumeister
Kann also ein kreativer PO nicht einfach seine Lösungsideen an sein Team von KI-Agenten übermitteln und diese bauen die Software dann ganz in seinem Sinne für ihn? An der Spitze dieses Teams würde ein bauleitender KI-Agent die Koordination übernehmen und die Detailarbeiten an weitere KI-Agenten delegieren.
Ja – technisch ist das inzwischen möglich. Und kommt es nicht auch ein wenig bekannt vor?
Sagen wir also „Hallo“ zu „Bot, der Baumeister“, unserem weisen KI-Bauleiter und seinen talentierten KI-Agenten-Freunden Backie, Frontie, Testie und wie sie alle heißen könnten.
Was so flapsig und auch ein wenig unglaubwürdig klingt, ist tatsächlich die treibende Idee hinter vielen aktuellen (und finanziell zum Teil überbordend unterstützten) Vibe Coding Tools und KI-getriebenen IDEs.
An dieser Stelle möchte ich nur die bekanntesten Werkzeuge nennen, wohlwissentlich, dass zum Zeitpunkt der Veröffentlichung dieses Artikels wahrscheinlich schon das nächste derartige Produkt in den Startlöchern steht:
- Cursor IDE
- Replit
- Roocode
- MGX
- Cline (VS Code Plugin)
- Lovable
- Kiro IDE (Amazon)
- V0 (Vercel)
- GitHub CoPilot (Microsoft)
Die genannten Tools sind in ihrer Philosophie als auch in ihrer Handhabung natürlich vollkommen unterschiedlich! Aber viele von ihnen, wie z.B. MGX, Lovable oder V0 haben zumindest eines gemeinsam: sie lieben die grüne Wiese und können sehr schnell von 0 auf 100 eine komplett neue, lauffähige Anwendung bauen. Das liegt wahrscheinlich mitunter daran, dass es für VCs beeindruckender ist, eine Software per Fingerschnips entstehen zu sehen als eine komplexe Legacy-Software zu migrieren, die man erst mal durchdringen müsste. Wie sagen sie im Silicon Valley immer so schön…
„Move fast and break things.“
… so, als wäre das Zerbrechen schon eine Heldentat für sich. Zugegeben: ich bin ja eher von der Fraktion „Move fast and improve things.“, aber bevor ich mich hier zu sehr als Silicon Valley Kritiker oute, komme ich zurück zum Thema, denn:
Bei genauerer Betrachtung sind die vielen Vibe Coding, Prototyping und App-Generierungs-Tools doch nicht so ähnlich wie sie auf den ersten Blick erscheinen mögen.
Sie lassen sich zwar nicht unbedingt in „Neubauer & Modernisierer“ aufteilen, jedoch immerhin in „Planer & Macher“: Während man in Cline beispielsweise eine Anforderungsspezifikation hinterlegt und zwischen den beiden Modi „Plan & Act“ umschalten kann, muss man bei Cursor IDE gefühlt jeden nächsten Umsetzungsschritt prompten.
Wer mich beim Selbstexperiment mit Cursor IDE erleben möchte, dem oder der empfehle ich meinen aktuellen Accessibility Podcast „2025: Odyssee Accessibility“… eine wahre Achterbahnfahrt der Gefühle.
Big Ball of Mud 2.0
Mein Vibe Coding Selbstexperiment mit Cursor IDE hat mir vor allem eine Erkenntnis beschert: obwohl wir nun schneller und billiger Code schreiben können, werden wir nicht zwangsläufig schneller zur perfekten Software kommen. Vor allem aber laufen wir Gefahr, uns schneller einen wunderschönen „Big Ball of Mud“ zu basteln… einen „Big Ball of Mud 2.0“ quasi.
Das größte Risiko, beim Bau von Software besteht nämlich trotz KI immer noch darin, dass wir nicht wissen, ob wir aus der Perspektive der Nutzenden und des Marktes etwas bauen, was auch tatsächlich Akzeptanz findet. Daher ist es wichtig zu betonen, dass die Stärke der genannten KI-Tools insbesondere im Prototyping liegt, nicht aber beim Aufbau skalierbarer Architekturen.
Risikoarme Software Modernisierung
Um die größten Risiken bei der Softwareentwicklung zu minimieren, lohnt es sich also, nicht nur die Code-generierenden Möglichkeiten von KI-Agenten zu betrachten, sondern auch die Möglichkeiten, wie man zu besseren Anforderungen gelangt. Dabei habe ich Prototyping schon als legitimes und probates Mittel herausgestellt.
Blickt man jedoch ein wenig tiefer, kann man die KI auch nutzen, um das bestehende Legacy-System als „Anforderungsfabrik“ für ein modernes, intuitives und architektonisch sauberes System zu nutzen.
Natürlich birgt auch eine solche KI-getriebene Migration gewisse Risiken und ein bloßes „Jo, wir schaffen das“ wird (auch hier) nicht reichen.
Der zweite Teil meiner Artikelreihe beschäftigt sich daher mit der Frage, wie man eine KI-getriebene Software-Migration schrittweise angehen kann, um die Nutzenden mitzunehmen und die Risiken des Scheiterns so gering wie möglich zu halten.
