Potenzielle Probleme in curl mit einem AI-Tool entdeckt

• Joshua Rogers hat mit seinem eigenen AI-basierten Toolset eine umfangreiche Liste potenzieller Probleme in der curl-Codebasis gefunden
• Die Liste umfasst nicht nur kleinere Mängel beim Codestil, sondern auch kleine Bugs und potenzielle Sicherheitslücken
• Die meisten gefundenen Probleme sind kleine Bugs, doch 1–2 davon könnten sicherheitskritische Schwachstellen sein
• Da diese Probleme zuvor nicht entdeckt worden waren, ist das Ergebnis tatsächlich sehr wertvoll
• Auf Basis des gemeldeten Inhalts wurden bereits 22 Bugs behoben
• Es bleiben noch mehr als doppelt so viele unbestätigte Issues offen, die weiterhin geprüft und behoben werden
• Die detaillierten Probleme sind mit "Reported in Joshua's sarif data" gekennzeichnet; wer interessiert ist, kann diese Daten direkt prüfen

[GN⁺]

Hacker-News-Kommentare

• Das ist für mich die ideale Form eines „AI Coding Companion“.
  Statt selbst Code zu schreiben oder zu ändern, soll er mir sagen, welche Stellen im Code verdächtig sind und wo ich genauer hinschauen sollte.
  Wenn ich Claude bitte, Bugs in meiner 20.000-Zeilen-C-Bibliothek zu finden, zerlegt es die Dateien, greppt nach bestimmten Code-Mustern und listet am Ende nur meine FIXME-Kommentare auf (lol).
  Das ist ehrlich gesagt auf dem Niveau eines simplen bash-Skripts und ziemlich enttäuschend.
  ChatGPT ist sogar noch weniger nützlich und wiederholt nur: „Sieht alles gut aus! Großartig! High five~“
  Bisher hat mir traditionelle statische Analyse beim Finden echter Bugs deutlich mehr geholfen, aber nur weil die statische Analyse sauber ist, heißt das nicht, dass es keine Logikfehler gibt.
  Genau hier sollten LLMs eigentlich glänzen.
  Wenn man für LLMs erst eine extrem maßgeschneiderte Umgebung bauen muss, um nützliche Hinweise auf potenzielle Bugs zu bekommen, dann sinkt der praktische Nutzen am Ende genauso wie bei statischen Analysewerkzeugen, die komplexe Konfiguration verlangen und deshalb oft nicht genutzt werden.
  • Es wird kaum darüber gesprochen, dass viele Programmierer gerne selbst entwerfen und coden (abgesehen von repetitivem Code), aber ungern Code-Reviews machen.
    Die Richtung „AI schreibt den Code und Programmierer reviewen ihn nur noch“ wirkt deshalb irgendwie falsch.
    Natürlich verstehe ich, warum sich das mit dem Ansatz „mehr Codezeilen~“ gut verkaufen lässt.
  • Wenn Claude wie erwähnt enttäuschende Ergebnisse liefert, funktioniert oft gut, „Claude selbst direkt zu fragen, welcher Prompt wirksam wäre“.
    Zum Beispiel: „Welchen Prompt sollte ich verwenden, damit Claude Code einen Plan erstellt, um Logikfehler effektiv zu prüfen und Kommentare wie FIXME oder TODO zu ignorieren?“
    Der resultierende Prompt ist zu lang, um ihn hier zu posten, aber es gibt ein öffentliches Beispiel als Gist.
    Darauf aufbauend kann man weiter iterieren und sogar einen Agenten daraus machen.
  • Cursor BugBot ist für genau so eine Rolle ziemlich gut geeignet.
    Nach der kostenlosen Testphase kam es in unserem Entwicklerteam so gut an, dass wir es offiziell eingeführt haben.
    Abgesehen von gelegentlichen Fehlalarmen ist es sehr nützlich.
    Sowohl PR-Autoren als auch Reviewer sparen damit viel Zeit.
  • Wenn man Claude fragt: „Es gibt einen Bug mit langsamen Antwortzeiten an einem bestimmten Endpoint, der nicht mit CPU-/Speicherauslastung oder der DB zusammenhängt — woran könnte es liegen?“, dann bekommt man nach ein paar Iterationen manchmal wirklich Hinweise auf schwer auffindbare Bugs.
    Ich hatte schon Fälle, in denen ich dank solcher Hinweise ein Problem lösen konnte, das mich sonst Stunden gekostet hätte.
    Dieses Potenzial von AI macht mir Hoffnung.
  • GPT-5 schmeichelt in solchen Situationen deutlich weniger als frühere Modelle.
    Es überrascht mich etwas, dass Antworten wie „Alles sieht gut aus“ überhaupt kamen.
    In Codex CLI stellt es oft durchaus Fragen in den Raum.
    Gemini 2.5 Pro ist in diesem Punkt ebenfalls okay.
• Ich hätte wirklich nie erwartet, im Zusammenhang mit curl und AI einmal eine positive Episode zu lesen.
  Mit Blick auf die Vorgeschichte ist das vielleicht interessant: HN-Suche zu curl+AI
  • Ich finde es bemerkenswert, dass Daniel Stenberg das diesmal so großzügig angegangen ist, obwohl er in der Vergangenheit rund um AI-Bugreports viele Probleme hatte.
• Der Punkt scheint mir das „Toolset“ zu sein. Es wird nicht mit einem Autopiloten verwechselt, sondern als System aus sauber kombinierten Werkzeugen eingesetzt.
  • Der Autor des Beitrags hat im eigentlichen Text vermutlich mehr Details beschrieben. Relevanter Blogpost (Mastodon-Erwähnung: relevanter Link)
  • Schade, dass die Diskussion auf ein binäres Schema wie „autonomes Fahren vs. Laissez-faire“ reduziert wurde.
    Am Ende läuft es wohl eher auf den Unterschied hinaus zwischen Leuten, die verstehen, was sie tun, und Leuten, die einfach nach Stimmung coden.
  • Stenberg hat es als Toolset beschrieben, aber mich würde auch interessieren, wie der eigentliche Contributor darüber denkt, der die Tools verwendet hat.
• Im curl-Repository gibt es 55 geschlossene PRs, in denen „sarif data“ erwähnt wird; genau diese Gruppe scheint hier gemeint zu sein.
  Das steht in deutlichem Kontrast zu den früheren Erlebnissen von Daniel Stenberg mit schlampigen, von AI erzeugten Pseudo-Sicherheitsmeldungen.
  Zu HackerOne: „Melder von AI-generiertem Müll werden sofort gebannt. Das ist praktisch DDoS-Niveau. Ich würde ihnen am liebsten sogar die verschwendete Zeit in Rechnung stellen.“
  Dazu passt auch Daniels Blogpost vom Januar dieses Jahres: The I in LLM stands for Intelligence?
  • Einige Bugs (zum Beispiel ein falscher printf-Formatspezifizierer für size_t) lassen sich schon durch korrekt gesetzte Compiler-Warning-Flags erkennen.
    Wenn AI einem sagt: „Dir fehlen wichtige Compiler-Warnflags“, wäre das durchaus ziemlich nützlich.
    Einige PRs dürften wohl auch mit Dependabot-Abgleichen zusammenhängen, und mit „Joshua sarif data“ findet man die konkreteren PR-Listen: Link
  • Die damals verwendeten Modelle scheinen sich stark verbessert zu haben.
    Ich vermute, das ist der Grund, warum sich Daniel Stenbergs Eindruck geändert hat.
• Unter den kommerziellen SAST-Scannern gibt es zwar ein paar gute, aber die meisten sind nicht zufriedenstellend.
  Es wird viel dafür geworben, AI-basierte SAST-Technik einzuführen, und entsprechende Produkte kommen auch tatsächlich auf den Markt, aber die meisten bleiben bisher hinter den Erwartungen zurück.
  Wenn es nur enttäuschend wäre, ginge es ja noch — gefährlich wird es, wenn daraus ein falsches Sicherheitsgefühl entsteht.
  Eine kritische Sicht auf AI-basierte SAST-Scanner und die Begründung dazu gibt es hier.
• Es war nicht sofort klar, um welches konkrete AI-Tool es eigentlich ging.
  Mich würde interessieren, warum diese Strategie diesmal wirksamer war, obwohl verschiedene andere Tools zuvor keine Bugs gefunden hatten.
  • In diesem Blogpost mit Produktkapitel findet man etwas mehr Informationen dazu.
    Der Mastodon-Link dient vermutlich dazu zu bestätigen, dass es sich trotz fehlerhafter Code-Snippets tatsächlich um echte Bugs handelt.
• Als verwandtes Thema wurde auch ein Fall genannt, in dem jemand „mit AI etwas gebaut hat, ohne selbst zu verstehen, was er da eigentlich tut“: You did this with an AI and you do not understand what you're doing here