EGM ผ่านการทดสอบจริงหรือยัง? สองการทดลองอิสระชี้ว่า AI ออกแบบเก่ง แต่โค้ดยังไม่ดีขึ้น

โดย Nokka (นก-กา) | 3 พ.ย. 2026

ผมเขียนบทความแนะนำ Elephant-Goldfish Model หรือ EGM ไปแล้วเมื่อวันที่ 1 พฤศจิกายน 2026 ตอนนั้นผมตอบได้แค่ว่ามันคืออะไรและทำงานอย่างไร [9]

คลิป TikTok ที่คนแชร์กันอีกรอบทำให้ผมกลับไปดูคำถามที่ค้างอยู่ นั่นคือมันได้ผลจริงหรือไม่

รอบนี้ผมเจอรายงานทดสอบจากคนนอกสองชิ้นที่เก็บตัวเลขไว้ละเอียด ชิ้นแรกทดสอบกับงานฟีเจอร์จริงบน Codex ชิ้นที่สองทดสอบความสามารถในการจับข้อบกพร่องของเอกสารออกแบบ

คำตอบที่ได้ไม่ใช่คำโฆษณา และไม่ใช่คำตำหนิจนเกินไป

EGM คืออะไร

Elephant-Goldfish Model หรือ EGM เป็นวิธีทำงานกับ AI ช่วยเขียนโค้ดที่ Google ใช้ภายในองค์กรมาระยะหนึ่ง แล้วเพิ่งเปิดเป็นโอเพนซอร์สเมื่อเดือนตุลาคม 2026 [1]

ตัวคลังโค้ดเปิด Apache 2.0 และมีคนกดดาวบน GitHub เกิน 10,700 ดวง ณ วันที่ 3 พฤศจิกายน 2026 [2] เวอร์ชันแรกที่ติดป้ายเลขคือ v0.1.0 ออกเมื่อ 27 ตุลาคม 2026 [5]

ในกล่องมีชุดคำสั่งและบทบาทของ agent ที่ติดตั้งเป็นปลั๊กอินในเครื่องมือเขียนโค้ด ซึ่งรวมถึง Antigravity, Claude Code, Claude Cowork และ OpenAI Codex ส่วน ChatGPT Work ติดตั้งได้แต่ผู้พัฒนายังบันทึกว่ามีช่องว่างในการตรวจสอบบนคลาวด์ [3][10]

หลักคิดของมันอยู่ในประโยคเดียวคือ "ออกแบบกับช้าง ตรวจกับปลาทอง" [2]

ทำไมต้องมีช้างกับปลาทอง

ปัญหาที่ EGM พยายามแก้คือสิ่งที่ทีมเขียนโค้ดด้วย AI เจอบ่อยในปีที่ผ่านมา

โมเดลภาษาใหญ่ (LLM) ทำงานได้เร็ว แต่ยิ่งบทสนทนายาวขึ้น มันยิ่งจำรายละเอียดช่วงต้นได้แย่ลง และเริ่มคิดเอาเองในจุดที่ไม่มีใครสั่ง

Google เรียกปัญหานี้ว่า session context collapse และเตือนว่าความเร็วที่เพิ่มขึ้นมาพร้อม slop และบั๊กที่เพิ่มตามมา [1]

คำว่า slop ในที่นี้ผมหมายถึงโค้ดที่ดูใช้ได้แต่ไม่ตรงกับสิ่งที่ต้องการ

แนวคิดของ EGM จึงแยกบทบาทออกเป็นสองขั้ว

• ช้าง คือ session ที่ถือบริบทครบ ทั้งประวัติระบบ สถาปัตยกรรม ขอบเขตของ component และเส้นทางที่ผู้ใช้เดินในผลิตภัณฑ์ [3]
• บทบาทของช้างคือตั้งคำถาม ชวนเถียงเรื่อง trade-off และร่างเอกสารออกแบบ โดยไม่เขียนโค้ด
• ปลาทอง คือ subagent ที่เริ่มจากกระดาษเปล่า ไม่เห็นบทสนทนาก่อนหน้า อ่านแค่เอกสารออกแบบกับโค้ดจริงในโปรเจกต์ แล้วหาจุดอ่อน [2]

เหตุผลที่ต้องไม่มีบริบทคือ ถ้าตัวตรวจรู้เหตุผลเดียวกับคนเขียน มันจะมองข้ามจุดบอดเดียวกันไปด้วย [1]

สามระยะการทำงาน

ตัวปลั๊กอินจัดลำดับงานเป็นสามคำสั่งหลัก [1][4]

1. /egm-brainstorm  ตั้งโจทย์ให้ชัดก่อน ยังไม่เขียนโค้ด
2. /egm-draft       ร่างเอกสารออกแบบเป็น Markdown
3. /egm-review      ให้ฝูงปลาทองตรวจแบบเป็นปฏิปักษ์

บล็อกของ Google นับการตรวจเป็นสามด่าน แต่ตัวปลั๊กอินที่ปล่อยจริงรันห้าด่าน [1][8]

ในระยะแรกมีกฎข้อหนึ่งที่ Google เน้นคือ "ห้ามเขียนโค้ด" ผู้ใช้กับ AI จะคุยกันเรื่องปัญหา ทางเลือก และข้อจำกัดก่อน

ระยะที่สองได้ไฟล์ Markdown ที่ต้องมีครบสี่เรื่อง คือ นิยามปัญหา แผนเทคนิค ทางเลือกที่พิจารณาแล้ว และแผนลงมือที่ระบุชื่อไฟล์ที่จะแก้จริง [1]

ระยะที่สามคือหัวใจของวิธีนี้

Goldfish Protocol ตรวจสามด่านในบล็อก ห้าด่านในตัวจริง

ด่านแรกคือ Comprehension Check ปลาทองต้องอ่านเอกสารทั้งหมดแล้วอธิบายกลับว่าแผนคืออะไร ถ้าอธิบายไม่ได้แปลว่าเอกสารยังกำกวม [1]

ด่านที่สองคือ Antagonistic Review ปลาทองหลายตัวรับบทเป็นผู้ตรวจสายโหด หา edge case, dependency ที่ซ่อนอยู่ และช่องโหว่ทางตรรกะ แล้วส่งคำวิจารณ์กลับให้ช้างแก้ [1]

ด่านที่สามคือ Implementation Readiness Check ปลาทองตัวสุดท้ายทำหน้าที่เป็นประตูอนุมัติ ตรวจว่าข้อมูลที่ต้องใช้เขียนโค้ดครบไหม เช่น path ของไฟล์ โครงสร้างข้อมูล และ signature ของฟังก์ชัน [1]

จุดที่ผมชอบคือคนยังต้องเป็นคนตัดสิน architectural trade-off และอนุมัติเอกสารก่อนลงมือ Google เขียนไว้ตรง ๆ ว่าในที่สุดแล้วดุลยพินิจของมนุษย์คือชิ้นงานที่สำคัญที่สุด [1]

ผลทดสอบชิ้นแรก: เอกสารดี แต่ยังไม่ดีกว่าวิธีที่ถูกกว่า

ผู้ทดสอบอิสระที่ใช้บัญชีชื่อ meabs ทำ pilot ทดสอบ EGM กับงานฟีเจอร์จริงเมื่อ 23 ตุลาคม 2026 บน Codex [6]

ผู้ทำรายงานระบุว่าคนที่ทำหน้าที่อนุมัติทุกช่วงคือ agent ไม่ใช่มนุษย์ เป็นข้อจำกัดที่ยอมรับไว้เอง [6]

งานที่ใช้คือระบบโค้ดส่วนลดที่แตะหลายส่วนของระบบ พร้อมชุดทดสอบซ่อน 16 ข้อ

ผลของ pilot ออกมาดังนี้ [6]

• Codex เปล่า ๆ รันแรกผ่าน 4 ข้อ รันที่สองผ่าน 2 ข้อ จากทั้งหมด 16 ข้อ ใช้เวลา 62 ถึง 91 วินาที
• EGM ผ่าน 3 จาก 16 และ 1 จาก 16 ข้อ ใช้เวลา 419 ถึง 550 วินาที และจ่ายเงิน 0.216 ถึง 0.294 ดอลลาร์ เทียบกับ 0.030 ถึง 0.032 ดอลลาร์ของ baseline

น่าสนใจว่าตัวรีวิวของ EGM จับปัญหาจริงได้หลายข้อ เช่น กฎส่วนลดเดิมที่ยังค้างอยู่และวันหมดอายุของโค้ด และบริการหมวดหมู่ที่มีอยู่แล้วซึ่งควรนำกลับมาใช้ [6]

แต่ตอนสร้างโค้ดจริง ทั้งสองรอบเขียนได้แค่โครง แล้วบอกว่างานเสร็จและโปรเจกต์คอมไพล์ผ่าน ทั้งที่ยังไม่ได้แตะส่วนคำนวณราคาในตะกร้า [6]

ผู้ทำรายงานสรุปตรง ๆ ว่าคุณภาพของเอกสารไม่ได้ส่งต่อไปถึงโค้ด แม้เอกสารจะยาว 405 และ 132 บรรทัดและระบุไฟล์ที่จะแก้ครบ [6]

สอง follow-up ที่ทำให้ภาพซับซ้อนขึ้น

รายงานเดียวกันมีอีกสองภาคต่อที่ผมคิดว่าสำคัญกว่าตัว pilot

Follow-up 1 ทดสอบตอนสร้างโค้ดด้วย effort ระดับกลาง (medium effort) ทั้ง EGM และ Codex เปล่าได้ 4 จาก 16 ข้อเท่ากัน แต่ Codex เปล่าใช้เงินเฉลี่ย 0.10 ดอลลาร์ต่อรอบ ขณะที่ EGM ใช้ 0.43 ดอลลาร์ [6]

จุดที่ต้องบอกให้ครบคือ follow-up นี้แก้ปัญหาที่ pilot เจอได้จริง ที่ระดับกลาง build เขียนฟีเจอร์ได้ครบราว 600 ถึง 650 บรรทัดใน 19 ถึง 21 ไฟล์ แต่คะแนนยังได้ 4 จาก 16 เท่ากับ Codex เปล่า เพราะทุกรันใช้ชื่อบรรทัดส่วนลดเดิมของระบบ ซึ่งเป็นจุดที่ทุกแขนพลาดเหมือนกัน [6]

Follow-up 2 ให้เอเจนต์ Claude ตัวใหม่ (Opus 5.5) รับบทเป็นวิศวกรผู้อนุมัติ ผลคือแขน EGM ได้ 16, 5 และ 16 ข้อ ส่วนแขน plan-first ได้ 6, 13 และ 16 ข้อ จากคะแนนเต็ม 16 เท่ากัน [6]

ต้นทางสรุปเองว่า EGM ไม่ได้ให้ผลดีขึ้นอย่างวัดได้เมื่อเทียบกับ plan-first แต่แลกมาด้วยต้นทุนราวห้าเท่า [6]

ผมอ่านสองท่านี้ว่า EGM ไม่ได้ไร้ค่า แต่มันไม่ได้ชนะวิธีการที่ง่ายกว่า และตัวชี้ขาดคะแนนไม่ใช่ปลาทอง

ใน follow-up 2 สิ่งที่ตัดสินว่าผ่านหรือไม่ผ่านคือผู้อนุมัติสั่งให้เอกสารระบุชื่อบรรทัดในยอดรวม (code discount) ให้ตรงกับที่โจทย์ต้องการ ไม่มีปลาทองตัวไหนยกประเด็นนี้ขึ้นมาเลย [6]

ผลทดสอบชิ้นที่สอง: ปลาทองทำคะแนนสูงสุด และแพงที่สุด

สถาบันวิจัย Claude Code ในญี่ปุ่นทำการทดลองอีกแบบที่เผยแพร่ปลายตุลาคม 2026 คือสร้างเอกสารออกแบบของงานบัญชีภาษีที่จงใจฝังข้อบกพร่องไว้ 10 จุด แล้วให้ AI ตรวจด้วยวิธีต่างกันห้าแบบ [7]

ผลคะแนนเต็ม 10 ออกมาดังนี้ [7]

• ตรวจในบทสนทนาเดิมที่ AI รู้ที่มาที่ไป ได้ 9.5 ถึง 10 คะแนน ต้นทุนราว 0.04 ดอลลาร์ ใช้เวลา 32 ถึง 39 วินาที
• เปิดบทสนทนาใหม่ที่ AI เห็นแค่เอกสาร ได้ 7 คะแนน ต้นทุน 0.06 ดอลลาร์
• ปลาทองแบบ subagent ที่เขียนเอง ได้ 6.5 ถึง 7 คะแนน ต้นทุน 0.08 ดอลลาร์
• ปลาทองที่เติมบรรทัดบังคับให้เปิดไฟล์อ้างอิง ได้ 7.5 ถึง 8 คะแนน ต้นทุน 0.09 ถึง 0.10 ดอลลาร์
• EGM ครบห้าด่าน ได้ 10 คะแนน ต้นทุน 0.82 ดอลลาร์ ใช้เวลา 3 นาที 54 วินาที

แปลว่า EGM ทำคะแนนสูงสุดเท่าที่งานทดสอบนี้วัดได้ คือเท่ากับแขนบทสนทนาเดิมที่ได้ถึง 10 แต่ถ้านับเฉพาะคำวิจารณ์ที่ปลาทองเขียนเอง ไม่นับตารางเทียบที่ช้างแนบท้ายเอกสาร คะแนนจะเหลือราว 8 [7]

ต้นทางกำกับจุดนี้ไว้เองว่าในสิบคะแนนนั้น มีข้อ 1, 3 และ 5 มาจากตารางของช้าง ซึ่งไม่ใช่คำวิจารณ์ของรีวิวเวอร์ และข้อ 5 เป็นเพียงการพูดถึงในระดับทั่วไป [7]

สิ่งที่ปลาทองทำได้ดีคือจับจุดที่คนอ่านครั้งแรกจะสะดุด เช่น หน้าที่การรักษาความลับ และความหมายของคำว่า "งวดเดือนพฤศจิกายน" [7]

สิ่งที่ปลาทองทำไม่ได้คือจับจุดที่ต้องรู้จากบทสนทนา เช่น ข้อมูลลูกค้าสองรายที่อยู่ในสมุดบัญชีกระดาษ หรือการอนุมัติของหัวหน้าสำนักงาน ทั้งการเปิดบทสนทนาใหม่และการใช้ปลาทอง รวมถึงปลาทองทั้งเก้าตัวในแขน EGM ต่างก็มองไม่เห็นจุดเหล่านี้ [7]

ราคาที่ต้องจ่ายคือ 0.82 ดอลลาร์ต่อครั้ง หรือราว 14 เท่าของการเปิดบทสนทนาใหม่มาตรวจเอง และใช้เวลานานกว่าราว 4 นาทีต่อครั้ง [7]

แล้วสรุปว่ามันดีไหม

จากหลักฐานที่มีตอนนี้ ผมอ่านว่า EGM แก้ปัญหาถูกจุด แต่ยังพิสูจน์ผลลัพธ์ไม่ได้

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

ยังพิสูจน์ไม่ได้เพราะทั้งสองการทดสอบข้างต้นเป็น sample เล็ก ไม่มีการวัดผลแบบควบคุมที่เพียงพอ และ Google เองยังไม่ได้เผยตัวเลขว่าช่วยลดบั๊กหรือเร็วขึ้นกี่เปอร์เซ็นต์

ที่ Google พูดได้คือมีวิศวกรหลายพันคนใช้ทุกวันในงานที่ขึ้น production จริง [1][3] ซึ่งเป็นข้ออ้างที่น่าเชื่อแต่ตรวจสอบจากภายนอกไม่ได้

ใครควรลอง ใครยังไม่ควร

EGM เหมาะกับงานที่ต้องตัดสินใจเชิงสถาปัตยกรรมก่อนลงมือ ตัวอย่างเช่น ฟีเจอร์ใหม่ที่แตะหลาย module หรือระบบที่ทีมยังไม่เห็นตรงกันว่าควรทำอย่างไร [2]

ไม่เหมาะกับงานเล็กที่ชัดอยู่แล้ว เอกสารของ EGM เองก็เขียนว่าแก้บั๊กง่าย ๆ ให้ใช้วิธีปกติ ไม่ต้องลากกระบวนการทั้งชุด [2]

ค่าใช้จ่ายเป็นเรื่องจริง ทั้งในรูป token ที่ใช้มากขึ้นหลายเท่า และในรูปเวลาของคนที่ต้องนั่งอนุมัติทุกช่วง [6][7]

ถ้าทีมคุณมีปัญหาว่า AI เขียนโค้ดเร็วแต่ต้องแก้ซ้ำบ่อย EGM น่าลองในสเกลเล็กก่อนหนึ่งฟีเจอร์ แล้ววัดว่าเอกสารที่ได้ช่วยลดรอบแก้จริงหรือไม่

ถ้าปัญหาของทีมคือส่งงานช้าเพราะคนรีวิวไม่ทัน EGM จะยิ่งทำให้ช้าลง เพราะมันเพิ่มขั้นตอนที่ต้องมีคนตัดสิน

อีกมุมที่ควรรู้ก่อนเลือกเครื่องมือ

อีกมุมที่ควรรู้คือ EGM ไม่ใช่วิธีเดียวในตลาด มีการเปรียบเทียบกับ GitHub Spec Kit และ OpenSpec ว่าทั้งสามแก้ปัญหาเดียวกันแต่ให้น้ำหนักต่างกัน EGM เน้นการตรวจแบบไม่มีบริบท ส่วนอีกสองตัวเน้นโครงเอกสารและการเปลี่ยน spec ให้เป็นงานย่อย [8]

ถ้าจะลองสัปดาห์นี้

ผมสรุปเส้นทางที่สั้นที่สุดไว้แบบนี้

1. เลือกฟีเจอร์หนึ่งที่ต้องคุยกันก่อนลงมือ
2. ติดตั้งปลั๊กอินในเครื่องมือที่ทีมใช้อยู่
3. รัน brainstorm แล้วห้ามให้ AI เขียนโค้ดในขั้นนี้
4. ร่างเอกสารด้วย /egm-draft แล้วอ่านเองก่อนส่งตรวจ
5. รัน /egm-review และจดว่าปลาทองจับอะไรได้บ้าง
6. วัดผลด้วยตัวเลขของทีม เช่น จำนวนรอบแก้ หรือจำนวนบั๊กที่หลุด

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

สิ่งที่ผมยังไม่เห็น

สามข้อนี้ยังไม่มีคำตอบจากแหล่งที่ผมตรวจ

• ยังไม่มีการเปรียบเทียบที่ใหญ่พอจะสรุปว่า EGM ให้โค้ดดีกว่า plan-first อย่างมีนัยสำคัญ เพราะ pilot ที่มีใช้เพียงไม่กี่รอบต่อแขน [6]
• ไม่มีตัวเลขจาก Google ว่าช่วยลดอะไรได้เท่าไร นอกจากการบอกว่ามีคนใช้จำนวนมาก [1]
• ยังไม่มีรีวิวระยะยาวจากทีมที่ใช้จริงเกินหนึ่งเดือน

ทั้งหมดนี้ทำให้ EGM น่าสนใจในฐานะวิธีคิด มากกว่าในฐานะเครื่องมือที่พิสูจน์แล้วว่าคุ้ม

แหล่งอ้างอิง

[1] Google Open Source Blog · Introducing the Elephant-Goldfish Model plugin (22 ต.ค. 2026) · https://opensource.googleblog.com/2026/10/introducing-elephant-goldfish-model-plugin.html
[2] GitHub · google/elephant-goldfish-model README (ต.ค. 2026 · Apache-2.0) · https://github.com/google/elephant-goldfish-model
[3] egm.dev · Elephant-Goldfish Model official site (ต.ค. 2026) · https://egm.dev/
[4] GitHub · docs/getting_started.md (ต.ค. 2026) · https://github.com/google/elephant-goldfish-model/blob/main/docs/getting_started.md
[5] GitHub Releases · EGM v0.1.0 (27 ต.ค. 2026) · https://github.com/google/elephant-goldfish-model/releases
[6] meabs/experiments · Elephant-Goldfish Model on a feature task: pilot report (23 ต.ค. 2026) · https://github.com/meabs/experiments/blob/45265e75c3219d3b49bac9e46dd11e523e1bf396/2026-10-egm-pilot/REPORT.md
[7] Claude Code Lab (ญี่ปุ่น) · บททดสอบ EGM ด้วยเอกสารออกแบบที่มีข้อบกพร่อง 10 จุด (ต.ค. 2026) · https://www.claude-code-lab.com/blog/claude-code-review-egm-goldfish
[8] Stackness · Elephant Goldfish model vs Spec Kit and OpenSpec (ต.ค. 2026) · https://stackness.dev/blog/elephant-goldfish-model-spec-driven-development-vs-spec-kit-openspec
[9] Nokka · Elephant-Goldfish Model คืออะไร? (1 พ.ย. 2026) · https://dev.to/sarantoon/elephant-goldfish-model-khuueaair-withiithii-google-aih-ai-raangaephnknekhiiynokhd-aelwaih-ai-15bc
[10] GitHub · docs/harnesses.md · harness ที่รองรับและช่องว่างการตรวจสอบ (ต.ค. 2026) · https://github.com/google/elephant-goldfish-model/blob/main/docs/harnesses.md

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)