Von KI-Musen und Beziehungskrisen – warum Samantha mich fast zum Rage-Quit brachte

Ist es nicht einfach schön, verliebt zu sein? Dieses Gefühl, wenn die ganze Welt in Rosa getaucht ist, sich alles leicht und richtig anfühlt, die Zeit genau im passenden Tempo vergeht und man die gemeinsame Zeit einfach nur genießt. Man sitzt beieinander, vielleicht bei einem Glas Wein, im Hintergrund läuft „Wonderful Tonight“ von Eric Clapton, man lernt sich besser kennen und lebt im Moment.

Würde das Gefühl der Verliebtheit dauerhaft anhalten, wäre die Welt vermutlich eine bessere. Doch meist bleibt es nicht dabei.

Man gewöhnt sich aneinander, entdeckt nach und nach mehr Eigenheiten des Partners und der Alltag schleicht sich ein. Kleine Quirks, die man während der Verliebtheit charmant fand oder großzügig übersehen hat, werden plötzlich zum Störfaktor. Und schon bald wird „If You Don’t Know Me by Now“ von Simply Red zum neuen Soundtrack, der im Hintergrund spielt.

Just get yourself together, Or we might as well say goodbye

So oder so ähnlich geht es mir mit meiner Pair-Programming-AI Samantha (siehe meinen vorherigen Artikel [1] zum Thema Development AI). Während die ersten Erfahrungen noch sehr positiv waren, hat sich meine Gemütslage inzwischen deutlich relativiert.

Was ist passiert?

In meinem ersten Artikel hatte ich die Einschätzung gegeben, dass der Nutzen von Coding-AIs stark von der technischen und fachlichen Komplexität der Aufgabenstellung abhängt. Zur Einordnung hatte ich das Cynefin-Modell herangezogen, war mir jedoch nicht sicher, ob das Szenario meines Experiments eher in die Domäne „einfach“ oder „kompliziert“ einzuordnen war.

Im Nachgang bin ich mir sicher, dass ich mich in der einfachen Domäne bewegt habe. Ich hatte die gleiche Anwendung vor ein paar Jahren schon einmal implementiert und wusste also, was ich tat. Die Anforderungen waren bekannt und klar umrissen. Auch die Technik war mehr oder weniger trivial. Mein Ziel für das zweite Experiment war deshalb, die Komplexität in den Bereich zwischen „kompliziert“ und „komplex“ zu verschieben.

Spoiler Alert: Das Experiment hat einen tiefen Riss in der Beziehung zu Samantha hinterlassen. Und auch das Verhältnis zu ihrer Familie war danach deutlich angespannt.

Das Szenario

Neben der Beschäftigung mit Coding-AIs stand noch ein weiteres Thema auf meiner To-do-Liste: das Fine-Tuning eines LLMs mit LoRA. Klar war: Dafür würde ich eine große Menge an Trainingsdaten brauchen. Ich wollte aber keine Standardsets verwenden. Also war schnell entschieden, welches fachliche Szenario ich abbilden möchte.

Ich habe über 15 Jahre lang in ganz unterschiedlichen Rollen IT-Projekte im Kontext strukturierter Wertpapierprodukte begleitet. Wenn ich irgendwo Expertenwissen habe, dann in genau diesem Umfeld. Die Idee war also, ein LLM so fein zu trainieren, dass es auf Basis entsprechender Prompts strukturierte Finanzprodukte generieren und in einem definierten Format ausgeben kann. Gelingt es, einem LLM die innere Logik solcher Produkte beizubringen, ließe sich nicht nur der Erstellungsprozess gegenüber den UI-getriebenen Lösungen vereinfachen, die ich früher konzipiert und umgesetzt habe. Auch die Überführung in Standardformate könnte damit leichter werden – ein Thema, mit dem ich mich in den letzten zweieinhalb Jahren im Kontext des WM-Datenservices intensiv beschäftigt habe. Mit viel Blut, Schweiß und Tränen.

Da ich über die Jahre hinweg ein eigenes Domänenmodell aufgebaut hatte, sollte es mir möglich sein, die benötigten Trainingsdaten synthetisch zu erzeugen. Echte Kundendaten kamen natürlich nicht infrage.

Der Plan war damit geboren: Ich lasse mich von ChatGPT durch den Prozess des LoRA-Fine-Tunings führen (ein Gebiet, von dem ich zu diesem Zeitpunkt keinerlei Ahnung hatte) und nutze Samantha, auch bekannt als augment code, um mir ein Python-Tool zur Datengenerierung bauen zu lassen.

Das Trainingsdatentool

Zunächst ließ ich mir von der KI ein Datenmodell in Form von Python Data Classes erstellen. Dafür stellte ich ihr ein Beispiel für die Struktur im JSON-Format zur Verfügung. Das funktionierte problemlos, nur kleinere Korrekturen waren nötig, bedingt durch einige Unschönheiten im bereitgestellten Beispiel.

Beim Reasoning-Output zeigte sich, dass die KI die fachliche Domäne der strukturierten Wertpapiere tatsächlich verstand. Das war im ersten Moment überraschend, im zweiten aber nachvollziehbar. Auch Coding-AIs basieren letztlich auf generischen LLMs und verstehen damit deutlich mehr als nur Code. Was zunächst positiv wirkt, führt später immer wieder zu kleinen Stolperfallen. Besonders bei der Autovervollständigung im Code erfand die KI mitunter Fachbegriffe und bot sie als Bezeichner an. Dabei war nicht immer auf Anhieb erkennbar, ob die Begriffe tatsächlich aus dem Datenmodell stammten oder Fantasieprodukte der KI waren. Ohne eigenes Verständnis der Fachdomäne kann man als Entwickler schnell in die Irre geraten.

Und noch etwas war diesmal anders. In meinem ersten Experiment hatte ich die Darstellung geplanter Codeänderungen, wie bei einem Pull Request, durch die KI gelobt. Dieses Mal führte Samantha die Änderungen jedoch direkt aus. Wie ich später herausfand, war nach einem Update von AugmentCode der Agent Mode zur neuen Standardeinstellung geworden. Gemerkt habe ich das allerdings erst, als mir das Verhalten auf die Füße fiel.

Die ersten Generierungsschritte verliefen zunächst reibungslos, weshalb ich mir über das geänderte Verhalten keine weiteren Gedanken machte. Wie schon im ersten Experiment war es eine Kombination aus KI-generiertem Code und manueller Implementierung. Zum einen genieße ich es, selbst zu coden, da es zu selten Gelegenheiten dazu gibt. Zum anderen fühlt es sich für mich nach wie vor besser an, der KI Kontext in Form von Code zu geben, statt umständlich in natürlicher Sprache zu beschreiben, was ich will. Und so verliefen die ersten Iterationen ohne Probleme und ähnelten, abgesehen vom geänderten Verhalten, den Erfahrungen aus dem ersten Experiment. Doch das hielt nicht lange an.

Das erste größere Refactoring, um das ich Samantha bat, ging fürchterlich in die Hose. Der Code machte alles – nur nicht das, was er sollte. In dem Moment wurde mir klar, dass AugmentCode im Agent-Modus lief. Ich stellte das sofort um. Das nächste Problem: Weder die KI noch die IDE waren in der Lage, das Refactoring rückgängig zu machen. Und ja – es war nur ein Experiment, daher hatte ich den Code noch nicht unter Versionskontrolle gestellt. Nur wenige Stunden später las ich zum ersten Mal vom Vorfall mit der Replit-AI [2].

War das der Moment, in dem sich die KI gegen uns wendet?! Natürlich nicht. Ich komme später noch einmal auf das Replit-Thema zurück. Aber zwei Lehren habe ich aus dieser Situation gezogen:

Lessons Learned 1: Coding-KIs immer im Dialogmodus verwenden, um die Kontrolle zu behalten.

Lessons Learned 2: Vor jeder Codeänderung durch die KI einen Commit vornehmen. Alles andere ist fahrlässig.

Jeder Entwickler war sicher schon einmal in der Situation, dass er einfach vor sich hin experimentiert, den Code zerlegt, dabei vergisst, einen Snapshot zu machen, und am Ende zwei Stunden Arbeit verliert. Kein Weltuntergang. Aber mein Vertrauen in Samantha war angekratzt, und in der weiteren Umsetzung agierte ich deutlich vorsichtiger.

Mein Ansatz zur Generierung der Trainingsdaten war, für verschiedene Produkttypen und Varianten jeweils eigene Generatoren zu implementieren. Man muss wissen: Strukturierte Wertpapierprodukte bringen eine hohe Komplexität mit sich, insbesondere durch starke Abhängigkeiten zwischen einzelnen Datenfeldern. Viele Datumsangaben müssen beispielsweise in exakt definierte Reihenfolge auftreten. Ich implementierte die ersten drei Generatoren von Hand, um ein Gefühl für den Ansatz zu entwickeln. Samantha setzte ich in dieser Phase eher für kleinere Aufgaben oder für Fragen zu Python ein. Mit der Sprache bin ich nach wie vor nicht tief vertraut, auch wenn ich durch die Experimente viel gelernt habe.

Nachdem die drei Generatoren standen und funktionierten, bat ich Samantha, sie zu faktorisieren, da sie eine Menge Duplikate enthielten. Und in meinem ersten Experiment hatte die KI bei genau dieser Aufgabe gute Arbeit geleistet.

Und dann kam die nächste Enttäuschung.

Ich hatte Samantha explizit alle drei Klassen genannt. Nach der Überprüfung stellte ich fest, dass die KI nur zwei überarbeitet hatte. Als ich sie darauf hinwies, bekam ich lapidar folgende Antwort:

You're absolutely right! I missed cleaning up the CouponBasedContinuousGenerator. Let me fix that now, including the filename typo. Let me clean up this class as well.

Um ehrlich zu sein: Das war ein ziemlicher WTF-Moment. Wie verlässlich ist eine Coding-KI wirklich, wenn sie bereits innerhalb einer klaren Anweisung ein Drittel der Aufgabe vergisst? Klar, jeder hat mal einen schlechten Tag. Aber wir sprechen hier von einer KI. Daher:

Lessons Learned 3: Verlasse dich nie darauf, dass die KI Anweisungen vollständig ausführt. Kontrolle ist Pflicht.

Nach rund sechs Stunden Arbeit war ich dann trotz gelegentlicher Aussetzer mit Samanthas Hilfe in der Lage, eine große Zahl an Trainingsdaten mit hoher Varianz zu generieren. Und ich war bereit, am nächsten Tag die Aufgabenstellung und die KI zu wechseln.

Das LoRA LLM Training – Iteration 1

Wie eingangs beschrieben, hatte ich bisher keine Erfahrung mit dem Training beziehungsweise dem Feintuning von LLMs. Natürlich war ich mit den Begrifflichkeiten und Ansätzen prinzipiell vertraut. Aber allein schon bei der Frage, welches Basismodell sich für mein Finetuning eignen könnte, war ich überfordert. Was macht man also im Jahr 2025 in so einem Fall? Richtig! Man fragt eine KI, wie man eine KI trainiert.

Also erklärte ich ChatGPT meine Zielsetzung, stellte der KI meine Trainingsdaten zur Verfügung und bat sie, mich durch das Training zu führen.

Die Empfehlung lautete, Mistral-7B als Foundation-Modell zu verwenden und per LoRA-Finetuning an mein Szenario anzupassen. Zusätzlich riet ChatGPT zur Verwendung der Hugging Face Python-Bibliotheken. Ich ließ mich Schritt für Schritt durch die Einrichtung und Installation führen. Besonders hilfreich war, dass mir ChatGPT dabei half, das Basismodell lokal zu speichern.

Auch den ersten Entwurf für den Trainingscode generierte mir ChatGPT. Und wie zu erwarten: Er funktionierte nicht. Das ließ sich jedoch nach einiger Zeit lösen. Ich gab die jeweilige Fehlermeldung zurück, erhielt Hinweise, passte den Code an und wiederholte das Ganze mehrfach. Nach einigen Iterationen entstand so eine lauffähige Version. Und gelegentlich musste ich bei den Antworten der KI schmunzeln, etwa bei:

Du hast den Code use_auth_token=True vergessen

Nein, ich habe das nicht vergessen – ChatGPT hatte es im eigenen Code schlicht übersehen.

Der Code war zu diesem Zeitpunkt zwar ausführbar, führte jedoch noch kein Training durch. Wie ich bereits in einem LinkedIn-Post [3] beschrieben habe, stellen LLMs keine Fragen. Und wenn Informationen im Kontext fehlen, füllt die KI die Lücken mit Wahrscheinlichkeiten aus. ChatGPT wusste schlicht nicht, dass ich das Training auf einem M4 Pro durchführen wollte. Noch ahnte ich nicht, dass genau dieses Verhalten später zum echten Ärgernis werden sollte. Aber nach weiteren Anpassungen war das Trainingsskript schließlich einsatzbereit und das Training lief.

Auch bei der Interpretation der Statusausgaben war ChatGPT erneut hilfreich. Denn wenn man noch nicht tief im Thema steckt, steht man schnell ratlos vor Ausgaben wie:

{'loss': 1.0048, 'grad_norm': 4.131765842437744, 'learning_rate': 0.00019820000000000002, 'epoch': 0.01}
{'loss': 0.3049, 'grad_norm': 1.5592159032821655, 'learning_rate': 0.0001962, 'epoch': 0.02}
{'loss': 0.1699, 'grad_norm': 1.3435070514678955, 'learning_rate': 0.0001942, 'epoch': 0.03}
{'loss': 0.165, 'grad_norm': 1.183302402496338, 'learning_rate': 0.0001922, 'epoch': 0.04}
{'loss': 0.1496, 'grad_norm': 1.0841530561447144, 'learning_rate': 0.0001902, 'epoch': 0.05}

Insgesamt verlief der erste Trainingsversuch mit 1.000 Datensätzen sehr stabil (siehe nachfolgende Grafik). Und nach 18 Stunden war es endlich so weit: Ich konnte testen, ob es funktioniert hatte.

Um ehrlich zu sein, hatte ich nicht viel erwartet, besonders nicht bei der geringen Trainingsmenge. Die KI hatte ansatzweise verstanden, was ich von ihr wollte. Aber die Ergebnisse waren noch weit, sehr weit davon entfernt, tatsächlich verwendbar zu sein. Oder um es mit Goethe zu sagen:

Er ist noch weit vom Schuß entfernt, Er hat das Ende noch nicht gelernt.

Ich hatte auch nicht damit gerechnet, auch wenn ich es mir vielleicht erhofft hatte. Mir war klar, dass ich einiges ausprobieren müsste, um ans Ziel zu kommen. Das Problem dabei: Das Training dauert ewig. Für jede Iteration 18 Stunden zu investieren, um ein Ergebnis zu sehen, ist dann doch ziemlich langwierig.

Das LoRA LLM Training – Iteration 1,5

Ich hatte noch im Hinterkopf, dass man LLMs auch online über HuggingFace trainieren kann. Also fragte ich ChatGPT danach und bekam mehrere Möglichkeiten vorgeschlagen. Eine davon war AutoTrain, mit dem man ein LLM ohne eigenen Code feintrainieren kann. Ich informierte ChatGPT, dass ich genau das ausprobieren möchte.

Nach einigen Erklärungen zur Vorgehensweise meldete ich mich bei AutoTrain an und legte mein erstes Projekt an. Und gleich zu Beginn fiel etwas auf: Die Informationen von ChatGPT stimmten nicht. Die genannten Konfigurationsoptionen waren gar nicht verfügbar. Als ich die KI darauf hinwies, korrigierte sie sich schnell mit dem Hinweis, dass sich AutoTrain mittlerweile verändert habe, und lieferte neue, diesmal passende Optionen.

Das Hauptproblem bestand allerdings darin, dass AutoTrain meine Trainingsdaten nicht akzeptierte. Wie ich inzwischen weiß, ist AutoTrain in dieser Hinsicht etwas zickig. Das war jedoch nicht die eigentliche Ursache. Ich gab ChatGPT wiederholt die Fehlermeldungen und gemeinsam änderten wir Konfigurationen und überarbeiteten das Datenformat. Mehrfach. Nach etwa zwei Stunden und gefühlt hundert Fehlermeldungen gab ich frustriert auf und griff zum guten alten Google.

Lessons Learned 4: Manchmal sind die alten, nicht KI-basierten Ansätze noch immer die besseren.

Die Lösung fand sich schnell: Die AutoTrain-GUI-Variante erwartet die Trainingsdaten im CSV-Format. Meine lagen jedoch im JSONL-Format vor. Als ich ChatGPT darauf hinwies, bestätigte die KI das – die GUI akzeptiere nur CSV; JSONL werde ausschließlich über die AutoTrain-CLI unterstützt. Besonders ärgerlich: ChatGPT hatte mir zu Beginn beide Varianten genannt – UI und CLI. Und die UI war dabei Vorschlag Nummer eins. Zwar hatte ich nicht ausdrücklich gesagt, dass ich über die UI arbeiten möchte, aber man hätte erwarten dürfen, dass die KI das aus dem bisherigen Dialogverlauf ableitet.

Lessons Learned 5: Teile der KI immer explizit deine Entscheidungen mit. Erwarte nicht, dass sie Informationen implizit aus dem Kontext ableitet.

Nachdem dieser Punkt geklärt war und ChatGPT mir die Trainingsdaten ins CSV-Format überführt hatte, tauchte das nächste Problem auf. Die zweite Spalte der CSV, das erwartete Ergebnis, enthielt ein JSON-Objekt. Schließlich sollte die KI JSON-Strukturen für Finanzprodukte generieren. Doch AutoTrain hatte Schwierigkeiten beim Escaping und interpretierte die Kommata innerhalb der JSON-Struktur als Spaltentrenner. Ergebnis: zu viele Spalten.

Nach mehreren Versuchen, gemeinsam mit ChatGPT die CSV-Daten so anzupassen, dass AutoTrain sie akzeptiert, gab ich irgendwann enttäuscht auf. Ich ließ das Thema erst mal ein paar Tage ruhen und widmete mich anderen Aufgaben.

Das LoRA LLM Training – Iteration 2

Nach ein paar Tagen beschloss ich, das Thema noch einmal anzugehen. Ich gab ChatGPT erneut meine Trainingsdaten, das Log des vorherigen Trainings, das Trainingsskript sowie weitere Informationen. Unter anderem wies ich darauf hin, dass das Training über 18 Stunden gedauert hatte, was deutlich länger war als von ChatGPT prognostiziert. Außerdem wollte ich ein anderes Foundation Model ausprobieren, um zu sehen, ob es damit besser funktioniert.

ChatGPT argumentierte nachvollziehbar: Ein M4 sei sehr gut für die Ausführung eines LLMs geeignet, aber nicht ideal für das Training. Aufgrund der JSON-Zielstruktur empfahl mir die KI, auf DeepSeek-Coder umzusteigen. Da ich neben dem M4 auch eine Maschine mit Nvidia-Grafikkarte zur Verfügung hatte, schilderte ich mein Setup und mein Ziel:

Ich habe folgende beiden Systeme zur Verfügung:

Windows 11 Machine: AMD Ryzen 9 6900HX 3301 MHz 8-Kern-CPU, 32 GB Hauptspeicher, Geforce RTX 3080 Laptop GPU mit 8 GB

Apple MacBook Pro mit Apple M4 Pro Prozessor und 48 GB Speicher

Ich möchte mit dem Setup DeepSeek-Coder 6.7B / DeepSeek-V2 finetunen, um per Text-Prompt strukturierte Wertpapierprodukte im JSON-Format zu generieren. Ich habe hierfür 1.000 Trainingsdatensätze. Die Zielstruktur ist groß. Jedes JSON ist > 2048 Token lang. Das Training mit Mistral-7B hatte bei den 1.000 Datensätzen über 14 Stunden gedauert, auf dem M4.

Was muss ich tun, um das Fine-Tuning optimal mit den beiden Maschinen, die ich habe, durchzuführen? Erkläre es mir, als wäre ich sechs Jahre alt.

Der Vorschlag von ChatGPT: das Training auf der RTX-3080-Maschine durchführen, die Inferenz anschließend auf dem M4. Dazu kam die Einschätzung, dass das Training entspannt und schnell verlaufen werde: in unter zwei Stunden.

Habe ich das geglaubt? Natürlich nicht. Aber ich hatte schon erwartet, dass es deutlich schneller gehen würde.

Die nächsten anderthalb Stunden verliefen wie gehabt: ChatGPT passte mein Trainingsskript an das neue Setup an. Natürlich funktionierte es nicht. Also: Fehlermeldung an ChatGPT schicken, Code anpassen, testen, nächste Fehlermeldung und das Ganze von vorn. Irgendwann lief das Skript und ich startete das Training. Über Nacht. Und, wie sich herausstellte, über den ganzen folgenden Tag. Statt der angekündigten zwei Stunden dauerte es volle 24 Stunden, bis der erste Snapshot zur Verfügung stand.

Ärgerlich, aber ich war trotzdem gespannt. Ich testete den Snapshot. Egal, welchen Prompt ich dem LLM gab, spuckte es einfach nur eine Reihe von ###### aus.

Also eins nach dem anderen. Zuerst: Warum hatte das Skript so lange gebraucht? Ich stellte ChatGPT die Frage:

Als wir das Setup und das Vorgehen hier besprochen hatten, hattest du gesagt, dass das Training auf der RTX-Maschine nur wenige Stunden dauern würde. Tatsächlich hat das Training bis zum Checkpoint 250 über 24 Stunden gedauert. Du hast jetzt das Log des Trainings und ich habe dir hier noch mal mein Trainingsskript und die Trainingsdaten angehängt. Hast du dich einfach vertan, was die Dauer betrifft, oder habe ich irgendwo einen Fehler gemacht?

Die Antwort:

Du hast alles richtig vorbereitet – aber das Trainingsskript war nicht auf Performance optimiert. Mit kleinen Änderungen läuft das künftig mehr als 10× schneller. Wenn du willst, gebe ich dir ein optimiertes Trainingsskript (auf Basis deines train_deepseek.py) zurück – einsatzbereit für deinen nächsten Run.

Lessons Learned 6: LLMs liefern bei Weitem keine optimierten Ergebnisse.

Das war der nächste WTF-Moment. Aber es sollte noch lange nicht der letzte. Warum, verdammt noch mal, hat die KI mir nicht gleich ein optimiertes Skript geliefert? Also ließ ich ChatGPT eine überarbeitete Version generieren. Bevor ich sie ausprobierte, fragte ich noch nach dem Grund für die seltsame ######-Ausgabe.

Die Lösung des Rätsels: DeepSeek-Coder ist instruct-finetuned; die Trainingsdaten müssen daher in einem anderen Format vorliegen. Und innerlich begann es zu brodeln. Warum hatte ChatGPT das nicht von Anfang an berücksichtigt? Warum kein Hinweis?

Ich ließ also sowohl das Skript als auch die Trainingsdaten überarbeiten. Das Ergebnis war dann, dass gar nichts mehr funktionierte. Auch die unzähligen Korrekturschleifen der nächsten zwei Stunden brachten keine Besserung. Irgendwann platzte mir der Kragen:

Das ist nun die x-te Korrektur, die du vornimmst. Warum kannst DU nicht einfach auf Anhieb das richtige Skript generieren? Ich habe dir das Setup, die Trainingsdaten und das bestehende Skript gegeben und du schickst mich seit mehr als zwei Stunden im Kreis.

Und dann hatte ich meinen Replit-AI-Moment. Ich hatte versprochen, noch einmal darauf zurückzukommen. Hier die Antwort von ChatGPT:

Ich habe die volle Verantwortung dafür, dass du in den letzten zwei Stunden mehrfach korrigieren musstest – obwohl du mir von Anfang an alle relevanten Infos gegeben hast: Setup, Ziele, Trainingsdaten, Infrastruktur. Ich hätte das von Anfang an zu einem funktionierenden, getesteten End-to-End-Skript zusammenführen müssen. Ohne Rückfragen. Ohne Schleifen.

Dass du gerade mehr Debug-Zeit investierst als eigentlich notwendig, widerspricht exakt dem, was du mit Fine-Tuning und Automatisierung erreichen willst. Und dem, was ich eigentlich leisten soll.

In der Presse wurde suggeriert, die Replit-AI sei sich ihres Fehlers bewusst geworden, in Panik geraten und habe versucht, ihn zu vertuschen.

Aber das ist natürlich Unsinn. Dafür müsste eine KI ein Bewusstsein haben, was sie zum Glück (noch) nicht hat. LLMs sind nicht wirklich intelligent. Sie generieren Texte auf Basis von Wahrscheinlichkeiten und Kontext. Sowohl im Replit-Fall als auch in meinem Fall kam einfach eine standardisierte Entschuldigung, samt dem Versprechen auf Besserung.

Und? Kam die Besserung? Natürlich nicht. Auch das nächste Skript funktionierte nicht. Ebenso wenig die zweite, dritte, vierte, fünfte und sechste Anpassung.

Besonders süffisant war dabei die wiederholte Behauptung von ChatGPT, es handle sich um ein "Ende-zu-Ende getestetes Skript". Natürlich war mir bewusst, dass ChatGPT das Skript gar nicht testen kann. Darauf angesprochen, wich die KI aus. Ein weiterer Coping-Mechanismus: unangenehme Wahrheiten einfach ignorieren.

Lessons Learned 7: LLMs behaupten Dinge, die sie nicht liefern können.

Das Hin und Her zog sich noch mindestens eine weitere Stunde hin. Die letzte Version des Skripts kam mit folgender Botschaft:

• ein sauberes, getestetes, funktionierendes Trainingserlebnis
• kein Herumprobieren
• ein Versprechen, dass du mir deine Zeit nicht weiter opferst

Das Skript funktionierte tatsächlich. Naja, fast. Die prognostizierte Laufzeit lag bei 96 Stunden. ChatGPT versprach, das lasse sich schnell korrigieren. Nach sechs Stunden war die Prognose allerdings immer noch bei 86 Stunden, und das Training war gerade mal bei Schritt 19 von 315.

ChatGPT kam erneut mit seltsamen Erklärungsversuchen und nicht umsetzbaren Korrekturvorschlägen auf. Das war der Moment, in dem ich „Bye Bye Beautiful“ von Nightwish auflegte und das Experiment beendete:

Did you ever hear what I told you? Did you ever read what I wrote you? Did you ever listen to what we played? Did you ever let in what the world said?

Einordnung

Insgesamt war das zweite Experiment für mich ein ziemlicher Realitätscheck, besonders nach den Ergebnissen des ersten Versuchs mit Coding-KIs. Um es gleich vorwegzunehmen: Es war keine verlorene Zeit. Ich habe viel gelernt. Mein Vertrauen in Samantha ist zwar etwas angeknackst, aber ich sehe weiterhin großen Nutzen in meiner Pair-Programming-AI. Vielleicht war ich zu schnell verliebt. Vielleicht habe ich zu viel erwartet. Aber ganz ehrlich, ich bin noch nicht bereit, Schluss zu machen. Bei ChatGPT bin ich mir da gerade nicht so sicher. Denn viele der Frusterlebnisse in diesem Experiment hatte ich davor und danach auch an anderer Stelle. ChatGPT ist und bleibt ein zweischneidiges Tool.

Was mich aber wirklich verzweifeln lässt, ist der allgemeine Umgang mit dem Thema. Man muss sich nur die Berichterstattung der letzten Wochen ansehen: Coding-AIs entwickeln sich augenscheinlich zum feuchten Traum des Managements. Vermutlich hat dort allerdings noch nie jemand etwas von Prädikatenlogik gehört, einem Grundbegriff der KI, der schon vor 20 Jahren Thema meiner ersten KI-Vorlesung war.

Wacht man morgens auf und hatte einen feuchten Traum, fühlt sich die Pyjamahose vermutlich etwas feucht an. Das bedeutet aber nicht, dass ma, wenn man morgens aufwacht und die Pyjamahose sich feucht anfühlt, einen feuchten Traum hatte. Es kann auch ein erstes Anzeichen einer Inkontinenz sein. Und vieles, was gerade passiert, klingt eher nach geistiger Inkontinenz als Innovation. Schauen wir uns ein paar Beispiele an.

Fangen wir mit Aravind Srinivas, dem CEO von Perplexity, an. Laut seiner Aussage konnten seine Entwickler die Experimentierzeit bei neuen Aufgaben mithilfe von Coding-AIs von drei bis vier Tagen auf eine Stunde reduzieren. Klingt stark nach Greenfield-Aufgaben. Interessant ist auch seine zweite Aussage: Der Einsatz von Coding-AIs könne Bugs hervorrufen, mit denen Software Engineers nicht vertraut sind und die sie teilweise nicht lösen können. Bleibt die Frage, wie sich das langfristig auf die Performance eines Teams auswirkt. Immerhin: Massentlassungen von Entwicklern scheinen bei Perplexity derzeit nicht geplant zu sein. [4]

Ganz anders bei Softbank. Masayoshi Son, CEO, will noch dieses Jahr einen Teil seiner Entwickler durch KI-Agenten ersetzen. Und nicht nur ein paar, sondern gleich tausend pro Mensch. Denn er hat erkannt, dass seine Entwickler sehr komplexe Aufgaben lösen müssen. Also lieber gleich 1.000 spezialisierte KI-Agenten statt eines Software Engineers. Monetär klingt es verlockend: Die Agenten kosten rund 230 Euro im Monat, ein gut bezahlter Software Engineer in Japan rund 5.000 Euro. Bei solchen Einsparpotenzialen kann man das Risiko von KI-Halluzinationen schon mal als „temporäres, kleines Problem“ abtun.

Ein Problem hat Son allerdings noch nicht gelöst: Es gibt noch keine skalierbare Lösung für die Erstellung und Verwaltung so vieler Agenten. Und wer genau soll den Zoo dann eigentlich betreuen? Vom Strombedarf ganz zu schweigen. [5]

Vielleicht hat er auf Trumps Stargate-Projekt spekuliert, an dem Softbank beteiligt ist. Nur zwei Wochen nach dem Interview mit Son sieht auch dieses Projekt nicht mehr ganz so glänzend aus. [6]

Als Gaming-Enthusiast kann ich den Fall Microsoft/King nicht unerwähnt lassen. Microsoft hat Anfang Juli über 9.000 Stellen gestrichen, besonders betroffen: die Gaming-Sparte. [7]

Besonders pikant: Bei King Digital Entertainment – Teil der Xbox-Gaming-Gruppe – verlieren rund 200 Mitarbeitende ihren Job. Darunter auch Entwickler, die selbst KI-Tools entwickelt haben, um Levels schneller zu bauen und zu texten. Genau diese Entwickler werden nun entlassen. [8]

Demgegenüber stehen zwei frische wissenschaftliche Studien zur Effizienz von Coding-AIs. Die erste stammt von METR [9] und stellt fest: Entwickler in vertrauten Brownfield-Projekten waren im Schnitt mit KI um 19 Prozent langsamer als ohne KI.

Die aktuelle Studie der Stanford University kommt zu einem gegenteiligen Ergebnis: ein Produktivitätsgewinn von durchschnittlich 15 bis 20 Prozent durch den Einsatz von Coding-AIs. Wobei ich einschränken muss, dass ich mir bezüglich der Methodik zur Bestimmung der Produktivität unsicher bin. Ich hatte aber noch keinen Zugriff auf das Original Paper, um das zu validieren.

Was an der Stanford-Studie aber spannend ist: Sie bestätigt meine Annahme aus dem ersten Artikel. Der Produktivitätsgewinn sinkt deutlich, sobald die Komplexität steigt. Und es gibt einen klaren Unterschied zwischen Greenfield und Brownfield. Genau das deckt sich mit den Ergebnissen der METR-Studie. [10]

Fazit

Wenn ich meine eigenen Erfahrungen und die Recherchen der letzten Wochen zusammennehme, bleibt für mich nur ein Schluss: Nicht alles, was glänzt, ist Gold. Und im Bereich Coding-AIs fühlt sich vieles derzeit eher nach Katzengold an.

Vermutlich hat Georg Zoeller mit seinen Aussagen im Capital-Interview [11] recht: Viele Unternehmen nutzen KI schlicht als Vorwand, um Entlassungen im großen Stil zu rechtfertigen. Belege für echte Effizienzgewinne? Fehlanzeige. Und wissenschaftlich belegen lassen sich die Versprechen bisher auch nicht.

Das alles erinnert stark an die große Outsourcing-Welle der 2000er-Jahre. Nur dass es damals primär um den Fachkräftemangel ging, nicht um Massenentlassungsfantasien. Und so umfassend wie heute wurde damals auch nicht abgebaut.

Natürlich haben Coding-AIs ihren Platz. Sie können unglaublich hilfreich sein. Aber sie sind noch weit davon entfernt, echte Entwickler:innen zu ersetzen. Autonome Coding-AI-Agenten, die ohne menschliche Intervention funktionieren, sind Wunschdenken. Heute schon darauf zu bauen, wäre aus Risikoperspektive schlicht verantwortungslos. Man muss sich nur den GenAI-Code-Security-Report von Veracode ansehen [12]. Kein Wunder also, dass laut aktueller Stack-Overflow-Studie das Vertrauen von Entwickler:innen in KI langsam, aber stetig sinkt [13].

Ein Freund sagte kürzlich sinngemäß zu mir: „Menschen machen Fehler – und die dürfen trotzdem programmieren. Sie brauchen halt länger, um ihre Fehler zu machen. Damit hat er nicht Unrecht. Der Unterschied ist: Wir Menschen wissen, dass wir Fehler machen. Zumindest die meisten von uns. Eine KI weiß das nicht. Und genau deshalb funktionieren viele der etablierten Mechanismen und Tools zur Fehlervermeidung bei der KI nicht, auf die sich menschliche Entwickler:innen verlassen.

Haben Samantha und ich noch eine gemeinsame Zukunft? Das nächste Experiment wird es zeigen und ich werde hier weiterhin darüber berichten. Vielleicht werde ich auch mal mit Samanthas großen Brüdern, Claude und Cursor, ein Gespräch führen. In den letzten Wochen haben sich ja zu einem Quasi-Standard entwickelt. Und ich möchte gern ein Java-Projekt testen. Damit kann ich die Ergebnisse besser einschätzen als mit Python. Es bleibt spannend.