กราฟแท่งภาพหนึ่งเรียงภาษาโปรแกรม 19 ภาษาตามจำนวนโทเคนเฉลี่ยต่อโจทย์ แท่งบนสุดคือ Clojure แท่งล่างสุดคือ C โดยสองฝั่งห่างกัน 2.6 เท่า สีในกราฟยังแยกภาษาสายสแตติกกับสายไดนามิกไว้เสร็จสรรพ คนที่เห็นจึงอ่านข้อสรุปได้ในสามวินาทีว่าภาษาไดนามิกกินโทเคนน้อยกว่าอย่างเห็นได้ชัด และถ้าโทเคนเป็นทั้งค่าใช้จ่ายและตัวกำหนดว่าเซสชันหนึ่งจะทำงานกับ agent ได้นานแค่ไหน ภาษาที่โปรเจกต์ใช้อยู่ก็ดูแพงเกินจำเป็นขึ้นมาทันที

ตัวเลขชุดนี้มาจากโพสต์ของ Martin Alderson เมื่อ 8 มกราคม 2026 วิธีทำตรงไปตรงมา คือให้ Claude Code เลือกภาษายอดนิยมมาชุดหนึ่ง แล้วหยิบเฉพาะโจทย์ใน Rosetta Code ที่มีคนส่งคำตอบครบทั้ง 19 ภาษา จากนั้นจึงนับโทเคนด้วย tokenizer ของ GPT-4 เจ้าของโพสต์เขียนกำกับไว้เองว่าชุดข้อมูลและวิธีการนี้มีข้อจำกัดและอคติมากมาย ตั้งใจให้เป็นเพียงมุมมองที่น่าสนใจ ไม่ใช่งานวิจัยเชิงวิทยาศาสตร์ เขายังเขียนด้วยว่าการใช้ภาษาที่มี type กับ LLM มีข้อดีมหาศาล เพราะเมื่อคอมไพล์ก็จะได้ feedback เรื่อง syntax error และการหลอนชื่อเมธอดทันที

คำเตือนเหล่านี้แพร่ไปไม่ไกลเท่ากราฟ Dan Luu ลองค้นคำถามง่ายๆ เรื่องต้นทุนโทเคนของภาษาไดนามิกเทียบกับสแตติก แล้วพบว่าคำตอบ AI ที่ Google แสดงขึ้นต้นว่า โดยทั่วไปภาษาที่มี type แบบไดนามิกมีต้นทุนโทเคนกับ LLM ต่ำกว่าภาษาสายสแตติกดั้งเดิม เพราะไม่ต้องประกาศ type จึงเขียนโค้ดได้กระชับกว่า พร้อมอ้างโพสต์เดียวกันนั้นเป็นหลักฐาน ข้อจำกัดที่เจ้าของโพสต์เขียนกำกับไว้หายไปตั้งแต่ตรงนี้ เหลือเพียงตัวเลขที่ดูหนักแน่นพอจะทำให้ทีมหนึ่งเริ่มคิดเรื่องย้ายภาษา

พอโจทย์ใหญ่ขึ้น ช่องว่าง 2.6 เท่าก็หายไป

Dan Luu นำข้ออ้างนี้ไปวัดกับโจทย์ที่ใหญ่พอจะนับเป็นงานได้ การทดลองแรกให้ agent อ่าน RFC ของ zstd พร้อม errata แล้วเขียนตัวถอดรหัสออกมาให้ครบ โดยขัง agent ไว้ในคอนเทนเนอร์ที่ไม่มีอินเทอร์เน็ตและไม่ให้เทสต์เลยแม้แต่ตัวเดียว โมเดลที่ใช้คือ GPT-5.6 Sol รันที่ effort สองระดับ คือ medium กับ ultra โดย ultra เป็นระดับที่ปล่อยให้โมเดลทุ่มแรงกับโจทย์ข้อเดียวมากกว่า ส่วนการทดลองที่สองดัดแปลงจาก Pandoc ProgramBench โดยให้ agent ได้ทั้งข้อมูลประกอบและเทสต์ทั้งหมดของ ProgramBench แล้ววัดคะแนนจริงด้วยชุดเทสต์อีกชุดที่กันไว้ต่างหาก

ก่อนดูผล เขาเขียนคำทายบอกเพื่อนไว้ล่วงหน้า คือมั่นใจ 95% ว่าข้ออ้างไดนามิกเหนือสแตติกจะไม่จริง · 60% ว่าสแตติกจะดีกว่านิดหน่อยที่ effort ระดับ ultra · และ 98% ว่าความเหนือกว่าของภาษาแปลกๆ อย่าง J จะไม่จริง

ผลของ zstd ให้ภาพสองแบบที่ต่างกัน ถ้าดูเฉพาะ effort ระดับ medium กลุ่มภาษาไดนามิกจะกองอยู่มุมบนซ้าย คือทั้งถูกกว่าและให้คำตอบที่ถูกต้องกว่ากลุ่มสแตติก จึงให้ข้อสรุปเรื่องต้นทุนไปในทางเดียวกับกราฟภาพแรก แต่เมื่อขยับขึ้นไปที่ ultra ผลกลับปะปนกันจนไม่มีฝั่งไหนเหนือกว่าอีกฝั่งทุกด้าน ภาษาสแตติกสองสามภาษาขึ้นมาทำได้ดีที่สุด และในบรรดาภาษาที่ทำผลงานได้ดี ภาษาสแตติกมีจำนวนมากกว่าภาษาไดนามิก แม้เปลี่ยนแกนจากค่าใช้จ่ายเป็นเวลา ก็ยังไม่มีฝั่งไหนชนะขาด ส่วนผลของ Pandoc ยิ่งตรงไปตรงมา เพราะไม่เห็นความสัมพันธ์ที่ชัดเจนเลยระหว่างความสำเร็จหรือค่าใช้จ่าย กับการที่ภาษาเป็นสแตติก ไดนามิก หรือเขียนได้กระชับ

ทั้งสองการทดลองมีสิ่งที่เห็นตรงกันอยู่สองอย่าง อย่างแรกคือภาษาที่ค่อนข้างเฉพาะกลุ่มทำได้แย่ และ assembly ยิ่งแย่กว่า อย่างที่สองคือมี correlation เชิงบวกระดับอ่อนถึงปานกลาง กล่าวคือภาษาที่มีคนใช้มากกว่ามักให้คำตอบที่ทั้งถูกต้องกว่าและมีต้นทุนต่ำกว่า ส่วนอัตราส่วนสุดขั้วที่เห็นในโจทย์จิ๋วหายไปเมื่อโจทย์ใหญ่ขึ้น เหลือเพียงกรณีที่คาดเดาได้อยู่แล้วว่าจะออกมาแย่

Dan Luu ไม่ได้นำเสนอผลของตัวเองเกินตัว หัวข้อสรุปของโพสต์ตั้งคำถามว่าทั้งหมดนี้แปลว่าอะไร แล้วตอบในบรรทัดถัดมาว่า Who knows? เขาเรียก eval ของตัวเองว่าเป็นงานแบบ quick and dirty ที่ให้ coding agent สร้างให้ และบอกว่าทุกครั้งที่ใช้เวลาหนึ่งนาทีตรวจหาปัญหา ก็จะเจออย่างน้อยหนึ่งจุด รวมแล้วเขาแก้บั๊กของ eval ไปเกินร้อยจุดและคาดว่ายังเหลืออยู่อีก ขอบเขตที่เขาวางไว้ให้ผลของตัวเองคือ ข้อมูลชุดนี้ใช้หักล้างข้ออ้างแรงๆ บางข้อและชี้ทิศทางให้ข้ออ้างอื่นได้ แต่ชี้ได้เพียงระดับประเภทของภาษา ยังไม่ถึงขั้นบอกได้ว่าภาษาใดดีกว่าภาษาใด เพราะมีการทดลองเพียงสองงาน

เกณฑ์อีกชั้น คือทีมตรวจงานของ agent ได้เร็วแค่ไหน

วันที่ 11 สิงหาคม 2026 Google Developers Blog ลงบทความที่เสนอว่า Go เหมาะกับงานวิศวกรรมซอฟต์แวร์ที่มี AI ช่วย เขียนโดย Cameron Balahan ซึ่งเป็น Group Product Manager ของ Go และ Richard Seroter ซึ่งเป็น Chief Evangelist ของ Google Cloud

แกนของบทความคือการเปลี่ยนเกณฑ์ เมื่อ coding agent พ่นโค้ดที่มี syntax ถูกต้องได้เป็นร้อยบรรทัดในไม่กี่วินาที ความเร็วที่มนุษย์พิมพ์โค้ดได้ก็หมดความสำคัญ สิ่งที่มีต้นทุนสูงคือการรีวิว ตรวจสอบ และดูแลโค้ดต่อหลังจากสร้างเสร็จแล้ว บทความระบุตรงๆ ว่าคอขวดของวงจรพัฒนาซอฟต์แวร์ย้ายจาก generation ไปเป็น verification โดยสิ้นเชิง แล้วจึงไล่เรียงคุณสมบัติของ Go ที่สอดรับกับเกณฑ์นี้

• ความเรียบง่ายแบบมีจุดยืน เมื่อรวมกับ gofmt ที่บังคับใช้รูปแบบเดียว ทำให้โค้ดจากซีเนียร์ จูเนียร์ หรือ LLM หน้าตาเหมือนกันหมด ถ้าภาษาหนึ่งเปิดทางให้เขียนตรรกะเดียวกันได้สิบสองแบบ โมเดลจะพ่นโค้ดที่มีสไตล์กระจัดกระจาย แล้วคนรีวิวต้องเสียแรงเดาเจตนา
• คำสัญญาเรื่องความเข้ากันได้ โค้ดที่เขียนเมื่อสิบห้าปีก่อนสำหรับ Go 1.0 ยังคอมไพล์และรันบน toolchain ล่าสุดได้โดยไม่ต้องแก้ และทีมประกาศไว้ว่าจะไม่มี Go 2.0
• formatter · test framework · dependency management รวมอยู่ในชุด toolchain มาตรฐานตั้งแต่ต้น แต่ละทีมไม่ต้องเลือกกันเอง
• static type บวกกับการคอมไพล์ที่รวดเร็ว ถ้า agent เรียกเมธอดที่ไม่มีอยู่ ส่ง type ผิด หรือปล่อยตัวแปรไว้โดยไม่กำหนดค่า โค้ดจะคอมไพล์ไม่ผ่านทันที และ Go คอมไพล์เร็วกว่า Java · C# · Rust หลายเท่า agent จึงวนแก้เองได้โดยใช้ลูปที่มีต้นทุนต่ำกว่า

ข้อสำคัญที่ต้องรู้คือ ทั้งหมดนี้เป็นการให้เหตุผลจากคุณสมบัติของภาษา ในบทความไม่มี benchmark ไม่มี eval และไม่มีจำนวนโทเคนแม้แต่ตัวเดียว ส่วนผู้เขียนก็มาจากทีมของภาษานั้นเองและฝ่าย evangelist ของผู้ให้บริการคลาวด์รายเดียวกัน เธรดบน Hacker News ที่ตั้งขึ้นจากบทความนี้จับประเด็นดังกล่าวได้ทันที ภายในเจ็ดชั่วโมงแรก เธรดขึ้นไปถึง 247 คะแนนและ 287 คอมเมนต์ คำถามที่ตามมาแทบจะทันทีก็คือ มีข้อมูลเชิงปริมาณอะไรรองรับข้ออ้างที่ว่า Go ดีกว่าในเวิร์กโฟลว์ที่ใช้ LLM

ข้อโต้แย้งที่น่าฟังกว่าการเถียงว่าภาษาใดดี คือการใช้เกณฑ์ของบทความเองโต้ข้อเสนอของบทความ คนที่ทำงานในบริษัทซึ่งใช้ Go เป็นหลักเล่าว่าโค้ด Go ที่ LLM สร้างมีข้อผิดพลาดน้อยจริง แต่มีปริมาณมากจนเพื่อนร่วมงานรีวิวได้แย่ และเขาเห็นการตัดสินใจผิดพลาดง่ายๆ หลุดผ่านการรีวิวไปได้ เช่น การคืน HTTP code ผิด อีกคนชี้ว่า หากการรีวิวสำคัญกว่าจริงตามที่บทความว่า ความยืดยาวของ Go ก็กลายเป็นข้อเสียตามเกณฑ์นั้นเสียเอง เพราะการรีวิว Ruby บรรทัดเดียวที่ดึงค่าจาก CSV ง่ายกว่าการไล่อ่านโค้ด Go สี่สิบบรรทัดทีละบรรทัด

งานสองชิ้นนี้จึงตอบคำถามกันคนละระดับ และไม่มีชิ้นใดตอบคำถามของอีกชิ้น ฝั่งหนึ่งเสนอว่าต้องเปลี่ยนเกณฑ์วัดภาษาไปเป็นการอ่านและการตรวจ อีกฝั่งนำเกณฑ์ที่คนใช้เป็นตัวแทนกันอยู่แล้วไปวัด และพบว่าการวัดเดิมยังไม่ดีพอ สรุปแล้ว งานสองชิ้นนี้ยังไม่ได้วัดเกณฑ์เรื่องการอ่านและการตรวจออกมาเป็นตัวเลข ส่วนข้อสรุปเรื่องไดนามิกกับสแตติกจากตัวเลขชุดแรกก็อ่อนลงมากเมื่อถูกวัดซ้ำ

คำถามสี่ข้อก่อนเชื่อกราฟเทียบภาษาใบต่อไป

ในเธรดเดียวกันนั้น มีคนยกลิงก์โพสต์ของ Dan Luu ขึ้นมาเป็นหลักฐานยืนยันว่า Python คือภาษาที่ให้ผลิตภาพสูงสุด ทั้งที่คำตอบในโพสต์นั้นเองคือยังไม่รู้ กราฟและลิงก์เดินทางเร็วกว่าเงื่อนไขที่ใช้วัดมันเสมอ เกณฑ์สี่ข้อที่ Dan Luu ใช้ทั้งตรวจงานของคนอื่นและงานของตัวเอง จึงนำมาใช้กับภาพเปรียบเทียบใดๆ ที่คุณพบในกลุ่มได้

1. โจทย์ที่ใช้วัดใหญ่แค่ไหน ประโยคที่เขาใช้ฟันธงคือ โจทย์ที่แก้จบได้ใน 70 โทเคนด้วย J และ 109 โทเคนด้วย Clojure แทบจะเรียกว่าโจทย์ไม่ได้ ช่องว่าง 2.6 เท่าจากงานจิ๋วชุดนี้ไม่ generalize ไปสู่งานจริงสองงานที่ Dan Luu ใช้วัดซ้ำ หากโจทย์ที่ใช้วัดเล็กกว่าไฟล์เดียวในโปรเจกต์ของคุณ ตัวเลขนั้นก็ตอบคำถามของคุณไม่ได้
2. agent เห็นเทสต์ทั้งหมดหรือเปล่า ถ้า agent เห็นเทสต์ทั้งหมดและไม่มี holdout ก็อาจเขียนโค้ดที่ผ่านเทสต์แต่ใช้จริงไม่ได้ Dan Luu ระบุว่า เมื่อไม่บอกว่ามี holdout จะมี agent จำนวนหนึ่งทำคะแนนได้ 100% บนเทสต์ที่มองเห็น ด้วยโค้ดที่เปราะจนไร้ประโยชน์ แต่เมื่อบอกว่ามี holdout คะแนนบนเทสต์ที่มองเห็นจะลดลง ขณะที่คะแนน holdout ดีขึ้นอย่างชัดเจน
3. เงื่อนไขเท่ากันทุกภาษาไหม ใน ai-coding-lang-bench ซึ่งเป็นอีกชุดที่มีผู้อ้างว่าสนับสนุนข้อสรุปเดียวกัน การรันที่เผยแพร่สั่งให้รัน ../../minigit แต่ path นี้ไม่มีอยู่จริง เพราะไฟล์จริงอยู่ที่ ../minigit เทสต์จึงพังและ Rust ไม่ผ่านด้วยเหตุนี้ ส่วนการรัน Go รอบแรกแก้ปัญหาด้วยการ symlink ../minigit ไปยังไฟล์ของตัวเอง ผลคือการรันของทุกภาษาในรอบหลังจากนั้นไปรันไฟล์จาก Go รอบแรกทั้งหมด เมื่อให้คะแนน Rust ใหม่โดยใช้ไฟล์ของตัวเอง Rust ได้คะแนนเต็ม ทฤษฎีที่เจ้าของ eval เสนอว่า Rust กับ Haskell ไม่ผ่านเพราะเป็นภาษายากจึงล้มไปด้วย ชุดเดียวกันนี้ยังมีเทสต์อีกสองตัวที่ if ชั้นในใส่ pass ไว้ทั้งสองสาขา ทำให้เทสต์ผ่านโดยไม่สนค่าที่ตรวจจริง นอกจากนี้ เงื่อนไขของแต่ละภาษาก็ไม่เท่ากันอยู่แล้ว เช่น Rust ที่ไม่มี rustfmt กับ Clippy · Haskell ที่ถูกห้ามใช้ bytestring · Zig ที่ใช้ toolchain เวอร์ชัน 0.10
4. คนวัดตรวจงานตัวเองแค่ไหน ในการทดลองของ Dan Luu เอง ผลของ assembly รอบแรกออกมาดีพอๆ กับภาษาอื่น ซึ่งเขาบอกว่าน่าสนใจมาก แต่ผลนั้นผิด เพราะ agent เขียน C แล้วคอมไพล์เป็น assembly มาส่งแทน อีกรอบหนึ่งได้ผลว่าภาษาไดนามิกแย่กว่าสแตติกอย่างชัดเจน ซึ่งตรงกับอคติของเขาพอดี แต่สาเหตุจริงมาจากการระบุขั้นตอน build ที่คลุมเครือ และภาษาสแตติกบังเอิญเจอปัญหานั้นน้อยกว่า บทเรียนที่เขาสรุปไว้เองคือ หากไม่ระวัง ก็ง่ายมากที่จะได้ผลลัพธ์ที่ผิดแต่ดูน่าเชื่อจนกลายเป็นไวรัล

แล้วเลือกภาษายังไง

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

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

หลีกเลี่ยงภาษาเฉพาะกลุ่มเมื่อจะให้ agent ทำงานหลัก นี่คือสัญญาณที่ปรากฏตรงกันในทั้งสองการทดลอง Dan Luu สรุปว่าสำหรับผู้ใช้ LLM ทั่วไป การเลือกภาษากระแสหลักน่าจะเป็นเดิมพันที่ดีกว่าภาษาเฉพาะกลุ่มที่เขียนโค้ดได้สั้น ส่วนภาษาแปลกๆ อาจคุ้มก็ต่อเมื่อมีงบมากพอจะเทรนหรือ fine-tune โมเดลให้เก่งภาษานั้นโดยเฉพาะ

ข้อสุดท้ายคือวิธีพิสูจน์ที่ถูกที่สุดสำหรับแต่ละทีม Dan Luu ตั้งข้อสังเกตว่าการทดลองแบบนี้เพิ่งเกิดขึ้นได้ เพราะหากต้องจ้างโปรแกรมเมอร์มืออาชีพมาอ่าน RFC ของ zstd แล้วเขียนตัวถอดรหัสหลายภาษาหลายรอบ ต้นทุนจะสูงจนการศึกษาแบบนี้ไม่มีทางเกิดขึ้น ด้วยเหตุผลเดียวกัน แต่ละทีมจึงหยิบงานจริงของตัวเองมาสักงาน รันด้วยสองภาษาที่กำลังชั่งใจ แล้ววัดด้วยเทสต์ที่ agent ไม่เคยเห็น ควบคู่กับเวลาที่คนใช้รีวิวจริงได้ โดยใช้แรงและโทเคนไม่มาก ผลจากงานของทีมเองจะตอบได้ตรงกว่ากราฟใดๆ ที่แชร์กันอยู่ว่าควรเลือกภาษาไหน

---

ที่มา:

• บทความ Why Go is an Ideal Language for AI-Assisted Software Engineering จาก Google Developers Blog
• บทความ What's the best programming language for coding agents? จาก Dan Luu
• บทความ Which programming languages are most token-efficient? จาก Martin Alderson
• เธรด Go is an ideal language for AI-assisted software engineering จาก Hacker News