Die 5 Mythe über die apokalyptische Ära des agentenbasierten Codings

Agentic AI verspricht schnelleres Programmieren - doch versteckte Risiken in den Bereichen Testen, Sicherheit und Wartung könnten Projekte zum Scheitern bringen, sofern Entwickler nicht neu darüber nachdenken, wie sie maschinengenerierte Software im großen Maßstab verwalten, validieren und überwachen.

Wichtige Erkenntnisse

• Wenn man die Kontrolle über das Coden an KI abgibt, steht man vor echten Wartungs- und Nachhaltigkeitsproblemen.

• KI-Agenten damit zu beauftragen, Ihren Code zu schreiben, ist sehr ähnlich, als würde man menschliche Auftragnehmer damit beauftragen.
• Diese Best Practices helfen Ihnen dabei, von KI das zu erhalten, was Sie verlangt haben.

Es gibt zwei vorherrschende Ansichten bezüglich des „Vibe Coding“. Die erste besagt, dass man nur einen einzigen Satz schreiben muss und die KI einem daraufhin eine Millionen-Dollar-App liefert. Die zweite Ansicht ist, dass die KI den gesamten Code schreibt - daher haben Menschen keinerlei Ahnung, was sich darin verbirgt. Folglich muss die App irgendwann versagen und zu einer Art „Apokalypse“ führen.

Beide Darstellungen sind Karikaturen der Realität. In früheren Artikeln habe ich über meine Arbeit an verschiedenen vibe-coded-Projekten geschrieben. Wir haben gesehen, dass diese Projekte zwar großartig sind, aber auch sehr viel Arbeit erfordern. In diesem Artikel werde ich mich intensiv mit den Fragen der Wartung und Nachhaltigkeit beschäftigen, die auftreten, wenn man die Kontrolle über das Programmieren an eine Maschine abgibt.

Als ich noch ein junger Produktmanager war, wurde ich nach Los Angeles geschickt, um unserem Vertriebsvorstand zur Seite zu stehen. Er beschloss, mich in eines seiner Lieblingsrestaurants mitzunehmen. Dieses Restaurant spezialisierte sich auf Fusion-Küche - das bedeutet, der Koch mischte viele verschiedene Einflüsse in seine Gerichte. Es hatte den Ruf, für das „Spezialgericht des Kochs“ bekannt zu sein - also für das Gericht, das der Koch an diesem Abend für die Gäste kreierte.

Ich erinnere mich, dass ich mich gefragt habe, worauf ich mich da eingelassen hatte. Ich wusste, dass ich etwas zu essen bekommen würde, aber ich hatte keine Ahnung, was von mir erwartet wurde, zu essen. Wie sich herausstellte, war das Essen, das wir an jenem Abend aßen,… seltsam. Es war essbar. Doch es war kein Ort, an den ich freiwillig noch einmal gehen würde.

Agentisches Codieren ähnelt sehr dem Besuch dieses Restaurants. Man weiß zwar, dass die Reputation der Code-KI, die man verwendet, gut ist - aber man hat eigentlich keine Ahnung, was einem am Ende serviert wird. Man hat kaum Einblick in den tatsächlichen Code, der von der KI erzeugt wird. Im Grunde muss man den Code einfach akzeptieren - egal, was einem serviert wird.

Wenn Agenten Ihren Code schreiben, ist das vergleichbar damit, dass eine Reihe von Auftragnehmern oder Untergebenen Ihren Code schreiben. Solange Sie ihn nicht testen und bewerten, wissen Sie nicht, was Sie am Ende erhalten werden.

Alles hängt von Ihrer Anweisung ab. „Müll hinein, Müll heraus“ hat eine viel tiefere Bedeutung, als dieser abgedroschene Ausdruck vermuten lässt. Wenn Sie Ihre Anweisungen nicht klar genug formulieren und das Gespräch nicht mit ausreichender Klarheit sowie Kontrolle fortführen, wird der von der KI erzeugte Code schwer verständlich sein.

1. Der Mythos vom verlorenen Kontrollverlust

Seit Zeiten der Pyramiden stehen Ingenieurmanager vor der Herausforderung, die unter ihrer Aufsicht stehenden Auftragnehmer zu managen. Die Zuweisung von Aufgaben sowie die Bewertung der Arbeitsergebnisse gehören zu den Aufgaben von Ingenieurmanagern. Die Aufrechterhaltung von Qualität und Kontrolle in diesem Prozess ist das Kernstück der Softwareentwicklung.

Andererseits: Auch wenn vieles von der pessimistischen Stimmung rund um das Vibe-Coding übertrieben ist, steckt doch etwas Wahrheit darin. Ohne Qualitätsstandards und -praktiken kann man am Ende auf problematischen Code stoßen. In diesem Artikel werden wir die Mythen rund um das agentenbasierte Programmieren sowie die besten Praktiken besprechen, die Ihnen helfen, von KI-Systemen das zu erhalten, was Sie verlangen.

Viele Befürworter der Nutzung von KI beim Codieren empfehlen, der KI ausführliche und detaillierte Anforderungsdokumente zur Verfügung zu stellen. Meine Erfahrung zeigt jedoch, dass die KI ein einzelnes Element in diesen Dokumenten falsch interpretieren kann - mit der Folge, dass sie völlig vom Kurs abkommt, auf eine Weise, die man nicht nachvollziehen oder erkennen kann.

Ich bevorzuge es, der KI eine einfache Aufgabe zu geben. Sobald diese erfolgreich erledigt ist, gebe ich ihr eine weitere Aufgabe. Auf diese Weise gibt es weniger Möglichkeiten, dass entweder die KI oder ich den Überblick über den Gesamtplan verlieren.

Als alleiniger Entwickler schrieb ich früher den Code Zeile für Zeile. Bei jeder einzelnen Zeile habe ich geschwitzt. Ich wusste alles über meinen Code. Doch als Engineering-Manager musste ich mich auf meine Teams sowie die einzelnen Entwickler in diesen Teams verlassen.

Natürlich hatten wir Programmierer (im Grunde das Äquivalent zu Agenten). Doch ich musste trotzdem eine Disziplin des Testens und der Integration in das System etablieren, um sicherzustellen, dass das, was von einem unserer Programmierer oder Auftragnehmer eingereicht wurde, mit allem anderen kompatibel war.

Wenn Sie agentenbasiertes Codieren verwenden wollen, müssen Sie dasselbe tun: Setzen Sie Checkpoints in jeder Phase und verfolgen Sie die Integration sorgfältig. Gehen Sie davon aus, dass Sie Leistungen von externen Auftragnehmern erhalten - daher müssen Sie deren Arbeit prüfen, bevor Sie sie in Ihr Hauptprojekt einbinden.

2. Der Mythos der Einsatzbereitschaft im Realleben

Ich habe einen Freund, mit dem ich meine Softwareprojekte nur ungern teile. Egal wie sorgfältig ich meinen Code entwerfe und teste - sobald ich ihn ihm zur Ausführung gebe, funktioniert er nicht mehr.

Das liegt daran, dass er den Code ohne mein Wissen verwendet. Ich weiß, was mein Code tun sollte - ich weiß, wie das Programm funktionieren sollte. Ich schreibe den Code so, dass er genau das tut. Mein Freund hingegen hat dieses „innere Verständnis“ nicht. Er verwendet den Code einfach. Dabei versucht er immer wieder etwas, wovon ich nie gedacht hätte, dass jemand es tun würde. Dadurch funktioniert der Code nicht mehr.

Mein Kollege ist ein typisches Beispiel für die Anfälligkeit automatisierter Testsysteme. Klar, automatisierte Tests können dabei helfen herauszufinden, ob eine kürzlich vorgenommene Änderung etwas anderes kaputtgemacht hat. Doch da die Tests im Voraus geplant werden, wird man unweigerlich etwas übersehen - etwas, das jemand von außen, der nicht über das vollständige Wissen bezüglich der Spezifikationen des Projekts verfügt, zwangsläufig entdecken würde.

In gewisser Weise helfen KI’s dabei, die Rolle des untrainierten Freundes zu übernehmen. Man kann ihnen befehlen, verschiedene Tests durchzuführen, um zu prüfen, ob der Code dem Zugriff standhält. Doch wenn man von KI’s verlangt, eigene Tests zu entwickeln, sind sie ebenfalls durch die Perspektive begrenzt, die sie einnehmen oder die ihnen für das Projekt vorgegeben wird.

Die meisten Unit-Tests untersuchen sogenannte „Happy Paths“ - also die Abläufe, die Entwickler kennen und erwarten, dass der Code daraufhin handelt. Doch diese Unit-Tests übersehen oft Ausnahmefälle. Wenn KI Unit-Tests erstellt, übernimmt sie oft dieselben Schwachstellen wie von Menschen erstellte Tests.

Testumgebungen sind ebenfalls keine realen Umgebungen. Es gibt mehr als 20.000 Websites, auf denen meine Sicherheitssoftware läuft. Sie würden nicht glauben, welche Probleme Nutzer gemeldet haben. Die Probleme reichen von echten Fehlern bis hin dazu, dass Support-Mitarbeiter tagelang damit beschäftigt sind, nur um festzustellen, dass die Software nicht funktioniert - weil der Nutzer sie nie installiert hat.

Viele Coding-Manager stützen ihre Annahme bezüglich der Korrektheit auf Berichte von Diagnose- und Testsystemen. Gute Abdeckungs- und Leistungsmetriken aus Tests, bei denen der „Fluch des Wissens“ eine Rolle spielt, können jedoch problemlos reale Probleme verschleiern.

Das sind die wahren Kosten. Wenn Fehler erst während der Integration und Implementierung statt in der Entwicklungsphase entdeckt werden, kann die Komplexität sowie der Aufwand für die Fehlerbehebung erheblich zunehmen.

Um dieses Problem zu überwinden, sollte man wie ein Außenstehender testen. Man sollte adversarische Testmethoden anwenden. Bei der Erstellung von Testplänen müssen Szenarien mit Randfällen, Fehlerverläufen sowie Missbrauchsmöglichkeiten berücksichtigt werden. Man sollte Personen und/oder KI-Systeme damit beauftragen, den Code absichtlich falsch zu verwenden - ohne jegliche Anleitung - um so echte Nutzer ohne internes Kontextwissen zu simulieren. Zudem sollte man Mechanismen zur Erfassung unerwarteten Verhaltens integrieren. Der gesamte Code sollte so gestaltet sein, dass Fehler erkannt und korrigiert werden können.

Wenn Sie agentenbasiertes Codieren verwenden, beachten Sie, dass Ihr Projekt niemals abgeschlossen ist - es befindet sich lediglich in einem Zustand, der zum Testen ausreicht. Rechnen Sie damit, dass Fehler auftreten können. Integrieren Sie Korrekturprozesse in Ihre Managementstruktur sowie direkt in den Code selbst.

3. Der Mythos vom vererbten Code

Im Laufe meiner Jahre in der Softwarebranche - sowohl als Angestellter als auch als Geschäftsinhaber - war eine meiner Kernkompetenzen der Erwerb von Rechten an geistigem Eigentum im Softwarebereich.

Abgesehen von den beiden Apple-Apps, an denen ich gerade arbeite, wurden alle Produkte, die ich auf den Markt gebracht habe, ursprünglich von jemand anderem programmiert. Das hatte Vorteile: Die meisten Produkte verfügten bereits über eine bestehende Kundengruppe sowie ein fundiertes Verständnis für die Kernfunktionen der Anwendung.

Doch auch übernommene Produkte bringen Herausforderungen mit sich. Meist gibt es Gründe dafür, warum das Software-IP zum Kauf angeboten wird. In der Software kann es technische Probleme geben - also Stellen, an denen etwas nicht funktioniert. Marktveränderungen können die Wertigkeit der Software verringern. Außerdem kann es - und das war ein wichtiger Grund für meine Übernahmen - eine große Müdigkeit seitens der ursprünglichen Entwickler geben; sie wollen die Verantwortung für Wartung und Support nicht mehr tragen.

Normalerweise erbte ich „schwarze Kisten“ - also Systeme, deren Code von anderen Personen und Teams geschrieben worden war. Um den Code zu verbessern, zu warten und zu verhindern, dass er mir zum Problem wird, musste ich irgendwie Code übernehmen, in dem sich alle möglichen Geheimnisse verbargen. Das ist so ähnlich, als würde man ein Haus kaufen, ohne es vorher inspizieren zu lassen - nur um anschließend defekte Verkabelungen und kaputte Rohre in den Wänden zu entdecken.

So wird jede KI-Programmier-Erfahrung ablaufen. Per Definition wird der Code nicht von menschlichen Entwicklern geschrieben. Die KIs erstellen eine ganze „Black Box“. Man hofft einfach, dass sie funktioniert.

Geben Sie bei diesem Prozess nicht auf. Ich habe es zu meiner Berufung gemacht, Code zu liefern, den ich zu Beginn nicht vollständig verstand. Anfangs musste ich mich auf meine Programmierungsteams verlassen, damit diese das Problem lösten. Später, als ich als alleinstehender Entwickler arbeitete, lernte ich systematisch Teile des Codes kennen - Funktion für Funktion - meist getrieben vom Wunsch, eine neue Funktion hinzuzufügen oder ein vom Kunden gemeldetes Problem zu beheben.

4. Der Mythos der Wartungsschulden

Da die KI kein Mensch ist, werden Designentscheidungen und Code-Strukturen nicht unter Berücksichtigung menschlicher Bedürfnisse erstellt. Bei Auftreten von Problemen besteht das Debugging aus einer Kombination aus Reverse Engineering der Arbeitsweise der KI sowie dem Überreden der KI, etwas zu korrigieren, was sie anfangs vielleicht nicht vollständig verstanden hat.

Code, der von einer KI erstellt wird, weist oft keine einheitliche Absicht, Struktur oder architektonische Kohärenz auf. Dies führt zu einer instabilen Grundlage - alles, was darauf aufbaut, wird zu einem Zusammenspiel disparater Elemente. Ebenso können Benennungskonventionen und Muster bei von KIs generierten Komponenten stark variieren. Die Folge ist, dass Änderungen und Updates zu unerwarteten Fehlern in nur lose miteinander verbundenen Bereichen führen.

Nach ein paar Tagen der Zusammenarbeit mit Claude an einer neuen iPhone-App beschloss ich, mir die Dateistruktur anzusehen. Sie war völlig unlogisch. Die KI hatte beschlossen, die Dateien überall dort abzulegen, wo es ihr gefiel. Sie benannte die Dateien nach Belieben. Was die Struktur betrifft: Es gab keine Gruppierung der Dateien - alles war ein riesiger Haufen von Dateien in einem einzigen Hauptverzeichnis.

Es muss nicht so sein. Ich wies die KI an, hinter sich aufzuräumen - und das hat sie getan. Es bedurfte einiger Versuche, um ein sinnvolles Dateistruktur-Muster zu erstellen. Weitere Versuche waren nötig, um dieses Vorgehen in die Startanweisungen zu integrieren. Das Denken wie ein Manager half mir dabei, meinen „digitalen Untergebenen“ unter Kontrolle zu bringen.

Ebenso gibt es Situationen, in denen sorgfältige Code-Reviews einem sehr weiterhelfen können. Mein Rat für das Zeitalter des agentenbasierten Codings, in das wir eintreten, ist, mehrere agentenbasierte KI-Systeme zu verwenden, die auf verschiedenen großen Sprachmodellen basieren. Nicht mehrere Agenten - sondern mehrere KI-Systeme. Lassen Sie ein Modell die Arbeit des anderen Modells überprüfen. Ein Modell soll dabei der „Ersteller“ sein; das andere Modell der „Bewerter“.

Dieser Ansatz wird nicht alle Probleme lösen. Ich habe Claude Code und OpenAI’s Codex genutzt, um die Arbeit des jeweils anderen zu überprüfen. Ich bin ziemlich zufrieden damit, wie sie - bei sorgfältiger Koordination meinerseits - einander ziemlich ehrlich gegenüberbleiben.

5. Der Mythos einer fehlerfreien Ausgabe

Wenn man darüber nachdenkt: Sobald man die Überprüfung auf Anfälligkeit mit der technischen Schuldenlast kombiniert, entstehen unweigerlich Sicherheitsblindstellen. Schlecht geschriebener Code mit inhärenten Fehlerquellen ist eine Rezeptur für ein perfektes Unwetter an Sicherheitsproblemen.

In gewisser Weise ist die Situation bei KI sogar noch schlimmer. KI-Programmiermodelle wurden mit Informationen trainiert, die im öffentlichen Internet verfügbar sind. Darunter befinden sich eine enorme Menge an fehlerhaftem Code sowie schlechten Ratschlägen. Programmierer posten im Internet bereits länger als jede andere Berufsgruppe - daher ist der Umfang und die Vielfalt dieses Wissensspeichers wohl größer als bei nahezu jedem anderen Themenbereich.

Da der größte Teil des Open-Source-Codes auf GitHub veröffentlicht wurde, stand auch die zugrundeliegende Software, auf der die meisten Menschen weltweit arbeiten, den Modellen zum Training zur Verfügung. Das Problem? Dieser Code funktioniert nicht immer - er weist häufig Fehler und Sicherheitslücken auf. Manchmal wurde er nur oberflächlich von einem einzelnen Entwickler getestet. Zudem enthalten die Codekommentare oft Fehler - sehr viele Fehler.

Modelle können daher durchaus unsichere Codierungsmuster reproduzieren, die sie aus öffentlich verfügbaren Daten gelernt haben. Lücken bei der Eingabevalidierung und -bereinigung ermöglichen subtile Angriffsvektoren. Ich war schockiert zu entdecken, dass die KI, die ich für die Entwicklung meines Sicherheitsprodukts verwendete, keinerlei Eingabeverifikation durchführte und sämtliche Best Practices völlig ignorierte. Nachdem ich meine Annahmen überarbeitet und der KI befohlen hatte, Eingaben ordnungsgemäß zu prüfen, waren die Validierungsroutinen besser als alles, was ich selbst hätte schreiben können. Doch ich musste der KI sorgfältig beibringen, wie sie für Sicherheit sorgen kann.

KI-Systeme beinhalten vermutlich auch Bibliotheken, die für das jeweilige Problem geeignet erscheinen - ohne dass dabei die Lieferkette auf potenzielle Schwachstellen oder Probleme überprüft wird. Da KIs Code viel schneller generieren, als wir Menschen ihn überprüfen können, besteht eine hohe Wahrscheinlichkeit, dass Fehler entstehen, die wir in der Realität einfach nicht erkennen können.

Dazu kommen die rasant wachsenden Mengen an Code, die durch Code-Generierung entstehen - ein Prozess, der nun Stunden statt Monate dauert. Das ergibt eine riesige „Zeitbombe“ aus ungeprüftem und potenziell unsicherem Code.

Denken Sie daran, dass von Menschen geschriebener Code ebenfalls ein Sicherheitsproblem darstellen kann. KI kann manchmal dabei helfen, dieses Problem zu beheben.

Mein Hosting-Anbieter teilte mir kürzlich mit, dass der Open-Source-Spam-Blocker, den ich verwendete, eine schwerwiegende Sicherheitslücke aufwies. Der Autor war nicht erreichbar, um Korrekturen vorzunehmen. Ich ließ meine KI den Code untersuchen, die Schwachstellen identifizieren und ein neues Code-Modul erstellen, das diese Schwachstellen nicht enthielt.

Durch den Einsatz einer separaten KI, die den Code der ersten KI überprüfte, wurden noch einige Fehler entdeckt, die behoben werden mussten. Diese Fehler ließ ich anschließend von der ersten KI beheben. Wir wiederholten diesen Prozess, bis keine Fehler mehr auftauchten. Es sind mittlerweile Monate vergangen, seit ich den neuen Code auf meinem Server installiert habe. In dieser Zeit hat der Hosting-Anbieter die neue Implementierung nicht als problematisch eingestuft.

Denken Sie wie ein Generalunternehmer, nicht wie ein Handwerker.

Vielleicht weil ich den größten Teil meiner Software-Karriere damit verbracht habe, an Code zu arbeiten, der durch IP-Übernahmen erworben wurde oder von Auftragnehmern sowie Mitarbeitern erstellt wurde, mache ich mir keine großen Sorgen darüber, dass von KI geschriebener Code ein großes „Black Box“-Phänomen ist. Man muss lediglich andere Fähigkeiten einsetzen.

In zahlreichen warnenden Artikeln zum Thema „Vibe Coding“ wird darauf hingewiesen, dass zwar die Phase des Code-Schreibens im Software-Lebenszyklus stark verkürzt wurde, die Phasen der Fehlerbehebung und Wartung jedoch ausgeweitet wurden, um das Chaos zu beheben, das KI-Systeme in ihrem Code verursachen - oft erst nachdem dieser an die Nutzer ausgeliefert wurde.

Diese Sorge hat durchaus Berechtigung - doch es unterscheidet sich im Grunde nicht davon, mit bereits vorhandenem Code oder von Auftragnehmern geschriebenem Code zu arbeiten. Projektleiter beschäftigen sich seit Jahrzehnten mit diesen Problemen. Gute Praktiken im Software-Engineering, in der Planung und im Projektmanagement dienen dazu, das Problem der mangelnden Transparenz seitens der Auftragnehmer zu überwinden. Dafür sind jedoch Disziplin, Schulung und Erfahrung erforderlich.

All das beruht auf der Prämisse, dass KI kein Wundermittel ist. Man kann niemals einfach einen einzeiligen Prompt eingeben und dadurch ein Produkt im Wert von einer Million Dollar erschaffen. Man muss dafür arbeiten. Man kann die Time-to-Market verkürzen. Man kann KI nutzen, um bei der Wartung zu helfen. Man kann KI nutzen, um Sicherheitslücken zu erkennen und zu beheben. Und man kann auch Spaß mit KI haben.

Denken Sie einfach daran: Die KI ist ein Werkzeug - Sie sind der Profi. Sie müssen die Arbeit managen, Aufgaben gezielt delegieren und fleißig testen. Wenn Sie das tun, werden Sie vermutlich eine „Apokalypse der Vibe-Coding“-Situation vermeiden können und solide Ergebnisse erzielen.

Was halten Sie von agentenbasierten KI-Systemen in der Softwareentwicklung? Teilen Sie uns Ihre Meinung in den Kommentaren unten mit.

Sie können meine täglichen Projektupdates in den sozialen Medien verfolgen. Abonnieren Sie unbedingt meinen wöchentlichen Newsletter und folgen Sie mir auf Twitter/X unter @DavidGewirtz, auf Facebook unter Facebook.com/DavidGewirtz, auf Instagram unter Instagram.com/DavidGewirtz, auf Bluesky unter @DavidGewirtz.com sowie auf YouTube unter YouTube.com/DavidGewirtzTV.