coding agent อาจเขียนโค้ดเสร็จในไม่กี่นาที แต่คำว่า “เสร็จ” ของมันกับคำว่า “พร้อมส่ง” ของทีมไม่ใช่คำเดียวกัน

ก่อนถึง commit ยังมีคำถามอีกหลายข้อ: agent เข้าใจโจทย์ตรงกับเราหรือยัง งานนี้ควรแยกให้ใครทำ ไฟล์ไหนเสี่ยงชนกัน ใครตรวจเรื่อง security และกฎใดต้องผ่านทุกครั้ง หากทุก session ต้องนึกคำตอบเหล่านี้ใหม่ เวลาที่ประหยัดได้ตอนสร้างโค้ดก็จะหมดไปกับการตรวจ แก้ และอธิบายงานซ้ำ

Vibe Coding Toolkit ของ Matheus Gomes พยายามแก้ปัญหานี้ด้วยการจัดปลั๊กอิน พรอมป์ เทมเพลต และกติกาการทำงานให้เป็น playbook เดียว ผู้สร้างระบุว่าวิธีเหล่านี้สกัดจากงาน fintech ใน production ภายใต้ NDA เราจึงตรวจดูโค้ดหรือผลวัดจากโปรเจกต์ต้นทางไม่ได้ แต่ยังอ่านและประเมินตัวระบบที่เปิดเผยได้

สิ่งที่น่าหยิบกลับมาไม่ใช่รายชื่อเครื่องมือทั้งหมด แต่คือทางผ่านสามชั้น:

1. workflow บังคับให้เข้าใจและวางแผนก่อนเขียน
2. orchestration ส่งงานให้ agent เท่าที่จำเป็น พร้อมกันเท่าที่ปลอดภัย
3. quality gate เปลี่ยนข้อตกลงของทีมให้เป็นเงื่อนไขที่ตรวจซ้ำได้

เมื่อสามชั้นนี้ต่อกัน coding agent ไม่ต้อง “เก่งทุกอย่าง” ใน session เดียว และทีมไม่ต้องหวังว่าผู้ตรวจจะจำ checklist ได้ครบทุกครั้ง

อ่านเป็นระบบ ไม่ใช่รายการปลั๊กอิน

เส้นทางหลักใน toolkit เริ่มจากติดตั้งและตั้งค่าโปรเจกต์ แล้วเดินผ่าน brainstorm → plan → parallel waves → review → ship ส่วน Superpowers, knowledge graph, token proxy, persona, memory และ quality gates ทำหน้าที่เป็นชั้นสนับสนุนตลอดทาง

ความต่างสำคัญอยู่ตรงนี้ หากมองแต่ละชิ้นแยกกัน เราอาจได้ปลั๊กอินช่วยวางแผนหนึ่งตัว, agent reviewer หลายตัว และ linter อีกสองตัว แต่ยังไม่รู้ว่าเมื่อไรต้องเรียกอะไร หรือผลจากขั้นหนึ่งอนุญาตให้ขั้นถัดไปเริ่มได้ตอนไหน Playbook เติมกติกาเชื่อมระหว่างชิ้นส่วนเหล่านั้น

ตัวอย่างเช่น Superpowers ถูกวางไว้ต้นทางเพื่อไม่ให้ agent กระโดดจากคำขอที่ยังตีความได้หลายแบบไปเขียนโค้ดทันที เมื่อเจตนาและแผนชัดแล้ว orchestration จึงแบ่งงาน เมื่อ implementation กลับมา reviewer และ gate จึงตรวจ ก่อนที่ session หลักจะ commit และ ship

ชั้นสนับสนุนอื่นแก้ปัญหาคนละชนิด:

• token proxy ย่อ output ของคำสั่งอ่านซ้ำ ๆ เช่น git status, diff หรือ grep เพื่อไม่ให้ context เต็มด้วยข้อความที่ไม่จำเป็น และปล่อยคำสั่งเดิมผ่านหาก proxy มีปัญหา
• knowledge graph เก็บความสัมพันธ์ของ codebase ข้าม session ช่วยตอบว่าไฟล์ใดเรียกอะไรหรือจุดไหนมีผลกระทบกว้าง โดยไม่ต้องสำรวจใหม่ทั้งหมด
• memory แยกเป็นดัชนีสั้นที่โหลดทุกครั้ง กับคลังระยะยาวที่ค้นเมื่อจำเป็น จึงเก็บบทเรียนได้โดยไม่เททุกอย่างเข้า context เริ่มต้น
• persona ด้านวิศวกรรมคอยถามว่ามีของเดิมหรือทางแก้ที่ง่ายกว่าหรือไม่ ส่วน persona ด้านการสื่อสารลดคำฟุ่มเฟือย ทั้งสองหน้าที่แยกจากกัน

นี่ไม่ได้แปลว่าทีมต้องติดตั้งทุกชิ้น คุณค่าของภาพรวมคือทำให้เห็นว่าแต่ละปัญหาควรมีเครื่องมือหรือกติกาที่รับผิดชอบโดยตรงเพียงหนึ่งชิ้น และเครื่องมือหนึ่งชิ้นไม่ควรแอบรับผิดชอบทุกอย่าง

หลาย agent จะคุ้มเมื่อแบ่งตามขอบเขตของ context

เอกสาร orchestration เสนอให้ session หลักทำหน้าที่คล้าย tech lead: เข้าใจปัญหา ตัดสินใจ และประสานงาน ส่วน subagent คือ instance แยกที่ได้รับงานเฉพาะ มี context ของตัวเอง และรายงานผลกลับมา

จุดที่ต้องระวังคือ การมีหลาย agent ไม่ได้แปลว่าต้องแยกงานให้มากที่สุด เอกสารอ้างบทความของ Anthropic ว่าระบบหลาย agent อาจใช้ token มากกว่า agent เดียวราว 3–10 เท่า ตัวเลขนี้เป็นการอ้างต่อจากแหล่งที่ไม่ได้อยู่ในชุดข้อมูลของบทความเรา จึงควรอ่านเป็นสัญญาณเรื่องต้นทุน ไม่ใช่ benchmark รับรอง toolkit

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

• ปกป้อง context หลัก: งานสำรวจมี output มากและไม่ควรทำให้ session ที่ตัดสินใจเต็มไปด้วย noise
• ขนานได้จริง: สองงานไม่รอผลกันและไม่เขียนไฟล์เดียวกัน
• ต้องใช้ checklist เฉพาะ: เช่น การตรวจ authentication ต้องการมุม security ที่ต่างจากการตรวจ React hooks

ในทางกลับกัน อย่าแยกเพียงเพราะตั้งชื่อฝ่ายได้ หาก agent ฝั่ง front-end ต้องรอ schema จาก agent ฐานข้อมูล หรือทั้งสองกำลังแก้ type เดียวกันในไฟล์ shared งานเหล่านั้นยังพึ่ง context และ state ชุดเดียวกัน การส่งพร้อมกันเพียงเปลี่ยน dependency ที่มองเห็นให้กลายเป็นการชนที่ต้องแก้ทีหลัง

รายชื่อ specialist ต้องตอบคำถาม “ใช้เมื่อไร”

toolkit แนะนำให้แต่ละ specialist มีชื่อและ trigger หนึ่งประโยค เช่น security reviewer ใช้เมื่องานแตะ authentication, secret หรือช่องโหว่ที่รู้จัก ส่วน React reviewer ใช้ตรวจ hooks, server/client boundary, accessibility และ rendering performance

ประโยค “ใช้เมื่อไร” คือ routing rule ในตัว ถ้าสองบทบาทรับ trigger เดียวกันโดยไม่มีขอบเขตต่างกันจริง เรามีบทบาทซ้ำ ไม่ได้มี coverage เพิ่ม

ทีมเล็กจึงไม่จำเป็นต้องเริ่มจากรายชื่อ agent ยาว ๆ ลองเริ่มจากสามบทบาทที่ pain ชัดก่อน:

ชื่อไม่สำคัญเท่ากับขอบเขต เมื่อผลลัพธ์ของบทบาทหนึ่งชัด session หลักจะรู้ว่าควรเชื่อมมันเข้ากับขั้นถัดไปอย่างไร

ก่อนปล่อยงานเป็นคลื่น ต้องประกาศไฟล์และ dependency

งานแต่ละชิ้นในแผนควรตอบสองช่อง:

Files: src/auth/session.ts, src/auth/session.test.ts
Depends-on: task-01

จากนั้นจัด task ที่ dependency พร้อมและไม่มีไฟล์ซ้อนกันให้อยู่ wave เดียวกัน ตัวอย่างเช่น reviewer ด้าน accessibility ของหน้า settings อาจรันพร้อมกับ migration ของตาราง audit log ได้ หากไม่มีไฟล์หรือข้อมูลระหว่างทางร่วมกัน แต่ UI ที่ต้องใช้ type จาก migration ใหม่ควรรอ wave ถัดไป

ใน shared working tree toolkit ให้ subagent แก้ไฟล์ได้ แต่ไม่ commit เอง session หลักรอให้ทั้ง wave จบ ตรวจ diff แล้ว commit ตามลำดับ กติกานี้ไม่ได้กำจัดความผิดพลาดทางวินัยทั้งหมด แต่ลดโอกาสที่ agent หลายตัวจะแย่งกัน commit และให้ session หลักควบคุมลำดับ commit รวมถึงรับผิดชอบประวัติการเปลี่ยนแปลงเพียงผู้เดียว

เลือก model tier ตามงาน ไม่ใช่ตาม session หลัก

อีกกติกาที่ควรย้ายตามมาคือเลือกโมเดลต่อ dispatch งานค้นไฟล์หรือแก้หนึ่งจุดที่ระบุครบไม่จำเป็นต้องใช้ reasoning tier สูงสุด งาน implementation, debug และ review ทั่วไปใช้ชั้นกลางได้ ส่วนโมเดลที่แข็งแรงกว่าควรเก็บไว้กับการตัดสินใจสถาปัตยกรรมที่ยากจริง

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

Quality gate ที่ดีต้องรัดขึ้นโดยไม่หยุดทีม

ฝั่ง orchestration จัดว่าใครทำอะไร ส่วน quality gate ตอบว่าเงื่อนไขใดต้องผ่านก่อนงานเดินต่อ

เอกสารของ toolkit ใช้ ESLint กับ Biome พร้อมกัน แต่ไม่ได้เปิด preset ทุกอย่างจากทั้งคู่ Biome รับกฎเชิง syntax จำนวนเล็กที่เลือกมาเพราะรันเร็ว ขณะที่ ESLint ดู type-aware rules, กฎเฉพาะ framework และกรณีที่ชุด Biome ตั้งใจไม่ครอบคลุม เหตุผลของแต่ละ rule อยู่ใกล้ configuration เพื่อให้คนแก้ไฟล์เข้าใจว่าทำไมมันเปิดอยู่

ประเด็นจึงไม่ใช่ “สองตัวดีกว่าหนึ่งตัว” แต่คือ ทุกกฎต้องมี owner และเหตุผล หาก stack ของเราจัด coverage ที่ต้องการได้ด้วยเครื่องมือเดียวโดยไม่เสียความเร็วหรือความชัด ก็ไม่จำเป็นต้องเพิ่มอีกตัว

เปลี่ยน warning ให้เป็น migration

การเปิดกฎใหม่เป็น error ทันทีใน codebase ที่มี violation อยู่แล้วมักจบสองทาง: build ของทุกคนพัง หรือทีมปิดกฎกลับเพราะงานประจำเดินต่อไม่ได้ Toolkit เสนอทางที่สาม:

1. เปิดกฎเป็น warn
2. นับ baseline ให้รู้ว่ามี debt เท่าไร
3. ลดจำนวน violation โดยแยกงานแก้ที่ตรวจสอบผลกระทบได้
4. เมื่อเหลือศูนย์ เลื่อนเป็น error
5. ไม่เปิดทางให้ violation แบบเดิมกลับเข้ามาอีก

warning จึงไม่ใช่สถานะครึ่ง ๆ กลาง ๆ แต่เป็นช่วง migration ที่มีตัวเลขและเส้นชัย หากไม่มี owner ไม่มี baseline และไม่มีเงื่อนไขเลื่อน severity มันก็ยังเป็นเพียงเสียงเตือนที่ทุกคนเรียนรู้จะมองข้าม

แนวคิดเดียวกันใช้กับขอบเขตสถาปัตยกรรมได้ สมมติทีมต้องห้าม UI import database client โดยตรง ของใหม่ควรถูกบล็อกเป็น error ตั้งแต่วันนี้ ส่วนไฟล์ legacy ที่ยังแก้ไม่หมดอาจใช้ rule logic เดียวกันภายใต้ชื่ออีกตัวและคงเป็น warning เฉพาะรายการที่รับรู้แล้ว วิธีนี้หยุดหนี้ใหม่โดยไม่แกล้งทำว่าหนี้เก่าหายไป

ก่อนเขียน custom ESLint rule ควรตรวจของที่มีอยู่ เช่น eslint-plugin-boundaries หรือ import/no-restricted-paths ก่อน Custom rule เหมาะเมื่อ invariant เฉพาะระบบไม่มีเครื่องมือทั่วไปครอบคลุมจริง เช่น บังคับให้ตรวจ authentication ก่อน mutation หรือห้ามใช้ floating point กับจำนวนเงินในบางชั้นของระบบ

แยก fast path ออกจากกฎที่ต้องอ่าน type ทั้งโปรเจกต์

type-aware lint ต้องให้ TypeScript สร้าง program ของทั้งโปรเจกต์ จึงช้ากว่ากฎที่อ่าน syntax ของไฟล์เดียว เอกสารแนะนำให้แยกสองทาง:

{
  "scripts": {
    "lint": "eslint .",
    "lint:types": "eslint . --config eslint.type-aware.config.js"
  }
}

lint แบบเร็วอยู่ในเส้นทาง commit ที่ทุกคนรันบ่อย ส่วน lint:types ไปอยู่ใน CI หรือคำสั่งเฉพาะ การแยกนี้รักษาความเข้มของการตรวจโดยไม่ทำให้ทุก commit ต้องจ่ายต้นทุนสูงสุด

เรื่อง formatter ก็ต้องดูสภาพ codebase หากโปรเจกต์เก่าไม่เคย format ทั้งก้อน การเปิด formatter แล้วสร้าง diff หลายพันบรรทัดอาจบดบัง bug fix จริง การปิดไว้พร้อมเขียนเหตุผลใน config จึงสมเหตุผลได้ แต่โปรเจกต์ใหม่ไม่มี legacy diff ให้หลบ การเปิด formatter ตั้งแต่ commit แรกกลับเป็นทางที่ง่ายกว่า

ต่อสามชั้นให้เป็นทางผ่านเดียว

เมื่อรวม workflow, orchestration และ gate เข้าด้วยกัน เราจะได้เส้นทางที่แต่ละช่วงมีคำถามคนละชุด:

จุดแข็งของโครงนี้คือไม่ผลักทุกปัญหาให้ model ตัดสิน หากเงื่อนไขตรวจซ้ำได้ เช่น import ข้ามชั้นหรือ warning count ควรให้เครื่องมือ deterministic จัดการ ส่วนคำถามที่มีคำตอบถูกต้องได้หลายแบบ เช่น จะแบ่ง context ตรงไหนหรือ review แบบใดเหมาะกับ diff นี้ ยังเป็นงานตัดสินใจของคนและ agent

เริ่มเล็กให้เห็นผลก่อนคัดลอกทั้ง toolkit

repository มีทั้ง playbook เอกสารเครื่องมือ prompts และ templates แต่ทีมไม่จำเป็นต้องย้ายทั้งหมดใน sprint เดียว วิธีเริ่มที่ดูแลต่อได้ง่ายกว่าคือแบ่งเป็นสามรอบ

รอบแรก: ปิดทางลัดจากโจทย์ไปหาโค้ด

เขียนกฎใน AGENTS.md, CLAUDE.md หรือไฟล์คำสั่งของเครื่องมือที่ใช้ว่า งานคลุมเครือต้องสรุป intent และแผนก่อนแก้ไฟล์ กำหนดคำว่า “พร้อม implement” ให้ตรวจได้ เช่น มี acceptance criteria, รายการไฟล์เบื้องต้น และคำถามค้างถูกปิดแล้ว

อย่าเริ่มจาก persona หลายชั้น หากทีมยังไม่มี gate ต้นทาง เพราะ agent ที่ตอบกระชับขึ้นก็ยังอาจสร้างของผิดชิ้นได้เร็วเหมือนเดิม

รอบสอง: ทดลอง orchestration กับงานที่แยกจริงหนึ่งชนิด

เลือกกรณีที่เห็น boundary ชัด เช่น ให้ explorer สำรวจ code path โดยไม่แก้ไฟล์ แล้วส่งแผนที่กลับมาให้ implementer หรือให้ reviewers สองด้านอ่าน diff เดียวกันอย่างอิสระก่อน session หลักสังเคราะห์

ทุก task ต้องประกาศ input, output, Files: และ Depends-on: หากเขียนสี่ช่องนี้ไม่ได้ แปลว่างานยังไม่พร้อมแยก ไม่ใช่สัญญาณว่าต้องเพิ่ม agent อีกตัว

รอบสาม: เลือก gate จากข้อผิดพลาดที่เกิดซ้ำ

อย่าเปิด ruleset ใหญ่เพราะชื่อ recommended ฟังดูปลอดภัย เลือกหนึ่งหรือสองปัญหาที่ทีมเจอจริง ตั้ง owner และเหตุผล วัด baseline แล้วตัดสินว่าอะไรต้องเป็น error ทันทีเพราะเป็น bug เสมอ กับอะไรควรเริ่มเป็น warning เพื่อทำ migration

หลังทดลองหนึ่งรอบ ทีมควรตอบได้ว่า:

• เวลาส่วนใดลดลงเพราะไม่ต้องสำรวจหรืออธิบายซ้ำ
• งานใดยังถูกแบ่งทั้งที่แชร์ context มากเกินไป
• gate ใดจับปัญหาก่อน review และ gate ใดสร้าง noise
• บทเรียนใดควรอยู่ในดัชนีสั้นของโปรเจกต์ และอะไรควรเก็บค้นภายหลัง

คำตอบเหล่านี้มีค่ากว่าจำนวนปลั๊กอินที่ติดตั้ง เพราะมันบอกว่า workflow กำลังช่วยงานจริงหรือเพียงย้ายความซับซ้อนไปอยู่ใน configuration

Playbook สำคัญกว่าการทำให้ agent ดูเหมือนทีมใหญ่

Vibe Coding Toolkit เปิดให้เห็นวิธีคิดของผู้สร้างมากกว่าสูตรสำเร็จ แนวทางจำนวนหนึ่งผูกกับ Claude Code โดยตรง เช่น plugin, hook และรูปแบบประกาศ subagent ขณะที่กติกาเรื่อง context boundary, file ownership, dependency, model tier และ warn-to-error migration ย้ายไปใช้กับ Codex หรือ agent อื่นได้ หากเครื่องมือนั้นอ่าน project instructions และรันคำสั่งของโปรเจกต์ได้

แก่นของเรื่องไม่ใช่ทำให้ terminal มี agent หลายชื่อ แต่ทำให้ทุกชิ้นรู้หน้าที่ของตัวเอง: workflow หยุดการรีบเขียน, orchestration หยุดการแชร์ context โดยไม่จำเป็น, และ quality gate หยุดข้อผิดพลาดที่ทีมตกลงแล้วว่าไม่ควรผ่าน

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

ที่มา: Vibe Coding Toolkit repository, Vibe Coding Toolkit overview, Subagent orchestration guide และ ESLint and Biome quality gates