อย่าใช้ AI ตัวเดียวทำทุกอย่าง: จัดทีมวิศวกร AI ตามจุดแข็งและราคา เหมือนจัดทีมคนจริง

Thesis: AI ตัวเดียวทำทุกบทบาท = แพงและแย่พร้อมกันทุกด้าน

ตอนแรกผมทำแบบที่ทุกคนทำ — เปิด AI ตัวที่เก่งที่สุดตัวเดียว แล้วให้มันทำทุกอย่าง: วางสถาปัตยกรรม, เขียนโค้ด, รีวิว, สรุป log ยาวๆ, จัดรูปแบบไฟล์. มันได้ผล แต่มันโง่ในเชิงเศรษฐศาสตร์: ผมจ่ายราคาโมเดล reasoning แพงสุดไปกับงานถูๆ อย่าง "สรุป diff" หรือ "จัด format" และในทางกลับกัน โมเดลตัวเดียวก็ไม่ได้เก่งทุกอย่างเท่ากัน.

บทเรียนที่เปลี่ยนวิธีทำงานผม: อย่ามอง AI เป็นพนักงานคนเดียวที่ทำทุกหน้าที่ — มองเป็น "ทีม" ที่มีหลายบทบาท แล้วจัดคน (โมเดล) ให้ตรงกับงานตามจุดแข็งและราคา เหมือนที่เราจัดทีมวิศวกรจริง ไม่มีใครให้ architect อาวุโสไปนั่งจัด indent โค้ดทั้งวัน.

แบ่งบทบาทตามจุดแข็ง ไม่ใช่ให้ตัวเดียวเหมาโหล

งานวิศวกรรมหนึ่งชิ้นมีหลายบทบาทที่ต้องการทักษะคนละแบบ. ผมแยกเป็นอย่างน้อย 4 role แล้ว assign โมเดลที่เหมาะกับแต่ละอัน:

• Architect / Planner — ตัดสินใจโครงสร้าง, แตกงาน, ชั่งน้ำหนัก trade-off → ใช้โมเดล reasoning ที่แข็งที่สุด (แพงสุด แต่ใช้กับ "การตัดสินใจ" ที่ผิดแล้วเสียหายมาก)
• Implementer — เขียนโค้ดตามแผน → ใช้โมเดลสาย coding ที่ implement เก่ง/เร็ว ไม่ต้อง reasoning ลึกมาก
• Reviewer — ตรวจงานแบบ adversarial → ต้องเป็นคนละค่ายกับ implementer (เดี๋ยวอธิบาย)
• Summarizer / Bulk — อ่าน log/diff ยาว, สรุป, จัด format, งานปริมาณมาก → ใช้โมเดลที่ถูกและเร็วที่สุด

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

ราคาคือแกนออกแบบ ไม่ใช่เรื่องรอง — และระวัง "ภาษีคงที่" ต่อ agent

เมื่อจัดเป็นทีม ราคาต่อ token ของแต่ละโมเดลกลายเป็น "ต้นทุนพนักงาน" ที่ต่างกันหลายสิบเท่า. หลักคิดคือ route งานไปหาโมเดลที่ถูกที่สุดที่ยังทำงานนั้นได้ดีพอ — decision ราคาแพงให้ตัวเก่ง, bulk ราคาถูกให้ตัวประหยัด.

แต่มีกับดักที่คนมองข้าม: ทุก agent มี "ภาษีคงที่" (fixed tax) ต่อการเรียกหนึ่งครั้ง — ค่า system prompt, tool schema, การ hand off context เข้าไป. ถ้างานเล็กเกินไป (เช่นแก้ไฟล์เดียว 10 บรรทัด) ค่า overhead ในการส่งงานให้ agent อื่นทำแพงกว่าที่ประหยัดได้จากการใช้โมเดลถูก. กติกาที่ผมใช้:

function pickWorker(task) {
  // งานจิ๋ว → ทำเองในบริบทเดิม ไม่ต้อง handoff (overhead ไม่คุ้ม)
  if (task.files <= 2 && task.lines < 100) return "self";

  // จับคู่ role กับ cost tier
  if (task.role === "plan"   || task.role === "review") return "strong_reasoning";
  if (task.role === "implement")                        return "coder";
  if (task.role === "summarize" || task.role === "bulk") return "cheap_fast";
  return "default";
}

บทเรียน: การกระจายงานให้ทีมไม่ได้ฟรี — มันคุ้มก็ต่อเมื่องานใหญ่พอที่ค่าโมเดลจะกลบค่า handoff.

Handoff contract: ส่งต่องานด้วย "สัญญา" ไม่ใช่ยัด context กันมั่ว

ปัญหาใหญ่ของทีม (คนหรือ AI) คือรอยต่อ. ถ้า architect วางแผนเสร็จแล้วโยน context ดิบทั้งก้อนให้ implementer มันจะมั่ว — implementer ไม่รู้ว่าอะไรคือข้อกำหนดที่ห้ามแตะ อะไรคือรายละเอียดประกอบ. ทางแก้คือ handoff contract: แต่ละ role ส่งต่อด้วย output ที่มีโครงชัด ไม่ใช่ transcript ยาวๆ.

// architect → implementer: สัญญาชัด ไม่ใช่ context ทั้งกอง
{
  goal: "เพิ่ม rate limit ต่อ user ที่ endpoint X",
  constraints: ["ห้ามแตะ schema เดิม", "ต้อง backward-compatible"],
  acceptance: ["unit test ครอบ 3 เคส", "429 เมื่อเกินโควตา"],
  files_in_scope: ["src/middleware/rateLimit.ts"],
  out_of_scope: ["ระบบ auth", "billing"]
}

สัญญานี้ทำสองอย่าง: (1) implementer โฟกัสถูกจุด ไม่หลุด scope, (2) reviewer มี "เกณฑ์" ที่ชัดว่าจะตรวจอะไร — acceptance criteria กลายเป็น checklist ของ reviewer โดยตรง. รอยต่อที่มีสัญญาชัด คือสิ่งที่ทำให้ทีมส่งงานต่อกันได้โดยไม่ต้องเล่าเรื่องกันใหม่ทุกครั้ง.

Reviewer ต้องคนละค่ายกับ implementer

กฎเหล็กข้อเดียวที่ห้ามผ่อน: คนตรวจต้องไม่ใช่คน (หรือโมเดล) เดียวกับคนทำ. ถ้า implementer กับ reviewer เป็นโมเดลตัวเดียวกัน มันจะมี blind spot แบบเดียวกัน — bug ที่มันสร้าง มันก็มองไม่เห็นเวลาตรวจ. ในทีม AI ผมบังคับให้ reviewer เป็นคนละ model family กับ implementer เสมอ และ prompt ให้ "หาเรื่องให้เจอ" ไม่ใช่ "ช่วยดูหน่อย".

หลักการนี้ไม่ได้ใหม่เลย — มันคือเหตุผลเดียวกับที่ทีมคนจริงไม่ให้คนเขียนโค้ด approve PR ตัวเอง. ความหลากหลายในทีมไม่ใช่เรื่องมารยาท มันคือกลไกจับ error ที่สายตาชุดเดียวมองข้าม. (เรื่องการวน implement→review→fix ให้บรรจบ ผมเขียนแยกไว้ในบทความเรื่อง closed-loop engineering)

สรุป

• อย่าใช้ AI ตัวเดียวเหมาทุกบทบาท — จัดเป็นทีมที่แบ่ง role: architect / implementer / reviewer / summarizer
• จับคู่โมเดลกับ role ตามจุดแข็ง ไม่ใช่ default ไปตัวแพงสุดเสมอ
• ราคาคือแกนออกแบบ — route งานไปหาโมเดลถูกสุดที่ยังทำได้ดีพอ
• ระวังภาษีคงที่ต่อ agent — งานจิ๋วทำเองคุ้มกว่า handoff
• ส่งต่อด้วย handoff contract (goal/constraints/acceptance/scope) ไม่ใช่ยัด context ดิบ
• reviewer ต้องคนละค่ายกับ implementer เสมอ — ไม่งั้นทีมแค่รับรอง blind spot ของตัวเอง