ถ้าคนหนึ่งใช้ agent สร้างงานได้มากขึ้น แต่อีกคนต้องรับภาระรีวิวงานที่เพิ่มขึ้น ทีมอาจไม่ได้ส่งมอบงานดีขึ้นตามไปด้วย Aditya Khandelwal ใช้ตัวอย่างสมมติของคนที่ส่ง 10 PR ต่อวัน เทียบกับคนที่ส่ง 1–2 PR เพื่ออธิบายปัญหานี้ ไม่ใช่รายงานตัวเลข productivity ที่วัดได้
Aditya Khandelwal จาก Amazon AGI Lab ทางช่อง AI Engineer เล่าประสบการณ์นำทีมราว 10 คนใช้ coding agents แล้วเสนอว่า การทำให้ agents ใช้ได้ผลในทีมเป็น งานของผู้นำและระบบร่วม ควบคู่กับการตั้งค่าเครื่องมือ บทความนี้เก็บแนวทางจาก codebase และ workflow ของทีมเขา พร้อมแยกตัวอย่างประยุกต์ของ VibeSolo
เปลี่ยนโจทย์จาก “ให้ทุกคนใช้ AI” เป็น “ทำให้ทีมใช้ AI ร่วมกันได้”
Aditya เล่าว่าการตั้งค่าให้คนหนึ่งใช้ agent ได้ดีอาจไม่พอเมื่อขยายสู่ production และทั้งทีม เขาวิจารณ์แนวทางบังคับให้ทุกคนใช้เครื่องมือหรือใช้ token มากขึ้น แล้วเสนอให้ดูทั้งวิธีทำงานและความมั่นใจของคน
กรอบคิดของ Aditya มองคนในทีมผ่านสองแกน คือ ความกลัว ว่า AI จะกระทบตำแหน่งงานหรือไม่ และ ความมั่นใจในการใช้งาน เขาอธิบายว่าคนที่เห็น early adopter ทำได้ดีอาจเริ่มใช้ตาม แต่เมื่อพบงานคุณภาพต่ำ ความมั่นใจก็อาจลดลง กรอบนี้เป็นข้อสังเกตของผู้พูด ไม่ใช่ผลสำรวจแรงงาน
สิ่งที่ VibeSolo ชวนวัดเพิ่มเติมจากจำนวน account หรือ token คือ ทีมรับมืองานที่ AI สร้างขึ้นได้หรือไม่ เช่น เวลาตรวจ งานที่ต้องแก้ซ้ำ และเหตุผลที่งานยังไม่พร้อมส่งต่อ
ตัวอย่างสมมติที่ VibeSolo เสนอคือ ทีมการตลาดเพิ่มปริมาณคอนเทนต์ด้วย AI แต่ยังไม่มี tone of voice มาตรฐานตรวจข้อเท็จจริง หรือคนอนุมัติงาน จึงควรตรวจว่าปริมาณที่เพิ่มขึ้นสร้างภาระรีวิวให้หัวหน้าทีมเท่าใด ตัวอย่างนี้ไม่ใช่กรณีธุรกิจไทยที่ผู้พูดรายงาน
ตรวจอาการว่า workflow ของ AI กำลังพาทีมไปผิดทาง
ผู้พูดตั้งคำถามว่าการมีไฟล์คู่มือและเพิ่ม skills เพียงอย่างเดียวพอหรือไม่ แล้วเสนอให้ดู workflow ทั้งระบบ สัญญาณที่เขายกมามีดังนี้:
- ต้องคอยเฝ้า agent: แทรกแซงหรือแก้ทิศทางอยู่เรื่อยๆ
- งานไม่ซับซ้อนแต่กิน context มาก: session ยาวหรือเกิด auto compaction ทั้งที่โจทย์ไม่ใหญ่
- ทีมถามว่า model แย่ลงหรือไม่: Aditya เสนอให้ตรวจ harness และ codebase ที่เกี่ยวข้องด้วย
- งานหลุดมาตรฐานต่อเนื่อง: ผลลัพธ์ดูเสร็จแต่สร้างงานแก้หรือภาระตรวจตามมา
- ภาระรีวิวตกกับคนกลุ่มเดิม: เป็นความเสี่ยงที่เขายกในตัวอย่างความต่างของจำนวน PR
Aditya ชวนเปลี่ยนคำถามจาก “model ไม่ฉลาด” ไปเป็น “จะปรับระบบร่วมให้มันทำงานได้ดีขึ้นอย่างไร” ส่วนคำถามที่ VibeSolo เสนอให้ตรวจคือ agent ได้รับข้อมูลอะไร มีข้อจำกัดใดเปลี่ยน และเส้นทางหาข้อมูลของมันยังชัดหรือไม่ อาการเหล่านี้เป็นจุดเริ่มตรวจ ไม่ใช่ข้อพิสูจน์ว่า codebase เป็นสาเหตุเสมอ
ให้ผู้นำรับผิดชอบระบบ ไม่ปล่อยให้พนักงานแก้เอง
Aditya เตือนว่าหากปล่อยให้แต่ละคนหาวิธีใช้ agent เอง ความต่างด้านการสร้างงานอาจทำให้คนที่ยังไม่คล่องต้องรับภาระตรวจ จนยิ่งไม่อยากใช้เครื่องมือ เขาจึงมองว่าเรื่องนี้ต้องมีผู้นำรับผิดชอบ
เหตุผลหนึ่งคือ การจัดโครงสร้าง codebase ให้เหมาะกับ agent ต้องอาศัยความเห็นร่วมของทีม คนคนเดียวอาจเปลี่ยนไม่ได้ VibeSolo เสนอให้กำหนดมาตรฐานเอกสาร ขั้นตอนอนุมัติ และเกณฑ์พร้อมส่งต่อควบคู่กัน
ตัวอย่างการประยุกต์ของ VibeSolo สำหรับทีมที่ไม่มี codebase คือ มอง “ศูนย์ความรู้และระบบงานกลาง” เป็นสิ่งที่ต้องจัดร่วมกัน เช่น ทีมขายกำหนดแหล่งข้อมูลสินค้า ราคา และข้อเสนอที่ใช้ร่วมกัน แทนการให้แต่ละคนเก็บและใช้ข้อมูลคนละชุด
ข้อเสนอสำหรับผู้นำจาก VibeSolo คือกำหนดเจ้าของข้อมูล จุดที่ต้องมีคนตรวจ และวิธีนำ feedback กลับไปปรับ workflow ร่วม ไม่จำเป็นต้องให้ผู้นำเป็นผู้เขียน prompt ทุกชิ้น
ออกแบบข้อมูลแบบ Progressive Disclosure ให้ agent หาเรื่องที่ต้องรู้เจอ
หลักการหนึ่งที่ Aditya ใช้กับ harness engineering คือทำให้ agent ได้บริบทที่ต้องใช้ในเวลาที่เหมาะสม โดยมีเส้นทางหาข้อมูล ไม่ต้องโหลดทุกอย่างตั้งแต่ต้น เขานำแนวคิดนี้มาใช้กับ progressive disclosure
เขาเสนอให้เอกสารเริ่มต้น เช่น CLAUDE.md หรือ AGENTS.md เป็นดัชนีบางๆ ที่ชี้ไปยังไฟล์ที่เกี่ยวข้อง Agent จึงเริ่มจากแผนที่แล้วค่อยเปิดรายละเอียดตามงาน แทนการรวมข้อมูลทั้งหมดไว้ในไฟล์เดียว
ในช่วงตอบคำถาม Aditya เล่าว่าทีมกำหนด SKILL.md ไม่เกิน 100 บรรทัด และมอง skill เป็นโฟลเดอร์ที่มีเอกสารประกอบ ข้อกำหนดนี้เป็นของทีมเขา ไม่ใช่มาตรฐานสากล สำหรับ code ที่ต้องมี runbook เขาเสนอให้ comments ชี้ไปยังเอกสารนั้น เพื่อให้ agent ที่ค้นพบไฟล์รู้ว่าต้องอ่านอะไรต่อ
ตัวอย่างการประยุกต์กับ knowledge base ที่ VibeSolo เสนอคือ:
- เอกสารเริ่มต้นระบุแบรนด์ กลุ่มลูกค้า กฎการอนุมัติ และลิงก์ไปยังคู่มือแต่ละแผนก
- คู่มือการตอบลูกค้าแยกตามหมวด เช่น การคืนสินค้า การชำระเงิน และสินค้ารุ่นต่างๆ
- ข้อมูลที่เปลี่ยนบ่อย เช่น โปรโมชันหรือราคา อยู่ในแหล่งเดียว พร้อมวันที่อัปเดตชัดเจน
- งานที่มีความเสี่ยง เช่น ข้อความทางกฎหมายหรือการคืนเงิน ต้องมีเส้นทางส่งต่อมนุษย์ระบุไว้
วิธีตรวจที่ Aditya เสนอคือดู agent หลังคำสั่งแรก มันรู้หรือไม่ว่าควรไปอ่านที่ไหน และโหลด context เพิ่มเท่าใด ทีมควรใช้ข้อมูลนี้ปรับเส้นทางค้นหา ไม่ถือว่าตัวเลข token ที่เขายกเป็นเกณฑ์ตายตัวของทุกระบบ
สร้าง workflow มูลค่าสูงหนึ่งชุด ก่อนขยายไปทุกงาน
Aditya เล่าว่าทีมลงทุนกับ skill มูลค่าสูงชื่อ Ship It เพื่อพางานจากจุดที่เขียน code เสร็จไปสู่ PR ที่พร้อมรีวิว รวมถึงคำอธิบาย PR ข้อคิดเห็น และการวนแก้ CI ที่ล้มเหลว ขอบเขตที่อธิบายคือความพร้อมให้ตรวจ ไม่ใช่การรับรองว่า merge หรือส่ง production ได้โดยไม่มีคนตรวจ
เขารายงานว่า skill นี้บางครั้งทำงานเกินหนึ่งชั่วโมง คนกังวลในช่วงแรก แต่เริ่มเห็นคุณค่าเมื่อไม่ต้องคอยเฝ้าทุกขั้นตอน ข้อมูลนี้เป็นประสบการณ์ของทีมเขา ระยะเวลานานไม่ได้ยืนยันว่าผลลัพธ์จะดีขึ้นเสมอ
ตัวอย่างการประยุกต์ของ VibeSolo สำหรับทีมอื่นคือ เลือก workflow ที่มีจุดเริ่มและจุดจบชัดหนึ่งเรื่องก่อน เช่น:
- นำลีดจากแบบฟอร์มมาจัดกลุ่ม สรุปความต้องการ และร่างข้อความติดต่อตามข้อมูลที่มี
- รวบรวมคำถามลูกค้า ทำร่างคำตอบจากฐานความรู้ แล้วส่งให้เจ้าหน้าที่อนุมัติ
- นำบันทึกประชุมมาสรุปเป็นงานที่ต้องทำ ผู้รับผิดชอบ และกำหนดส่ง
- แปลง brief การตลาดเป็นโครงร่างคอนเทนต์ พร้อมเช็กว่าใช้คำและข้อเสนอที่อนุญาตหรือไม่
ข้อเสนอของ VibeSolo คือกำหนดเกณฑ์ “พร้อมส่งต่อ” ให้ workflow นั้น เช่น ต้องมีข้อมูลและหลักฐานใดก่อนคนรีวิว หากโจทย์กว้างเกินไป ทีมอาจระบุจุดวัดผลหรือแก้ปัญหาได้ยาก
ปิดวงจรคุณภาพ และยอมรับว่า setup ต้องปรับตลอด
Aditya เสนอให้มีวงจรตรวจและแก้งานที่หลุดมาตรฐาน พร้อมปรับ setup ต่อเนื่อง เขารายงานว่าทีมเชื่อม issues และ boards กับ repository เพิ่ม CI/CD และ agentic reviews รวมถึง code gardener ที่ตรวจความเป็นระเบียบของ codebase ตอนกลางคืน โดยเกณฑ์การจัดระเบียบต้องสัมพันธ์กับแต่ละ codebase
ตัวอย่างประยุกต์ของ VibeSolo คือเก็บงาน AI ที่ถูกแก้บ่อย จัดหมวดเหตุผล แล้วนำกลับไปอัปเดตคู่มือหรือ prompt กลาง แต่การเพิ่มระบบตรวจต้องดูผลข้างเคียงด้วย: Aditya เล่าว่าช่วงแรกทีมมี issues เพิ่มเป็นราว 400–500 รายการภายในไม่กี่สัปดาห์ เพราะ agents หลายตัวสร้างงานโดยยังเชื่อมกันไม่ดี เขายังยกปัญหา merge conflicts และคนกลับไปเฝ้า agent แบบเดิมเมื่อ setup ไม่ตรงความคาดหวัง
เขาเสนอให้แยก งานทดลอง ที่ยังไม่ส่งมอบออกจากงานจริง เพื่อไม่ต้องใช้มาตรฐานชุดเดียวกันกับ prototype ตั้งแต่ต้น VibeSolo เสนอให้ระบุสถานะทดลองและเกณฑ์ก่อนส่งต่ออย่างชัดเจน แทนการตีความว่าการทดลองอนุญาตให้ข้ามการตรวจงานที่จะใช้งานจริง
ชนะใจคนที่ยังไม่เชื่อ ไม่ใช่บังคับให้เงียบ
Aditya ย้ำว่าความกลัวและความรู้สึกของคนมีอยู่จริง การบังคับใช้เครื่องมืออย่างเดียวไม่ตอบโจทย์ เขาจึงเสนอให้รับฟังคนที่ยังไม่มั่นใจ แล้วช่วยให้เข้ามามีส่วนร่วมกับระบบร่วม
วิธีที่เขาเล่าคือให้คนที่ตั้งคำถามได้แก้ไขและทดลอง shared setup รวมถึงนำ feedback กลับไปปรับ skill การมีส่วนร่วมนี้เป็นสิ่งที่เขาใช้ดูว่าคนเริ่มลงทุนกับวิธีทำงานใหม่ ไม่ใช่ข้อพิสูจน์ว่าระบบเหมาะกับทุกงานแล้ว
เขายังชี้ว่าความมั่นใจของคนเปลี่ยนได้ตามวันและสิ่งที่กำลังเผชิญ เมื่อ model หรือ harness เปลี่ยนก็ต้องกลับมาดู setup และพูดคุยถึงปัญหา ทีมจึงต้องกันเวลาให้ปรับระบบร่วมอย่างต่อเนื่อง
ที่มา: Agents, codebases, and teams — Aditya Khandelwal, Amazon AGI Lab โดย Aditya Khandelwal จาก Amazon AGI Lab ทางช่อง AI Engineer อัปโหลด 11 สิงหาคม 2026 ตามเวลาไทย เนื้อหาและประสบการณ์ของทีมเป็นสิ่งที่ผู้พูดรายงานในเวลานั้น ตัวอย่างประยุกต์และข้อเสนอเพิ่มเติมที่ระบุชื่อ VibeSolo เป็นมุมมองของกองบรรณาธิการ
