Wie Entwickler sich mit KI versündigen

>Im nächtlichen Schein der IDE suhlt sich mancher Dev im KI-Sündenpfuhl.Kateryna Reka | shutterstock.com



Die Normen der Softwareentwicklung sind weiterhin gültig. Zumindest offiziell sind robuste CI/CD-Pipelines, elegante Architekturmuster und wartbarer Code nach wie vor gesetzt.



Wenn wir unbeobachtet sind, zeigt sich dann in vielen Fällen die Realität: Wir hängen wie entrückte Magier mit manischem Glanz in den Augen über unseren Konsolen und beschwören Modelle und Agenten, um uns voll und ganz dem KI-Rausch hinzugeben.



Dabei begehen wir nicht selten Development-Sünden, die Fred Brooks die Schamesröte ins Gesicht getrieben hätten. So wie die folgenden sieben. Vorsicht, Ironie – stellenweise.



1. Grundlagenwissen für überflüssig halten



Objektorientierte oder funktionale Programmierung? CAP-Theorem? DRY-Prinzip? Design-Pattern? Können Sie vergessen. Ebenso Frameworks, Runtimes und Deployment-Plattformen.



Die KI weiß schließlich ganz genau, was bereits vorhanden ist und welche Tools zu nutzen sind. So haben wir als Entwickler auch mehr mentale Bandbreite, um uns Nebenprojekten zu widmen. Zum Beispiel einem Roman über die KI-Weltherrschaft.



2. Dokumentationen links liegen lassen



„RTFM“ nutzen viele Developer auch heutzutage noch gerne – auch wenn sie selbst eigentlich seit 2023 keine einzige Seite einer Anbieter-Dokumentation mehr gelesen haben. Löst ein Package eine bizarre Exception aus, wird weder der Execution-Pfad überprüft noch erfolgt ein Blick in die Release Notes. Stattdessen werden alle 200 Zeilen des Stack-Trace kopiert und in eine KI geworfen – in der Erwartung, dass diese uns dann löffelweise mit der Lösung füttert.



Oder es wird direkt eine ADE auf den Fehler angesetzt. Die findet den Fehler und fragt uns dann nur noch, ob die Lösung so korrekt ist. Manche werfen dann eventuell einen Blick auf die Beschreibung dieser Lösung – insofern sie die KI nicht vorher schon auf „Auto-Confirm“ umgestellt haben.



So werden wir zu glorifizierten Copy-Paste-Orchestratoren – die einfach nur darauf hoffen, dass der stochastische Papagei hinter dem Prompt die Syntax richtig errät.



3. Backend-Struktur ignorieren



KI-berauschte Devs geben manchmal vor, Datenflüsse akribisch designt, relationale Einschränkungen sorgfältig ausgearbeitet und API-Beziehungsgeflechte gewissenhaft abgebildet zu haben. Auch wenn wir eigentlich nur die KI angewiesen haben, ein modernes Deployment-Gerüst zu bauen und dieses mit einer Backend-Datenbank zu verknüpfen.   



Dabei wurden Security-Regeln und Schemata erstellt, die wir unter Umständen nicht vollständig verstehen. Aber solange es funktional aussieht, wird es schon gut gehen. Eventuell wurden auch Infrastructure-as-Code-Skripte generiert, die Cloud-Ressourcen bereitstellen. Sicher wird sich jemand anderes darum kümmern, dass das kein Loch ins Budget frisst. Wahrscheinlich, indem er die Metriken in einen anderen Chatbot einspeist.



Ist aber auch egal, weil das Mittagessen wartet.



4. Inzestuöses Testing fördern



Test-driven Development war immer schon ein schöner Traum, der – wenn man ihn lebt – in Dependency-Wildwuchs ausarten kann. Es ist also eine super Sache, dass wir heutzutage mit KI fast mühelos eine Testabdeckung von 95 Prozent erreichen können. Warum sollten wir die Maschine das nicht direkt mit übernehmen lassen, wenn sie auch alles andere automatisiert erstellt?



So kann man auch jedem der es wissen will (oder der gerade keine Fluchtmöglichkeit hat), das Narrativ von der erstaunlichen Testabdeckung unter die Nase reiben und sich in ausgiebigen Schwärmereien über die automatisierte Qualitätssicherung ergehen. Was dabei geflissentlich verschwiegen wird: Die komplexe Anwendungslogik und die Testsuite wurden von derselben KI generiert. Diese validiert also genau den Code, den sie zuvor zusammengeschustert hat.



Daraus entsteht ein hermetisch abgeriegelter Kreislauf der algorithmischen Selbstbeweihräucherung: Die Mocks, Randfälle und Assertions werden zur Echokammer für die ursprünglichen Annahmen des KI-Modells. Die Maschine benotet also ihre eigenen Hausaufgaben und gibt sich dafür eine Eins mit Sternchen.



Das wird von einigen von uns allerdings gerne in Kauf genommen, denn wenn der Code verändert werden muss, zaubert die KI auch dafür mühelos neue Tests aus dem Hut.



5. KI-Ergebnisse als Strategie ausgeben



Dokumente zu designen, kann KI erstaunlich gut: Diese sind meist apart formatiert, wirken schlüssig und schlagen nahtlos die Brücke zwischen übergeordneten Geschäftszielen und detaillierten technischen Specs. Und: Sie enthalten auch die tollen Sequenz-Diagramme, die das Management so schätzt.



Architekturvorschläge, die auf diese Art und Weise entstanden sind, werden regelmäßig in Sprint-Planungs-Meetings präsentiert – und kommen beim Rest des Teams oft gut an. Schließlich weiß auch niemand, dass in den hochgelobten Vorschlag ungefähr vier Sekunden „Mühe“ investiert wurden.



Ignoriert wird dabei, dass solche KI-generierten Dokumente gleichermaßen anfällig für fatale Mängel in Bezug auf Scope und Alignment sind, wie von Menschenhand gemachte. Aber wenn das Projekt schon scheitert, war wenigstens das Markdown schön klar und die Bulletpoints echt überzeugend. Das wahre Ausmaß des folgenden Desasters wird zwar erst erkannt, wenn es schon viel zu spät ist – aber immerhin war der Ansatz visionär.



6. Heimlich dem Vibe Coding verfallen



Vibe Coding ist unter Devs in sozialen Kanälen regelmäßig eine Lachnummer. Und auch in Slack-Channels werden regelmäßige augenrollende Emojis verschickt, wenn es um das Thema geht. Nach außen möchten wir alle möglichst professionell wirken.



Wenn niemand zusieht, wird dann unter Umständen aber doch der heimlichen Vibe-Coding-Leidenschaft gefröhnt: Unausgereifte Gedanken und ein Drink, sind alles was man braucht, um entspannt dabei zusehen zu können, wie die KI ihre “Coding-Magie” entfaltet.



Daraus entsteht dann vielleicht endlich ein funktionierender Ultima-V-Klon oder eine App, um Krypto-Protfolios zu tracken, die nach dem Interface aus „Neuromancer“ aussieht. Und zwar in 30 Sekunden. Das berauscht. Und kann süchtig machen. Leider ganz besonders, wenn man tief in der harten, altmodischen Realität des Programmierhandwerks verwurzelt ist.



7. Prompts als Allheilmittel betrachten



Ahnlich wie die Figur von Adam Sandler in „Der schwarze Diamant“ sind manche Devs davon überzeugt, dass mit der nächsten Runde alles besser wird – nur bezogen auf Prompts. Wenn die Dinge aus dem Ruder laufen, bevorzugen diese regelmäßig, den KI-Prompt zu verfeinern – statt sich selbst dem Komplexitätsdickicht zu widmen.



Der gleiche fehlerbehaftete Stack Trace wird dann unerbittlich immer und immer wieder in den Chat gehämmert, das Modell auf einen immer schmaleren Pfad gezwungen – solange, bis der Code endlich keine Fehler mehr ausgibt. Debugging und Variablen-Tracing sind so gut wie nicht mehr existent, Funktionen werden nicht mehr schrittweise geprüft. Stattdessen wird unermüdlich iterativer Druck auf die KI ausgeübt, bis diese kapituliert. Und dann geht’s ab in die Produktion.



So fließt am Ende ähnlich viel Zeit und Energie in den Kampf mit dem Bot, wie früher in die manuelle Syntaxerstellung. (fm)



Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.