รัน AI coder ทั้งกองพร้อมกัน
แล้วเพิ่งรู้ว่าของแพงไม่ใช่ตัว coder

วันหนึ่งเรามีสคริปต์ค้างอยู่ 3 ไฟล์ที่ต้องแก้คล้ายๆ กัน แทนที่จะนั่งแก้ทีละไฟล์ เราสั่ง AI coder 3 ตัวให้ลงมือพร้อมกัน ตัวละไฟล์ แต่ละตัวทำงานในพื้นที่ของตัวเอง ไม่ชนกัน ไม่กี่นาทีต่อมาก็ได้ pull request กลับมา 3 อัน แยกไฟล์ พร้อมรีวิว

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

ช่วงที่ 1ตัว coder ไม่ใช่ต้นทุนที่แท้จริง

คนส่วนใหญ่คิดว่าการรัน AI ให้เขียนโค้ดเยอะๆ คือการจ่ายต่อโทเคนที่พุ่งขึ้นเรื่อยๆ เพราะภาพในหัวคือการต่อ API ที่คิดเงินตามการใช้ แต่ coder ที่เรารันไม่ได้ต่อแบบนั้น เรารันผ่าน Hermes ซึ่งเป็นเฟรมเวิร์กสำหรับรัน AI agent ตัว Hermes เป็นคนจัดการว่าจะเอาเครื่องยนต์ตัวไหนมาขับ coder เครื่องยนต์ตรงนี้ก็คือโมเดลเบื้องหลังที่ทำงานจริง และเครื่องยนต์ที่เราเสียบไว้ก็ล็อกอินด้วย subscription รายเดือนที่จ่ายอยู่แล้ว ไม่ใช่ API key ที่คิดเงินเป็นโทเคน ผลคือจะปล่อย 1 ตัวหรือ 3 ตัวพร้อมกัน ค่าใช้จ่ายต่อรอบก็แทบไม่ต่างกัน

แล้วต้นทุนจริงไปอยู่ที่ไหน อยู่ที่ตัวเราเอง รอบแรกๆ เราเฝ้า coder ด้วยการ ssh เข้าไปเช็กสถานะซ้ำๆ ทุกไม่กี่วินาที การวิ่งกลับไปกลับมาแบบนั้นต่างหากที่กินทรัพยากร ไม่ใช่ตัว coder ทางแก้เลยไม่ใช่ลดจำนวน coder แต่เป็นเลิกเฝ้าเอง แล้วให้มีตัวจัดคิวคอยสั่งงานและตัดจบให้อัตโนมัติ คนเป็นคนตั้งโจทย์และตัดสินใจ ไม่ใช่คนนั่งจ้อง

พอเห็นภาพนี้ การปล่อย coder ทำงานพร้อมกันหลายตัวเลยไม่ใช่เรื่องฟุ่มเฟือยอย่างที่กลัว ตัว coder ถูกและทดแทนกันได้ ของแพงคือเวลาและความสนใจของคน

ช่วงที่ 2ของถูกที่ปล่อยพร้อมกันได้ ต้องมีคนตรวจที่ไม่ใช่คนเขียน

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

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

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

🔗 ทำไมตัวรีวิวที่เป็นคนละเครื่องยนต์ถึงสำคัญ อ่าน Codex รีวิวโค้ดที่ Claude Code เขียน

ช่วงที่ 3คนถือสิทธิ์ merge ไว้เสมอ และแยกพื้นที่ไม่ให้ชนกัน

ปล่อย coder ทำงานพร้อมกัน มีตัวรีวิวคั่นแล้ว ยังเหลือเส้นสุดท้ายที่ต้องลากให้ชัด คือใครเป็นคนกด merge เข้าโค้ดหลัก คำตอบของเราคือคน ไม่ใช่ AI ตัวไหนเลย coder เขียนได้ ตัวรีวิวติได้ แต่คนเป็นคนตัดสินใจว่าจะรับเข้าจริงไหม เราเรียกด่านสุดท้ายนี้ว่า Gate A ไม่ใช่เพราะไม่เชื่อ AI แต่เพราะการรับโค้ดเข้าระบบหลักเป็นการตัดสินใจที่ย้อนยาก ควรมีคนรับผิดชอบจุดนั้นเสมอ

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

🔗 วิธีแยกพื้นที่ไม่ให้ agent ชนกัน อ่าน git worktree กับการรัน AI agent หลายตัวพร้อมกัน

สรุปโครงที่เอาไปลองเองได้

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

ลองเริ่มจากเล็กๆ ก่อน ไม่ต้องมีทั้งกองตั้งแต่วันแรก

1. coder ตัวเดียว รันบน subscription ที่จ่ายอยู่แล้ว แทนที่จะต่อ API ที่คิดเงินตามโทเคน
2. ตัวรีวิวอีกตัว ที่ไม่ใช่ตัวเขียน คอยอ่านและติก่อนเสมอ
3. คนถือสิทธิ์ merge ไว้เอง ที่เหลือให้ตัวจัดคิวสั่งงานแทนการนั่งเฝ้า

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