นอกจากนี้ ผู้ดูแลระบบย่อย (Subsystem maintainers) ยังมีอำนาจในการกำหนดกฎที่เข้มงวดยิ่งขึ้น ในเดือนสิงหาคม 2026 นาย Johannes Berg ผู้ดูแลระบบเครือข่ายไร้สายของเคอร์เนล (802.11, mac80211, WWAN, rfkill) ได้ประกาศท่าทีที่แข็งกร้าวเป็นพิเศษต่อแพตช์ที่สร้างโดย AI/LLM :

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

นโยบายนี้เกิดขึ้นหลังจากที่นาย Greg Kroah-Hartman ประกาศกฎว่า drivers/staging/ subsystem จะปฏิเสธแพตช์ที่สร้างโดย LLM ทั้งหมด ยกเว้นการแก้ไขด้านความปลอดภัยที่แท้จริง

เหตุผลเบื้องหลังแนวทางของ Linux Kernel

ชุมชนเคอร์เนลระบุปัญหาหลักสามประการที่นำไปสู่นโยบายนี้:

1. วิกฤตแบนด์วิธในการตรวจสอบ: ผู้ดูแลระบบถูกท่วมท้นด้วยแพตช์ที่สร้างโดย AI จำนวนมาก ซึ่งหลายชิ้นดูดีภายนอกแต่ผิดพลาดทางความหมายหรือเป็นอันตราย
2. การเสื่อมถอยของสัญญาณ: แพตช์ที่ดูดีไม่สามารถบ่งชี้ถึงความพยายาม ความเข้าใจ หรือความสนใจในระยะยาวของผู้มีส่วนร่วมได้อีกต่อไป
3. ความรับผิดชอบ: ชุมชนสรุปว่าความรับผิดชอบของมนุษย์นั้นไม่สามารถต่อรองได้ เครื่องจักรไม่สามารถรับรองแหล่งที่มาตามกฎหมายหรือรับผิดชอบต่อบั๊กได้

Rust Project: นโยบาย LLM ของห้าทีม (5 สิงหาคม 2026)

ในวันที่ 5 สิงหาคม 2026 ห้าทีมของ Rust ได้นำนโยบาย LLM อย่างเป็นทางการมาใช้กับ rust-lang/rust monorepo นโยบายนี้ ไม่ใช่ ท่าทีอย่างเป็นทางการของโปรเจกต์ทั้งหมด และใช้เฉพาะกับ repository หลักและทีมที่นำไปใช้เท่านั้น

สิ่งที่อนุญาต (พร้อมการเปิดเผย)

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

สิ่งที่ห้าม

• การส่งเอกสารที่สร้างโดย LLM รวมถึง doc comments และ safety comments
• การโพสต์คอมเมนต์ GitHub, เนื้อหาของ Issue, คำอธิบาย Pull Request, ข้อวินิจฉัยของคอมไพเลอร์ หรือคอมเมนต์โค้ดต้นฉบับที่มีนัยสำคัญที่สร้างโดย LLM
• การเผยแพร่โค้ดที่เขียนโดย LLM เว้นแต่จะได้รับความยินยอมจากผู้ตรวจสอบก่อน และการใช้ LLM นั้นถูกเปิดเผยอย่างชัดเจน
• การส่งเนื้อหาที่สร้างโดย AI โดยไม่มีความเข้าใจหรือตรวจสอบ

สรุปนโยบายได้คือ: "การใช้ LLM เพื่อตอบคำถาม วิเคราะห์ กลั่นกรอง ตรวจสอบ แนะนำ ทบทวน เป็นเรื่องที่ดี แต่ไม่ใช่เพื่อการสร้าง"

เหตุผลที่ Rust เลือกแนวทางนี้

นาย Jynn Nelson ผู้เขียนนโยบาย ได้ระบุปัญหาหลักสามประการในบล็อกประกาศอย่างเป็นทางการ :

1. ผลิตภัณฑ์ทางเทคนิคที่ดูดีไม่บ่งบอกถึงความพยายามและความเข้าใจอีกต่อไป: LLM สามารถสร้างแพตช์ที่ดูสะอาดตาได้ แต่ผู้ส่งอาจไม่เข้าใจมัน ซึ่งทำลายสัญญาณทางสังคมที่ว่า PR ที่ดีนั้นมาจากการลงทุนของมนุษย์อย่างแท้จริง
2. แบนด์วิธในการตรวจสอบมีไม่พออยู่แล้ว: มี PR ที่เปิดค้างอยู่ถึง 1,281 รายการใน rust-lang/rust การทำให้เขียนโค้ดง่ายขึ้นโดยไม่เพิ่มขีดความสามารถของผู้ตรวจสอบจะเป็นการซ้ำเติมคอขวดที่มีอยู่แล้ว
3. การคัดลอกและวางโดยไร้กลไกเป็นการเสียเวลาทุกคน: ผู้มีส่วนร่วมที่นำคอมเมนต์ตรวจสอบไปวางใน LLM แล้วนำคำตอบของ LLM กลับมาวางบน GitHub จะบั่นทอนความไว้วางใจและข้ามกระบวนการไตร่ตรองของมนุษย์

นโยบายนี้ยังมีแรงจูงใจจากความต้องการที่จะเปลี่ยนจากการควบคุมแบบไม่เป็นทางการและไม่สอดคล้องกัน ไปเป็นกฎที่ชัดเจนและเป็นทางการที่ผู้ตรวจสอบสามารถอ้างถึงและผู้มีส่วนร่วมใหม่สามารถค้นหาได้

ผลกระทบในวงกว้างต่อการกำกับดูแลโอเพนซอร์ส

นโยบายทั้งสองเผยให้เห็นรูปแบบร่วมกันและชุดความท้าทายในการกำกับดูแลที่เหมือนกัน:

สัญญาณจากเหตุการณ์นี้

• "วิกฤตการตรวจสอบ" คือความตึงเครียดหลัก: ทั้งสองโปรเจกต์ตระหนักดีว่า LLM เพิ่มปริมาณการมีส่วนร่วมอย่างมากโดยไม่เพิ่มจำนวนผู้ตรวจสอบที่มีคุณภาพ นี่คือความเครียดด้านการกำกับดูแลที่ใหญ่ที่สุด
• การพังทลายของสัญญาณเป็นเรื่องจริง: ทั้งสองชุมชนชี้ให้เห็นว่า PR ที่ดูดีเคยเป็นสัญญาณของความพยายามและความเข้าใจ แต่ LLM ได้ทำลายสัญญาณนั้น
• การทำให้เป็นทางการกำลังเข้ามาแทนที่การควบคุมแบบเฉพาะกิจ: ทั้งสองโปรเจกต์ย้ายจากกฎที่ไม่เป็นทางการไปสู่นโยบายที่ประมวลผลแล้ว เนื่องจากการบังคับใช้ที่ไม่สอดคล้องกันทำให้ผู้มีส่วนร่วมสับสนและทำให้ผู้ดูแลระบบเหนื่อยล้า
• อิสระของระบบย่อยมีความสำคัญ: แนวทางของ Linux Kernel อนุญาตให้ผู้ดูแลระบบแต่ละคนกำหนดกฎที่เข้มงวดกว่า เช่นที่ Johannes Berg ทำสำหรับ wireless ส่วนแนวทางของ Rust คือการนำไปใช้เป็นทีมต่อทีม
• ไม่มีฉันทามติเกี่ยวกับ AI เอง: นโยบายของ Rust ระบุอย่างชัดเจนว่าจะไม่มีวันมีฉันทามติทั่วทั้งโปรเจกต์เกี่ยวกับ AI ดังนั้นนโยบายจึงมุ่งเน้นไปที่กลไกการมีส่วนร่วมอย่างแคบ ๆ แทนที่จะตัดสินเชิงศีลธรรมเกี่ยวกับ LLM

นอกจากนี้ ผู้ดูแลระบบย่อย (Subsystem maintainers) ยังมีอำนาจในการกำหนดกฎที่เข้มงวดยิ่งขึ้น ในเดือนสิงหาคม 2026 นาย Johannes Berg ผู้ดูแลระบบเครือข่ายไร้สายของเคอร์เนล (802.11, mac80211, WWAN, rfkill) ได้ประกาศท่าทีที่แข็งกร้าวเป็นพิเศษต่อแพตช์ที่สร้างโดย AI/LLM :

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

นโยบายนี้เกิดขึ้นหลังจากที่นาย Greg Kroah-Hartman ประกาศกฎว่า drivers/staging/ subsystem จะปฏิเสธแพตช์ที่สร้างโดย LLM ทั้งหมด ยกเว้นการแก้ไขด้านความปลอดภัยที่แท้จริง

เหตุผลเบื้องหลังแนวทางของ Linux Kernel

ชุมชนเคอร์เนลระบุปัญหาหลักสามประการที่นำไปสู่นโยบายนี้:

1. วิกฤตแบนด์วิธในการตรวจสอบ: ผู้ดูแลระบบถูกท่วมท้นด้วยแพตช์ที่สร้างโดย AI จำนวนมาก ซึ่งหลายชิ้นดูดีภายนอกแต่ผิดพลาดทางความหมายหรือเป็นอันตราย
2. การเสื่อมถอยของสัญญาณ: แพตช์ที่ดูดีไม่สามารถบ่งชี้ถึงความพยายาม ความเข้าใจ หรือความสนใจในระยะยาวของผู้มีส่วนร่วมได้อีกต่อไป
3. ความรับผิดชอบ: ชุมชนสรุปว่าความรับผิดชอบของมนุษย์นั้นไม่สามารถต่อรองได้ เครื่องจักรไม่สามารถรับรองแหล่งที่มาตามกฎหมายหรือรับผิดชอบต่อบั๊กได้

Rust Project: นโยบาย LLM ของห้าทีม (5 สิงหาคม 2026)

ในวันที่ 5 สิงหาคม 2026 ห้าทีมของ Rust ได้นำนโยบาย LLM อย่างเป็นทางการมาใช้กับ rust-lang/rust monorepo นโยบายนี้ ไม่ใช่ ท่าทีอย่างเป็นทางการของโปรเจกต์ทั้งหมด และใช้เฉพาะกับ repository หลักและทีมที่นำไปใช้เท่านั้น

สิ่งที่อนุญาต (พร้อมการเปิดเผย)

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

สิ่งที่ห้าม

• การส่งเอกสารที่สร้างโดย LLM รวมถึง doc comments และ safety comments
• การโพสต์คอมเมนต์ GitHub, เนื้อหาของ Issue, คำอธิบาย Pull Request, ข้อวินิจฉัยของคอมไพเลอร์ หรือคอมเมนต์โค้ดต้นฉบับที่มีนัยสำคัญที่สร้างโดย LLM
• การเผยแพร่โค้ดที่เขียนโดย LLM เว้นแต่จะได้รับความยินยอมจากผู้ตรวจสอบก่อน และการใช้ LLM นั้นถูกเปิดเผยอย่างชัดเจน
• การส่งเนื้อหาที่สร้างโดย AI โดยไม่มีความเข้าใจหรือตรวจสอบ

สรุปนโยบายได้คือ: "การใช้ LLM เพื่อตอบคำถาม วิเคราะห์ กลั่นกรอง ตรวจสอบ แนะนำ ทบทวน เป็นเรื่องที่ดี แต่ไม่ใช่เพื่อการสร้าง"

เหตุผลที่ Rust เลือกแนวทางนี้

นาย Jynn Nelson ผู้เขียนนโยบาย ได้ระบุปัญหาหลักสามประการในบล็อกประกาศอย่างเป็นทางการ :

1. ผลิตภัณฑ์ทางเทคนิคที่ดูดีไม่บ่งบอกถึงความพยายามและความเข้าใจอีกต่อไป: LLM สามารถสร้างแพตช์ที่ดูสะอาดตาได้ แต่ผู้ส่งอาจไม่เข้าใจมัน ซึ่งทำลายสัญญาณทางสังคมที่ว่า PR ที่ดีนั้นมาจากการลงทุนของมนุษย์อย่างแท้จริง
2. แบนด์วิธในการตรวจสอบมีไม่พออยู่แล้ว: มี PR ที่เปิดค้างอยู่ถึง 1,281 รายการใน rust-lang/rust การทำให้เขียนโค้ดง่ายขึ้นโดยไม่เพิ่มขีดความสามารถของผู้ตรวจสอบจะเป็นการซ้ำเติมคอขวดที่มีอยู่แล้ว
3. การคัดลอกและวางโดยไร้กลไกเป็นการเสียเวลาทุกคน: ผู้มีส่วนร่วมที่นำคอมเมนต์ตรวจสอบไปวางใน LLM แล้วนำคำตอบของ LLM กลับมาวางบน GitHub จะบั่นทอนความไว้วางใจและข้ามกระบวนการไตร่ตรองของมนุษย์

นโยบายนี้ยังมีแรงจูงใจจากความต้องการที่จะเปลี่ยนจากการควบคุมแบบไม่เป็นทางการและไม่สอดคล้องกัน ไปเป็นกฎที่ชัดเจนและเป็นทางการที่ผู้ตรวจสอบสามารถอ้างถึงและผู้มีส่วนร่วมใหม่สามารถค้นหาได้

ผลกระทบในวงกว้างต่อการกำกับดูแลโอเพนซอร์ส

นโยบายทั้งสองเผยให้เห็นรูปแบบร่วมกันและชุดความท้าทายในการกำกับดูแลที่เหมือนกัน:

สัญญาณจากเหตุการณ์นี้

• "วิกฤตการตรวจสอบ" คือความตึงเครียดหลัก: ทั้งสองโปรเจกต์ตระหนักดีว่า LLM เพิ่มปริมาณการมีส่วนร่วมอย่างมากโดยไม่เพิ่มจำนวนผู้ตรวจสอบที่มีคุณภาพ นี่คือความเครียดด้านการกำกับดูแลที่ใหญ่ที่สุด
• การพังทลายของสัญญาณเป็นเรื่องจริง: ทั้งสองชุมชนชี้ให้เห็นว่า PR ที่ดูดีเคยเป็นสัญญาณของความพยายามและความเข้าใจ แต่ LLM ได้ทำลายสัญญาณนั้น
• การทำให้เป็นทางการกำลังเข้ามาแทนที่การควบคุมแบบเฉพาะกิจ: ทั้งสองโปรเจกต์ย้ายจากกฎที่ไม่เป็นทางการไปสู่นโยบายที่ประมวลผลแล้ว เนื่องจากการบังคับใช้ที่ไม่สอดคล้องกันทำให้ผู้มีส่วนร่วมสับสนและทำให้ผู้ดูแลระบบเหนื่อยล้า
• อิสระของระบบย่อยมีความสำคัญ: แนวทางของ Linux Kernel อนุญาตให้ผู้ดูแลระบบแต่ละคนกำหนดกฎที่เข้มงวดกว่า เช่นที่ Johannes Berg ทำสำหรับ wireless ส่วนแนวทางของ Rust คือการนำไปใช้เป็นทีมต่อทีม
• ไม่มีฉันทามติเกี่ยวกับ AI เอง: นโยบายของ Rust ระบุอย่างชัดเจนว่าจะไม่มีวันมีฉันทามติทั่วทั้งโปรเจกต์เกี่ยวกับ AI ดังนั้นนโยบายจึงมุ่งเน้นไปที่กลไกการมีส่วนร่วมอย่างแคบ ๆ แทนที่จะตัดสินเชิงศีลธรรมเกี่ยวกับ LLM