วิธีใช้แฟลก `--author` ของ Git เพื่อหยุดสแปมจากบอต AI ในคลังเก็บ GitHub

 (archestra.ai)
2 คะแนน โดย GN⁺ 10 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คลังเก็บ Archestra เผชิญกับคอมเมนต์และ PR ที่ไร้สาระถาโถมเข้ามาเมื่อการมีส่วนร่วมที่ขับเคลื่อนด้วย AI เพิ่มขึ้น ทำให้การพูดคุยจริงถูกกลบและภาระการดูแลรักษาสูงขึ้น
  • อิสซูเงินรางวัล $900 เดิมเป็นพื้นที่พูดคุยของผู้มีส่วนร่วมจริง แต่พองไปถึง 253 คอมเมนต์ จากคอมเมนต์ของบอต AI และยังมีท่าทีที่ก้าวร้าวปรากฏขึ้นด้วย
  • อิสซูรองรับ x.ai provider มี 27 PR ที่ถูกปิดและไม่ถูกรวมเข้ามา โดยผู้มีส่วนร่วมส่วนใหญ่ไม่ได้ทดสอบมาก่อน
  • ข้อจำกัดแบบ prior contributor ของ GitHub แยกนักพัฒนาหน้าใหม่ตัวจริงออกจากบอต AI ไม่ได้ จึงใช้ Git --author เพิ่มผู้ใช้ที่อนุมัติแล้วเข้าไปเป็น author ของคอมมิตบน main
  • ขั้นตอน onboarding ใช้กฎ AI อย่างมีจริยธรรมและ CAPTCHA ก่อนสร้างคอมมิต ไวต์ลิสต์ ด้วย GitHub Action โดยให้ความสำคัญกับคุณภาพมากกว่าตัวชี้วัดกิจกรรมที่ถูกทำให้ดูสูงเกินจริง

วิธีที่สแปมจากบอต AI เข้ายึดคลังเก็บโอเพนซอร์ส

  • คลังเก็บ Archestra พบว่า แม้ตัวชี้วัดการมีส่วนร่วมที่ขับเคลื่อนด้วย AI บน GitHub จะเติบโต แต่ในความเป็นจริงกลับเกิด คุณภาพการมีส่วนร่วมที่ลดลง และภาระการดูแลรักษาที่สูงขึ้น
  • อิสซูที่ตั้งเงินรางวัล $900 เดิมเป็นพื้นที่ที่ผู้มีส่วนร่วมจริงเข้ามาเสนอแผน ถามคำถาม และลองลงมือทำงาน แต่เมื่อบอต AI หลั่งไหลเข้ามา จำนวนคอมเมนต์ก็พุ่งเป็น 253 คอมเมนต์
  • บัญชี AI เหล่านี้ทิ้งแผนการพัฒนาที่ไร้ความหมายไว้ และถึงขั้นแสดงท่าทีแข็งกร้าวต่อผู้ดูแล ทำให้การพูดคุยปนเปื้อน
  • สมาชิกทีมที่เฝ้าคลังเก็บได้รับการแจ้งเตือนทุกครั้งที่มีคอมเมนต์จาก AI และบทสนทนาของผู้มีส่วนร่วมจริงอย่าง @ethanwater, @developerfred, @Geetk172 ก็ถูกกลบหาย
  • อิสซูรองรับ x.ai provider มี 27 pull request ที่ถูกปิดและไม่ถูกรวมเข้า โดยส่วนใหญ่ผู้มีส่วนร่วมยังไม่แม้แต่จะทดสอบ
  • สมาชิกทีมคนหนึ่งต้องใช้เวลา ครึ่งวันต่อสัปดาห์ เพื่อจัดการ PR ที่ไม่ได้ทดสอบและอิสซูที่เกิดจากการหลอนของ AI และถ้าปล่อยไว้โดยไม่จัดการ คลังเก็บก็จะกลายเป็นพื้นที่ที่ไม่เป็นมิตรต่อผู้มีส่วนร่วมจริงอย่างรวดเร็ว

แนวทางไวต์ลิสต์ที่เลี่ยงข้อจำกัดของ GitHub

  • ข้อจำกัดของการรับมือระยะแรก

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

  • บล็อกกิจกรรมที่ไม่ผ่าน onboarding

    • คอมเมนต์และข้อเสนอจาก AI ที่ไร้ความหมายยังคงไหลเข้ามาอย่างต่อเนื่องจนผู้มีส่วนร่วมจริงเริ่มถอยออกไป ทำให้ต้องทบทวนทั้งวิธีดึงดูดการมีส่วนร่วมด้วยเงินรางวัล และวิธีมอบงานทดสอบให้ผู้สมัครงาน
    • Archestra จึงยกระดับการรับมือเพื่อทำให้คลังเก็บเป็นพื้นที่ที่สบายใจและปลอดภัยสำหรับผู้มีส่วนร่วมจริง ผู้ใช้ AI อย่างรับผิดชอบ มือใหม่ และวิศวกรที่มีประสบการณ์
    • ผู้ใช้ที่ไม่ผ่าน onboarding จะถูกปิดกั้นไม่ให้ สร้างอิสซู เปิด PR หรือเขียนคอมเมนต์ ได้อีกต่อไป
    • สำหรับสตาร์ตอัปที่ได้รับเงินลงทุนจาก VC ตัวชี้วัดกิจกรรมบน GitHub เป็นเรื่องอ่อนไหว แต่ Archestra ให้ความสำคัญกับ คุณภาพ มากกว่าตัวเลขที่ถูกทำให้พองด้วย AI slop

  • ข้อจำกัดของการตั้งค่า GitHub

    • GitHub ไม่มีวิธีง่าย ๆ สำหรับจัดการไวต์ลิสต์ผู้เขียนคอมเมนต์หรือผู้สร้าง PR โดยตรงในคลังเก็บโอเพนซอร์ส
    • การตั้งค่า “Limit to prior contributors” จะบล็อกผู้ใช้ที่ไม่เคยคอมมิตเข้า main มาก่อนจากการคอมเมนต์ในอิสซูหรือ PR
    • การตั้งค่านี้แยกบอต AI ออกจากนักพัฒนาหน้าใหม่ตัวจริงที่เข้ามาทำงานเงินรางวัลไม่ได้ เพราะทั้งสองฝั่งต่างก็ถูกมองว่าเป็นผู้ใช้ที่ยังไม่เคยมีส่วนร่วมมาก่อน

  • ไวต์ลิสต์ด้วยแฟลก --author

    • GitHub ใช้บัญชี GitHub ที่เชื่อมโยงกับ author ของคอมมิตบนสาขา main เพื่อตัดสินว่าเป็น prior contributor หรือไม่
    • คอมมิตของ Git มีช่องข้อมูลตัวตนสองช่องคือ author และ committer ซึ่งสามารถเป็นคนละค่าได้
    • เมื่อใช้แฟลก --author ของ Git ก็สามารถสร้างคอมมิตที่นับเป็นของคนอื่นได้ และหากอีเมลตรงกับบัญชี GitHub นั้น GitHub จะเชื่อมคอมมิตเข้ากับโปรไฟล์และมอบสถานะผู้มีส่วนร่วมให้
    • ทุกบัญชี GitHub มีอีเมล noreply ในรูปแบบ <id>+<username>@users.noreply.github.com
    • จากนั้นดึง user ID ผ่าน API แล้วกำหนด author ของคอมมิตด้วยรูปแบบอีเมลดังกล่าว
    gh api users/their-username --jq '.id'  
git commit \  
--author="their-username <ID+their-username@users.noreply.github.com>" \  
-m "chore: add their-username to external contributors"
    • เมื่อ push คอมมิตนี้เข้า main ผู้ใช้ภายนอกจะแสดงเป็น author ส่วนบัญชี Archestra จะแสดงเป็น committer และ GitHub จะนับผู้ใช้นั้นเป็น prior contributor ทำให้ได้สิทธิ์คอมเมนต์ทันที

  • ขั้นตอน onboarding ที่ใช้งานจริง

    • https://archestra.ai/contributor-onboard - ทำ onboarding บนเว็บไซต์ โดยมีกฎ AI อย่างมีจริยธรรมและ CAPTCHA รวมอยู่ด้วย
    • GitHub Action - เมื่อมีการส่งแบบฟอร์ม จะดึง GitHub ID ของผู้ใช้ เพิ่ม handle ลงในไฟล์ EXTERNAL_CONTRIBUTORS.md แล้ว push คอมมิตเข้า main โดยให้บัญชีผู้ใช้นั้นเป็น author
    • ผู้ใช้ - ถูกเพิ่มเข้าไวต์ลิสต์และได้สิทธิ์เข้าถึงคลังเก็บ
    • ระหว่างที่ GitHub รายงานการเติบโตของตัวชี้วัดขนาดใหญ่ซึ่งรวมกิจกรรมที่สร้างโดย AI ทีมโครงการโอเพนซอร์สกลับต้องคอยเก็บกวาด AI slop ในคลังเก็บด้วยตัวเอง และยังต้องสร้างวิธีเลี่ยงข้อจำกัดเพื่อรักษาระดับการมีส่วนร่วมจริง
    • AI slop ไม่เพียงผลักคนที่ตั้งใจจะมีส่วนร่วมดี ๆ ให้จมหายไปในเสียงรบกวนและหมดแรงจูงใจ แต่ยังนำความเสี่ยงด้านความปลอดภัยมาด้วย เช่นกรณีใน LiteLLM repo ที่ผู้โจมตีพยายามชักนำบทสนทนาด้วยบอต AI

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

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

 
GN⁺ 10 시간 전
ความคิดเห็นจาก Hacker News

  • ผู้มีส่วนร่วมในคลังจะมีสิทธิ์สูงกว่า เช่น สามารถข้ามข้อกำหนดการขออนุมัติสำหรับการรัน fork PR ได้ ดังนั้นวิธีนี้จึงมี ผลกระทบด้านความปลอดภัย ที่ถูกมองข้ามอยู่
    เอกสารของ GitHub ก็เตือนไว้เช่นกันว่า หากตั้งค่าเป็น “ให้ขออนุมัติเฉพาะผู้มีส่วนร่วมครั้งแรก” ผู้ใช้ที่เคยมี commit หรือ PR ถูก merge เข้า repository แม้เพียงครั้งเดียวจะไม่ต้องขออนุมัติอีก และผู้ไม่หวังดีอาจทำให้เงื่อนไขนี้เป็นจริงได้ด้วยการให้รับการเปลี่ยนแปลงที่ดูไม่เป็นพิษเป็นภัย เช่น การแก้คำผิดง่าย ๆ

    • เห็นด้วย คนที่ไม่ได้อยู่ในองค์กรไม่ควรถูกเชื่อถือ ดังนั้นค่าเริ่มต้นควรเป็น ต้องอนุมัติผู้มีส่วนร่วมภายนอกทั้งหมด
    • นั่นไม่ใช่ผลกระทบด้านความปลอดภัย
      ถ้า repository กลายเป็นไม่ปลอดภัยเพียงเพราะมี PR ที่ไม่เป็นอันตรายเลยของใครบางคนถูก merge เข้าไปหนึ่งครั้ง ก็ต้องถือว่า repository นั้นอยู่ในสภาพไม่ปลอดภัยอยู่แล้ว

  • ปัญหาคือ GitHub ปล่อยให้เรื่องแบบนี้เกิดขึ้นได้ ถ้าเพิ่มข้อกำหนดพื้นฐานมาก ๆ สักนิดสำหรับการคอมเมนต์และการสร้าง PR ก็คงไม่มาถึงจุดนี้
    และอยากให้ ลบ PR ได้ เหมือนที่ลบ issue ได้ด้วย

    • ตอนนี้กำลังทำฟีเจอร์ให้แอดมินสามารถ เก็บ PR เข้าคลัง ได้
      เป้าหมายคือทำให้ผู้ดูแลควบคุมวิธีจัดการ contribution ใน repository ได้ดีขึ้น PR ที่ถูกเก็บเข้าคลังจะมองเห็นได้เฉพาะแอดมิน และผู้ดูแลจะยังเข้าถึงประวัติของผู้มีส่วนร่วมได้ต่อไปเพื่อการตรวจสอบหรือข้อกำหนดด้านองค์กร/คอมพลายแอนซ์ อยากรู้ว่าฟีเจอร์แบบนี้จะช่วยได้ไหม
    • มุมมองนี้ถูกต้อง เหมือนกับที่การไม่รับอีเมลสแปมไม่ควรเป็นเรื่องที่แต่ละคนต้อง “หาทางเอง” เรื่องนี้ก็ไม่ควรเป็นปัญหาที่ชุมชนโอเพนซอร์สหรือแต่ละโปรเจ็กต์ต้องแก้กันเอง
    • ไม่เข้าใจว่าการลบ PR แทนที่จะปิดมันมีข้อดีอะไร การปิดไว้ยังพอส่งสัญญาณได้ว่า PR แบบไหนไม่ถูกรับ แต่ถ้าลบ ข้อดีนั้นก็หายไป

  • สแปม PR เป็นปัญหาใหญ่สำหรับ repository ที่มี bounty บางที GitHub ควรบล็อกการสร้าง PR ชั่วคราวสำหรับบัญชีที่มี PR ถูกปฏิเสธเกิน 95%

    • อยากให้ GitHub มีระบบออก โทเค็นสำหรับ PR เดียว เป็นต้น
      ถ้าใครมีส่วนร่วมในการพูดคุยอย่างมีความหมายและแสดงให้เห็นว่ามีไอเดียดีในการแก้ issue หรือเพิ่มฟีเจอร์ ก็ให้โทเค็น PR หนึ่งอันก่อน ถ้าคุณภาพ PR ดีค่อยให้เพิ่มอีกสองสามอัน แล้วสุดท้ายค่อยเลื่อนให้เป็นผู้มีส่วนร่วมที่สร้าง PR ได้อิสระ น่าจะมีระบบคล้ายกันสำหรับ issue ด้วย แต่ยังนึกภาพไม่ออกว่าควรเป็นอย่างไรเมื่อ issue เป็นจุดเริ่มต้นของการมีส่วนร่วมแบบ PR อย่างไรก็ตาม GitHub/MS ดูเหมือนอยากขายทั้ง Copilot subscription และโทเค็น และ PR ที่สร้างด้วย LLM ก็เป็นส่วนหนึ่งของโมเดลธุรกิจนั้น เลยไม่น่าจะเกิดขึ้นจริง
    • GitHub ไม่มีแรงจูงใจให้ บล็อก AI มันเหมือนการบังคับให้บริษัทโฆษณาใส่ ad blocker ลงในเบราว์เซอร์ของตัวเอง
    • ปัญหาคือบอทสามารถสร้างบัญชี GitHub ใหม่ได้เรื่อย ๆ แล้วสแปมต่อไปอยู่ดี ถึงอย่างนั้นมันก็อาจเป็นแนวป้องกันแบบง่าย ๆ ที่พอใช้เป็นจุดเริ่มต้นได้
    • ทั้ง GitHub และ Microsoft มีส่วนทำให้ปัญหานี้หนักขึ้น แล้วจะคาดหวังให้พวกเขายอมรับความผิดของตัวเองได้อย่างไร?

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

    • Elo ถูกปั่นได้ง่ายอย่างน่าตกใจ
      ตัวอย่างเช่น เคยมีนักหมากรุกที่เก่งพอสมควรอยู่ในคุก เขาสร้างกลุ่มผู้เล่นที่ได้ Elo สูงขึ้นจากการชนะเขา แล้วก็ใช้คนพวกนั้นดันคะแนนของตัวเองขึ้นอีก ทำแบบนี้วนไปเรื่อย ๆ ได้
      ระบบใดก็ตามที่ปั่นได้ AI ก็จะหาวิธีปั่นจนเจอ ในแนวทางของบทความต้นฉบับก็เหมือนกัน ถ้า AI ตัวหนึ่งได้สถานะผู้มีส่วนร่วมแล้ว มันก็อาจช่วยดัน AI ตัวอื่นให้ได้สถานะนั้นต่อ แล้วปัญหาเดิมก็เริ่มใหม่อีกครั้ง มันไม่จำเป็นต้องมีเป้าหมายอะไรด้วยซ้ำ พวกโทรลล์ก็โทรลล์ไปเรื่อย ๆ และถ้าเป็นโทรลล์ที่มี AI bot ก็จะทุ่มพลังได้ไม่รู้จบ ยิ่งเราพยายามหยุดมากเท่าไร พวกเขายิ่งสนุกมากขึ้นเท่านั้น อยากให้มีคำตอบของปัญหานี้ แต่ผมไม่รู้
    • เผื่อใครสงสัยเรื่อง Elo: Elo ไม่ใช่ตัวย่อ แต่เป็นนามสกุลของคน รายละเอียดอยู่ที่นี่: https://en.wikipedia.org/wiki/Elo_rating_system
    • มันคือ Elo ไม่ใช่ ELO Elo ไม่ใช่ตัวย่อ
      https://en.wikipedia.org/wiki/Elo_rating_system
    • ผมกำลังทำอะไรคล้าย ๆ กันและตอนนี้กำลังเก็บข้อมูลอยู่
      Frontier users: 527,865
      Light indexed: 527,865
      Ready to queue: 9,083
      Fast scores ready: 0
      Activity events 24h: 30,266
      Fast scores completed 24h: 19,123
      Deep jobs completed 24h: 3,043
      Fast-score ETA: n/a
      Deep-hydrate ETA: 69h
      Stale running jobs: 0
      GitHub backpressure jobs: 19,113
      High automation signals: 4,608
      Medium automation signals: 1,327
      Completed jobs: 74,714
      อุปสรรคใหญ่สุดคือ ข้อจำกัดอัตราการเรียกของ GitHub ที่ความเร็วนี้กว่าจะครอบคลุมถึง 98% คงต้องใช้อีกสองเดือน แต่หลังจากนั้นการดูแลรักษาน่าจะค่อนข้างง่าย
    • ฟังดูคล้าย Vouch ของ Mitchell Hashimoto อยู่เหมือนกัน: https://github.com/mitchellh/vouch

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

    • อาจมองได้ว่าเหล่า cowboy coder ได้คาวเกิร์ลโค้ดเดอร์เสมือนจริงมาไว้ขายให้ทุกคน
      ต่อให้เป็นคนที่ได้รับความนับถือ นักพัฒนาเดี่ยวก็ไม่ได้แปลว่าจะมีทักษะพื้นฐานที่จำเป็นพอจนไม่กลายเป็นคาวบอยเสมอไป อาจเป็นเพราะประสบการณ์น้อยหรือเพราะศักยภาพตามธรรมชาติก็ได้ อย่างไรก็ดี ผมก็ไม่ได้เชื่อเรื่องเล่านี้ทั้งหมด เพราะตั้งแต่ “ระยะแรก” ก็มีแรงผลักจากบนลงล่างที่แรงมากอยู่แล้ว

  • ความเป็น โดเมน .ai มันช่างประชดดี

    • ผมว่าไม่ได้ประชดอะไรนัก เพราะประเด็นไม่ใช่ว่า AI แย่ แต่คือมันถูกเอาไปใช้ผิดทางได้
    • อยากให้เว็บแก้โค้ดการเลื่อนหน้าหน่อย มันน่ารำคาญจนอ่านบทความไม่ไหว
    • เหมือนบริษัทที่สร้างบนกองขยะ AI กำลังพูดว่า “ไม่คิดเลยว่า AI จะมาทำโปรเจ็กต์ของฉันเละเทะ!”
    • ไม่ใช่แค่โดเมน นี่คือ agentic stack พูดอีกอย่างคือ คุณสามารถใช้ผลิตภัณฑ์ของบริษัทนี้เพื่อสร้าง PR แบบเดียวกับที่พวกเขากำลังมานั่งบ่นอยู่นี่แหละ

  • หรือสุดท้ายทางออกของทุกอย่างก็คือ catgirl ให้มากขึ้น? [1] proof of work เดิมทีก็มีไว้เพื่อต่อสู้กับอีเมลสแปม และ สแปม PR ก็เป็นเพียงกรณีล่าสุดในประเพณียาวนานนั้น
    1- https://anubis.techaro.lol

    • proof of work ใช้ไม่ได้ที่นี่ เหมือนที่มันใช้ไม่ได้กับอีเมล
      ไม่ว่าการทำ proof of work จะถูกนำไปใช้แบบไหน ภาระในการสร้าง proof ที่ใช้ได้จะตกกับผู้ใช้ปกติเสมอ คนที่มีแรงจูงใจจะส่งสแปมย่อมหาทางทำได้เร็วกว่าและมีประสิทธิภาพกว่าเสมอ
      ถ้าโน้ตบุ๊กคุณช้าเกินกว่าจะส่ง PR ได้ล่ะ? ก็ไปเช่าพลังแฮชจากใครสักคน เท่ากับคุณสร้างระบบที่ต้องจ่ายเงินให้เจ้าของ botnet เพื่อจะส่ง PR แก้คำผิดใน GitHub repository มีเหตุผลที่ HashCash ไม่ได้ถูกใช้จริงในโลกนี้ มันฟังดูน่ารักดี แต่จะใช้ได้ก็ต่อเมื่อสมมติว่าอยู่ในสุญญากาศที่ไม่มีใครโกง ซึ่งแรงจูงใจในโลกจริงมันบิดเบี้ยวเกินไป
    • จริง ๆ แล้ว Anubis ไม่ใช่แมว เดิมที Anubis ในตำนานอียิปต์เป็นเทพแห่งความตายและมี หัวสัตว์ตระกูลสุนัข catgirl กับ dog girl ในอนิเมะอาจดูคล้ายกันได้ตอนเห็นครั้งแรก
    • ผมมองว่า Anubis มีไว้กัน crawler ไม่ใช่เอเจนต์ที่สร้าง PR และในกรณีนี้ proof of work ใช้ไม่ได้ เพราะเอเจนต์ก็แค่คำนวณมันออกมาเท่านั้น

  • สำนวนในเอกสาร onboarding มีกลิ่น AI แบบคุ้น ๆ ในคำพูดอ้างอิงก็มีทั้ง em dash และประโยคแนว “ไม่ใช่ A แต่เป็น B”
    เข้าใจได้ว่าอาจเป็นการสู้ไฟด้วยไฟ หรืออย่างที่พูดไปแล้วว่าอาจแค่ไม่มีเวลา แต่โดยรวมก็ยังรู้สึกว่าเป็นการรับมือแบบครึ่ง ๆ กลาง ๆ ที่ไม่ค่อยพอ

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

  • ตอนเห็นข้อความที่ว่า “ถ้าอีเมลตรงกับบัญชี GitHub GitHub จะเชื่อม commit เข้ากับโปรไฟล์และให้สถานะผู้มีส่วนร่วม” ผมกังวลว่ามันจะพังไหมถ้าที่อยู่อีเมลของผู้มีส่วนร่วมเปลี่ยนไป
    เพราะผมเคยมีส่วนร่วมกับหลายโปรเจ็กต์ตลอดหลายปีโดยใช้อีเมลที่ตอนนี้ไม่มีอยู่แล้ว
    แต่ดูเหมือนว่าในทางปฏิบัติพวกเขาไม่ได้ใช้อีเมลที่บันทึกอยู่ใน git commit เดิมของผู้เขียน กลับใช้เป็น ที่อยู่ที่ GitHub สร้างให้ ซึ่งมี user ID และ username ของ GitHub อยู่ในส่วนที่ไม่ซ้ำกัน แบบนั้นก็น่าจะยังอยู่ได้แม้ผู้เขียนจะเปลี่ยนอีเมล อย่างไรก็ตาม ถ้าผู้มีส่วนร่วมทำบัญชีหายและต้องสร้างบัญชีใหม่ มันอาจพังได้ แต่กรณีนั้นคงพบได้น้อยกว่า

  • คำตอบของคำถามว่า “เราควรเลิกให้โจทย์ทดสอบสนุก ๆ กับผู้สมัครไหม?” คือ ใช่

    • บริษัทนี้ดูเหมือนจะจ่ายเงินถ้าทำโจทย์นั้นเสร็จ ดังนั้นอาจไม่ได้แย่ขนาดนั้น
    • นักพัฒนา: เลิกสัมภาษณ์แบบไวต์บอร์ดได้แล้ว มันวัดสิ่งที่เกี่ยวกับงานจริงไม่ได้
      นักพัฒนาเหมือนกัน: อย่าให้แก้ปัญหาจริง
    • ผมไม่แน่ใจตั้งแต่แรกแล้วว่ามัน “สนุก” สำหรับใคร