การรีวิวโดยมนุษย์คือคอขวด: ออกแบบกระบวนการรีวิวสำหรับเอเจนต์แบบขนาน

ครั้งแรกที่คุณรัน coding agent สามตัวพร้อมกัน การรันจะไม่ใช่ส่วนที่ช้าอีกต่อไป คุณโยนบั๊กหนึ่งตัวให้ Claude Code งาน refactor ให้ Codex และช่องว่างของ test coverage ให้ Runtime ตัวที่สาม แล้วสี่สิบนาทีต่อมา สาม branch ก็พร้อมใช้งาน จากนั้นการรอจริงก็เริ่ม เพราะทั้งสามตัวกำลังรอคุณอยู่ คุณอ่าน diff ตัวแรก อนุมัติ แต่อีกสองตัวก็นั่งว่าง คุณมีการรันแบบขนานแต่การรีวิวเป็นแบบทีละตัว ความขนานจึงแทบไม่ให้อะไรกับคุณเลย

นี่คือกับดักที่เล่นงานทุกทีมที่เริ่มเก่งเรื่องการรัน agent แบบขนาน คอขวดไม่ได้หายไป มันแค่ย้ายที่ จาก “agent เขียนโค้ดได้เร็วแค่ไหน” ไปเป็น “คนอ่าน ตัดสิน และอนุมัติผลลัพธ์ได้เร็วแค่ไหน” การเพิ่ม agent ตัวที่สี่ยิ่งแย่ลงไปอีก: คิวงานที่เสร็จแล้วยาวขึ้น แต่คนรีวิวก็ยังมีคนเดิม

ทางแก้ไม่ใช่การรีวิวให้เร็วขึ้นหรือเชื่อใจให้มากขึ้น แต่คือการออกแบบการรีวิวให้เป็นส่วนหนึ่งของ workflow อย่างชัดเจน แทนที่จะเป็นเรื่องที่คิดเอาเองในหัวทีหลัง นั่นคือ workflow ที่บทความนี้จะพาไล่ดู และเป็นปัญหาที่ Sharkly ถูกสร้างขึ้นมาเพื่อแก้: เก็บเป้าหมาย diff หลักฐาน และการรีวิวของทุกการรัน agent ไว้ใน Task เดียวกัน เพื่อให้คิวรีวิวกลายเป็นสิ่งที่มองเห็นและจัดการได้ แทนที่จะเป็นกองแท็บเบราว์เซอร์ที่เปิดค้างไว้

ทำไม agent ที่รันขนานกันถึงย้ายคอขวดมาที่การรีวิว

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

เครื่องมือส่วนใหญ่ซ่อนเรื่องนี้ไว้ กอง pull request แสดงให้คุณเห็นงาน แต่ไม่บอกว่ารายการไหนกำลังรอการตัดสินใจจริง ๆ อันไหนยังรันอยู่ อันไหน merge ไปแล้ว คิวนั้นมีอยู่จริง แต่มันกระจายอยู่ตามแท็บ การแจ้งเตือน และความจำ เป้าหมายการออกแบบข้อแรกคือทำให้มันมองเห็นได้ เพราะคุณจัดการคอขวดที่มองไม่เห็นไม่ได้ บทความคู่กันเรื่อง คณิตศาสตร์ของความสามารถในการรีวิว อธิบายว่าจะเกิดอะไรขึ้นเมื่อ concurrency สูงขึ้น

โมเดลการดำเนินงาน: ใครมอบหมาย ใครรัน ใครรีวิว ใครอนุมัติ

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

มีคนหนึ่งมอบหมายงาน: เปลี่ยนความตั้งใจให้เป็น Task ที่มีขอบเขตชัดเจนพร้อมเกณฑ์การยอมรับ มีอะไรบางอย่างรันมัน: Agent บน Computer ที่ทำงานใน Runtime ผลิตการเปลี่ยนแปลงออกมาพร้อมบันทึกว่าได้ทำอะไรไปบ้าง มีคนหนึ่งรีวิวผลลัพธ์: อ่าน diff และหลักฐาน แล้วตัดสินว่าตรงตามเกณฑ์หรือไม่ มีคนหนึ่งอนุมัติมัน: ตัดสินใจ merge และปล่อย ซึ่งเป็นการตัดสินใจที่ต่างจาก “โค้ดดูโอเค”

Sharkly สรุปสัญญานี้ไว้บรรทัดเดียวที่ควรจดติดโพสต์อิท: agent ค้นคว้า ลงมือ ทำการทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง ให้อำนาจ และอนุมัติผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้วิจารณญาณของทีม การ assign และ accept เป็นของคนโดยการออกแบบ ส่วน run เป็นของ Agent และ review คือหน้าที่ที่ต้องออกแบบเป็นงานวิศวกรรม เพราะมันคือจุดที่คิวก่อตัวขึ้น

เส้นแบ่งที่มีประโยชน์: PR ที่ merge แล้วไม่เหมือนกับผลลัพธ์ที่ได้รับการอนุมัติ การ merge เป็นการดำเนินการของ git ส่วนการอนุมัติคือคนตัดสินว่าการเปลี่ยนแปลงนั้นทำในสิ่งที่ Task ขอไว้จริง เมื่อสองอย่างนี้รวมกันเป็นการคลิกครั้งเดียว คุณภาพการรีวิวก็จะตกไปเท่ากับพลังงานที่คนรีวิวมีอยู่ในนาทีนั้น

บทบาท สถานะ และประตูรีวิว

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

ประตูคือการเปลี่ยนสถานะเข้าสู่ Ready for review และออกไปเป็น Done agent ไปถึงประตูได้ด้วยตัวเอง แต่ผ่านประตูไม่ได้ กฎข้อเดียวนี้คือสิ่งที่ทำให้คุณรัน agent สิบตัวได้อย่างปลอดภัย: พวกมันเติมคอลัมน์ Ready for review แบบขนาน และคุณระบายมันออกด้วยจังหวะที่ยังรักษาคุณภาพได้ ความยาวของคอลัมน์คือคอขวดของคุณที่มองเห็นได้

นี่คือคู่การตัดสินใจที่ตรงไปตรงมา ปิดประตูทุกการเปลี่ยนแปลงที่ปล่อยถึงผู้ใช้ หรือแตะเรื่องเงิน การยืนยันตัวตน การย้ายข้อมูล หรือ public API ไม่ต้องปิดประตูกับงานทดลองชั่วคราว โค้ด boilerplate ที่ generate ใหม่ได้อยู่แล้ว หรืองานที่ซ่อนอยู่หลัง flag ที่ยังไม่มีใครเข้าถึง การปิดประตูกับทุกอย่างเพียงย้ายคอขวดกลับไปที่คนรีวิวสำหรับการเปลี่ยนแปลงที่ไม่เคยต้องใช้คนเลย Approval gates พูดถึงว่าจะวางจุดหยุดไว้ตรงไหนสำหรับงานที่มีความเสี่ยงสูงกว่า

ออกแบบการรีวิวให้รองรับการขยายตัว

การรีวิวผลลัพธ์จาก agent ที่รันขนานกันไม่เหมือนกับการรีวิว PR ของเพื่อนร่วมทีม คุณมีมากกว่า มันมาเป็นระลอก และคุณมักรู้ที่มาที่ไปของมันน้อยกว่า สามวิธีนี้ช่วยลดต้นทุนต่อชิ้นของคนรีวิวได้

แนบหลักฐานไว้กับ Task ไม่ใช่กับความจำของคุณ การรันควรคืนค่ากลับมาเป็นสรุปการเปลี่ยนแปลง ผลลัพธ์ของ typecheck และ test ผลลัพธ์ของ build และข้อจำกัดที่รู้อยู่ ทั้งหมดอยู่ในบันทึก เมื่อคุณเปิดรายการ Ready for review คุณกำลังอ่านแฟ้มคดี ไม่ใช่พยายามประกอบเรื่องราวว่ามันเกิดอะไรขึ้น นั่นคือความต่างระหว่างการรีวิวด้วยหลักฐานระดับ Task กับการรันทุกอย่างซ้ำเองเพื่อเรียกความเชื่อใจกลับมา

รีวิวการตัดสินใจ ไม่ใช่การกดปุ่ม สิ่งที่เครื่องตรวจได้ เช่น การจัดรูปแบบ ความปลอดภัยของ type การเทสต์ผ่านหรือไม่ ควรถูกกั้นด้วยเครื่องก่อนที่ Task จะมาถึงคุณ แนวทางการรีวิวโค้ดของ Google ก็แบ่งแบบเดียวกัน: ทำสิ่งที่เครื่องมือตรวจสอบได้ให้เป็นอัตโนมัติ เพื่อให้คนใช้ความสนใจไปกับ design และความเข้ากันได้ วิจารณญาณที่มีจำกัดของคุณควรไปอยู่ที่ “การเปลี่ยนแปลงนี้ถูกต้องหรือไม่” ไม่ใช่ “มันคอมไพล์ผ่านไหม”

จำกัดงานที่ค้างอยู่ในมือ การกำหนดเพดานแข็งว่ามี Task อยู่ใน In progress ได้มากแค่ไหนในแต่ละครั้ง ช่วยไม่ให้คอลัมน์ Ready for review กลายเป็นกำแพงที่คุณไม่มีวันขยายได้ นี่คือแนวคิด WIP limit ของคันบัง ที่นำมาใช้กับ agent: การเริ่มรันตัวที่หกทั้งที่มีห้าตัวรอคุณอยู่ไม่ได้เพิ่ม throughput มันแค่ซ่อนคิวไว้ และยังช่วยให้มอนิเตอร์ agent ที่กำลังรันอยู่ได้ด้วย เพื่อแยกว่าตัวไหนค้างกับตัวไหนแค่ช้า ก่อนที่มันจะไปถึงประตู

ตัวอย่างจริงหนึ่งเคส จาก ticket สู่ PR ที่ merge แล้ว

ลองดู Task ที่ดูสมจริงสักอัน SH-312: “จำกัดอัตราการเรียกใช้ public search endpoint” มีคนปั้นมันใน Backlog พร้อมเกณฑ์การยอมรับ (ได้ 429 หลังจาก N คำขอต่อนาทีต่อ key, มี header ที่เขียนเอกสารไว้, มีเทสต์) แล้วเลื่อนไปที่ Ready

Agent สามตัวกำลังทำงานใน Space เดียวกันแบบขนาน ตัวหนึ่งรับ SH-312 ไป โคลน repository ที่ตั้งค่าไว้ลงบน Computer และรันในworktree ที่แยกออกมา เพื่อให้ branch ของมันไม่ชนกับอีกสองการรันที่กำลังดำเนินอยู่ มันเขียนตัวจำกัดอัตรา เพิ่มเทสต์ รัน typecheck และชุดเทสต์ เปิด PR ที่ชื่อมี Task ID อยู่ และเลื่อน SH-312 ไปเป็น Ready for review พร้อมสรุปการเปลี่ยนแปลง ผลลัพธ์เทสต์ที่ผ่าน และข้อจำกัดหนึ่งข้อที่บันทึกไว้: ตัวนับอยู่ในโปรเซส ไม่ได้แชร์ข้าม instance

คุณเปิด Task ไม่ใช่สิบห้าแท็บ หลักฐานอยู่ตรงนั้น และโน้ตเรื่องข้อจำกัดนั่นแหละคือส่วนที่มีประโยชน์: เทสต์ผ่าน แต่ state ที่แชร์ข้าม instance เป็นการตัดสินใจเชิงออกแบบที่คุณต้องเลือกเอง คุณทิ้งคอมเมนต์ไว้แล้วเลื่อนไปที่ Changes requested คอมเมนต์นั้นเริ่มการรันต่อเนื่องบน Task เดิม agent สลับตัวนับไปใช้ shared store แล้วส่งหลักฐานชุดใหม่กลับมา ครั้งนี้คุณอนุมัติ การเลื่อน SH-312 ไปเป็น Done คือการตัดสินใจของคุณ บันทึกไว้เป็นการเปลี่ยนสถานะที่มีชื่อคุณกำกับ ไม่ใช่ผลข้างเคียงเงียบ ๆ จากการ merge git

ระหว่างนั้น Agent อีกสองตัวก็อยู่ใน Ready for review เพราะคิวเป็นคอลัมน์ ไม่ใช่กล่องขาเข้าของคุณ คุณจึงเคลียร์ต่อเป็นลำดับถัดไปตามลำดับ โดยไม่หลุดประเด็น

เส้นแบ่งที่คุณเก็บไว้ให้คน

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

คุณสร้างสิ่งนี้เองได้ด้วย worktree ธรรมเนียมการตั้งชื่อ branch และวินัย หรือจะให้ Sharkly จัดการ workflow ให้ก็ได้: Agents ที่มอบหมายได้, Tasks ที่พาการรันและหลักฐานของมันมาด้วย และบอร์ดที่ Ready for review เป็นคอลัมน์ที่คุณระบายออก เพื่อให้ agent ค้นคว้า ลงมือ ทำการทดสอบ และรายงาน ขณะที่คนเก็บการตัดสินใจขั้นสุดท้ายไว้ ถ้าคุณรัน agent หลายตัวอยู่แล้ว นี่คือที่ที่คุณจัดการ Task และผลลัพธ์ของพวกมันได้ในที่เดียว แทนที่จะพึ่งความจำ

คำถามที่พบบ่อย

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

ทุกการเปลี่ยนแปลงจาก agent ควรมีคนรีวิวไหม? ไม่ควร ปิดประตูกับการเปลี่ยนแปลงที่ปล่อยถึงผู้ใช้ หรือแตะเรื่อง auth ข้อมูล เงิน หรือ public API ปล่อยงานความเสี่ยงต่ำหรืองานที่ generate ใหม่ได้ ให้ผ่านด้วยการตรวจจากเครื่องเท่านั้น การปิดประตูกับทุกอย่างเพียงย้ายคอขวดกลับไปที่คนรีวิวสำหรับการเปลี่ยนแปลงที่ไม่เคยต้องใช้คน

การ merge PR ก็เท่ากับการอนุมัติงานไม่ใช่หรือ? ไม่ใช่ การ merge เป็นการดำเนินการของ git ส่วนการอนุมัติคือคนตัดสินว่าการเปลี่ยนแปลงนั้นตรงตามเกณฑ์ของ Task การแยกสองอย่างนี้ออกจากกันช่วยรักษาคุณภาพการรีวิวเมื่องานมีปริมาณมาก ดู human-in-the-loop coding agents ว่าควรเก็บการตัดสินใจของคนไว้ตรงไหน