Junior เรียกว่า Vibe Coding, Staff เรียกว่า Agentic Orchestration: Prompt เดียวกัน แต่งานไม่เหมือนกัน

ช่วงนี้ผมเห็นโพสต์สั้น ๆ ใน X ที่คนตอบกันเยอะครับ เป็นมุกสามบรรทัดของ Wes Winder ซึ่งโพสต์ไว้เมื่อ 25 ตุลาคม 2026

junior ships a feature with claude code: vibe coding

staff engineer ships the same feature with claude code: agentic orchestration

same prompt btw

หน้า X ผมเปิดผ่านเครื่องมือตรง ๆ ไม่ได้ เลยอ่านข้อความผ่าน API ของ fxtwitter ซึ่งดึงข้อความโพสต์มาให้ ตัวโพสต์มีแค่ข้อความ ไม่มีรูปหรือเธรดอธิบายต่อ ผมไม่ได้ไล่อ่านคอมเมนต์ทั้งหมด เลยจะไม่อ้างว่าคนตอบว่าอะไรนะครับ

โพสต์นี้อยู่ในซีรีส์ Critical Thinking ต่อจากทิปใช้ coding agent ของ Thorsten Ball ครับ คราวนี้เป็นคำถามที่ผมเจอเองในฐานะคนดูแลทีม junior สี่ทีม คือถ้าเครื่องมือเหมือนกัน และ prompt อาจจะเหมือนกันด้วย อะไรคือสิ่งที่ทำให้งานออกมาต่างกัน

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

มุกนี้ถูกครึ่งหนึ่ง

ผมอ่านมุกนี้ได้สองแบบครับ

แบบแรก: แซวเรื่องป้ายชื่อ คืองานเหมือนกันเป๊ะ แต่พอคนที่มีตำแหน่งสูงกว่าทำ ก็ได้ชื่อที่ฟังดูดีกว่า ข้อนี้ผมว่าจริงในหลายที่ และควรระวัง เพราะถ้า staff engineer ไม่ได้รีวิว ไม่ได้ทดสอบ แค่กดรับสิ่งที่ agent ทำมา มันก็คือ vibe coding ที่มีชื่อเท่ขึ้นเท่านั้น

แบบที่สอง: prompt ไม่ใช่ตัวแปรเดียว ต่อให้พิมพ์ประโยคเดียวกันจริง ๆ คนที่มีประสบการณ์มักแบ่งงานมาก่อนแล้ว มี repo ที่มีเทสต์และ AGENTS.md รอไว้ รู้ว่าจุดไหนต้องตรวจ และรู้ว่าเมื่อไหร่ควรโยนผลทิ้งแล้วเริ่มใหม่ prompt ที่เหมือนกันจึงไม่ได้แปลว่าบริบทเหมือนกัน

ตรงนี้ผมว่าคำนิยามของ Simon Willison ช่วยตัดสินได้ดีที่สุดครับ ในบทความ "Not all AI-assisted programming is vibe coding" เขานิยาม vibe coding ว่าคือการสร้างซอฟต์แวร์ด้วย LLM "without reviewing the code it writes" และบอกว่าถ้า LLM เขียนโค้ดให้ แล้วเรารีวิว ทดสอบอย่างละเอียด และอธิบายให้คนอื่นฟังได้ว่ามันทำงานยังไง นั่นไม่ใช่ vibe coding แต่คือการพัฒนาซอฟต์แวร์ ซึ่งสอดคล้องกับโพสต์ต้นทางของ Andrej Karpathy ที่บัญญัติคำนี้ไว้ในเชิง "forget that the code even exists"

แปลว่า เส้นแบ่งไม่ใช่ตำแหน่ง แต่คือคุณรีวิวและเข้าใจสิ่งที่ส่งออกไปหรือเปล่า junior ที่ตรวจงานละเอียดไม่ได้ vibe และ staff ที่กดรับทุกอย่างก็ไม่ได้ orchestrate ครับ

ส่วนคำว่า orchestration ผมยึดตามที่ Addy Osmani อธิบายใน"conductors to orchestrators" คือ conductor ทำงานใกล้ชิดกับ agent ตัวเดียวแบบโต้ตอบทีละขั้น ส่วน orchestrator ดูแล agent หลายตัวที่ทำงานขนานกัน โดยงานหลักของคนคือการกำหนดเป้าหมาย ประสานงาน ควบคุมคุณภาพ และรวมผลลัพธ์ เขาย้ำด้วยว่าคนยังเป็น "final failsafe" และควรปฏิบัติกับ agent เหมือนผู้รับเหมาที่ต้องมี definition of done ชัดเจน

สิ่งที่ต่างกันจริง อยู่รอบ ๆ prompt

ถ้าแยกงานหนึ่งชิ้นออกเป็นช่วง ๆ ผมว่าความต่างระหว่างสองแบบหน้าตาประมาณนี้ครับ ตารางนี้เป็นการสรุปของผมเอง ไม่ได้มาจากแหล่งไหนโดยตรง

ช่วงของงาน	แบบ vibe	แบบ orchestrate
ก่อนเริ่ม	เปิด agent แล้วพิมพ์ชื่อฟีเจอร์	แตกงานเป็นชิ้นเล็กที่ตรวจได้ทีละชิ้น
บริบท	ให้ agent เดาเอาจากโค้ด	ชี้ไฟล์ที่เกี่ยวข้อง ข้อจำกัด และสิ่งที่ห้ามแตะ
เกณฑ์เสร็จ	"รันได้แล้ว"	acceptance criteria ที่วัดได้ และเงื่อนไขหยุด
ระหว่างทำ	นั่งเฝ้า หรือปล่อยแล้วลืม	ให้ agent ทำงานที่แยกขาดจากกันได้ไปพร้อม ๆ กัน
ตรวจงาน	ดูว่าหน้าจอขึ้น แล้วเปิด PR	อ่าน diff รันเทสต์ ขอหลักฐาน และอธิบายได้ว่าโค้ดทำอะไร
เมื่อผลไม่ดี	สั่งให้แก้ซ้อนไปเรื่อย ๆ	ย้อนกลับไปแก้สเปกหรือบริบท แล้วเริ่มใหม่

สังเกตว่าแทบไม่มีแถวไหนเกี่ยวกับถ้อยคำใน prompt เลยครับ ทั้งหมดเป็นเรื่องที่ PM กับ PO ทำกับงานของคนอยู่แล้ว คือแตกงาน เขียน AC และตรวจรับ ซึ่งผมเขียนไว้ละเอียดในยุค agent = คุณต้องเขียน AC เหมือน PO

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

ทำไม junior ถึงไหลไปทาง vibe

ผมไม่คิดว่าเป็นเพราะ junior ขี้เกียจครับ ผมว่ามีเหตุผลเชิงโครงสร้างอยู่สามข้อ (ข้อนี้เป็นความเห็นของผม ไม่ได้มีงานวิจัยมารองรับ)

• ยังไม่มีภาพในหัวว่า "ดี" หน้าตาเป็นยังไง คนที่ยังไม่เคยเห็นระบบพังเพราะ race condition หรือ N+1 query ก็มองไม่ออกว่าโค้ดที่ agent เขียนมีปัญหานั้นอยู่
• แรงจูงใจที่ทีมตั้งไว้เอง ถ้าทีมวัดผลจากจำนวน ticket ที่ปิด สิ่งที่คุ้มที่สุดสำหรับ junior ก็คือรับงานจาก agent ให้ไวที่สุด
• ไม่มีใครสอนขั้นตอนก่อนและหลัง prompt เราสอนเรื่องการใช้เครื่องมือ แต่ไม่ค่อยสอนเรื่องการแตกงานหรือการตรวจรับ เพราะ senior ทำเรื่องพวกนี้จนเป็นนิสัย และอธิบายออกมาเป็นคำพูดไม่ค่อยได้

ข้อสุดท้ายสำคัญที่สุดครับ เพราะถ้าความต่างอยู่ที่กระบวนการ กระบวนการก็สอนกันได้ ซึ่งต่างจากการหวังให้ junior "เก่งขึ้นเอง"

บันได 5 ขั้น จาก vibe ไป orchestration

นี่คือบันไดที่ผมคิดไว้ใช้โค้ชทีมครับ ยังไม่ใช่สิ่งที่ผ่านการทดลองจริง แต่ตั้งใจให้แต่ละขั้นวัดได้ว่าผ่านหรือยัง

ขั้น 0: Vibe รับสิ่งที่ agent ทำมาตามที่เห็น ใช้ได้กับ prototype ที่ทิ้งได้ แต่ห้ามเข้า main branch

ขั้น 1: อธิบายได้ ทุกบรรทัดที่ส่งเข้า PR ต้องอธิบายให้คนรีวิวฟังได้ ตรงกับกฎของ Simon Willison ที่ว่าจะไม่ commit โค้ดที่อธิบายให้คนอื่นฟังไม่ได้ว่ามันทำอะไร

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

ขั้น 3: แตกงานและขอหลักฐาน แบ่งฟีเจอร์เป็นชิ้นที่รีวิวได้ในครั้งเดียว และให้ agent ส่ง output เทสต์จริง ขั้นตอนทดสอบซ้ำ และสิ่งที่ยังไม่ได้ทดสอบกลับมาทุกครั้ง

ขั้น 4: Orchestrate ทำงานที่แยกขาดจากกันไปพร้อม ๆ กันได้ รวมผลแล้วตรวจที่ระดับระบบ และรู้ว่าเมื่อไหร่ควรทิ้งผลแล้วเริ่มใหม่แทนการแก้ซ้อน

ผมจะไม่ผูกบันไดนี้กับตำแหน่งครับ junior ที่อยู่ขั้น 3 ได้อย่างสม่ำเสมอมีค่ากับทีมมากกว่า senior ที่วนอยู่ขั้น 0

Checklist สำหรับรีวิว PR ที่ทำร่วมกับ agent

เวลารีวิวงาน junior ผมว่าคำถามที่ควรถามเปลี่ยนไปครับ จากเดิมที่ดูว่า "โค้ดถูกไหม" อย่างเดียว ตอนนี้ต้องดูด้วยว่า "เจ้าของ PR ควบคุมงานนี้อยู่หรือเปล่า"

• PR อ้างถึง AC หรือเกณฑ์เสร็จที่เขียนไว้ก่อนเริ่ม ไม่ใช่เขียนย้อนหลัง
• ขนาด diff รีวิวได้ในครั้งเดียว ถ้าใหญ่เกิน ให้ถามว่าทำไมไม่แตก
• เจ้าของ PR อธิบายส่วนที่ซับซ้อนที่สุดได้ด้วยคำพูดของตัวเอง (ให้ถามสด ๆ สักข้อ)
• มีเทสต์ที่ fail ได้จริงเมื่อ logic ผิด ไม่ใช่เทสต์ที่ agent เขียนให้ผ่านอย่างเดียว
• มีหลักฐานการรันจริง เช่น output เทสต์ ภาพหน้าจอ หรือขั้นตอนทดสอบซ้ำ
• ไม่มีไฟล์ที่ไม่เกี่ยวกับงานถูกแก้ไปด้วย
• ระบุชัดว่าอะไรยังไม่ได้ทดสอบ หรือยังไม่แน่ใจ
• ถ้าเป็นจุดเสี่ยง เช่น auth, การเงิน, migration ต้องมี senior รีวิวเสมอ ไม่ว่าใครเขียน

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

ถ้าผมจะเริ่มใช้กับทีม

ส่วนนี้เป็นแผนนะครับ ไม่ใช่สิ่งที่ทำเสร็จแล้ว

สมมติว่าทีมหนึ่งได้ฟีเจอร์ "ส่งออกรายงานเป็น CSV" มา ถ้าทีมผมจะลองใช้บันไดนี้ ผมจะไม่ให้เริ่มจากการเปิด agent แต่ให้ใช้สิบห้านาทีแรกเขียนสามอย่าง คือ AC (คอลัมน์ไหนบ้าง ภาษาไทยต้องเปิดใน Excel ได้ ข้อมูลหนึ่งแสนแถวต้องไม่ทำให้เซิร์ฟเวอร์ค้าง) สิ่งที่ห้ามแตะ (API รายงานเดิมที่หน้าอื่นใช้) และหลักฐานที่จะขอจาก agent ตอนจบ แล้วค่อยเอาสามอย่างนี้ไปเป็น prompt

ผมเดาว่าสิ่งที่จะเห็นคือ prompt ที่ได้ไม่ได้ยาวหรือฉลาดขึ้นมาก แต่คำถามที่ junior ถามกลับมาจะเปลี่ยนไป จาก "ทำไม agent ทำไม่ได้" เป็น "เคสนี้ควรทำยังไง" ซึ่งคือคำถามที่ PM ควรได้ยินตั้งแต่แรก

ต่อจากนั้นผมจะเอาข้อตกลงเรื่องหลักฐานกับ checklist ด้านบนไปใส่ใน AGENTS.md และ PR template เพื่อให้กระบวนการไม่ได้อยู่แค่ในหัวของ senior บางคน

ท้ายที่สุด

ผมว่ามุกของ Wes Winder ตลกเพราะมันจริงครึ่งหนึ่งครับ คำเรียกมักขึ้นกับว่าใครเป็นคนทำ แต่อีกครึ่งที่มุกไม่ได้พูดก็คือ "same prompt" ไม่ได้แปลว่า "same work" สิ่งที่แยกสองแบบออกจากกันคือการแตกงาน การให้บริบท การตั้งเกณฑ์เสร็จ และการตรวจรับ ซึ่งไม่มีอันไหนขึ้นอยู่กับตำแหน่งเลย

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

คำถามที่ผมอยากให้ทุกคนในทีมถามตัวเองก่อนเปิด PR จึงมีข้อเดียวครับ "ถ้ามีคนถามว่าโค้ดนี้ทำอะไรและรู้ได้ยังไงว่ามันถูก ผมตอบได้โดยไม่ต้องเปิด agent ไหม" ถ้าตอบได้ ก็ไม่ได้ vibe แล้ว ไม่ว่าจะมีตำแหน่งอะไรก็ตาม