เวิร์กโฟลว์ VM0 dev: จัดการ AI agent แบบทีมงาน

ในทีม VM0 dev นักพัฒนาแต่ละคนจะทำงานกับ Claude Code หลายอินสแตนซ์พร้อมกัน โดยปกติมากกว่าแปดอินสแตนซ์

เราปฏิบัติต่อ Claude Code เหมือนกับนักพัฒนาจริง (ใช่แล้ว บริษัทเราตั้งชื่อแบบขำ ๆ ว่า AI Colleagues Co!)

ด้วยเหตุนี้ ปรัชญาการออกแบบเวิร์กโฟลว์ VM0 dev จึงสะท้อนแนวปฏิบัติการบริหารทีมแบบคลาสสิกในวิศวกรรมซอฟต์แวร์

เราใช้ GitHub Issues เพื่อติดตามงาน, Pull Requests สำหรับรีวิวโค้ดและการรวมโค้ด และ GitHub Actions สำหรับงานอัตโนมัติ ในช่วงสองเดือน ระบบนี้ช่วยให้เราส่ง 404 รีลีส และเขียนโค้ดได้มากกว่า 230,000 บรรทัด

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

เวิร์กโฟลว์ dev ขับเคลื่อนด้วย AI ในทางปฏิบัติ

เมื่อคุณประสานงาน AI agent หลายตัวพร้อมกัน คอขวดไม่ได้อยู่ที่ว่าโมเดลจะเขียนโค้ดได้หรือไม่ แต่คือ ภาระทางความคิดของมนุษย์

เวิร์กโฟลว์นี้ประกอบด้วยคำสั่ง slash 14 คำสั่ง แบ่งเป็นสามชั้น: Deep Dive, การจัดการ Issue และการจัดการ PR

มาดูกันก่อนว่าเวิร์กโฟลว์ของผมหน้าตาเป็นอย่างไร และฟีเจอร์หนึ่งมักถูกสร้างขึ้นอย่างไร

1. ปรับความต้องการให้ตรงกัน

   มนุษย์เปิดเซสชัน Claude และเริ่มด้วย /deep-research Claude จะรวบรวมข้อมูลจากโค้ดเบส เอกสาร และบริบทที่เกี่ยวข้อง เราจะพูดคุยผลลัพธ์และปรับความเข้าใจว่ากำลังแก้ปัญหาอะไร

2. สำรวจแนวทางแก้ไข

   ใช้ /deep-innovate ให้ Claude เสนอแนวทางเป็นไปได้หลายแบบ พร้อมข้อดีข้อเสีย เราจะพูดคุย คัดเลือก และเลือกทิศทาง

3. สร้าง Issue

   เราสร้าง GitHub issue โดยใช้ /issue-create มนุษย์จะตรวจสอบ issue เพื่อให้แน่ใจว่าความต้องการถูกบันทึกชัดเจน

4. วางแผนและอนุมัติ

   ใช้ /issue-plan ให้ Claude ทำงานต่อ Claude จะรัน deep-dive workflow แบบเต็มโดยอัตโนมัติและโพสต์ผลลัพธ์ลงใน issue รวมถึง:

   1. ข้อมูลที่ค้นพบจาก /deep-research
   2. การเปรียบเทียบจาก /deep-innovate
   3. แผนการนำไปใช้ที่ชัดเจนจาก /deep-plan

5. ลงมือทำ

   หลังอนุมัติ /issue-action ให้ Claude ลงมือทำตามแผน เขียนเทสต์ เปิด PR และตรวจสอบให้ CI ผ่าน

6. รีวิวและรวมโค้ด

   เราใช้ /pr-review สำหรับรีวิวแบบมีโครงสร้าง แล้วจึงรีวิวรอบสุดท้ายโดยมนุษย์ก่อนจะรวมโค้ด

   มนุษย์จะเข้ามาแทรกในสามจุดตรวจ: ความต้องการ, ทิศทาง, และการยอมรับ ส่วนอื่น ๆ ทำงานอัตโนมัติ

เปลี่ยนมุมมอง: คุณคือหัวหน้าทีม AI developer

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

ถ้าไม่มีเครื่องมือภายนอก ผมไม่สามารถจัดการ Claude หลายอินสแตนซ์พร้อมกันได้เลย นั่นแหละถึงเข้าใจว่านี่ไม่ใช่ปัญหา AI แต่เป็นปัญหาการบริหารจัดการ

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

ประสบการณ์บริหารโครงการและทีมงานสิบปี กลับมามีความหมายในบริบทใหม่นี้ เมื่อปฏิบัติต่อ Claude เป็นสมาชิกทีม และ GitHub เป็นพื้นที่สื่อสารและบริหารร่วมกัน ทั้งระบบก็กลับมาควบคุมได้อีกครั้ง

หัวหน้าทีมที่ดีรู้ว่าเมื่อไรควรเข้าไปมีส่วนร่วม และเมื่อไรควรถอยออก:

จุดตรวจ	สิ่งที่ผมทำ	สิ่งที่ AI ทำ
ความต้องการ	ปรับปัญหาให้ตรงกัน ชี้แจงขอบเขต	ค้นคว้าโค้ดเบส รวบรวมบริบท
ทิศทาง	ตรวจสอบผลลัพธ์ อนุมัติแนวทาง	เสนอแนวทาง 2-3 ประเมินข้อดีข้อเสีย
การยอมรับ	ตรวจ PR ตรวจสอบคุณภาพ	ลงมือทำ ทดสอบ แก้ไข CI

นี่สะท้อนการทำงานของทีมซอฟต์แวร์ที่มีประสิทธิภาพ ผมไม่ได้จู้จี้กับ developer แต่ตั้งความต้องการให้ชัด ตรวจสอบการตัดสินใจสำคัญ และตรวจสอบผลลัพธ์สุดท้าย หลักการเดียวกันนี้ใช้ได้กับการจัดการ AI agent

deep dive flow บังคับให้คิดอย่างมีโครงสร้างและรอบคอบ

deep dive workflow บังคับให้คิดอย่างรอบคอบก่อนลงมือทำ บางครั้ง Claude เจอทางตัน เมื่อเกิดแบบนั้น เราจะบังคับให้ Claude หยุดคิด แล้วพูดคุยกันต่อ มีสามเฟส:

เฟส	คำสั่ง	วัตถุประสงค์	ผลลัพธ์
Research	/deep-research	รวบรวมข้อเท็จจริง เข้าใจบริบท	research.md
Innovate	/deep-innovation	สำรวจแนวทางหลายแบบ	innovate.md
Plan	/deep-plan	กำหนดขั้นตอนที่ชัดเจน	plan.md

แต่ละเฟสมีขอบเขตชัดเจน

• Research: ห้ามเสนอแนวทาง
• Innovate: ห้ามลงรายละเอียด
• Plan: ห้ามลงมือทำ

ข้อจำกัดเหล่านี้บังคับให้ Claude ใช้เหตุผลอย่างรอบคอบ แทนที่จะรีบเขียนโค้ดทันที ถ้าไม่มีข้อจำกัดนี้ มักจะพลาดกรณีขอบและปัญหาเชิงสถาปัตยกรรม!

ตัวอย่างการใช้งาน

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

สำหรับงานง่าย ๆ สามารถข้าม deep dive แล้วไปที่ /issue-create ได้เลย

สำหรับงานซับซ้อนที่มีความไม่แน่นอนทางเทคนิค deep dive จะช่วยให้คุณกับ Claude เข้าใจตรงกันก่อนเริ่มลงมือ

ใช้ GitHub เป็นหน่วยความจำร่วม

เครื่องมือ AI ส่วนใหญ่ถือว่าบริบทเป็นเรื่องชั่วคราว เมื่อเซสชันจบ ข้อมูลก็หายไป

VM0 ใช้ GitHub เป็นหน่วยความจำถาวร:

ฟีเจอร์ GitHub	สิ่งที่จัดเก็บ
Issue body	ความต้องการและการตัดสินใจ
Issue comments	ข้อมูลค้นคว้า ตัวเลือก แผนงาน
PR comments	รีวิวและสรุป
Labels	สถานะเวิร์กโฟลว์

นี่ก็แก้ปัญหาของมนุษย์ด้วย: การกู้คืนบริบท

เมื่อผมจัดการ Claude 8+ อินสแตนซ์ ผมจะได้รับแจ้งว่างานเสร็จแล้ว แต่ผมไม่สามารถย้อนดูจากบทสนทนาของ Claude ได้ว่ากำลังทำอะไร ตัดสินใจอะไรไปแล้ว หรือสถานะปัจจุบันคืออะไร

GitHub issues แก้ปัญหานี้ แต่ละ issue จะแสดง:

• ความต้องการเดิม
• ข้อมูลที่ค้นพบ (ค้นพบอะไรบ้าง)
• เฟส innovation (พิจารณาตัวเลือกอะไรบ้าง)
• แผนที่อนุมัติ (จะนำไปใช้อะไร)

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

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

ส่งต่องานระหว่าง agent

เพราะบริบททั้งหมดอยู่ใน GitHub งานจึงส่งต่อระหว่าง agent ได้อย่างราบรื่น:

• agent หนึ่งสร้าง issue หรือ PR
• อีก agent มาทำต่อโดยใช้ /deep-research issue 123 หรือ /issue-plan 123 หรือ /deep-research PR 124

สำหรับการสนทนายาว ๆ /issue-compact จะรวมทุกอย่างเป็น issue body ที่สะอาด ส่งต่อง่ายทั้งสำหรับมนุษย์และ AI

สรุปแพทเทิร์นเวิร์กโฟลว์

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

งานง่าย

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

ใช้เมื่อความต้องการชัดเจนและงานตรงไปตรงมา

งานซับซ้อน

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

วิธีนี้ช่วยป้องกันการเสียแรงกับแนวทางที่ผิด

งานขนาน

agent หลายตัวสามารถทำงานพร้อมกัน ขณะที่มนุษย์รีวิวแต่ละ checkpoint ที่เสร็จแล้ว ตรงนี้เวิร์กโฟลว์จะขยายขนาดได้ดีที่สุด

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

อ้างอิงคำสั่ง

คำสั่ง deep dive

คำสั่ง	วัตถุประสงค์
/deep-research	รวบรวมข้อมูล เข้าใจโค้ดเบส ห้ามเสนอแนวทาง
/deep-innovate	สำรวจแนวทาง 2-3 ประเมินข้อดีข้อเสีย ห้ามเขียนโค้ด
/deep-plan	สร้างขั้นตอนการนำไปใช้ที่ชัดเจน ห้ามลงมือทำ

คำสั่ง Issue

คำสั่ง	วัตถุประสงค์
/issue-create	สร้าง issue จากบริบทการสนทนา
/issue-bug	สร้าง bug report พร้อมขั้นตอนการทำซ้ำ
/issue-feature	สร้าง feature request ที่เน้นความต้องการ
/issue-plan	รัน deep-dive workflow แบบเต็ม โพสต์ผลลัพธ์ลง issue
/issue-action	ดำเนินการต่อหลังมนุษย์อนุมัติ
/issue-compact	รวม issue body + คอมเมนต์เพื่อส่งต่องาน

คำสั่ง PR

คำสั่ง	วัตถุประสงค์
/pr-check	ติดตาม CI pipeline แก้ไขอัตโนมัติ ลองใหม่สูงสุด 3 ครั้ง
/pr-review	รีวิว PR ทีละ commit เทียบกับมาตรฐานโครงการ
/pr-comment	สรุปการสนทนาเป็นคอมเมนต์ใน PR

เริ่มต้นใช้งาน

1. เริ่มจากงานง่าย: ใช้ /issue-create → /issue-plan → /issue-action กับงานแรกของคุณ
2. เพิ่ม deep dive สำหรับงานซับซ้อน: เมื่อความต้องการไม่ชัดหรือซับซ้อนทางเทคนิค ให้เริ่มที่ /deep-research
3. ขยายทีละน้อย: เพิ่ม Claude อินสแตนซ์เมื่อคุณคุ้นกับจังหวะการรีวิว
4. เชื่อมั่นในกระบวนการ: ให้ Claude ทำงานอัตโนมัติระหว่าง checkpoint

เวิร์กโฟลว์นี้ออกแบบให้ปรับใช้ได้ทีละขั้น คุณไม่จำเป็นต้องใช้คำสั่ง 14 ทั้งหมดตั้งแต่วันแรก เริ่มจาก flow issue พื้นฐาน แล้วค่อยเพิ่ม deep dive และงานขนานเมื่อมั่นใจ

ข้อควรพิจารณาเมื่อขยายขนาด: ถ้ามี agent มากขึ้น

เวิร์กโฟลว์นี้ผ่านการทดสอบกับ Claude 10+ อินสแตนซ์พร้อมกัน คำแนะนำของเรา:

• สูงสุด 10 agent: ทำงานร่วมกันอย่างใกล้ชิดได้สบาย
• เกิน 10: ไม่แนะนำ

ข้อจำกัดไม่ได้อยู่ที่เวิร์กโฟลว์ แต่อยู่ที่ความใส่ใจและคุณภาพการตัดสินใจของมนุษย์ เมื่อจัดการ agent เกิน 10 ตัว คุณจะกลายเป็นคอขวดที่ checkpoint และคุณภาพการตัดสินใจจะลดลง

หลักการ "ทีมสองถาดพิซซ่า" แบบคลาสสิกใช้ได้ที่นี่ ข้อจำกัดเดียวกับขนาดทีมมนุษย์ก็จำกัดจำนวน AI agent ที่คนหนึ่งจะบริหารได้อย่างมีประสิทธิภาพ

ตอนนี้ผมกำลังทดลองโครงสร้างทีมสองชั้น 8×8 เพื่อขยายเกิน 10 agent แต่ยังไม่มีแนวปฏิบัติที่ได้ผล จะมาเล่าเพิ่มเมื่อมีผลลัพธ์ที่ชัดเจน…

เวิร์กโฟลว์ VM0 dev เปลี่ยนวิธีคิดเกี่ยวกับการพัฒนาซอฟต์แวร์เมื่อ AI กลายเป็นส่วนหนึ่งของทีม

เมื่อคุณปฏิบัติต่อ AI agent เป็นสมาชิกทีม ไม่ใช่แค่เครื่องมือ ทุกอย่างจะลงตัว GitHub กลายเป็นหน่วยความจำร่วมของทีม Issue คือรายการงาน PR คือสิ่งส่งมอบ และคุณคือหัวหน้าทีมที่โฟกัสสถาปัตยกรรม ทิศทาง และคุณภาพ ขณะที่ทีม AI ของคุณดูแลการลงมือทำ

นี่คือวิธีที่เราส่ง 404 รีลีสใน 2 เดือน และเป็นวิธีที่คุณจะขยายการพัฒนาของคุณด้วย AI ได้เช่นกัน