Artificial Analysis Coding Agent Index: เลือก AI Coding Agent ต้องดู Model + Harness + Cost

เวลาทีมเริ่มใช้ AI เขียนโค้ด คำถามที่ได้ยินบ่อยมากคือ:

“ตอนนี้ model ไหนเก่งสุด?”

คำถามนี้ยังสำคัญครับ แต่เริ่มไม่พอแล้ว

เพราะในโลกของ AI coding agent เราไม่ได้ใช้ model ล้วน ๆ แบบอยู่ในห้องทดลอง

เราใช้ model ผ่าน agent harness เสมอ

เช่น Cursor, Codex, Claude Code, Gemini CLI, OpenCode หรือระบบ agent ที่บริษัทสร้างเอง

และสิ่งที่ Artificial Analysis เพิ่งเปิดตัวใน Coding Agent Index น่าสนใจมาก เพราะเขา benchmark แบบที่ใกล้โลกจริงกว่าเดิม:

วัด “model + harness” เป็นคู่ ไม่ใช่ model อย่างเดียว

นี่เป็น shift ที่สำคัญสำหรับทีมที่อยากใช้ AI coding agents แบบจริงจัง ไม่ใช่แค่ลอง prompt เล่น

1) เกิดอะไรขึ้น

Artificial Analysis ประกาศ Artificial Analysis Coding Agent Index เพื่อวัด performance ของ coding agents บน software engineering tasks ที่หลากหลาย

Index นี้เป็น composite จาก 3 benchmark:

• SWE-Bench-Pro-Hard-AA — งาน code generation / bug fixing จาก SWE-Bench Pro hard subset จำนวน 150 tasks
• Terminal-Bench v2 — งาน agentic terminal use จำนวน 84 tasks ในชุดที่ Artificial Analysis ใช้ หลัง exclude 5 tasks จาก 89 เพราะ environment compatibility
• SWE-Atlas-QnA — คำถาม technical Q&A จำนวน 124 tasks ที่ต้องเข้าใจ codebase, trace behavior, และตอบด้วยเหตุผลเชิงเทคนิค

พูดง่าย ๆ คือไม่ได้วัดแค่ “เขียน function ได้ไหม”

แต่วัดหลายมิติของ coding agent:

• แก้ code จริงใน repo ได้ไหม
• ใช้ terminal ทำงานหลาย step ได้ไหม
• เข้าใจ codebase และ root cause ได้ไหม
• ใช้ token เท่าไร
• cost ต่อ task เท่าไร
• ใช้เวลาต่อ task เท่าไร
• cache behavior ส่งผลต่อเศรษฐศาสตร์ของงานแค่ไหน

นี่เป็นแนวทางที่ practical กว่า leaderboard แบบ model-only มากครับ

2) ทำไม Model อย่างเดียวไม่พอ

ถ้าเราเลือก coding agent จาก model อย่างเดียว เรากำลังมองแค่ “สมอง” แต่ไม่ได้มอง “ร่างกาย” และ “ระบบงาน”

Agent harness คือชั้นที่กำหนดว่า model จะทำงานกับโลกจริงอย่างไร:

• อ่านไฟล์ยังไง
• search repo ยังไง
• edit code ยังไง
• run test ยังไง
• recover จาก error ยังไง
• ใช้ context ยังไง
• cache prompt ได้ดีไหม
• มี approval / safety loop ไหม
• ส่ง diff หรือ proof ให้ human review ยังไง

ดังนั้น model เดียวกัน เมื่ออยู่คนละ harness ผลลัพธ์อาจต่างกันได้มาก

ในหน้า Artificial Analysis มีตัวอย่างชัดมาก: เขาเปรียบเทียบ Claude Opus 4.7 ในหลาย harness

ผลที่เห็นคือ:

• Opus 4.7 + Cursor CLI ได้ Index 61
• Opus 4.7 + Claude Code ได้ Index 60
• Opus 4.7 + OpenCode ได้ Index 37

นี่ไม่ได้แปลว่า OpenCode แย่ถาวร หรือ Cursor ชนะทุกงาน

แต่มันย้ำประเด็นว่า scaffold / harness / execution loop มีผลมาก

ถ้าธุรกิจจะลงทุนกับ AI coding agents คำถามจึงไม่ควรจบที่ “ใช้ GPT, Claude, Gemini, Kimi หรือ GLM ดี”

แต่ต้องถามต่อว่า:

ใช้ผ่าน harness อะไร และ harness นั้นเหมาะกับ workflow เราไหม

3) ตัวเลขที่ควรสนใจ ไม่ใช่แค่คะแนนรวม

ผลประกาศจาก Artificial Analysis มีหลายจุดที่น่าสนใจ

กลุ่มคะแนนนำ

ตัวบน ๆ ของ Index คือ:

• Cursor CLI + Opus 4.7 — 61
• Codex + GPT-5.5 — 60
• Claude Code + Opus 4.7 — 60
• Cursor CLI + GPT-5.5 — 58

ความต่างของคะแนนบนหัวตารางไม่ได้ห่างกันมาก

แปลว่า ถ้ามอง score อย่างเดียว หลายตัวอยู่ในระดับใกล้กัน

แต่พอเปิดดู cost, runtime, token usage ภาพจะเปลี่ยนทันที

Open-weight models เริ่มน่าสนใจ แต่ยังไม่เท่าหัวตาราง

Artificial Analysis ระบุว่า open-weight models แข่งขันได้มากขึ้น แต่ยังตาม proprietary leaders อยู่

ตัวอย่าง:

• GLM-5.1 + Claude Code ได้ 53
• Kimi K2.6 + Claude Code ได้ 50
• DeepSeek V4 Pro + Claude Code ได้ 50

สำหรับทีมที่อยากคุม cost, data boundary, หรือ provider dependency ตัวเลขนี้น่าสนใจมาก

แต่ต้องอ่านคู่กับ runtime และ token usage ด้วย

เพราะ open-weight ที่ score ดีอาจกิน token เยอะ หรือใช้เวลานานกว่า

Cost ต่างกันแรงมาก

จุดที่ผมว่า business team ควรดูคือ cost per task

Artificial Analysis ระบุว่า cost ต่อ task ต่างกันมากกว่า 30 เท่า

ตัวอย่างจากหน้า benchmark:

• Composer 2 + Cursor CLI ถูกสุดประมาณ $0.07/task
• DeepSeek V4 Pro + Claude Code ประมาณ $0.35/task
• Kimi K2.6 + Claude Code ประมาณ $0.76/task
• Opus 4.7 + Claude Code ประมาณ $1.24/task
• GPT-5.5 + Codex ประมาณ $2.21/task
• GLM-5.1 + Claude Code ประมาณ $2.26/task

นี่คือประเด็นสำคัญมาก

เพราะถ้าทีมของคุณมีงาน coding agent วันละ 10 tasks กับวันละ 1,000 tasks คำตอบเรื่อง “เลือกอะไรดี” จะไม่เหมือนกันเลย

Score สูงกว่า 2-3 จุด อาจไม่คุ้ม ถ้างานเป็นงาน routine ที่แก้ได้ด้วยตัวถูกกว่า

แต่สำหรับงาน critical เช่น production refactor, security-sensitive change, หรือ codebase ที่ซับซ้อน คะแนนและ reliability อาจคุ้มกว่าค่า model

4) Token usage และเวลาคือ operational cost ที่หลายทีมลืม

อีกตัวเลขที่ควรดูคือ token usage และ execution time

Artificial Analysis ระบุว่า token usage ต่างกันมากกว่า 3 เท่า และ time per task ต่างกันมากกว่า 7 เท่า

ตัวอย่าง runtime ต่อ task:

• Claude Code + Opus 4.7 เร็วมาก ประมาณ 5.8 นาที/task
• Codex + GPT-5.5 ประมาณ 7.1 นาที/task
• Cursor CLI + Composer 2 ประมาณ 8.7 นาที/task
• Claude Code + DeepSeek V4 Pro ประมาณ 18 นาที/task
• Claude Code + GLM-5.1 ประมาณ 21.6 นาที/task
• Claude Code + Kimi K2.6 ช้าสุดในชุดที่เห็น ประมาณ 41.5 นาที/task

เวลาไม่ใช่แค่ UX ครับ

เวลาคือ throughput ของทีม

ถ้า agent หนึ่งถูกกว่า แต่ใช้เวลานานมาก อาจเหมาะกับงาน batch หลังบ้าน แต่ไม่เหมาะกับ interactive workflow ที่ engineer รออยู่

กลับกัน ถ้า agent แพงกว่าแต่จบเร็วและถูกต้องกว่า อาจคุ้มกว่าในงานที่ human attention แพงกว่าค่า token

นี่คือเหตุผลที่ผมชอบ benchmark แบบนี้

มันบังคับให้เราคิดแบบ operator ไม่ใช่คิดแบบคนดู leaderboard

5) Cache hit rate คือเศรษฐศาสตร์ที่ซ่อนอยู่

อีกจุดที่ Artificial Analysis ใส่ไว้ และหลายคนมักมองข้าม คือ prompt cache hit rate

Cache hit rates ใน benchmark อยู่ประมาณ 80% ถึง 96%

ฟังดู technical แต่ผลทางธุรกิจชัดมาก

เพราะ cached input tokens มักถูกกว่าราคาปกติมาก

ถ้า harness หรือ provider routing ทำให้ cache hit rate ดี ต้นทุนจริงอาจลดลงมาก

ถ้า routing ทำให้ cache hit rate แย่ ทั้งที่ใช้ model เดียวกัน งานเดียวกัน ค่าใช้จ่ายจริงก็เปลี่ยนได้

สำหรับองค์กร นี่แปลว่า:

• อย่าดูแต่ราคา token list price
• ต้องดู cache behavior ใน workflow จริง
• ต้องวัด cost ต่อ completed task ไม่ใช่ cost ต่อ 1M tokens อย่างเดียว
• ต้องดู retries ด้วย เพราะ retry คือ cost ที่ไม่ค่อยถูกนับใน demo

6) Benchmark นี้ควรใช้ยังไงในธุรกิจ

ผมไม่แนะนำให้ทีมเอา leaderboard นี้ไปสรุปง่าย ๆ ว่า “ตัวที่ได้คะแนนสูงสุดคือ default สำหรับทุกงาน”

ควรใช้เป็นกรอบคิดมากกว่า

เริ่มจากแบ่งงาน coding agent ของเราเป็นกลุ่ม:

งานเล็ก ชัด ทำซ้ำเยอะ

เช่น:

• เพิ่ม test
• แก้ lint
• refactor ชื่อ function
• update docs
• port util เล็ก ๆ
• generate boilerplate

งานกลุ่มนี้ควร optimize ที่ cost/time มากกว่าใช้ flagship ทุกครั้ง

ถ้า Composer 2 หรือ model/harness ที่ถูกกว่าแก้ได้พอ ก็อาจคุ้มกว่า

งาน production ที่มี edge case

เช่น:

• bug ที่แตะหลาย module
• migration
• payment / auth / permission logic
• integration ที่พังยาก
• security-sensitive code

งานนี้ควรใช้ agent ที่ reliable กว่า และมี review loop ที่ดี

แพงขึ้นได้ ถ้าลดโอกาสพัง

งาน terminal/devops

เช่น:

• debug CI
• inspect logs
• run scripts
• reproduce bug
• setup environment
• write migration helper

งานนี้ต้องดู Terminal-Bench-style performance และความสามารถในการ recover จาก command failure

ไม่ใช่ดูแค่ coding score

งาน repo understanding / advisory

เช่น:

• ทำไม behavior นี้เกิดขึ้น
• API path ไหนเรียกอะไร
• root cause อยู่ตรงไหน
• architecture flow เป็นอย่างไร

งานนี้ใกล้ SWE-Atlas-QnA มากกว่า SWE-Bench patching

agent ที่ตอบ technical Q&A ดี อาจไม่ใช่ตัวเดียวกับ agent ที่ patch code ดีที่สุด

7) บทเรียนสำหรับทีมไทย

ถ้าจะเอา AI coding agent เข้าองค์กร ผมอยากให้เริ่มจาก operating checklist นี้ก่อนเลือก model:

1. นิยามงานก่อน — งานเป็น patch, terminal task, Q&A, test writing, refactor หรือ investigation?
2. กำหนด proof — เสร็จแล้วต้องมี test, screenshot, log, diff, benchmark หรือ reviewer note อะไร?
3. แยกงานตาม risk — งาน low-risk ใช้ agent ถูก/เร็วได้ งาน high-risk ต้องใช้ stronger agent + human review
4. วัด cost ต่อ completed task — ไม่ใช่แค่ดูราคา token
5. วัด time ต่อ task — ถ้า human ต้องรอ agent นาน cost แฝงสูงมาก
6. เก็บ retry rate — agent ที่ต้อง retry บ่อยอาจแพงกว่าที่เห็น
7. มี rollback path — agent ไม่ควรแก้ production โดยไม่มีทางย้อน
8. ทำ eval ของตัวเอง — benchmark สาธารณะเป็น reference แต่ workflow บริษัทเราต้องวัดเอง

8) มุมมองของผม

ผมคิดว่า Coding Agent Index นี้สำคัญ เพราะมันทำให้ conversation โตขึ้น

จากเดิม:

“model ไหนเก่งสุด?”

กลายเป็น:

“model + harness + workflow แบบไหนเหมาะกับงานเรา?”

นี่คือคำถามที่ถูกกว่าในโลกธุรกิจ

เพราะ AI coding agent ไม่ใช่แค่ chatbot ที่ตอบ code

มันคือ worker ที่เข้า repo, อ่านไฟล์, แก้ code, run command, เจอ error, ตัดสินใจ retry, และส่ง proof ให้มนุษย์ตรวจ

ถ้าระบบรอบตัวมันไม่ดี ต่อให้ model ฉลาดก็ยังส่งงานไม่ดีได้

และถ้าระบบรอบตัวดีขึ้น model ที่ไม่ใช่อันดับหนึ่งก็อาจคุ้มที่สุดในบางงาน

ผมชอบประโยคนี้ในเชิง operating model:

อย่าเลือก AI coding agent จากคะแนนเดียว ให้เลือกจากงานจริง + cost จริง + เวลาจริง + proof ที่ทีมตรวจได้

สำหรับทีมที่กำลังเริ่มใช้ coding agents ปีนี้ ผมจะไม่เริ่มด้วยการถามว่า “ซื้อตัวไหนดี”

ผมจะเริ่มด้วยการสร้าง internal eval เล็ก ๆ:

• เลือก 20 tasks จากงานจริงของทีม
• แบ่งเป็น bug fix, docs, test, refactor, investigation
• ให้ agent หลายชุดลองทำ
• วัด pass rate, review effort, cost, time, retry, และ defect หลัง merge
• แล้วค่อยตัดสินใจ route งานแต่ละประเภทไปหา agent ที่เหมาะ

เพราะในยุค agentic workflow ผู้ชนะไม่ใช่ทีมที่มี model แพงที่สุด

แต่คือทีมที่รู้ว่า งานแบบไหนควรให้ agent ตัวไหนทำ ภายใต้ guardrail อะไร และต้องมี proof แบบไหนก่อนบอกว่า done

นี่แหละครับที่ทำให้ AI coding agents เปลี่ยนจากของเล่น เป็นระบบผลิตงานจริง