เรื่องเริ่มจากตอนที่ AI ตัวเดียวเขียนโค้ดได้คล่องแล้ว สั่งงานเล็ก ๆ มันก็ส่งโค้ดกลับมาใช้ได้จริง พอเห็นแบบนั้นก็อยากลองให้มันรับงานทั้งก้อน หลาย ๆ งานพร้อมกัน เหมือนมีทีมเล็ก ๆ ในเครื่อง
แต่พอลองคุมหลายตัวด้วยวิธีเดิม คือเปิดแชทแล้วพิมพ์สั่งทีละตัว มันพังเร็วมาก ตัวนี้ทำเสร็จรอคำสั่งต่อ ตัวนั้นไปแก้ไฟล์เดียวกับอีกตัวจนชนกัน เราเองกลายเป็นคอขวด นั่งจ้องสิบหน้าต่างแล้วก็ลืมว่าใครทำอะไรถึงไหน
ตรงนี้แหละที่เห็นชัดว่า ของยากไม่ใช่ "AI เขียนโค้ดเป็นไหม" อันนั้นมันทำได้แล้ว ของยากคือ การจัดการให้หลายตัวทำงานพร้อมกันโดยไม่ชนกัน ไม่หลุด และตรวจได้ พูดอีกแบบคือ ตัวเดโมมันง่าย ของที่เป็นโปรดักต์จริงคือระบบจัดการรอบ ๆ ตัวมัน ส่วนนี้แหละที่คนมักข้าม
เรื่องที่จะเล่าไล่เป็นขั้น เริ่มจาก ทำไมการแชทคุยทีละตัวถึงไปไม่รอด ต่อด้วย แพตเทิร์น Kanban swarm ที่เปลี่ยนวิธีคุม แล้วปิดด้วย ด่านคุณภาพก่อนงานเข้าโค้ดจริง ทั้งหมดเป็นหลักการที่ลองเองกับงานของตัวเอง ไม่ใช่ทฤษฎีลอย ๆ
ช่วงที่ 1ทำไมการแชทคุยทีละตัวถึงไม่สเกล
เวลามี AI coder ตัวเดียว การเปิดแชทคุยกับมันได้ผลดี เพราะเราถือบริบททั้งหมดไว้ในหัว รู้ว่าสั่งอะไรไป มันทำถึงไหน แต่พอเพิ่มเป็นสามสี่ตัว สิ่งที่พังไม่ใช่ตัว AI มันคือ วิธีที่เราคุม
ปัญหาโผล่มาสามอย่างพร้อมกัน หนึ่ง เราต้องคอยป้อนงานถัดไปให้ทุกตัวเอง พอตัวไหนทำเสร็จมันก็นั่งรอ ว่าง ๆ ไปเฉย ๆ จนกว่าเราจะพิมพ์สั่ง สอง พอหลายตัวแก้โค้ดชุดเดียวกันในที่เดียวกัน งานมันทับกันเอง ของที่ตัวหนึ่งเพิ่งเขียน อีกตัวเขียนทับหายไป สาม เราเองกลายเป็นคอขวด เพราะกลายเป็นว่าทุกการตัดสินใจต้องผ่านเรา
จุดสำคัญอยู่ตรงนี้ การแชทคือการคุมแบบจำทุกอย่างไว้ในหัวคนสั่ง วิธีนี้ไม่สเกล เพราะหัวคนเดียวจำได้จำกัด ทางออกไม่ใช่พิมพ์ให้เร็วขึ้นหรือเปิดหน้าต่างให้มากขึ้น แต่คือ ย้ายบริบทออกจากหัวเราไปไว้ในระบบ ที่ทุกตัวอ่านร่วมกันได้ ตรงนี้แหละที่กระดาน Kanban เข้ามา
ช่วงที่ 2แพตเทิร์น Kanban swarm
แทนที่จะคุยกับ agent ทีละตัว เราเปลี่ยนเป็นให้ทั้งทีมทำงานรอบ ๆ กระดานงานใบเดียวกัน แบบ Kanban ที่ทีมคนใช้กันนั่นแหละ มีคอลัมน์ รอทำ กำลังทำ เสร็จ ต่างกันแค่คราวนี้คนหยิบการ์ดคือ agent ตัวที่เราใช้คุมกระดานนี้จริง ๆ คือ Hermes เครื่องมือโอเพนซอร์สที่ออกแบบมาให้ agent ทำงานเป็นทีมรอบกระดานเดียวกัน
หนึ่งโจทย์ แตกเป็นการ์ด
เริ่มจากให้ตัวหัวหน้า (lead) รับโจทย์ก้อนใหญ่มาหนึ่งอัน เช่น "เพิ่มระบบล็อกอิน" หน้าที่แรกของมันไม่ใช่ลงมือเขียน แต่คือ แตกโจทย์เป็นการ์ดงานย่อย ที่แต่ละใบเล็กพอจะจบในตัว เสร็จแล้วการ์ดพวกนี้ก็ไปกองอยู่ในคอลัมน์ รอทำ บนกระดาน
กระดานนี้แหละคือบริบทที่ย้ายออกมาจากหัวเรา ใครทำอะไรถึงไหน ดูที่กระดานจบ ไม่ต้องจำเอง
แจกการ์ด แต่ละตัวทำในที่ของตัวเอง
พอมีการ์ดในคอลัมน์รอทำ worker ก็มาหยิบไปทำทีละใบ หัวใจที่ทำให้ขนานกันได้โดยไม่ชนคือ worker แต่ละตัวทำงานใน worktree ของตัวเอง ก็คือ git แตกสำเนาโค้ดออกมาคนละโฟลเดอร์ ตัว A แก้ไฟล์เดียวกับตัว B ได้ เพราะมันคนละสำเนากัน ไม่เห็นกัน ไม่ทับกัน
ส่วนนี้คือสิ่งที่ทำให้ "ขนาน" เป็นจริงได้ ถ้าทุกตัวแก้ในโฟลเดอร์เดียว เพิ่มตัวเท่าไรก็ยิ่งชนกันมากขึ้น แต่พอแยก worktree ให้แล้ว การเพิ่ม worker ก็แค่เพิ่มสำเนา งานเดินขนานกันจริง
หลักข้อเดียวที่ทำให้ swarm ไม่กลายเป็นความวุ่นวาย คือแต่ละ worker ต้องมีที่ทำงานของตัวเองที่แยกขาดจากตัวอื่น การแยกพื้นที่ไม่ใช่หน้าที่ของ worker แต่เป็นหน้าที่ของตัวจัดคิว
ของจริงที่ลองแล้วเดินได้ครบวง คือจากการ์ดหนึ่งใบ ไปสร้าง worktree ให้ worker ทำ จนได้ไฟล์โค้ดจริงออกมาในเวลาหลักสิบวินาที แล้วการ์ดก็เลื่อนไปคอลัมน์เสร็จเอง ไม่ต้องมีเรามาคอยป้อน
เครื่องยนต์สลับได้ ตัว agent ยังเป็นคนเดิม
มีเส้นแบ่งหนึ่งที่ทำให้ทั้งระบบยืดหยุ่น คือ ตัวตนของ agent แยกขาดจากเครื่องยนต์ที่ขับมัน งานวางแผนแตกโจทย์ที่ต้องเข้าใจภาษาดี ๆ ใช้โมเดลตัวที่เก่งด้านนั้น ส่วนงานเขียนโค้ดซ้ำ ๆ จะสลับไปใช้โมเดลที่ถูกกว่าก็ได้ โดยที่บทบาท หน้าที่ และวิธีทำงานของ agent ไม่เปลี่ยน
วิธีคิดแบบนี้คือออกแบบให้ หน้าสัมผัสตายตัว แต่เครื่องยนต์ข้างในสลับได้ ของจริงตอนนี้ worker รันบน gpt-5.5 (ผ่าน Codex) ส่วนเราเองนั่งสั่งงานจาก Claude Code จุดที่ทำให้สองฝั่งเชื่อมกันคือ skill ที่ worker ของ Hermes ใช้ กับที่เราใช้ใน Claude Code เป็นชุดเดียวกัน มาจากต้นทางไฟล์เดียว พอมีโมเดลใหม่ที่ถูกหรือเก่งกว่า ก็สลับเข้ามาในบทบาทเดิมได้ Hermes ให้กระดานกับการสลับ engine นี้มาเป็นฐาน ส่วนตัวกาวที่เราต่อเพิ่มเอง ทั้งการจัดคิว worker แยก worktree ไม่ให้ปนกัน และผูกเข้ากับ skill ชุดเดียวของเรา คือส่วนที่กำลังทำต่อ
ช่วงที่ 3ด่านคุณภาพ ก่อนคนกด merge
ให้ agent เขียนโค้ดขนานกันได้เร็วเป็นเรื่องดี แต่เร็วอย่างเดียวไม่พอ ถ้าของที่ออกมาเชื่อไม่ได้ เราก็แค่ผลิตบั๊กได้เร็วขึ้น ด่านคุณภาพเลยสำคัญพอ ๆ กับตัว swarm
คนตรวจต้องคนละเครื่องยนต์กับคนเขียน
กฎที่เราถือคือ ตัวที่ review ควรเป็นคนละเครื่องยนต์กับตัวที่เขียน เพราะโมเดลที่เขียนโค้ดผิดด้วยตรรกะแบบหนึ่ง มักมองข้ามที่ผิดของตัวเองด้วยตรรกะแบบเดียวกัน พอเอาอีกเครื่องยนต์มาตรวจ มันเห็นมุมที่ตัวแรกมองไม่เห็น ของจริงที่เราทำตอนนี้คือ worker เขียนเสร็จ เปิด PR (คำขอรวมโค้ด) แล้วมีด่าน review เครื่องยนต์ที่สองคั่นตรงนั้นก่อนถึงมือคน ส่วนการแยกเครื่องยนต์ระหว่างคนเขียนกับคนตรวจให้ขาดกันทุกตัว เป็นทิศที่เรากำลังทำให้ครบ
คนเป็นคนกด merge เสมอ
ด่านสุดท้ายก่อนโค้ดเข้าของจริง คือคน ระบบจะแตกงาน เขียน ตรวจ เองได้หมด แต่จังหวะ กด merge เข้าโค้ดหลักเป็นของคน เพราะนี่คือก้าวที่ย้อนยาก ของที่เข้าไปแล้วคนอื่นดึงต่อทันที จุดนี้คือเส้นแบ่งเดียวกับที่เคยเขียนไว้เรื่อง เส้นแบ่งว่างานไหนให้ AI ทำเอง งานไหนต้องให้คนเคาะ งานที่ย้อนได้ปล่อยให้ระบบวิ่ง งานที่ย้อนยากให้คนตัดสิน การกด merge อยู่ฝั่งหลัง
ระบบที่ดีไม่ได้แปลว่าคนหลุดออกจากวง แต่แปลว่าคนไปยืนตรงจุดที่สำคัญที่สุดจุดเดียว คือก่อนของจะเข้าแบบย้อนไม่ได้
ช่วงที่ 4เอาไปใช้กับงานของคุณ
หลักสามข้อที่ถอดไปใช้ได้เลย
- ย้ายบริบทออกจากหัว ไปไว้บนกระดาน ถ้าต้องจำเองว่าใครทำอะไรถึงไหน แปลว่ายังไม่สเกล ให้สถานะงานอยู่ในที่ที่ทุกตัวอ่านร่วมกันได้
- แยกพื้นที่ทำงานให้ทุก worker ขนานกันได้เพราะแต่ละตัวมีสำเนาของตัวเอง ไม่ใช่เพราะตกลงกันว่าจะไม่ชน การแยกเป็นหน้าที่ของตัวจัดคิว ไม่ใช่ความมีวินัยของ worker
- คนตรวจคนละเครื่องยนต์ คนกด merge คือคน ความเร็วมาจาก agent ความน่าเชื่อมาจากด่านตรวจที่มองคนละมุม กับคนที่ยืนเฝ้าจุดย้อนยาก
เริ่มยังไงดี
ไม่ต้องสร้างระบบเต็มตั้งแต่แรก เริ่มจากของที่มีอยู่แล้วก่อน
- หยิบงานที่เคยสั่ง AI ทำทีละตัว แล้วลองแตกเป็นการ์ดย่อยด้วยมือ ดูว่าใบไหนทำขนานกันได้จริง
- ก่อนปล่อยสองตัวทำพร้อมกัน ให้แต่ละตัวอยู่คนละ git worktree ลองดูว่ามันไม่แก้ทับกันแล้วจริงไหม
- พองานเสร็จ อย่าเพิ่งรวมเข้าโค้ดหลักเอง ให้ AI อีกตัว (คนละเครื่องยนต์ถ้าทำได้) อ่านทวนก่อน แล้วคุณเป็นคนกดรวมเอง
แค่รอบเดียวก็จะเห็นเองว่า ตัวที่เปลี่ยนเกมไม่ใช่ "AI เก่งขึ้น" แต่เป็นกระดานกับการแยกพื้นที่ ที่ทำให้หลายตัวเดินไปด้วยกันได้โดยไม่ต้องมีเราคอยถือทุกอย่างไว้ในหัว
ส่วนของจริงที่ทำให้ทั้งหมดนี้เดินเองได้ ตั้งแต่ตัวจัดคิวที่แจกการ์ดและคุมเวลา ไปจนถึงการสลับเครื่องยนต์ตามบทบาท กับการแยก worktree ไม่ให้ปนกัน ขอเก็บไว้เล่าต่อในบทความหน้าของซีรีส์นี้
- แนวคิดสถาปัตยกรรม fleet กับการวาง Hermes ทั้งหมดในบทความนี้ เราเรียนมาจาก workshop ของคุณนัท ผู้สร้างระบบ Oracle แวะกลุ่มของแกได้ที่ กลุ่ม Oracle ของคุณนัท
- Hermes เป็นโครงการโอเพนซอร์ส nousresearch/hermes-agent
- ตอนนี้ แพตเทิร์น Kanban swarm (กำลังอ่านอยู่)
- ต่อไป ตัวตนของ agent ไม่ใช่เครื่องยนต์ของมัน สลับโมเดลโดยไม่เสียตัวตน
- ต่อไป การแยกพื้นที่คือหน้าที่ของตัวจัดคิว เรื่องเล่าจากตอน worktree ปนกัน
- อ่านเส้นแบ่งคนกับ AI ได้ที่ งานไหนให้ AI ทำเอง งานไหนต้องให้คนเคาะ
- เลือกโมเดลให้ตรงงาน อ่าน ทำไมโมเดลที่เก่งสุดมักเป็นตัวที่ผิดงาน