เมื่อ agent อยู่บนเครื่องของคนเขียนโค้ด แต่ไอเดียจากลูกค้าและการตัดสินใจอยู่ในระบบอื่น ทีมก็ยังต้องส่งต่อข้อมูลกันหลายรอบ คลิปนี้ชวนดูว่าจะทำให้คนทั้งทีมเข้าร่วมงานเดียวกันกับ agent ได้อย่างไร
Arjun Singh จาก Superconductor บนช่อง AI Engineer เสนอแนวคิด Multiplayer Agentic Engineering จากการนำ agents เข้ามาใน workflow ของทีมเขา: ทำให้ agent เป็นพื้นที่ทำงานร่วมกันตั้งแต่ support และ growth ไปจนถึงวิศวกร โดยมีมนุษย์ตรวจงานก่อนส่งมอบ
สำหรับทีมเล็ก VibeSolo ชวนใช้คลิปนี้เป็นแนวทางออกแบบ workflow ที่เปลี่ยนเสียงลูกค้าให้กลายเป็นร่างงานที่ตรวจสอบได้ พร้อมกำหนดสิทธิ์และผู้รับผิดชอบให้ชัดเจน
เลิกผูก workflow ของเรากับ model หรือเครื่องมือรายเดียว
Arjun เริ่มจากแนวคิดสำคัญว่าองค์กรควรเป็น model agnostic และ harness agnostic กล่าวคือ ไม่ผูกวิธีทำงานทั้งหมดไว้กับ model หรือเครื่องมือเขียนโค้ดตัวเดียว
Arjun ให้เหตุผลว่า model และ harness ที่เหมาะกับงานอาจเปลี่ยนได้ ทั้งเมื่อมีตัวใหม่หรือเมื่อเครื่องมือที่ใช้อยู่หายไป เขาเล่าว่าทีมกำลังทดลอง open-weight models ด้วย ประเด็นคือทำให้เปลี่ยนเครื่องมือได้โดยไม่ต้องเปลี่ยนวิธีทำงานร่วมกันทั้งทีม ไม่ใช่เลือกตัวที่ดีที่สุดตลอดไป
อีกมุมที่ Arjun ชวนคิดคือแรงจูงใจของผู้ขาย token อาจต่างจากเป้าหมายของทีมที่ต้องการทำผลิตภัณฑ์ให้ลูกค้าใช้ได้ดี เขาจึงเสนอให้รักษาความสามารถในการเลือกและสลับเครื่องมือ ส่วนเกณฑ์เลือกควรผูกกับงานและต้นทุนของทีมเอง
ตัวอย่างการประยุกต์ที่ VibeSolo เสนอสำหรับทีมเล็กคือ กำหนดงาน 3 กลุ่ม ได้แก่ งานสรุปและค้นหา งานสร้างร่างแรก และงานที่กระทบลูกค้าหรือข้อมูลสำคัญ จากนั้นทดลองเครื่องมือมากกว่าหนึ่งตัวกับงานจริงชุดเดียวกัน แล้วบันทึกคุณภาพ เวลา และค่าใช้จ่ายไว้
ทำให้ agent session เดียวเข้าถึงได้จากทุกจุดที่ทีมทำงาน
Arjun อธิบายปัญหาของ agent ที่ผูกอยู่กับโน้ตบุ๊กของคนหนึ่ง แม้ต่อมาเชื่อม Slack bot ได้ งานบางส่วนก็ยังเกิดนอก Slack เช่น ในแอปของทีมและ GitHub ทีมของเขาจึงต้องการให้หลายช่องทางเข้าถึงงานเดียวกันได้
แนวทางในคลิปคือ ใช้ agent session เดียวกันข้ามช่องทาง เช่น เริ่มทำงานร่วมกันใน Slack ต่อรายละเอียดในแอปเดสก์ท็อปหรือมือถือ แล้วจบด้วยการรีวิวใน GitHub Arjun เน้นว่าเป็น session และ context เดิม ไม่ใช่เริ่มใหม่แล้วให้คนคัดลอกข้อมูลไปเล่าซ้ำ
ตัวอย่างสมมติที่ VibeSolo เสนอคือ ทีมบริการลูกค้าพบข้อความสถานะใบสั่งซื้อที่ทำให้สับสน จึงเปิดงานผ่าน Slack พร้อมภาพหน้าจอ ฝ่าย product เพิ่มเงื่อนไขที่ต้องการ แล้วฝ่ายเทคนิคตรวจสอบใน session เดียวกัน ตัวอย่างนี้ใช้ต่อยอดแนวคิดในคลิป ไม่ใช่กรณีลูกค้าที่ผู้พูดรายงาน
จุดสำคัญคือ context ที่ต่อเนื่อง และการเห็นว่ามีใครเข้าร่วมงานนั้นบ้าง VibeSolo เสนอให้กำหนดเจ้าของงานและสิทธิ์ตัดสินใจเพิ่มด้วย การส่งปัญหาให้ agent กับการอนุมัติให้แก้ระบบจริงควรมีขอบเขตชัดเจน
ทำให้งานของ agent มองเห็น ตรวจสอบ และร่วมตัดสินใจได้
เมื่อ agent แจ้งว่าเสร็จแล้ว ผู้รับช่วงต่อยังต้องรู้ว่าแก้อะไรและใครตรวจแล้ว Arjun จึงเน้นทั้งการเห็นผู้เข้าร่วม session และการแสดงงานที่ agent ทำ
Arjun เล่าว่าทีมทำให้งานมองเห็นผ่าน session และ artifacts เช่น ภาพหน้าจอหรือวิดีโอ ที่เปิดดูได้จากหลายช่องทาง ผู้รีวิวสามารถถาม agent ใน session เดิมว่าทำไมจึงเลือกวิธีนั้น แทนการอ่านบทสนทนายาวทั้งหมด
กติกาที่ VibeSolo เสนอให้ลองใช้คือ งานที่มีผลต่อระบบหรือลูกค้าต้องมีหลักฐานให้ตรวจ เช่น ภาพก่อนและหลัง รายการเงื่อนไขที่ผ่าน หรือผลทดสอบ โดยเลือกหลักฐานให้เหมาะกับงาน
Artifact ช่วยให้ผู้รับช่วงต่อมีข้อมูลประกอบการรีวิว แต่ไม่ใช่การอนุมัติอัตโนมัติ Arjun ระบุในช่วงท้ายว่าทีมยังให้มนุษย์รีวิวทุกงาน แม้ pull request เกือบทั้งหมดจะมี agent ช่วยสร้างอย่างมาก
เปลี่ยนสัญญาณจากลูกค้าให้เป็นงานที่ประเมินได้
Arjun ยกสัญญาณหลายแบบที่อาจกลายเป็นงานพัฒนาได้: การประชุมกับลูกค้า onboarding การคุยขาย รายงาน bug อีเมลขอฟีเจอร์ และข้อความใน Slack ปัญหาที่เขาชี้คือ แม้ agent อ่านข้อมูลจากระบบเหล่านี้ได้ คนก็ยังต้องคัดเลือกและส่งต่อว่าจะให้ทำเรื่องไหน
ตัวอย่างที่เขาเล่าคือ meeting bot ที่อยู่ใน Google Meet ของบูทนาน 4 ชั่วโมง เมื่อมีคนเสนอว่า coding agent ควรมี acceptance criteria ก่อนประกาศว่างานเสร็จ bot จับไอเดีย สร้าง ticket และเริ่มทำงาน จากนั้นเพิ่มช่อง acceptance criteria สองช่องในแบบฟอร์ม ticket ได้โดยไม่มีใครเปิดงานด้วยมือ ตามรายงานของ Arjun
Arjun ย้ำว่าเขาคงไม่ส่งการเปลี่ยนแปลงนี้ตามที่เป็นอยู่ทันที แต่ตอนนี้มีตัวอย่างที่จับต้องได้ให้เปิด preview ทดลองและประเมิน ประเด็นจึงอยู่ที่ทำให้ไอเดียกลายเป็นร่างงานสำหรับตัดสินใจ ไม่ใช่ถือว่าทุกสิ่งที่ bot สร้างพร้อมใช้จริง
ข้อเสนอเพิ่มเติมของ VibeSolo คือ อย่าแปลงทุกประโยคในการประชุมเป็น ticket ทันที ให้เริ่มจากสรุปประเด็น ตรวจหางานเดิมที่เกี่ยวข้อง และเสนอร่างงานพร้อม acceptance criteria แล้วกำหนดคนตัดสินใจว่าจะทำต่อหรือไม่ ส่วนการเชื่อมกับงานเดิมเป็นพฤติกรรมที่ Arjun อธิบายไว้ในคลิป
ย้ายงาน agent ไปยัง cloud sandbox และใช้สิทธิ์เท่าที่จำเป็น
Arjun อธิบายว่า workflow ก่อนหน้านี้อาศัย cloud environment ที่แยกไว้สำหรับงาน เพื่อไม่ให้ agent ผูกอยู่กับเครื่องของคนหนึ่ง เขาเล่าว่าการย้ายขึ้น cloud ช่วยให้ทีมปิดโน้ตบุ๊กได้ แล้วเน้นต่อว่าการจำกัดสิทธิ์เป็นเหตุผลที่สำคัญกว่า
เขายกสถานการณ์เสี่ยงที่ agent ได้คำสั่งให้ล้าง staging แต่พบ token บนเครื่องที่ชี้ไปยัง production จึงทำความเสียหายผิดระบบ ประเด็นของตัวอย่างคือ agent ควรเข้าถึงเฉพาะสิ่งที่ต้องใช้ในงาน ไม่ใช่มีสิทธิ์ตามทุกอย่างที่เก็บไว้บนเครื่องพนักงาน
แนวทางที่ Arjun อธิบายคือ จำกัดสิทธิ์ตามงาน จำกัดปลายทาง network และขออนุมัติเมื่อ agent ต้องเข้าถึงบริการใหม่ โดยอนุญาตได้เป็นราย ticket หรือราย project การอยู่บน cloud เพียงอย่างเดียวไม่ได้ยืนยันว่าระบบปลอดภัย ต้องตั้งขอบเขตเหล่านี้ด้วย
เขายังเล่าว่าทีม support และ growth ส่งปัญหาผ่าน Slack หรือแอปได้โดยไม่ต้องมี development environment บนเครื่อง Agent ทำการแก้ไขและแสดงภาพหน้าจอ จากนั้นวิศวกรตรวจและ merge เป็น workflow ของทีมที่ผู้พูดรายงาน ไม่ใช่การยืนยันว่าทุกคำขอจะสำเร็จโดยอัตโนมัติ
วัดผล agent บนงานจริงของเรา ไม่ใช่เชื่อคะแนน benchmark อย่างเดียว
Arjun ชี้ว่าผล benchmark สาธารณะอาจต่างจากงานบน codebase ของทีมเขาที่ใช้ Ruby on Rails จึงควรดูผลบนงานจริงของทีมประกอบ แทนการใช้คะแนนภายนอกตัดสินเพียงอย่างเดียว
แนวทางของทีมคือเลือก pull request ที่เป็นตัวอย่างงานวิศวกรรมคุณภาพดี ไม่ว่าจะสร้างโดยคน agent หรือทั้งสองอย่าง แล้วทดสอบ agents ที่สนใจใน codebase เดียวกัน เทียบ คุณภาพ ต้นทุน และเวลา Arjun ย้ำว่าผลที่แสดงเป็นของ codebase ทีมเขา และไม่ได้อ้างอันดับทั่วไป
Arjun รายงานว่า pull request เกือบทั้งหมดของทีมมี agent ช่วยสร้างอย่างมาก แต่ยังให้มนุษย์รีวิวทุกงาน ส่วนผลเปรียบเทียบเครื่องมือทำให้ทีมเปลี่ยน default ในเวลานั้น ข้อมูลนี้เป็นประสบการณ์ที่เขารายงาน ไม่ใช่หลักฐานว่าเครื่องมือตัวใดดีที่สุดหรือถูกที่สุดสำหรับทุกทีม
สำหรับทีมที่ไม่มี codebase ตัวอย่างการประยุกต์ของ VibeSolo คือให้ AI สรุปบันทึกการคุยลูกค้า ร่างอีเมล หรือจัดหมวดหมู่ ticket ชุดเดิม แล้วประเมินความถูกต้อง เวลาแก้ และความพร้อมใช้งาน เพื่อดูว่าทีมต้องทำงานต่อมากแค่ไหน
ที่มา: Multiplayer agentic engineering — Arjun Singh, Superconductor โดย Arjun Singh จาก Superconductor ทางช่อง AI Engineer อัปโหลด 10 สิงหาคม 2026 ตามเวลาไทย เนื้อหาและประสบการณ์ของทีมเป็นสิ่งที่ผู้พูดรายงานในเวลานั้น ตัวอย่างประยุกต์และข้อเสนอเพิ่มเติมที่ระบุชื่อ VibeSolo เป็นมุมมองของกองบรรณาธิการ
