- Die aktuelle Diskussion über LLMs findet ohne klare quantitative Belege statt.
- Die Erfahrungen einzelner Nutzer sind stark fragmentarisch, und entscheidende Faktoren wie der tatsächliche Einsatzkontext oder das Vorwissen werden kaum geteilt.
- Aufgrund ihrer nichtdeterministischen Eigenschaften liefert selbst dieselbe Aufgabe je nach Zeitpunkt unterschiedliche Ergebnisse, was die Zuverlässigkeit einschränkt.
- Überzogene Behauptungen von Branchenführern fördern eine unkritische Übernahme und übersteigerte Erwartungen.
- Tatsächlich nutzt der Autor selbst verschiedene AI-Tools im Alltag und schildert aus der Praxis, dass er nur mit einer Wahrscheinlichkeit von etwa 50 % das gewünschte Ergebnis erhält.
Die Debatte um LLMs und der Blick auf die Technologie
Kritik an LLMs und die Stimmungslage
- In den jüngsten Debatten über AI, insbesondere über LLMs (Large Language Models), entsteht oft eine Atmosphäre, in der kritische Sichtweisen als „Meinungen von Menschen, die die Technologie nicht richtig verstehen“ abgetan werden.
- Auf Hacker News und anderswo wiederholt sich häufig die Reaktion, dass schon das Stellen von Fragen zu AI als Ausdruck von Unwissen über das Wesen der Sache gelte.
Die Kluft zwischen den Erfahrungen der Nutzer
- Hinsichtlich des tatsächlichen Nutzens von LLMs gibt es einerseits Nutzer, die sagen, „bis zu einem gewissen Grad hilft es“, und andererseits solche, die meinen, „ich habe alles versucht, aber wirklich nützlich ist es nicht“.
- Der Grund für diese Unterschiede ist, dass konkrete Maßstäbe und Informationen zu den Erfahrungen nicht geteilt werden.
- In welchem Projekt es eingesetzt wurde
- In welchem Zustand sich die Codebasis befand (neues Projekt, reifer Code, proprietärer Source Code usw.)
- Wie hoch die Fachkenntnis des Nutzers war und wie eng diese Expertise mit dem tatsächlichen Problem verbunden war
- Welcher zusätzliche Aufwand nötig war, um die vom LLM erzeugten Ergebnisse tatsächlich zu verfeinern und bereitzustellen
Schwierigkeit beim Vergleich von Erfahrungen und Nichtdeterminismus
- Selbst wenn ein Nutzer alle Informationen im Detail teilen würde, wäre ein Vergleich der Erfahrungen mit anderen Nutzern nahezu unmöglich.
- LLMs und Automatisierungsagenten sind ihrem Wesen nach nichtdeterministisch.
- Selbst wenn man für dasselbe Problem auf dieselbe Weise fragt, erhält man jedes Mal andere Ergebnisse.
- Es gibt viele veränderliche Faktoren wie Projekttyp, verwendetes Modell, Tools oder Sprache, was eine konsistente Verifizierung erschwert.
Branchenführer und überzogene Erwartungen
- Es gibt zahlreiche Fälle, in denen Branchenführer die Leistungsfähigkeit von LLMs übermäßig betonen.
- Beispiel: Ein Branchenführer berichtet, mit „Claude Code“ sei ein alter Bug erstaunlich leicht behoben worden, erhält breite Zustimmung, ohne Details zu teilen.
- Entscheidende Informationen wie Größe des Codes, Schwierigkeit des Bugs, zusätzlicher Arbeitsaufwand oder die verwendete Programmiersprache und das Framework werden ausgelassen, während sich nur die sehr positive Botschaft verbreitet.
- Solche Fälle verzeichnen mehr als 1,8 Tsd. Reaktionen und 204 Reposts, wodurch überzogenes Marketing leicht weite Verbreitung findet.
Nutzungserfahrung und realistische Einordnung
- Auch der Autor setzt täglich verschiedene AI-Tools wie Vercels v0, Claude Code und Midjourney ein.
- Erstellung einer Monitoring-App mit SwiftUI ohne Kenntnisse in Swift
- Automatische Generierung eines Posters für ein Event mit Midjourney
- Codierung von MCP-Server-Funktionen auf Basis von Elixir
- Die Erfolgsquote liegt jedoch nur bei ungefähr 50 %, und die Ergebnisse sind nie wirklich konsistent.
- Manchmal fühlen sich LLMs zwar wie Magie an, tatsächlich sind sie aber nur nichtdeterministische statistische Modelle.
- In dieser Realität, so die Kritik, bleibt die Branchendebatte bei einer binären Gegenüberstellung (Magie vs. Engineering) stehen.
Fazit
- Das Umfeld rund um LLMs und AI bevorzugt tendenziell überzogene Vorstellungen, Erwartungen und Glaubenssätze ohne belastbares und klares Verifikationssystem.
- Wichtig ist, das kritische Denken nicht aufzugeben und Funktionen sowie Wirkung tatsächlich im Detail zu überprüfen.
- Entscheidend für die Debatte ist das Teilen konkreter und quantitativer Informationen.
- Es braucht eine ausgewogene Perspektive auf die Grenzen und Möglichkeiten von LLMs.
1 Kommentare
Hacker-News-Kommentar
Ich bin frustriert, weil das Management bei mir auf der Arbeit von 10-facher Produktivitätssteigerung spricht. Einige unserer Early Adopters in der Firma behaupten das selbst. Aber diese Erwartungen sind viel zu hoch. Amdahls Gesetz spielt auch eine Rolle: Ich verbringe den Großteil meiner Zeit nicht mit Coden, sondern mit Denken und Kommunikation. Selbst wenn das Coden wirklich 10-mal schneller würde (was in den meisten Fällen nicht so ist), steigt die Gesamtproduktivität nur um 10–15 %. Das ist immer noch ziemlich gut, aber eben nicht 10x
Vielleicht liegt es daran, dass meine aktuelle Arbeit eher R&D-artig ist, aber LLMs bringen mir beim „Denken“ ungefähr genauso viel wie beim „Coden“ (Kommunikation bekomme ich selbst gut hin). Mit LLMs Denkaufgaben zu erledigen fühlt sich an wie vor 20 Jahren, als man gelernt hat, Websuche zu meistern. Früher musste ich wissen, wonach ich suche; jetzt finden LLMs sogar erst einmal heraus, wonach ich suchen sollte (und suchen dann oft auch gleich selbst). Dinge, die ich früher als schwierig eingeordnet hätte, lassen sich jetzt dank LLMs leicht lösen. Etwa ein Drittel meiner Websuchen mache ich inzwischen mit ChatGPT o3. Ich kann mir nicht mehr vorstellen, darauf zu verzichten. Dazu kommt der psychologische Aspekt, dass LLMs meine unfertigen Gedanken ordnen und als Diskussionspartner dienen. Dadurch wirken viele Dinge deutlich weniger einschüchternd, und das macht einen großen Unterschied
Bei uns in der Firma ist es ähnlich. Die von internen Early Adopters behaupteten Produktivitätsgewinne werden entweder sehr eng gemessen oder die Rechnerei ist einfach ziemlich schlampig
Es könnte sein, dass LLMs Senior-Entwickler stärker beschleunigen als Junioren (weil Junioren guten und schlechten Code schlechter unterscheiden können). Wenn ein Senior einen verbesserten LLM-Workflow nutzt, könnte das produktivitätsmäßig früher vielleicht zehn Junioren entsprechen. Ein schlechter Entwickler kann die Produktivität sogar effektiv ins Negative ziehen (weil er Senior-Zeit bindet). Selbst ordentliche Junioren bleiben dann bei repetitiven Aufgaben hängen, die LLMs bereits besser erledigen. Deshalb halte ich es für möglich, dass Jobs tatsächlich verschwinden
Wenn der Einsatz von LLM-Tools die Produktivität nur um 10–15 % erhöht, aber die Beschäftigungskosten durch die Tool-Kosten ebenfalls um 10–15 % steigen, dann sehe ich keinen besonderen Vorteil. Man muss die Gesamtkosten der Produktion betrachten
Bei privaten Projekten geht es leicht fast 10-mal schneller. Aber im Unternehmen passt dieses Umfeld wegen Abstimmungen mit mehreren Teams, geänderten Anforderungen, PR-Reviews usw. nicht. Solch optimiertes Design und standardisierte Muster sind auf kleine Startups oder Solo-Projekte begrenzt. Sobald mehrere Personen beteiligt sind, ist schon Konsens schwierig. Damit AI die besten Ergebnisse liefert, müsste alles standardisiert sein, aber in der Realität ist immer alles ein bisschen verschoben, daher ist es in echten Organisationen schwer, diesen Effekt zu erreichen. Wenn wenige Entwickler mit gleichem Willen zusammenarbeiten, sind vielleicht 10x drin, aber in Unternehmensumgebungen ist das fast unmöglich. Ich denke, AI passt eher zu Middle Management und Projektplanung
Ich bin eher die Sorte, über die sich der Autor beschwert. Ich habe ein Greenfield-Produkt veröffentlicht, als ChatGPT noch ziemlich schwach war. Danach habe ich Claude genutzt und per Copy-paste zwischen Webchat und XCode gearbeitet, danach dann Cursor. Build-Fehler gab es oft, aber die Produktivität war trotzdem mindestens 3x. Jetzt werden die Agenten besser und Claude 4 ist da, deshalb code ich fast gar nicht mehr. Ich übernehme eher die Rolle von Architect/Manager und dirigiere die Agenten mit meinem Fachwissen. Im Startup habe ich seit Monaten keine einzige Zeile Code mehr selbst geschrieben. Ich prüfe alles, bevor ich selbst einen PR einreiche, und teste gründlich, aber die Kombination aus Cursor+Sonnet ist verrückt. Zeilenzahlen sind unwichtig; eher kommen langjährige Experten der bestehenden Codebasis mit kleinen Bug-Fragen zu mir. Dank Claude habe ich sogar Frontend-Arbeit angefasst, weshalb ich vorsichtig bin. Ich werfe nicht einfach nur Queries hinein, sondern lasse einen gründlichen Recherche-, Planungs- und schrittweisen Explorationsprozess durchlaufen. Domainwissen ist unverzichtbar. Trotzdem finde ich es erstaunlich, dass manche Leute das nicht auf diese Weise nützlich einsetzen können. Ich habe das Gefühl, solche Artikel sehe ich jede Woche zweimal
Ich habe eine ähnliche Erfahrung, aber in einem etwas anderen Umfeld (PhD-Student). Ich war LLM-skeptisch, aber seit Claude Code hat sich meine Arbeitsweise komplett verändert. Die Kuratierung bleibt aber vollständig meine Aufgabe (eine wichtige Soft Skill im PhD und auch deshalb, weil LLMs Ziele oder Kontext schnell verlieren oder nicht im Gedächtnis behalten). Wenn man präzise kommunizieren kann, lässt sich mit CC Rechenarbeit auf eine Weise organisieren, die früher unmöglich war. Programmieren wird dadurch nicht einfacher, aber es entsteht ein völlig anderes Format
Mich würde der tatsächliche Prüf- und Kontrollprozess interessieren: wie man von LLMs erzeugten, nicht vertrauenswürdigen Code schnell überprüft, ob das LLM auch Unit-Tests schreibt, wie lang die durchschnittlichen Prompts sind usw.
Der Einwand ist, ob man dem LLM-Output direkt vertraut. Das LLM versteht den Gesamtkontext eines Projekts nicht und produziert viele Unsinnsantworten (Halluzinationen), daher ist Verifikation nötig
Ich finde, die Codequalität von LLMs ist insgesamt oft deutlich unzureichend. Man muss mehrfach iterieren, sodass es oft schneller ist, es selbst zu schreiben. Für groß angelegte mechanische Refactorings sind Agenten aber extrem nützlich. Statt komplizierte vim-macros oder AST-Skripte zu schreiben, nutze ich dafür Agenten
Seit Monaten keine einzige Zeile Code mehr selbst zu schreiben, klingt für mich persönlich sehr langweilig
Du bestätigst damit im Grunde nur noch einmal die Behauptungen aus dem Blogpost (nicht verifizierbar, riesige Leistungsbehauptungen usw.). Es sieht auch so aus, als wäre der Account neu erstellt worden
Meiner Meinung nach besteht der Großteil echter Arbeit in der Dienstleistungswirtschaft aus manueller Tätigkeit wie dem Verschieben von Excel-Sheets oder dem Übertragen von Daten zwischen CRM/E-Mail und Excel. In Großunternehmen gibt es davon vermutlich hundertmal so viele Vollzeitkräfte wie Software Engineers. Deshalb ist es egal, wenn LLMs kein OCaml können; wenn sie in Excel nur ein bisschen besser sind als Menschen, entsteht riesiger Wert. Wenn man mit etwas wie MCP E-Mail, CRM und Excel verbindet und automatisiert, sinken Fehlerquote und Halluzinationen massiv. Menschen sind ebenfalls nicht deterministisch, deshalb ist Determinismus in solchen Prozessen nicht entscheidend. LLMs und Kryptowährungen unterscheiden sich bei Utility und Adoption völlig. Es erinnert mich an die Verbreitung von Smartphones. Selbst meine nichttechnischen Freunde nutzen LLMs inzwischen auf sehr viele Arten
Ich halte den Vergleich mit Kryptowährungen nicht für konstruktiv. Technisch hat das überhaupt nichts miteinander zu tun. Es gibt aber schon eine Tendenz zur Technologie-Überhöhung. Für Menschen, die bisher nicht einmal grundlegende Automatisierung erlebt haben, können LLMs wie Science-Fiction wirken. So mainstream war dieses Feld noch nie. Ich glaube, wir gehen jetzt in einen Wildwest-Moment mit Erfolgen, Misserfolgen, vielen Meinungen und Praxiserfahrungen. Der gute Teil daran ist: Die App-Idee eines Freundes kann man jetzt tatsächlich selbst ausprobieren
Auch FTEs, die manuelle Datenbereinigung machen, haben Ergebnisverantwortung, Fristen und rechtliche Haftung. LLMs können vorübergehende Ausnahmefälle (zum Beispiel, dass ein Wert an Feiertagen 0 sein sollte) nicht außerhalb des Kontexts erkennen und prüfen. Für solche Verifikation ist eine FTE-Stelle den Aufwand absolut wert
Ich frage mich, für welche Firmen das Verhältnis von 100 manuellen Data-Pipeline-FTEs pro Software Engineer gelten soll. Ich glaube nicht, dass der Großteil realer Backoffice-/Data-Entry-Arbeit ausmacht. Ich stimme der Wirkung von AI zu, bin aber skeptisch gegenüber der Behauptung, dass White-Collar-Arbeit insgesamt fast nur aus E-Mail und Dateneingabe besteht
Ich denke, du unterschätzt die Komplexität dieser Art von Tätigkeiten
Ich bin pensionierter Programmierer und kann mir nicht vorstellen, mission-kritische Verantwortung auf probabilistisch generierten Code zu legen. Wenn es nur darum geht, etwas zu bekommen, das sich mit ein wenig Nacharbeit verwenden lässt, kann ich das nachvollziehen. Außerhalb des Codens sind LLMs erstaunlich gut: Brainstorming, kreatives Denken, Unterstützung bei Recherche. Ich nutze LLMs als Denkpartner. Sie machen Fehler, aber die lassen sich leicht finden, wenn man mit anderen Quellen gegenprüft oder ein anderes LLM drüberschauen lässt
Ich bin eigentlich auch grundsätzlich skeptisch, aber als ich es tatsächlich genutzt habe, hat es meine Erwartungen in jeder Hinsicht übertroffen. In wenigen Stunden habe ich Projekte vom Prototyp bis zum Release gebracht, für die ich früher Monate gebraucht hätte. Dinge, die ich selbst kann, erledige ich schneller, und sogar Dinge, die ich nicht kann (für die ich früher Freelancer oder Neueinstellungen gebraucht hätte), schaffe ich jetzt schnell und zu geringen Kosten. Natürlich ist es nicht perfekt und hat nervige Seiten (ignoriert explizite Anweisungen, lügt usw.), aber für mich ist es ein Game Changer
Die Nutzung von LLMs als Denkpartner schien bei mir auch eine Weile gut zu funktionieren, aber irgendwann zeigt sich die Wahnhaftigkeit. LLMs bringen einen leicht dazu zu glauben, sie hätten Wissen oder würden schlussfolgern. Besonders gefährlich ist das in Bereichen, in denen ich mich nicht auskenne. Bei Suchmaschinen kann ich die Vertrauenswürdigkeit anhand der Quellen vergleichen, bei LLMs geht das nicht. Fehler zu erkennen ist auch nicht immer einfach
Ich bin Entwickler mit 40 Jahren Erfahrung und nutze LLMs seit ein paar Monaten; meine Arbeitsweise hat sich stark verändert. Log-Fehlermeldung hineinkopieren, in einer Minute einen Fix bekommen, Design-Brainstorming, neue Lösungsvorschläge usw. Den Code prüfe ich zwar, aber über die Genauigkeit und Intelligenz bin ich jeden Tag aufs Neue erstaunt. (Mit Kryptowährungen ist das überhaupt nicht vergleichbar)
Ich bin zwar LLM-Skeptiker, aber eigentlich ist auch jeder von Menschen geschriebene Code im Kern probabilistisch. Deshalb gibt es Code Reviews, Unit-Tests, Pair Programming und Guidelines. Weder LLM- noch Menschen-Output sollte man unkritisch übernehmen. Meine Sorge ist eher, dass LLMs nicht als hilfreiches Werkzeug, sondern als Magie missverstanden werden und dann Boilerplate aufblasen, während langfristige Werte wie Effizienz, Sicherheit oder Refactoring ignoriert werden
Meiner Meinung nach sind LLMs in der Data Science am stärksten. Die IO ist klar definiert, deshalb lassen sich Ergebnisse leicht überprüfen. Wenn man die Eigenschaften der Daten kennt, kann man auch leicht Testcode erzeugen lassen. Falls Kontext nötig ist, bringt Claude Code einen großen Unterschied. Beispiel: Aus einer PCAP-Datei mehrere Nachrichten pro UDP-Paket extrahieren, filtern, Pattern Matching, für Tests aufteilen usw. Wenn man sagt: „Schreib Unit-Tests für all diese Funktionen“, kann das LLM sich sogar selbst verifizieren
Ich nutze seit einem Jahr fast täglich LLMs, und in 90 % der Fälle lösen sie mein Problem. Ich weiß nicht, wann negative Meinungen zu AI/LLMs ernsthaft ernst zu nehmen sind. In meiner Erfahrung gibt man nicht einfach die gesamte Codebasis ein und erwartet Magie; ich stelle nur präzise und konkrete Fragen, die ich kenne und verstehe, und setze Lösungen so um, dass ich sie verifizieren kann. Wenn man das nicht so macht, nutzt man LLMs falsch. Wenn man Magie tatsächlich erleben will, liegt der Schlüssel in kleiner, alltäglicher und konsistenter Nutzung
Wie in einer Weatherman-Parodie: „Es funktioniert mit 60%iger Wahrscheinlichkeit immer.“ Auch ich nutze GPT und Claude jeden Tag in Cursor. GPT o3 ist gut für allgemeine Wissenssuche, Claude scheitert oft. Das Modell selbst ist ziemlich dumm, trifft aber manchmal den Kern. Wenn man selbst weiß, was man will, und das LLM gut zähmt, kann man damit produktiv arbeiten
Auch die Behauptung „In meiner Erfahrung klappt es zu 90 %“ finde ich schwer glaubwürdig
Ich glaube, der Autor ist wütend über ungenaue Kommentare von Debattierern. Tatsächlich kennen gerade die Nutzer = Promoter, die LLMs täglich einsetzen, deren Probleme und Grenzen sehr gut. Übersetzung, Transkription, Codegenerierung (bis zu einer gewissen Größenordnung) sind Probleme, die früher unmöglich oder fast unmöglich waren und jetzt vollständig oder fast vollständig gelöst sind
Waren Übersetzung, Transkription und Codegenerierung wirklich nahezu unmöglich? Es gab doch Google Translate, Whisper und Ähnliches schon lange, lautet der Einwand
Die tatsächlichen Mängel werden von detractors offengelegt, während die promoters LLMs eher unkritisch als Alleskönner anpreisen
In letzter Zeit finde ich die Verwendung der Begriffe AGI und AI besonders in wissenschaftlichen Arbeiten viel zu vage. Ich fände es gut, wenn jedes Paper zumindest seine eigene Definition klar angeben würde. Wenn man AGI sauber definiert, könnte man auch logisch beweisen, dass ein bestimmtes AI-System diese Definition erfüllt. Auch wenn das vielleicht praktisch wenig nützt, wäre es immer noch besser als bedeutungslose Begriffe. Im Moment wirkt es so, als würde AGI ohne Definition als Ausweichwort benutzt. Auf Wikipedia steht etwas wie „nahezu alle kognitiven Aufgaben auf menschlichem Niveau oder darüber“, aber das ist nicht messbar. Ich frage mich, warum man solche hohlen Begriffe überhaupt benutzt
Nicht jeder muss es im selben Sinn verwenden. Es reicht, wenn man für AGI seinen eigenen Maßstab hat (auch wenn die Mehrheit nicht zustimmt). Für mich bedeutet crypto ursprünglich auch cryptography. Mainstream und persönlicher Maßstab können auseinandergehen
Falls AI überhaupt eine Definition hat, dann vielleicht: „Dinge, die noch nicht erreicht wurden, nennt man AI“ – Verweis auf den AI effect
Wir haben in der Firma kürzlich begonnen, LLMs einzusetzen. Die erste Aufgabe war die Transkription von 20.000 Kundenservice-Anrufen und die Extraktion von Daten daraus (Vergleichsprodukte, Probleme, typische Use Cases usw.). Früher hätte diese Recherche Wochen gedauert, jetzt war sie in wenigen Stunden erledigt. Daraus haben wir sogar eine neue Business-Strategie entwickelt und tatsächlich großen Wert gezogen. Als Natural-Language-Processing-Engine sind LLMs extrem stark. Es gibt viel übertriebenes Marketing, aber für uns helfen sie ganz konkret. Es ist nur ein Werkzeug, und ich habe nicht das Gefühl, irgendwem etwas beweisen zu müssen
Ich glaube nicht, dass Hype völlig harmlos ist. Er kann Märkte verzerren, Überinvestitionen auslösen, Teams verkleinern und unrealistische Erwartungen schaffen. Solche Artikel sind nötig, um Markt und Erwartungen wieder abzukühlen. Die Leute, die LLMs verkaufen, sprechen meist nicht von der Zusammenfassung von Support-Anrufen, sondern von allen möglichen übertriebenen Szenarien, in denen Personal ersetzt wird
Nur Leute ohne Erfahrung darin, große Datenmengen auf verlässliche Weise zu verarbeiten, würden sagen, LLMs seien nutzlos. Auch Übersetzungen lassen sich jetzt viel kontextsensitiver erledigen
Auch vertrauenswürdige Leute aus der Tech-Branche sagen direkt, dass GenAI die Produktivität in der Entwicklung stark erhöht. Die Spannweite der Bedeutung ist groß, etwa von 5 % bis 100 %. Man sollte es zumindest als ziemlich nützliches Werkzeug akzeptieren. Für diese Behauptung braucht man meiner Meinung nach keine konkreten Zahlen wie Codezeilen, Bytes oder CPU
Auch die LLM-Technologie wird am Ende ihre richtigen Einsatzorte finden, aber inzwischen missbrauchen sie schon zu viele Menschen, sodass es nicht mehr umkehrbar ist. Unzählige Junior-Entwickler werden Risiken eingehen und scheitern, und enorme Investitionen werden verschwendet werden. Unternehmen können auch nicht mehr zurück und sind bereits komplett all-in gegangen