ต้องเปิดเผยเมื่อมีการใช้เครื่องมือ AI ในการมีส่วนร่วม

 (github.com/ghostty-org)
5 คะแนน โดย GN⁺ 2025-08-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในการอภิปราย PR ของโปรเจกต์โอเพนซอร์ส Ghostty มีการเสนอความเห็นว่าควร เปิดเผยอย่างชัดเจน ว่ามีการใช้เครื่องมือ AI หรือไม่
  • ผู้เสนอชี้ว่า AI ยังมักสร้าง โค้ดคุณภาพต่ำ อยู่บ่อยครั้ง โดยเฉพาะเมื่อ ผู้ใช้ที่ยังไม่ชำนาญส่งงานโดยไม่ตรวจทาน ปัญหาจะยิ่งรุนแรง
  • เป้าหมายของการเปิดเผยคือเพื่อให้ผู้ดูแลโปรเจกต์ประเมินความน่าเชื่อถือของ PR ได้ และสามารถให้ ฟีดแบ็กเชิงการเรียนรู้แก่ผู้มีส่วนร่วมที่เป็นมนุษย์ พร้อมลดความพยายามที่ไม่จำเป็นกับงานที่สร้างโดย AI แบบล้วน ๆ
  • ผู้เข้าร่วมอีกคนเสนอว่าสามารถเพิ่มเช็กลิสต์ที่รวมการใช้ AI ผ่าน เทมเพลต PR ได้
  • อีกด้านหนึ่ง ยังมีแนวคิดว่าหากเครื่องมือ AI สามารถ ทำ byline พิเศษให้เป็นมาตรฐาน และบันทึกลงในข้อความคอมมิตของ GitHub ได้อัตโนมัติ ก็จะช่วยรับประกันทั้งความโปร่งใสและการเปิดเผยเครื่องมือที่ใช้

ความจำเป็นของการเปิดเผยการใช้ AI

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

ข้อเสนอให้นำเทมเพลต PR มาใช้

  • Yawaramin เสนอให้ใช้ ฟีเจอร์เทมเพลต PR ของ GitHub เพื่อระบุการใช้ AI
    • พร้อมกันนั้นยังสามารถใส่เช็กลิสต์อย่าง Developer Certificate of Origin(DCO) ได้ด้วย
  • วิธีนี้จะช่วยให้ผู้มีส่วนร่วมทุกคน แจ้งการใช้ AI ได้อย่างสม่ำเสมอในรูปแบบเดียวกัน

แนวคิดการทำให้เป็นมาตรฐานบน GitHub

  • Tobi เสนอให้ GitHub สร้าง มาตรฐาน byline เฉพาะสำหรับ AI
    • ทุกครั้งที่มีการใช้เครื่องมือ AI ให้บันทึกลงในไฟล์ staging ของ .git และเพิ่มเข้าไปในข้อความคอมมิตโดยอัตโนมัติ
    • GitHub สามารถจัดทำรายการเหล่านี้และใส่ลิงก์ไปยังเครื่องมือ → ผู้ดูแลโปรเจกต์สามารถตรวจสอบแหล่งที่มาได้
    • ขณะเดียวกัน เครื่องมือ AI ก็ไม่จำเป็นต้อง ใช้ co-authors แบบสแปมในทางที่ผิดเหมือนปัจจุบัน
  • แนวทางนี้ถูกประเมินว่าเป็นวิธีที่ตอบโจทย์ทั้ง ความโปร่งใส การโปรโมตเครื่องมือ และประสิทธิภาพในการดูแลโปรเจกต์

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

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

 
GN⁺ 2025-08-22
ความคิดเห็นจาก Hacker News
  • มีการชี้ให้เห็นว่าแม้กระทั่งตอนใช้ "AI" ก็เกิดปัญหาการปนเปื้อนด้านทรัพย์สินทางปัญญาได้ แต่พวกเรากลับเมินเรื่องนี้อยู่ หากมีใครสักคนท่องจำโค้ดของโปรเจกต์โอเพนซอร์สทั้งหมดแล้วเขียนออกมาตามต้องการได้ เราก็ควรห้ามคนแบบนั้นในบริษัทอยู่แล้ว แต่พอเป็นกรณีของ AI กลับมีการหาเหตุผลและข้ออ้างต่าง ๆ เพื่อปฏิเสธข้อเท็จจริงนี้อยู่ ในทางปฏิบัติมันเหมือนการฟอกโค้ดจากหลายแหล่งอย่างหลวม ๆ รวมถึงโค้ดที่มี GPL ด้วย และสิ่งนี้แฝงความเสี่ยงร้ายแรงต่อบริษัทที่ยืนอยู่บนทรัพย์สินทางปัญญา (IP)
    • ศาลสหรัฐฯ เคยตัดสินแล้วว่าการใช้ข้อมูลฝึกเป็นการใช้งานแบบแปลงรูป (transformative) แม้จะยังมีรายละเอียดอีกมากที่ต้องจัดการ แต่สุดท้ายมันคือการเปลี่ยนแปลงที่ย้อนกลับไม่ได้ หากต้องการให้การสร้าง IP เป็นกิจกรรมที่ยั่งยืนในเชิงเศรษฐกิจ ระบบกฎหมายที่เกี่ยวข้องก็ต้องเปลี่ยนด้วย
    • ถ้าตามตรรกะนี้ StackOverflow หรือแม้แต่ตำราเรียนแทบทุกสาขาก็ควรถูกห้ามด้วย ในโลกความจริงโปรแกรมเมอร์ย่อมหลีกเลี่ยงไม่ได้ที่จะเห็นโค้ดของคนอื่น
    • มองตามจริงแล้ว นอกจากคนที่มีผลประโยชน์ทางการเงินเกี่ยวข้อง ก็แทบไม่มีใครมองประเด็นกฎหมาย AI อย่างจริงจัง โชคดีที่ส่วนใหญ่ก็เพิกเฉยต่อประเด็นนี้ และระบบกฎหมายก็ยังทำงานได้ดีตราบเท่าที่ไม่ขัดขวางความก้าวหน้า
  • รู้สึกประทับใจมากกับส่วนที่ mitchellh พูดว่า "ช่วยเหลือผู้ร่วมพัฒนาใหม่จนถึงที่สุด และช่วยให้ PR ถูก merge" การให้ฟีดแบ็กเพื่อให้นักพัฒนามือใหม่เติบโตเป็นสิ่งที่มีคุณค่ามากจริง ๆ แต่ถ้าผู้ส่ง PR เอาฟีดแบ็กนั้นไปโยนให้ AI ทันที แล้วตัวเองไม่ได้เรียนรู้อะไรเลย มันก็เป็นการเสียเวลา
    • จากนี้ไปนักพัฒนามือใหม่คงจะไม่มีสภาพแวดล้อมการทำงานแบบไร้ AI อีกแล้ว
  • ดีใจมากที่หน้าแรกของ HN วันนี้เต็มไปด้วยเนื้อหาดี ๆ ที่อิงประสบการณ์จริง มีเรื่องเล่าตรงไปตรงมาโดยไม่มีความกลัวเกินเหตุหรือการพูดเกินจริง บนคอมพิวเตอร์ส่วนตัวฉันปิด AI assist ไว้ และในบริษัทก็ใช้เฉพาะตอนจำเป็นจริง ๆ แบบจำกัดมาก AI assist เก่งมากกับงานย่อยที่แยกเป็นหน่วยเล็ก ๆ (atomic work) แต่แย่มากกับงานซับซ้อนที่มีหลายส่วนประกอบ (compound work) สุดท้ายแล้ว AI ก็ขึ้นอยู่กับว่ามนุษย์จะใช้งานมันอย่างไร สติปัญญาของมนุษย์ยังเป็นแกนหลัก
    • ยิ่งนานยิ่งเห็นด้วยกับคำว่า "AI ฉลาดได้เท่าที่มนุษย์ใช้งานมัน" ตอนแรกไม่เข้าใจว่าทำไม AI ตัวเดียวกันถึงให้ผลลัพธ์ต่างกันสุดขั้ว แต่ตอนนี้สัมผัสได้จริงว่า AI ไม่ใช่เวทมนตร์ คิดย้อนกลับไปแล้วรู้สึกว่าตัวเอง naïve ที่เคยคาดหวังว่าคนที่อธิบายเรื่องให้เพื่อนร่วมทีมยังไม่ได้ จะดึงคุณค่าจาก AI ออกมาได้ ตรงกันข้าม AI อาจยิ่งถ่างช่องว่างระหว่างวิศวกรธรรมดากับวิศวกรที่เก่งมากให้กว้างขึ้น แม้ตอนนี้ยังรู้สึกซับซ้อนอยู่ แต่ก็เริ่มเข้าใจแล้วว่าทำไมบางคนถึงรู้สึกว่า AI ไม่มีประโยชน์
    • มีการอ้างถึงข้อสรุปจาก “No Silver Bullets, Refired” ของ Frederik P. Brooks ว่าการพัฒนาซอฟต์แวร์มีความซับซ้อนโดยเนื้อแท้ และแทนที่จะรอคอยวิธีแก้ปัญหาแบบปฏิวัติวงการ เราควรมุ่งหาการเพิ่มผลิตภาพแบบค่อยเป็นค่อยไป มุมมองนี้ให้ความรู้สึกทั้งสมจริงและมีความหวัง
    • รู้สึกวลี "AI ฉลาดได้เท่าที่มนุษย์ใช้งานมัน" น่าสนใจดี เพราะสุดท้ายแล้วคนที่โพสต์ว่า "ฉันสร้างไลบรารีเจ๋ง ๆ ได้ในวันเดียวด้วย AI" ก็มักเป็นนักพัฒนาที่เก่งอยู่แล้วตั้งแต่แรก
    • ตัวฉันเองก็เห็นด้วย บริษัทกำลังอยู่ในช่วง hack week เลยมีการทดลองใช้เครื่องมือ AI กันทั้งองค์กร และผลที่ดีจริง ๆ มักมาจากการประยุกต์ใช้แบบมีการวิเคราะห์ มี guardrail และมี grounded generation ช่วงนี้ให้ความรู้สึกว่ากระแสแชตบอตไร้สาระเริ่มซาไปแล้ว และพาราไดม์กำลังรีเซ็ตกลับไปสู่แก่นของแมชชีนเลิร์นนิง
    • มองว่ามนุษย์เป็นคนตัดสินใจเรื่องสำคัญ แล้ว AI ค่อยเชื่อมส่วนที่เหลือเข้าด้วยกัน อะไรคือการตัดสินใจสำคัญ และอะไรคือแค่งานเชื่อมจุดเฉย ๆ นั้นแตกต่างกันไปตามแต่ละโดเมน แต่ในความเป็นจริงโค้ดส่วนใหญ่ (ราว 80~90%) เป็นงานซ้ำ ๆ หรือเชื่อมส่วนต่าง ๆ เข้าหากัน หากรักษาเส้นแบ่งนี้ได้ดี ผลิตภาพจะเพิ่มขึ้นมาก แต่ถ้าปล่อยให้ AI ตัดสินใจเรื่องสำคัญ ความเสียหายจะยิ่งมากกว่าเดิม จนบางทีทิ้งแล้วทำใหม่ยังดีกว่า ตัวอย่างของการตัดสินใจสำคัญ เช่น การออกแบบฐานข้อมูล การกำหนด type การเลือก dependency การออกแบบระบบ/โครงสร้างพื้นฐาน/หน้าจอ การเลือกหัวข้อทดสอบ และการจัดโครงสร้างโค้ด ส่วนงานที่ AI ทำได้ดีคือ CRUD, API handler, การแปลงโครงสร้างข้อมูลง่าย ๆ, สคริปต์ deploy, การเขียนเทสต์, โค้ด UI component, การจัดสไตล์ และการจัดข้อมูลชั่วคราวให้เป็นระเบียบ ทั้งนี้ AI ก็ยังช่วยได้ในเรื่องการค้นคว้า การสำรวจไอเดีย และการเปรียบเทียบทางเลือกต่าง ๆ แต่ข้อสรุปและการลงมือทำจริงมนุษย์ต้องเป็นผู้ดูเอง
  • ฉันไม่ใช่คนที่คลั่ง AI อะไรมาก แต่ก็มองว่ามันเป็นแค่เครื่องมือชนิดหนึ่ง ไม่ว่าใครจะเตรียม PR มาอย่างไร ถ้าผลลัพธ์ออกมาดีก็ไม่ค่อยสนใจ อย่างไรก็ตาม ถ้าเมนเทนเนอร์ขออะไรไว้ก่อนส่ง PR ก็ควรทำตามนั้นเพื่อเป็นมารยาท
    • ที่มาของ PR และวิธีที่มันถูกสร้างขึ้นมานั้นสำคัญ เพราะผู้รีวิวเองก็มีข้อผิดพลาดและข้อจำกัด จึงยิ่งต้องพึ่งพาความไว้วางใจ หากไม่มีความไว้วางใจ ก็ควรไม่รับเข้ากระบวนการรีวิวตั้งแต่แรก นี่ก็เป็นเหตุผลเดียวกับที่ทีม Linux kernel แบนมหาวิทยาลัยมินนิโซตาจากการทดลองของพวกเขา
    • ดูเหมือนจะยังไม่ได้ตอบประเด็นหลักของบทความจริง ๆ นั่นคือ "เป้าหมายคือช่วยให้ผู้ร่วมพัฒนาใหม่เติบโตได้ แต่ถ้าคู่สนทนาเป็น AI มันก็เป็นแค่การเสียเวลา"
    • AI สามารถสร้าง PR ได้วันละ 1,000 อัน คุณอาจกำลังคิดถึงแต่ PR ที่ AI ช่วยทำออกมาได้ดี แต่ในโลกจริง AI ก็สามารถทำให้เมนเทนเนอร์ของโปรเจกต์ลำบากอย่างมหาศาลได้เช่นกัน
    • ตามข้อมูลจากสำนักงานลิขสิทธิ์สหรัฐฯ ผลลัพธ์ที่ AI สร้างขึ้นไม่อยู่ภายใต้การคุ้มครองลิขสิทธิ์ ดังนั้นแม้เพื่อจุดประสงค์ด้านไลเซนส์ก็ควรต้องเปิดเผยว่าใช้ AI หากฝ่าฝืน คุณอาจสูญเสียลิขสิทธิ์ของผลงานทั้งหมด รายละเอียดดูได้จากรายงานและหน้าหลัก
    • ถ้าใช้ AI แล้วมีคนถามเรื่องนั้น ฉันจะเปิดเผยเสมอ แต่ถ้าไม่ได้ถามอย่างเฉพาะเจาะจง ก็จะไม่บอกล่วงหน้าแบบ 'ตามมารยาททั่วไป' คิดว่าคนส่วนใหญ่ถือว่าการใช้ AI เป็นเรื่องปกติหรือไม่ก็ไม่ได้สนใจมัน และมองว่ามันเป็นแค่ป้ายเล็ก ๆ ที่ทำให้เสียสมาธิมากกว่า เหมือนแจ้งเตือนของ dependabot ที่มีขึ้นมาก็ไม่ได้ทำให้คนสนใจจริง ๆ
  • มีคนถามหลายครั้งว่า "แล้ว autocomplete ของฉันล่ะ" แต่ในเอกสารนโยบายก็ยกเว้นไว้อย่างชัดเจนแล้วว่า ถ้าเป็นแค่คีย์เวิร์ดหรือวลีสั้น ๆ แบบ tab autocomplete ก็ไม่จำเป็นต้องเปิดเผย แนะนำให้อ่านเอกสาร (หรือ PR) ให้ดี
  • นโยบายนี้ฟังขึ้นเพราะมีการอธิบายบริบทเพิ่มเติม นโยบายเกี่ยวกับ AI หลายฉบับที่เคยเห็นก่อนหน้านี้ออกแนวเป็นแถลงการณ์เชิงอุดมการณ์มากกว่า แต่ที่นี่อธิบายเหตุผลของข้อกำหนดและทิศทางต่อจากนี้ไว้ จึงดูสมจริงกว่ามาก อยากให้มีแนวทางแบบนี้เพิ่มขึ้น
  • กังวลว่านโยบายนี้สุดท้ายจะทำให้คนซื่อสัตย์ใช้ AI ได้ยากขึ้นหรือไม่ เพราะถ้ายอมรับว่าใช้ AI แล้ว PR จะได้รับความสนใจน้อยลง ทุกคนก็อาจเลือกปิดบังกันหมดหรือเปล่า
    • คิดว่ามันไม่ง่ายขนาดนั้น คนที่ออกนโยบายนี้ (mitchellh) เองก็ใช้ LLM เหมือนกัน ดังนั้นถ้าคุณอธิบายได้ว่าคุณเข้าใจงานที่ตัวเองทำอย่างเพียงพอ และใช้ AI แค่เพื่อความสะดวก ก็คงไม่ทำให้เสียความน่าเชื่อถือมากนัก
    • ความกังวลนี้อาจเป็นจริงได้ เพราะ AI สามารถผลิตโค้ดแบบ "ดูเผิน ๆ เหมือนถูก แต่จริง ๆ เละเทะ" ได้เป็นจำนวนมาก ถ้าความไม่ไว้วางใจต่อโค้ดจาก AI เพิ่มขึ้น นั่นก็เป็นปัญหาของ AI ไม่ใช่ปัญหาของคน เราจำเป็นต้องมีเครื่องมือเขียนโค้ดด้วย AI ที่ดีกว่านี้
    • ถ้าบอกว่า "ใช้ chat-gpt" ก็จะโดนกลบทันที แต่ถ้าไม่พูดอะไรแล้วแกล้งทำเป็นรู้จริงกลับได้รับคำชม ตอนนี้ทุกคนกำลังมุ่งไปในทิศทางของการซ่อนการใช้ AI กันอยู่แล้ว
    • คิดว่าการมองสิ่งนี้เป็นปัญหาเองก็ไม่มีความหมายมากนัก
    • จุดประสงค์ไม่ใช่ "ห้ามใช้ AI" แต่คือถ้าใช้แล้วก็ให้บอกอย่างตรงไปตรงมาใน PR
  • สงสัยว่าทำไมถึงต้องบังคับให้เปิดเผยแบบละเอียด เช่น "ใช้ ChatGPT ช่วยทำความเข้าใจ codebase แต่ลงมือเขียนโค้ดเองจริง ๆ"
    • ถ้ามีคำอธิบายแบบนี้ ผู้รีวิวก็จะรู้ว่าควรจับตาเรื่องความเข้าใจ codebase เป็นพิเศษ เพราะจุดนั้นอาจเป็นแหล่งของความเข้าใจผิดหรือความคลาดเคลื่อนในการรีวิว
    • ฉันไม่ใช่นักพัฒนา แต่ AI assistant แบบนี้ช่วยลดเวลาในการสำรวจโค้ดได้อย่างชัดเจน สำหรับฉัน AI ช่วยได้มากจริง ๆ
  • คิดว่ารูปแบบที่แนบทุก prompt ที่ใช้สร้าง PR มาด้วยเป็นแนวทางที่ดี LLM อาจไม่ใช่เครื่องมือที่ให้ผลลัพธ์แบบกำหนดตายตัว แต่คุณค่าของมันอยู่ที่การทิ้งบริบทไว้ว่าได้ผลลัพธ์นี้มาจากขั้นตอนหรือ prompt อะไรบ้าง
    • ในทางปฏิบัติมันไม่ค่อยใช้ได้จริง เพราะการสร้าง PR ด้วย AI หนึ่งอันมักปนกันทั้ง 10~20 prompt, การทดสอบ, การปรับบริบทด้วยมือ และการเขียนโค้ดด้วยมือหลายขั้นตอน เลยคิดว่าบางทีอัดหน้าจอไว้ยังจะดีกว่า
    • ฉันใช้ปลั๊กอิน vscode (specsytory) คู่กับ cursor เพื่อบันทึกล็อกการโต้ตอบกับ LLM ทั้งหมดเป็นไฟล์ md แล้วส่งไปพร้อม Pull Request เพื่อใช้อ้างอิงตอนรีวิวโค้ด
  • ในโปรเจกต์ส่วนตัว ฉันตั้งกฎให้ต้องเปิดเผยแม้กระทั่งการใช้ autocomplete ของ editor
    • วิธีสื่อเจตนาน่าสนใจ แต่ AI ตอนนี้แตกต่างจาก autocomplete แบบเดิมโดยสิ้นเชิง จะใช้มันแบบ autocomplete ก็ได้ แต่สิ่งที่ AI ทำได้หลากหลายและลึกกว่านั้นมาก การมอง AI เป็นแค่การเติมโค้ดอัตโนมัติเป็นเพียงมุมมองส่วนตัวเท่านั้น หลายคนไม่ได้ใช้มันแบบนั้น
    • นโยบายนี้ยกเว้น tab autocomplete ไว้อย่างชัดเจนแล้ว
    • autocomplete ส่วนใหญ่เป็นเพียงเครื่องมือด้านไวยากรณ์ แต่ AI พยายามชี้นำไปถึงความหมายและโครงสร้างของโค้ดด้วย