- Der Redis-Gründer antirez nutzt AI und LLMs häufig, ist aber der Ansicht, dass die menschliche Problemlösungsfähigkeit zum aktuellen Zeitpunkt LLMs noch weit überlegen ist
- Beim Beheben eines komplexen Bugs in den Redis Vector Sets hat er die Grenzen von LLMs direkt erlebt
- Die von LLMs vorgeschlagenen Algorithmen bleiben bei standardisierten oder einfachen Lösungen
- Der kreative Ansatz menschlicher Entwickler ist im Vorteil, wenn es darum geht, innovative Lösungen vorzuschlagen, die für LLMs schwer erreichbar sind
- LLMs sind als Validierung von Ideen oder Gesprächspartner sehr nützlich, aber die letztendliche Kreativität liegt beim Menschen
Einleitung: Vergleich zwischen Mensch und LLM
- Ich habe keinerlei Abneigung gegen AI und LLMs
- Ich nutze LLMs seit langer Zeit im Alltag und setze sie auf verschiedene Weise ein, etwa zum Testen von Ideen, für Code-Reviews und zur Suche nach Alternativen
- Das aktuelle Niveau von AI ist eindeutig praktisch und beeindruckend, doch ich betone, dass der Abstand zur menschlichen Intelligenz weiterhin groß ist
- Ich habe diesen Text geschrieben, weil ich zuletzt das Bedürfnis hatte, dies zu sagen, da eine ausgewogene Diskussion über AI immer schwieriger wird
Der Bug in den Redis Vector Sets
- Vor Kurzem war ich damit beschäftigt, einen Bug in den Vector Sets von Redis zu beheben
- Während meine Redis-Kollegen abwesend waren, habe ich eine zusätzliche Schutzfunktion gegen Dateibeschädigung (RDB/RESTORE) eingeführt
- Sie ist standardmäßig deaktiviert und dient als zusätzliches Sicherheitsnetz, um Beschädigungen zu verhindern, selbst wenn die Prüfsumme erfolgreich ist
- Das Problem entstand bei der Geschwindigkeitsoptimierung der Serialisierung der Graph-Repräsentation der HNSW-Struktur in RDB
- Die Verbindungslisten zwischen Knoten werden als Ganzzahlen gespeichert und bei der Deserialisierung wieder in Pointer zurückverwandelt
- Aufgrund einer Eigenschaft der HNSW-Eigenimplementierung (garantierte Gegenseitigkeit der Verbindungen) können bei Graph- oder Speicherkorruption folgende Probleme auftreten
- Es wird gespeichert, dass A mit B verbunden ist, aber B ist nicht mit A verbunden (etwa wegen eines Nummerierungsfehlers)
- Wenn Knoten B gelöscht wird, bleibt aufgrund der verletzten Gegenseitigkeit ein Link A→B bestehen, was später bei der Suche nach B->A zu einem use-after-free-Bug führt
- Nach dem Laden der Daten muss überprüft werden, ob alle Links die „gegenseitige Verbindung“ erfüllen
- Bei Anwendung eines rein algorithmischen Ansatzes ergibt sich eine Komplexität von O(N^2). Bei großen Datenmengen (~20 Millionen Vektoren) verdoppelte sich die Ladezeit nachweislich von 45 auf 90 Sekunden
Einsatz von LLMs und ihre Grenzen
- Ich habe mit Gemini 2.5 PRO gechattet, um nach einer effizienteren Methode zu fragen, und die Vorschläge des LLMs geprüft
- Der erste Vorschlag des LLMs: die Listen benachbarter Knoten sortieren und dann binäre Suche (binary search) anwenden (eine bereits weithin bekannte Methode)
- Da dies keine große Verbesserung brachte, bat ich um weitere Ideen, erhielt aber keine bessere Antwort
- Ein von mir vorgeschlagener alternativer Ansatz: Registrierung und Entfernung von Link-Paaren (A:B:X, sortiert und ohne Unterscheidung der Richtung) mithilfe einer Hash-Tabelle
- Das LLM bewertete dies ebenfalls als gute Idee, wies jedoch auf Nachteile wie die Performance der Schlüsselerzeugung und des Hashings hin
- Zusätzlich schlug ich vor, feste Schlüssellängen ohne
snprintf und stattdessen mit memcpy zu verarbeiten, um die Effizienz zu steigern
Menschliche Kreativität vs. Grenzen von LLMs
- Ich schlug die Idee vor, eine XOR-Technik auf einen Akkumulator anzuwenden, ganz ohne Hash-Tabelle
- Pointer-Paare (sowie Ebeneninformationen) werden per XOR in den Akkumulator eingebracht; bei gegenseitigen Verbindungen heben sie sich auf (0), bei fehlenden bleibt ein Muster zurück
- Allerdings wies ich auf mögliche Kollisionen und die Vorhersagbarkeit von Pointern hin (dem stimmte auch das LLM zu)
- Weitere Verbesserung: Kombination mit zufälligem Seed/Hashing (murmur-128 und
urandom-Seed) und Anwendung von XOR auf einen 128-Bit-Akkumulator
- Am Ende wird anhand dessen, ob der Akkumulator den Wert 0 hat, entschieden, ob die gegenseitige Verbindung erfüllt ist
- Das LLM bewertete diesen Ansatz als effizient und zugleich robust gegenüber allgemeinen Fehlern und externen Angreifern
Fazit
- Abschließend wurde die Analyse beendet, um auf Basis der Zuverlässigkeitsbewertung über die Einführung zu entscheiden
- In diesem Fall zeigte sich, dass der kreative, nicht standardisierte Ansatz menschlicher Entwickler den begrenzten Antworten eines LLMs überlegen war
- LLMs sind als Validierung von Ideen und intellektueller Gesprächspartner („smarte Ente“) äußerst nützlich
- Doch bei der Fähigkeit, die letztlich kreative Lösung abzuleiten, ist die Überlegenheit des Menschen klar
7 Kommentare
Dann wird Redis wohl bald abgehängt.
Fühlt sich an, als würde man ein Fahrrad gegen Laufen antreten lassen.
antirez gehört zu den besten 1 % der menschlichen Entwickler. Ich denke, dass die besten 1 % der menschlichen Entwickler LLMs weiterhin überlegen sein werden. Aber wie es bei den übrigen 99 % aussieht, weiß ich nicht.
Ich habe schon mehrfach versucht, mithilfe von KI Troubleshooting zu betreiben, bin dabei aber komplett gescheitert und habe das Problem am Ende selbst gelöst.
Dass LLMs hochwertig und kreativ wirken, liegt meiner Meinung nach daran, dass sie solche Texte gelernt haben, und daran, dass zahlreiche Wissenschaftler dieses Wissen überprüft und das Niveau der Trainingsdaten verbessert haben, um die Ergebnisse zu steigern.
Aber weil sich Trends mit der Zeit ändern oder je nach Situation andere Kreativität gefragt ist, muss am Ende nicht doch der Nutzer selbst Kreativität entfalten, die zu seiner eigenen Situation passt..
Hacker-News-Kommentare
Das entspricht ziemlich genau meiner Erfahrung. Der große Wert von LLM-Assistenten für mich besteht eigentlich darin, dass sie als ziemlich intelligenter „Rubber Duck“ fungieren. Manchmal widerspricht mir diese „Ente“ sogar und hilft mir dabei, meine Gedanken weiter zu verfeinern. (Was ist Rubber-Duck-Debugging?) Aber ich finde, die Kernfrage, die alle gern überspringen, lautet: „Wird dieser Wert auch in zwei Jahren noch bestehen?“ Darauf kenne ich selbst keine Antwort.
Für mich ist ein LLM kein Rubber Duck, sondern eher eine „Falschantwort-Maschine“. Es heißt ja, der beste Weg, im Internet eine Antwort zu bekommen, sei, eine falsche Antwort zu posten — genau diese Rolle übernimmt es für mich. Wenn ich dem LLM einfache, aber lästige Aufgaben gebe, liefert es so grotesk falsche Ergebnisse, dass ich irgendwann genervt bin und es aus blankem Frust einfach selbst mache.
Eine Ente mit übertriebenem Selbstvertrauen, die viel mehr Sicherheit ausstrahlt, als ihre tatsächlichen Fähigkeiten rechtfertigen. Ich habe schon viel zu viele Leute gesehen, die sich im Gespräch mit einem LLM verirrt haben.
Für mich ist ein LLM wie ein Junior-Entwickler, der unter mir arbeitet: kennt APIs gut, hat aber beim Thema Architektur zu wenig gesunden Menschenverstand. Ich prüfe die meisten PRs gleich drei- bis viermal, weil ich Angst vor absurden Fehlern habe, bevor ich sie überhaupt ins Team-Review gebe. Der Vorteil ist, dass ich mein Gehirn in der Zeit auf andere Probleme richten kann.
Ob dieser Wert in zwei Jahren noch da ist? Für mich ist die größere Sorge nicht „Wird dieses Gespräch dann noch relevant sein?“, sondern eher: „Kommen wir überhaupt bis in zwei Jahren?“ Die Welt ist gerade so instabil, dass man nicht einmal vorhersagen kann, wie sie in sechs Monaten aussieht.
Für mich fühlt sich ein LLM wie ein Pair-Programming-Partner an. Jemand, mit dem ich Ideen besprechen kann, der Code Reviews macht und Alternativen vorschlägt. Und ich kann etwas lernen, weil es Funktionen verwendet, die ich noch nicht kannte.
Wenn ich diese Kommentarspalte lese, habe ich ein wenig den Eindruck, dass viele Hoffnung auf Aussagen setzen wie „Menschen sind unverzichtbar“, „LLMs können nicht debuggen“ oder „LLMs führen einen in die Irre“. Das stimmt zwar alles, aber automatische Codegenerierung hat sich in den letzten zwei Jahren enorm weiterentwickelt, obwohl das damals noch unmöglich schien, und das Tempo ist weiterhin hoch. Vielleicht verlangsamt sich die Verbesserung künftig nach Art des Pareto-Prinzips, aber Fortschritt wird es sicher weiter geben. Ich habe neulich in r/fpga davon erzählt, dass ich mit einem LLM erfolgreich die erste Version einer Testbench erstellt habe, und war ziemlich überrascht, wie Leute, die es nie ausprobiert hatten, die Möglichkeit an sich schon abgetan haben.
Diese Haltung ist unter Angehörigen von Fachberufen extrem verbreitet. Ich war auch in /r/law unterwegs und habe beim Thema Dario Amodeis Aussagen zu KI im Rechtsbereich diese reflexhafte Ablehnung direkt gespürt. Vielleicht ist das eine Art Anpassungsmechanismus oder Bequemlichkeit gegenüber der Realität, aber für die Fähigkeit, auf künftige wirtschaftliche und gesellschaftliche Veränderungen zu reagieren, ist das sehr schlecht.
Das ist ähnlich wie damals, als Programmierer in der Ära, in der Assembler die Grundlage war, beim Aufkommen von Programmiersprachen darüber spotteten, sie seien ineffizient, unflexibel und übermäßig vereinfacht — unabhängig davon, ob das faktisch stimmte. Solche Reaktionen sind natürlich und haben nur wenig mit dem tatsächlichen Wert der neuen Technologie zu tun.
LLMs sind eine Zeit lang explosionsartig gewachsen, aber bei den jüngsten Modellen habe ich eher das Gefühl eines Rückschritts. Für das Erzeugen von Testcode liefern sie gute Ergebnisse, aber wenn LLMs zu tief für Aufgaben wie die Implementierung neuer Features eingesetzt werden, wird es eher seltsam. Für neue Projekte oder einfache Web-Apps funktionieren sie gut, aber bei groß angelegten oder Legacy-Code-Refactorings und beim Hinzufügen von Funktionen ist der Nutzen gering. Ich sehe zum Beispiel oft, wie Claude oder ChatGPT komplette D3-APIs einfach halluzinieren.
Letztlich baust du gerade selbst deinen eigenen Ersatz, während deine Kollegen vorsichtiger vorgehen.
ChatGPT-4o zeigt gewaltige Fähigkeiten beim Schreiben von VHDL. Ich erlebe heute wieder beeindruckende Ergebnisse beim Prototyping eines Low-Level-Controllers.
Der Kontext, den man braucht, um echte Software ordentlich zu schreiben, ist für LLMs viel zu umfangreich. Software ist an sich „in Code gegossenes Business“. Wie soll ein LLM all die Sonderzusagen kennen, die das Vertriebsteam Kunden gemacht hat, oder die impliziten Regeln einzelner Abteilungen? Was LLMs aktuell lösen können, ist allgemein und begrenzt. Sobald mehr als zwei Klassen im Spiel sind oder mehr als 20 bis 30 Dateien, verlieren selbst Top-LLMs den Faden und den Fokus. Weil sie den Kontext nicht halten können, entsteht unnötig viel Code-Churn. Um echte Entwickler wirklich zu ersetzen, müssten LLMs sehr viel mehr Kontext aufnehmen, Kontext aus der gesamten Organisation sammeln und auch in langfristigen Projekten den Gedankengang aufrechterhalten können. Wenn diese Probleme tatsächlich auf eine reale Lösung zusteuern, fange ich an, mir ernsthaft Sorgen zu machen.
In jeder Diskussion darüber, ob LLMs Entwickler ersetzen, wird vergessen, dass echte Softwareentwicklung weit mehr umfasst als nur Code zu schreiben. Das Schreiben von Code ist eher ein kleiner Teil. Entscheidend sind soziale Fähigkeiten, Anforderungsanalyse und herauszufinden, was der Kunde tatsächlich will — zumal der Kunde oft selbst nicht genau weiß, was er will, und der Engineer sich damit abmühen muss, das herauszuarbeiten. Wenn das schon für Menschen schwierig ist, wird ein LLM es kaum schaffen.
Im Kern geht es um eine Feedback-Schleife, also um einen unmittelbaren iterativen Prozess, in dem Kunden das Produkt tatsächlich benutzen und Rückmeldungen geben. Chat-UIs sind hervorragend für diese Kunden-Feedback-Schleife, und Agenten erzeugen schnell neue Versionen. LLMs können durchaus Abstraktion, verschiedene Komponentensysteme, das Design der Gesamtstruktur und sogar Anforderungsanalyse leisten. Entscheidend ist, wie schnell die Iteration ist. Die Robustheit und der IQ der Modelle werden weiter besser. Die gesamte Softwareentwicklung ist bereits in die Phase der Automatisierung eingetreten. Wahrscheinlich wird der Mensch in fünf Jahren, wenn er nicht unterstützt wird, zu einem massiven Bottleneck. Wer sich nicht tief mit KI integriert, wird zwangsläufig zurückfallen.
Genau dieses Problem gab es auch in den 2000ern beim Offshore-Outsourcing an ausländische Entwicklerteams. Diese Teams konnten Änderungswünsche oder Probleme nur schwer ansprechen und haben deshalb einfach stumpf das umgesetzt, was man ihnen sagte. Am Ende hat sich alles nur immer weiter aufgestaut. Ich vermute, mit KI wird etwas Ähnliches passieren. Wahrscheinlich mit einem ähnlichen Ergebnis.
LLMs betreiben von vornherein kein Software Engineering. Aber das ist nicht unbedingt ein Problem. Viele erfolgreiche Programme laufen in der Praxis auch ohne „Software Engineering“ gut, besonders in Umgebungen, in denen sich niemand um Cloud-Kostenstrukturen schert. Eher denke ich, dass künftig jemand mit technischem Gespür, wie ein IT-Business-Partner, komplette Apps ohne Hilfe eines Software Engineers bauen wird. In der Green-Energy-Branche ist das schon heute tägliche Realität. Das Problem explodiert aber dann, wenn Wartbarkeit, Skalierung und Effizienz wichtig werden. Erst dann werden Fragen wie „Nehme ich in Python eine Liste oder einen Generator?“ relevant — und genau dort beginnt der Punkt, an dem echtes Engineering nötig ist.
In fünf Jahren könnte es sein, dass wir fast keinen Code mehr entwerfen. Schon jetzt tippe ich im Vergleich zu vor einem Jahr deutlich weniger Code. Aber das ist nur ein Teil des Prozesses; Entwickler werden deshalb nicht einfach verschwinden.
Andererseits wird die Rolle des bloßen „Coders“ bereits stark ersetzt. Genau darin sind LLMs gut. Es gibt viele hirnlose Coder, die einfach nur Tickets abarbeiten wie „Nimm diese API und gib jenen Wert zurück“, ohne Kundenanforderungen zu verstehen oder irgendetwas zu analysieren, und genau diesen Bereich räumen LLMs schnell ab. Richtiges Software Engineering ist etwas völlig anderes, aber man darf nicht ignorieren, wie groß die Nachfrage nach simplen Codern war.
Ein sehr wichtiger Punkt ist, dass nur Menschen die Fähigkeit zu abstrakten Programmkonzepten und kreativer Problemlösung haben. Ein Programmierer ist ein Architekt der Logik, und der Computer ist das Werkzeug, das menschliche Denkweisen in Anweisungen übersetzt. Werkzeuge können Menschen imitieren und für bestimmte Aufgaben Code erzeugen, aber grundlegendes abstraktes Design und die eigentliche Aufbauarbeit können sie nicht ersetzen. Wenn Modelle nicht nur Code schreiben, sondern anhand einer Spezifikation ein ganzes Projekt vollständig erzeugen können, wird sich die Rolle des Entwicklers erneut verändern.
Man muss immer davon ausgehen, dass „was besser ist“ von Aufgabe zu Aufgabe unterschiedlich ist. Bei repetitiven und formelhaften Arbeiten — CSS-Syntax richtig hinbekommen, bekannte Bibliotheken aufrufen und so weiter — sind LLMs bereits viel besser als ich. Solche „Kleinkram-Ereignisse“ haben früher viel meiner Zeit gefressen; jetzt sind sie fast sofort erledigt, und damit bin ich sehr zufrieden.
Beim grundlegenden Styling — also allem, was über simples CSS hinausgeht — sind die Ergebnisse von LLMs eher schlecht. Wenn sich der gewünschte Effekt nicht klar beschreiben lässt oder die Aufgabe subtil wird, liefern sie oft gerade das wichtigste Ergebnis nicht und verrennen sich stattdessen in einer einzigen Herangehensweise.
In Dingen, die ich nicht gut kann (SQL), ist ein LLM viel besser; in Dingen, die ich gut kenne (CSS), eher schlechter. Das zeigt den Maßstab ziemlich klar.
Ich stimme sowohl der Aussage „besser als die meisten Entwickler“ zu als auch der, dass LLMs nur deshalb bei CSS besser wirken, weil viele CSS nicht können. Das Missverständnis entsteht oft dadurch, dass viele Leute CSS hassen, es nie richtig lernen und sich nur dazu zwingen, es irgendwie zu benutzen. Wenn ein Unternehmen keinen echten CSS-Experten einstellen kann und billig davonkommen will, dann ist ein LLM eine Alternative. Wenn man sich jemanden leisten kann, der es wirklich gut beherrscht, ist ein LLM natürlich kein Vergleich. Im Ergebnis konkurrieren LLMs also mit schlechten Entwicklern.
Bei wichtigen Sprachen oder Bereichen, die man nicht genau kennt, ist die Autovervollständigung durch LLMs eine große Hilfe. Wenn man aber keine „reflexhafte Erinnerungskompetenz“ aufbaut und sich nur auf das LLM verlässt, fehlt einem womöglich die Fähigkeit, die Empfehlungen des Werkzeugs zu beurteilen, und man bleibt bei schlechten Lösungen hängen.
Ich freue mich, dass sich so viele Menschen Sorgen um „guten Code“ machen, habe aber Angst, dass es in der Praxis bedeutungslos sein könnte. Die Softwarebranche ist schon seit Langem von der Geschäftswelt vereinnahmt, und ich weiß nicht einmal mehr genau, seit wann — vielleicht seit Bill Gates 1976 seinen offenen Brief schrieb? Das eigentliche Problem ist, dass Aktionäre und Führungskräfte sich immer weniger um den Code kümmern, solange nur der Gewinn steigt. Ohne kulturellen Widerstand von Entwicklern und Nutzern wird diese Struktur wohl bestehen bleiben.
Zu der Aussage, ohne kulturellen Widerstand von Entwicklern und Nutzern sei alles verloren, möchte ich sagen: Es gibt auch Unternehmen, die guten Code schreiben, und nicht überall ist alles ein Chaos. Das Problem ist weniger die Codequalität als die ethische Frage, ob man kapitalistischen Geschäftszielen zustimmt. Am wichtigsten ist das Gleichgewicht zwischen schöner Software und der Realität. Ich bin selbst Entwickler und Gründer, liebe Open Source und Engineering, möchte aber gleichzeitig auch bequem genug leben.
Code ist der Motor des Geschäfts. Schlechter Code führt zu schlechtem Geschäft. Zwischen Hosting-Teams (physische Firewalls, VMware, Proxys usw.) und der Public Cloud (QEMU, Netfilter, einfache Appliances usw.) gibt es einen deutlichen Unterschied. Wer hier wen vereinnahmt hat, und wie die Zukunft aussieht, kann niemand vorhersagen.
Ich habe gestern Nacht meine ganze Zeit damit verbracht, mit o3 zu ringen. Ich hatte in meinem Leben noch nie ein Dockerfile geschrieben und wollte deshalb lieber einfach o3 mein GitHub-Repository geben und es automatisch lösen lassen — und habe dann Stunden damit verschwendet, das Ergebnis zu debuggen. Es fügte ständig Dinge hinzu, die gar nicht existierten, löschte oder vermischte Dinge, die es gar nicht gab, und verwechselte sogar grundlegende Konzepte wie den Unterschied zwischen
python3undpython. Am Ende war ich so genervt, dass ich einfach die Google-Dokumentation nachgeschlagen habe, und dann war es schnell geklärt. KI ist ein großartiges Werkzeug, aber kein Allheilmittel, und irgendjemand muss auf jeden Fall „wach bleiben“.Unternehmen, die mit LLMs und KI die Produktivität ihrer Mitarbeiter steigern, werden florieren; Unternehmen, die Mitarbeiter vollständig ersetzen wollen, werden scheitern. Kurzfristig könnten CEOs und Führungskräfte sich zwar mit kurzfristigen Ergebnissen zufriedengeben und dabei künftiges Wachstum aufzehren.
Genau das ist die richtige Antwort. LLMs sollte man als Assistenten für Programmierer nutzen; als vollständiger Ersatz taugen sie nicht. Der richtige Weg ist, die Technologie in angemessenem Maß anzunehmen.
Die Idee, dass das Ersetzen von Mitarbeitern den kurzfristigen Wert steigern und dem Unternehmen damit nützen könnte, finde ich ziemlich interessant. Das heißt: Mittel- und langfristig schadet es der Firma, aber vorübergehend kann der Aktienkurs durchaus steigen.
Code-Assistenten sind ein unverzichtbares allgemeines Werkzeug, aber keine Waffe, um Menschen zu ersetzen. In einer Zeit, in der die Konkurrenz dieselben KI-Abos kaufen kann, kann man damit keine Menschen ersetzen.
Erfahrungsbericht aus der Praxis: Früher Entwickler, jetzt eher Manager, aber ich schreibe immer noch Code. LLM-Assistenten helfen, sind aber manchmal auch lästig. Wenn sie ungefragt unerwartete Codevorschläge herausblasen, geht das manchmal in eine ganz andere Richtung als beabsichtigt, und die Überprüfung kostet Zeit. Vermutlich ist es eine Einstellungsfrage, aber ich würde gern den Standard so ändern, dass ich sie nur sehe, wenn ich sie explizit per Befehl aufrufe. Eines ist auf jeden Fall sicher: Selbst wenn ich einem LLM die komplette Datei oder Funktion schreiben lasse, durchläuft das Ergebnis immer meinen eigenen Review-Prozess.
Im Zed-Editor gibt es so einen Modus mit „dezenten Vorschlägen“ (mehr dazu). Ich wünschte, alle Editoren würden so einen Modus anbieten.
Da ich in Startups derzeit viele unterschiedliche Dinge mache, mag ich UIs, die von LLMs erzeugt wurden, nicht besonders. Für grundlegende Building Blocks sind sie nützlich, aber wenn ich Claude ganze lange Codeblöcke am Stück schreiben lasse, braucht es sehr viele Überarbeitungen, bis ich bei dem Ergebnis ankomme, das ich eigentlich wollte.
https://freederia.com Wie auf einer KI-Wissenschaftler-Website werden wir eine koexistente Beziehung aufrechterhalten.