KI versteht die Funktionsweise dieses Codes tiefgehend

 (github.com/ocaml)
4 Punkte von GN⁺ 2025-11-27 | 2 Kommentare | Auf WhatsApp teilen
  • Es wurde ein umfangreicher PR mit 13.000 Zeilen eingereicht, der dem nativen OCaml-Compiler DWARF-v5-Debug-Informationen hinzufügt und damit Quellcode-Debugging auf Source-Ebene mit GDB und LLDB unter macOS und Linux unterstützt
  • Die Implementierung umfasst unter anderem Breakpoints auf Funktions- und Zeilenebene, Nachverfolgung von Parametern und lokalen Variablen, Anzeige grundlegender Typinformationen sowie Unterstützung für AMD64 und ARM64
  • Der Autor erklärt, dass dieser Code das Ergebnis der Zusammenarbeit von KI-Modellen wie Claude Sonnet 4.5 und ChatGPT 5 (Codex) sei; statt selbst Code zu schreiben habe er die KI angeleitet und überprüft
  • Die OCaml-Maintainer lehnten einen Merge ab und schlossen den PR mit Verweis auf Urheberrechtsfragen, fehlende Designdiskussion, Wartungsaufwand und die Schwierigkeit, KI-generierten Code zu prüfen
  • Die Debatte zeigt neue Herausforderungen der Open-Source-Community im Hinblick auf Qualität, Urheberrecht und Kollaborationsprozesse bei KI-generiertem Code

Überblick über den PR zur DWARF-v5-Debug-Unterstützung

  • Der PR fügt dem nativen OCaml-Compiler DWARF-v5-Debug-Informationen hinzu und ermöglicht damit Source-Level-Debugging in GDB und LLDB
    • Setzen von Breakpoints nach Funktionsname, Datei und Zeile, Anzeige von Variablennamen, Bereitstellung von Typinformationen
    • Unterstützung für die Architekturen AMD64 und ARM64, 32-Bit-Plattformen werden nicht unterstützt
  • Sowohl unter macOS (Mach-O) als auch unter Linux (ELF) wird vollständige DWARF-Unterstützung mithilfe von sectionsrelativen Relocations implementiert
  • Durch das zusätzliche LLDB-Plugin (ocaml_lldb.py) wird der OCaml-Werteausgabebefehl ocaml print bereitgestellt
  • Die Tests bestehen aus 9 Punkten und prüfen Funktions-, Typ- und Zeilen-Debugging

Implementierungsdetails

  • Upgrade von DWARF v4 auf v5; dabei wird DW_FORM_string verwendet, um Linkerfehler zu vermeiden
  • Unterstützung für mehrere Compile Units (CU) sowie Beseitigung doppelter Einträge in der String-Tabelle
  • Nachverfolgung lokaler Variablen und Parameter, lexikalische Blöcke und grundlegende Typinformationen werden in der DWARF-Struktur abgebildet
  • Das Modul Var_lifetime verfolgt den Lebenszyklus von Variablen, und über das Feld fun_var_info werden Variableninformationen durch die gesamte Compiler-Pipeline weitergereicht
  • DW_TAG_lexical_block dient zur Darstellung verschachtelter Scopes
  • Testskripte prüfen in GDB und LLDB Breakpoints sowie die Anzeige von Typen

Kontroverse um KI-generierten Code

  • Der Autor erklärte: „Claude Sonnet 4.5 hat den Großteil geschrieben und ChatGPT 5 (Codex) hat geprüft“
    • Er erläuterte weiter: „Ich habe die KI nur angeleitet und überprüft, aber keine einzige Zeile selbst geschrieben.“
  • In einigen Dateien war Mark Shinwell als Autor aufgeführt, was eine Kontroverse über die Herkunft des Urheberrechts auslöste
  • In einem separaten Analysebericht argumentierte der Autor, die Struktur, Benennung und das Typsystem unterschieden sich von der OxCaml-Implementierung; es handle sich daher nicht um eine Kopie

Reaktionen der Maintainer

  • gasche: Es sei problematisch, dass ohne vorherige Designdiskussion mehr als 13.000 Zeilen Code eingereicht wurden; das verursache hohen Review- und Wartungsaufwand
    • Für KI-generierten Code sei die Prüfung „schwieriger und mit rechtlichen Risiken verbunden“, daher komme ein Merge nicht infrage
  • dra27: Kritisierte die Formulierung, „die KI verstehe den Code“, und betonte, LLMs seien keine verstehenden Systeme, sondern Werkzeuge zur Mustererzeugung
  • bluddy und tmcgilchrist: Der DWARF-Code solle in eine separate Bibliothek ausgelagert werden; eine Einbindung in den Compiler erhöhe den Wartungsaufwand
  • Als die Diskussion eskalierte, wurde der PR mit dem Status „too heated“ gesperrt

Streitpunkte bei der Zusammenarbeit von KI und Open Source

  • Der Autor betonte, es habe sich um ein KI-gestütztes Entwicklungs­experiment gehandelt, mit dem gezeigt werden sollte, dass KI hochwertigen Code fertigstellen könne
  • Die Maintainer wiesen auf das Fehlen klarer Richtlinien zu Qualität, Urheberrecht und Review-Prozessen für KI-generierten Code hin
  • Der Fall hat eine Debatte darüber ausgelöst, welche Verfahren und Standards nötig sind, wenn KI-gestützte Entwicklung in Open-Source-Projekte integriert wird

Verwandte Beiträge

2 Kommentare

 
iolothebard 2025-11-27

Aber … die Person, die den PR eingereicht hat, versteht es überhaupt nicht.
Daher … lehne ich diesen PR ab. (klopf klopf klopf)
 
GN⁺ 2025-11-27
Hacker-News-Kommentare

  • Ich frage mich, ob die OCaml-Maintainer eine spezielle Ausbildung im Umgang mit schwierigen Menschen bekommen haben.
    Ihre Geduld und Reife sind wirklich erstaunlich. Ich hätte vermutlich im Torvalds-Stil sofort geblockt.

    • In dem Großkonzern, in dem ich arbeite, gilt man fast als Außenseiter, wenn man AI skeptisch sieht.
      Das Management hat fast einen religiösen Glauben an AI und will, dass alle Engineers sie maximal nutzen.
      Sogar Code Reviews werden zunehmend von AI übernommen. In diesem Fall waren sie aber wohl nicht deshalb freundlich.
    • Als Maintainer eines großen Open-Source-Projekts bekommt man so ein Training wahrscheinlich ganz automatisch.
    • Der Contributor schien keine böswillige Absicht zu haben. Vielleicht hätte man diese Energie in konstruktive Bahnen lenken können,
      zum Beispiel indem man ihn dazu bringt, den PR aufzuteilen oder einen Design-Vorschlag zu machen.
    • Bei manchen Leuten scheint durch die Existenz von AI das Denken kaputtgegangen zu sein.
      Die Maintainer sind zu nett; es frustriert, ihnen dabei zuzusehen, wie sie ihre Zeit an solche Leute verschwenden.
    • Ich war beim erneuten Lesen des Threads beeindruckt.
      Wie die Maintainer ohne Emotionen, nur mit Logik und Empathie reagiert haben, war wirklich Lehrbuch-Kommunikation.
      Ich frage mich nur, ob diese Freundlichkeit die Illusionen am Ende nicht noch verstärkt.

  • Manche Leute wirken noch weniger selbstreflektiert als ein LLM.
    Eine AI nach der Rechtfertigung für von AI erzeugte Commits zu fragen, ist wirklich absurd.
    Immerhin war er wenigstens ehrlich. Der Satz „Ich werde diesen Müllhaufen warten, aber nur gegen Bezahlung“ war der Höhepunkt.

    • Beeindruckend war, wie die Community ruhig konstruktives Feedback gegeben hat.
      Dadurch hatte ich sogar Lust, selbst zum OCaml-Ökosystem beizutragen.
    • Ich denke, er war nicht einfach nur dumm, sondern vielleicht ein Troll auf hohem Niveau.
    • Genau dieser Teil war das Sahnehäubchen.

  • Auf die Frage „Warum ist der Autor der eingereichten Datei als Mark Shinwell eingetragen?“
    antwortete er: „Die AI hat das so entschieden, ich habe nicht nachgefragt.“ Das fasst alles zusammen.

    • Noch lustiger ist, dass er vorher gesagt hatte: „Die AI versteht diesen Code tiefgehend, also fordert sie heraus.“
    • Das erinnert mich an die Aussage, dass gute Entwickler auf mehreren Abstraktionsebenen gleichzeitig denken können müssen.
      Diese AI-Generation betreibt nicht einmal minimale mehrdimensionale Denkarbeit.
      Dass jemand fragen würde, warum dort ein Copyright eingetragen ist, war völlig absehbar, und trotzdem war keine Antwort vorbereitet.
    • Es ist zwar Open Source, aber diese Art von Beitrag wirkt weit entfernt vom geistigen Open-Source-Ethos.
      Am Ende wird die Review-Last auf die Maintainer abgewälzt, während der Contributor keine Verantwortung für die Wartung trägt.
    • Ich dachte zuerst, es sei ein Witz, und war schockiert, dass es echt war.
    • Ich habe sogar sein GitHub-Profil gesucht, weil ich dachte, vielleicht ist der echte Mark Shinwell hier unterwegs.

  • Der Lebenslauf dieses Mannes ist legendär.
    Wall-Street-Banken, dann technischer Direktor bei der Deutsche Bank, Verkauf von Lizenzen an EA,
    ein Versuch, das Buch „Hardcore Erlang“ zu schreiben, 2 Millionen Dollar Krypto-Funding in zwei Tagen usw.
    Entweder ist er ein Genie oder der größte Aufschneider des Jahrhunderts.
    Relevante Links: früherer Blog, Lebenslauf als PDF, Interview, offizielle Website, Nachricht zur Absage des Erlang-Buchs

  • Selbst wenn der Code von AI erzeugt wurde: Wenn die Community sich die Zeit nimmt, zu reden und Feedback zu geben,
    dann ist es meiner Meinung nach ein sofortiger Block-Grund, wenn der Autor lange von AI geschriebene Texte einfach 1:1 hineinkopiert.
    Wer sich wie ein Spam-Bot verhält, darf auch wie ein Spam-Bot behandelt werden.

    • Früher hat ein Kollege mal ein Jira-Ticket in ChatGPT eingefügt, die Antwort kopiert und damit einen PR eingereicht.
      Wenn ich Fragen gestellt habe, klang die Antwort ganz typisch nach GPT.
      Als ich es schließlich selbst ausprobierte, bekam ich fast wortgleich dieselbe Antwort,
      und danach habe ich erklärt, dass ich seinen Code nicht mehr reviewen werde.

  • Als der Satz „Hier ist die von AI erstellte Copyright-Analyse“ fiel, war für mich bereits Schluss.
    Ich hätte an der Stelle sofort den Repo-Zugang blockiert.

    • Die emotionale Reife der Maintainer war bemerkenswert hoch.
    • Es war einfach Clownerie, über die man lachen und hinweggehen kann.

  • Ich selbst habe in mehreren Open-Source-Projekten schon AI-generierte PRs geschlossen.
    Solche Contributor ziehen einfach weiter zum nächsten Projekt, wenn sie bei einem abgelehnt werden.
    Die Review-Last steigt, und echte Contributions werden weniger.
    Trotzdem ist es interessant, solche Diskussionen in Echtzeit auf HN zu verfolgen.

    • Dieser PR wurde am Ende geschlossen und gesperrt. Die Maintainer haben geduldig reagiert,
      aber der Autor ließ sich durch Logik überhaupt nicht überzeugen. Andere Projekte dürften dem wohl ähnlich standhalten können.
    • Open-Source-Maintainer werden sich schon deshalb gegen diese Welle stemmen, weil sie nicht auf HN oder Reddit verspottet werden wollen.
      Eigentlich Sorgen machen sollte man sich eher um Enterprise-Software.

  • Ich würde den AI-Befürwortern gern eine Frage stellen:
    Wenn ihr einen von AI geschriebenen Vortrag haltet und danach Fragen bekommt, was antwortet ihr dann?
    Genau das ist diese Situation.

    • Aus Sicht eines AI-Befürworters ist das Problem nicht AI selbst, sondern die Haltung, etwas einzureichen, das man nicht versteht.
      Einen PR mit 13k Zeilen ohne Verständnis reinzuwerfen, ist unabhängig von AI falsch.
      AI ist nur ein Tool; ob man eine CNC-Maschine oder eine Säge benutzt, entscheidend ist, dass man das Ergebnis versteht.
    • Die Antwort „Die AI hat das so entschieden, ich habe nicht nachgefragt“ sagt bereits alles.
    • Eine Haltung wie „Ich habe keine Finanzierung, also kann ich nicht antworten. Wenn ihr zahlt, frage ich die AI“ ist schlicht absurd.
    • Es kam auch der Witz auf, dass Politiker das eigentlich schon immer so gemacht hätten.
    • Auch der Satz „Die AI versteht Ihre Frage perfekt. Beweisen Sie, dass sie falsch liegt“ fiel.

  • Von allen AI-generierten PRs, die ich bisher gesehen habe, war dies der ungewöhnlichste Fall.
    Meistens ist es kaputter Code von Anfängern, aber diesmal war er komplex und funktionierte tatsächlich.
    Der Autor, Joel Reymont, war ein Entwickler mit 30 Jahren Erfahrung und ein HN-Veteran mit Account seit 2008.
    Die Geduld der OCaml-Maintainer war beeindruckend, und am Ende fasste er seine Position in einem menschlich formulierten Kommentar zusammen
    und sagte, dass er damit aufhören werde, mit AI zu OSS beizutragen.
    Trotzdem sind solche PRs weiterhin für alle Zeitverschwendung,
    und ich habe bisher keinen Fall gesehen, in dem sie produktiv genutzt wurden.

  • Das war wirklich ein erstaunlicher PR.
    Link zu dem Commit

    • Zumindest dieser Änderungsteil könnte ja vielleicht ausnahmsweise nicht von AI geschrieben worden sein /s