FrontierCode Diamond: แพตช์รวมได้ 13.4% จาก 50 งานยาก (มิถุนายน 2026)

ดูเนื้อหาเพิ่มเติมเกี่ยวกับการกำหนดค่าเครื่องมือได้ในเอกสารประกอบของ Ailoot

FrontierCode คืออะไร และทำไมจึงสำคัญ?#

Cognition คือบริษัทเบื้องหลัง Devin (วิศวกร AI อัตโนมัติรายแรก มีนาคม 2024) และ Windsurf (เข้าซื้อกิจการในเดือนกรกฎาคม 2025) บริษัทยังพัฒนาโมเดลตระกูล SWE-1.x ของตนเองด้วย เบนช์มาร์กนี้เผยแพร่ในบล็อกสาธารณะที่ cognition.com/blog/frontier-code

ประเด็นสำคัญไม่ใช่ตัวเลขใหม่ แต่คือ มาตรวัดที่ใช้ประเมินสิ่งต่าง ๆ ในตอนนี้

เบนช์มาร์กมีสามระดับความยาก: Extended (150 งาน ซึ่งเป็นชุดเต็ม), Main (100 งานที่ยากที่สุด รวม Diamond) และ Diamond (50 งานที่ยากสุดขีด) Cognition ตั้งใจปล่อย Diamond ให้ “ยังไม่อิ่มตัวเป็นส่วนใหญ่”—แม้แต่โมเดลที่ดีที่สุดก็แก้ได้ไม่ถึง 15% จุดประสงค์คือให้เบนช์มาร์กมีพื้นที่พัฒนาไปได้อีกหนึ่งปี และป้องกันไม่ให้ถึงจุดอิ่มตัวภายในหนึ่งเดือนอย่างที่เกิดกับ HumanEval

FrontierCode วัดอะไร: “ผู้ดูแลจะรวม PR นี้หรือไม่?”#

เกณฑ์ประเมินทั้งหกด้าน (จากบล็อกทางการของ Cognition):

1. ความถูกต้องเชิงพฤติกรรม — แพตช์แก้ปัญหาตามโจทย์หรือไม่?
2. ความปลอดภัยจากการถดถอย — หลีกเลี่ยงการทำให้โค้ดเดิมเสียหรือไม่?
3. ความเรียบร้อยเชิงกลไก — ผ่านการตรวจ build, lint และสไตล์หรือไม่?
4. ความถูกต้องของการทดสอบ — การทดสอบที่เอเจนต์เขียนถูกต้องหรือไม่ (การทดสอบที่ผ่านกับโค้ดใด ๆ ไม่นับ)?
5. ขอบเขต — แพตช์หลีกเลี่ยงการแตะไฟล์ที่ไม่ได้ร้องขอหรือไม่?
6. คุณภาพโค้ด — โค้ดทำตามธรรมเนียมของโปรเจกต์และอ่านเข้าใจได้หรือไม่?

แพตช์จะนับว่าพร้อมรวมได้ก็ต่อเมื่อผ่าน ครบทั้งหกด้าน หากตกแม้แต่ด้านเดียว ก็จะไม่ถูกรวม

นี่คือการเปลี่ยนมุมมองหลัก “ความถูกต้องกลายเป็นเกณฑ์พื้นฐานไปแล้ว” ตามที่ Cognition กล่าว ก่อนหน้านี้เบนช์มาร์กถามว่า “โค้ดผ่านการทดสอบหรือไม่?” ตอนนี้ถามว่า “หัวหน้าทีมเทคนิคจริง ๆ จะรับโค้ดนี้เข้ามาในโปรเจกต์หรือไม่?”

Cognition นำเสนอเทคนิคการให้คะแนนแบบใหม่สามอย่าง:

• Reverse-Classical: การทดสอบที่เอเจนต์เขียนต้องไม่ผ่านกับโค้ดเวอร์ชันที่เสีย มิฉะนั้นการทดสอบนั้นก็เป็นของปลอม
• Code Scope: ตัวตรวจสอบอัตโนมัติจะตรวจว่าแพตช์อยู่ภายในไฟล์และจำนวนบรรทัดที่ตกลงกันไว้สำหรับงานหรือไม่
• Adaptive Classical Grading: เครื่องมือ LLM ชื่อ “mutagent” ปรับการทดสอบที่เข้มงวดให้เข้ากับรูปแบบโซลูชันที่ถูกต้อง

ทำไมเบนช์มาร์กแบบเดิมถึงใช้ไม่ได้อีกต่อไป?#

เอเจนต์ AI ทำคะแนน HumanEval ได้ดีมากไปแล้วตั้งแต่ปี 2024 SWE-bench Verified ก็แทบไม่ต่างกัน: ในเดือนสิงหาคม 2025 OpenAI ยอมรับต่อสาธารณะว่ามีปัญหาข้อมูลปนเปื้อน (โมเดล “เคยเห็น” ชุดข้อมูลระหว่างการฝึก) เบนช์มาร์กจึงสูญเสียความสามารถในการแยกความแตกต่างระหว่างโมเดลชั้นนำ

งานศึกษาสำคัญที่ทำให้มาตรวัดแบบเดิมสั่นคลอนเผยแพร่ในเดือนมีนาคม 2026

สิ่งที่พวกเขาทำ:

• เลือกผู้ดูแลที่ยังทำงานอยู่ 4 คนจาก 3 คลังโค้ด (scikit-learn, Sphinx, pytest)
• ให้พวกเขาประเมิน PR ที่ AI สร้างจาก SWE-bench Verified จำนวน 296 รายการ—PR ทั้งหมดนี้ผ่านการทดสอบอัตโนมัติ
• เปรียบเทียบการตัดสินใจของผู้ดูแลกับตัวประเมินอัตโนมัติ

กล่าวอีกอย่างคือ เบนช์มาร์กบอกว่า “ผ่าน” แต่ผู้ดูแลบอกว่า “ไม่รวม” ซึ่งเกิดขึ้นโดยเฉลี่ยในหนึ่งในสี่ของกรณี เหตุผลหลักสามข้อที่ถูกปฏิเสธ เรียงจากร้ายแรงน้อยไปมาก:

1. คุณภาพโค้ด — ไม่ตรงกับสไตล์ของคลังโค้ด
2. ทำให้โค้ดส่วนอื่นเสีย — ทำให้โค้ดข้างเคียงเสีย
3. ฟังก์ชันหลักล้มเหลว — แก้โจทย์ได้ไม่ครบ แม้การทดสอบจะผ่าน

FrontierCode ทำให้ปัญหานี้เป็นรูปธรรม Cognition นำแนวคิดนี้มาขยายเป็นเบนช์มาร์กเต็มรูปแบบ โดยมีผู้ดูแลมากกว่า 20 คน แทนที่จะมี 4 คน

อีกหนึ่งหลักฐานสำคัญคืองานศึกษาเมื่อเดือนธันวาคม 2025 เกี่ยวกับความปลอดภัยของแพตช์ที่ AI สร้าง

ในงานศึกษานี้ โซลูชันของ SWE-Agent ที่ใช้ Claude 4 Sonnet ถูกต้องในเชิงการทำงาน 61% แต่มีเพียง 10.5% เท่านั้นที่ปลอดภัย

โค้ดผ่านการทดสอบ แต่แพตช์หนึ่งในสองกลับสร้างช่องโหว่ด้านความปลอดภัย คุณมองไม่เห็นเรื่องนี้เลยจากเบนช์มาร์ก SWE-bench เพราะไม่ได้วัดความปลอดภัย อย่างน้อย FrontierCode ก็พยายามตรวจจับผ่านเกณฑ์ “ความเรียบร้อยเชิงกลไก” และคุณภาพโค้ด

อันดับโมเดล: Opus 4.8 ได้ 13.4%, GPT-5.5 ได้ 6.3%#

สิ่งที่เห็นได้ชัดจากตาราง:

• มีผู้นำที่ชัดเจนหนึ่งราย Opus 4.8 ของ Anthropic นำคู่แข่งที่ใกล้ที่สุดอยู่ประมาณสองเท่า ช่องว่างที่สังเกตเห็นได้ยากใน SWE-bench ปรากฏชัดเจนใน FrontierCode
• โมเดลโอเพนซอร์สยังตามไม่ทัน Kimi K2.6—โมเดลโค้ดโอเพนซอร์สที่ดีที่สุด—ได้คะแนน 3.8% บน Diamond ต่ำกว่า Opus 4.8 อยู่ 3–4 เท่า Cognition ไม่ได้เผยแพร่ตาราง Kimi K2.6 แบบเต็มสำหรับ Main และ Extended จึงยังเปรียบเทียบกับชุดเต็มไม่ได้
• Cognition วางโมเดลของตัวเองไว้อย่างตรงไปตรงมา ในช่วงล่างของตาราง

ชุดย่อย Diamond ถูกตั้งใจปล่อยให้ “ยังไม่อิ่มตัว” Cognition เผื่อพื้นที่ปลอดภัยไว้สำหรับปีต่อ ๆ ไป หากเบนช์มาร์กก่อนหน้านี้ถึงจุดอิ่มตัวใน 12–18 เดือน FrontierCode ก็ได้รับการออกแบบให้มีเพดานที่สูงกว่า

“พร้อมรวม 13%” หมายความว่าอย่างไรสำหรับผู้ทำ Vibe Coding ที่ใช้ Claude Code?#

ก่อนอื่น ต้องปรับกรอบความคิดเรื่องสำคัญ: ชุด Diamond ของ FrontierCode ตั้งใจให้ยากสุดขีด สำหรับงานทั่วไปในโปรเจกต์สตาร์ตอัปใหม่ที่ไม่มีโมดูลพึ่งพากันถึงสี่สิบโมดูล เอเจนต์ AI ทำได้ดีกว่าอย่างเห็นได้ชัด Opus 4.8 รุ่นเดียวกันได้คะแนนโค้ดพร้อมรวม 51.8% บน Extended (150 งาน ซึ่งเป็นชุดเต็ม) นี่เป็นภาพที่ต่างออกไปโดยสิ้นเชิง

ผล 51.8% ใช้กับ Extended 150 งานของเบนช์มาร์ก สูงกว่า Diamond แต่ทั้งสองตัวเลขไม่ประมาณ mergeability ของแพตช์ทุกโมเดลในงานของคุณ คะแนน Main หรือ Extended ที่ขาดของโมเดลอื่นไม่อนุญาตให้เติมผลให้มัน

เรื่องนี้หมายความว่าอย่างไรสำหรับผู้ทำ vibe coding ที่ผลักโค้ดไปใช้งานจริง:

• ผลทดสอบผ่านไม่ได้แปลว่า “พร้อมรวม” อีกต่อไป การทดสอบที่ AI เขียนเองอาจไม่มีประโยชน์—มันผ่านกับโค้ดใด ๆ ก็ได้ FrontierCode วัดเรื่องนี้โดยตรงผ่าน Reverse-Classical: หากการทดสอบไม่ล้มเหลวกับโค้ดเวอร์ชันที่เสีย ก็ไม่นับ
• สไตล์และธรรมเนียมของคลังโค้ดมีความสำคัญ หากโปรเจกต์มีรูปแบบที่ใช้อยู่แล้วแต่ AI ไม่ทำตาม ผู้ร่วมงานจริงก็จะไม่ยอมรับการเปลี่ยนแปลง ในโปรเจกต์ส่วนตัวที่ไม่มีกฎ เรื่องนี้ไม่ใช่ปัญหาใหญ่ แต่ในทีม นี่คือปัญหาอันดับหนึ่ง
• การทดสอบไม่ได้แก้ปัญหาความปลอดภัย จำตัวเลขข้างต้นไว้: มีแพตช์เพียง 10.5% ที่ปลอดภัย แม้ว่า 61% จะถูกต้อง ต้องตรวจเรื่องนี้แยกต่างหาก โดยใช้เครื่องมือที่ตรวจหาโทเค็น ไฟล์ .env และรหัสผ่านเริ่มต้น
• การทำเกินขอบเขตงานเป็นข้อผิดพลาดทั่วไปของ AI คุณขอให้แก้ฟังก์ชันการอนุญาต แต่กลับได้แพตช์ที่เขียนเลเยอร์ภายในและระบบบันทึกล็อกใหม่ด้วย นี่เป็นหนึ่งใน 6 เกณฑ์ของ FrontierCode

AI ทำข้อผิดพลาด 6 หมวดหมู่ใดบ้างในงานยาก?#

มาดูแต่ละเกณฑ์ด้วยภาษาง่าย ๆ:

1. ความถูกต้องเชิงพฤติกรรม — แพตช์แก้ปัญหาตามโจทย์หรือไม่?

เกณฑ์พื้นฐานที่สุด AI มักเขียนโค้ดที่ดูเหมือนเป็นโซลูชัน แต่แก้ปัญหาผิดจุด ฉันขอให้เพิ่ม “ใบตอบรับการอ่านข้อความ” แล้วได้ฟังก์ชัน markAsRead แต่ฟังก์ชันนั้นยังไม่ได้เชื่อมกับคอมโพเนนต์แชต การทดสอบฟังก์ชันผ่าน แต่งานทางธุรกิจยังไม่สำเร็จ

2. ความปลอดภัยจากการถดถอย — หลีกเลี่ยงการทำให้โค้ดข้างเคียงเสียหรือไม่?

AI เปลี่ยนโมดูลหนึ่ง แล้วอีกโมดูลกลับใช้งานไม่ได้ กรณีที่พบบ่อยที่สุดคือเอเจนต์ AI เปลี่ยนซิกเนเจอร์ของฟังก์ชัน โดยลืมว่ามีการเรียกใช้จากอีก 17 จุด คุณมองไม่เห็นเรื่องนี้ใน SWE-bench เพราะรันการทดสอบเพียงไฟล์เดียว แต่ใน FrontierCode จะรัน ชุดทดสอบทั้งหมดของคลังโค้ด

3. ความเรียบร้อยเชิงกลไก — ผ่านการตรวจ build, lint และสไตล์หรือไม่?

AI อาจสร้างโค้ดที่คอมไพล์ในเครื่องได้ แต่ไม่ผ่าน CI: import หายไป ใช้แท็บแทนช่องว่าง มีช่องว่างท้ายบรรทัดสองช่อง หรือพลาดใน eslint.config.js โปรเจกต์ที่ใช้งานจริงไม่ได้มองสไตล์เป็นเรื่องตามใจชอบ แต่เป็นกฎของทีม

4. ความถูกต้องของการทดสอบ — การทดสอบที่ AI เขียนถูกต้องหรือไม่?

เกณฑ์ที่ซับซ้อนที่สุด AI เขียนการทดสอบที่ผ่าน แต่การทดสอบนั้นผ่านกับโค้ดทุกแบบ รวมถึงโค้ดที่เสียด้วย ฉันเห็นเรื่องนี้มาหลายครั้ง: การทดสอบเช็กว่า “สคริปต์ล่มหรือไม่” แต่ไม่เช็กว่า “สคริปต์ส่งคืนผลลัพธ์ที่ถูกต้องหรือไม่” Reverse-Classical ของ FrontierCode ตรวจจับกรณีนี้ได้ตรงจุด

5. ขอบเขต — แพตช์หลีกเลี่ยงการแตะไฟล์ที่ไม่เกี่ยวข้องหรือไม่?

ฉันขอให้แก้ฟังก์ชันเดียว แต่ได้แพตช์สำหรับ 12 ไฟล์ รวมถึงไฟล์ที่ไม่เกี่ยวกับงาน นี่คือ “ความริเริ่ม” จาก AI ที่ทำให้โปรเจกต์ใช้งานจริงเสียหายด้วยการเปลี่ยนสิ่งที่ฉันไม่ได้ขอ เกณฑ์นี้เป็นข้อขัดขวางเด็ดขาดใน FrontierCode

6. คุณภาพโค้ด — โค้ดทำตามธรรมเนียมของคลังโค้ดหรือไม่?

AI เขียนฟังก์ชันของตัวเอง “ตั้งแต่ต้น” แทนที่จะใช้ตัวช่วยที่มีอยู่แล้วใน lib/ หรือเลือกชื่อตัวแปรที่ไม่ตรงกับสไตล์โปรเจกต์ หรือวางตรรกะไว้ผิดเลเยอร์สถาปัตยกรรม จากมุมมองของการทดสอบ ทุกอย่างทำงาน แต่จากมุมมองของหัวหน้าทีมเทคนิค โค้ดนี้จะไม่ถูกรวม

วิธีตรวจสอบโค้ด AI ก่อน push: 5 ขั้นตอน#

1. รันชุดทดสอบทั้งหมด ไม่ใช่แค่การทดสอบที่เกี่ยวกับการเปลี่ยนแปลง

   AI มักเปลี่ยนโค้ดเกินขอบเขตงาน ปัญหาจะแสดงในผลการทดสอบของส่วนข้างเคียง ฉันรันชุดทดสอบทั้งหมด (ด้วยคำสั่งเดียว npm test โดยไม่ระบุพาธ) ไม่ใช่เฉพาะการทดสอบของไฟล์ใดไฟล์หนึ่ง ในโปรเจกต์ขนาดใหญ่ การทำแบบนี้ควบคู่กันผ่าน git worktree สะดวกกว่า (ดู Git worktree in Claude Code)

2. รันการตรวจ lint, สไตล์ และชนิดข้อมูล

   รันสามคำสั่งตามลำดับ: eslint ., prettier --check ., tsc --noEmit เอเจนต์ AI อาจพลาดทั้งแท็บและช่องว่างท้ายบรรทัดที่เกินมา หากโปรเจกต์มีการตรวจเข้มงวด ให้รันในเครื่องก่อนเผยแพร่

3. ทดสอบตัวการทดสอบเอง

   สำคัญที่สุดในบรรดาการตรวจทั้ง 5 ข้อ ฉันทำให้โค้ด “พัง” เล็กน้อย (เปลี่ยน return true เป็น return false) การทดสอบควรล้มเหลว ถ้าการทดสอบไม่ล้มเหลว AI ก็เขียนมันมาแค่ให้ดูเหมือนมี และมันใช้การไม่ได้ ฉันลบการทดสอบนั้น แล้วขอให้ AI เขียนใหม่พร้อมเงื่อนไขบังคับ: การทดสอบต้องล้มเหลวกับเวอร์ชันที่ทำให้เสีย

4. ตรวจดูว่า AI แตะไฟล์ใดบ้าง

   คำสั่ง git diff --stat แสดงไฟล์ที่เปลี่ยนและจำนวนบรรทัด หาก AI แตะ 12 ไฟล์เพื่อตอบสนองคำขอ “แก้แบบฟอร์มติดต่อ” แสดงว่าทำเกินขอบเขตงาน ฉันย้อนการเปลี่ยนแปลงส่วนเกินด้วยคำสั่งเดียวสำหรับไฟล์นั้น

5. ตรวจความปลอดภัยด้วย skill สำเร็จรูป

   การทดสอบตรวจไม่พบ SQL injection หรือรหัสผ่านที่เขียนฝังไว้ ฉันใช้ skill ความปลอดภัยสำเร็จรูปสำหรับ Claude Code (ดู skill ความปลอดภัยสำเร็จรูป 754 รายการ) อย่างน้อยที่สุด ให้ค้นคำว่า “password,” “secret,” และ “key” ในโค้ดของโปรเจกต์ด้วยตนเอง และตรวจว่า .env.example มีข้อมูลครบถ้วน

ทั้ง 5 ขั้นตอนครอบคลุม 5 ใน 6 เกณฑ์ของ FrontierCode (ข้อ 1–5) ส่วนเกณฑ์ที่หก—คุณภาพโค้ด—ตรวจโดยอัตโนมัติผ่าน lint และการรีวิวโดยมนุษย์

อะไรช่วยเพิ่มโอกาสให้โค้ดพร้อมรวมได้จริง?#

เอเจนต์ AI ในโปรเจกต์ที่ยังไม่ได้เตรียมไว้จะเห็น เฉพาะไฟล์ที่คุณเปิดให้ดู ไม่มีประวัติการตัดสินใจของคุณ ไม่มีธรรมเนียมของคุณ และไม่มีแผนผังโมดูล เรื่องนี้ไม่ใช่ปัญหาใหญ่สำหรับการเปลี่ยนแปลงง่าย ๆ สำหรับการแก้ยาก บริบทโปรเจกต์ที่ขาดเป็นความเสี่ยงที่ควรแก้ แต่ตัวเลข 13.4% ไม่ได้แยกคุณภาพบริบทเป็นสาเหตุ

สิ่งที่ต้องทำเพื่อเปลี่ยน 13% ให้กลายเป็นสิ่งที่ผลักดันไปใช้งานจริงได้:

1. กฎของโปรเจกต์ — เพื่อให้ AI จำลองวิธีคิดของคุณ แทนที่จะใช้ค่าเฉลี่ยของอินเทอร์เน็ต

นี่คือชุดโซลูชันสำเร็จรูป นิสัย และกฎที่เรียนรู้มาของคุณ ซึ่งจัดเก็บในรูปแบบที่เอเจนต์ AI อ่านทุกครั้งที่ได้รับคำขอ เมื่อมีกฎ 30+ ข้อ AI ก็หยุดแต่ง “ค่าเฉลี่ยของอุตสาหกรรม” ขึ้นมาเอง และเริ่มเสนอคำแนะนำในสไตล์ของคุณ การทำงานเกินขอบเขตโจทย์แก้ได้ด้วยกฎหนึ่งบรรทัด: “อย่าแตะไฟล์นอกเหนือจากที่ระบุชื่อไว้อย่างชัดเจนในคำขอ”

2. แผนที่โปรเจกต์ — โฟลเดอร์ที่อธิบายโปรเจกต์

ใส่ข้อมูลเกี่ยวกับผลิตภัณฑ์ กลุ่มเป้าหมาย เศรษฐศาสตร์ ตัวชี้วัด และการตั้งค่าไว้ที่นี่ ก่อนรับคำขอแต่ละครั้ง เอเจนต์ AI จะอ่านสารบัญและเข้าใจว่า กำลังทำงานกับส่วนใดของธุรกิจ วิธีนี้จัดการเหตุผลที่ทำให้ถูกปฏิเสธสองข้อที่กล่าวถึงข้างต้นได้โดยอัตโนมัติ ได้แก่ สไตล์และการทำให้โค้ดส่วนอื่นเสีย

3. วิศวกรรมบริบท — จัดการสิ่งที่ AI เห็นก่อนรับคำขอ

ไม่ใช่ “จะเขียนพรอมป์ต์อย่างไร” แต่คือ “จะใส่อะไรลงในหน้าต่างบริบทก่อนพรอมป์ต์” CLAUDE.md ข้อกำหนดเบื้องต้น และลิงก์ไปยังไฟล์ที่ตรงเป้าหมาย วิธีนี้จัดการปัญหาความถูกต้องเชิงพฤติกรรมและคุณภาพโค้ด

ใช้การผสมนี้เตรียมพร้อมสำหรับการตรวจ ไม่ใช่หลักฐานว่าผ่านห้าแกนแล้ว ตรวจพฤติกรรม regressions การทดสอบ ขอบเขต และคุณภาพโค้ดบนแพตช์จริงก่อนยอมรับ

อีกชั้นหนึ่งคือเอเจนต์รีวิว:

• Cursor Bugbot — รีวิวทุก PR ตามข้อมูลของ Cursor เครื่องมือนี้ประมวลผล PR ประมาณ 2 ล้านรายการต่อเดือน
• subagents แบบซ้อนใน Claude Code v2.1.172 — เอเจนต์หนึ่งเขียนโค้ด อีกเอเจนต์รีวิว และเอเจนต์ที่สามรันการทดสอบ เป็นแนวคิดเดียวกับ FrontierCode คือแยกบทบาท “ผู้เขียน” และ “หัวหน้าทีมเทคนิค” ออกจากกัน

ดูเพิ่มเติม: ความปลอดภัยใน Vibe Coding, วิธีกำหนดค่า Claude Code ไม่ให้ทำโปรเจกต์พังตอนกลางคืน และแนวคิดเรื่องวิศวกรรมบริบท

ดูเนื้อหาเพิ่มเติมเกี่ยวกับการทำงานกับเครื่องมือได้ในเอกสารประกอบของ Ailoot