การถกเถียงว่าควรปล่อยให้ AI สร้างซอฟต์แวร์แบบอัตโนมัติเต็มรูปแบบหรือไม่ ในที่สุดก็ปะทุขึ้นแล้ว โดยชนวนเหตุคือ
@yetone ที่ดูแลโปรเจกต์ magpie ซึ่งถูกคนในวงการวิจารณ์ว่าเป็น "ฟาสต์ฟู้ด" และ "เสี่ยงเกินกว่าจะนำมาใช้"
คนส่วนใหญ่เห็นตรงกันว่า การให้ AI สร้างซอฟต์แวร์แบบอัตโนมัตินั้นคือทิศทางของโลก แล้ว magpie ทำเรื่องนี้ได้อย่างไร? ผมดึงโค้ด magpie มาวิเคราะห์ commit ทั้ง 2,862 ครั้งในช่วงสิบวันที่ผ่านมา และใช้ OpenClaw เป็นตัวเปรียบเทียบ
https://x.com/wquguru/status/2109458639501271530
1204 เวอร์ชันใน 19 วัน
magpie คือ local LLM gateway ที่เชื่อมต่อ coding agent อย่าง Claude Code, Codex และ Gemini CLI เข้ากับโมเดลหรือ subscription ใดก็ได้ นับจาก commit แรกเมื่อวันที่ 22 กันยายนจนถึงวันนี้ มันกวาดไปถึง 9,474 stars ภายในเวลาแค่ 19 วัน ในบรรดา commit ทั้ง 2,862 ครั้ง บัญชีของ yetone เป็นผู้ทำถึง 85% และ merge PR จากคอมมูนิตี้ไป 383 ตัว
จำนวน tag (ซึ่งเทียบเท่ากับเวอร์ชัน) พุ่งไปถึง 1,204 ครั้งใน 19 วัน เฉลี่ยวันละกว่า 60 เวอร์ชัน ซึ่งเป็นความถี่ที่มนุษย์ไม่มีทางทำได้ด้วยมือ เปรียบเทียบกับ OpenClaw ที่มี 1,423 commits ในช่วง 19 วันแรก โดย 99% ส่งเข้ามาโดย Peter Steinberger คนเดียว และมี tag แค่ราวๆ 10 ตัวเท่านั้น
magpie มีจำนวน commit มากกว่าสองเท่า แต่มีจำนวนเวอร์ชันมากกว่าเป็นร้อยเท่า
สิ่งเดียวที่ผมอยากหาคำตอบคือ: AI ปิดวงจรการทำงานในโปรเจกต์นี้ได้อย่างไรกันแน่?
ตาราง Routing และสมุดจดข้อผิดพลาด
ไฟล์ CLAUDE.md ของ magpie อ้างอิงไฟล์เพียงสองไฟล์เท่านั้น คือ AGENTS.md และ LESSONS.md
AGENTS.md ทำหน้าที่เป็นตาราง routing มันไม่ได้เขียนกฎขึ้นมาเอง เพียงแต่บอก agent ว่าต้องไปอ่านเอกสารไหนก่อนลงมือทำงาน เช่น ให้ดู docs/subsystems/ ก่อนแก้ไข subsystems, ให้ทำตาม docs/code-standards.md เวลาเขียนหรือรีวิวโค้ด และให้อ่าน docs/contributors.md เวลารีวิว PR จากคอมมูนิตี้
ประโยคแรกของ LESSONS.md ตอบคำถามข้างต้นได้ทันที:
โค้ดของ magpie ถูกเขียน รีวิว merge และปล่อยเวอร์ชันโดย agent ทั้งหมด (โค้ดของ magpie ถูกเขียน รีวิว merge และปล่อยเวอร์ชันโดย agent ทั้งหมด)
ทั้งการเขียน การรีวิว การ merge และการปล่อยเวอร์ชัน ล้วนทำโดย agent ทั้งหมด ถ้าไม่มีคนคอยคุม ทำไมมันถึงไม่พัง? คำตอบอยู่ในไฟล์นี้ ไฟล์ขนาด 479 บรรทัดนี้เปรียบเสมือน "สมุดจดข้อผิดพลาด" ที่ agent เขียนขึ้นทุกคืน
ทุกคืน agent จะมารีวิว commit ทั้งหมดของวันนั้น โดยโฟกัสไปที่ 3 กรณี:
- งานแก้บั๊กไหนที่ต้องกลับมาแก้อีกรอบ?
- งานไหนที่ไม่ควรถูก merge ตั้งแต่แรก?
- การตรวจสอบรอบไหนที่ทำแบบขอไปที?
ทุกครั้งที่เจอปัญหา มันจะบันทึกกฎ เหตุผล พร้อมแนบหมายเลข commit และ issue ไว้เป็นหลักฐาน ตัวอย่างเช่น:
จงจำลองเคสของผู้รายงานบนหน้าจอที่เขาใช้จริงให้ได้เสียก่อน แล้วค่อยบอกว่าแก้เสร็จแล้ว
Issue 834 กลับมาให้แก้ซ้ำถึง 4 รอบ (v0.1.920 → .925 → .931 → .938) แต่ละรอบแก้แค่ agent ที่ปรากฏในภาพหน้าจอ พบ 1× (2026-10-05)
Issue 834 ต้องกลับมาแก้ซ้ำสี่ครั้ง โดยแต่ละครั้งแก้แค่ agent ที่เห็นในภาพหน้าจอ กฎจึงออกมาว่า: ก่อนจะบอกว่าแก้เสร็จแล้ว ต้องจำลองปัญหานั้นบนหน้า UI ที่ผู้รายงานใช้ได้จริง
จุดสำคัญอยู่ที่บรรทัดสุดท้าย: พบ 1× หากบทเรียนเดิมโผล่มาในการรีวิว 3 วันต่างกัน มันจะถูกย้ายจาก LESSONS.md ไปยัง code-standards.md กลายเป็นกฎเหล็กที่ได้จากประสบการณ์ และการรีวิว PR ทุกครั้งหลังจากนั้น จะต้องเช็กตามกฎเหล่านี้ทีละข้อ
ตอนนี้มีกฎ 8 ข้อที่ถูกเลื่อนขั้นด้วยวิธีนี้แล้ว เช่น การแก้บั๊กที่คล้ายกันพร้อมกันไปเลย (ถูกจับได้วันที่ 5, 6 และ 7 ตุลาคม), ถ้าเทสต์บน main ไม่ผ่านถือเป็นบั๊กเร่งด่วนที่ต้องแก้ทันที, และต้องระบุให้ชัดเจนว่าเทสต์อะไรไปบ้างและบน commit ไหนก่อนทำการ merge
แน่นอนว่าสมุดจดข้อผิดพลาดนี้ก็บันทึกสิ่งที่ทำได้ดีไว้ด้วย โดยแปะป้ายว่า Done right เพื่อให้ agent ได้อ่านไม่ใช่แค่ "ห้ามทำอะไร" แต่ยังรวมถึง "ให้ทำแบบนี้แทน" ด้วย
ระบบสมุดจดข้อผิดพลาดเริ่มใช้ตอนเช้ามืดวันที่ 6 ตุลาคม
ระบบนี้ออกแบบไว้ตั้งแต่แรกเลยหรือเปล่า? เมื่อลองไล่ดู commit history ของ LESSONS.md เวอร์ชันแรกคือ commit 303819c5 ซึ่งสร้างขึ้นตอนตี 3:10 น. ของวันที่ 6 ตุลาคม
หนึ่งวันก่อนหน้านั้น ในวันที่ 5 ตุลาคม magpie ปล่อยเวอร์ชันออกไปถึง 168 เวอร์ชัน
LESSONS.md เวอร์ชันแรกบันทึกเรื่องราวของวันนั้นเอาไว้ ด้วย commit 220 ครั้งและการปล่อยเวอร์ชันราว 170 ครั้ง ประมาณ 40 ครั้งเป็นการแก้เวอร์ชันที่เพิ่งปล่อยไปในวันเดียวกันหรือวันก่อนหน้า CI แทบทุกครั้งถูกยกเลิกเพราะมี push ใหม่เข้ามา เทสต์ตัวหนึ่งที่พังเฉพาะบน Linux ขึ้นสีแดงค้างอยู่ตั้งแต่ v0.1.877 ถึง v0.1.892 โดยไม่มีใครสังเกตเห็นเลย
294 tags ใน 51 ชั่วโมง ทำให้ไม่มี CI run ไหนรันจบได้เลย (294 tags ใน 51 ชั่วโมง ทำให้ไม่มี CI run ไหนรันจบได้เลย)
เวอร์ชันแรกจึงเพิ่มกฎเข้าไปว่า: ก่อนจะสร้าง tag ได้ CI ของ commit นั้นต้องรันจบและเป็นสีเขียว ส่วน run ที่ถูกยกเลิกเพราะมี push ใหม่ไม่นับ
วันแรกปล่อย 168 เวอร์ชัน วันที่สองเหลือ 42 วันที่สามเหลือ 15 แล้วก็คงที่อยู่ระหว่าง 15 ถึง 26 เวอร์ชัน
ไม่มีการประชุมใดๆ ไม่มีการส่งแจ้งเตือน การรีวิวตอนกลางคืนเจอปัญหา ก็เพิ่มกฎลงในสมุดจดข้อผิดพลาด แล้ว agent ที่ทำงานอยู่ก็อ่านกฎนั้นและชะลอความเร็วในการปล่อยเวอร์ชันลง
ดังนั้น การปล่อยเวอร์ชันยี่สิบกว่าครั้งต่อวันที่เพิ่งถูกหยิบยกมาเป็นประเด็นเมื่อไม่นานมานี้ จริงๆ แล้วคือความเร็วหลังจากเหยียบเบรกแล้วต่างหาก
เกณฑ์การรับ PR
ต่อไปมาดู PR ของจริงกัน:
code-standards.md ระบุเกณฑ์การรับไว้ 6 ข้อ ต้องผ่านทั้งหมดก่อนจะ merge หรือปล่อยเวอร์ชันได้ นอกจากการเช็กมาตรฐานอย่างการคอมไพล์บนสามแพลตฟอร์มและการเทสต์ใน sandbox แล้ว มีอีก 3 ข้อที่หาได้ยากมากในโปรเจกต์ทั่วไป:
- Regression Test: เอาโค้ดเก่ากลับไปใส่ เทสต์ใหม่ต้องล้มเหลวอย่างชัดเจนและชี้ได้ว่าพฤติกรรมไหนผิด คอมไพล์ไม่ผ่านหรือข้ามเทสต์ไปเฉยๆ ไม่นับ
- Real Usage: ถ้าเปลี่ยน vendor integration ต้องทดสอบด้วยบัญชี คอนฟิก และ API response จริง ฟีเจอร์ที่ยังไม่ได้เทสต์ ห้ามเอาไปต่อยอดหรือบอกผู้ใช้ว่าใช้งานได้
- ต้องระบุรายการที่ไม่ได้เทสต์:
การเช็กที่ไม่ได้ทำ ต้องระบุว่า "ไม่ได้ทำ" ห้ามตกหล่นเด็ดขาด (การเช็กที่ไม่ได้ทำ ต้องระบุว่า "ไม่ได้ทำ" ห้ามตกหล่นเด็ดขาด)
ผมสุ่มเลือก #1339 มาดูคอมเมนต์ที่ทิ้งไว้ก่อน merge:
Red check หมายถึง regression test, Break check หมายถึงการแกล้งทำให้โค้ดพังเพื่อดูว่าเทสต์จับได้ไหม และบรรทัดสุดท้ายเขียนว่า Not run แปลว่าไม่ได้เทสต์บนฮาร์ดแวร์จริง
คำสั่ง merge จะมี --match-head-commit <reviewed sha> แนบไปด้วย ถ้ามีคน push โค้ดเพิ่มระหว่างที่กำลังรีวิว การ merge จะล้มเหลวทันที เป็นการรับประกันว่าจะไม่มีโค้ดที่ยังไม่ได้รีวิวหลุดเข้าไปได้
Human in the Loop
แน่นอนว่ามนุษย์ก็ยังมีส่วนร่วมในงานบางอย่าง อย่างน้อยก็ในด้านเหล่านี้:
- การตัดสินใจด้านผลิตภัณฑ์: "ห้ามกลับคำตัดสินใจที่ตั้งใจไว้แล้ว" เรื่องอย่างพฤติกรรมการเลื่อนหน้าจอหรือเคอร์เซอร์เมาส์บนปุ่ม ห้ามเปลี่ยนผ่าน PR
- ด่านความปลอดภัย: ถ้าการเช็กความเสี่ยงแจ้งเตือน ต้องรอ maintainer อนุมัติก่อน
- ข้อเสนอแนะจากคอมมูนิตี้: ชื่อ commit 474 รายการมีการกล่าวถึงผู้รายงานจาก X หรือ Discord เช่น JonahFu บน X, Jeremy.Zhou บน Discord
สรุปง่ายๆ คือ มนุษย์เป็นคนกำหนดทิศทางและเฝ้ายาม ส่วนการเขียน การรีวิว การ merge และการปล่อยเวอร์ชัน ปล่อยให้ agent จัดการ
yetone ซ่อนอะไรไว้หรือเปล่า?
มาถึงตรงนี้ หลายคนอาจสงสัยว่า yetone ซ่อนอะไรไว้หรือเปล่า? ผมเองก็อยากรู้เลยขุดลึกไปอีก
จริงๆ แล้วมีหลายอย่างที่ไม่ได้อยู่ใน repo:
- ไม่มีเอกสารอธิบายว่าการรีวิวตอนกลางคืนถูกทริกเกอร์อย่างไร ใน workflow ทั้ง 4 ตัวไม่มีตัวไหนตั้งเวลาไว้เลย
- ผมดึงเวลาที่อัปเดต LESSONS.md มา 7 ครั้ง: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26 เวลามันกระจัดกระจาย ดูไม่เหมือน cron job แต่เหมือนคนสั่งรันเองบนเครื่องหรือใช้สคริปต์เฉพาะกิจมากกว่า
- prompt ที่ใช้ในการรีวิวตอนกลางคืนก็ไม่มีเช่นกัน ใช้ agent ตัวไหน รันกี่ session ขนานกัน ไม่มีเอกสารระบุไว้เลย
ระหว่างทาง ผมเจอข้อมูลเพิ่มเติมอีกสองเรื่อง:
เรื่องแรก วิธีนี้พึ่งพาการมีส่วนร่วมของคอมมูนิตี้ด้วย เอกสาร subsystem และการรีวิว semantic change ถูกเพิ่มเข้ามาผ่าน PR #889 ของ Junjie Zhou สมาชิกในคอมมูนิตี้ และตารางสองตารางในตอนต้นของ code-standards.md ก็ระบุเครดิตไว้ใน commit 926bcaa3 อย่างชัดเจนว่าเป็นกฎการรีวิว 6 ข้อที่ Junjie Zhou เสนอไว้บน Discord
เรื่องที่สอง บทสนทนาระหว่าง yetone กับ agent ถูกเก็บไว้ใน commit ชื่อ commit 52 รายการมีคำพูดดั้งเดิมของ yetone อยู่ในวงเล็บ:
1(เจ้าของโปรเจกต์: อันนี้มันน่าเกลียดเกินไป)2(เจ้าของโปรเจกต์: ทำไมอันนี้ถึงใช้ native selector แทนที่จะเป็น ComboBox แบบ abstract ของเรา?)3(เจ้าของโปรเจกต์: ทำไมเรื่องนี้กลับมาอีกแล้ว? เราตกลงกันแล้วไม่ใช่เหรอว่ามันควรโผล่มาตอน hover เท่านั้น? โผล่มาตลอดเวลามันน่าเกลียดเกินไป)4(เจ้าของโปรเจกต์: ตอน pr-preview บางทีไม่มีข้อมูลให้เทสต์ ช่วยสร้างข้อมูลปลอมๆ มาให้หน่อยได้ไหม?)
ส่วนใหญ่เป็นคำบ่นสั้นๆ แค่บรรทัดเดียว ที่เหลือ agent จะเติมให้เอง ซึ่งมักจะทำให้เนื้อความใน commit ยาวเป็นร้อยๆ คำ คำขอข้อมูลปลอมที่ว่านี้ ต่อมากลายเป็นชุด mock data ที่ใช้บันทึกใน CI
มนุษย์เป็นคนชี้ว่าอะไรผิด ส่วน agent จะแปลงมันเป็นความเปลี่ยนแปลงที่ตรวจสอบได้ ชื่อ commit หลายสิบรายการนี้อธิบายวิธีการทำงานได้ชัดเจนกว่าเอกสารใดๆ
ถ้าอยากทำแบบนี้เองบ้าง
ใครๆ ก็เขียนตาราง routing ได้ สิ่งที่มีค่าจริงๆ ที่ควรลอกเลียนแบบคือระบบสมุดจดข้อผิดพลาด รูปแบบของ LESSONS จะเป็นประมาณนี้:
1**<กฎแบบประโยคเดียว>**2- <commit/issue ไหนทำให้เกิดปัญหา ผลลัพธ์คืออะไร>3- <commit ที่ใช้แก้>4- Done right: <ตัวอย่างของการทำที่ถูกต้อง>5- Seen N× (YYYY-MM-DD, YYYY-MM-DD).
ให้ agent มารีวิว commit รายวันทุกคืน โดยมองหาแค่งานแก้ซ้ำ การ merge ผิดพลาด และการตรวจสอบที่ไม่รัดกุม ถ้าปัญหาเดิมโผล่มา 3 วันต่างกัน ให้ย้ายไปอยู่ใน code standards ระหว่างการตรวจรับ ให้ลิสต์ regression test, real usage และรายการที่ไม่ได้เทสต์ไว้ในเนื้อหา commit และคอมเมนต์ PR
หลังจากรีวิว repo นี้จนจบ สิ่งที่ประทับใจผมที่สุดคือเกณฑ์ Seen 3× ข้อผิดพลาดถูกจดไว้ agent อ่านมันตอนเริ่มทำงาน และถ้าทำพลาดเรื่องเดิมครบสามครั้ง มันจะถูกยกระดับเป็นกฎเหล็ก สะท้อนสำนวนที่ว่า "สามครั้งถือว่าจบ" (หรือจะเรียกว่าโดนเตือนสามครั้งแล้วไล่ออกก็ได้) ได้อย่างสมบูรณ์แบบ
บทสรุป...
เมื่อปีก่อน หรือแม้แต่ครึ่งปีก่อน ความสามารถของโมเดลแทบจะไม่ถึงระดับที่จะทำ automation สำหรับงาน production ได้ แต่ตอนนี้ โดยเฉพาะตั้งแต่ Opus 5.5 เปิดตัว เราจะเห็นได้ว่าอนาคตมาถึงแล้วจริงๆ
เรื่องนี้ทำให้ผมนึกถึง Yoyo ของ @yuanhao ซึ่งเป็น Agent ที่ iterate ตัวเองมาแล้วกว่า 200 วัน: https://yoyo-gasp.yolog.dev/ น่าไปลองดูเหมือนกัน
