coding agent ที่เปิด pull request ได้นั้นมีประโยชน์ แต่ coding agent ที่ merge pull request ได้ในตอนที่ไม่มีใครเฝ้าดู คือความเสี่ยงที่ถือสิทธิ์ commit อยู่เต็มมือ ช่องว่างระหว่างสองประโยคนี้คือปัญหาทั้งหมด เมื่อ agent push ขึ้น branch, รันเทสต์ และกด merge ได้แล้ว คำถามจะไม่ใช่ "มันทำงานได้ไหม" อีกต่อไป แต่กลายเป็น "อำนาจของมันสิ้นสุดตรงไหน"
ทีมส่วนใหญ่ตอบคำถามนี้โดยบังเอิญ agent ได้สิทธิ์อะไรก็ตามที่ runtime ตั้งไว้ให้ การรีวิวเกิดขึ้นใน terminal ไหนก็ตามที่เริ่มรันงาน และบันทึกว่าใครอนุมัติอะไรก็อยู่ใน scrollback ของใครสักคน วิธีนี้ใช้ได้จนกว่าคุณจะรัน agent สามตัวข้ามสอง repository แล้วการ deploy วันศุกร์ก็ปล่อยของที่ไม่มีใครได้อ่านออกไป Approval gate คือทางแก้ แต่ใช้ได้ก็ต่อเมื่อมันเป็นจุดตรวจที่เป็นจริงในระบบที่ใช้ร่วมกัน ไม่ใช่ความเคยชินที่หวังว่าทุกคนจะทำตาม
ระบบที่ใช้ร่วมกันนั้นคือสิ่งที่ Sharkly ให้บริการอยู่ คุณมี coding agent อยู่แล้ว Sharkly เปลี่ยนการรันของพวกมันให้กลายเป็น Task ที่มีสถานะ มี Assignee และมีขั้นตอนรีวิวที่คนต้องตั้งใจทำจริง ๆ บทความนี้จะพาดูโมเดลการทำงานที่อยู่เบื้องหลัง ใครมอบหมายงาน ใครรัน ใครรีวิว ใครรับงาน และจุดหยุดควรอยู่ตรงไหนกันแน่ เพื่อให้ agent ไม่มีทาง merge การเปลี่ยนแปลงของตัวเองโดยไม่ผ่านการรีวิว
Approval gate จริง ๆ แล้วคืออะไร
Approval gate คือจุดหนึ่งใน lifecycle ของงาน ที่การทำงานอัตโนมัติหยุดลงและรอให้คนตัดสินใจขั้นถัดไป ไม่ใช่คำเตือน ไม่ใช่ log บรรทัดหนึ่งที่เลื่อนผ่านได้ แต่เป็นสถานะที่งานค้างอยู่จนกว่ามนุษย์จะขยับมัน
ความต่างที่สำคัญที่สุดคือความต่างระหว่าง agent ที่เสนอการเปลี่ยนแปลง กับ agent ที่ปล่อยมันขึ้นจริง การเปิด pull request คือการเสนอ ส่วนการ merge คือการตัดสินใจเกี่ยวกับ production สองอย่างนี้เป็นอำนาจคนละระดับ และอย่างหลังคือจุดที่ดุลยพินิจของทีมต้องอยู่ Sharkly ทำให้เส้นแบ่งนี้ชัดเจน แม้จะเชื่อมต่อ GitHub ไว้แล้ว การ merge pull request ก็ไม่เปลี่ยนสถานะของ Task การ merge ยังคงเป็นการกระทำของคนที่ถูกบันทึกไว้ ไม่ใช่ผลข้างเคียงที่ agent ก่อขึ้นเองเมื่อทำงานเสร็จ
จำเส้นแบ่งนี้ไว้ให้ดี เพราะเรื่องเล่า "agent ทำ prod พัง" ส่วนใหญ่แท้จริงแล้วคือเรื่องของด่านตรวจที่หายไประหว่างการเสนอ กับการปล่อยขึ้นจริง
โมเดลการทำงาน: มอบหมาย, รัน, รีวิว, รับงาน
Sharkly แบ่งงานออกเป็นสี่บทบาท แต่ละบทบาทมีหน้าที่เดียว สัญญาถูกระบุไว้ตรง ๆ ว่า Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนกำหนดทิศทาง มอบอำนาจ และรับผลลัพธ์
- มอบหมาย คนอธิบายความต้องการและกำหนด Assignee Task หนึ่งงานมีการมอบหมายสองส่วนที่แยกจากกัน คือ People ที่เกี่ยวข้อง และ execution Assignee เพียงหนึ่งเดียว ซึ่งเป็น Agent หรือ Crew ที่ลงมือทำงานนั้น การเปลี่ยนอันหนึ่งไม่กระทบอีกอันหนึ่ง
- รัน execution Assignee ลงมือทำงานใน git worktree ที่แยกออกมา ทำให้งานที่รันพร้อมกันไม่ไปยุ่งไฟล์ของกันและกัน ความคืบหน้า อุปสรรค และผลลัพธ์จะกลับมาอยู่ที่ Task
- รีวิว เมื่อ Agent ทำงานเสร็จ มันจะปล่อยให้ Task รอการรีวิวจากคน แทนที่จะปิดงานเอง diff ผลการทดสอบ และสรุปการเปลี่ยนแปลงถูกแนบไว้กับ Task ไม่ใช่กับ terminal
- รับงาน คนอ่านหลักฐานแล้วตัดสินใจว่าจะขอให้แก้ไข หรือรับงานและ merge การรับงานคือก้าวสุดท้าย และมีแต่คนเท่านั้นที่ทำได้
คุณค่าไม่ได้อยู่ที่ Sharkly รัน agent ให้ แต่อยู่ที่สี่บทบาทนี้ยังมองเห็นได้ในที่เดียว แทนที่จะยุบรวมไปกับ terminal ที่บังเอิญเปิดอยู่ ถ้าอยากเจาะลึกในครึ่งที่เป็นการรีวิว อ่านต่อได้ที่ human-in-the-loop coding agents
ทำให้ด่านตรวจเป็นสถานะ ไม่ใช่ความเคยชิน
ด่านที่ต้องคอยจำ คือด่านที่สักวันคุณจะข้ามมันไป ดังนั้นจงฝังมันไว้ใน lifecycle ของงาน
สถานะของ Sharkly มีความหมายเชิงระบบผ่านหมวดหมู่ของมัน Backlog คือสถานะพักงาน Task ที่อยู่ตรงนั้นจะไม่ถูกรันแม้จะมอบหมาย Agent ไว้แล้ว การย้ายมันเข้าหมวดพร้อมทำงานคือสิ่งที่ทำให้เริ่มรันได้ Completed คือสถานะสิ้นสุด และการไปถึงตรงนั้นเป็นการกระทำของคน ไม่ใช่สิ่งที่ Agent ตั้งให้ตัวเอง
สถานะของ Task ถูกแยกออกจากสถานะการทำงานของ Agent อย่างจงใจ ขณะที่สถานะ lifecycle ขึ้นว่า In Progress ตัว Agent ข้างใต้จะกำลังทำงาน รอคนตอบ รอการรีวิวจากคน หรือรายงานข้อผิดพลาดอยู่ก็ได้ การแยกกันนี้แหละคือด่านตรวจ Agent สามารถทำงานจนจบและแสดงสถานะ "รอการรีวิวจากคน" โดยที่ Task ไม่เคยขยับไปสู่สถานะที่สื่อว่ามันถูกปล่อยขึ้น production แล้ว งานจะกลับมาอยู่ที่ Task และหยุดอยู่ตรงนั้นจนกว่าจะมีคนรับมัน
นี่ก็เป็นเหตุผลที่ทำให้รัน agent หลายตัวพร้อมกันได้อย่างปลอดภัย เมื่อ agent ห้าตัวที่รันขนานกันใน worktree ที่แยกจากกัน มาลงเอยในคอลัมน์รีวิวเดียวกัน คุณมีที่เดียวให้จัดลำดับความสำคัญ แทนที่จะต้องคอยเฝ้า terminal ห้าอัน
ตัวอย่างจริงหนึ่งเคส: จากตั๋วงานถึง PR ที่ merge แล้ว
ลองพา Task หนึ่งงานเดินผ่านขั้นตอนทั้งหมด โดยใช้รูปแบบรหัส SH-312 ของ Sharkly
- เปิดงาน คนสร้าง
SH-312ซึ่งเป็นงานบั๊ก: "Search คืนผลลัพธ์เก่าหลังเปลี่ยน filter" คำอธิบายมีทั้งเป้าหมาย วิธีทำซ้ำ และเกณฑ์การยอมรับ Assignee: Claude Code Agent ที่ผูกกับ repository ของ search - วางกรอบงาน Agent ค้นคว้า codebase และประวัติที่เกี่ยวข้อง ยืนยันขอบเขตงาน แล้วโพสต์แผนกลับไปที่ Task คนอ่านแผนแล้วย้าย
SH-312ออกจาก Backlog ไปยังสถานะพร้อมทำงาน ซึ่งเป็นสัญญาณให้เริ่มได้ - ลงมือทำ Agent รับ Task ไปทำใน worktree ใหม่ เขียน fix รัน typecheck และชุดทดสอบ แล้วเปิด pull request ที่มี
SH-312อยู่ในชื่อ เพื่อให้ Sharkly เชื่อม PR กลับไปที่ Task - หยุดที่ด่านตรวจ Agent ไม่ merge มันแนบสรุปการเปลี่ยนแปลง ผลทดสอบที่ผ่าน และข้อจำกัดที่รู้ไว้ แล้วปล่อย
SH-312รอการรีวิวจากคน งานได้กลับมาอยู่ที่ Task แล้ว - รีวิว คนเปิด
SH-312อ่าน diff และหลักฐานทั้งหมดในมุมมองเดียว แล้วสังเกตว่า fix ไปแตะ shared query helper จึงคอมเมนต์ขอให้แก้ให้แคบลง สำหรับ Task ที่มี Agent Assignee พร้อมอยู่ คอมเมนต์นั้นจะจัดคิวรันใหม่ วงจรขอแก้จึงยังอยู่ในบันทึก แทนที่จะไปเริ่มกันใหม่ในแชตส่วนตัว - รับงานและ merge การรันรอบสองผ่านการรีวิว คนอนุมัติ pull request merge มัน แล้วย้าย
SH-312ไปเป็น Completed เพราะการ merge ไม่ปิด Task อัตโนมัติ การรับงานกับการ merge จึงเป็นสองการตัดสินใจของคนที่ถูกบันทึกไว้ ไม่ใช่ลูกโซ่อัตโนมัติครั้งเดียว
ทุกขั้นในสายนี้ตรวจสอบย้อนหลังได้ นั่นคือหัวใจของ workflow แบบ traceable จาก requirements สู่โค้ด คุณตอบคำถาม "ใครอนุมัติเรื่องนี้ และอนุมัติบนหลักฐานอะไร" ได้โดยไม่ต้องขุด scrollback ของใครสักคน
ไม่ควรวางด่านตรวจไว้ตรงไหน
ด่านที่มากขึ้นไม่ได้แปลว่าปลอดภัยขึ้นโดยอัตโนมัติ มันเพิ่มแรงเสียดทานที่ฝึกให้คนกดผ่าน ๆ ควรวางด่านตรงที่ต้นทุนของการ merge ผิด ๆ เป็นของจริง สำหรับการเปลี่ยนแปลงเล็ก ๆ ที่นิยามชัดและความเสี่ยงต่ำ ซึ่งมอบหมายให้ Agent ตัวเดียว จุดหยุดเพื่อรีวิวก่อน merge ก็เพียงพอ ไม่ต้องมี Crew หรือขั้นอนุมัติเพิ่มซ้อนเข้าไป ควรเพิ่มความเข้มของการรีวิวเมื่อวงกว้างของผลกระทบใหญ่ เช่น shared code, migration หรืออะไรก็ตามที่แตะระบบ auth หรือ billing
ด่านเดียวที่คุณไม่ควรถอดออกคือ merge gate Agent จะค้นคว้า เขียน ทดสอบ และเสนอทั้งวันก็ได้ แต่การเปลี่ยนแปลงของมันจะไปถึง main branch หรือไม่ เป็นการตัดสินใจของคน และควรเป็นเช่นนั้นเสมอแม้ agent จะถูกเกือบตลอดเวลา จับคู่การรีวิวระดับ Task ของ Sharkly เข้ากับ branch protection ที่คุณมีอยู่ เพื่อให้แพลตฟอร์มบังคับใช้ตามที่ workflow ตั้งใจ และใช้เครื่องมือที่ทีมคุณใช้อยู่แล้วต่อไป: เชื่อม GitHub และ assign ตั๋วงานให้ AI agent โดยไม่ต้องรื้อกระบวนการเดิม
ถ้าคุณรัน coding agent หลายตัวอยู่แล้ว และเริ่มตามไม่ทันว่าตัวไหนเสร็จ ตัวไหนล้มเหลว ตัวไหนกำลังรอคุณอยู่ คอลัมน์รีวิวนั่นแหละคือเหตุผลที่ควรลอง Sharkly ลองเอา agent ที่มีอยู่มารันผ่านมันดู แล้วเก็บการตัดสินใจ merge ไว้ในที่ที่มันควรอยู่
คำถามที่พบบ่อย
Sharkly หยุด agent ไม่ให้ merge ด้วยตัวเองได้ไหม ได้ การ merge pull request ไม่เปลี่ยนสถานะของ Task ใน Sharkly การรันจึงจบที่ "รอการรีวิวจากคน" แทนที่จะปล่อยการเปลี่ยนแปลงขึ้นจริง จับคู่กับ branch protection ของ GitHub เพื่อบังคับให้มีการรีวิวที่จำเป็นในระดับ repository
สถานะ Task กับสถานะ agent ต่างกันอย่างไร สถานะ Task คือหมวดหมู่ใน lifecycle (Backlog, Started, Completed และอื่น ๆ) ส่วนสถานะ agent คือสิ่งที่การรันกำลังทำอยู่ตอนนี้ กำลังทำงาน รอคนตอบ รอรีวิว หรือ error Task หนึ่งงานสามารถอยู่ใน In Progress ขณะที่ Agent รอคุณอยู่ได้
ต้องมี Crew ทุกงานที่ต้องรีวิวไหม ไม่ต้อง สำหรับงานเล็กที่ขอบเขตชัดเจน มอบหมาย Task ให้ Agent ตัวเดียวแล้วใช้จุดหยุดรีวิวก่อน merge เก็บ Crew ไว้ใช้กับเป้าหมายที่ต้องมี leader Agent คอยประสานสมาชิกหลายตัว
