elephant-goldfish-model

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) · opensource.googleblog.com [2] GitHub · google/elephant-goldfish-model README (ต.ค. 2026 · Apache-2.0) · google/elephant-goldfish-model [3] egm.dev · Elephant-Goldfish Model official site (ต.ค. 2026) · egm.dev [4] GitHub · docs/getting_started.md (ต.ค. 2026) · github.com/google/elephant-goldfish-model/blob/ma… [5] GitHub Releases · EGM v0.1.0 (27 ต.ค. 2026) · github.com/google/elephant-goldfish-model/releases [6] meabs/experiments · Elephant-Goldfish Model on a feature task: pilot report (23 ต.ค. 2026) · github.com/meabs/experiments/blob/45265e75c3219d3… [7] Claude Code Lab (ญี่ปุ่น) · บททดสอบ EGM ด้วยเอกสารออกแบบที่มีข้อบกพร่อง 10 จุด (ต.ค. 2026) · claude-code-lab.com [8] Stackness · Elephant Goldfish model vs Spec Kit and OpenSpec (ต.ค. 2026) · stackness.dev [9] Nokka · Elephant-Goldfish Model คืออะไร? (1 พ.ย. 2026) · dev.to [10] GitHub · docs/harnesses.md · harness ที่รองรับและช่องว่างการตรวจสอบ (ต.ค. 2026) · github.com/google/elephant-goldfish-model/blob/ma… บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

Google has an interesting workflow for AI coding: Elephant drafts with full context. Goldfish reviews with fresh context. You approve before coding. A clever way to catch AI's blind spots. google/elephant-goldfish-model

The neat idea in Google's Elephant-Goldfish agent: a deep-context agent drafts your spec, then zero-context subagents review it. If a fresh agent with no memory gets confused, your spec is missing assumptions. google/elephant-goldfish-model t.co

#Google published open-source skills for designing and reviewing software with AI agents google/elephant-goldfish-model t.co

# AIに任せるなんてとんでもない！と言われている人達へ — 「AIを信じなくていい仕組み」から始める 「最先端のAI企業のエンジニアは、もうコードを書いていないらしい」「プロンプトを書く時代は終わった」「AIエージェントがひと晩でアプリを作った」——X や YouTube には、こんな話が毎日のように流れてきます。一方、職場では「AIに全部やらせるなんて危ない」という空気がある。どちらを信じればいいのか分からないまま、結局チャット欄にコードを貼っては貼り返す毎日に戻っている。この記事は、そんな人に向けて書きました。 先に結論を書きます。大事なのは、AIをどこまで信じるかではありません。AIを信じなくても困らない仕組みを、先に用意することです。 流れてくる話に、映っていないもの 派手な事例の多くは、たぶん本当です。ただ、記事や動画に映りやすいのは「AIが何をしたか」で、映りにくいのは「それが正しいと、誰がどう確かめたか」です。 自動化がうまくいっているチームは、たいていこの地味な部分を作り込んでいます。 テストが通らなければ、マージできない AIが触れてはいけないファイルは、そもそもAIから見えない AIの「修正しました」という報告は、証拠として扱わない 実際、派手な成果の正体は、この地味な部分だったという報告がいくつも出ています。OpenAI のあるチームは、人間が直接コードを書かずに、約5か月で100万行規模のソフトウェアをAIに作らせたと報告しました。ただ、その報告の大半は「AIに何を書かせたか」ではなく、「AIを迷わせない仕組み」の話です。短く保った指示ファイルや、間違いを指摘するだけでなく直し方まで教えてくれる検査ツールといったものです。LangChain は、AIのモデルを一切変えずに、周りの仕組みだけを作り直して、ベンチマークの順位を上位30位の圏外から上位5位まで上げています（2026年2月の発表時点）。 この部分を飛ばして真似ると、うまくいきません。そして、うまくいかなかった経験が「やっぱりAIに任せるのは危ない」という空気を強めます。派手な話も、慎重な声も、半分しか映していないのです。 人間が毎回見ていても、16回やり直した 私自身の失敗談を書きます。縦書きの本を組むツールを、AIとチャットしながら作っていたときのことです。図がページの境目で切れる、章がページの途中から始まる——こうしたレイアウト崩れを直すのに、20回以上のやり取りが必要になりました。 手を抜いていたわけではありません。毎回スクリーンショットを撮ってAIに見せ、直ったら自分の目で確かめていました。1回の確認は5分ほどです。それでも、20回以上のやり取りのうち16回は、直ったはずのものが直っていなかったためのやり直しでした。「直ったと思ったら、別の場所が崩れていた」「A5では直っていたのに、ほかの用紙サイズでは崩れたままだった」。このツールは用紙4種類×縦書き・横書きの8通りで見た目が変わるので、5分の目視ではとても見切れなかったのです。 つまり、人間がループの中にいても、品質は守られていませんでした。足りなかったのは人間の注意力ではありません。「直ったかどうか」を測る物差しです。 信じるのではなく、信じなくていいようにする そこで、物差しをプログラムで作りました。「どの図もページの境目をまたいでいない」「どの章もページの頭から始まる」を、ブラウザで実際に組んだ結果から測り、だめなら失敗で終わるテストです。8通りすべてに掛けても、人間の手間は増えません。 話はここで終わりません。このテスト自体にも穴がありました。わざと壊したツールに掛けてみたところ、横書きの崩れを一つも検出できていなかったのです。それでもテストは「合格」を返し続けていました。壊した版で試していなければ、何も測っていない物差しを信じていたことになります。 ここから言えるのは、「AIを信じるか、人間が全部見るか」の二択ではない、ということです。 合否を決める物差しを用意する その物差しが本当に測れているかも、わざと壊して確かめる この2つがあれば、AIの出力を一つひとつ信じて確かめる必要はなくなります。物差しが通さなければ、マージされないだけです。ただし物差しも完全ではありません。何を測っていて、何をまだ測っていないかを把握しておくのは、人間の仕事として残ります。 会社で「AIに全部やらせるのは危ない」と言われたら 企業では「中身を理解していないコードを本番に出すのは、説明責任の放棄だ」という声がよく上がります。この心配はもっともです。ただ、少し考えると、私たちはこれまでも、依存しているライブラリのコードを1行ずつ読んできたわけではありません。採用実績、脆弱性の監視、テストや監査の記録といった「信頼してよい根拠」を示すことで、説明責任を果たしてきました。 AIが書いたコードも同じです。人間がすべての行を読むのをやめる代わりに、人間が読むものを変えます。 仕様 —— 何を満たせば完成なのか テスト —— 仕様を正しく写しているか 間違えると被害が大きい箇所の差分 —— 認証、決済、データの削除など 差分をどこまで読むかは、一律に決めなくてかまいません。間違えたときの被害の大きさで変えます。画面の文言の修正ならテストの結果で十分ですし、認証や決済に触れる変更なら、人間が行単位で読みます。 それ以外は、テストの結果と記録で示します。「全部読みました」と言うより、検証できる根拠を示せる分、説明としてはむしろ強くなります。「フル自動は悪」と「全部任せればいい」の間には、この現実的な道があります。 明日からできる、小さな4歩 いきなり全部を自動化する必要はありません。コツは、注意書きを増やすのではなく、修正を「お願い」から「仕組み」へ一段ずつ下ろしていくことです。プロンプトや指示ファイルに書いた注意は、会話が長くなったりモデルが替わったりすると、いつの間にか埋もれます。テストや設定にしたものは、消すまで効き続けます。 4つも多いと感じたら、最初は一つだけでかまいません。次にAIに不具合の修正を頼むとき、直す前に、その不具合を再現するテストを書かせ、それが落ちるところを見せてもらってください。直したあとに同じテストが通れば、「直しました」を言葉ではなく結果で確かめたことになります。 そこから先は、次の4つへ広げていきます。どれも数日で試せて、どれも「AIを信じる」必要がありません。 本物のパスワードや鍵を、AIの作業場所に置かない —— 「.env を読まないで」とお願いするのではなく、そもそもファイルが存在しない状態にします。お願いは破られることがありますが、無いものは読めません。 「直しました」を信じず、CI の結果で判断する —— テストが通らなければマージできないよう、リポジトリの設定（ルールセットやブランチ保護）で縛ります。管理者も含めて例外を許さず、AIの使うアカウントには設定を変える権限を渡さなければ、AIにも人間にも抜け道がなくなります。 AIが一度ハマった失敗は、テストを1本書いて残す —— 注意書きを増やすより確実に、同じ失敗を防げます。そしてそのテストは、わざと壊した版で落ちることを確かめてから使います。 レビューの重心を、コードからテストと仕様へ移す —— テストや仕様の変更には人間の承認が必要になるよう設定し、AIがテストを書き換えて「合格」させる抜け道を塞ぎます。 この4つが揃うと、AIに任せる範囲を少しずつ広げても怖くなくなります。任せる範囲を決めるのは、AIの賢さではなく、物差しの確かさだからです。 もっと知りたい人へ この記事の背景にある考え方は、論文「自律型AIエージェント時代におけるソフトウェア工学の再定義」にまとめました。上の4歩をそのまま始められる雛形（エージェントへの指示ファイル AGENTS.md、仕様のテンプレート、CI とレビューの設定など）と、記事に出てきた組版ツール、そして「物差しの物差し」まで含めたテストも、同じリポジトリで公開しています。 リポジトリ：hamatz/agent-harness-kit 論文：github.com/hamatz/agent-harness-kit/blob/main/doc… リポジトリを取ってきて npm install のあと npm run demo を実行すると、わざと壊した組版ツールが検査で落ち、壊していない版が通る様子を数分で見られます。まずはそこから触ってみてください。 設計の段階については、Google が公開している Elephant-Goldfish Model というプラグインが参考になります。設計書をAIと一緒に書き、それまでの会話を知らない別のAIに査読させる仕組みです。このキットは、その後ろの「実装して、正しいと確かめる」段階を受け持つように作っています。 AIをどこまで信じるかで悩むのは、もうやめていいと思います。信じなくていい仕組みを、一つずつ足していきましょう。

Elephant-Goldfish Model คืออะไร? วิธีที่ Google ให้ AI ร่างแผนก่อนเขียนโค้ด แล้วให้ AI อีกตัวที่จำอะไรไม่ได้ตรวจ โดย Nokka (นก-กา) | 1 พ.ย. 2026 !ภาพประกอบ: โต๊ะทำงานกลางคืน มีรูปปั้นช้างตัวเล็กวางข้างแล็ปท็อปที่จอแสดงบรรทัดเอกสาร และโหลปลาทองที่มีปลาตัวเดียวว่ายอยู่ ทวีตภาษาอาหรับจากบัญชี @EngMoElgaraihy เมื่อปลายเดือน ต.ค. 2026 [1] เล่าเครื่องมือตัวหนึ่งที่เขาเรียกว่า "อาวุธลับ" ของวิศวกร Google หลายพันคน ใช้กันไม่ให้ AI เขียนโค้ดเร็วแต่เต็มไปด้วยข้อผิดพลาด ชื่อเครื่องมือคือ Elephant-Goldfish Model หรือ EGM และมีเว็บไซต์ทางการที่ egm.dev [7] ผมเปิดรีโปจริง อ่าน README อ่านเอกสารการติดตั้ง และนับรายการที่ค้างในระบบ issue เพื่อแยกว่าอะไรคือกลไกจริง อะไรคือคำโปรย EGM คืออะไร google/elephant-goldfish-model เป็นชุดสกิลโอเพนซอร์สสำหรับออกแบบและรีวิวซอฟต์แวร์ด้วยเอเจนต์ AI ภายใต้สัญญาอนุญาต Apache 2.0 [2] [3] แนวคิดย่อสั้นคือ ออกแบบกับช้าง รีวิวกับปลาทอง [3] - ช้าง คือเอเจนต์ที่ถือบริบทของโปรเจกต์ทั้งหมด คุยกับคุณแล้วร่างเอกสารออกมา - ปลาทอง คือเอเจนต์ตัวใหม่ที่ไม่มีความจำของการคุยก่อนหน้า ถูกปล่อยมาอ่านเฉพาะเอกสารกับไฟล์อ้างอิง - คุณ เป็นคนตัดสินใจเรื่องการแลกเปลี่ยนเชิงสถาปัตยกรรมและอนุมัติแผนก่อนลงมือเขียนโค้ด ข้อมูลรีโป ณ 1 พ.ย. 2026 [2] - 7,923 ดาว และ 465 ฟอร์ก - Apache 2.0 - สร้าง 13 ก.ย. 2026 และ push ล่าสุด 30 ต.ค. 2026 - รายการเปิดค้าง 62 รายการ แยกเป็น issue 40 และ pull request 22 - รายการใน git tree 316 รายการ แยกเป็นไฟล์จริง 227 ไฟล์ที่เหลือเป็นโฟลเดอร์ ทำไมต้องมีปลาทอง เหตุผลที่ผู้เขียนรีโปให้ไว้ สั้นและตรงประเด็น ถ้าให้โมเดลตัวเดิมที่เพิ่งคุยกับคุณมาร่วมชั่วโมงร่างแผน แล้วให้ตัวเดิมนั้นตรวจแผนของตัวเอง มันจะจำเหตุผลที่มันเพิ่งใช้ไปแล้ว และมีแนวโน้มเห็นด้วยกับตัวเอง [3] การเริ่มเซสชันใหม่ที่ไม่มีความจำเดิม ทำให้ผู้ตรวจไม่มี Bias ติดมา มันเห็นแค่สิ่งที่เขียนไว้ในเอกสาร ถ้าอ่านแล้วยังไม่เข้าใจ นั่นคือสัญญาณว่าเอกสารยังไม่ชัด [3] เจ็ดสกิลที่ใช้แยกกันได้ ใช้เฉพาะตัวที่ตรงกับช่วงงาน รีโปไม่ได้บังคับให้ใช้ครบทั้งกระบวนการ คุณหยิบอันที่ต้องการได้ [3] egm-brainstorm ทดสอบไอเดียและเขียน concept brief egm-draft เปลี่ยน brief เป็นเอกสารออกแบบ egm-resolve คุยกับผลรีวิวและตกลงว่าจะแก้อะไร egm-review รีวิวแบบเปิดเอเจนต์ใหม่ห้าด่าน egm-review-loop เรียกกลุ่มผู้ตรวจที่ตั้งค่าไว้สำหรับงานหนึ่ง ๆ egm-bootstrap สร้างหรืออัปเดตเอกสารของโค้ดเดิม egm-drift-report เทียบเอกสารในรีโปกับโค้ดปัจจุบัน ตัวอย่างใน README ใช้สามคำสั่งนี้เป็นหลัก คือ /egm-brainstorm, /egm-draft และ /egm-review [3] ใน Antigravity และ Claude Code ต้องเติม prefix เป็น /egm:egm-brainstorm เสมอ เพราะบางเวอร์ชันของ agy ไม่เติมให้อัตโนมัติ [3] ห้าด่านของการรีวิว ผมเปิดไฟล์สกิลนับเอง ทวีตเล่าเป็นห้าขั้น แต่เมื่อเปิดไฟล์ skills/egm-review/SKILL.md ดูจริง ชื่อด่านทั้งห้าเรียงอย่างนี้ [5] Stage 5 Initial Zoom Out Review Stage 6 Comprehension Test Stage 7 Critic Review (egm-design, egm-structural, egm-style) Stage 8 Intermediate Zoom Out Review Stage 9 Implementation Readiness Test ด่านที่สองคือ Comprehension Test ตรงกับที่ทวีตเล่าว่าให้ปลาทองอธิบายแผนกลับมา ถ้าอธิบายไม่ได้แปลว่าเอกสารกำกวม [3] [5] ด่านสุดท้ายคือ Implementation Readiness ซึ่งดูว่าเส้นทางไฟล์และ signature ชัดพอจะลงมือหรือยัง ตรงกับที่ทวีตเรียกว่า "ไฟเขียว" [5] รันได้บนอะไร ไม่ใช่แค่ Antigravity ทวีตเขียนว่าเครื่องมือนี้ทำงานใน Antigravity และจะรองรับสภาพแวดล้อมอื่นเร็ว ๆ นี้ ตรงนี้ข้อมูลล้าสมัย เอกสาร docs/harnesses.md ระบุว่ารองรับหลายที่แล้ว [4] Antigravity CLI / App / ส่วนขยาย VS Code Claude Code Claude Cowork Codex ChatGPT (แบบอัปโหลดปลั๊กอิน) omp แต่มีรายละเอียดที่คนจะติดตั้งควรรู้ก่อน - Antigravity IDE แบบเดี่ยวไม่รองรับ เพราะไม่มีเครื่องมือ invoke_subagent ที่ให้เอเจนต์ใหม่ทำงานแยกบริบท ซึ่งเป็นหัวใจของปลาทอง [4] - Codex ไม่มี reviewer persona แบบมีชื่อ แต่มีเครื่องมือ spawn/wait ในตัว เอกสารจึงบอกให้ตั้ง fork_context: false ทุกครั้งที่ปล่อยปลาทอง เพื่อไม่ให้มันรับบริบทเดิมมา [11] - ถ้าติดตั้งแบบคัดลอกแค่โฟลเดอร์ skills/ ระบบจะพัง เพราะสกิลอ่าน agents/ และ resources/ ตอนรัน ต้องติดตั้งปลั๊กอินทั้งชุด [4] สองประโยคที่ต้องอ่านให้ครบ ประโยคแรกคือ "Thousands of Googlers use this plugin every day to ship production Google code" ซึ่งไม่ได้มีแค่บน README แต่ปรากฏในประกาศทางการบนบล็อกโอเพนซอร์สของ Google ลงวันที่ 22 ต.ค. 2026 เขียนโดย Brian Suchy, Jim Quinn, Elise Ewing, Oliver Newth และ Dave Rensin [10] สิ่งที่ยังจริงคือมันไม่ได้ให้ตัวเลขที่ตรวจได้ ไม่มีงานสำรวจจำนวนผู้ใช้ที่ตรวจสอบได้ และไม่มีงานวัดผลจาก Google เอง ผมจึงอ่านเป็นคำอ้างของผู้พัฒนา ไม่ใช่สถิติ ประโยคที่สองอยู่ท้าย README ว่า "This is not an officially supported Google product" [3] แปลว่าโค้ดอยู่ใต้ org ของ Google และเปิดให้ใช้จริง แต่ไม่ใช่ผลิตภัณฑ์ที่ Google รับประกันการซัพพอร์ต ถ้าคุณเอาไปใช้ในทีม ต้องเข้าใจความต่างนี้ รีโปมีไฟล์ TESTING.md สำหรับรันยูนิตเทสต์ของชุดสกิลเอง ซึ่งวัดความถูกต้องของปลั๊กอิน ไม่ได้วัดว่าซอฟต์แวร์ที่สร้างด้วย EGM ดีขึ้นแค่ไหน [6] สองการทดลองอิสระที่ผมเจอ และผลออกมาคนละทาง ผมค้นหาต่อหลังอ่าน README และเจอการทดลองที่เผยแพร่ก่อนวันเขียนบทสองชิ้น ชิ้นแรก เผยแพร่ 23 ต.ค. 2026 บนเว็บ programmingtheloop.com ทดสอบกับฟีเจอร์ยากหนึ่งชิ้น แบ่งเป็นสองแขน แขนละสามรอบ วัดด้วย hidden test 16 ข้อ [8] ทั้งสองแขนให้ AI รับบทผู้อนุมัติแทนคน เพื่อแยกว่า gain มาจาก EGM หรือมาจากตัวผู้อนุมัติ และตัวเลขต้นทุนนับเฉพาะค่า Codex ไม่รวมค่าใช้จ่ายของผู้อนุมัติ [8] ผลคือแผนที่ผ่าน EGM ได้ค่าเฉลี่ย 12.3 จาก 16 ส่วนแผนธรรมดาได้ 11.7 จาก 16 และต้นทุนต่อรอบอยู่ที่ 0.95 ดอลลาร์กับ 0.19 ดอลลาร์ [8] ผู้เขียนสรุปเองว่า "EGM ไม่ได้เพิ่มอะไรที่วัดได้เหนือแผนธรรมดา แต่แลกมาด้วยต้นทุนราวห้าเท่า" และกำกับข้อจำกัดว่าทดสอบฟีเจอร์เดียว สามรอบต่อแขน ผลต่างแค่ข้อหรือสองข้อไม่มีความหมาย [8] ชิ้นที่สอง เผยแพร่ในวันเดียวกันบน dev.to ผู้เขียนลองกับมินิโปรเจกต์จริง ใช้ Claude Code 2.1.278 กับ EGM 0.1.0 ใช้เวลารีวิว 14 นาที ได้ข้อสังเกต 26 ข้อ แยกเป็นตัวบล็อก 9 ข้อ เรื่องใหญ่ 9 ข้อ เรื่องเล็ก 8 ข้อ [9] แต่ผู้เขียนก็เขียนเองว่าปลาทอง ตัดสินผิด 2 ครั้ง และมองข้ามบั๊กไป 2 ตัว ต้นทุนอยู่ที่ประมาณ 3.40 ดอลลาร์ที่ราคา API ของ Claude Sonnet 5 [9] อ่านสองชิ้นนี้คู่กันแล้วได้ภาพที่ตรงกว่าคำโปรย คือกลไกทำงานได้จริงในระดับหนึ่ง แต่ยังไม่มีหลักฐานว่าช่วยให้โค้ดดีขึ้นอย่างมีนัยสำคัญ และมีหลักฐานหนึ่งชิ้นที่บอกว่าไม่ช่วยทั้งยังแพงกว่า ใครควรลอง เลือกตามขนาดงาน - ทีมที่ AI เขียนโค้ดเร็วจนตามรีวิวไม่ทัน เพราะ EGM บังคับให้หยุดที่เอกสารก่อน - คนที่ต้องส่งงานข้ามทีม เพราะเอกสารออกแบบกลายเป็นของกลางที่คนอื่นอ่านได้ - คนที่ใช้ Claude Code หรือ Antigravity อยู่แล้ว ติดตั้งไม่กี่คำสั่ง ยังไม่ต้องใช้ถ้า งานที่ทำเป็นบั๊กเล็กที่แก้บรรทัดเดียว เพราะ README เองบอกให้ใช้กระบวนการเขียนโค้ดปกติ [3] และถ้าคุณใช้ Codex เป็นหลัก ต้องเช็คเอกสาร docs/codex.md ก่อน ว่าการรีวิวที่ต้องใช้เอเจนต์ใหม่ทำงานได้แค่ไหนในสภาพแวดล้อมนั้น [5] เริ่มใช้ยังไง ถ้าใช้ Antigravity CLI [3] agy plugin install https://github.com/google/elephant-goldfish-model ถ้าใช้ Claude Code [3] claude plugin marketplace add google/elephant-goldfish-model claude plugin install egm@egm ตัวอย่างงานที่เหมาะกับการลองครั้งแรก คือฟีเจอร์ที่มีทางแยกให้ตัดสินใจ ไม่ใช่การแก้คำผิด หลังติดตั้งให้เปิดเซสชันใหม่ แล้วลองสั่งงานเล็ก ๆ ที่ต้องมีการตัดสินใจ เช่น เพิ่มระบบส่ง webhook พร้อมคำถามว่า ถ้าส่งไม่สำเร็จจะทำอย่างไร ถ้าเหตุการณ์เดิมมาสองครั้งจะกันซ้ำอย่างไร [3] สิ่งที่ผมยังไม่ได้ทำ ผมยังไม่ได้ติดตั้ง EGM แล้วรันกับโปรเจกต์จริงในรอบนี้ ผมตรวจ README เอกสาร harnesses ไฟล์สกิลรีวิว ข้อมูลรีโปจาก API และรายการ issue ที่เปิดอยู่ ดังนั้นคำถามว่า "ใช้แล้วดีจริงไหม" ผมตอบด้วยประสบการณ์ตรงไม่ได้ และจะไม่ยกตัวเลขที่ไม่มีที่มาแทนคำตอบ แหล่งอ้างอิง [1] X (Twitter) · @EngMoElgaraihy · 31 ต.ค. 2026 22:21 UTC หรือ 1 พ.ย. 2026 เวลาไทย · x.com [2] GitHub REST API · ข้อมูลรีโป google/elephant-goldfish-model และรายการ issue/PR (1 พ.ย. 2026) · api.github.com [3] GitHub · google/elephant-goldfish-model · README ฉบับ main (เข้าถึง 1 พ.ย. 2026) · google/elephant-goldfish-model [4] รีโปเดียวกัน · docs/harnesses.md (เข้าถึง 1 พ.ย. 2026) · github.com/google/elephant-goldfish-model/blob/ma… [5] รีโปเดียวกัน · skills/egm-review/SKILL.md (เข้าถึง 1 พ.ย. 2026) · github.com/google/elephant-goldfish-model/blob/ma… [6] รีโปเดียวกัน · TESTING.md (เข้าถึง 1 พ.ย. 2026) · github.com/google/elephant-goldfish-model/blob/ma… [7] เว็บไซต์ทางการของโครงการ (เข้าถึง 1 พ.ย. 2026) · egm.dev [8] Programming the Loop · "Pilot EGM" (23 ต.ค. 2026) · programmingtheloop.com [9] DEV Community · thereleasedesk · "One AI wrote the plan. A forgetful one found 26 holes in it." (23 ต.ค. 2026) · dev.to [10] Google Open Source Blog · "Introducing the Elephant-Goldfish Model plugin" (22 ต.ค. 2026) · opensource.googleblog.com [11] รีโปเดียวกัน · docs/codex.md (เข้าถึง 1 พ.ย. 2026) · github.com/google/elephant-goldfish-model/blob/ma… บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

Elephant-Goldfish with Antigravity 2.0 for Improving My Coding Projects I have used spec driven workflows for my coding projects like superpowers, bmad and others that help in antigravity. tried google/elephant-goldfish-model and asked flash3.8 to add it and said it was already in antigravity so i told it to look at my projects and it found a lot to fix with its audit. just another tool to check out to see if it helps. not affiliated not my project or anything.

"Draft specs with deep-context agents and stress-test them with zero-context subagents before writing code. Elephant holds your project context and drafts the specification. Goldfish reviewers examine the draft without the earlier conversation, helping expose unstated assumptions and blind spots"

Google 的 EGM 10月27日发了首个标签版：一个 agent 写设计文档，再让没看过前面聊天的 agent 挑漏掉的条件，写代码前先审方案。 官方注明：审稿需要独立上下文的子 agent；发布包还没完成宿主验证，别当稳定版。 google/elephant-goldfish-model

Elephant-goldfish-model: skills for designing and reviewing software with agents