Real-SWE วัด coding agent บนโค้ดเบสบริษัทจริงที่ไม่เคยหลุดสู่อินเทอร์เน็ต — Fable 5.1 ใน Claude Code นำที่ 38.8% แต่ทั้งตารางมาจากงานแค่ 10 ข้อ

Specific Labs สตาร์ทอัพที่ขาย “ชุดข้อมูลของงานจริง” ให้บริษัทที่สร้างเอเจนต์ เผยแพร่ Real-SWE เมื่อเดือน ก.ย. 2026 (หน้าเว็บไม่ระบุวันที่แน่ชัด และเริ่มถูกพูดถึงวงกว้างบน Hacker News เมื่อ 12 ก.ย.) คำถามของเบนช์มาร์กนี้คือ “coding agent ทำงานของวิศวกรซอฟต์แวร์ในโลกจริงได้ไหม” — ทุกงานมาจาก โค้ดเบส production ส่วนตัวที่ Specific ซื้อสิทธิ์มาจากบริษัทจริง เป็นปัญหาที่วิศวกรของบริษัทเหล่านั้นเคยทำ และโค้ดกับเฉลยไม่เคยอยู่บนอินเทอร์เน็ต

ผลคือโมเดล frontier ทั้ง 8 ตัว เมื่อรันในฮาร์เนสของตัวเอง แก้งานได้เพียง 16.2–38.8% — ต่ำกว่าตัวเลข 70–80% ที่เราเห็นกันจนชินบนเบนช์มาร์กสาธารณะมาก

Real-SWE ต่างจาก SWE-bench อย่างไร

Specific ชูสามจุด: โค้ดเป็น ของส่วนตัว จึงไม่มีทางอยู่ในข้อมูลเทรน, งานมี ผลทางธุรกิจ เช่น คิดภาษีให้ถูก บิลลิ่ง ย้ายข้อมูลลูกค้า ซึ่งมักข้ามหลายเซอร์วิส และแต่ละบริษัทมี ธรรมเนียมการเขียนโค้ดของตัวเอง ที่เอเจนต์ต้องทำตาม

ตัวอย่างงานที่เปิดให้ดูคือเซอร์วิส NestJS ที่ออกใบแจ้งหนี้โดยไม่มีภาษีเลย เอเจนต์ต้องทำให้แต่ละธุรกิจคิดภาษีตามวิธีของตัวเอง (บางรายตั้งอัตราเอง บางรายส่งไปถาม TaxJar ตามปลายทางผู้ซื้อ บางรายไม่เก็บ) ยกเว้นลูกค้าที่มีสิทธิ์ยกเว้นภาษี เลือก TaxJar sandbox หรือ production ตามบัญชี ส่งยอดขายกลับไปยื่นหลังชำระ และบันทึกลง InfluxDB ledger สภาพแวดล้อมรวมทั้งหมดมีตั้งแต่ AWS emulator, Docker, Kubernetes, PostgreSQL, MongoDB, Redis ไปจนถึง Linear MCP, Slack, Intercom และ Google Drive

ตัวเลขเปรียบเทียบที่ Specific ให้ไว้: คำสั่งงานยาวเฉลี่ย (มัธยฐาน) 1,742 ตัวอักษร ใกล้เคียง DeepSWE และ Terminal-Bench แต่เฉลยอ้างอิงแก้ไฟล์มัธยฐาน 11 ไฟล์ เทียบกับ 6 ไฟล์ของ FrontierCode และ DeepSWE ทุกงานอยู่ในรูปแบบ Harbor รันใน sandbox แยก และตัวตรวจถูกใส่เข้าไปตอนให้คะแนน โดยดัดแปลงหรือใช้เทสต์ที่มีอยู่แล้วในโค้ดเบสนั้น

ผลลัพธ์

Resolution rate คือ pass@1 เฉลี่ยจาก 8 รอบต่องาน คอลัมน์สุดท้ายเราคำนวณเองจากตัวเลขในหน้าเว็บ (ต้นทุนต่อรอบ ÷ อัตราผ่าน)

#	โมเดล	ฮาร์เนส	อัตราผ่าน	ต้นทุน/รอบ	ต้นทุน/งานที่ผ่าน
1	Fable 5.1	Claude Code	38.8%	$6.96	~$18.0
2	GPT-6 Astra	Codex CLI	33.8%	$4.67	~$13.8
3	Gemini 3.8 Flash	Gemini CLI	31.2%	$2.50	~$8.0
4	GLM 5.3	Claude Code	28.8%	$5.12	~$17.8
=5	Grok 4.6	Grok Build	23.8%	$3.44*	~$14.5*
=5	Muse Spark 1.3	Muse Code	23.8%	$2.74	~$11.5
7	Kimi K3	Kimi Code	18.8%	$3.90*	~$20.8*
8	GPT-5.6 Sol	Codex CLI	16.2%	$2.65	~$16.3

* Specific ระบุว่าข้อมูลการใช้งานของ Grok และ Kimi ไม่ครบ ต้นทุนจริงอาจสูงกว่านี้

Fable ใช้ output tokens มากกว่าคู่แข่งอย่างเห็นได้ชัด — เช่นงาน API token metering ใช้เฉลี่ย 95k โทเคนต่อรอบ เทียบกับ GPT-6 Astra ราว 31k — จึงแพงที่สุดต่อรอบ ส่วน Gemini 3.8 Flash ได้อันดับสามด้วยต้นทุนถูกที่สุด

ล้มเหลวแบบไหน

Specific จัดประเภทความล้มเหลวตามแนวของ DeepSWE และพบว่าแต่ละโมเดลพังคนละแบบ:

• ทำไม่ครบตามโจทย์ (missed requirement) เป็นสาเหตุที่พบบ่อยที่สุด — หนักสุดคือ Grok 4.6 ที่ 67.2% ของรอบที่ fail และ Kimi K3 53.8%
• ทึกทักเอาเองโดยไม่ตรวจ (unverified assumption) — GPT-5.6 Sol 43.3%, GPT-6 Astra 34.0%
• ไอเดียถูกแต่ต่อเข้าระบบผิด (integration error) — Gemini 3.8 Flash 49.1% ซึ่งยังเป็นตัวที่ ทำของเดิมพัง (regression) บ่อยที่สุดที่ 10.9% ขณะที่ GLM 5.3, Grok และ Kimi ไม่มี regression เลย

ระดับงานรายข้อยิ่งน่าสนใจ: 6 จาก 10 งานมีอัตราผ่านรวมต่ำกว่า 15% และงาน Analytics stream reducer ไม่มีใครผ่านเลยสักรอบจาก 64 รอบ แต่ละโมเดลก็มีจุดแข็งเฉพาะที่ตารางรวมกลบไว้ — Grok 4.6 ที่อยู่อันดับห้าผ่านงาน Customer identity migration 8/8 ขณะที่ GPT-6 Astra ได้ 1/8, Astra ผ่าน API token metering 5/8 ขณะที่ตัวอื่นได้ไม่เกิน 1/8, และในงาน S3 datastore measurement กับ Linearizable scan มีแค่ GLM 5.3 กับ Grok ที่ผ่านได้บ้าง ส่วน Fable, Astra และ Gemini ได้ 0/8 ทั้งคู่ อีกข้อสังเกตคือรอบที่จบภายใน 10 นาทีก็ fail พอ ๆ กับรอบยาว (71.4% เทียบ 73.4%) แปลว่าเอเจนต์ไม่ได้แพ้เพราะวนนานเกินไป แต่มักเข้าใจงานผิดตั้งแต่ต้น

ข้อควรระวังในการอ่านตาราง

• ทั้งตารางมาจาก 10 งาน — 8 โมเดล × 10 งาน × 8 รอบ = 640 rollouts ซึ่งตรงกับจำนวนรอบที่ fail ของแต่ละโมเดลที่หน้าเว็บแสดง (Fable fail 49 จาก 80 = ผ่าน 31) แต่ละงานจึงมีน้ำหนัก 10% ของคะแนนเต็ม
• ส่วนต่างอันดับบนเล็กมาก — Fable ผ่าน 31 รอบ Astra ผ่าน 27 รอบ ห่างกัน 4 รอบจาก 80 ถ้าคำนวณแบบ binomial อย่างง่าย ช่วงความเชื่อมั่น 95% ของ 38.8% จาก 80 รอบคือราว ±11 จุด และยังกว้างกว่านั้นเมื่อคิดว่ารอบในงานเดียวกันไม่ได้อิสระต่อกัน
• วัดคู่โมเดล+ฮาร์เนส ไม่ใช่โมเดลล้วน — GLM 5.3 รันใน Claude Code ส่วน GPT รันใน Codex CLI หัวข้อ Setup ในหน้าเว็บมีแค่สองประโยค ไม่ระบุเวอร์ชันฮาร์เนสหรือระดับ reasoning effort
• ข้อมูลไม่เปิด — ต้องขอสิทธิ์เพื่อดูตัวอย่างงาน และ Specific ทำธุรกิจขายข้อมูลแบบนี้ เบนช์มาร์กจึงเป็นทั้งงานวิจัยและเครื่องมือการตลาดไปพร้อมกัน

มุมมอง AI Curator

ทิศทางของ Real-SWE ถูกต้องและตอบคำถามที่เบนช์มาร์กสาธารณะตอบไม่ได้: ถ้าโค้ดไม่เคยอยู่บนอินเทอร์เน็ต ตัวเลขจะเหลือเท่าไร สิ่งที่สำคัญกว่าอันดับคือ ประเภทของความล้มเหลว — “ทำไม่ครบตามโจทย์” กับ “ทึกทักเอาเอง” รวมกันเป็นสาเหตุหลักเกือบทุกโมเดล ปัญหาของ coding agent ในงานธุรกิจจึงอยู่ที่การอ่านข้อกำหนดให้ครบและตรวจสมมติฐานกับระบบจริงก่อนลงมือ มากกว่าความสามารถในการเขียนโค้ด ซึ่งตรงกับประสบการณ์ของทีมที่ใช้เอเจนต์กับโค้ดเบสเก่า — งานที่พังคืองานที่ “กฎธุรกิจอยู่ในหัวคน ไม่ได้อยู่ในเอกสาร”

แต่ด้วยงานเพียง 10 ข้อ ตารางนี้ยังเป็นหลักฐานระดับ “น่าสนใจ” ยังไม่ถึงระดับ “ใช้ตัดสินใจเลือกโมเดล” การบอกว่า Fable นำ Astra จากส่วนต่าง 4 rollouts เป็นการอ่านเกินข้อมูล สิ่งที่เชื่อได้มากกว่าคือภาพรวม: ไม่มีโมเดลไหนเกิน 40%, ทุกโมเดลมีงานที่ได้ 0/8 และโมเดลอันดับกลางชนะงานเฉพาะบางแบบได้ขาดลอย

สำหรับทีมไทย บทเรียนที่เอาไปใช้ได้ทันทีคือ สร้าง “Real-SWE ส่วนตัว” จากรีโปของตัวเอง — หยิบ PR ที่ merge แล้ว 10–20 ชิ้นที่มีเทสต์รองรับ เขียนคำสั่งงานสั้นแบบที่หัวหน้าทีมสั่งจริง รันแต่ละคู่โมเดล+ฮาร์เนสหลายรอบ แล้วจัดประเภทความล้มเหลวแบบที่ Specific ทำ เมื่อจ่ายค่า API เป็นดอลลาร์ ให้ดู ต้นทุนต่องานที่ผ่าน ไม่ใช่ต้นทุนต่อรอบหรืออันดับ — บนตัวเลขชุดนี้ Gemini 3.8 Flash ถูกกว่า Fable ต่องานที่ผ่านราวครึ่งหนึ่ง ($8 เทียบ $18) แม้อัตราผ่านจะต่ำกว่า และในงานที่มีเทสต์ตรวจอัตโนมัติ การรันโมเดลถูกซ้ำหลายรอบอาจคุ้มกว่าการจ่ายแพงเพื่อรอบเดียว

แหล่งข่าว

• Specific Labs — Introducing Real-SWE: Benchmarking frontier AI models on private, real-world, enterprise codebases (ก.ย. 2026)
• Specific Labs — หน้าบริษัท (Datasets of real work)