- Martin Fowler weist darauf hin, dass aktuelle Umfragen zur Nutzung von LLMs den tatsächlichen Nutzungsablauf oft nicht abbilden und dadurch zu verzerrten Schlussfolgerungen führen können
- Auf Fragen zur Zukunft des Programmierens oder zur Jobsicherheit gilt: Noch weiß es niemand mit Sicherheit, und es ist wichtig, selbst zu experimentieren und Erfahrungen zu teilen
- Die KI-Branche befindet sich eindeutig in einer Blase, doch wie bei allen technologischen Umbrüchen in der Geschichte können auch nach dem Platzen der Blase überlebende Unternehmen wie Amazon entstehen
- Das Wesen von LLMs ist Halluzination, und schon der Prozess, Fragen mehrfach umzuformulieren und Antworten zu vergleichen, ist nützlich
- LLMs erweitern die Angriffsfläche von Softwaresystemen erheblich; besonders Browser-Agenten bergen laut Warnung ein strukturelles Risiko, das sich nicht grundsätzlich sicher machen lässt
Nutzungsweisen von LLMs und Produktivität von Entwicklern
- In letzter Zeit wird intensiv über die Auswirkungen von KI auf die Softwareentwicklung in ersten Untersuchungen diskutiert
- Der Großteil der LLM-Nutzung konzentriert sich auf hochentwickelte Autovervollständigung in Form von Co-Piloten
- Tatsächlich bevorzugen diejenigen, die LLMs am effektivsten einsetzen, jedoch einen Ansatz, bei dem LLMs Quellcodedateien direkt lesen und ändern können
- Untersuchungen, die Unterschiede in der Nutzung von LLMs ignorieren, bergen ein hohes Risiko, Daten in die falsche Richtung zu interpretieren
- Zusätzlich machen Funktionsunterschiede zwischen verschiedenen LLM-Modellen die Interpretation der Ergebnisse noch schwieriger
Programmierberufe und die Zukunft von LLMs
- Häufig werden Fragen zur Zukunft des Programmierens, zum Bedarf an Junior Engineers und zur Zukunft erfahrener Fachkräfte gestellt
- Darauf gibt es keine klare Antwort, denn eine etablierte Methode für den effektiven Einsatz von LLMs existiert bislang noch nicht
- Nötig ist eine experimentelle Herangehensweise sowie die Haltung, konkrete Workflow-Erfahrungen anderer zu beobachten und zu teilen
- Es selbst auszuprobieren und Erfahrungen auszutauschen, ist die klügste Form der Anpassung
Blasenphänomen im Bereich KI und LLM
- Zur Ansicht, KI sei eine Blase, wird erläutert, dass jede technologische Innovation von Blasenphänomenen begleitet wird
- Eine Blase platzt irgendwann zwangsläufig, und Fehlinvestitionen treten auf
- Doch der Zeitpunkt des Platzens und das Ausmaß der Wertschöpfung lassen sich nicht vorhersagen
- Auch wenn die Blase platzt, verschwinden nicht alle Unternehmen; einige können sogar dauerhaft weiterwachsen
- Während der Dotcom-Blase scheiterten pets.com und Webvan, während Amazon überlebte und weiterwuchs
Die Halluzinationseigenschaft von LLMs
- Das Halluzinationsphänomen von LLMs ist kein Fehler, sondern eine wesentliche Eigenschaft
- LLMs sind letztlich Werkzeuge zur Erzeugung von nützlichen Halluzinationen
- Es ist sinnvoll, dieselbe Frage mehrfach und in unterschiedlicher Formulierung zu stellen, um mehrere Antworten zu erhalten und zu vergleichen
- Wenn numerische Antworten nötig sind, ist es wichtig, durch wiederholte Anfragen die Schwankung zwischen Antworten zu prüfen
- LLMs direkt auf deterministisch berechenbare Probleme antworten zu lassen, ist nicht angemessen
Einführung von Nichtdeterminismus in die Softwaretechnik
- Traditionelle Softwaretechnik wird in einer deterministischen Umgebung entworfen und umgesetzt
- Struktur- und Prozessingenieure berücksichtigen in der Realität Nichtdeterminismus (Unsicherheit) und planen entsprechende Toleranzen ein
- Die Einführung von LLMs könnte ein Wendepunkt sein, an dem die Softwaretechnik in die Welt des Nichtdeterminismus eintritt
Vergleich von LLMs mit Junior-Entwicklern
- LLMs werden oft mit Junior-Kollegen verglichen
- Doch LLMs behaupten oft, „alle Tests bestanden“ zu haben, obwohl in Wirklichkeit fehlgeschlagene Tests häufig auftreten
- Bei einem Menschen wäre das ein Verhalten, das schnell zu personellen Konsequenzen führen würde
Zunehmende Sicherheitsbedrohungen und das Problem von Browser-Agenten
- LLMs erweitern die Angriffsfläche von Softwaresystemen massiv
- Die von Simon Willison benannte 'tödliche Dreierkombination (Trifecta)' besteht aus Zugriff auf nicht öffentliche Daten, externer Kommunikation und Kontakt mit nicht vertrauenswürdigen Inhalten
- Über in Webseiten versteckte Anweisungen (z. B. 1pt große weiße Schrift) lassen sich LLMs täuschen, um sensible Informationen preiszugeben
- Browserbasierte Agenten sind besonders riskant; böswillige Aktionen wie Kontotransfers durch externe Anweisungen sind möglich
- Willison vertritt die Ansicht, dass agentenartige Browser-Erweiterungen grundsätzlich nicht sicher gemacht werden können
Fazit
- LLMs eröffnen der Softwareentwicklung neue Möglichkeiten, doch Nutzungsweise und Grenzen müssen klar verstanden werden
- Blasen sind unvermeidlich, können aber dennoch zu nachhaltigem technologischem Fortschritt führen
- Entwickler sollten das Potenzial von LLMs durch einen experimentellen Ansatz und unter Berücksichtigung der Sicherheit bestmöglich ausschöpfen
3 Kommentare
Schon der Gedanke daran ist bedrückend…
Ich stimme insbesondere der Analogie mit Juniors zu 100 % zu. Die Kategorien der Fehler, die sie machen, unterscheiden sich von denen von Menschen ... ich halte das für eine typische misslungene Analogie.
Hacker-News-Kommentare
Meine frühere Kollegin Rebecca Parsons sagt schon seit Langem, dass Halluzinationen bei LLMs weniger ein Bug als vielmehr eine Kernfunktion sind. Tatsächlich besteht das, was LLMs tun, darin, nützliche Halluzinationen zu erzeugen. Jedes Mal, wenn ich so eine Behauptung höre, habe ich das Gefühl, dass der Begriff „Halluzination“ nach Belieben umdefiniert wird, sodass es wie eine neue Einsicht wirkt. Bisher bedeutete „Halluzination“, Details zu erzeugen, die nichts mit der Realität zu tun haben, sie aber plausibel wie eine Wahrnehmung erscheinen zu lassen. Diese Logik läuft jedoch einfach nur auf „Ausgabe“ hinaus. Es ist nichts Neues daran, dass LLMs Ausgaben erzeugen; man nimmt nur ein Label, das bisher als „nicht gut“ galt, hängt es an das gesamte Verhalten und lässt es dadurch neu erscheinen
Ich denke nicht, dass Fowler den Begriff „Halluzination“ wirklich umdefiniert. Vielmehr betont er ironisch, dass Halluzination die grundlegende Arbeitsweise dieser Systeme ist. So ähnlich wie bei der Formulierung „Kollateralschäden sind wesentlicher Bestandteil von Bomben“ – man muss das nicht wörtlich nehmen
Diese Behauptung soll die falsche Dichotomie korrigieren: „LLMs erzeugen entweder Wahrheit oder Halluzinationen.“ Solche Aussagen lassen es so aussehen, als bliebe nur Wahrheit übrig, wenn man Halluzinationen reduziert. Tatsächlich ist aber jede Ausgabe eine Art Halluzination. Einige davon spiegeln nur die Realität wider oder passen zu Erwartungen und erscheinen deshalb wahr. Das ist so, als würde man beim Würfeln sagen: „Der Würfel hat meine Absicht gelesen“, nur weil die gewünschte Zahl fällt. Wie bei unendlich vielen Affen an unendlich vielen Schreibmaschinen, die irgendwann Hamlet erzeugen – nur dass man diese Wahrscheinlichkeit mit AI erhöht hat
Ich fand diese Sichtweise interessant. Dass anerkannt wird, dass LLMs nicht wissen können, ob das, was sie ausgeben, korrekt ist, liefert Menschen, die LLMs in der Softwareentwicklung einsetzen, einen praktischen Kontext
Es war mir unangenehm, dieses Phänomen mit dem Wort „Halluzination“ zu beschreiben. Wenn Menschen ohne Grundlage plausibel klingende Dinge erfinden, nennen wir das „bullshit“ – und bei LLMs ist es im Grunde ähnlich. Mit der Perspektive von „bullshit“ verliert Kritik an der Nutzung von LLMs etwas an Schärfe. Wenn einen dieser Aspekt von LLMs stört, wird man letztlich auch kaum mit Menschen arbeiten können. Allerdings ist es deutlich schwieriger, das Wort „bullshit“ neu zu definieren. Trotzdem erfüllt der Text als Sammlung loser Gedanken seinen Zweck, und ich habe nicht den Eindruck, dass der Autor autoritär wirken will
Etwas unbeholfen formuliert, aber der Kern ist, dass es zwischen „halluzinierten“ Ausgaben und anderen Ausgaben eigentlich keinen klaren Unterschied gibt. So wie in einem RDBMS zwei Query-Ergebnisse im Wesentlichen gleichartig sind. Das ist ein sinnvoller Hinweis
In unserem Unternehmen fühlt es sich so an, als hätten wir eine Flut von Code, der zu 90 % okay ist, zu 10 % kaputt und fast auf dem gewünschten Niveau liegt. Die produzierte Code-Menge ist gestiegen, aber niemand kommt hinterher, und die Qualität sinkt eindeutig. Man nähert sich dem Ziel nicht langsam an, sondern ist sofort bei 90 % und verbringt dann Zeit damit, sich in fremden Code einzuarbeiten und ihn immer weiter zu korrigieren. Vielleicht ist das am Ende trotzdem schneller als früher, aber in der Praxis ist der Unterschied zwischen beiden Vorgehensweisen womöglich kleiner, als man denkt. Was mich am meisten stört: Ich erschaffe lieber etwas Neues, als Zeit damit zu verbringen, mir unbekannten Code zu reparieren
Ich ziehe es ebenfalls klar vor, etwas Neues zu bauen. Manche empfinden diese neue schnelle und improvisierte Arbeitsweise aber als angenehmer. Ich habe es notgedrungen kurz ausprobiert, empfand es als fremd, alles gelöscht und es dann mit AI-Unterstützung manuell neu gebaut – und genau das war wirklich befriedigend. Der einzige AI-generierte Code, den ich noch nicht zu 100 % verstanden habe, ist eine komplexe SQL-Query. Damit kann ich aber leben, weil sich SQL-Queries schnell auf korrektes Verhalten prüfen lassen und keine unerwarteten Nebenwirkungen haben
Dieses Phänomen ähnelt schmerzhaft dem, was passiert, wenn ein Team von 3 auf 10 Personen wächst. Plötzlich strömt Code herein, den man nicht kennt, die architektonische Konsistenz nimmt ab, und man verlässt sich stärker auf Regeln und CI. Der Unterschied bei LLMs ist, dass Mentoring oder Entlassungen keine Bedeutung haben. Eine effektive Nutzung von LLMs bedeutet, dass die Person, die sie einsetzt, 100 % Verantwortung für das Generierte übernimmt. Das heißt, sie muss den erzeugten Code klar verstehen – und es ist schwer, das in der Praxis sicherzustellen
LLMs sind hervorragend darin, Boilerplate-Code automatisch zu erzeugen. Das macht einen nachlässig beim Aufräumen von Boilerplate. Wenn riesige Mengen Code als PR hochgeladen werden, ist auch das Review schwierig. Github eignet sich ebenfalls nicht dafür, zu viele Zeilen auf einmal zu reviewen. Dadurch verbringen Junior- und Mid-Level-Entwickler ihre Zeit nur noch mit dem Auflösen von Boilerplate und verlieren Lerngelegenheiten. So wird sich die Code-Qualität schnell verschlechtern
Zitat von Perlis, Aphorismus 7: „Es ist leichter, ein falsches Programm zu schreiben, als ein richtiges zu verstehen“<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
Ich stimme der Einschätzung „Die Qualität sinkt eindeutig“ zu, und dieses Phänomen wird sich in Zukunft wohl noch verstärken. Am Ende muss man das ökonomische Konzept von Trade-offs gut verstehen, um beurteilen zu können, ob wirklich ein „Nettogewinn“ entsteht. Viele scheinen zu übersehen, dass es kein kostenloses Mittagessen gibt
Das Framing von Rebecca Parsons – „Halluzination ist die Kernfunktion von LLMs“ – spricht mich sehr an. Ich habe auch versucht, das Menschen in meinem Umfeld zu erklären, und dieser Satz fasst genau das zusammen, was ich sagen wollte
Ich habe LLMs gegenüber Familie und Freunden ebenfalls als Schauspieler oder Darsteller beschrieben. LLMs spielen lediglich passend zur Rolle; auf Fakten greifen sie nur dann zurück, wenn Fakten benötigt werden<br>https://jstrieb.github.io/posts/llm-thespians/
Das alte Bonmot passt hier perfekt: „Alle Modelle sind falsch. Manche sind nur nützlich.“
Intelligenz ist die Fähigkeit, unnötige Informationen herauszufiltern. Das gilt gleichermaßen für Gedanken wie für Sinneseindrücke
Ich weiß nicht mehr, wer es gesagt hat, aber die Ausgabe eines LLM ist immer eine Halluzination. Es ist nur so, dass über 90 % davon richtig wirken
Für einen Moment fühlte es sich so an, als würden LLMs uns die Arbeit wegnehmen. Tatsächlich habe ich aber erkannt, dass sie eher Berge von Arbeit erzeugen können, die wir später wieder ausbessern müssen. Inzwischen nutze ich sie mit praktischen Hilfswerkzeugen wie Claude Code gut und merke, dass sie kein Ersatz, sondern ein Mittel zur Ergänzung sind
Ich habe den Rat gesehen: „Wenn du von einem LLM eine numerische Antwort willst, frag ungefähr dreimal nach.“ Das funktioniert auch bei Menschen. Wenn die Polizei jemanden verhört, lässt sie dieselbe Geschichte dreimal erzählen oder auch rückwärts. Wenn gelogen wird oder die Erinnerung unscharf ist, kann die Person sich bei Wiederholungen verraten. Auch in Interviews kann man prüfen, ob jemand ein Thema wirklich verstanden hat, indem man sich drei verschiedene Erklärungen geben lässt
Diese Technik kann auch unschuldige Menschen verwirren und sie dadurch wie Lügner wirken lassen. Man sollte sie vorsichtig anwenden
Diese Vorgehensweise ist nur unter bestimmten Bedingungen sinnvoll. Es gibt viele Fälle, in denen Erinnerungen umso stärker verzerrt werden, je häufiger man sie abruft und wiedergibt. Wenn die Polizei wiederholt dieselbe Frage stellt, geschieht das mitunter absichtlich, um Widersprüche in Aussagen hervorzurufen. Selbst bei identischen Informationen kann man irgendwann Fehler machen, wenn man sie zu oft und auf zu viele verschiedene Arten selbst beantworten muss. Man sollte außerdem immer bedenken, dass Fragesteller Antworten in eine bestimmte Richtung lenken können
Das NASA-Space-Shuttle nutzte Triple Modular Redundancy. Das diente als Absicherung für den Fall, dass Prozessoren oder Speicher durch Weltraumstrahlung verfälscht wurden<br>https://llis.nasa.gov/lesson/18803
Ich erlebe mit LLMs eine ziemlich hohe Produktivität. Nicht nur einfaches Autocomplete, sondern eine deutliche Zeitersparnis. Gleichzeitig mache ich mir Sorgen, dass zu freier Einsatz seine ganz eigenen Schulden erzeugen kann. Für mich persönlich war es erfolgreich, mit Claude Sonnet oder GPT-5 im Stil von Test Driven Development (TDD) Funktionen schrittweise aufzubauen. Es gibt dazu noch nicht viele Texte oder Diskussionen, aber nachdem ich Martins Artikel gelesen habe, verstehe ich wohl warum. Sehr starke TDD-Praktiker sind offenbar nicht gerade der Typ, der massenhaft in LLM-basierte Code-Automatisierung springt; meist sind sie stolz auf die handwerkliche Qualität von Code und auf menschliche Kommunikation. Deshalb fehlt es im Vergleich zu früher noch an reichlich praxiserprobtem Know-how. In Zukunft wird sich wohl eine neue „Prärie“ dafür öffnen, wie man mit LLM-Tools Software schreibt, und ich erwarte, dass sich dabei viele Erkenntnisse ansammeln. Referenz: https://news.ycombinator.com/item?id=45055439
Entwickler sollten von LLMs erzeugten Code grundsätzlich selbst verifizieren und prüfen. Man sollte nicht zu viel Code auf einmal anfordern, sondern LLMs lieber in kleineren Einheiten nutzen. Auch Unit-Tests führe ich selbst aus. Wenn ein LLM Tests startet und sagt „erfolgreich“, muss das nicht echt sein. Vertrauen habe ich erst, wenn ich die Tests selbst laufen lasse
Ich stimme der Aussage zu, dass „Halluzinationen die Funktion von LLMs sind“
Ich würde es so ausdrücken, dass LLMs in einer Welt leben, die nur aus Text und Kombinationen besteht. Wörter, andere Wörter und Geschichten – das ist für sie die ganze Welt. Deshalb sind sie am stärksten darin, neue Geschichten zu erzeugen. Diese Geschichten sind manchmal ungenau und widersprüchlich, sodass sie letztlich auf Vermutungen beruhen. LLMs können Zahlen nicht wirklich zählen, aber sie kennen Muster wie „2 kommt nach 1“ und „3 ist größer als 2“. So wie Menschen Taschenrechner benutzen, können auch sie über Werkzeuge rechnen. In Zukunft braucht es nicht nur arithmetische Engines, sondern eine „epistemic engine“, die Logik, Widerspruchsvermeidung und die sichere Unterscheidung von Fakten unterstützt, damit AI wirklich vertrauenswürdig werden kann
Aus dieser Perspektive könnte man LLM-Agenten einfach als Mittel sehen, um halluzinierte Ergebnisse herauszufiltern
Ich stimme eher der Formulierung zu: „Die Ausgabe aller (großen Sprach-)Modelle ist Halluzination. Ein Teil davon ist nur nützlich.“ Weil der Anteil dieser nützlichen Halluzinationen sehr hoch ist, kam es überhaupt zum AI-Boom
Ich finde, das ist eine zu starke Vereinfachung
Genau deshalb ist der Begriff „Halluzination“ auch immer umstritten. Er erzeugt die Illusion, dass manche Ergebnisse vielleicht keine „Halluzination“ seien, obwohl in Wirklichkeit jede Ausgabe eines LLMs gedankenlos erzeugt wird
Derzeit braucht es bei der Nutzung von LLMs eher Senior-Entwickler, die logisch gegenprüfen können, um die gewünschten Ergebnisse zu bekommen. Wenn künftig Juniors verschwinden, frage ich mich, wer dann die Rolle der Seniors übernehmen soll. Letztlich gehe ich davon aus, dass LLMs irgendwann ausreichend selbst programmieren werden. Im jetzigen Stadium sind sie definitiv gute Hilfsmittel, aber kein Ersatz
Zum Rat, einem LLM mehrfach dieselbe Frage zu stellen: Wenn man macOS nutzt, würde ich einen Alfred-Workflow empfehlen. Mit command + space und dann
llm <Prompt>kann man in Browser-Tabs auf einmal mehrere gewünschte LLMs starten, etwa perplexity, deepseek (lokal), chatgpt, claude oder grok. So lässt sich Fowlers Idee des Cross-Checkings zwischen LLMs schnell und effizient umsetzen, und mit der Zeit merkt man auch, welches LLM für welche Aufgaben besonders gut ist