วิธีรีวิวโค้ดที่ AI สร้างด้วยหลักฐานระดับงาน

Pull request เข้ามาในคิวของคุณพร้อม 340 บรรทัดที่เปลี่ยนแปลงในเก้าไฟล์ เขียนโดย coding agent ตัวหนึ่ง ตัว diff ไม่ได้บอกคุณว่า agent ถูกสั่งให้ทำอะไร ลองวิธีไหนแล้วทิ้งไป รันอะไรเพื่อ убе ตัวเองว่างานใช้ได้ หรือรู้ตัวว่าตรงไหนที่ตัดมุมไป เพราะฉะนั้นคุณจะทำอย่างใดอย่างหนึ่งในสองอย่าง: อ่านผ่าน ๆ แล้วอนุมัติ หรือไม่ก็สร้างความเปลี่ยนแปลงใหม่ทั้งหมดตั้งแต่ต้น อย่างแรกคือวิธีที่โค้ดแย่ ๆ ถูกปล่อยออกไป อย่างที่สองหมายความว่า agent ไม่ได้ช่วยให้คุณประหยัดอะไรเลย

การรีวิวโค้ดที่สร้างโดย AI ให้ดีเป็นงานคนละแบบกับการรีวิว PR ของเพื่อนร่วมงาน เพราะผู้เขียนไม่สามารถนั่งข้าง ๆ คุณแล้วอธิบายเหตุผลได้ ทางแก้คือรีวิว diff พร้อมกับหลักฐานของมัน: เป้าหมาย การตรวจสอบที่รันไป และข้อจำกัดที่ agent ระบุไว้แล้ว นั่นคือสิ่งที่ Sharkly ถูกสร้างขึ้นมาเพื่อรองรับ Sharkly วางตัวอยู่เหนือ coding agent ของคุณ (Claude Code, Codex, Gemini และตัวอื่น ๆ) และเก็บเป้าหมาย การเปลี่ยนแปลง ผลการตรวจสอบ และการรีวิวโดยมนุษย์ของทุกการรันไว้ใน Task เดียว แทนที่จะกระจายอยู่ตาม terminal และคำอธิบาย PR

คู่มือนี้จะพาไปดูโมเดลการทำงานที่อยู่เบื้องหลังสิ่งนั้น: ใครมอบหมายงาน ใครรัน ใครรีวิว ใครอนุมัติ สถานะและประตูต่าง ๆ ที่แยกงานของ agent ออกจากงานของมนุษย์ และตัวอย่างจริงหนึ่งตัวอย่างตั้งแต่ ticket จนถึง PR ที่ merge แล้ว

คำตอบสั้น ๆ

รีวิวโค้ดที่สร้างโดย AI ในระดับ Task ไม่ใช่ระดับ diff ให้ agent แนบสรุปการเปลี่ยนแปลง ผลการ typecheck/test/build ที่มันรัน และข้อจำกัดที่รู้อยู่ เข้ากับ Task ที่แชร์กัน แล้วเลื่อน Task นั้นไปยังสถานะรีวิว มนุษย์อ่านหลักฐานควบคู่กับ diff ขอให้แก้ไขหรืออนุมัติ และตัดสินใจเรื่องการ merge Agent เป็นผู้สร้างและตรวจสอบ คนเป็นผู้อนุมัติ

ทำไมการรีวิวแค่ diff อย่างเดียวถึงไม่พอ

การอ่านโค้ดยากกว่าการเขียนโค้ด ข้อเท็จจริงที่มีการบันทึกไว้ดีเกี่ยวกับการรีวิวโค้ด คือผู้รีวิวมี context น้อยกว่าผู้เขียน และเมื่อผู้เขียนเป็น agent ช่องว่างนั้นก็กลายเป็นทั้งหมด GitHub diff โชว์ให้คุณเห็นปลายทาง แต่ไม่เคยโชว์เส้นทาง คุณมองไม่เห็นว่า agent ลองทำ caching layer ก่อน เจอ race condition แล้วถอยกลับออกมา คุณมองไม่เห็นว่ามันรัน test suite แล้วมี test ที่ flaky ตัวหนึ่งล้มเหลวโดยไม่เกี่ยวข้องกับการเปลี่ยนแปลง

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

หลักฐานระดับ Task หมายถึงอะไรจริง ๆ

หลักฐานระดับ Task คือบันทึกที่ Agent แนบเข้ากับ Task ของมัน: เป้าหมายที่มันใช้ทำงาน การเปลี่ยนแปลงที่มันสร้าง การตรวจสอบที่มันรัน และข้อจำกัดที่มันรู้อยู่ แทนที่จะได้แค่ diff เปล่า ๆ คุณจะได้ diff พร้อมร่องรอยที่มาที่ไป

ในทางปฏิบัติ ชุดหลักฐานประกอบด้วยสี่สิ่ง:

• เป้าหมายและเกณฑ์การยอมรับ ในคำอธิบาย Task เพื่อให้การรีวิววัดเทียบกับสิ่งที่สั่งไว้ ไม่ใช่เทียบกับสิ่งที่ดูสมเหตุสมผล
• สรุปการเปลี่ยนแปลง ในคำพูดของ agent เอง: มันแตะอะไรและเพราะอะไร
• ผลการตรวจสอบ: เอาต์พุตของ typecheck, เทส และ build ที่ agent รันก่อนส่งงาน
• ข้อจำกัดที่รู้อยู่: edge case ข้อสันนิษฐาน และงานที่ต้องตามต่อที่ agent ระบุไว้ แทนที่จะซ่อน

ทั้งหมดนี้กลับมาอยู่ใน Task การรัน อุปสรรค ผลลัพธ์ และการสนทนาติดตามผลอยู่ในไทม์ไลน์เดียว ผู้รีวิวจึงเปิดบันทึกเพียงรายการเดียว แทนที่จะต้องเอา PR, เธรด Slack และ prompt ที่จำได้ครึ่ง ๆ กลาง ๆ มาต่อเข้าด้วยกัน นี่คือวินัยที่อยู่เบื้องหลัง workflow จาก requirement สู่โค้ดที่ตรวจสอบย้อนกลับได้: หลักฐานเป็นส่วนหนึ่งของสิ่งที่ส่งมอบ

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

การรีวิวที่ดีขึ้นอยู่กับบทบาทที่ชัดเจน สัญญาสั้น ๆ: agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนกำหนดทิศทาง ให้อำนาจ และอนุมัติผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้วิจารณญาณของทีม

Sharkly ไม่ใช่ตัวแทนของ Claude Code, Codex หรือเครื่องมือรันอื่น ๆ มันเพิ่มเลเยอร์ Task, Computer, context และการรีวิวที่ใช้ร่วมกันเข้าไปรอบ ๆ เครื่องมือที่ทีมคุณใช้อยู่แล้ว runtime เขียนโค้ด ส่วน Sharkly ตัดสินว่าการรีวิวจะไปตกในคิวของใคร และต้องมีหลักฐานอะไรบ้างก่อนที่คนจะเข้ามาดู ถ้าอยากได้เวอร์ชันเจาะลึกของฝั่งการมอบหมาย ดู ใครมอบหมายและใครอนุมัติงานของ agent

สถานะและประตูรีวิว: agent เลื่อนเป็น Ready for review คนเลื่อนเป็น Done

ประตูรีวิวคือเส้นแบ่งสถานะ ใน Sharkly ทุกสถานะของ task อยู่ในหมวดหมู่ตายตัวที่สื่อความหมายเชิงระบบ: Backlog (พักไว้), Unstarted (พร้อม ยังไม่เริ่ม), Started (กำลังดำเนินการ) และ Completed (จุดสิ้นสุด) สถานะที่มองเห็นได้หลายสถานะสามารถอยู่หมวดเดียวกันได้ workflow ของ task type หนึ่งจึงรัน Development กับ Ready for review เป็นสองสถานะ Started ที่แยกจากกัน ก่อนที่อะไรจะไปถึง Completed

โครงสร้างนี้เองที่ทำให้ประตูนั้นเป็นของจริง Agent สามารถพา Task จาก Development ไป Ready for review และปล่อยให้ Task รอการรีวิวจากมนุษย์ได้ แต่มันไม่มีสิทธิ์เลื่อน Task เข้าสู่สถานะ Completed ด้วยตัวเอง การยอมรับเป็นการเปลี่ยนสถานะโดยมนุษย์ ซึ่งออกแบบไว้แบบนั้น

ตั้งค่า workflow ให้การเปลี่ยนเข้าสู่สถานะ Completed ต้องมีคนทำ แล้วคุณจะมีประตูรีวิวที่ยังคงอยู่ แม้ agent จะผลิตเร็วเกินกว่าที่คุณจะเฝ้าดูทัน นี่คือเวอร์ชันเชิงกลไกของการรักษา human in the loop สำหรับ coding agent และเป็นจุดที่คุณตัดสินใจว่า จะหยุด agent ตรงไหนก่อนที่มันจะ merge

ตัวอย่างจริง: จาก ticket สู่ PR ที่ merge แล้ว

สมมติ SH-312: “เพิ่ม rate limiting ให้ endpoint ค้นหาสาธารณะ 60 คำขอต่อนาทีต่อ API key”

1. คนหนึ่งเปิด SH-312 พร้อมเป้าหมายนั้นและเกณฑ์การยอมรับสองข้อ: คำขอที่เกินลิมิตต้องตอบกลับ HTTP 429 และลิมิตต้องนับต่อ key ไม่ใช่ต่อ IP Task เริ่มต้นที่ Todo
2. Agent รับงาน เลื่อนเป็น Development และรันใน worktree แยกเฉพาะ เพื่อให้ checkout ของมันไม่ชนกับ agent ตัวอื่นที่ทำงานใน repo เดียวกัน (worktree คือเหตุผลที่การรันแบบขนานยังสะอาด ดู one checkout ต่อหนึ่ง task)
3. Agent ทำ limiter แบบ token-bucket เปิด PR และแนบหลักฐานเข้ากับ SH-312: สรุปการเปลี่ยนแปลง ผล typecheck และ unit test ที่ผ่าน ผล build และข้อจำกัดที่รู้อยู่หนึ่งข้อ: “bucket อยู่ในหน่วยความจำของโปรเซส ลิมิตจึงรีเซ็ตเมื่อ deploy และไม่แชร์ข้าม instance”
4. Agent เลื่อน SH-312 ไป Ready for review มันเข้ามาในคิวของคน พร้อม diff และหลักฐานอยู่ด้วยกัน
5. ผู้รีวิวอ่านบันทึกข้อจำกัดที่รู้อยู่ก่อน ตัดสินว่า bucket ในหน่วยความจำโอเคพอสำหรับตอนนี้ และขอแก้หนึ่งอย่าง: ให้ส่ง header Retry-After กลับไปพร้อม 429 ด้วย Agent แก้ไขแล้วแนบเอาต์พุตเทสที่อัปเดตใหม่
6. ผู้รีวิวอนุมัติ merge PR และเลื่อน SH-312 ไป Done โดยมี ticket ติดตามผลสำหรับ limiter แบบแชร์กันถูก link ไว้แล้ว

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

วิธีรีวิวหลักฐานให้เร็ว และเมื่อไหร่ควรผ่อน

ไม่ใช่ทุกการเปลี่ยนแปลงต้องใช้วิธีเต็มรูปแบบ ใช้กฎการตัดสินใจ

ทำแบบละเอียดเมื่อการเปลี่ยนแปลงแตะเรื่อง auth, การเรียกเก็บเงิน, การย้ายข้อมูล, public API หรืออะไรก็ตามที่ย้อนกลับยาก: อ่าน diff ทีละบรรทัด รันเทสเองอีกรอบ และเช็กบันทึกข้อจำกัดที่รู้อยู่เทียบกับ edge case ของคุณเอง ทำแบบเบาเมื่อการเปลี่ยนแปลงเป็นการแก้ข้อความ การ refactor ภายในที่เทสครบถ้วน หรือการอัปเดต dependency ที่เช็กผ่านหมด: อ่านสรุป กวาดดู diff ยืนยันว่าการตรวจสอบผ่าน แล้วอนุมัติ

เช็กลิสต์รีวิวแบบละเอียดให้เร็ว:

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

ถ้าคุณรัน coding agent หลายตัวอยู่แล้ว นี่คือ workflow ที่ Sharkly มอบให้คุณจัดการในที่เดียว: มอบหมาย Task ให้ agent แนบหลักฐาน รีวิวที่ประตู คุณสร้างชิ้นส่วนต่าง ๆ เองได้ด้วย worktree, เทมเพลต PR และบอร์ดสถานะ หรือจะ ดาวน์โหลด Sharkly แล้วได้ Task, หลักฐาน และประตูรีวิวเป็นระบบเดียว

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

หลักฐานระดับ Task สำหรับโค้ดที่สร้างโดย AI คืออะไร? คือบันทึกที่ agent แนบเข้ากับ Task ของมันควบคู่กับ diff: เป้าหมาย สรุปการเปลี่ยนแปลง ผล typecheck/test/build ที่มันรัน และข้อจำกัดที่รู้อยู่ การรีวิวชุดนั้นเร็วกว่าและปลอดภัยกว่าการรีวิวแค่ diff

AI agent อนุมัติโค้ดของตัวเองได้ไหม? ไม่ได้ และนั่นคือจุดประสงค์ของประตูรีวิว Agent เลื่อน Task ไป Ready for review ได้ แต่การเปลี่ยนเข้าสู่สถานะ Completed เป็นการตัดสินใจของมนุษย์ Agent เป็นผู้สร้างและตรวจสอบ คนเป็นผู้อนุมัติ

จะรีวิวโค้ด AI ให้เร็วขึ้นโดยไม่ประทับตราผ่าน ๆ ได้ยังไง? จับคู่ความพยายามกับความเสี่ยง อ่านหลักฐานทุกการเปลี่ยนแปลง แต่สงวนการรีวิวทีละบรรทัดและการรันเทสซ้ำไว้สำหรับพื้นที่ความเสี่ยงสูงอย่าง auth และ migration ดูว่า ความสามารถในการรีวิวขยายได้แค่ไหน เมื่อ agent เร็วกว่ามนุษย์

ยังต้องใช้ pull request อยู่ไหม? ใช่ Agent เปิด pull request บน GitHub จริง เลเยอร์ Task เพิ่มหลักฐานและประตูรอบ ๆ พวกมัน เพื่อให้ PR ไม่ใช่ที่เดียวที่ context อาศัยอยู่