Warum ich beschlossen habe, meine Nutzung von LLMs zu reduzieren

• Alberto Fortin, Softwareingenieur mit 15 Jahren Erfahrung, hatte große Erwartungen an die Einführung von LLMs (Large Language Models), stieß jedoch in der realen Produktionsumgebung auf mehrere Grenzen
• Beim Neuaufbau einer auf Go und ClickHouse basierenden Infrastruktur erlebte er die Stärken und Schwächen von AI aus erster Hand und hatte das Gefühl, dass selbst Modellverbesserungen die Kernprobleme nicht ausreichend lösen
• Er weist darauf hin, dass es eine Illusion von Produktivitätssteigerung gibt und dass in der Praxis stattdessen mehr Bugs und unerwartete Probleme auftreten
• Er betont die Lehre, LLMs als Assistenten (assistant) zu betrachten und dass zentrale Entwürfe und Entscheidungen von Entwicklern selbst getroffen werden müssen
• „AI ist revolutionär, aber noch nicht vollständig ausgereift, daher braucht es eine ausgewogene Nutzung und einen nüchternen Blick auf die Realität“

---

Alberto Fortins Erfahrungen und Rückblick zu LLMs

• Der Softwareingenieur Alberto Fortin mit 15 Jahren Berufserfahrung führte LLMs aktiv in seine Entwicklungsarbeit ein und verband damit große Erwartungen
• Beim Neuaufbau einer Infrastruktur mit Go und ClickHouse stieß er auf verschiedene Herausforderungen und Grenzen und schrieb daraufhin einen Blogbeitrag über die Kluft zwischen AI und realer Entwicklungsarbeit
• In einer neueren ergänzenden Analyse prüfte er anschließend, ob aktuelle Modelle wie Claude Opus 4 diese Probleme gelöst haben

• Albertos Erfahrungen bieten Ingenieuren, die über den Einsatz von LLMs im Arbeitsalltag nachdenken, praktische Erkenntnisse und eine realistische Sicht darauf, in welchen Bereichen das Tool Wert schafft und wo seine Grenzen liegen

Zentrale Zitate von Alberto zu seinen LLM-Erfahrungen

> „Ich war wirklich überrascht, dass es nicht nur um Fehlverhalten oder nicht funktionierende Features ging. Als Entwickler, der diesen Code in den nächsten Jahren warten will, muss der Code sauber genug sein.“

> „Es wirkt, als wäre das Problem gleich gelöst, aber am Ende tritt wieder ein neuer Fehler auf, und es dauert erneut etwa zwei Wochen, ihn zu beheben — diese Erfahrung hat sich wiederholt.“

> „Wenn man die Fehlermeldung an ein LLM weitergibt, bekommt man zwar eine neue Antwort, aber oft verkompliziert es etwas oder macht an anderer Stelle etwas kaputt.“

Erkenntnis über überzogene Erwartungen an LLMs

> „Als man kleine Funktionen wie frühes Autocomplete zum ersten Mal nutzte, waren alle Entwickler erstaunt. Es fühlte sich an, als würde es meine Gedanken lesen, und dadurch steigen die Erwartungen schnell.“

> „Es fühlt sich an, als könnte die Entwicklungsproduktivität um das Zehnfache steigen, aber tatsächlich neigt man dazu, diese Erwartungen viel zu schnell zu haben.“

Neujustierung von Rolle und Erwartungen

> „Der größte Unterschied ist die veränderte Wahrnehmung der Rollen. Ich bin Architekt und Senior-Entwickler, und das LLM ist nur mein Assistent. Ich mache den Plan, und das LLM übernimmt eine unterstützende Rolle.“

> „Nachdem ich das Vertrauen verloren hatte, überlasse ich ihm keine wichtigen Funktionen mehr. Ich nutze es nur noch für kleine Einheiten wie Refactoring.“

> „Ich habe angefangen, Bugs selbst zu beheben. Wenn man die Codebasis vollständig versteht, ist es viel schneller und effizienter, Probleme direkt selbst zu lösen.“

Veränderung der Sicht auf LLMs und Ratschläge

> „Als Senior-Entwickler habe ich für mich akzeptiert, dass der Einsatz von LLMs nicht deshalb schlecht zu mir passt, weil mir Fähigkeiten fehlen. Entscheidend ist, die bestehende Arbeitsweise beizubehalten und AI unterstützend zu nutzen.“

> „Es stimmt, dass die Technologie einen Schritt vorangekommen ist, aber die nächste Stufe ist noch nicht erreicht. Entscheidungen und Architektur müssen weiterhin Menschen übernehmen.“

> „Die AI-Revolution ist erstaunlich, aber im Moment braucht es ausgewogene und realistische Erwartungen.“

[tested]

> https://de.news.hada.io/topic?id=20955

[GN⁺]

Hacker-News-Kommentare

• Ich glaube, ich verbringe zu viel Zeit auf HN, weil ich in fast jedem Beitrag und Kommentar immer wieder dieselben Geschichten lese. LLMs sind zwar interessant, aber der erzeugte Code ist komplex, fühlt sich nicht nach dem eigenen an, und weil man nicht wie bei selbst geschriebenem Code die gesamte Struktur im Kopf hat, ist er schwer zu warten. Für kurze Skripte, die man ohnehin nicht pflegen will, taugt das, aber bei großen Projekten wird es problematisch. Auf der anderen Seite gibt es Leute, die sagen, wie großartig Workflows seien, bei denen mehrere LLM-Agenten für verschiedene Aufgaben parallel arbeiten und die Ergebnisse dann zusammengeführt werden — aber sie zeigen keinen echten Code, sondern wirken eher, als würden sie nur angeben

  • Ich finde, diese Zusammenfassung trifft den Kern wirklich gut. LLMs steigern das Entwicklungstempo enorm, aber weil ich den gesamten Code nicht wirklich verstehe, ist es schwer nachzuvollziehen, wann und wo ein Problem entstanden ist. Am Ende fühlt es sich an, als würde ein neuer Entwickler in sein eigenes Projekt eingearbeitet werden. Deshalb committe ich häufig und bitte das LLM regelmäßig erneut darum, den Code zu erklären. Dabei findet das LLM oft sogar seine eigenen Bugs. Für eng umrissene Aufgaben wie Datenanalyse kann man so schnell vorankommen und trotzdem alles gut im Griff behalten. Umgekehrt wird es in großen Codebasen schnell chaotisch, wenn man nicht die Fähigkeiten und Gewohnheiten hat, LLMs dort sinnvoll einzusetzen. Prompting, Kontextverwaltung, Tempokontrolle, Aufgabenorganisation und eine präzise Review der LLM-Ergebnisse sind Fähigkeiten, die man unbedingt lernen muss. Offiziell bringt einem das bisher niemand bei, deshalb lernen alle per Versuch und Irrtum. Trotzdem ist es schwer, wieder zum alten Zustand zurückzukehren, wenn man einmal davon gekostet hat. Nervige oder repetitive Arbeiten kann man eben an ein LLM abgeben. Und nach über 20 Jahren Entwicklung habe ich auch nicht mehr die Geduld von früher; selbst Ideen, bei denen ich den Implementierungsweg nicht gut kenne, lassen sich mit LLMs deutlich effizienter umsetzen

  • Mir gefällt die Sichtweise auf Programmierung als Prozess des „Theorieaufbaus“. Siehe Programming as Theory Building. Gegen den Einsatz von AI an sich habe ich nichts. Was ich aber nicht gutheiße, ist die Haltung, die Verantwortung für die Ergebnisse des generierten Codes abzugeben. Wie bei Werkzeugen wie grep ergibt der Einsatz nur dann Sinn, wenn man auch die Verantwortung für das Ergebnis übernimmt. Für generierten Code gilt das umso mehr; das lässt sich nicht einfach mit einem Disclaimer abtun

  • Ich kann die Müdigkeit bei AI-bezogenen Beiträgen nachvollziehen. Dass die Meinungen auseinandergehen, stimmt natürlich. Trotzdem gibt es auch Beispiele von Leuten, die ihren echten Code offenlegen. Armin Ronacher, der Flask/Jinja2/Sentry gebaut hat, hat auf YouTube ein Workflow-Video und eine Vorstellung seiner selbst gebauten AI-Bibliothek veröffentlicht, und ich selbst baue etwa 50 bis 80 % meiner Open-Source-Projekte mit AI. Siehe cijene-api

  • Für mich fühlt es sich so an, als würden sich die Nutzer in einer Glockenkurve verteilen. An einem Ende stehen die Leute, die von LLMs mit zu viel Code in deren eigenem Stil überschüttet werden, sodass der Kontext nicht mehr im Kopf bleibt und sie sich überfordert fühlen. Dann gibt es die Gruppe, die allein nie in der Lage gewesen wäre, etwas zu implementieren, für die LLMs aber den Weg öffnen, überhaupt Dinge zu bauen. Und am anderen Ende stehen Menschen, die grundsätzlich auch selbst langsam implementieren könnten, LLMs aber wie ein Heer von Junior-Entwicklern einsetzen, sich nur noch auf das Gesamtbild des Algorithmus konzentrieren und dadurch viel größere Projekte viel schneller zusammensetzen

  • Das wirkt auf mich gar nicht so anders, als in einer großen Codebasis zu arbeiten, an der gleichzeitig mehr als 25 Entwickler beteiligt sind. In meiner Organisation kümmern sich 160 Engineers um Frontend und Middle Tier, und man muss ständig in Code ohne Eigentumsgefühl herumwühlen, während bei git blame regelmäßig der Name eines externen Entwicklers von vor drei Jahren auftaucht. Für kleine Vorhaben sind LLMs okay, für mittlere ungeeignet, und in großen Projekten dann wieder brauchbar, wenn sie auf kleine Module begrenzt werden

• LLMs helfen mir sehr dabei, meine Ziele zu erreichen, aber ich habe das Gefühl, dass meine eigentlichen Programmierfähigkeiten darunter leiden. Es ist ein bisschen wie mit Steroiden: Die Muskeln wachsen schnell, aber die Nebenwirkungen sind groß, und sobald man damit aufhört, bricht alles sofort zusammen. Firmen interessiert eher der schnelle Output als Gesundheit, deshalb verstärkt sich dieser Effekt noch. Ich habe angefangen, bewusst Grenzen zu setzen und den Einsatz zu dosieren

  • Der Vergleich mit Steroiden ist einprägsam. Ich musste dabei an einen aktuellen Beitrag im Blog von Cal Newport denken, in dem es darum geht, dass AI uns träge macht. Forscher hätten dort auch EEG-Daten vorgestellt, nach denen Menschen ohne AI-Unterstützung mehr Gehirnaktivität zeigen. Das heißt trotzdem nicht, dass AI in allen Bereichen verboten werden sollte. Für E-Mails und andere nicht zentrale Aufgaben kann man sie nutzen, aber bei der eigentlichen Kernarbeit sollte man eher zurückhaltend sein. Zum Blog

• Dank LLMs scheinen viele Entwickler die Lehren aus "Simple Made Easy" vergessen zu haben. Der von LLMs erzeugte Code ist hervorragend darin, einen „Ball of Mud“ zu produzieren — also chaotischen Code, der sich weder sauber refaktorieren noch gut pflegen lässt. Die eigentliche Stärke liegt darin, komplexe Probleme in kleine Teile zu zerlegen, sodass jede kleine Komponente einfach funktioniert und ihr Zusammenspiel die eigentliche Komplexität erzeugt. Wenn jede Komponente einfach bleibt, werden Verständnis, Debugging und Performance-Abschätzung leichter. Wenn LLMs diesem Prinzip irgendwann wirklich gut folgen, dann braucht man vielleicht tatsächlich keine Entwickler mehr

  • Eigentlich kann man dem LLM die gewünschte Richtung auch direkt vorgeben. Der Unterschied zwischen Leuten, die LLMs nützlich finden, und denen, die das nicht tun, liegt darin, ob sie die Stärken und Schwächen von LLMs verstehen und einschätzen können, wie stark sich die Qualität je nach Input-Prompt verändert. Ich frage ein LLM zum Beispiel lieber danach, wie man ein komplexes Problem sinnvoll zerlegen kann, um zu prüfen, ob ich etwas übersehen habe, und übergebe ihm erst danach die konkrete Implementierung. Ich lasse mir nicht ohne jede Anleitung ein komplettes Großprojekt generieren

  • Das „Ball of Mud“-Problem tritt nicht nur im Code auf. Bei mir im Unternehmen gibt es Führungskräfte, die sagen, man müsse „AI offensiv annehmen“, und ich habe schon Vorstellungen gesehen, nach denen sogar Deployment-Systeme und komplexe Betriebsabläufe von AI gesteuert werden sollen. Im Ergebnis setzt man damit auf ein ohnehin komplexes System noch eine weitere komplexe Blackbox obendrauf — nach dem Motto: „Um diese Blackbox zu verstehen, brauchen wir noch eine neue Blackbox.“ Für mich ergibt das keinen Sinn. Wegen der druckvollen Stimmung in der Organisation bekomme ich dabei manchmal sogar das Gefühl, als wäre ich derjenige mit der schrägen Sichtweise

  • Wenn LLMs wirklich perfekt würden, braucht man dann tatsächlich keine Entwickler mehr? Ich glaube nicht, dass irgendjemand ein System will, das 24/7 einfach wie eine „Maschine zur Softwareproduktion“ weiterläuft. Es wird weiterhin Menschen brauchen, die Probleme zerlegen und die tatsächlich benötigte Software finden und bauen. So wie wir sie heute eben Softwareentwickler nennen

• Ich bin letztlich bei einem ähnlichen Fazit gelandet. Als eine Art Autocomplete für die gesamte Codebasis taugen LLMs nicht besonders. Das Problem ist, dass das mentale Modell davon verschwindet, was wo was macht. Als personalisiertes StackOverflow für Begriffserklärungen, Zusammenfassungen unbekannter Konzepte oder grobe Richtungsangaben sind sie dagegen sehr nützlich, während ich die eigentliche Implementierung und die Entscheidungen lieber selbst treffe — das war für mich deutlich effizienter

  • Ich nutze es auch so, aber Cursor schlägt trotzdem hartnäckig immer wieder Codeänderungen vor. Mich würde interessieren, ob es irgendeinen Trick gibt, ihn nur introspektiv arbeiten zu lassen, ohne Inhalte der Codebasis anzufassen

  • Bei mir ist es anders. Wenn ich den vom LLM vorgeschlagenen Code immer sorgfältig reviewe, weiß ich ziemlich klar, was wo liegt und wie es zusammenwirkt

• Auch ich reduziere meine Nutzung inzwischen deutlich. LLM-Antworten waren oft genug falsch. Deshalb frage ich inzwischen meist nur noch, in welchem Manual oder Dokument ich etwas finden kann, und schaue mir den eigentlichen Inhalt dann selbst an. Diese Methode hilft dabei, ein Gefühl für Fundstellen zu entwickeln, und senkt die Abhängigkeit von Suchmaschinen und LLMs. Ein LLM ist eben nur ein Werkzeug, und dazu noch eines mit begrenzter Genauigkeit

• Ein Punkt, der bisher kaum erwähnt wurde: LLMs können die Produktivität manchmal auch senken. Wenn sie einen mit plausibel klingenden Antworten in die falsche Richtung führen, kostet das im Zweifel massiv Zeit. Insgesamt helfen sie oft, aber „Vertrauen und verifizieren“ ist wichtig, und nicht selten ist direkte Eigenimplementierung tatsächlich schneller

• Die Grenzen von LLMs sind klar erkennbar. Sie sind sehr mächtig, aber ihnen fällt es schwer, kreative Sprünge wie ein Mensch zu machen. Auf die Frage „Unter Android kann ich keinen Port unter 1000 binden — wie starte ich dann einen Webserver?“ haben Claude und Gemini beide nur drei naheliegende Standardlösungen genannt: 1) Reverse Proxy 2) Rooten 3) Portnummer erhöhen. Die eigentliche Lösung, die ich wollte, war ein HTTPS-RR-Record (siehe hier). Beide kennen diese Spezifikation grundsätzlich, konnten sie aber nicht auf die konkrete Situation anwenden. Erst als ich selbst mehr Kontext ergänzt habe, kam die richtige Antwort zustande

  • Ich finde es ehrlich gesagt nicht überraschend, dass das LLM das nicht empfohlen hat. Es ist schwer zu erwarten, dass es eine neue Spezifikation vorschlägt, die selbst in Chrome nicht offiziell unterstützt wird, und ich wäre vermutlich auch nicht darauf gekommen

  • Diese Information habe ich mir auch notiert. In letzter Zeit, während ich wirklich mit LLMs gesprochen habe, habe ich gemerkt, dass etwas Nachsicht — so wie bei Menschen — den Stress verringert. Wenn ich zum Beispiel mit Cursor Code schreibe und es auf etwas Fehlendes hinweise, denke ich manchmal, dass mir derselbe Fehler auch hätte passieren können. Ich habe LLMs auch schon als „Buchclub“- oder „Filmclub“-Partner genutzt und sie zwei Filme diskutieren lassen; dabei gab es Fehler bei Details zu den Figuren, aber wenn man nicht 100 % Genauigkeit erwartet und dieselbe Nachsicht walten lässt wie bei Menschen, wird das Gespräch viel entspannter. Es ist gut, AI auch im Gespräch positiv zu behandeln

  • Von SRV-Records hatte ich schon gehört, aber sie schienen kaum benutzt zu werden; HTTPS RR war mir neu. Die tatsächliche Unterstützungslage scheint auch besser zu sein als bei SRV

  • Das ist das klassische LLM-Problem: Erst wenn man die richtige Antwort selbst erwähnt, wird sie plötzlich in die Liste der Lösungen aufgenommen

  • Wenn man Ziel und Randbedingungen ausreichend klar angibt, schlägt ChatGPT o3 diese Lösung durchaus vor. Es weist dann aber korrekt darauf hin, dass sie nur in neueren Browsern funktioniert. Beispiel

• Ich nutze oft die Enterprise-Version von ChatGPT und habe mit der Zeit ein paar Dinge gelernt. Man sollte keine großen Codeblöcke hineinkippen, sondern mit sehr unabhängigen Funktionen oder kleinen Klassen arbeiten; dann funktioniert es gut. Bei Anfragen zur Codegenerierung oder -vervollständigung lassen sich etwa 10 % der Fälle durch zusätzliche Anweisungen retten, aber die Qualität bleibt mäßig, und bei etwa 25 % verbessert sie sich gar nicht, egal wie viel man erklärt. Dann ignoriere ich es konsequent und löse das Problem selbst. Für Reviews von neu geschriebenem Code ist es dagegen ziemlich brauchbar. Die Hälfte der Kommentare ist nutzlos, manches ist vage, aber gelegentlich weist es auf wirklich wichtige Bugs oder Probleme hin. Man sollte nicht mehrere Seiten auf einmal hineingeben, sondern den Stoff aufteilen. In Nischenbereichen wie HLSL-Shadern oder SIMD kommt wegen mangelnder Trainingsdaten kaum etwas Brauchbares heraus. Insgesamt hilft es aber, die Codequalität zu verbessern. Weil ich Code in kleine Einheiten aufteile und separat validiere, werden Funktionen, Klassen und Module architektonisch klarer getrennt, was der Gesamtqualität zugutekommt

  • Ich habe angefangen, AI für Code-Reviews zu nutzen, und das ist wirklich praktisch. In kleinen, klar abgegrenzten Bereichen wie einzelnen Funktionen hilft sie enorm, und besonders für das lästige Schreiben von Unit-Tests ist sie nützlich. Die Qualität von AI-Coding-Assistenten ist im letzten Jahr wirklich stark gestiegen; wer sie vor längerer Zeit ausprobiert hat und enttäuscht war, sollte ihnen vielleicht noch einmal eine Chance geben

• Für langfristige Softwareentwicklung ist LLM für mich am attraktivsten als „fortgeschrittener Boilerplate-Generator“. Für einmalige Aufgaben ohne Wartungsbedarf ist es ohnehin schon gut, aber auch in langfristigen Projekten ist es extrem nützlich für repetitiven Code, der sich schwer sinnvoll abstrahieren lässt, zum Beispiel Testcode. Anfangs war ich skeptisch, inzwischen bin ich sehr zufrieden. Langweilige, repetitive Teile haben sich in ein interessantes neues Spiel namens „Prompt-Optimierung“ verwandelt, und meine Produktivität ist deutlich gestiegen. Prompts zu schreiben und Code zu reviewen geht viel schneller als stumpfe Fleißarbeit. Dadurch bleiben nur noch die interessanten Teile übrig, für die man wirklich den Kopf braucht

• Mir ist klar geworden, dass LLMs letztlich nicht nur beim Programmieren, sondern auch bei vielen anderen Aufgaben ein Phänomen sind wie „Trend-Diäten“. Alle wollen eine schnelle und einfache Lösung, aber einen Königsweg gibt es am Ende nicht. Bequemlichkeit bedeutet immer Trade-offs, und irgendwann müssen das alle akzeptieren