แพตช์ Emacs ถูกปฏิเสธเพราะเปิดเผยว่าใช้ vibecoding

 (xlii.space)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แพตช์ขนาดเล็กที่ทำขึ้นเพื่อ ปรับปรุงประสิทธิภาพของ Emacs บน macOS ถูกส่งไปยัง emacs-devel แต่ไม่ได้รับการยอมรับเนื่องจากนโยบายของ GNU ที่ไม่รับงานที่มี LLM ช่วย
  • ผู้พัฒนาระบุอย่างเปิดเผยว่า GLM 5.2 เป็นผู้ค้นหาปัญหาและทำร่างแรก แต่ตนเองเป็นผู้รับผิดชอบด้านความถูกต้อง การวิเคราะห์ผลกระทบ การแก้ไข การทดสอบด้วยมือ และ ความรับผิดชอบส่วนบุคคล
  • แพตช์ที่ถูกปฏิเสธมีขอบเขตแคบ เป็นแพตช์ขนาดเพียง 92 บรรทัด และเขาวิจารณ์ว่านโยบายนี้ทำให้การเปิดเผยอย่างซื่อตรงเสียเปรียบ ทั้งที่อาจปกปิดการใช้ LLM ได้
  • ความกังวลของฝั่ง GNU ใกล้เคียงกับเรื่องความเปิดกว้างและความเป็นไปได้ทางกฎหมายของผลลัพธ์จาก LLM มากกว่า แต่เขาไม่เห็นด้วย โดยอ้างถึงโมเดล open-weight และกรณีการใช้งานจริงในอุตสาหกรรม
  • เขากล่าวว่าจะไม่ทำงานเกี่ยวกับ Emacs อีกต่อไป และเปิดเผยเฉพาะบางส่วนจากแพตช์ปรับปรุงประสิทธิภาพราว 40 ชิ้นที่มีอยู่ในฮาร์ดไดรฟ์ หลังจากตรวจสอบล่าสุดแล้ว

งานปรับปรุงประสิทธิภาพ Emacs บน macOS

  • Przemysław Alexander Kamiński ใช้เวลาหลายเดือนในการปรับปรุง ประสิทธิภาพของ Emacs บน macOS พร้อมทั้งใช้เวลากับการเชื่อมต่อเครื่องมือวัดและเขียนเบนช์มาร์ก
  • เขาให้ LLM หลายตัวดูโค้ดเบสของ Emacs แล้วให้ค้นหาปัญหาเฉพาะ แต่โดยรวมแล้วผลลัพธ์ไม่ค่อยดีนัก
    • เมื่อตรวจดูแพตช์จะพบว่าหลายครั้งผลกระทบมีน้อย หรือเข้าใจปัญหาผิด
  • ในตอนนั้น เขาประเมินคอขวดด้านประสิทธิภาพไว้ดังนี้
    • ปัญหาหลักบน macOS คือ ปัญหาการเรนเดอร์ และ memory thrashing จากการจองและคืนหน่วยความจำอย่างรวดเร็ว
    • วิธีทำงานของระบบ malloc บน macOS ทำให้เกิดการพองตัวของหน่วยความจำเสมือนและสูญเสีย cache locality เนื่องจากไม่มี memory compression
    • ในแกนหลักของ Emacs เองก็ยังมีปัญหาด้านประสิทธิภาพเหลืออยู่
    • การประมวลผล regexp ถูกใช้ในหลายจุด ดังนั้นหากปรับปรุงได้ก็อาจส่งผลต่อประสิทธิภาพโดยรวม

แพตช์ที่ค้นพบด้วย GLM 5.2 และกระบวนการส่ง

  • เขาได้ Max plan ของ z.ai จากเพื่อน จึงสามารถใช้ GLM 5.2 ได้ และประเมินว่าโมเดลนี้ค่อนข้างเก่งเรื่องการปรับโค้ดให้มีประสิทธิภาพ
  • โดยอาศัยความรู้ที่สะสมไว้ก่อนแล้ว เขาจึงตั้งคำถามเฉพาะเกี่ยวกับ Emacs และให้ GLM 5.2 สำรวจและวิเคราะห์ปัญหา
  • หลังจากประมาณ 3 ชั่วโมง เขาได้รับรายงานหลายชิ้น จากนั้นจึงตรวจสอบข้อเสนอและโค้ด ทดสอบผลกระทบของแต่ละรายการ และรันเบนช์มาร์ก
  • เนื่องจากการจัดระเบียบเพื่อส่งแพตช์ต้องใช้เวลา เขาจึงเลือกเพียงรายการที่มีแววดีที่สุดหนึ่งรายการ และส่งไปยังเมลลิงลิสต์ emacs-devel สองวันก่อนเขียนบทความนี้
  • วันถัดมา เขาจึงทราบว่า GNU มีนโยบายไม่รับงานที่มี LLM ช่วย ทำให้แพตช์นี้ไม่ได้รับการยอมรับ

ขอบเขตการใช้ LLM ที่เปิดเผยในอีเมลส่งแพตช์

  • ตอนส่งแพตช์ไปยังเมลลิงลิสต์ เขาได้ระบุทั้งการใช้ LLM และขอบเขตการตรวจทานของตนเองไว้ด้วย
    • เขาระบุว่าการค้นพบปัญหาและการร่างแพตช์เบื้องต้นทำโดย GLM 5.2 และอธิบายว่า GLM 5.2 เป็นโมเดล open-weight จากจีน
    • เขาวิเคราะห์ความถูกต้องและผลกระทบของรายงานปัญหาด้วยตนเอง
    • เขาตรวจทานและแก้ไขแพตช์
    • เขาทดสอบแพตช์ด้วยมือ
    • เขาประกาศสถานะความเป็นผู้ประพันธ์ของผลงานเพื่อวัตถุประสงค์ทางกฎหมาย และระบุว่าพร้อมจะยืนยันว่าการมีส่วนร่วมของตนมากกว่า LLM
    • เขาประกาศว่าจะรับผิดชอบต่อผลงานที่ส่งทั้งหมดแต่เพียงผู้เดียว
  • ผลงานที่ส่งมีขอบเขตการเปลี่ยนแปลงแคบมากและขนาดเล็ก
    • แพตช์ ที่เปิดเผยมีเพียง 92 บรรทัด และมีคำอธิบายเหตุผลของการมีอยู่ในคอมเมนต์
  • เขาไม่คิดว่าแพตช์นี้ควรถูกจัดเป็น “slop” แต่ก็เสริมว่าแต่ละคนจะตัดสินเองก็ได้

ข้อโต้แย้งต่อนโยบายของ GNU

  • เขาระบุว่าเคารพนโยบายของ GNU แต่ไม่เห็นด้วย และมองว่านโยบายนี้มีเหตุผลรองรับไม่เพียงพอ
  • เขาสามารถปกปิดการใช้ LLM ได้ แต่เลือกที่จะเปิดเผยอย่างชัดเจน และเห็นว่าผลที่ตามมาคือการส่งแพตช์เสียเปรียบ
    • ดังนั้นเขาจึงวิจารณ์ว่านโยบายนี้ลงโทษ การเปิดเผยอย่างซื่อตรง มากกว่าการใช้ LLM เอง
    • เขามองว่าตนไม่เชื่อถือ LLM เลย ดังนั้นงานที่มี LLM ช่วยจึงไม่ควรได้รับการตรวจน้อยลง แต่ควรถูกตรวจมากขึ้นและจากหลายมุมมากขึ้น
  • เขากล่าวว่าไม่ทราบบริบททั้งหมดของนโยบาย เพราะมีการพูดคุยกันในลิสต์ภายในของ GNU และสรุปว่าจากบทสนทนาในอดีต ข้อสงสัยหลักใกล้เคียงกับการที่ผลงานจาก LLM เปิดพอหรือไม่ และสามารถใช้งานได้อย่างถูกกฎหมายหรือไม่
  • เขาไม่เห็นด้วยกับตรรกะที่ตั้งคำถามต่อความเปิดกว้างของโมเดล open-weight
    • ตัวอย่างเช่น เขามองว่าการแบ่งว่าใช้ Qwen 3.6 ในเครื่องตัวเองได้ แต่ใช้ผ่าน OpenRouter ไม่ได้ เป็นการแยกแยะที่ไม่สมเหตุสมผล
    • เขากล่าวว่า GLM 5.2 เป็น โมเดล open-weight และหากมี RAM 256GB กับ VRAM 24GB ก็สามารถรันในเครื่องเพื่อหลีกเลี่ยงข้อถกเถียงว่า “SaaS เป็นระบบปิด” ได้
    • เขาย้อนถามว่าในอินเทอร์เน็ตก็มีคอนเทนต์ที่ไม่เสรีมากมาย ดังนั้นหากใช้ตรรกะเดียวกัน จะต้องห้ามการเข้าถึงอินเทอร์เน็ตตอนสร้างผลงานส่งด้วยหรือไม่
  • เขาไม่เห็นด้วยกับความกังวลทางกฎหมายเช่นกัน
    • เขากล่าวว่าบริษัทเกมไวต่อ IP และ LLM มากกว่า แต่ก็ยังเห็นการใช้ LLM อยู่, ChatGPT มีผู้ใช้งานจริงต่อเดือน 1 พันล้านคน และมีองค์กรตั้งแต่หลักแสนถึงหลักล้านที่ใช้ผลลัพธ์จาก LLM ทุกวัน
    • เขาเกริ่นว่าไม่ใช่ทนายในสหรัฐฯ แต่เข้าใจว่าประเด็นเรื่องการจดทะเบียนลิขสิทธิ์เกี่ยวข้องกับฝ่ายที่ติดประกาศลิขสิทธิ์มากกว่า
    • เขาไม่เห็นด้วยกับท่าทีที่ GNU ให้ความสำคัญสูงสุดกับทนายของตัวเองและความเห็นของตนเอง

ยุติงาน Emacs และแพตช์ที่เปิดเผย

  • เขากล่าวว่า GNU มีเสรีภาพที่จะตัดสินใจเอง และเขาเองก็มีเสรีภาพที่จะวิจารณ์
  • เขาวิจารณ์ว่าการหารือนโยบายกันภายในโดยไม่โปร่งใสต่อผู้ใช้ เปิดกว้างพอๆ กับที่ Meta ตัดสินทิศทางของ Facebook กันภายในองค์กร
  • ผลลัพธ์คือเขาประกาศว่าจะไม่ทำ งานเกี่ยวกับ Emacs อีกต่อไป
    • เขาบอกว่าไม่ชอบสถานการณ์ที่ทำงานแบบอาสาแล้วกลับถูกบอกว่า “กำลังจับผิดด้านของไม้เท้า”
  • ในฮาร์ดไดรฟ์ของเขามีแพตช์ปรับปรุงประสิทธิภาพประมาณ 40 ชิ้น โดยบางส่วนซ้อนทับกัน และบางส่วนยังพิสูจน์ผลกระทบจริงไม่ได้
  • เขาเปิดเผยเฉพาะบางแพตช์ที่เพิ่งตรวจสอบแล้วว่าทำงานได้และส่งผลอย่างมีนัยสำคัญที่ นี่ และยืนยันว่าแพตช์เหล่านั้นสร้างความแตกต่างได้จริง

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

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

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

  • ดูเหมือนผู้เขียนจะเข้าใจผิดว่าคำว่า open ใน "open weight" หมายถึงอะไร
    การที่มีการเปิดเผยเมทริกซ์ชุดสุดท้ายและสามารถปรับจูนต่อได้ในระดับหนึ่ง ไม่ได้แปลว่าข้อมูลฝึกที่ใช้สร้างสิ่งนั้นเป็นโอเพนซอร์สด้วย OSI seems to agree ก็ดูจะมองไปในทิศทางเดียวกัน ซึ่งถ้าเป็นเช่นนั้น ปัญหาเรื่องลิขสิทธิ์ก็ยังไม่ได้รับการแก้ไขเลย
    ผมเข้าใจและเห็นใจคนที่พยายามมีส่วนร่วมด้วยความหวังดีโดยไม่หวังผลตอบแทน แต่ GNU เขียนกฎไว้ชัดเจนแล้ว และถ้าคุณไปที่นั่นพร้อมบอกว่า "ผมฝ่าฝืนแค่นิดหน่อย และนี่คือแพตช์" การถูกปฏิเสธก็ไม่ใช่เรื่องแปลก เหตุผลที่ถูกปฏิเสธไม่ใช่เพราะความซื่อสัตย์ แต่เพราะได้ทำในสิ่งที่ประกาศไว้ชัดเจนว่าไม่ให้ทำ

    • งั้นไดรเวอร์ที่เขียนขึ้นจาก datasheet ที่ติดสัญญาไม่เปิดเผยข้อมูลก็ถือว่าไม่ใช่ซอฟต์แวร์เสรีทั้งหมดด้วยหรือ? แล้วกรณีพนักงานของผู้ผลิตใช้เอกสารภายในกับความรู้เฉพาะทางในการเขียนไดรเวอร์ควรมองอย่างไร?
    • ผมไม่ค่อยเข้าใจว่าทำไมข้อมูลฝึกถึงเกี่ยวข้องนัก ถ้าผลลัพธ์สามารถนำไปใช้ แจกจ่ายต่อ และแก้ไขได้อย่างเสรี ผมก็คิดว่านั่นค่อนข้างใกล้เคียงกับ open แล้ว

  • หวังว่าวันนี้ผู้เขียนจะได้เรียนรู้ว่าคนหลายพันล้านคนก็อาจผิดพร้อมกันได้ Normalization of deviance ไม่ได้ทำให้ความผิดปกติกลายเป็นเรื่องชอบธรรม แต่มันแค่อธิบายว่าความเบี่ยงเบนนั้นแพร่กระจายต่อไปอย่างไร
    หนึ่งในรูปแบบที่พบใน chatbot psychosis คือการมองมนุษย์ที่คัดค้านหรือมีความเห็นต่างว่าเป็นศัตรู narremes ที่แชตบอตเรียนรู้มานั้นมีมุมมองว่าผู้ใช้คือพระเอกของเรื่อง พร้อมกล้องมุมมองข้ามไหล่และเรื่องเล่าส่วนบุคคลที่อ่านง่าย เรื่องเล่าตามความชอบที่แชตบอตผ่านการปรับแต่งแล้วส่งผลโดยตรงต่อผู้ใช้ ด้วยการเสริมความรู้สึกว่าตัวเองเป็นตัวเอก และเมื่อผู้ใช้ถูกไอออไนซ์มากพอ ก็จะไม่สามารถยอมรับแม้แต่จุดยืนที่เป็นกลางได้อีก
    ในกรณีนี้ ผมแนะนำให้อ่าน การสนทนาดั้งเดิม ที่ผู้เขียนไม่ได้ลิงก์หรืออ้างถึง ชุมชน Emacs ปฏิบัติต่อผู้เขียนอย่างสุภาพ เปิดรับ ซักถาม แสดงความสนใจ และมีท่าทีพร้อมยอมรับ แม้ตอนปฏิเสธแพตช์ก็ยังพูดอย่างนุ่มนวลโดยโฟกัสที่นโยบายของ GNU มากกว่าจะตำหนิตัวผู้เขียน

    • การไม่ใส่ลิงก์ไปยังการสนทนาจริงไว้ในบทความ เป็น สัญญาณอันตรายครั้งใหญ่ แบบตรงไปตรงมาเลย ผมแทบไม่อยากเชื่อว่าไม่ทันสังเกต
    • บทความ Wikipedia ของ narremes มีอยู่แค่ย่อหน้าเดียว และยังติดแท็ก [incomprehensible] ไว้ด้วย
      ถึงอย่างนั้น จากบริบทก็ยังพอเข้าใจว่าหมายถึงอะไร และมันก็ดูเป็นแนวคิดที่มีประโยชน์และเข้ากับเรื่องนี้ดี

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

    • พูดตามตรง ถ้าดูจากบรรทัดฐานคดีในตอนนี้ ความเข้าใจ กฎหมายสหรัฐฯ ของผู้เขียนก็ผิดเหมือนกัน[1] ตามแนวคำพิพากษาที่มีอยู่ โค้ดที่ LLM สร้างขึ้นไม่อาจได้รับความคุ้มครองลิขสิทธิ์ได้ ดังนั้นจึงไม่สามารถติดไลเซนส์ได้ และจะกลายเป็นสาธารณสมบัติโดยอัตโนมัติ
      ยิ่งไปกว่านั้น ถ้ามีโค้ดที่ LLM สร้างอยู่ในรีโพซิทอรี แต่ไม่ได้แยกหรือระบุไว้อย่างชัดเจน ก็อาจถูกมองได้ว่าทั้งรีโพซิทอรีไม่สามารถรับความคุ้มครองลิขสิทธิ์หรือการให้ไลเซนส์ได้เลย
      พูดอีกอย่างคือ ถ้าผู้เขียนโกหกจนทำให้โค้ดถูกคอมมิตเข้าไปได้ ก็อาจทำให้ผลบังคับใช้ของไลเซนส์ทั้งโค้ดเบสของ Emacs ตกอยู่ในความเสี่ยง
      ทั้งหมดนี้ยังแยกจากท่าทีหยิ่งผยองที่เกือบเป็นอาการหลงผิดแบบ "ผมไม่ใช่ทนาย แต่พวกทนายผิดอย่างเห็นได้ชัด" เขากำลังอ่านบทกฎหมายที่เกี่ยวข้องเพียงบางส่วน ขณะเดียวกันก็กล่าวหาว่าพวกทนายหยิ่งยโส
      [1] ล่าสุดตามที่ผมคุยเรื่องนี้กับทีมกฎหมายของบริษัทเมื่อราวสองเดือนก่อน

  • ผมไม่แน่ใจว่า "ถ้าโกหกก็คงได้รับการยอมรับ" เป็นข้อโต้แย้งที่มีความหมายหรือไม่

    • จะใช้ตรรกะแบบเดียวกันกับ ไลเซนส์ ก็ได้ ถ้าไปคัดลอกบางอย่างมาจากโค้ดเบสที่เป็นกรรมสิทธิ์แล้วโกหกว่าเขียนเอง แพตช์ก็อาจได้รับการยอมรับ แต่ถ้าพูดความจริงก็จะถูกปฏิเสธ งั้นข้อสรุปคือไลเซนส์ไม่ดีอย่างนั้นหรือ?
    • ใช่ ผมมักได้ยินข้ออ้างกับนโยบาย no-LLM ว่า "งั้นคนก็แค่โกหกกันสิ"
      แต่นั่นไม่ได้พูดอะไรดี ๆ เกี่ยวกับคนเหล่านั้นเลยไม่ใช่หรือ?
      ผมไม่คิดว่าจะมีประโยชน์อะไรในการไปรังควานผู้ดูแลเพราะนโยบายที่เห็นด้วยหรือไม่เห็นด้วยกับ LLM พวกเขากำลังทำงานอยู่ และมีสิทธิ์เลือกว่าจะประเมิน รับ หรือปฏิเสธการมีส่วนร่วมแบบใด
      แน่นอนว่าการบ่นก็พอเข้าใจได้ คนนี้กำลังแสดงจุดยืนของตัวเองผ่านบล็อก และนี่ก็เป็นวิธีที่ใช้ปรับกรอบการถกเถียงกัน เพียงแต่ผมไม่เห็นด้วยกับการ framing ปัญหาตรงนี้ไม่ใช่ "ความซื่อสัตย์" ถ้ามีการประกาศนโยบาย no-LLM ไว้แล้ว ความรับผิดชอบที่เอาเวลาไปใช้ LLM เพื่อพยายามมีส่วนร่วมกับโครงการที่ไม่ต้องการการมีส่วนร่วมแบบนั้น ก็อยู่ที่เจ้าตัวเอง
      มันไม่ต่างจากการเอาอาหารที่มีเนื้อหรือชีสไปให้คนวีแกน แล้วมาบ่นว่าเขาไม่ยอมกินทั้งที่เราบอกส่วนผสมอย่าง "ซื่อสัตย์" ว่า "ถ้าไม่บอกก็คงไม่รู้ว่ามีนม" ฟังดูไม่ดี และ "ถ้าไม่บอกก็คงไม่รู้ว่าผมใช้ LLM" ก็ไม่ต่างกัน
    • เห็นด้วย ผมได้เสนอชื่อใหม่ว่า Vibecoding gets Emacs patch rejected การยอมรับอย่างซื่อสัตย์ว่าใช้ vibe coding ก็คล้ายกับการยอมรับอย่างซื่อสัตย์ว่าละเมิดลิขสิทธิ์ สาเหตุรากของการถูกปฏิเสธไม่ใช่ความซื่อสัตย์
    • ผมคิดว่าการใช้ LLM แล้วเปิดเผยตามตรง เป็นเหตุผลให้แพตช์ถูกปฏิเสธได้ ส่วนการใช้ LLM แล้วโกหก นอกจากเป็นเหตุให้แพตช์ถูกปฏิเสธแล้ว ยังเป็นเหตุให้ถูกแบนจากการพยายามมีส่วนร่วมในอนาคตด้วย

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

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

  • รู้ไหมว่าอาชญากรรมจะผิดกฎหมายก็ต่อเมื่อถูกจับได้เท่านั้น

  • แม้ผมจะไม่ได้เป็นแฟนตัวยงของ GNU เลย แต่เครื่องมือเขียนโค้ด LLMมันอยู่คนละขั้วกับปรัชญา GNU ไม่ใช่หรือ? ให้ความรู้สึกเหมือนพาหมาเข้า cat cafe แล้วโกรธที่โดนไล่ออก

  • ผมคิดว่าการเปลี่ยนชื่อจาก "Honesty gets Emacs patch rejected" เป็น Vibecoding gets Emacs patch rejected นั้นไม่ซื่อสัตย์อย่างมาก
    ต่อให้ผู้เขียนจะได้ความช่วยเหลือจากเครื่องมือ AI แบบที่ผู้เขียนบทความว่าไว้ แต่ถ้าลงเวลาและความเข้าใจในโค้ดขนาดนั้น ก็ชัดเจนว่าไม่ใช่ vibe coding ถ้าโยนคำสั่งว่า "ทำให้ Emacs เร็วขึ้น" ให้ AI แล้วหลับหูหลับตาส่งผลลัพธ์ไปเลย แบบนั้นถึงจะเรียกว่า vibe coding แต่จากที่อ่าน เห็นได้ชัดว่าไม่ใช่กรณีนั้น

    • ชื่อที่ใช้คำว่า "honesty" ก็ไม่ซื่อสัตย์เหมือนกัน แพตช์ถูกปฏิเสธไม่ใช่เพราะความซื่อสัตย์ แต่เพราะฝ่าฝืนนโยบาย
    • ผมเห็นด้วยกับการตีความคำว่า "vibe coding" นะ แต่พอเห็นว่าคนใช้คำนี้ต่างกันมาก ก็ไม่ถึงกับมองว่าไม่ซื่อสัตย์ขนาดนั้น
      ถ้าเป็นผม คงใช้ประมาณว่า "Breaking contribution policy gets Emacs patch rejected" ยังมีความเหน็บแนมอยู่ แต่ก็โต้แย้งได้ยากกว่า

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

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

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