GitHub Code Quality ขึ้น GA — รวม CodeQL กับ AI ตรวจ maintainability/reliability ใน PR พร้อม quality gate และ code coverage

วันที่ 20 กรกฎาคม 2026 GitHub ประกาศให้ GitHub Code Quality ขึ้นสถานะ generally available แล้ว หลังอยู่ในช่วง public preview — เปิดใช้บน GitHub Enterprise Cloud และ GitHub Team (ยังไม่รวม Enterprise Server ในรอบเปิดตัว)

หัวใจของผลิตภัณฑ์คือการ จับคู่สองแนวทางที่ต่างขั้ว: การวิเคราะห์แบบ deterministic ของ CodeQL ที่ให้ผลแน่นอนทำซ้ำได้ กับ AI ที่ตรวจจับปัญหาเชิง maintainability และ reliability ซึ่งเขียนเป็นกฎตายตัวได้ยาก แล้วเอาผลทั้งสองมาแสดงตรงใน pull request ก่อน merge

สิ่งที่ได้จริงใน GA

ประกาศระบุความสามารถชุดใหญ่ที่พร้อมใช้:

• Dashboard ระดับองค์กร แสดงคะแนน maintainability และ reliability ข้าม repository ทั้งหมด — เห็นภาพรวมว่าหนี้ทางเทคนิคกองอยู่ที่ไหน
• Code coverage บน PR อ่านจากรายงานทดสอบรูปแบบ Cobertura XML แล้วแสดงผลตรงในหน้า pull request
• Quality gate ผ่าน GitHub rulesets ตั้ง threshold ของ coverage และโหมดประเมินได้ — บล็อกการ merge เมื่อไม่ผ่านเกณฑ์
• Management API สำหรับเปิดใช้งานราย repository และดึงรายการ findings ไปต่อ pipeline
• Copilot Autofix เสนอวิธีแก้ที่ AI ร่างให้ ทบทวนได้ก่อน merge

ตัวเลขที่ GitHub ยกมาอ้างจากทีมวิศวกรรมของตัวเอง: ทีมภายใน GitHub แก้ findings ได้ 67.3% ก่อน merge PR — เป็นการวางตำแหน่งเครื่องมือให้เป็นด่านตรวจ “ก่อน” โค้ดเข้า main ไม่ใช่รายงานย้อนหลัง

ราคาและการคิดเงิน

โครงสร้างราคาชัด: 10 ดอลลาร์สหรัฐต่อ active committer ต่อเดือน (นับครั้งเดียวต่อองค์กร ไม่นับบัญชี bot) บวก usage-based billing สำหรับฟีเจอร์ฝั่ง AI โดย ไม่ต้องมี Copilot subscription แยก ส่วนการรัน CodeQL analysis บน GitHub Actions ก็คิด compute ตามจริง การเก็บเงินเริ่มวันที่ 20 กรกฎาคม 2026

จุดที่ทีมต้องคำนวณคือ “active committer” — ในองค์กรที่มีคน push โค้ดหลายร้อยคน ตัวเลขนี้ขยายได้เร็ว และ usage-based ฝั่ง AI เป็นตัวแปรที่ต้องเฝ้าดูแยกจากค่า seat คงที่

มุมมอง AI Curator

GitHub Code Quality คือสัญญาณของการที่ GitHub ขยับจาก “การหาบั๊กด้านความปลอดภัย” (ซึ่ง CodeQL กับ code scanning ทำมานาน) ไปสู่ การวัดสุขภาพของโค้ดเบสในเชิงคุณภาพ — maintainability และ reliability เป็นมิติที่วัดยากกว่า security เพราะไม่มีคำจำกัดความตายตัว และนี่คือจุดที่การเอา AI เข้ามาเสริม deterministic analysis มีเหตุผล: บางปัญหาบอกได้ด้วยกฎ (เช่น null dereference) แต่ “โค้ดนี้อ่านยากและจะพังตอนแก้ครั้งหน้า” ต้องใช้การประเมินที่ยืดหยุ่นกว่า

แต่นี่ก็เป็นดาบสองคม เพราะ คะแนน maintainability ที่ AI ให้ ไม่ใช่ความจริงเชิงภววิสัย ต่างจาก CodeQL ที่ถ้าเจอ path จริงก็คือเจอจริง คะแนนเชิงคุณภาพจาก AI มีทั้ง false positive และอคติของโมเดล องค์กรที่เอาคะแนนนี้ไปตั้งเป็น quality gate แข็ง ๆ (บล็อก merge อัตโนมัติ) อาจได้ทีมที่เรียนรู้วิธี “เอาใจ” ตัวตรวจแทนที่จะเขียนโค้ดดีขึ้นจริง — เป็นกับดัก Goodhart เวอร์ชันเดียวกับที่เคยเกิดกับ code coverage percentage มาแล้ว ตัวเลข 67.3% ที่ GitHub อ้างก็ต้องอ่านด้วยความระวัง เพราะมันคือ “สัดส่วน findings ที่ถูกแก้” ไม่ใช่ “สัดส่วนบั๊กจริงที่ถูกจับ”

สำหรับทีมไทย ข้อเสนอที่ตรงประเด็นคือ: เปิดใช้ในโหมด รายงานก่อน แล้วค่อยตั้ง gate อย่าเพิ่งบล็อก merge ด้วยคะแนน AI ตั้งแต่วันแรก ใช้ช่วงแรกดูว่า findings ที่มันยกมาตรงกับสิ่งที่ทีมมองว่าเป็นปัญหาจริงแค่ไหน แล้วค่อยยกระดับเป็น hard gate เฉพาะเกณฑ์ที่พิสูจน์แล้วว่าเชื่อถือได้ (เช่น coverage threshold ที่เป็นตัวเลขตรงไปตรงมา) ส่วนคะแนนเชิงคุณภาพจาก AI เก็บไว้เป็น “สัญญาณเตือน” ให้คนตัดสินใจ ไม่ใช่ผู้ตัดสินเอง — เพราะราคา 10 ดอลลาร์ต่อหัวต่อเดือนคุ้มก็ต่อเมื่อมันช่วยให้ทีมเขียนโค้ดดีขึ้น ไม่ใช่แค่เพิ่มด่านให้ทีมต้องหาทางผ่าน

แหล่งข่าว

• GitHub Code Quality is now generally available — GitHub Changelog
• GitHub Changelog
• About GitHub Code Quality — GitHub Docs