ครั้งหนึ่งเราปล่อย AI coder หลายตัวให้ช่วยเคลียร์งานค้างพร้อมกัน แต่ละตัวรับงานคนละชิ้น คิดว่าทำขนานกันแบบนี้จะเร็วกว่าหลายเท่า
พอผลออกมา PR แรกที่มันส่งกลับมา กลับมีไฟล์ที่ไม่เกี่ยวกับงานนั้นปนมาตั้งสามไฟล์ เป็นไฟล์ของงานที่ตัวอื่นกำลังทำอยู่คนละชิ้น
สาเหตุไม่ได้อยู่ที่ AI ตัวไหนทำพลาด แต่อยู่ที่เราปล่อยให้ทุกตัวทำงานในโฟลเดอร์เดียวกัน พอหลายตัวแก้ไฟล์ในที่เดียวพร้อมกัน งานก็เหยียบกันเอง ใครเซฟทีหลังก็ทับของคนก่อน แล้วเวลาเก็บงานไปส่ง มันก็คว้าทุกอย่างที่เปลี่ยนในโฟลเดอร์ติดมาด้วย ทั้งที่ครึ่งหนึ่งไม่ใช่งานของมัน
บทเรียนของเรื่องนี้คือ การแยกงานให้ไม่ปนกัน ไม่ใช่หน้าที่ของ worker แต่ละตัว มันเป็นหน้าที่ของคนจัดคิว
ช่วงที่ 1AI หลายตัว โฟลเดอร์เดียว เหยียบกันเอง
เวลามีงานค้างเยอะ ๆ การให้ AI หลายตัวลุยพร้อมกันฟังดูเป็นความคิดที่ดี และมันก็ดีจริง ถ้าแต่ละตัวมีที่ทำงานของตัวเอง ปัญหาจะเริ่มตอนที่ทุกตัวใช้ที่เดียวกัน
โค้ดหนึ่งโปรเจกต์ก็เหมือนโต๊ะทำงานตัวเดียว ถ้าให้คนคนเดียวนั่งทำทีละงานก็ไม่มีปัญหา แต่พอจับคนสี่ห้าคนมานั่งโต๊ะเดียวกัน แล้วต่างคนต่างหยิบของมาวางมาแก้พร้อมกัน ของมันก็ปนกันเป็นเรื่องธรรมดา ไม่ใช่เพราะใครซุ่มซ่าม แต่เพราะพื้นที่มันมีชุดเดียว
กับ AI ยิ่งเนียนกว่านั้น เพราะมันไม่ได้บ่นว่าของมันหาย มันแค่ทำงานของมันต่อไปบนสภาพโฟลเดอร์ที่ตัวอื่นเพิ่งเปลี่ยนไป แล้วพอถึงเวลาส่งงาน มันก็เหมาทุกความเปลี่ยนแปลงที่เห็นในโฟลเดอร์ใส่กล่องเดียวกันมาให้ ผลคือ PR ที่ควรมีไฟล์เดียว กลับมีของคนอื่นติดมาด้วย
ช่วงที่ 2ทำไม "สั่งให้ระวัง" ถึงไม่พอ
ทางแก้แรกที่คนมักนึกถึงคือไปบอก AI ทุกตัวว่า "อย่าไปยุ่งกับไฟล์ของงานอื่นนะ" แต่นั่นคือการฝากความหวังไว้กับวินัยของแต่ละตัว
การฝากความหวังไม่ใช่การป้องกัน ตราบใดที่ทุกตัวยังเอื้อมถึงไฟล์เดียวกันได้ โอกาสที่มันจะเผลอแตะของผิดก็ยังอยู่ ทุกครั้งที่ปล่อยให้มันรันใหม่ ความเสี่ยงก็กลับมาใหม่ ความปลอดภัยที่ขึ้นกับการที่ทุกตัวต้องทำถูกทุกครั้ง ไม่ใช่ความปลอดภัย มันแค่ยังไม่พังเท่านั้น
ของแบบนี้ต้องแก้ที่โครงสร้าง ไม่ใช่ที่คำสั่ง ถ้าออกแบบให้ AI ตัวหนึ่งไม่มีทางมองเห็นหรือแตะงานของอีกตัวได้เลย การเขียนทับกันก็ไม่ใช่แค่ "ขอให้ไม่เกิด" แต่มันเกิดขึ้นไม่ได้ตั้งแต่ต้น
ช่วงที่ 3วิธีแก้ หนึ่งงาน หนึ่ง worktree
ข่าวดีคือ git มีเครื่องมือสำหรับเรื่องนี้อยู่แล้ว เรียกว่า worktree คือ working directory แยกอีกอันที่ชี้กลับไปที่ repo เดียวกัน แต่ทำงานอยู่บน branch ของตัวเอง โฟลเดอร์คนละอัน branch คนละอัน ไม่ทับกัน
หัวใจอยู่ที่ใครเป็นคนสร้างมัน คนจัดคิว (orchestrator) ตัวที่แจกงานให้ AI แต่ละตัว ต้องเป็นคนสร้าง worktree แยกให้ทีละงาน แตกออกจาก main ก่อน แล้วค่อยส่ง AI เข้าไปทำในของมัน ไม่ใช่ปล่อยให้ AI แต่ละตัวไปสร้างที่ทำงานของตัวเองเอา เพราะถ้าฝากให้ worker ทำ ก็กลับไปฝากความหวังไว้กับวินัยอีก
พอวางแบบนี้ AI แต่ละตัวเปิดมาก็เห็นแต่งานของตัวเอง จะแก้ทับใครก็ไม่ได้ เพราะไฟล์ของคนอื่นไม่ได้อยู่ในสายตามันตั้งแต่แรก เวลาเก็บงานไปส่ง มันก็คว้าได้แค่ของในโฟลเดอร์ตัวเอง
ผลของจริงหลังเปลี่ยนมาทำแบบนี้ คือรอบสุดท้าย 13 งานที่รันพร้อมกัน ได้ PR สะอาดไฟล์เดียวต่องาน ครบทั้ง 13 อัน จากเดิมที่ของปนกันมั่วใน PR เดียว ความต่างไม่ได้มาจากการสั่งให้ AI ระวังมากขึ้น แต่มาจากการที่มันไม่มีทางไปแตะของคนอื่นได้เลย
ช่วงที่ 4หลักที่กว้างกว่า worktree
เรื่องนี้ไม่ได้จบแค่ไฟล์ หลักเดียวกันคือ การแยกให้ไม่ปนกันเป็นหน้าที่ของคนจัดคิว ใช้ได้กับเรื่องสิทธิ์ด้วย
ตอนให้ AI worker เปิด PR เอง มันไปติดตัวกันพลาดของระบบความปลอดภัยบนเครื่อง ราวกันตกตัวเดียวกับที่คอยกันคำสั่งอันตรายอย่าง rm -rf ทางที่ผิดคือไปปลดล็อกให้มันผ่านตรงนั้น เพราะนั่นทำให้กติกากันพลาดอ่อนลงทั้งระบบ เพื่อความสะดวกแค่เรื่องเดียว
ทางที่ถูกคือย้ายงานที่ต้องใช้สิทธิ์ ไปไว้กับคนที่ควรถือสิทธิ์นั้น แบ่งตามระดับ worker ทำงานตัดสินใจในพื้นที่ปิดแยกของมัน (sandbox) แก้ แล้ว commit แล้ว push ส่วนงานที่ต้องใช้สิทธิ์สูงกว่าอย่างการเปิด PR ให้ตัวจัดคิวที่เชื่อถือได้เป็นคนทำ แล้วการกด merge จริงเป็นหน้าที่คน ราวกันตกไม่ต้องอ่อนลงเลยสักนิด แค่ย้ายงานไปให้ถูกมือ ตรงไหนให้ AI เดินเอง ตรงไหนต้องให้คนเคาะ เป็นเส้นแบ่งเดียวกับที่เคยเขียนไว้เรื่อง งานไหนให้ AI ทำเอง งานไหนต้องให้คนเคาะ
ทั้งสองเรื่องคือหลักเดียวกัน อย่าหวังให้แต่ละตัวทำตัวดี ออกแบบให้มันทำตัวไม่ดีไม่ได้ตั้งแต่แรก
ช่วงที่ 5เอาไปใช้
ถ้ากำลังจะให้ AI หลายตัวทำงานพร้อมกัน ลองถามตัวเองข้อเดียวก่อน แต่ละตัวมีที่ทำงานของตัวเองจริงไหม หรือทุกตัวแชร์ที่เดียวกันอยู่
ถ้าแชร์กันอยู่ อย่าเพิ่งปล่อยรันพร้อมกัน แยกที่ให้มันก่อน หนึ่งงาน หนึ่ง worktree แตกจาก main ให้คนจัดคิวเป็นคนสร้าง ไม่ใช่ฝากให้ worker แล้วค่อยส่งงานเข้าไป
หลักนี้เอาไปคิดต่อกับทุกอย่างที่ของใช้ร่วมกันได้ ไม่ว่าจะเป็นไฟล์ สิทธิ์ หรือทรัพยากรอื่น ถ้าหลายตัวเอื้อมถึงของชิ้นเดียวกันได้พร้อมกัน ไม่ช้าก็เร็วมันจะเหยียบกัน ทางแก้ที่เชื่อถือได้ไม่ใช่การขอให้ทุกตัวระวัง แต่คือการออกแบบให้มันแยกขาดจากกันตั้งแต่ต้น
- ตัวเลข 13 งาน ได้ PR ไฟล์เดียวครบทั้ง 13 อัน เป็นผลที่วัดจากการรัน fleet จริงของเราเอง ไม่ใช่ตัวเลขอ้างอิงจากที่อื่น
- แนวคิด fleet กับการวางตัวจัดคิว เราเรียนมาจาก workshop ของคุณนัท ผู้สร้างระบบ Oracle แวะกลุ่มของแกได้ที่ กลุ่ม Oracle ของคุณนัท
- git worktree เป็นคำสั่งมาตรฐานของ git อ่านเอกสารทางการได้ที่ git-scm.com/docs/git-worktree
- ตอนนี้ การแยกพื้นที่คือหน้าที่ของตัวจัดคิว เรื่องเล่าจากตอน worktree ปนกัน (กำลังอ่านอยู่)
- ก่อนหน้า ภาพรวมทั้งทีม อ่าน สร้างทีม AI coding agent: แพตเทิร์น Kanban swarm
- ตัวกันพลาดคนละเครื่องยนต์ก่อน merge อ่าน ให้ AI อีกตัวรีวิวโค้ดก่อนคนกด merge
- ทำไมปล่อย coder เป็นกองถึงไม่แพง อ่าน AI coding agents ตัว coder ไม่ใช่ต้นทุนที่แพงที่สุด
- เส้นแบ่งคนกับ AI อ่าน งานไหนให้ AI ทำเอง งานไหนต้องให้คนเคาะ
- แยกตัวตน เครื่องยนต์ คนจัดคิว อ่าน อย่าแต่งงานกับโมเดลเดียว
- มอบงานให้ AI fleet ผ่าน task board อ่าน เลิกสั่ง AI ทีละแชท เขียนงานลงบอร์ด แล้วให้มันมาหยิบเอง
บทความนี้เป็นหนึ่งชั้นใน สถาปัตยกรรม AI agent ระดับ production ทั้ง 7 ชั้น