repo-slopscore: ตรวจจับการมีส่วนร่วมของ AI/LLM ในที่เก็บ Git ผ่านการวิเคราะห์ประวัติการคอมมิต

 (slopscan.ava.pet)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • repo-slopscore ถูกแนะนำว่าเป็นเครื่องมือที่วิเคราะห์ประวัติการคอมมิตของที่เก็บ Git เพื่อตรวจจับการมีส่วนร่วมของ AI/LLM
  • บริการนี้มีหน้าโฮม, การสแกนที่เก็บ, และลิงก์ซอร์สโค้ด โดยซอร์สโค้ดเปิดเผยอยู่ที่ codeberg.org/polyphony/repo-slopscore
  • จำนวนที่เก็บทั้งหมดที่ถูกสแกนแสดงเป็น 3058 แห่ง และรายการสแกนล่าสุดจะแสดง URL ของที่เก็บพร้อมเวลาวิเคราะห์แบบ UTC
  • เป้าหมายการสแกนไม่ได้มีแค่ GitHub แต่รวมถึง Git hosting หลายแห่ง เช่น Codeberg, Bitbucket, SourceHut, git.kernel.org, chromium.googlesource.com เป็นต้น
  • ที่เก็บบางรายการมีรายการซ้ำจากความต่างของเครื่องหมาย slash หรือคำต่อท้าย .git ดังนั้นเวลาตีความรายการควรคำนึงถึง ความต่างในการทำ URL normalization

ประเด็นสำคัญ

  • repo-slopscore ถูกแนะนำว่าเป็นบริการที่ตรวจจับการมีส่วนร่วมของ AI/LLM ในที่เก็บ Git โดยอิงจากการวิเคราะห์ประวัติการคอมมิต
  • หน้าสาธารณะมีฟังก์ชันสแกนที่เก็บ, รายการที่เก็บที่ถูกสแกนล่าสุด, และลิงก์ซอร์สโค้ด
  • จำนวนที่เก็บที่ถูกสแกนทั้งหมดแสดงเป็น 3058 แห่ง
  • รายการสแกนล่าสุดมี helix-editor/helix, Agoric/Agoric-sdk, FiloSottile/age, github/copilot-cli, fish-shell/fish-shell, tmux/tmux, httpie/cli เป็นต้น
  • ลิงก์ผลการสแกนแต่ละรายการอยู่ในรูปแบบที่นำที่อยู่ที่เก็บต้นฉบับซึ่งผ่าน URL encoding แล้วไปต่อท้ายใต้ slopscan.ava.pet/repo/

บริบทสำคัญ

  • เป้าหมายการสแกนไม่ได้จำกัดอยู่ที่ GitHub แต่รวมโดเมนโฮสติ้งหลายแห่ง เช่น Codeberg, Bitbucket, SourceHut, git.kernel.org, chromium.googlesource.com, gcc.gnu.org, gerrit.wikimedia.org, git.ffmpeg.org
  • ในรายการมีโครงการโอเพนซอร์สที่เป็นที่รู้จัก เช่น OpenRGB, coreboot, gentoo/gentoo, guix/guix, wlroots, forgejo, ziglang/zig, FFmpeg, FreeCAD, WebKit, NixOS/nixpkgs
  • ที่เก็บที่เกี่ยวข้องกับความปลอดภัย ระบบ และโครงสร้างพื้นฐานที่แสดงมี Mbed-TLS/mbedtls, OpenVPN/openvpn, WireGuard/wireguard-windows, Yubico/yubikey-manager, NationalSecurityAgency/ghidra, ReFirmLabs/binwalk
  • ในรายการยังมีที่เก็บที่มีชื่อเกี่ยวกับ AI หรือ slop เช่น anthropics/claude-code, anthropics/claudes-c-compiler, codeberg.org/brib/slopfree-software-index, codeberg.org/jruz/slop-detector
  • เวลาวิเคราะห์กระจายตั้งแต่ต้นเดือนพฤษภาคม 2026 ถึงช่วง 00 นาฬิกา UTC ของวันที่ 14 มิถุนายน 2026 และรายการสแกนล่าสุดแสดงรายการตั้งแต่ 2026-06-13 23:22:37 +0000 ถึง 2026-06-14 00:36:00 +0000
  • มีกรณีที่โครงการเดียวกันปรากฏเป็นคนละรายการด้วยรูปแบบ URL ที่ต่างกัน เช่น aur.archlinux.org/yay กับ aur.archlinux.org/yay.git และ TeamNewPipe/NewPipe กับ TeamNewPipe/NewPipe/

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs

  • ไม่อยากพูดถึงสิ่งที่คนอื่นทำในแง่ลบ แต่โปรเจ็กต์นี้ให้ความรู้สึกเหมือนมี ความเป็นลบเป็นเป้าหมายหลัก
    มันดูเหมือนเครื่องมือที่ทำให้การดูแคลนโปรเจ็กต์ซอฟต์แวร์ที่สร้างด้วยเครื่องมือหรือแนวทางที่ตนไม่เห็นด้วย หรือที่รับ contribution แบบนั้น กลายเป็นเรื่องอัตโนมัติ
    การให้คะแนนก็ไม่ได้มีประโยชน์นัก nixpkgs ได้คะแนน 0 (F) เพราะมี “สัญญาณจากคอมมิต” 228 รายการที่ชวนให้คิดว่ามีการใช้ AI แต่ใน repository ของ nixpkgs ตอนนี้มีคอมมิตทั้งหมด 1,016,046 รายการ เท่ากับว่าแค่ 0.022% ของทั้งหมดก็โดนให้ 0 คะแนนแล้ว
    ที่ Bevy ได้คะแนน 97 (A+) แทนที่จะได้ 100 ก็เพราะมี pull request เดียว ที่มีหมายเหตุ “co-authored by Claude” ติดอยู่ ไม่ได้สะท้อนเลยว่า PR นั้นดีไหม, ตอน merge ผู้ดูแลอาจ ไม่ได้เห็นหมายเหตุ “co-authored by” หรือว่า Bevy มี นโยบายเรื่อง AI contribution ที่สมเหตุสมผล อยู่แล้ว
    ประเด็นสำคัญคือเครื่องมือนี้ทิ้ง บริบทและความละเอียดอ่อน ไปหมด มันตัดความจำเป็นที่คนจะต้องเข้าไปดูโปรเจ็กต์เองเวลามีข้อกังวล ทำความเข้าใจว่าผู้ดูแลคิดอย่างไร และคนที่สร้างโปรเจ็กต์นั้นมีเหตุผลหรือความรู้สึกแบบไหน แค่ใส่ URL ก็ได้คะแนนออกมาแล้ว
    ด้วยนัยของคำว่า “slop” และการให้คะแนนแบบรุนแรง มันเลยให้ความรู้สึกจงใจเป็นลบ และยังดูไร้ความเป็นมนุษย์ด้วย เพราะพยายามบีบรวมการตัดสินใจและองค์ประกอบของมนุษย์ที่อยู่ในกระบวนการผลิตซอฟต์แวร์ แม้แต่กรณีที่มี AI ช่วย ให้เหลือเป็นคะแนนเดียว ถ้าเป็นโปรเจ็กต์ที่สนใจซอฟต์แวร์ที่คนอื่นสร้างและวิธีที่พวกเขาสร้างจริง ๆ ก็รู้สึกว่าเครื่องมือนี้และกระบวนการทำมันขาดความใส่ใจและการไตร่ตรอง

    • กังวลว่าคนจะมารังควานฉันเพราะเรื่องนี้ ปีนี้ก็หนักพออยู่แล้ว
    • ดูเหมือนว่าสัญญาณที่ใช้พึ่งพา เกณฑ์ที่เปราะบางมาก ฉันลองใส่ repository ที่โค้ดจาก LLM กับโค้ดที่คนเขียนมีสัดส่วน 50:50 แต่เพราะไม่มีคอมมิตที่ลงชื่อร่วมกัน มันเลยจับได้แค่ agents.md และให้คะแนน 95
      เดิมทีคาดหวังว่าจะเป็นวิธีที่คล้ายแพนแกรม คือดูจากโค้ดจริงเพื่อจับร่องรอยของ LLM
    • จุดประสงค์ของโปรเจ็กต์นี้คือทำให้ข้อมูลโปร่งใส กล่าวคือเป็นข้อมูลว่า “มี ร่องรอยการใช้ LLM ให้เห็นในประวัติคอมมิตหรือ source tree หรือไม่?”
      ไม่มีเครื่องมือไหนสมบูรณ์แบบ แต่สิ่งนี้ช่วยให้ค้นพบข้อมูลนั้นได้ง่ายขึ้น จะเอาข้อมูลนั้นไปใช้อย่างไรขึ้นอยู่กับผู้ใช้ ฉันเห็นด้วยว่าคำว่า “slop” มีปัญหา แต่ไม่เห็นด้วยกับคำวิจารณ์ที่เหลือ
    • น่าเศร้ามากที่ดูเหมือนว่าชุมชนโอเพนซอร์สส่วนใหญ่กำลังกลายเป็นสิ่งที่พวกเขาเคยต่อสู้ต่อต้านเมื่อไม่นานมานี้เอง
      เครื่องมือแบบนี้เมินทุกอย่างแล้วเรียกทุกอย่างว่า slop หรือ vibe coding พร้อมตามมาด้วยปฏิกิริยาที่ไปรังควานเจ้าของโปรเจ็กต์ ค่อนข้างน่าตกใจที่ได้เห็น ความก้าวร้าวจากฝ่ายต่อต้าน AI จากคนที่คิดว่าน่าจะให้คุณค่ากับความเห็นอกเห็นใจ ความเข้าใจ และการเปิดใจ
    • การทำให้พวก vibe coder ไม่พอใจสักไม่กี่คน เทียบไม่ได้เลยกับผลกระทบต่อมนุษย์จากอุตสาหกรรม AI
      ถึงพวก LLM จะเสียใจมากถ้าเอา codebase นี้ไป scrape ก็เถอะ :(

  • มีวิธี opt-out ไม่ให้โปรเจ็กต์ของฉันไปแสดงในรายการนี้ไหม? กังวลเรื่องการคุกคาม เลยอยากตัดโอกาสนั้นทิ้งก่อนที่จะเกิดขึ้นจริง

  • คำว่า “ฉันเป็นผู้เขียนเครื่องมือนี้เลยถือว่าเป็นการโปรโมตตัวเอง” ไม่ได้ใกล้เคียงกับคำเตือนแบบ disclaimer เท่าไร แต่ใกล้กับ การเปิดเผยความเกี่ยวข้อง มากกว่า
    แล้วเพราะมีติ๊ก “I am the author” ให้เห็นอยู่แล้ว มันเลยจะแสดงเป็น “authored by ava” มากกว่า “via ava” จึงดูไม่จำเป็นต้องเขียนย้ำในเนื้อหาอีก

    • เป็นเรื่องที่เกิดจากกำแพงภาษา ฉันเพิ่งเข้ามาในชุมชนนี้ได้ไม่นาน เลยคิดว่าระวังไว้ก่อนน่าจะดีกว่า ขอบคุณที่บอก จะจำไว้

  • รายการของ curl นี่ตลกมาก และดูเหมือนเป็น การตัดสินที่ผิดพลาดแทบสมบูรณ์แบบ

    • ใช่ แก่นของมันคือกลไกที่เรียบง่ายมาก ถึงอย่างนั้น การที่สัญญาณที่ถูก flag ไว้ถูกแสดงออกมาจริงก็ยังมีประโยชน์
      ไม่จำเป็นต้องเชื่อผลจากเครื่องมือแบบตรง ๆ เพราะเราดูเองได้ว่า “อ๋อ อันนี้ false positive” แม้แต่ในโปรเจ็กต์ที่เคยใช้ AI ในอดีตแต่ตอนนี้ไม่ใช้แล้ว การรู้ว่า “อันนี้ใช่ แต่คอมมิตนั้นเกิดเมื่อ 2 ปีก่อน” ก็ช่วยเพิ่มข้อมูลประกอบการตัดสินใจ

  • พอเห็นว่า LibAFL อยู่ในรายการนี้ก็เศร้ามาก ไม่ใช่เพราะมันผิด แต่เพราะฉันโน้มน้าว co-maintainer ไม่สำเร็จให้ อย่าใส่ slop ลงใน codebase
    นี่เป็นเหตุผลใหญ่ที่ทำให้ความตั้งใจของฉันที่จะเข้าไปแก้ไขลดลง

  • ไม่มีแท็ก vibe coding เหรอ

    • ถ้าจะให้สอดคล้องกับโพสต์อื่น ๆ ที่เกี่ยวกับ vibe coding ก็ควรมี แท็ก vibe coding

  • กังวลว่าถ้าโปรเจ็กต์ต่าง ๆ เลิกเปิดเผย การใช้เครื่องมือ LLM เพื่อหลีกเลี่ยงการถูกระบุตัวได้ง่าย การตรวจจับก็จะยิ่งยากขึ้นมาก
    ถ้าจะหยุดการยอมรับใช้งาน หน้าเว็บที่รวบรวมเหตุผลว่าทำไมไม่ควรใช้เครื่องมือ LLM พร้อมบรรณานุกรมอย่างดี อาจมีประสิทธิภาพมากกว่าการประจาน ผู้ดูแลหลายคนอาจได้เห็นเนื้อหาที่สนับสนุน AI มากกว่า จนมุมมองเอนเอียงไปทางนั้น และอาจยังไม่เห็นภาพรวมทั้งหมด

  • มีโพสต์ที่ค่อนข้างเกี่ยวข้องเมื่อไม่นานมานี้: https://lobste.rs/s/avubpi/can_we_measure_software_slop_experiment
    และมีเว็บไซต์คล้ายกันด้วย: https://slop-o-meter.dev/. สิ่งที่ชอบเป็นพิเศษใน implementation นี้ นอกจากดีไซน์ที่สนุกและขี้เล่นแล้ว คือสามารถปรับพารามิเตอร์ของอัลกอริทึมการให้คะแนนได้ตามต้องการ ซึ่งฟังดูสมเหตุสมผล เพราะคงไม่ใช่ว่าทุก repository จะต้องใช้เกณฑ์เดียวกันแบบเป๊ะ ๆ ทั้งหมด แบบประชดหน่อย ๆ ก็คือ implementation นี้เองก็เป็น slop เหมือนกัน :/