- Bei der Go-Implementierung von ML-DSA, einem von NIST standardisierten postquantenresistenten Signaturalgorithmus, trat ein Problem auf, bei dem die Signaturprüfung fehlschlug
- Claude Code v2.0.28 fand allein anhand von Testcode und Quellpfaden schnell einen komplexen Low-Level-Bug
- Als Ursache wurde ein Fehler beim Zusammenführen von Funktionen festgestellt: Im Schritt
Verify wurden die höheren Bits von w1 doppelt berechnet
- In zwei weiteren Experimenten fand Claude jeweils einen Fehler bei der Berechnung einer Montgomery-Konstante und einen Bug durch inkonsistente Signaturlänge
- In allen drei Versuchen wurde der Bug erfolgreich identifiziert, was das Potenzial von KI für Low-Level-Debugging zeigt
ML-DSA-Implementierung und anfängliches Problem
- Der Autor implementierte ML-DSA (Post-Quantum Signature Algorithm), standardisiert von NIST, neu in Go
- Nach vier Tagen Live-Coding trat in den Tests das Problem auf, dass die Verify-Funktion alle Signaturen ablehnte
- Im Test-Log wurde wiederholt der Fehler
invalid signature ausgegeben
- Wegen Erschöpfung brach er das Debugging ab und bat Claude Code, das Problem zu analysieren
Erstes Debugging mit Claude Code
- Claude Code v2.0.28 (Modell Opus 4.1, ohne System-Prompt) erhielt die folgenden Informationen
- Befehl zum Ausführen der Tests (
bin/go test crypto/internal/fips140/mldsa)
- Code-Pfad (
src/crypto/internal/fips140/mldsa)
- Die Beschreibung „Signaturen werden immer abgelehnt“ sowie den Hinweis „w1 ist unterschiedlich“
- Claude lieferte innerhalb weniger Minuten einen vollständigen Fix-Vorschlag zurück
- Die Ursache: Nach dem Zusammenlegen von
HighBits und w1Encode wurden in Verify auf das Ergebnis von UseHint, das die höheren Bits bereits erzeugt hatte, erneut die höheren Bits angewendet
- Es handelte sich also um einen strukturellen Fehler, bei dem die höheren Bits von w1 doppelt berechnet wurden
- Claude identifizierte die Ursache direkt nach dem Laden des Codes und schrieb eigene Tests, um die Hypothese zu verifizieren
- Der vorgeschlagene Fix war nicht perfekt, verkürzte aber durch die korrekte Identifizierung der Kernursache die Debugging-Zeit deutlich
- Anschließend refaktorierte der Autor
w1Encode, sodass die Funktion die höheren Bits als Eingabe erhält, und verkürzte außerdem den Ablauf der Umwandlung in die Montgomery-Darstellung
Zweites Experiment: Bugs im Schritt der Signaturerzeugung
- Auch bei der Implementierung der Signaturerzeugung schlugen Tests fehl
- Erster Bug: Fehler bei der Berechnung von Konstanten (1, -1) in der Montgomery-Domäne
- Das Problem war schwer zu finden, erforderte zahlreiche
printf-Ausgaben und Vermutungen und kostete etwa 1 bis 2 Stunden
- Zweiter Bug: Längenfehler bei einem in der Signatur enthaltenen Wert (32 Bit statt 32 Byte)
- Dieser wurde wegen der abweichenden Signaturlänge vergleichsweise leicht entdeckt
- Der Autor hielt diese beiden Bugs für geeignet, um Claudes Leistung zu überprüfen, und führte Claude Code erneut mit einer früheren Codeversion aus
Ergebnisse des zweiten Debugging-Durchlaufs mit Claude Code
- Im ersten Prompt führte Claude
printf-Debugging und Werteverfolgung durch, fand die falsche Konstante und korrigierte sie
- Die Bearbeitungszeit war kürzer als beim Menschen, und die Ursache des Testfehlers wurde präzise identifiziert
- Im zweiten Prompt fand Claude das Problem der inkonsistenten Signaturlänge
- Nach der Untersuchung mehrerer Pfade schlug Claude einen Fix vor, der nur die Länge der Allokation anpasst
- Der vorgeschlagene Fix war nicht vollständig, verwies aber exakt auf die Stelle des Kernfehlers
- In allen drei unabhängigen Versuchen fand Claude eigenständig die genaue Ursache des Bugs
Effizienz und Bedeutung von KI-Debugging
- Claudes Ansatz erwies sich als wirksamer automatisierter Helfer, spezialisiert auf die Suche nach Ursachen von Testfehlern
- Der Nutzer übernahm Claudes Patch-Vorschläge nicht direkt, sondern prüfte nur die Bug-Position und korrigierte den Code selbst
- Der Autor erwähnt den Bedarf an einem Tool, bei dem ein LLM bei Testfehlern automatisch die Ursache analysiert und meldet
- Im Vergleich zu einfachem Chatten oder automatisch erzeugten PRs wäre die ideale Form ein testbasierter Debugging-Agent
Sponsoring und weitere Informationen
- Die Open-Source-Wartung des Autors wird über Geomys unterstützt; zu den Sponsoren zählen
Smallstep, Ava Labs, Teleport, Tailscale und Sentry
- Ava Labs betont die Bedeutung einer nachhaltigen Open-Source-Entwicklung kryptografischer Protokolle
- Teleport stellt die Plattform Teleport Identity vor, die auf Schutz vor Account-Übernahmen und stärkere Zugriffskontrolle abzielt
Anhang: Bilder und persönliche Anmerkungen
- Im Artikel erscheint Clippy aus Microsoft Office mit einer Sprechblase, in der steht, dass „die höheren Bits von w1 zweimal genommen wurden“
- Am Ende ist außerdem ein Katzenfoto enthalten, das als humorvolle Einlage zur Entschärfung emotionaler Debatten über KI dient
2 Kommentare
In letzter Zeit entwickle ich ein wenig GPU-Kernel mit triton oder cuda. Selbst mit 3.5 habe ich kaum erlebt, dass etwas korrekt lief, aber bei 4.5 sieht man, dass einigermaßen brauchbarer Code oder Optimierungen herauskommen.
Hacker-News-Kommentare
Die Nutzung von Coding-Agenten, um die Grundursache eines Bugs aufzuspüren, funktioniert ziemlich gut
Drei One-Shot-Debugging-Versuche waren alle erfolgreich. Entscheidend ist, dass das LLM den Code nicht direkt selbst ändert, sondern als Helfer, der nur die Stelle des Bugs zeigt, damit ich selbst urteilen und ihn beheben kann
Dieser Ansatz könnte auch für LLM-Skeptiker ein guter Einstieg sein. Man lässt sie nicht den Code schreiben, sondern nur lästige Bugs finden
Der Vorschlag „Das muss man beheben“ ist nicht unbedingt falsch, aber oft am Kernproblem vorbei. Am Ende häufen sich unnötige Änderungsvorschläge, und wenn ein Junior-Entwickler sie einfach übernimmt, entsteht nur unnötige Arbeit
Ich nutze solche Tools auch, habe aber oft das Gefühl, dass ich „am Ende mehr Zeit damit verbringe, es einem Junior zu erklären“
Auch bei der Testgenerierung sind sie bei Algorithmen gut, stoßen aber in Concurrency-Situationen an Grenzen. Trotzdem sind sie für „Testgenerierung“ oder „Debugging“ auf jeden Fall wertvoll
Für Code-Refactoring oder langfristige Wartbarkeit reichen sie weiterhin nicht aus
Als ich sie jedoch wie im Blog empfohlen als Bug-Hunter eingesetzt habe, waren sie überraschend effektiv. Innerhalb weniger Wochen haben sie mehrere Produktions-Bugs aufgespürt
Wenn man es vor dem eigentlichen Eintauchen in den Code ausführliche Dokumente schreiben lässt, ist es selbst bei Fehlern wenig riskant und auch für skeptische Menschen ein guter Startpunkt
Es wäre schade, diesen Prozess einer Maschine zu überlassen. Bug-Hunting führt zu einem tiefen Verständnis der Systemarchitektur und hilft langfristig dabei, ein besserer Programmierer zu werden
Ohne solche Erfahrungen besteht am Ende das Risiko, sogar das Urteil über den eigenen Code an ein LLM auszulagern
Mein einziger Rat ist: AI First
Wenn man ein Problem zuerst der AI vorlegt, lernt man sowohl die Grenzen des Modells kennen als auch, wie man Prompts strukturiert
Die neuesten Modelle sind leistungsfähig genug, dass man sie bei den meisten Problemen wie Kollegen behandeln kann. Wichtig ist aber, ihre Fehlermuster zu verstehen und ein Gespür dafür zu entwickeln
Ich würde empfehlen, bei jeder neuen Modellgeneration bestehende Prozesse zu verwerfen und mit den neuesten Modellen wie GPT-5-Codex oder Sonnet 4.5 zu experimentieren
Domain-Experten können Halluzinationen und Fehler eines LLM unterscheiden, andere verschwenden damit eher Zeit
Letztlich sind diese Tools für Experten am nützlichsten, während die Qualität für Anfänger stark schwankt
Ich habe Sonnet 4.5 auch ausprobiert, aber es war nur ein wenig besser als die vorherige Version. Zeitverschwendung kommt weiterhin häufig vor
Anthropic hat mir mehrere Monate lang Claude Max kostenlos zur Verfügung gestellt
In letzter Zeit ist auch Instagram voller Claude-bezogener Werbung. Wenn ständig Anzeigen wie „Claude Code installieren“ auftauchen, scheint das Marketingteam wirklich hart zu arbeiten
Entwickler empfinden Claude Code als sehr nützlich, und es gibt viele Abos für 200 Dollar im Monat. Wenn es profitabel ist, ist es nur natürlich, viel Geld ins Marketing zu stecken
LLMs helfen beim Finden von Bugs, liefern aber manchmal auch abwegige Erklärungen, die Zeit kosten
Entscheidend ist letztlich, kritisches Denken beizubehalten
Das LLM ist ein großartiges Werkzeug, zieht aber gern vorschnelle Schlüsse. In dem Moment, in dem der Mensch aufhört nachzudenken, rennt das Modell in die falsche Richtung
Ich stimme der Meinung zu, dass „LLMs nur als Chat oder Autocomplete zu benutzen, wenig bringt“
Auch ich habe das Potenzial erst mit Claude Code/Codex wirklich gespürt. Ein dauerhaft laufender Modus wäre noch interessanter
Es könnte versehentlich Dateien löschen oder ein Git-Repository ruinieren. Deshalb experimentiere ich nur in einer Sandbox-Umgebung
Ich möchte ein kollaboratives Tool im sokratischen Stil, bei dem das Modell mir Fragen stellt und ich direkt eingreife und dabei lerne
Der heutige „automatisierungszentrierte“ Ansatz birgt die Gefahr, Entwickler zu Code-Analphabeten zu machen. Gut gestaltet könnte es dagegen ein Werkzeug zur Verstärkung von Verständnis und Intuition sein
Das CLI-Terminal ist weiterhin eine mächtige Schnittstelle
Gemini CLI und Qwen Code sind kostenlos, und auch eine OpenAI-kompatible API lässt sich leicht anschließen.
Einfache Aufgaben kann man automatisieren und schwierige Teile per One Shot mit Grok erledigen. Schon mit CLI + MCP-Server + MD-Dateien kann man intelligente Programme bauen
Die Idee ist interessant, bei jedem fehlgeschlagenen Test automatisch ein LLM die Ursache analysieren zu lassen
Mit einem Git-Hook lässt sich dafür Claude CLI ausführen.
Beispiele und ein Cheatsheet gibt es in diesem Guide
Bald werden wir wohl Fälle sehen, in denen durch adversariale Angriffe auf LLM-Trainingsdaten kryptografische Fehler herbeigeführt werden
Dass „die Korrektur das Hinzufügen einer komplett neuen Funktion umfasst“, wirkt bei Krypto-Implementierungen riskant
Der Artikel scheint einen falschen Rat zu geben
Der Patch-Code wurde verworfen und von einem Menschen selbst geschrieben. Das wirkt eher wie ein konservativer und verantwortungsvoller Einsatz
Das LLM sollte nicht als „Reparateur“, sondern wie ein Gasmelder eingesetzt werden: als Werkzeug, das den Ort des Problems zeigt
LLMs haben viele langweilige Probleme beseitigt, indem sie mehrdeutige Muster im Code erkannt haben
Das kann aber auch eine Nebenwirkung sein. Meine Codebase sieht zwar wie Node.js aus, ist es aber in Wirklichkeit nicht, sodass das Modell sie ständig fälschlich für ein Node-Projekt hält