Copilot กด Approve พูลรีเควสต์ได้แล้ว และนับเป็นเสียงอนุมัติตามกฎ required-approvals ของรีโป — เปิด public preview 1 ก.ย.

GitHub ลง changelog เมื่อ 1 กันยายน 2026 หัวข้อ “Copilot code review can now approve pull requests” — จากเดิมที่ Copilot ทำได้แค่คอมเมนต์ ตอนนี้มันกด Approve ได้ และประโยคที่สำคัญที่สุดในประกาศทั้งฉบับคือประโยคนี้: “When enabled, Copilot can submit an approval that counts toward the repository’s required-approvals rule.”

แปลตรง ๆ คือ กฎ “ต้องมีคนอนุมัติอย่างน้อย N คน” ที่หลายทีมใช้เป็นด่านสุดท้ายก่อน merge นั้น ตอนนี้ AI นับเป็นหนึ่งเสียงได้ ฟีเจอร์อยู่ใน public preview บนแพลน Copilot Pro, Pro+, Max, Business และ Enterprise

สองเรื่องที่ถูกปล่อยพร้อมกัน แต่ต้องแยกให้ออก

ประกาศฉบับนี้มีของสองชิ้นที่ชื่อคล้ายกันมากจนอ่านผ่านแล้วสับสน:

1) Approval assessment — มาให้ทุกคน เปิดอัตโนมัติ ทุกรีวิวของ Copilot จะมี “ผลประเมินว่าควรอนุมัติหรือยัง” ปรากฏใน overview comment ตั้งแต่นี้ไป แต่ GitHub เขียนกำกับไว้ชัดว่า “An approval assessment alone does not count toward merge requirements” — มันเป็นแค่ความเห็น ไม่ใช่เสียงโหวต

2) Approval จริง — ปิดเป็นดีฟอลต์ ต้องแอดมินเปิดเอง อันนี้คือตัวที่ส่ง approving review เข้าไปในระบบและนับรวมกับกฎ required approvals

ในหน้าตั้งค่าของรีโป (Settings → Copilot → Code review) หัวข้อ “Auto-approval” ยังแยกสวิตช์ออกเป็นสองตัวอีกชั้น: “Allow Copilot to approve pull requests” (ให้ Copilot กด approve ได้) และ “Allow Copilot approvals to count toward merge requirements” (ให้เสียงนั้นนับ) — คือเปิดให้มันอนุมัติเพื่อดูเป็นสัญญาณ โดยยังไม่ให้มันปลดล็อกปุ่ม merge ก็ทำได้

พฤติกรรมหนึ่งที่ออกแบบมาถูกแล้วคือ การ push commit ใหม่หลัง Copilot อนุมัติ จะทำให้ approval นั้นถูก dismiss เหมือนของรีวิวเวอร์คน แล้วต้องขอรีวิวใหม่ ไม่ใช่ตราประทับที่ติดค้างอยู่กับ PR ตลอดไป

ปุ่มคุมมีสามชั้น และตัวกรองที่คนจะตั้งพลาด

GitHub ให้แอดมินคุมเป็นลำดับชั้น:

ชั้น	ทำอะไรได้
Enterprise	ปิดทั้งองค์กร หรือปล่อยให้แต่ละ org ตัดสินใจเอง
Organization	เปิดทั้ง org / มอบให้แอดมินรีโปตัดสินใจ / เปิดเฉพาะบางรีโป / ปิดทั้ง org
Repository	เปิด-ปิด และ เลือกว่า Copilot อนุมัติไฟล์เส้นทางไหนได้บ้าง

ตัวกรองระดับรีโปคือรายละเอียดที่ควรอ่านช้า ๆ เอกสารเขียนว่าให้ใส่ file glob บรรทัดละหนึ่งอัน และเสียงอนุมัติจะนับ “only on pull requests where every changed file matches one of the globs” — คือ ทุกไฟล์ใน PR ต้องเข้าเงื่อนไข ถ้า PR แตะไฟล์นอกรายการแค่ไฟล์เดียว เสียงของ Copilot ก็ไม่นับ ปล่อยว่างไว้ = นับทุกไฟล์ และเพดานคือ 15 glob

ตรรกะแบบ “ทุกไฟล์ต้องผ่าน” เป็นดีฟอลต์ที่ปลอดภัยกว่าแบบ “ไฟล์ใดไฟล์หนึ่งผ่านก็พอ” แต่ก็แปลว่าคนตั้งค่าต้องคิดกลับด้าน: นี่ไม่ใช่ blocklist ของไฟล์อันตราย แต่เป็น allowlist ของไฟล์ที่ยอมให้ AI ตัดสิน และ 15 บรรทัดก็หมดเร็วกว่าที่คิดในโมโนรีโป

เอกสารกำกับไว้ซ้ำ ๆ ว่า “Copilot approvals are in public preview and subject to change.”

สิ่งที่ประกาศ “ไม่ได้” พูดถึง

อ่านทั้ง changelog และหน้า docs สำหรับตั้งค่า code review จบแล้ว มีสองคำถามที่ทีมจะเจอในวันแรกและ ไม่มีคำตอบอยู่ในเอกสาร:

• Copilot อนุมัติ PR ที่ Copilot cloud agent เขียนเองได้ไหม — เอกสารไม่พูดถึงเคสนี้เลย ทั้งที่มันเป็นเคสที่จะเกิดบ่อยที่สุดในทีมที่ใช้ coding agent ยิงงานอยู่แล้ว
• เสียงของ Copilot ไปเกี่ยวกับกฎ CODEOWNERS อย่างไร — หน้าตั้งค่าพูดถึงแต่ “required-approvals rule” ไม่ได้ระบุว่าถ้ารีโปบังคับ review จาก code owner แล้ว Copilot จะแทนที่ได้หรือไม่

ทั้งสองข้อไม่ใช่การเดา — คือช่องว่างในเอกสารที่ต้องไปทดสอบเองในรีโปทดลองก่อนเปิดใช้จริง

มุมมอง AI Curator

ผมมองว่านี่คือการข้ามเส้นที่ต่างจากทุกฟีเจอร์ AI code review ที่ผ่านมา ก่อนหน้านี้ AI เป็น ผู้ให้ข้อมูล — มันคอมเมนต์ มันเตือน มันเสนอ diff แต่คนยังเป็นผู้ตัดสิน วันนี้มันกลายเป็น ผู้มีสิทธิ์ออกเสียง ในกลไกที่องค์กรออกแบบมาเพื่อการันตีว่า “มีมนุษย์อย่างน้อยหนึ่งคนได้ดูโค้ดนี้แล้ว” ความน่าสนใจคือ GitHub เองก็รู้ตัว จึงแยกสวิตช์เป็นสองตัวและปิดเป็นดีฟอลต์ — การออกแบบแบบนี้เป็นการโยนความรับผิดชอบให้แอดมินอย่างตั้งใจ ไม่ใช่ความบังเอิญ

สำหรับทีมไทย ผมคิดว่าจุดเสี่ยงจริงไม่ได้อยู่ที่ “AI รีวิวเก่งพอไหม” แต่อยู่ที่ เหตุผลที่ทีมจะเปิดมัน ทีมเล็กในไทยจำนวนมากตั้งกฎ required approvals = 1 ไว้เพื่อความเรียบร้อยด้าน compliance หรือเพราะลูกค้า/ผู้ตรวจสอบขอ แล้วในทางปฏิบัติก็ติดคอขวดตรงที่มีคนรีวิวได้จริงคนเดียวหรือสองคน สวิตช์นี้จึงเป็นทางออกที่ น่ากดมาก — เปิดปุ๊บ PR ไหลทันที และตัวเลข “ผ่านการอนุมัติ 100%” ในรายงานก็ยังสวยเหมือนเดิม นั่นแหละคือปัญหา เพราะกฎที่ตั้งไว้เพื่อบังคับให้มีสายตามนุษย์ จะยังดู “ผ่าน” ทั้งที่ไม่มีมนุษย์คนไหนอ่านโค้ดนั้นเลย

ข้อแนะนำเชิงปฏิบัติของผมคือ เปิดเฉพาะสวิตช์แรก อย่าเพิ่งเปิดสวิตช์ที่สอง ปล่อยให้ Copilot กด approve เพื่อสะสมสถิติสักหนึ่งถึงสองเดือน แล้วย้อนดูว่ามี PR กี่ใบที่มันอนุมัติแต่คนกลับพบบั๊กทีหลัง ถ้าจะเปิดให้นับจริง ให้ใช้ glob เป็น allowlist ของสิ่งที่พังแล้วไม่เจ็บ — ไฟล์ i18n, เอกสาร, สแนปช็อตเทสต์, ไฟล์ล็อกของ dependency — และกันเส้นทางที่แตะเงิน สิทธิ์ผู้ใช้ การย้ายข้อมูล และ migration ออกไปตั้งแต่วันแรก ส่วนทีมที่อยู่ใต้ PDPA หรือมาตรฐานของธนาคาร ควรถามฝ่ายกำกับก่อนด้วยว่า “ผู้อนุมัติ” ในเอกสารควบคุมภายในของคุณนิยามว่าต้องเป็นบุคคลหรือไม่ เพราะสวิตช์นี้อาจทำให้หลักฐานการควบคุมที่คุณส่งผู้ตรวจสอบเปลี่ยนความหมายไปเงียบ ๆ

และเชื่อมกับข่าวที่เราเขียนไปเมื่อ 31 ส.ค.: GitHub เพิ่งเปลี่ยนดีฟอลต์ระดับความละเอียดของ code review จาก Lite เป็น Balanced ในวันที่ 28 ก.ย. นี้ด้วย — สองการเปลี่ยนแปลงนี้มาชนกันพอดี คือ AI จะรีวิวลึกขึ้น และ มีสิทธิ์อนุมัติได้ ในเดือนเดียวกัน ถ้าจะเปิด ควรเปิดทีละอย่างและเว้นเวลาให้เห็นผลของแต่ละตัวแยกกัน

แหล่งข่าว

• Copilot code review can now approve pull requests — GitHub Changelog, 1 ก.ย. 2026
• Configuring code review by GitHub Copilot — GitHub Docs (หัวข้อ Auto-approval, file globs)
• GitHub ประกาศเปลี่ยนนโยบาย Copilot สามเรื่องรวด — บล็อกนี้, 31 ส.ค. 2026