LLM-generierter Code in Abhängigkeiten verboten

 (joeyh.name)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • git-annex wurde im vergangenen Monat mit rund 100 Stunden Aufwand überprüft, damit es ohne Abhängigkeiten mit LLM-generiertem Code gebaut werden kann
  • Diese Arbeit macht deutlich, dass man in der Praxis nicht nur einzelne Code-Stellen, sondern den gesamten Dependency Tree kontinuierlich nachverfolgen muss, was den Wartungsaufwand erheblich erhöht
  • Bei der Prüfung wurden Fälle wie das kommentarlos rückgängig gemachte Zurückrollen umfangreicher LLM-generierter Änderungen, eine Änderung von 10.000 Zeilen in einer Codebasis mit 26.000 LOC sowie eine uneinheitliche Commit-Nachricht mit 1.489 Zeilen festgestellt
  • Positiv ist, dass zusätzliche Qualitätsinformationen zu Abhängigkeiten gewonnen wurden; gegenüber Reaktionen auf Organisationsebene wie durch die Software Freedom Conservancy oder die FSF bleibt jedoch Skepsis
  • Auch wenn sich per LLM leicht Konfigurationen hinzufügen oder Formatierungsänderungen erstellen lassen, können solche Commits direkte Kosten für das Vertrauen in der Zusammenarbeit und die Beteiligung am Projekt verursachen

Prüfung der git-annex-Abhängigkeiten

  • git-annex wurde etwa einen Monat lang mit rund 100 Stunden Aufwand überprüft, damit es ohne Abhängigkeiten gebaut werden kann, die LLM-generierten Code enthalten
  • Bislang scheint dieses Ziel erreicht zu sein
  • Eine zugehörige Seite ist git-annex no LLM code
  • Der Kern des Problems liegt in der Belastung, den gesamten Dependency Tree eines Programms kontinuierlich überprüfen zu müssen

Bei der Prüfung sichtbar gewordene Fälle und Auswirkungen

  • Die festgestellten Fälle führen nicht nur zu Geschmacksfragen, sondern zu Problemen bei Wartung und Vertrauen
    • Eine umfangreiche LLM-generierte Änderung wurde im nächsten Release ohne jede Erklärung rückgängig gemacht
    • In eine Codebasis mit 26.000 LOC flossen 10.000 geänderte Zeilen ein; die Commit-Nachricht bestand aus 1.489 Zeilen uneinheitlichen Inhalts
    • Es gab einen LLM-Prompt, Code aus einem anderen Projekt zu kopieren, und offenbar wurde nur mit Glück eine Urheberrechtsverletzung vermieden
  • Durch diese Arbeit wurden zusätzliche Informationen zur Qualität von Abhängigkeiten gewonnen, die künftige Entscheidungen beeinflussen können
  • Die Software Freedom Conservancy scheint das Thema in ihren Empfehlungen zu LLM-basierter generativer KI übergangen zu haben, und es ist unklar, ob die FSF es besser machen wird
  • Inmitten dieser Veränderungen wird die Beteiligung an den betreffenden Communitys überdacht, doch die Arbeit und die Unterstützung der Nutzer werden fortgesetzt
  • Es mag einfach erscheinen, einem LLM Prompts wie Add fourmolu config and restyled, neat oder format a module zu geben und das Ergebnis zu committen; dennoch sollte man die weitreichenden Auswirkungen dieses Handelns berücksichtigen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Lobste.rs

  • Ich habe heute erfahren, dass git-annex in Haskell geschrieben ist – ziemlich cool.

    Auf dem Heimweg in der U-Bahn schaute die Person neben mir YouTube Shorts bei maximaler Lautstärke, und in einem ruhigen, vollen Zug war das als Lärmbelästigung ziemlich nervig.
    Noch nerviger war, dass die Videos, die er schaute, komplett KI-generierter Low-Quality-Content waren.

    Die Anekdote in diesem Beitrag, dass Autoren von Abhängigkeiten mit LLMs Änderungen erzeugen, die schwer zu verstehen sind, hat bei mir einen Nerv getroffen.
    Das Frustrierendste am Missbrauch von LLMs ist, dass er unsere Interaktionen miteinander kaputtmacht.
    Früher konnte man in der Firma auch unausgereifte Vorschläge prüfen; die Kernidee lag offen da, sodass man sie leicht herausgreifen und kommentieren konnte. Heute kann jeder eine unausgereifte Änderung in ein LLM werfen und daraus etwas machen, das auf den ersten Blick gut strukturiert aussieht, bei der Prüfung aber voller Lücken ist.
    Genauso kann man schlechten Code erzeugen, der auf den ersten Blick gut aussieht.

    Das ist keine neue Beschwerde, aber es fängt an, mir zunehmend auf die Nerven zu gehen.
    Es fühlt sich an, als würden wir einen wesentlichen Teil der menschlichen Verbindung verlieren, die Arbeit und Leben angenehm und erfüllend gemacht hat.

    • Ich finde es gut, wenn ein Kollege ehrlich sagt: „Das hat 🤖 gemacht“, weil ich dann vorher weiß, welches Maß an Review erwartet wird.
      Meistens ist es eine Dokumentation des Prozesses, mit dem er die Codebase besser kennenlernen wollte, und ich kann darauf vertrauen, dass er die LLM-Ausgabe gelesen hat und bestätigt haben möchte, dass er sie richtig verstanden hat.

    • Ich denke, was LLMs verändert haben, ist der relative Preis von Qualität.
      In der Haus-Analogie: Früher kostete eine miserable McMansion mit undichtem Dach und schlechtem Fundament 1000X, ein gutes Haus ohne versteckte Probleme 2000X.

      Jetzt kann LLM-Technologie den Preis für ein gutes Haus theoretisch auf 1500X senken, indem Fachleute einen Teil der mechanischen, leicht überprüfbaren Arbeit auslagern.
      Die miserable McMansion ist aber auf 100X gefallen.

      Daher ist es sehr wahrscheinlich, dass minderwertige McMansions Qualitätsarbeit auf hässliche Weise verdrängen.
      Ich habe nichts dagegen, Handwerker zu kritisieren, die den Preis eines guten Hauses von 2000X auf 1500X senken. Wenn aber grottige 100X-Häuser Besseres aus dem Markt drängen und einen Lemons Market schaffen, könnten Kunden Software insgesamt deutlich misstrauischer sehen.
      Ein Lemons Market ist hässlich, weil Käufer keine Möglichkeit haben, Qualität von Müll zu unterscheiden.
      Das bekannteste Beispiel in der Software ist der Videospiel-Crash von 1983, als viele Kunden von einer riesigen Welle an Schrottspielen verbrannt wurden und aufhörten zu kaufen.

  • Ich halte diese Position für völlig vernünftig.
    Persönlich glaube ich, dass das mit der Zeit größtenteils vergebliche Mühe sein wird, und bei meiner eigenen Software-Nutzung stört es mich nicht besonders. Aus subjektiver Sicht ist es aber absolut legitim und interessant, und ich finde es gut, dass diese Person so vorgeht.

    So wie KI-Optimisten übertreiben, neigt auch die Anti-KI-Seite dazu, die negativen Aspekte überdramatisch darzustellen.
    Dieser Beitrag selbst ist eher eine Ausnahme, aber ohne die vorschnelle Verallgemeinerung im letzten Absatz wären die gesamte Absicht und Botschaft deutlich stärker gewesen.

    Trotzdem lese ich solche Texte gern und suche in den Emotionen nach den interessanten Teilen.
    Eine Datenbank der letzten bekannten 100% nicht-LLM-Codebasis pro Projekt wäre spannend.
    Auch eine Datenbank zu einflussreichem Slop wäre interessant, wobei „einflussreich“ sowohl positiv als auch negativ gemeint ist und „Slop“ wichtig als ungeprüfte Ausgabe zu verstehen ist.

    Man könnte sich auch ungefähr mit einem GitHub-Archiv von Anfang 2023 behelfen, aber interessanter wäre nicht einfach ein Snapshot zu einem bestimmten Zeitpunkt, sondern der letzte Commit-Snapshot pro Projekt.
    Aus so einem Datensatz ließen sich vermutlich viele interessante Ergebnisse gewinnen, und er wäre auch für Leute hilfreich, die wie in diesem Beitrag ein Ökosystem nur aus nicht-LLM-Software aufbauen möchten.

    Wie man wohl schon vermuten kann, bin ich LLM-Nutzer.
    Trotzdem halte ich mich für eher vernünftig.
    Wenn es dich interessiert, kannst du meine Website-Beiträge lesen; ich verspreche, dass der Text meiner Blogposts zu 100% von Menschen geschrieben ist.
    Ich denke, Gegenpositionen zu lesen ist eine der besten Methoden, um zu lernen und zu wachsen, deshalb beteilige ich mich gern an solchen Versuchen.

    • Es gibt ein Projekt, das dem Tracking der letzten nicht-LLM-Version pro Projekt nahekommt.
      Es wird von stark anti-KI eingestellten Leuten betrieben: https://codeberg.org/ethical-foss/open-slopware
      Bei einigen Projekten gibt es eine „letzte nicht kontaminierte Version oder Commit-ID“, aber es deckt nicht alle Projekte ab.

  • Ich habe diesen Beitrag eingereicht, weil mir gefiel, dass der Autor selbst nach bestimmten Commits gesucht hat, die auf LLM-Nutzung hindeuten, und eine Seite mit seinen Funden erstellt hat.

    Persönlich war ich mir nicht sicher, ob ich den Tag vibecoding setzen sollte, weil es in diesem Beitrag eher um Community und Praktiken geht als um Vibe Coding.

  • Da steht die Stelle: „Ich weiß, dass ich an diesem Punkt vielleicht versuche, die Flut aufzuhalten.“

    Wenn der Compiler, von dem ein Projekt abhängt, betroffen ist, kann man nicht gewinnen.
    Ich betreibe auch Schadensbegrenzung, aber irgendwann kommt der Moment, in dem die Alternative, auf der man besteht, schlechter ist und man nachgeben muss.

  • Ein schwieriges Problem.
    Selbst mit noch so guter Analyse wird es wahrscheinlich schwer sein, LLM-Code zu vermeiden.
    Code, der zum Beispiel per Autocomplete hineinkommt, wird man nicht erkennen.

  • Der Punkt, an dem das Vertrauen gebrochen wurde, war meines Erachtens nicht, als diese Libraries anfingen, LLMs zu verwenden, sondern als sie riesige Änderungen akzeptierten und integrierten und dazu schwer lesbare, nutzlose Commit-Messages anhängten.

    Das ist ein Software-Engineering-Versagen, unabhängig davon, ob LLMs verwendet wurden.

    Nebenbei: Ich mag Joey Hess und seine Software, und ich bin der Ansicht, dass Code-Beiträge nach den Vorzügen des Ergebnisses bewertet werden sollten, egal mit welchen Tools sie erstellt wurden.

  • Die Darstellung ist etwas enttäuschend.
    Der persistent-Commit scheint nicht von einem LLM geschrieben worden zu sein.
    Ich wünschte, Leute würden nicht jeden Commit mit „Co-authored-by“ als LLM-generiert bezeichnen.

    Der erste yesod-Link ist eine CI-Änderung, daher halte ich es für schwierig, das als Code zu sehen, von dem man abhängig ist.
    Als von einem „LLM-generierten Commit mit einer 1489 Zeilen langen Commit-Message“ die Rede war, erwartete ich, dass der Commit selbst völlig verrückt ist; tatsächlich ist es aber ein vernünftiger Squash-Merge, nur mit einem enorm großen Diff.

    Beim cabal-Commit heißt es, dass das LLM nur Tests generiert habe, und ich frage mich auch, ob ich das als Code betrachten sollte, von dem ich abhängig bin.
    Der git-Commit ist ebenfalls nur CI.

    Ich bezweifle nicht, dass einige dieser Abhängigkeiten LLMs verwenden, aber die vorgelegten Belege halten dem meiner Meinung nach nicht wirklich stand.
    Andererseits steckt deutlich mehr Arbeit darin, als ich erwartet hätte, und es ist gut, etwas Konkretes zu haben, auf das man als Grund verweisen kann, bestimmte Abhängigkeiten nicht zu verwenden.