repo-slopscore: Erkennung von AI/LLM-Beiträgen in Git-Repositories durch Analyse der Commit-Historie

 (slopscan.ava.pet)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • repo-slopscore wird als ein Tool vorgestellt, das durch die Analyse der Commit-Historie von Git-Repositories AI/LLM-Beiträge erkennt
  • Der Dienst bietet Home, Repository-Scan und einen Link zum Source Code; der Source Code ist auf codeberg.org/polyphony/repo-slopscore öffentlich verfügbar
  • Die Gesamtzahl der gescannten Repositories wird mit 3058 angezeigt, und die Liste der zuletzt gescannten Repositories zeigt zusammen mit der Repository-URL auch den UTC-Zeitpunkt der Analyse an
  • Zu den Scan-Zielen gehören nicht nur GitHub, sondern auch verschiedene Git-Hostings wie Codeberg, Bitbucket, SourceHut, git.kernel.org und chromium.googlesource.com
  • Bei einigen Repositories existieren aufgrund von Unterschieden bei Schrägstrichen oder dem Suffix .git doppelte Einträge, daher sollte bei der Interpretation der Liste die URL-Normalisierungsdifferenz berücksichtigt werden

Kernaussagen

  • repo-slopscore wird als ein Dienst vorgestellt, der auf Basis der Analyse der Commit-Historie AI/LLM-Beiträge in Git-Repositories erkennt
  • Die öffentliche Seite bietet eine Repository-Scan-Funktion, eine Liste der zuletzt gescannten Repositories und einen Link zum Source Code
  • Die Gesamtzahl der gescannten Repositories wird mit 3058 angezeigt
  • In der Liste der zuletzt gescannten Repositories sind unter anderem helix-editor/helix, Agoric/Agoric-sdk, FiloSottile/age, github/copilot-cli, fish-shell/fish-shell, tmux/tmux und httpie/cli enthalten
  • Jeder Link zu einem Scan-Ergebnis ist in der Form aufgebaut, dass unter slopscan.ava.pet/repo/ die URL-kodierte Originaladresse des Repositories angehängt wird

Wichtiger Kontext

  • Die Scan-Ziele sind nicht auf GitHub beschränkt, sondern umfassen mehrere Hosting-Domains wie Codeberg, Bitbucket, SourceHut, git.kernel.org, chromium.googlesource.com, gcc.gnu.org, gerrit.wikimedia.org und git.ffmpeg.org
  • Die Liste enthält bekannte Open-Source-Projekte wie OpenRGB, coreboot, gentoo/gentoo, guix/guix, wlroots, forgejo, ziglang/zig, FFmpeg, FreeCAD, WebKit und NixOS/nixpkgs
  • Als sicherheits-, system- und infrastrukturbezogene Repositories werden unter anderem Mbed-TLS/mbedtls, OpenVPN/openvpn, WireGuard/wireguard-windows, Yubico/yubikey-manager, NationalSecurityAgency/ghidra und ReFirmLabs/binwalk angezeigt
  • In der Liste sind auch Repositories mit Namen rund um AI oder slop enthalten, darunter anthropics/claude-code, anthropics/claudes-c-compiler, codeberg.org/brib/slopfree-software-index und codeberg.org/jruz/slop-detector
  • Die Analysezeitpunkte verteilen sich von Anfang Mai 2026 bis zur UTC-Stunde 00 am 14. Juni 2026; die Liste der zuletzt gescannten Repositories zeigt Einträge von 2026-06-13 23:22:37 +0000 bis 2026-06-14 00:36:00 +0000
  • Es gibt Fälle, in denen dasselbe Projekt unter verschiedenen URL-Formen als getrennte Einträge erscheint, etwa aur.archlinux.org/yay und aur.archlinux.org/yay.git sowie TeamNewPipe/NewPipe und TeamNewPipe/NewPipe/

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare

  • Ich möchte nicht schlecht über etwas sprechen, das jemand anderes gemacht hat, aber dieses Projekt wirkt, als sei Negativität der eigentliche Zweck.
    Es sieht aus wie ein Tool, das die Verachtung für Softwareprojekte automatisiert, die mit Werkzeugen oder auf Arten erstellt wurden, denen man nicht zustimmt, oder die solche Beiträge annehmen.
    Auch die Bewertung ist nicht nützlich. nixpkgs gets a 0 (F) score bekommt 0 Punkte wegen 228 „Commit-Signalen“, die auf AI-Nutzung hindeuten sollen, aber das nixpkgs repository hat derzeit 1.016.046 Commits. Das bedeutet, dass schon 0,022 % des Ganzen zu 0 Punkten führen.
    Bevy gets a 97 (A+) score bekommt auch nicht 100 Punkte, und zwar nur wegen eines single pull request mit dem Vermerk “co-authored by Claude”. Ob der PR gut war, ob die Maintainer beim Mergen den “co-authored by”-Vermerk übersehen haben oder ob Bevy eine vernünftige AI-Beitragsrichtlinie hat, wird nicht berücksichtigt.
    Der Kernpunkt ist, dass dieses Tool Kontext und Nuancen wegwirft. Es nimmt einem die Notwendigkeit ab, sich ein Projekt bei Bedenken selbst anzusehen und herauszufinden, was die Maintainer denken und welche Gründe und Gefühle die Menschen hinter dem Projekt haben. Man gibt einfach eine URL ein und bekommt nur eine Punktzahl.
    Wegen der Konnotation des Wortes „slop“ und der harten Bewertung wirkt es absichtlich negativ, und weil es menschliches Urteilsvermögen und menschliche Anteile an der Softwareproduktion, selbst bei AI-gestützter Hilfe, in einer einzigen Zahl plattdrückt, wirkt es auch entmenschlichend. Für ein Projekt, das angeblich großes Interesse an der Software anderer Leute und an ihrer Entstehungsweise hat, wirken dieses Tool und seine Entwicklung wenig rücksichtsvoll und wenig durchdacht.

    • Ich mache mir Sorgen, dass Leute mich deswegen belästigen werden. Dieses Jahr war ohnehin schon schwer genug.
    • Die Signale scheinen auf ziemlich fragilen Kriterien zu beruhen. Ich habe ein Repository eingegeben, in dem der Code zu 50:50 aus LLM-generiertem und von Menschen geschriebenem Code besteht, und weil es keine mitunterzeichneten Commits gab, wurde nur agents.md als Hinweis erkannt und es bekam 95 Punkte.
      Ich hatte erwartet, dass es eher wie eine fast pangrammartige Methode funktioniert, die im tatsächlichen Code nach LLM-Spuren sucht.
    • Der Zweck dieses Projekts ist es, die Daten transparent zu machen. Die Daten lauten also: „Sind in der Commit-Historie oder im Source-Tree Spuren von LLM-Nutzung sichtbar?“
      Kein Tool ist allmächtig, aber es erleichtert das Auffinden dieser Informationen. Wie man diese Informationen nutzt, liegt beim Benutzer. Dass die Bezeichnung „slop“ problematisch ist, sehe ich genauso, aber der restlichen Kritik stimme ich nicht zu.
    • Es macht mich sehr traurig, dass ein großer Teil der Open-Source-Community inzwischen zu dem geworden zu sein scheint, wogegen sie noch vor Kurzem selbst gekämpft hat.
      Solche Tools ignorieren alles und nennen einfach alles slop oder Vibe Coding, und dann kommen Reaktionen, bei denen die Projektinhaber belästigt werden. Es überrascht mich ziemlich, von Menschen, bei denen ich dachte, sie legten Wert auf Empathie, Verständnis und Offenheit, die Aggressivität des Anti-AI-Lagers zu sehen.
    • Ein paar Vibe Coder zu verärgern ist nichts im Vergleich zum menschlichen Schaden der AI-Industrie.
      Es wäre natürlich sehr schade für sie, wenn LLMs diese Codebasis scrapen würden :(

  • Gibt es eine Möglichkeit, Opt-out zu machen, damit mein Projekt nicht in dieser Liste erscheint? Ich habe Sorge vor Belästigung und würde diese Möglichkeit gern ausschließen, bevor es tatsächlich passiert.

  • „Ich bin der Autor dieses Tools, also Eigenwerbung“ ist weniger ein Disclaimer als eher eine Offenlegung.
    Und weil das Häkchen bei „I am the author“ sichtbar ist, wird „authored by ava“ statt „via ava“ angezeigt. Deshalb scheint es nicht nötig zu sein, das im Text noch einmal extra zu erwähnen.

    • Das lag an der Sprachbarriere. Ich bin in dieser Community noch ziemlich neu und dachte, vorsichtiger zu sein wäre besser. Danke für den Hinweis, ich merke es mir.

  • Der curl-Eintrag ist lustig und wirkt fast wie eine völlig unzutreffende Bewertung.

    • Stimmt. Der Kern ist ein sehr einfacher Mechanismus. Trotzdem ist es hilfreich, dass die markierten Signale tatsächlich angezeigt werden.
      Man muss dem Ergebnis des Tools nicht blind vertrauen, sondern kann selbst sehen: „Ah, das ist ein False Positive.“ Auch bei Projekten, die früher AI genutzt haben, es jetzt aber nicht mehr tun, liefert „das stimmt, aber dieser Commit ist zwei Jahre alt“ zusätzliche Grundlage für eine Einschätzung.

  • Es macht mich sehr traurig, LibAFL in dieser Liste zu sehen. Nicht, weil es falsch wäre, sondern weil ich die Co-Maintainer nicht davon überzeugen konnte, keinen slop in die Codebasis zu bringen.
    Das ist ein wichtiger Grund dafür, warum ich weniger Motivation habe, Dinge daran zu verbessern.

  • Es gibt kein Vibe-Coding-Tag.

    • Um mit anderen Beiträgen über Vibe Coding konsistent zu sein, braucht es ein Vibe-Coding-Tag.

  • Ich mache mir Sorgen, dass die Erkennung deutlich schwieriger wird, wenn Projekte beginnen, die Nutzung von LLM-Tools nicht mehr offenzulegen, um nicht leicht identifiziert zu werden.
    Um die Verbreitung zu verhindern, könnte eine gut zusammengestellte Seite mit Referenzen, die erklärt, warum man keine LLM-Tools verwenden sollte, wirksamer sein als öffentliches Beschämen. Viele Maintainer waren möglicherweise stärker AI-freundlichen Inhalten ausgesetzt und haben sich deshalb in diese Richtung orientiert, ohne das Gesamtbild zu sehen.

  • Vor Kurzem gab es einen einigermaßen verwandten Beitrag: https://lobste.rs/s/avubpi/can_we_measure_software_slop_experiment
    Es gibt auch eine ähnliche Website: https://slop-o-meter.dev/. Was mir an dieser Umsetzung besonders gefällt, ist nicht nur das lustige und verspielte Design, sondern auch, dass man die Parameter des Bewertungsalgorithmus nach Belieben anpassen kann. Es ist vernünftig, dass nicht auf alle Repositories exakt dieselben Maßstäbe angewendet werden. Ironischerweise ist die Implementierung selbst auch slop :/