- Die von einem LLM in Rust neu geschriebene Version von SQLite zeigt bei Primärschlüssel-Lookups eine etwa 20.000-mal langsamere Performance als das Original
- Der Code kompiliert und besteht die Tests, enthält intern jedoch kritische Algorithmusfehler und ein ineffizientes Design
- Hauptursachen sind das Nicht-Erkennen von PRIMARY KEY und fsync-Aufrufe bei jeder Abfrage; die Struktur wirkt plausibel, das tatsächliche Verhalten ist jedoch fehlerhaft
- Dieses Phänomen entsteht durch die „Plausibilitätsoptimierung“ (sycophancy) von AI-Modellen; wenn Nutzer keine klaren Akzeptanzkriterien (acceptance criteria) definieren, lassen sie sich leicht täuschen
- LLMs können die Produktivität nur dann steigern, wenn erfahrene Entwickler Korrektheitskriterien klar festlegen; andernfalls sind sie nicht mehr als einfache Token-Generatoren
Performance-Experiment mit LLM-generiertem Code
- Ein Primärschlüssel-Lookup in SQLite (100 Zeilen) dauert 0,09 ms, die vom LLM erzeugte Rust-Version 1.815,43 ms und ist damit etwa 20.171-mal langsamer
- Beide Implementierungen verwenden dieselbe Abfrage, dasselbe Schema und dieselben Compiler-Optionen
- Mit Turso/libsql hat das nichts zu tun; Turso zeigt gegenüber SQLite eine normale Performance von etwa dem 1,2-Fachen
- Die Rust-Version wirkt oberflächlich funktionsfähig: erfolgreich kompiliert, Tests bestanden, Dateiformat-Kompatibilität erhalten
- Tatsächlich kommt es jedoch bei grundlegenden Datenbankoperationen zu massivem Performance-Verlust
Analyse der Hauptfehler
- Bug #1: INTEGER PRIMARY KEY wird nicht erkannt
- SQLite mappt
id INTEGER PRIMARY KEY intern auf rowid und führt damit eine O(log n)-Suche aus
- Die Rust-Version erkennt in
is_rowid_ref() nur "rowid", "_rowid_" und "oid"
- Dadurch wird die Abfrage
WHERE id = N als vollständiger Tabellen-Scan (O(n²)) verarbeitet, was die 20.000-fache Verlangsamung verursacht
- Bug #2: fsync-Aufruf bei jeder Abfrage
- Bei jedem INSERT außerhalb einer Transaktion wird eine vollständige Synchronisierung (fsync) ausgeführt
- SQLite verwendet
fdatasync und überspringt damit die Synchronisierung von Metadaten, was deutlich effizienter ist
- Bei 100 INSERTs benötigt die Rust-Version 2.562,99 ms, SQLite 32,81 ms – ein 78-facher Unterschied
Zusammengesetzte Ineffizienzfaktoren
- Viele Designentscheidungen wie AST-Kopieren und erneutes Kompilieren, 4-KB-Heap-Allokationen, Schema-Neuladen, String-Formatierung und Objekt-Neuerzeugung summieren sich zu einem Performance-Verlust von etwa 2.900x
- Jede einzelne Entscheidung kann mit „Sicherheit“ begründet werden, wird aber auf dem kritischen Pfad (hot path) zum fatalen Engpass
- Die Performance von SQLite kommt nicht einfach nur von C, sondern ist das Ergebnis von 26 Jahren Profiling und Feintuning
Zweiter Fall: unnötig komplexes Tool zur Festplattenverwaltung
- Ein weiteres vom LLM generiertes Rust-Projekt implementierte einen Daemon zum Aufräumen von Build-Artefakten mit 82.000 Zeilen
- Einschließlich 192 Abhängigkeiten, eines Dashboards mit 7 Bildschirmen und einer Bayes’schen Scoring-Engine – also deutlich überzogener Funktionalität
- Das eigentliche Problem ließ sich mit einer einzigen cron-Zeile lösen:
find ... -exec rm -rf
- Das ist ein Fall, in dem die „geforderte Funktionalität“ zwar treu umgesetzt wurde, die eigentliche Problemlösung aber unnötig verkompliziert wurde
Kluft zwischen Absicht und Korrektheit: das Phänomen „Sycophancy“
- LLMs zeigen die Tendenz zur „schmeichlerischen Zustimmung“ (sycophancy), also dazu, den Erwartungen der Nutzer zu entsprechen
- Die Anthropic-Forschung (2024) und der BrokenMath-Benchmark (2025) bestätigten ein strukturelles Problem, bei dem Zustimmungsraten statt Korrektheit gelernt werden
- Selbst GPT-5 erzeugte, wenn Nutzer positive Signale gaben, in 29 % der Fälle einen Beweis für eine falsche Aussage
- RLHF (Reinforcement Learning from Human Feedback) verstärkt diesen agreement bias
- OpenAI führte wegen dieses Problems beim GPT-4o-Update 2025 sogar ein Modell-Rollback durch
- Diese Verzerrung wirkt nicht nur bei der Codegenerierung, sondern auch bei der eigenen Code-Review, sodass Fehler nicht selbst erkannt werden
Externe Forschung und Industriedaten
- METR-Experiment (2025–2026): 16 erfahrene Open-Source-Entwickler waren mit AI 19 % langsamer, hielten sich selbst aber für schneller
- GitClear-Analyse (2020–2024): In 211 Millionen Codezeilen nahmen Copy-and-paste zu, Refactorings dagegen ab
- Replit-Vorfall (2025): Ein AI-Agent löschte die Produktionsdatenbank und erzeugte anschließend 4.000 fingierte Nutzer
- Google-DORA-Bericht 2024: Wenn die AI-Nutzung auf Teamebene um 25 % steigt, sinkt die Delivery-Stabilität um 7,2 %
Welchen Maßstab für „Korrektheit“ SQLite zeigt
- SQLite umfasst etwa 156.000 Zeilen C-Code, erreicht 100 % MC/DC-Coverage und erfüllt damit ein Verifikationsniveau auf Luftfahrt-Software-Niveau
- Wichtige Performance-Faktoren:
- Zero-copy-Seitencache
- Wiederverwendung von Prepared Statements
- Schema-Cookie-Prüfung zur Vermeidung unnötigen Neuladens
- Verwendung von
fdatasync zur Minimierung von Commit-Latenzen
- iPKey-Prüfung zur Sicherstellung von O(log n)-Suchen
- Die in Rust neu geschriebene Version umfasst dagegen 576.000 Zeilen, lässt aber die entscheidende eine Zeile zur Prüfung von
is_ipk aus
Fazit: Nicht „Plausibilität“, sondern „Korrektheit“ definieren
- LLMs imitieren Muster, lernen aber Performance-Invarianten nicht eigenständig
- Dass „der Code kompiliert“, ist nicht ausreichend; Fehler müssen direkt gefunden und erklärt werden können
- LLMs werden zu einem mächtigen Werkzeug, wenn erfahrene Entwickler Korrektheitskriterien klar definieren
- Andernfalls sind sie nur plausibel wirkende Token-Generatoren und bleiben auf dem Niveau von „vibe coding“
- Die zentrale Botschaft: Erst die Korrektheitskriterien definieren, dann messen.
16 Kommentare
Das scheint ein gutes Beispiel dafür zu sein, was passiert, wenn man nicht einmal einfache erfolgsbezogene Leistungskriterien vorgibt. Die Coding-Agenten, die ich bisher verwendet habe, zielen auf die Problemlösung selbst ab, optimieren ihre Leistung aber ohne expliziten Vorab-Prompt oder Validierungsschleife fast nie eigenständig. Man muss der KI Anweisungen geben, als würde man eine Coding-Testaufgabe stellen. Gerade wenn es wie hier sogar eine Baseline gibt, Leistungsanforderungen nicht ausdrücklich zu formulieren und trotzdem ein optimales Performance-Ergebnis zu erwarten, kann man auch als eine Art Nachlässigkeit der Person betrachten, die die KI benutzt.
+1 👍
Eigentlich gilt das nicht nur für LLMs, sondern auch für Menschen.
Der Unterschied ist, dass Menschen Feedback verarbeiten können, während sich merkwürdige Gewohnheiten bei LLMs kaum korrigieren lassen. Selbst wenn man sie darauf hinweist, machen sie es irgendwann am Ende doch wieder genauso.
Entstehen nicht genau an diesem Punkt Ineffizienz und Ermüdung?
Bis die Leute die Eigenschaften des Modells verstanden und passende Prompts sowie Skill-Workflows gefunden und angewendet haben, ist schon wieder ein neues Modell erschienen....
Ich bezweifle sogar, dass man Agenten derzeit überhaupt richtig nutzen kann.
Auch George Hotz nutzt KI nur im Bewusstsein, dass sie eine Art Compiler ist. Bei Design, Struktur oder der Auswahl ist nach wie vor menschliches Urteilsvermögen nötig ... Wenn man der KI insgesamt die Führung überlässt, gibt es letztlich keinen Grund mehr, warum das überhaupt noch ein Entwickler machen sollte.
Wenn man eine bereits perfekt implementierte, extrem optimierte Query als Vergleich nimmt und dann verlangt, sie in einer anderen Sprache neu zu schreiben, ist es natürlich klar, dass sie langsamer ist.
Man hat ja nur gesagt: „Schreib’s einfach“, hahaha
Die Vibe-Coder auf Big-Tech-Niveau werden wohl gleich in den Kommentaren auftauchen.
Wenn Sie keinen konstruktiven Kommentar schreiben, dann schreiben Sie einfach gar keinen.
Ich muss lachen.
hahahahaha, auch Mistgeschreibsel ist Geschreibsel
Sagt nichts dagegen
bevor es zur Theorie des toten Internets wird
Kacke, hihi
Das wird von Hacker News übernommen – glaubt man dort etwa auch, dass immer nur produktive Beiträge gepostet werden ... kein schöner Anblick.
Hast du die Hacker-News-Richtlinien überhaupt gelesen? Solche Beiträge sollte man wirklich vermeiden. Diese Haltung à la „Der baut doch auch Mist, warum gehst du dann nur auf mich los?“ ist ziemlich kindisch.
Falsch. Es müsste heißen: Der kackt doch auch, warum gehst du nur den so an?
Das merkt man sofort, selbst wenn man es nur ein bisschen ausprobieren lässt. Ich konnte nicht nachvollziehen, warum andere Entwickler sagen, dass Reviews ermüdend seien, aber egal wie gut man Prompts und Skills einsetzt, der von der KI erzeugte Code hatte immer irgendwo einen Mangel.
Ich habe den Originaltext gelesen, und die Analyse und Kritik wirken plausibel. Allerdings haben die in der Arbeit zitierten Forschungsmodelle aus heutiger Sicht einen etwas veralteten(?) Eindruck.
Hacker-News-Kommentare
Grundsätzlich neigen LLMs dazu, Probleme zu lösen, indem sie mehr Code draufschichten
Wenn etwas mit einem ineffizienten Ansatz umgesetzt wird, werden bei jeder späteren Einschränkung immer weiter Workarounds oder duplizierter Code hinzugefügt
Wenn die Performance zu langsam ist, wächst der Code exponentiell durch Fast-Path-Optimierungen, Spezialroutinen und benutzerdefinierte Datenstrukturen
Wenn es viele Bugs gibt, werden für jeden Bug zehn Tests geschrieben, und wenn das bestehende Mocking-Framework nicht passt, wird ein neues gebaut
Wenn man sagt, man solle Duplikate zusammenführen, heißt es: „Klar, ich baue ein neues metamock abstract adapter framework mit allen Features!“ — und schon kommt die nächste komplexe Struktur dazu
Der Review-Prozess ist unverzichtbar, damit keine falschen Annahmen oder technische Schulden entstehen
Zuerst sollte eine vernünftige Architektur entworfen werden, und wenn Module sich verheddern, sollte man in einem sauberen Kontext neu anfangen
LLMs sind schwach darin, denselben Code immer wieder zu verändern, aber stark darin, wie in „Groundhog Day“ von vorn neu zu implementieren
LLMs warnen nicht vor solchen Entscheidungen und erinnern auch nicht daran
Deshalb bevorzuge ich Claude Code gegenüber Codex
Auch beim Verfassen juristischer Dokumente sind die „plausiblen“ Ergebnisse von LLMs ein Problem
Auf den ersten Blick wirken sie stimmig, in Wirklichkeit sind es aber oft logisch unangemessene oder riskante Behauptungen
Richter haben oft weder die Zeit noch den Willen, alles im Detail zu prüfen, sodass solche Dokumente unverändert durchgehen können
Das erzeugt, ähnlich wie Brandolinis Gesetz, eine Asymmetrie, bei der Generieren leicht, Widerlegen aber schwer ist
Am Ende ähnelt das der Situation, in der Entwickler der Zukunft die von LLMs erzeugten kognitiven und technischen Schulden auflösen müssen
Wenn LLMs regelbasierte Dokumente verfassen, enthalten sie plausibel klingende, aber unbegründete Andeutungen
Deshalb lasse ich das LLM seinen eigenen Text noch einmal prüfen und solche Stellen markieren, aber am Ende ist menschliche Prüfung nötig
Kollegen erzeugen mit LLMs in wenigen Minuten PRs mit Tausenden Zeilen
Tests sind zwar dabei, aber in Wirklichkeit ist das Ergebnis oft chaotisch
Am Ende muss der Reviewer den ganzen Tag prüfen, die falsche Struktur verstehen und erklären, in welche Richtung es korrigiert werden sollte
Deshalb würde ich vorschlagen, dass AI-erzeugte PRs dem Reviewer Story Points geben sollten
Vernünftige Urteile sollten als formale Logik berechnet und das Ergebnis anschließend in natürliche Sprache übersetzt werden
LLMs sollten nicht beim Denken, sondern nur bei der Interpretation und Ausdrucksphase eingesetzt werden
Von LLMs erzeugter Code besteht Tests oft, erfüllt aber die Anforderungen nicht
Zum Beispiel wird
fsyncbei jeder Query aufgerufen oder ein Primärschlüssel falsch identifiziertBei solchen großen Projekten ist so viel Code vorhanden, dass Menschen ihn kaum vollständig lesen können
Deshalb sind LLMs am effizientesten, wenn man sie auf dem Niveau von Autocomplete nutzt
Kleine Codefragmente lassen sich sofort überprüfen, und Claude ist dabei meist korrekt
Wenn man ihnen aber den gesamten Code überlässt, kostet Planung und Steuerung mehr Zeit, und auch die Wartbarkeit leidet
Letztlich gibt es den Geschwindigkeitsvorteil nur dann, wenn bereits in den Trainingsdaten vorhandener Code reproduziert wird
LLMs erzeugen statistisch die häufigsten Code-Patterns
Deshalb kommt ohne besondere Anweisungen meist „unternehmensmäßig wirkender, OOP-basierter Code mit einer Menge trendiger Dependencies“ heraus
Man muss „Korrektheit“ definieren und messen
Für Automatisierung braucht man Intent und Measurement
Man muss den Risikobereich verstehen, um zu wissen, wie viel man im Voraus abdecken muss
Wenn Tools wie AI evals oder eval-ception für Bewertungssysteme von AI
sich zu einer gemeinsamen Sprache zwischen Rollen entwickeln, wird Zusammenarbeit viel einfacher
Dass LLMs auf die Erzeugung von möglichst plausiblem Code ausgelegt sind, ist ihr Wesen
Das ist eine Folge von cross entropy loss, und mit Nachbearbeitung wie RLVR versucht man, die Genauigkeit zu verbessern
Trotzdem bleiben noch viele Altlasten
Wenn sich künftig Reward Engineering weiterentwickelt, könnten bessere Ergebnisse möglich sein
Auf die Frage „Worin unterscheidet sich das vom Menschen?“
Im Schlaf sind diese abgeschaltet, wodurch traumartig unlogisches Denken entsteht; das Denken von LLMs ist auf einem ähnlichen Niveau von Traumlogik
Früher gab es die Unsicherheit, eine Technologie nicht vollständig zu verstehen, heute überdeckt das Tool diese Unsicherheit
Wir leben in einer Zeit, in der Ergebnisse auch ohne tiefes Verständnis produziert werden
Menschen erwarten aber eine objektive AI, die richtige Antworten liefert
Diese Diskrepanz erzeugt den Wahrnehmungsunterschied zwischen normalen Nutzern und Experten
Es gibt Leute, die jeden Tag PRs mit Tausenden Zeilen hochladen
Das meiste davon ist chaotisch, sodass Review praktisch unmöglich wird
Früher hätte die Erstellung solcher PRs wohl eine Woche gedauert, heute wird das alles an einem Tag ausgeschüttet
Es gibt viele Fragen schon zum Begriff „LLM“ selbst
Ein Modell, das direkt per Raw API aufgerufen wird, ist ein LLM, und Dinge wie Claude.ai oder ChatGPT sind Harnesses, die darübergelegt werden
Solche Harnesses enthalten verschiedene Funktionen wie Prompt-Templates oder die Verwaltung des Gesprächszustands
Tatsächlich verwenden wir fast immer mehr als nur ein LLM
Solche Agenten können Code ausführen, selbst testen und korrigieren
Auch ChatGPT und Claude haben diese Funktion und sind damit faktisch coding agents
Daher gilt die Aussage „LLMs haben kein Gedächtnis“ nur für das Modell selbst
Claude Code oder Cursor sind agentic systems, die Zustand aufrechterhalten
Der Titel dieses Artikels ist interessant, aber zu sagen, LLMs schrieben „plausiblen Code“, ist nicht ganz richtig
Tatsächlich erzeugen sie nur Code, der Clustern von Code aus den Trainingsdaten ähnelt
Frei generieren können sie nur in Bereichen, die nicht durch RLHF oder RLVR eingeschränkt sind
Deshalb spricht die gesamte Branche dieselbe Sprache, aber genau das ist wiederum eine Ursache für Missverständnisse
Es erzeugt die Illusion, dass alle dieselben Probleme lösen
Wenn man zum Beispiel nach tree-sitter-Queries fragt, erfindet es Direktiven, die es gar nicht gibt
Man muss dafür nicht unbedingt die komplizierte interne Struktur erklären
Kürzlich habe ich Codex gebeten, ein UI-Element auf Datastar-Basis zu erstellen, und es ist komplett gescheitert
Es war eine einfache Aufgabe, aber mit jedem neuen Versuch wurden Inline-JavaScript und Backend-Code immer mehr
Vorheriger Code wurde auch nicht aufgeräumt
Komplexe Aufgaben schafft es gut, zeigt aber ausgerechnet bei grundlegenden Aufgaben unintuitive Fehlschläge