โรงงานซอฟต์แวร์ของ Claude Code: ทำไมรีวิวผ่านทั้ง 4 ด่าน AI ยังไม่ยอม merge ให้?

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI และระบบเปิด | ตรวจสอบข้อมูล ณ 20 ต.ค. 2026

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

คลิป 58,000 วิวกับคำถามว่าโรงงานนี้ปิดไฟได้จริงไหม

คลิป TikTok บัญชี @zazencodes ยาว 126 วินาที มียอดชม 58,528 ครั้ง และถูกแชร์ต่อ 548 ครั้ง [5]

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

จุดที่คนดูส่วนใหญ่จำได้คือประโยคสุดท้าย ที่ว่าโรงงานส่งผลลัพธ์มาให้เจ้าของโปรเจกต์ตรวจเองก่อน merge

คำถามที่ผมสนใจไม่ใช่ "เอเจนต์เขียนโค้ดได้ไหม" เพราะเรื่องนั้นจบไปนานแล้ว

วิดีโอต้นทางยาวกว่า 25 นาที [1] และมีบทความอธิบายหัวข้อไว้ในบล็อกของผู้เขียนอีกฉบับ [6]

คำถามคือ อะไรทำให้คนที่สร้างระบบนี้ตัดสินใจว่า งานชิ้นหนึ่งต้องผ่านมือคน

และคำตอบไม่ได้อยู่ในคลิป แต่อยู่ในไฟล์กำหนดค่าของโปรเจกต์ที่เขาเปิดให้ดาวน์โหลด

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

โรงงานนี้มีแค่ไฟล์ Markdown เจ็ดไฟล์กับตัวควบคุมอีกหนึ่ง

repo zazencodes/zazencodes-season-3 มีโฟลเดอร์ src/software-factory-claude-code ที่มีตัวระบบจริงอยู่ข้างใน [2]

โครงสร้างที่สำคัญคือ .claude/agents/ ซึ่งเก็บนิยามเอเจนต์เจ็ดตัว และ .claude/skills/factory/SKILL.md ซึ่งเป็นตัวควบคุมวงจร

เจ็ดตัวนั้นแบ่งงานแบบนี้

• spec-writer ใช้ Opus เขียนสเปก
• builder ใช้ Opus สร้างฟีเจอร์และ commit บนสาขาของงานนั้น
• reviewer-security ใช้ Opus ตรวจความปลอดภัย
• reviewer-ux ใช้ Sonnet ตรวจประสบการณ์ผู้ใช้
• reviewer-ui ใช้ Sonnet ตรวจหน้าตา
• reviewer-code ใช้ Sonnet ตรวจคุณภาพโค้ด
• approver ใช้ Opus ตัดสินใจด่านสุดท้าย [2]

ไม่มีเซิร์ฟเวอร์ ไม่มีฐานข้อมูล ไม่มีคิวงานภายนอก ทั้งระบบคือไฟล์ข้อความที่โมเดลอ่าน [2]

นี่คือจุดที่ผมชอบที่สุดของงานชิ้นนี้ เพราะมันพิสูจน์ว่าสถาปัตยกรรมหลายเอเจนต์ไม่จำเป็นต้องเริ่มจาก infrastructure หนัก ๆ

วงจรที่ทุกคนเห็นในคลิป

ลำดับการทำงานเขียนไว้ใน SKILL.md ตรง ๆ

feature -> spec-writer -> builder -> [security, ux, ui, code]
                          ^                    |
                          |  any CHANGES: resume builder
                          |                    v
                 merge to main <- APPROVE <- approver -> ESCALATE -> needs-human

ผู้รีวิวทั้งสี่ตัวทำงานพร้อมกัน และรอบหนึ่งจะนับว่าเสร็จก็ต่อเมื่อไฟล์รีวิวครบทั้งสี่ไฟล์

ถ้าตัวใดตัวหนึ่งเขียน VERDICT: CHANGES ระบบจะปลุก builder ตัวเดิมขึ้นมาทำต่อ [2]

ตัวเลขที่คนพูดถึงน้อยแต่สำคัญคือ MAX_RESUMES = 2 [2]

แปลว่างานหนึ่งชิ้นมีรอบรีวิวได้มากที่สุดสามรอบ แล้วต้องจบ ไม่วนต่อเอง (ถ้าคนสั่ง rework เพดานจะรีเซ็ตใหม่)

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

กติกาที่ทำให้ระบบนี้ต่างจากเดโมอื่น

ส่วนที่ผมคิดว่ามีค่าที่สุดในทั้ง repo ไม่ใช่เอเจนต์ แต่เป็นข้อตกลงสามข้อ

ข้อแรก เอเจนต์อ่านบริบทจากไฟล์ ไม่ใช่อ่านจากบทสนทนา แต่ละตัวได้ prompt ที่บอกโฟลเดอร์งาน worktree และสาขา แล้วอ่าน spec.md กับ build.md เอง

ข้อสอง เอเจนต์เขียนได้คนละไฟล์เดียว reviewer-code เขียนได้แค่ round-N/review-code.md ห้ามแตะโค้ด ห้ามแตะไฟล์คนอื่น

ข้อสาม ตัวควบคุมไม่เขียนงานเอง เซสชันที่รัน /factory ทำหน้าที่แค่เดินสถานะและเป็นผู้เขียน job.json คนเดียว

ข้อตกลงแบบนี้แก้ปัญหาที่พบบ่อยในระบบหลายเอเจนต์ คือเอเจนต์แย่งกันเขียนไฟล์เดียวกันแล้วข้อมูลทับกัน [2]

ตัวอย่างจริง: งานที่รีวิวผ่านทั้งสี่ด่านแต่ต้องรอคนเซ็นก่อน merge

repo มีงานตัวอย่างสองชิ้นที่รันจริงบนเว็บไซต์ของผู้เขียน

ชิ้นแรก 001-blog-reading-time เพิ่มเวลาอ่านโดยประมาณข้างวันที่บนหน้าบทความ

ผลรอบแรกใน job.json เขียนว่า security PASS · ux PASS · ui PASS · code PASS ครบทั้งสี่ด่าน

แต่ decision.md ของงานนี้ขึ้นต้นด้วยคำว่า ESCALATE

เหตุผลที่เขียนไว้คือ ตัวงานถูกต้องครบทุกเกณฑ์ และสาขา merge เข้า main ได้ไม่ชนกัน แต่สาขานั้นแก้ไฟล์ scripts/prerender-blog.js ซึ่งอยู่ในรายการงาน deploy ที่ต้องให้คนอนุมัติ

การแก้มีบรรทัดเดียว คือเพิ่มชื่อไฟล์เข้าไปในรายการ dependency ของตัว prerender ตามที่สเปกข้อ 6 กำหนด

สรุปสั้น ๆ คือ งานถูก แต่พื้นที่ที่งานไปแตะเป็นพื้นที่ห้ามอัตโนมัติ [2]

job.json ของงานนี้บันทึกสถานะสุดท้ายเป็น merged แปลว่าคนสั่งให้ merge ก่อน ไม่ใช่ระบบตัดสินใจ merge เอง

ชิ้นที่สอง 002-not-found-page เพิ่มหน้า 404 ผลคือ APPROVE และ merge เข้า main ได้เลย เพราะเป็นการเพิ่ม view กับ route ต่อท้าย โดยไม่แตะเรื่องเงิน สิทธิ์ หรือการ deploy

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

รายการที่ห้ามให้เอเจนต์ตัดสินคนเดียว

หมวดที่ต้องส่งคนทันที

ในไฟล์ approver.md มีรายการที่ต้องส่งให้คนทันที สี่หมวด

หมวดแรก เงิน สิทธิ์ และตัวตน ครอบคลุมการจ่ายเงิน การยืนยันตัวตน สิทธิ์การเข้าถึง และกฎความปลอดภัยของฐานข้อมูลหรือที่เก็บไฟล์

หมวดที่สอง การ deploy และ CI รวมถึงไฟล์ตั้งค่าโฮสติ้ง และสคริปต์ build ที่ระบบนั้นเรียกใช้

หมวดที่สาม การเปลี่ยนแปลงที่ย้อนยาก เช่น การย้ายโครงสร้างฐานข้อมูล การส่งอีเมล การเขียนข้อมูลบนระบบจริง และการเพิ่ม dependency ใหม่

หมวดที่สี่ การตัดสินใจทางธุรกิจที่ซ่อนในสเปก เช่น ราคา ข้อความประชาสัมพันธ์ หรืออะไรฟรีอะไรเสียเงิน

ข้อความในไฟล์ยังบอกด้วยว่า APPROVE หมายถึงตัวควบคุมจะ merge เข้า main โดยไม่มีคนดู ดังนั้นให้อนุมัติเฉพาะสิ่งที่ตัวมันเองกล้า merge [2]

ผมอ่านประโยคนี้แล้วคิดว่า นี่คือประโยคที่ระบบเอเจนต์ส่วนใหญ่ขาดไป

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

ตัวเลขที่บอกว่าโรงงานนี้ยังปิดไฟไม่ได้

แนวคิดโรงงานที่ไม่มีคนเฝ้า มีงานวิจัยออกมาวัดตรง ๆ แล้วในเดือนตุลาคม 2026

paper ชื่อ (When) Should a Software Factory be Lights-off? สร้างชุดทดสอบชื่อ CRBugBench ขึ้นมาวัดว่าเอเจนต์รีวิวจับบั๊กที่มนุษย์ยืนยันแล้วได้แค่ไหน [3]

ชุดทดสอบมี 1,000 งาน จาก 98 repo โอเพนซอร์ส และเพิ่มอีก 800 งานจาก repo ภายในของบริษัทใหญ่แห่งหนึ่ง

ผลคือเอเจนต์ที่ดีที่สุดจับบั๊กได้ 71.9% ภายในห้าคอมเมนต์แรก และตัวเลขนี้เพิ่มจาก 47.7% เมื่อห้าเดือนก่อน

ฟังดูดี แต่ผู้อ่านควรจับตาสองประโยคถัดมา

เอเจนต์อ่อนลงชัดเมื่อเจอการเปลี่ยนแปลงที่ซับซ้อน หรือบั๊กที่ต้องใช้การอนุมานข้ามไฟล์ และผลตกฮวบเมื่อเจอ repo ภายในองค์กรซึ่งต้องใช้บริบทของโปรเจกต์มาก

แปลว่าในรีโปโอเพนซอร์สที่ใช้ทดสอบ เอเจนต์ได้เปรียบเรื่องบริบท และนั่นไม่ใช่สภาพของงานภายในองค์กร

ปัญหาที่ลึกกว่า: เอเจนต์ตรวจงานตัวเองไม่เจอ

อีก paper หนึ่งชื่อ Articulate but Wrong ทดลองกับโมเดล 11 ตัวจาก 7 ตระกูล รวม 1,980 ครั้ง [4]

คำถามคือ ถ้าโมเดลแก้โค้ดเก่าให้ทันสมัย แล้วให้โมเดลตัวเดิมตรวจว่างานตัวเองเปลี่ยนพฤติกรรมหรือไม่ มันจับได้ไหม

ผลคือในเคสที่โค้ดเปลี่ยนพฤติกรรมจริง มีถึง 31.7% ที่โมเดลตัวเดิมออกมาฟันธงว่าไม่มีปัญหา

และมีโมเดลหนึ่งที่พลาดครบ 100% ในขณะที่อีกห้าตัวพลาด 0%

ที่น่าสนใจคือบางตัวอธิบายความต่างระหว่าง Python 2 กับ Python 3 ได้ถูกต้อง แล้วยังสรุปว่าพฤติกรรมไม่เปลี่ยน

ตัวเลขนี้ตอกย้ำเหตุผลที่สถาปัตยกรรมของโรงงานต้องแยกคนเขียนกับคนตรวจออกจากกันเด็ดขาด

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

สิ่งที่เดโมนี้ยังไม่ได้พิสูจน์

ผมไม่ได้รันโรงงานนี้ด้วยตัวเอง และไม่ได้ติดตั้งเพื่อทดสอบ ผมอ่านจากโค้ดและไฟล์ผลลัพธ์จริงใน repo เท่านั้น

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

หนึ่ง ตัวอย่างมีแค่สองงาน ทั้งสองงานเป็นงานเล็กในเว็บส่วนตัวของผู้เขียน ไม่มีงานที่แตะเงินจริงหรือฐานข้อมูลจริง

สอง ผู้รีวิวมาจากตระกูลโมเดลเดียวกัน แม้จะแยกบทบาท แต่ความผิดพลาดเชิงระบบอาจซ้ำกัน งานวิจัยข้างต้นพบว่า snippet กลุ่มเล็ก ๆ เชิงความหมายตัวเลขล้มเหลวเกือบทุกโมเดล

สาม ไม่มีตัวเลขต้นทุน ทั้งระบบใช้ Opus สี่ตัวในเกือบทุกขั้น การรันหนึ่งฟีเจอร์จึงน่าจะกินโทเคนมากกว่าการเขียนโค้ดตรง ๆ และ repo ไม่ได้สรุปว่าคุ้มหรือไม่

สี่ ไม่มี security scanner จริง ด่านความปลอดภัยคือเอเจนต์อ่าน diff ไม่ใช่เครื่องมืออย่าง Semgrep หรือ CodeQL ซึ่งต่างกันมากในเรื่องอัตราการพลาด

ถ้าจะสร้างโรงงานของตัวเอง ควรเริ่มตรงไหน

สามข้อที่เริ่มได้สัปดาห์นี้

จากหลักฐานที่อ่านมา ผมสรุปเป็นสามข้อที่ใช้ได้ทันที

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

แยกคนเขียนกับคนตรวจให้ขาด อย่าให้เอเจนต์ตัวเดียวทั้งสร้างและอนุมัติ เพราะตัวเลข 31.7% บอกว่าโมเดลตัวเดิมมักมองไม่เห็นความเปลี่ยนพฤติกรรมของงานตัวเอง

กำหนดเพดานรอบ โรงงานนี้ใช้สามรอบ ถ้าครบแล้วยังไม่ผ่าน ให้ส่งคนแทนที่จะปล่อยวน

ทั้งหมดนี้ไม่ต้องใช้เครื่องมือพิเศษ ใช้ไฟล์ Markdown กับ git worktree ก็พอ ทีมเล็กเริ่มทำได้ในสัปดาห์เดียว

ข้อสังเกตสุดท้าย

ตอนอ่านโค้ด ผมเจอประโยคที่ผู้เขียนเขียนไว้เองว่า "ถ้าจะแก้โรงงาน ให้แก้ไฟล์นี้กับไฟล์เอเจนต์"

ประโยคสั้น ๆ นี้บอกปรัชญาของทั้งระบบ คือตัวโรงงานไม่ใช่ซอฟต์แวร์ที่ต้องคอมไพล์ แต่เป็นชุดกติกาที่คนอ่านออกและแก้ได้ [2]

และกติกาที่ดีที่สุดในนั้น คือกติกาที่บอกว่าเมื่อไหร่ต้องหยุดแล้วเรียกคน

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

[1] ZazenCodes, "Build Your Own AI Software Factory with Claude Code", YouTube, 2026. https://www.youtube.com/watch?v=ctoaIC4LHmI

[2] ZazenCodes, repo zazencodes-season-3, โฟลเดอร์ src/software-factory-claude-code (README, SKILL.md, ไฟล์เอเจนต์, งานตัวอย่าง 001 และ 002), GitHub, 2026. https://github.com/zazencodes/zazencodes-season-3

[3] Yang et al., "(When) Should a Software Factory be Lights-off? Benchmarking Code Review Agents on Bug Detection", arXiv:2610.13668, 9 ต.ค. 2026. https://arxiv.org/abs/2610.13668

[4] Reddy, Lolla และ Sanku, "Articulate but Wrong: Self-Review Failures in LLM-Based Code Modernization", arXiv:2605.21537, 20 พ.ค. 2026. https://arxiv.org/abs/2605.21537

[5] บัญชี TikTok @zazencodes, คลิป "Here's how to build a Claude Code software factory", 2026. https://www.tiktok.com/@zazencodes/video/7698415925753564424
[6] ZazenCodes, "Build Your Own Software Factory with Claude Code" (บทความประกอบ), Substack, 7 ต.ค. 2026. https://zazencodes.substack.com/p/build-your-own-software-factory-with