Skip to main content

Multi-Agent Dev Workflow Diary: เมื่อผมมี AI 2 ตัวช่วยเขียน code (นานาโกะ + Kimi)

· 15 min read
Kongvut Sangkla
Kongvut Sangkla
Author

สารบัญ

เมื่อก่อนตอนผมเขียน code ผมทำคนเดียวทุกอย่าง - เขียนเอง, test เอง, debug เอง, deploy เอง ตอนนี้ workflow เปลี่ยนไปเยอะ: ผมมี AI 2 ตัว ช่วยทำงาน - นานาโกะ ช่วย verify + เขียน ticket, Kimi ช่วยเขียน code - แล้วผมเป็นคน "design + decide + review" ทั้งหมด

มันไม่ใช่ "AI แทน developer" - แต่เป็น "AI เป็น co-worker" ที่ต้องมี workflow ที่ชัดเจน ไม่งั้นจะกลายเป็น chaos วันนี้เล่าให้ฟังว่า setup, workflow, และ lessons learned จากการทำงานแบบนี้มาเกือบอาทิตย์

TL;DR​

ผมใช้ AI 2 ตัว (นานาโกะ + Kimi) ทำงานร่วมกันแบบ ticket-driven workflow มาเกือบอาทิตย์ — นานาโกะช่วย research + verify, Kimi ช่วย implement code ส่วนผมทำหน้าที่ design + review เท่านั้น ผลลัพธ์คืองานคุณภาพดีขึ้น แต่ต้องยอมรับ coordination overhead และ latency ~70 นาทีต่อ task กุญแจสำคัญคือ "1 ticket = 1 concern" และ "human ต้องเป็นเจ้าของการตัดสินใจเสมอ"

เมื่อก่อน: Developer คนเดียว​

ก่อนจะมี AI agents ผมทำงานแบบ classic:

Pain points:

  • Context switching เยอะ (debug + deploy + monitor)
  • บางทีเขียน 2-3 ชม. แล้วรู้ว่า requirement ผิด
  • อดนอนจนเป็นเรื่องปกติ

ตอนนั้นผมคิดว่า "นี่คือชีวิต developer" - ทุกคนเป็นแบบนี้ แต่พอได้ลองใช้ AI agents จริงๆ ผมเริ่มเข้าใจว่า ส่วนใหญ่ของเวลาไม่ได้อยู่ที่ "เขียน code" แต่อยู่ที่ "คิด + verify + debug" - และ AI ช่วยตรงนี้ได้

The Setup: ใครทำอะไร​

ตอนนี้ผมมี AI 2 ตัวที่ทำงานคนละแบบ - ถ้าแยกหน้าที่ไม่ชัดเจน = chaos

Note: กุญแจสำคัญคือ "ใครถนัดอะไร" - นานาโกะทำงานเร็ว (7-11s) เหมาะกับ verify + ticket writing Kimi ใช้เวลานานกว่า (70 นาที) แต่เขียน code ยาวๆ ได้ครบ ส่วนเราเป็นคน decide อย่างเดียว - ไม่มี AI ตัวไหนทำ design decisions ได้ดีเท่าคน

Why 2 Agents ไม่ใช่ 1?​

คำถามแรกที่หลายคนถาม: "ใช้แค่ Claude Code หรือ Cursor ตัวเดียวไม่ได้เหรอ?" - คำตอบคือ ได้ แต่ผมเลือกแบบนี้เพราะ:

Note: Multi-agent ไม่ใช่ "always better" - มัน trade-off ระหว่าง cost/specialization กับ coordination overhead ถ้า task เล็กๆ ตัวเดียวเร็วกว่า แต่ถ้า task ใหญ่หรือต้อง audit แบบจริงจัง = 2 layers คุ้มกว่า

Ticket-Driven Workflow - หัวใจของระบบ​

ผมเรียนรู้จากประสบการณ์ว่า ถ้าไม่มี ticket → AI จะ hallucinate หรือทำผิดทิศ เลยใช้ pattern "Ticket-Driven Development" ที่เขียน context ทั้งหมดลงไฟล์ก่อน แล้ว AI ค่อยทำตาม

Note: เขียน context ทั้งหมดลงไฟล์ ไม่ใช่ chat - เพราะ AI ไม่ retain memory ระหว่าง session ถ้า chat ไป 3-4 รอบ context จะหาย Ticket file เป็น "external memory" ที่ทั้งคนและ AI อ่านได้

ทำไม "ไม่ bundle tasks"​

ตอนแรกผมเคยส่ง Kimi 1 ticket ใหญ่ๆ ที่มี 3-4 changes ผลคือ:

Note: "ทำทีละอย่าง = เร็วกว่า" - ฟังดูขัดความรู้สึก แต่เป็นความจริง เพราะเมื่อ error เกิด Kimi ต้องเริ่ม debug จาก context ทั้งหมด - แต่ถ้าแยก ticket context แคบลง debug เร็วกว่า และ error logs อ่านง่ายกว่า

Real Example: V3 → V4 Trading Bot Journey​

นี่คือตัวอย่างจริงๆ ของ workflow นี้ - พัฒนา trading bot V3 ไป V4

Background​

T1: นานาโกะ analyze (5 min)​

Kimi execute T1 (70 min)​

T2: นานาโกะ verify (5 min)​

T3: Kimi implement (70 min)​

Review + Commit (เรา, 10 min)​

$ git status
On branch main
Changes:
  M  src/trading/strategy.ts
  M  src/trading/config.ts
  ?? reports/v4-backtest.md

$ git diff src/trading/strategy.ts
# อ่าน actual diff - ตรวจว่า logic ตรงตามที่คุย
# ตรวจ edge cases: ถ้า confidence = 60 boundary → ทำอย่างไร
# ตรวจ config validation: position size > balance → reject

$ cat reports/v4-backtest.md
# อ่าน report - V3 baseline: 39 trades, $5.20 net
#                    V4: 31 trades, $7.80 net (+50%!)

$ # Open follow-up tickets ถ้าเจอ issue
$ # เช่น Ticket T4: "Position size > balance" edge case fix

$ git add -A
$ git commit -m "v4: bigger position + LLM confidence filter (+50% PnL)"

Note: ขั้นตอน review เป็นเรื่องที่ "AI ไม่ทำ" 100% - เราต้องอ่าน diff เอง, คิดเอง, decide เอง AI เป็นแค่ "คนเขียน code" ส่วน "หัวหน้า" คือเรา

Lessons Learned - 5 Patterns ที่ได้จาก Multi-Agent​

หลังจากทำงานแบบนี้มาเกือบอาทิตย์ ผมสรุป patterns ที่ work จริง:

Pattern 1: "งานแยก ticket = เร็วกว่า"​

Pattern 2: "นานาโกะ verify Kimi เสมอ"​

Note: 2 AI layers ไม่ซ้ำซ้อน - นานาโกะ catch ได้สิ่งที่ Kimi miss (เช่น logic gap ใน Q4) เพราะ model คนละตัว pattern การอ่าน requirement ต่างกัน

Pattern 3: "70 นาที realistic expectation"​

Pattern 4: "ไม่ให้ AI decide design"​

Pattern 5: "เก็บ ticket file เป็น audit trail"​

Note: Ticket files ไม่ใช่แค่ "งานที่ต้องทำ" - มันคือ "decision history" ถ้า 6 เดือนข้างหน้ามีคนถามว่า "ทำไม trade logic เป็นแบบนี้" - คำตอบอยู่ใน T1-T4 แล้ว

When Multi-Agent Works vs Doesn't​

ไม่ใช่ทุกงานที่ multi-agent เหมาะ - ผมเจอทั้งเคสที่ work และที่พัง

✅ Works Well​

❌ Doesn't Work​

Cost Reality Check​

คำถามที่หลายคนถาม: "แพงไหม?" - มาดูตัวเลขจริง

Note: $50/เดือน ถูกกว่า coffee เมื่อเทียบกับเวลาที่ประหยัดได้ - แต่ "cost" ไม่ใช่แค่เงิน ยังมี "context switch overhead" และ "ticket writing time" ที่ต้องคำนวณด้วย

Honest Trade-offs​

ไม่อยากให้ภาพว่า "multi-agent = perfect" - มันมี cost แฝงที่ต้องยอมรับ

Note: "AI 2 ตัว" ไม่ได้แปลว่า "เร็วขึ้น 2 เท่า" มันแปลว่า "scale ได้มากขึ้น" แต่ latency ต่อ task อาจช้าลงถ้าไม่ระวัง coordination

Quick Reference: When to Use Each Agent​

Conclusion - มันไม่ใช่ Magic​

ผมเชื่อว่า multi-agent workflow ไม่ใช่ทางลัด - มันเป็น operating model ใหม่ ที่ต้อง invest เวลาเรียนรู้เหมือนที่เรา invest เวลาเรียน React เมื่อ 5 ปีก่อน

ถ้าใครกำลังจะลอง multi-agent แบบนี้ ผมแนะนำ:

  1. Start with 1 agent - ใช้ Claude Code หรือ Cursor ตัวเดียวก่อน
  2. Add second agent เมื่อรู้ limitation - เมื่อรู้สึกว่า "AI นี้ verify ตัวเองไม่ได้"
  3. Write tickets religiously - ไม่งั้น context หาย
  4. Set time expectations - อย่าคาดว่า AI จะเร็วแบบ 5 นาที
  5. Keep human in the loop - AI เป็น co-worker ไม่ใช่ boss

ที่สำคัญที่สุด: "AI เป็น co-worker ไม่ใช่ replacement" - แต่ละตัวมีจุดแข็งจุดอ่อนต่างกัน การจัดให้ทำงานร่วมกันแบบมีโครงสร้าง มัน work จริง แต่ต้องมี "คน" เป็นคนคุมทั้งหมด ไม่งั้นจะกลายเป็น 2 AI ที่คุยกันเองแล้วก็ hallucinate ไปด้วยกัน

ถ้ามีคำถามเกี่ยวกับ workflow ตัวไหน ถามได้เลยครับ!

อ้างอิง:

Related Blogs​

  • Honcho Memory Layer - memory layer ที่ผมใช้กับ Hermes Agent (นานาโกะ) เพื่อให้ agent จำข้าม session
ai-agentmulti-agentworkflowkiminanakodev-toolsdevops
แชร์บทความ
☕

เนื้อหานี้มีประโยชน์ไหม? ช่วยสนับสนุนค่ากาแฟให้ผู้เขียนสักแก้ว

Buy Me a Coffee
Loading...