Steve Yegge ประกาศเลิกทำ harness แบบใช้ซ้ำ แล้วบอกว่า CI/CD จะตายภายในปีหน้า — พร้อมเปิดตัวเลขจริง 175-250 commit ต่อวัน และค่า token เดือนละ $87,000

Steve Yegge เผยแพร่เรียงความ “The Shape of Things to Come, Part 1: The Continuous Thunderdome” เมื่อวันที่ 3 สิงหาคม (ขึ้น Hacker News วันเดียวกัน) — เป็นรายงานภาคสนามจากคนที่รัน agent กว่า 40 ตัวตลอด 24 ชั่วโมงบนโค้ดเบสอายุ 25 ปีของเกม MMO ชื่อ Wyvern ที่เขาเขียนมาตั้งแต่ปี 1996 และยังมีผู้เล่นจ่ายเงินอยู่จริง

สิ่งที่ทำให้มันน่าอ่านกว่าบทความทำนายอนาคตทั่วไปคือเขาเปิดตัวเลขจริงหมด: commit ต่อวัน ค่า token ต่อเดือน จำนวน agent จำนวนบรรทัดของ harness — และคำสารภาพว่าระบบตัวก่อนของเขาพังยับเพราะการอัปเดตโมเดล

Gas Town พังเพราะ Opus 4.7 และเขาสรุปว่า harness แบบใช้ซ้ำไม่มีอยู่จริง

Gas Town คือ harness ตัวก่อนที่ Yegge ตั้งใจทำให้ใช้ซ้ำได้ แต่สุดท้ายเขาบอกว่า “ผมได้ใช้มันสร้างแค่ตัวมันเอง” มันทำงานได้ดีมาตลอดจนถึง Claude Opus 4.6 แล้วพังตอน 4.7 ซึ่งมาพร้อมอาการที่เขาเรียกว่า “just two more things” tic — Opus จะอยากกลับไปแก้ตัว Gas Town เองไม่หยุด จนไม่เคยเข้าโหมดพร้อมทำงานจริงสักที อาการนี้ไม่เคยหายไป Gas Town เลย “ไหม้ลงไปทั้งเมือง”

ตัวใหม่ชื่อ Wheelhouse อายุหกสัปดาห์ ปิดซอร์ส ทำมาเพื่อตัวเขาคนเดียว และประโยคที่เขาย้ำคือ “harness จะกลายเป็นของสั่งทำเฉพาะตัวทั้งหมด และคนที่พยายามขาย harness ให้คุณจะเจ๊งกันหมด” เหตุผลของเขาคือ harness ต้องเชื่อมติดเข้ากับตัวแอปพลิเคชันในระดับพันธะเคมี ไม่ใช่เฟรมเวิร์กที่โหลดมาใช้

สเปกของ Wheelhouse: โค้ด ~150k–300k บรรทัด (ส่วนใหญ่เป็น bash เพราะ agent บอกว่าเหมาะสุด) บวก elisp อีก ~25k บรรทัด รันบน Emacs ทั้งหมด, agent 18 ตัวใน “crew” (ใช้ Fable ทำ design + review), fleet ที่เป็น Opus 5 ทำ implementation, และ role agent แบบยืนประจำอีกกว่าสิบตัวสำหรับดูแล production — Gargoyle (SRE), Drawbridge (เฝ้า deploy), Warden (เฝ้าผู้เล่นก่อกวน), Herald (เขียน patch notes) พร้อม launchd/systemd unit อีกราว 45 ตัวตามกฎที่เขาตั้งว่า “cron เฝ้า, model ลงมือ”

ที่ควรอ่านให้ดีคือตัวเลขค่าใช้จ่าย: การพัฒนา Wyvern เผา token เทียบเท่าราคา API ที่ $87,000 ต่อเดือน (~69 พันล้าน token ในเดือนกรกฎาคม, cache hit 96%) เขาแก้ด้วยการซื้อบัญชี Claude Max $200 เพิ่มอีก 12 บัญชี (บวกค่า Google Workspace user อีกบัญชีละ $17/เดือน) แล้วเขียนให้ agent หมุนใช้บัญชีอัตโนมัติเมื่อใกล้ชนลิมิต ทำให้จ่ายจริงราว $2,800/เดือน — เขาระบุเองว่าเชื่อว่าไม่ผิด Consumer Terms เพราะจ่ายทุกที่นั่งและไม่แชร์ให้ใคร แต่ เตือนไว้ตรง ๆ ว่าถ้าทำแบบนี้ในนามบริษัทหลายคน “แทบจะแน่นอนว่าผิดข้อกำหนด” และควรไปใช้ API billing แทน

Thunderdome: เมื่อ merge queue แพ้หลักรังนกพิราบ

ส่วนที่เป็นเนื้อหาเชิงวิศวกรรมจริงที่สุดคือข้อโต้แย้งเรื่อง CI/CD ซึ่งเขาวางเป็นคณิตศาสตร์ล้วน

merge queue แบบเดิมทำงานด้วยการจับ commit รวมเป็น batch เพื่อลดจำนวน build แล้วถ้า batch ไหนพัง ก็ bisect หาคนผิดด้วย log(N) รอบ — ใช้ได้ดีมาสิบกว่าปี แต่ Yegge เล่าว่าเดือนนี้เขาทำ commit “ของจริง” (ไม่นับ noise จากการ orchestrate) เฉลี่ย 175 commit ต่อวัน บางวันถึง 250 และ build gate ของเขาใช้เวลาราวครึ่งชั่วโมง ผลคือคิวโตทะลุ 100 MR ภายในสองวัน แล้วติดอยู่ในลูป bisection จนไม่มีอะไรคืบหน้าเลย

ทางออกที่เขาเรียกว่า Land Rush: พอคิวแตะ 100 ก็เลิก bisect แล้วโยนทั้งกองลง main ทีเดียวเป็น megabatch จากนั้นใช้ swarm diagnosis คือปล่อย agent ฝูงหนึ่งเข้าไปวินิจฉัยพร้อมกัน แทนการไล่หาว่าใครผิด เขาบอกว่าทำมาราวหนึ่งสัปดาห์ เคลียร์ batch ขนาด 120–150 commit ไปได้หลายรอบแล้ว

เหตุผลเชิงหลักการที่เขาให้คือ Pigeonhole Principle — เมื่ออัตรา commit วิ่งแซงจำนวนช่อง build ที่มี “หนึ่ง commit ต่อหนึ่ง green build” จะเป็นไปไม่ได้ในทางคณิตศาสตร์ agent คูณอัตรา commit ขึ้นเป็นระดับ order of magnitude ขณะที่เวลา build เท่าเดิม

หลักฐานสนับสนุนที่น่าสนใจที่สุดไม่ได้มาจากวงการ AI: ระหว่างไปสอนทีมที่ SaaS แห่งหนึ่งในลอนดอน วิศวกรอาวุโสที่เคยทำเกมมาหลายปีเล่าให้ฟังเรื่อง “Game DevOps” — วงการเกม AAA ที่ build ยาวมากและ asset pipeline ใหญ่ ทำแบบนี้มานานแล้ว คือทุกคนยิง commit ลง main, ตัด release branch แล้วรันจาก branch นั้น ปล่อยให้ main แดงเป็นปกติ Yegge ถามว่าทำบ่อยแค่ไหน คำตอบคือ “หลายครั้งต่อวัน”

ส่วน human code review เขาตอบ CTO ที่ถามว่าตายแล้วหรือยังว่า “ยัง — แต่จะตายภายในปีหน้า” เขายอมรับว่า SOC 2 จะยื้อไว้ได้อีกพัก (พร้อมข้อสังเกตว่า SOC 2 แพร่ไปทั่วอุตสาหกรรมโดยไม่มีกฎหมายรองรับเลย) แต่ยืนยันว่าคำว่า “review” จะไม่ได้แปลว่ามีมนุษย์หนึ่งคนอนุมัติทุก diff อีกต่อไป และคำแนะนำระยะสั้นของเขาคือ ยังต้องรีวิวโค้ด agent อยู่ เพราะตอนนี้มีแค่ Fable ที่เขาเชื่อถือได้พอ — แต่ให้เริ่มวางแผนแทนที่ด้วย agentic review หลาย ๆ รอบไว้ได้เลย

Wish Factory และเมืองที่โตขึ้นเอง

ส่วนสุดท้ายคือ Wish Factory — agent ที่รับ GitHub issue (ไม่รับ PR) แล้วลงมือ implement ให้เลย ไอเดียมาจาก Guy Podjarny แห่ง Tessl ส่วนเวอร์ชันของ Yegge เริ่มจาก agent ชื่อ Sage ที่ล็อกอินเข้าเกมไปนั่งฟังในช่องแชทของแอดมิน ใครพิมพ์ว่า “ผู้เล่นบอกว่าสเปลไฟลูกใหม่ทำให้แลค” Sage ก็ตอบ ไปสืบ แล้วบันทึกเป็นงาน ซึ่งจะถูกหยิบไป implement ต่อ — “การแก้ส่วนใหญ่จบโดยที่ผมไม่เคยอยู่ในลูปเลย” ตอนนี้เขาขยายให้ผู้เล่นทั่วไปยื่นคำขอได้แล้ว โดยใส่ guardrail และ triage เพิ่ม จำกัดที่บั๊กคุณภาพชีวิตที่ไม่กระทบสมดุลเกม

ข้อสังเกตที่ตรงกับคนทำ Agent Skills: เขาเล่าว่าตอนแรกมอง Skills เป็นแฟชั่นเพราะ Bitter Lesson ของ Richard Sutton แต่เปลี่ยนใจแล้ว โดยให้เหตุผลว่า “ปัญหาของ public Skills คือมันจะไหลเข้าไปอยู่ใน training data ของโมเดลรุ่นใหม่แล้วหมดความหมายไปเอง” ส่วน private Skills ยังมีค่าจริงเพราะเข้ารหัสความรู้เฉพาะขององค์กรและลดการเผา token ตอน prime งาน — ตอนนี้เขามีอยู่ราว 30 skill กับไฟล์ markdown “สมองโปรเจกต์” อีกราว 100 ไฟล์

และตัวเลขที่คนกำลังจะสร้าง harness ควรจดไว้: การดูแล Wheelhouse เองกินเวลาราว 20-25% ของงาน Wyvern ทั้งหมด และเขาคิดว่าตัวเลขนี้อาจจะคงที่ไปตลอดอายุของระบบที่มี agent harness

มุมมอง AI Curator

เรียงความนี้มีคุณค่าตรงที่มันเป็นรายงานจากคนที่ลงมือทำจริงและกล้าบอกว่าอะไรพัง ไม่ใช่ vision deck ของคนขายของ — และมันไม่ได้ขายอะไรด้วย เพราะ Wheelhouse ปิดซอร์สและเขาบอกเองว่าคุณโหลดมาใช้ไม่ได้ แต่ก็ต้องอ่านโดยรู้ว่า นี่คือ n=1 ของโปรเจกต์ที่พิเศษมาก: เกมของตัวเอง ไม่มีเพื่อนร่วมทีมที่เป็นมนุษย์ ไม่มี compliance ไม่มีลูกค้าองค์กร และงบ token ที่คนทั่วไปเข้าไม่ถึง สิ่งที่ Yegge ยืนยันว่า “ผมไม่ได้พิเศษ ผมแค่อยู่ข้างหน้าคุณ” เป็นสมมติฐานของเขา ไม่ใช่ข้อเท็จจริงที่พิสูจน์แล้ว

สำหรับทีมไทย ผมคิดว่าคำทำนายที่ควรเชื่อกับที่ควรระวังนั้นต่างกันมาก ข้อโต้แย้งเรื่อง merge queue นั้นแข็งที่สุด เพราะมันคือเลขคณิตล้วน ๆ ไม่ใช่ความเห็น: ถ้าอัตรา commit เกินจำนวนช่อง build เมื่อไร รูปแบบเดิมพังทันทีไม่ว่าคุณจะชอบหรือไม่ และหลักฐานจากวงการเกมที่มาถึงคำตอบเดียวกันโดยไม่มี AI เกี่ยวข้องเลย เป็นการยืนยันข้ามอุตสาหกรรมที่หนักแน่น ทีมที่กำลังจะปล่อย coding agent เข้า repo ควรถามตัวเองวันนี้ว่า build gate ใช้เวลาเท่าไร แล้วมันจะรับ commit ได้กี่ตัวต่อวัน

แต่ ข้อสรุปว่า “harness แบบใช้ซ้ำจะเจ๊งทั้งหมด” นั้นเร็วเกินไป — และวันเดียวกันนี้เองก็มีหลักฐานสวนทาง: LongHorizon-Harness ของทีม Alibaba เป็น harness แบบใช้ซ้ำที่ครอบ Claude Code/Codex ได้โดยไม่แก้ agent loop เดิม แล้ววัดได้ว่าดัน Qwen ให้แซง Opus 4.7 นั่นแปลว่าอย่างน้อยชั้น “การจัดการสถานะงานกับการตรวจสอบ” นั้นใช้ซ้ำได้จริง ส่วนที่ต้องสั่งทำเฉพาะน่าจะเป็นชั้นบนที่ผูกกับ domain มากกว่า

ประเด็นที่ควรระวังที่สุดสำหรับผู้อ่านไทยคือเรื่องการหมุนบัญชี Max หลายใบ Yegge เขียนไว้เองว่านั่นเป็นการตีความข้อกำหนดของเขา และเตือนชัดว่าอย่าทำในนามบริษัท — เราไม่แนะนำให้ทีมไหนลอกวิธีนี้ ตัวเลขที่ควรเอาไปใช้จริงมากกว่าคือ 20-25% ของเวลางานทั้งหมดที่หมดไปกับการดูแล harness เอง ใครกำลังเสนอผู้บริหารว่า agent จะช่วยประหยัดแรง ควรใส่ต้นทุนก้อนนี้ลงในสไลด์ด้วย

แหล่งข่าว

• The Shape of Things to Come, Part 1: The Continuous Thunderdome — Steve Yegge
• The Shape of Things to Come, Part 2: Model Welfare for Agentic Engineers
• กระทู้บน Hacker News