- Es gibt Entwickler, die Schwierigkeiten haben, mit Coding-LLMs einen klaren Mehrwert zu erzielen
- Manche Nutzer sind mit der Qualität der Ausgaben von LLMs nicht zufrieden
- Bei konkreten Anforderungen oder komplexen Problemen bleiben LLMs tendenziell hinter den Erwartungen zurück
- Andererseits wird bei einfacher Automatisierung oder wiederkehrenden Aufgaben ein gewisses Maß an Komfort erlebt
- Entwickler suchen nach Methoden zur Prompt-Entwicklung oder zur Verbesserung ihrer Workflows
Diskussion über Schwierigkeiten bei der Nutzung von Coding-LLMs und Wege zur Verbesserung
Begrenzter Wert von LLMs
- In letzter Zeit experimentieren viele Entwickler mit ChatGPT, GitHub Copilot, Claude und anderen Coding-LLMs für verschiedene Einsatzzwecke
- Ein erheblicher Teil der Nutzer spürt jedoch nicht die erwartete spürbare Produktivitätssteigerung
- Besonders bei komplexen Algorithmen, der Strukturierung großer Codebasen oder dem Entwurf von Projektarchitekturen ist der von LLMs empfohlene Code oft fragmentiert oder ineffizient
Unzufriedenheit mit der Ausgabequalität
- Einige Entwickler berichten, dass der von LLMs gelieferte Code Bugs enthält oder ungenaue Ergebnisse liefert, weil der Kontext nicht ausreichend verstanden wird
- Häufig sind Erklärungen oder Analysen unzureichend, oder der Code spiegelt die Komplexität und den Kontext des Projekts nicht angemessen wider
Hilfe in einfachen Einsatzbereichen
- Bei der Erstellung kurzer Code-Snippets, wiederkehrenden Aufgaben oder der Lösung einfacher Syntaxprobleme zeigt sich ein klarer Komfortgewinn im Bereich der grundlegenden Automatisierung
- Der Einsatz für Unit-Tests, Refactoring und die Anpassung des Code-Stils bei Routineaufgaben wird positiv bewertet
Versuche zur Verbesserung
- Einige Entwickler setzen aktiv Prompt-Engineering-Techniken ein, um bessere Ergebnisse zu erzielen
- Sie experimentieren mit Nutzungsweisen von LLMs, die zu ihrem eigenen Workflow passen, sowie mit Kombinationen aus verschiedenen Open-Source-Tools
Fazit und Erkenntnisse
- Derzeit wird anerkannt, dass LLMs keine universelle Lösung für alle Anforderungen in der Softwareentwicklung sind
- Community und Entwickler tauschen Erfahrungen aus und suchen nach effizienten Nutzungsstrategien sowie Wegen, ihre Grenzen zu überwinden
1 Kommentare
Hacker-News-Kommentare
Ich habe das Gefühl, dass es bei Entwicklern zwei Lager gibt. Das eine behauptet lautstark, LLMs seien beim Programmieren eine absolute Superkraft und ihre Produktivität habe sich verhundertfacht. Das andere sieht darin eher ein ziemlich heikles Werkzeug, mit dem man nur mit viel Handarbeit und Mühe zu bestenfalls durchschnittlichen Ergebnissen kommt. Wenn die erste Gruppe mit ihren revolutionären Produktivitätsgewinnen durch LLMs wirklich so beeindruckend wäre, fragt man sich allerdings, ob sie dann nicht längst den Markt dominieren und alle Konkurrenten hinwegfegen müsste.
Bei Greenfield-Arbeit fühlt es sich für mich mit LLMs tatsächlich nach bis zu 100-facher Produktivität an. Zum Beispiel kann ich für eine React-App in wenigen Minuten mehrere Seiten, einen Redux-Store, Authentifizierung und ähnliche Grundstruktur erzeugen lassen. Wenn ich sage: „Füge jetzt X hinzu“, kommt meistens etwas Brauchbares heraus. Aber bei der Wartung bestehender Systeme, beim Hinzufügen komplexer Funktionen oder wenn Domänenwissen wichtig ist, sind LLMs kaum hilfreich. Für Code-Autovervollständigung oder das Ergänzen einzelner Funktionen sind sie gut, aber bei der Umsetzung ganzer Features stoßen sie schnell an Grenzen. In solchen Fällen ist die Zeit, die ich fürs Anweisen des LLM aufbringe, ungefähr dieselbe wie die, in der ich es selbst direkt coden würde. Deshalb schreibe ich meist erst Stub-Code in der gewünschten Struktur und lasse das LLM nur die Lücken füllen. Leute, die von 100-facher Produktivität reden, hatten wahrscheinlich bisher nur mit den einfachen Teilen zu tun oder sind den schwierigen Stellen noch nicht begegnet. In der Praxis sind 90 % der Arbeit leicht, und die letzten 10 % sind wirklich hart — und genau diesen Teil bekommen LLMs nicht richtig hin.
Etwas spöttisch gesagt: Die Leute mit den 100x Produktivität multiplizieren in Wahrheit einfach eine kleine Zahl mit 100. In der Recherchephase helfen LLMs enorm. Ich musste zum Beispiel kürzlich explizit linearen Algebra-Code für bestimmte Domänen schreiben und konnte keine Bibliotheken wie LAPACK verwenden, also habe ich alles selbst implementiert. Dabei konnte ich das LLM statt eines Nachschlagewerks nutzen, um mir die nötigen Informationen auf einmal zusammenzufassen, und die eigentliche Recherchezeit hat sich dadurch wirklich um den Faktor 100 verkürzt. Aber als ich dem LLM die konkrete Implementierung überließ, baute es subtile Fehler ein, die jemand ohne Fachkenntnis kaum bemerkt hätte. Ein Junior hätte das vielleicht einfach durchgewunken. Da mir Code-Review wichtig ist, glaube ich nicht, dass sich die Geschwindigkeit des eigentlichen Codens selbst massiv erhöhen wird, egal wie gut LLMs werden. Aber bei der Erkundung und Zusammenfassung, also bei der Entscheidung, welchen Code man überhaupt schreiben sollte, beschleunigen LLMs enorm. Am Ende sind Innovation und kreative Ideen der eigentliche Wert in der Welt, und ich denke, das bleibt weiterhin menschliche Aufgabe. LLMs sind wichtige Helfer, aber hochwertigen Code sollte man meiner Ansicht nach selbst schreiben.
Tatsächlich gibt es auch Leute, die in keines der beiden Lager passen. Es ist keine 100-fache Produktivität, aber auch kein krampfhaftes Arbeiten. Ich programmiere seit über 30 Jahren professionell und musste schon immer Dinge nachschlagen; konkrete Sprachen oder Syntaxdetails vergesse ich regelmäßig. Viele Jobs erfordern nun einmal, zwischen mehreren Sprachen zu wechseln. Früher musste man ständig Referenzbücher, Handbücher oder noch mühsamere Quellen durchforsten. Mit Suchmaschinen wie Google wurde es etwas besser, Plattformen wie Stack Overflow waren dann noch effizienter. Jetzt ist das LLM einfach der nächste Schritt. Vorschläge bei der Autovervollständigung sind manchmal genau der Hinweis, den ich gesucht habe. Natürlich ignoriere ich Unnötiges, aber das Chat-Interface ist angenehmer als Google- oder SO-Suche, weil man viel dialogischer fragen kann.
Ich lerne Mathematik mit Math Academy, ChatGPT und YouTube, insbesondere 3Blue1Brown. Ohne diese Kombination wäre es quälend, jetzt macht es Spaß. Als ich früher einen ähnlichen Kurs an der University of Amsterdam belegt habe, war ChatGPT noch nicht so klug wie heute, daher war es viel schwieriger. ChatGPT beantwortet sogar Fragen, die für Lehrkräfte schwer zu beantworten wären, und das passt perfekt zu mir, weil ich oft auch den kulturellen Hintergrund der Mathematik verstehen muss, um Dinge nachzuvollziehen und kreativ zu lösen. Als ich zum Beispiel fragte, warum man bei Winkeln ein m verwendet, erklärte es mir, dass das historisch von measure kommt. Dadurch kann ich mich wieder stärker auf das Wesentliche an der Mathematik konzentrieren. Auch die schnelle Formel zur Varianzberechnung hat ChatGPT mir leicht verständlich erklärt. Es ist kein Mittel zur Weltherrschaft, aber ich lerne damit Wissen, das ich sonst vielleicht nie gelernt hätte. Natürlich spielen auch YouTube und Math Academy dabei eine große Rolle.
LLMs geben Menschen, die in vielen Bereichen breit arbeiten und nicht in allem Experten sind, eine Superkraft. Wenn man nur ein einziges Spezialgebiet tief bearbeitet und immer nur dort arbeitet, sind sie weniger nützlich. Zum Beispiel ist es großartig, mit einem LLM ein Dockerfile zu schreiben, wenn man pro Projekt vielleicht nur einmal damit zu tun hat und keinen eigenen Deployment-Experten hat. Kleine Syntaxfehler und sonstige Kleinigkeiten lassen sich damit schneller lösen als per Google. Auch Architektur-Trade-offs kann man vom LLM analysieren lassen und die finale Entscheidung selbst treffen; das hilft der Produktivität. Allerdings muss man den Bereich per Prompt gut eingrenzen, damit das LLM nichts Dummes anstellt, und man muss iterativ nachbessern, weil es häufig Unsinn macht, etwa nicht existierende APIs erfindet. Trotzdem bleibt selbst mit Iteration ein Geschwindigkeitsvorteil.
Ich nutze LLMs ebenfalls auf viele Arten. Bei kleinen Debugging-Problemen, Shell-Skripten, Coding und Fragen helfen sie mir in verschiedenen Situationen. Privat verwende ich neben Claude und OpenAI auch Google oder Perplexity und nehme jeweils das Tool mit dem besten Ergebnis. Beruflich nutze ich in VSCode über Copilot oder interne Plattformen Claude, OpenAI und Google, und ich habe auch etwas mit Copilot Studio experimentiert. Ich arbeite seit über anderthalb Jahren so; nicht jedes Tool habe ich die ganze Zeit verwendet, aber mein Gesamteindruck ist folgender: Ja, LLMs haben meine Produktivität erhöht. Ich konnte mit mehreren Programmiersprachen experimentieren und viele Themen besser verstehen, wodurch bestimmte Aufgaben definitiv leichter geworden sind. Aber unabhängig von Modell oder Version zeigt sich klar: Sobald die Aufgabe komplex wird, man seinen eigenen Weg geht oder über bloße Kombinationen hinauskommt, scheitern sie alle. Manchmal frisst die Zeit, die man für das Beheben des vom LLM produzierten Unsinns braucht, genau die Zeit wieder auf, die man anfangs gewonnen hatte. Mein ehrliches Fazit im Moment ist: LLMs sind nützlich für kleine Code-Autovervollständigungen, Debugging und Erklärungen, aber das ist auch schon alles. Unsere Jobs bedrohen sie akut noch nicht.
Beim Lernen neuer Bibliotheken, APIs oder Sprachen helfen mir LLMs sehr. Zu fragen, wie man etwa Text in OpenGL rendert, ist viel schneller, als sich durch gigantische, chaotische offizielle Dokumentation zu kämpfen. Auch beim Schreiben repetitiven und langweiligen Boilerplate-Codes, wenn es im bestehenden Code nichts gibt, woran man sich orientieren kann, sind LLMs nützlich. Aber in dem Bereich, den ich als die eigentliche „Arbeit“ ansehe — also der einzigartige, servicespezifische Code — ist ihr Nutzen im Sinn von „sie schreiben den Code für mich“ nicht sehr hoch. Als Senior Engineer verbringe ich ohnehin kaum Zeit mit dem eigentlichen Tippen von Code; wichtig sind Architektur, Legacy-Refactoring, Performance-Probleme, Debugging seltener Bugs und Ähnliches. LLMs beschleunigen vor allem repetitives Code-Schreiben. Wenn man also nicht jede Woche ein neues Projekt von null auf startet, ist der Nutzen begrenzt. Wenn man immer noch viel Boilerplate schreibt, sollte man vielleicht neben LLMs auch über grundlegendere Lösungen nachdenken.
Beim Lesen chaotischer offizieller Doku und beim Erklären sind LLMs deutlich besser als der Durchschnittsprogrammierer. In diesem Bereich liefern sie klar Mehrwert. Und es gibt ja durchaus Sprachen mit sehr viel Boilerplate.
Es gibt keine Silberkugel, und die Konzeptualisierung ist der wirklich schwierige Teil. The Mythical Man-Month ist ein wichtiger Text, den man unbedingt weiter lesen sollte.
Es gibt keine Silberkugel. Erstaunlich, wie wir den einfachen Rat von Fred Brooks immer wieder vergessen. Wenn man die Erwartungen nicht zu hoch schraubt und versteht, dass im Trainingsmaterial viel fehlerhafter Code steckt und LLMs daher natürlich ebenfalls Bugs produzieren, werden sie viel nützlicher. Man sollte die Entwurfsarbeit nicht einfach abgeben, sondern Dinge wie Funktionszuschnitt selbst vorbereiten und LLMs dafür nutzen, lästige Arbeiten oder unbekannte Bereiche zu erleichtern. Aber auch bei LLM-generiertem Code gilt: Wenn ich dafür Verantwortung tragen soll, muss das auf meinem eigenen Wissen und meiner eigenen Verifikation beruhen. Selbst wenn der Code perfekt aussieht, können versteckte Fehler darin stecken. Deshalb muss ich weiter lernen, meine Fähigkeiten ausbauen und skeptisch bleiben. Man darf ihnen niemals blind vertrauen.
Es ist ziemlich klar, dass LLMs unbrauchbar werden, sobald das Problem eine gewisse Größe überschreitet. Für repetitive Aufgaben oder komplexe find & replace-Operationen sind sie hervorragend. Bei alltäglichem, klar umrissenem Code wie dem Ausfüllen von CRUD-Methoden für API-Ressourcen sind sie sehr nützlich. Kürzlich habe ich sogar Claude Opus 4 meine Patches reviewen lassen; gelegentlich findet es Fehler oder erinnert mich daran, was ich noch tun muss. Aber sobald man einen bestimmten Komplexitätsschwellenwert überschreitet, fällt der Nutzen von LLMs rapide ab. Wenn Änderungen sich etwa über mehrere relativ große Dateien ziehen, denkt man ohnehin schon ganz natürlich selbst darüber nach, welche Dateien anzufassen sind. Trotzdem kann man ein LLM gut als Rubber Duck verwenden. Wenn die KI es richtig macht, schön; wenn nicht, mache ich einfach selbst weiter. Am Ende hilft das LLM meist nur beim Einstieg, und den Großteil der Änderungen muss ich sowieso selbst erledigen. Wenn es mir grob das Framework hinstellt und ich es dann nach meinen Vorstellungen anpasse, ist das immerhin leichter, als komplett bei null anzufangen. Wenn ein LLM sichtbar kämpft, zwinge ich es nicht. Wenn es wegen unklarer Spezifikationen falsch geraten hat, weise ich es darauf hin, und wenn es dann immer noch nicht klappt, mache ich es eben selbst fertig.
Meine Erfahrung ist ähnlich. In folgenden Bereichen sehe ich Wert: Ziemlich eigenständige React-Komponenten oder Seiten erzeugt es zusammen mit populären UI-Bibliotheken sehr gut. Gut definierte Pure Functions kann es recht zuverlässig erzeugen, und sie lassen sich leicht verifizieren. Boilerplate für bekannte Frameworks erstellt es wirklich einfach und gut. Aber Leute um mich herum prahlen mit mächtigen End-to-End-Erfahrungen, und weil das bei mir in der Praxis überhaupt nicht so funktioniert, macht mich das fast wahnsinnig. Selbst wenn ich mich sehr bemühe, brechen LLMs bei vollständigen Funktionseinheiten komplett zusammen. Mit Tools wie aider bekam ich nicht einmal eine simple Template-E-Mail-Funktion in Next.js hin. Wenn ich das Feature in kleine Teile zerlege und einzeln abarbeiten lasse, wird es etwas besser, aber dafür beschädigt es nach und nach den bestehenden Code. Selbst wenn ich die Probleme erkläre, wird es mit mehr Prompts eher noch seltsamer. Am Ende wollte ich alles manuell reparieren, aber der Code war schon völlig verwüstet.
Meine Vibe-Coder-Freunde haben mir schon gesagt, mein Maßstab sei einfach zu hoch. Ich glaube, Vibe Coder prüfen ihren Code im Grunde nicht wirklich, deshalb haben sie keinen echten Qualitätsmaßstab. Wenn Vibe Coding tatsächlich so gut funktionieren würde, dann würden Teams wie Google AI mit riesigen GPU- und TPU-Budgets und den neuesten Modellen ihre Produkte schon längst viel schneller als Menschen verbessern. Und wenn das wirklich passieren würde, würden wir es nicht zuerst daran merken, dass unsere Arbeit allmählich leichter wird, sondern eher daran, dass plötzlich in den Nachrichten etwas völlig Unerwartetes und Großes passiert — und dass KI der Grund war, würden wir erst deutlich später erfahren.
LLMs sind gut für Wegwerfcode. Für Entwicklung, Wartung, Debugging und Reparatur ist das alles nicht so einfach. Da der Großteil von Code in der Praxis eher kein echtes Produkt, sondern eher Verbrauchscode ist, passen sie dort gut. Selbst wenn man dabei an Fast Food, Fließband oder automatisierte Produktion denkt, bleibt der Unterschied riesig. Dinge aus Maschinenproduktion sind zu 99,99 % korrekt und deshalb vertrauenswürdig. Bei LLMs muss ich dagegen jeden einzelnen Schritt selbst verifizieren; wenn ich das nicht tue, funktioniert es einfach nicht. Dass ein LLM 24 Stunden lang unbeaufsichtigt erfolgreich Probleme löst, ist unmöglich. Deshalb nimmt es uns die Jobs vorerst nicht weg.
Ich würde einem LLM niemals das gesamte komplexe Problem komplett überlassen und einfach das Ergebnis abnehmen. Das ist nicht seine Stärke. Der eigentliche Wert von LLMs liegt in „Hinweisen“, die beim Vorankommen helfen, und darin, einfache, aber zeitraubende Teile zu überspringen. Vor ein paar Tagen musste ich einen Log-String bauen, und das LLM schlug sofort schöner formatierten Code vor, als ich ihn selbst im Kopf hatte. Dadurch wurde aus 15 Minuten in 30 Sekunden eine sehr gute Lösung. Solche kleinen Gewinne summieren sich und erzeugen den Wert.
notepad.exe. Bei einfachen, aber mächtigen Sprachen wie Lisp ist Klammerhervorhebung absolut notwendig. Wenn man auf die letzten 10 bis 20 Jahre zurückblickt, haben sich die Sprachen stark verändert. Java, C# und C++ haben viel von funktionalen Sprachen übernommen, auf der JVM gibt es Clojure, Go hält stur an Konstruktionen wieif err != nilfest. Rust hat?hinzugefügt, Zig ist ähnlich. Python wird mit Typannotationen und anderem zunehmend länger und komplexer. Autoformatter sind wirklich praktisch; man muss sich nicht um Einrückung kümmern, aber Python ist wegen seiner Whitespace-Sensitivität nicht perfekt. Werkzeuge helfen bei wortreichen Sprachen, und ausdrucksstarke Sprachen helfen durch knappen Code. Man verbringt weit mehr Zeit mit Lesen als mit Schreiben von Code. Deterministische Werkzeuge sind stark bei der Struktur von Code, probabilistische Werkzeuge wie LLMs eher beim Annähern an die Intention. Sprachmodelle sind eine evolutionäre Weiterentwicklung von Automatisierungswerkzeugen und werden wie Autovervollständigung immer besser werden, aber sie werden Coding nicht „vollständig lösen“ können. Es gibt keine eine richtige Antwort, am Ende sind es nur unterschiedliche Meinungen.