ทีม Claude Code เปิดวิธีรีวิวโค้ดเมื่อ AI เขียน 90% — PR ที่ merge เพิ่มกว่าเท่าตัว revert ลดกว่า 40% ใช้ classifier แบ่งระดับความเสี่ยง และจำกัดรอบรีวิวไว้ที่ 3 รอบหลังเจอ PR วน 50 รอบข้ามคืน

ทีมที่ใช้ coding agent จริงจังเจอปัญหาเดียวกันหมด คือโค้ดเพิ่มเร็วเกินกว่าที่คนจะอ่านไหว บล็อก claude.dev ตอน “How the Claude Code team does code review” (15 ต.ค. 2026 โดย Addy Osmani, Morgan Westlee Lunt และ Qing Wang) ให้ตัวเลขจากข้างในว่า monorepo ของ Anthropic มีการเปลี่ยนแปลงที่ลงต่อวันเพิ่มจาก ราว 2,500 ใน พ.ค. เป็นมากกว่า 30,000 ใน ก.ย. และ Claude เขียนโค้ดของ Claude Code เองราว 90%

ทีมไม่ได้ยกเลิกการรีวิว แต่เปลี่ยนเป้าหมายเป็น “ใช้เวลาคนให้น้อยที่สุดโดยที่ revert และ incident ไม่เพิ่ม” ผลระหว่าง มิ.ย.–ก.ย. คือ PR ที่ merge เพิ่มขึ้นกว่าเท่าตัว ขณะที่สัดส่วนที่ต้อง revert ลดลงกว่า 40% บล็อกยังประกาศว่า Code Review for Claude Code เปิดให้ใช้ทั่วไปแล้วบนแพลน Team และ Enterprise และคำสั่ง /code-review ใช้รันเวอร์ชันเบาบนเครื่องได้

หลายชั้นแทนด่านเดียว และแบ่งระดับตามความเสี่ยง

ก่อนเปิด PR Claude ต้องรันเทสต์ build และ linter แล้วแสดงผลจริงแทนที่จะบอกว่าเสร็จแล้ว จากนั้นให้ subagent อีกตัวรีวิว diff ใน context ใหม่ บน PR มี CI, AI review ที่ให้หลาย agent หาบั๊กพร้อมกันแล้ว ให้อีกกลุ่มโหวตยืนยันแต่ละข้อก่อนโพสต์ และ security review แยกอีกรอบ ถ้ายังมีข้อค้นพบที่ไม่ได้ปิด PR จะ merge ไม่ได้ ต้องแก้หรือปิด thread พร้อมเหตุผล

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

ระดับ	ตัวอย่าง	ต้องมีคนอนุมัติ
ต่ำ	เอกสาร ข้อความ ฟีเจอร์ภายใน งานเพิ่มเติมที่อยู่หลัง flag	ไม่ต้อง ถ้า automated review และ security เขียวหมด
กลาง	งานโปรดักต์ทั่วไป, caching, auto-updater, system prompt	1 คน
สูง	โค้ดเสี่ยงที่สุด และ path บางชุดที่บังคับไว้	2 คน

ระดับมาจาก classifier และมี classifier ตัวที่สองตรวจซ้ำว่า PR นี้ควรมีคนดูเพิ่มหรือไม่ มีกฎที่ไม่ยกเว้นอยู่ไม่กี่ข้อ คือไฟล์ CI workflow และ path ที่ owner ระบุว่าอ่อนไหวต้องมีคนอนุมัติเสมอ, ทางลัดใช้ได้เฉพาะผู้เขียนที่อยู่ใน trusted list, การอนุมัติของ agent ไม่นับเป็นการอนุมัติของคน, คนที่สั่ง agent ให้เขียนนับเป็นผู้รีวิวคนหนึ่ง และถ้ามี commit ใหม่ที่ระบบรับรองไม่ได้ เช่น agent push เพิ่ม ต้องอนุมัติใหม่

ข้อมูลที่น่าสนใจที่สุด: reviewer กับ agent วนกันไม่จบ

• ใช้ incident เป็น eval: ทีมรวบรวม PR ที่เคยทำให้เกิด incident หรือถูก revert ให้วิศวกรที่รู้โค้ดส่วนนั้นยืนยันบั๊ก แล้วรัน reviewer กับชุดนี้ทุกวัน การปรับ prompt เครื่องมือ หรือโมเดลจะถูกเก็บไว้ก็ต่อเมื่อคะแนนขึ้น
• วัด noise จากพฤติกรรมคน ว่าผู้เขียนแก้ตาม บอกว่าผิด บอกว่าตั้งใจ หรือเห็นว่าไม่สำคัญ เพราะถ้าผู้เขียนเป็น agent มันจะแก้ทุก nit ซึ่งทำให้เกิด commit ใหม่และรีวิวอีกรอบ
• มี PR หนึ่งของ CLI ที่ รีวิวและแก้วนกันกว่า 50 รอบข้ามคืน จนผู้เขียนต้องหยุดเอง เมื่อ git blame ดูก็พบว่า ราว 59% ของสิ่งที่ reviewer เตือนซ้ำเป็นโค้ดที่มีอยู่ตั้งแต่รีวิวรอบแรก ทีมจึงตั้ง cap ที่ 3 รอบ ซึ่งหลังจากนั้น reviewer จะขอให้ผู้เขียนทบทวนแนวทาง และรีวิวเฉพาะ diff ใหม่ ผลคือ PR ที่ผ่านในรอบเดียวเพิ่มจาก 65% เป็น 78%, ที่ต้องใช้ 5 รอบขึ้นไปลดจาก 8.9% เป็น 1.5% และค่าเฉลี่ยรอบรีวิวลดจาก 2.08 เป็น 1.32
• ตอนเริ่มทดลอง AI review สัดส่วน PR ภายในที่ได้คอมเมนต์ที่มีสาระเพิ่มจาก 16% เป็น 54%

ไฟล์ REVIEW.md และเช็กลิสต์สำหรับทีมอื่น

นอกจาก CLAUDE.md ที่บอกว่าโปรเจกต์คืออะไร ทีมให้ code owner เขียน REVIEW.md เพื่อบอก reviewer ว่าส่วนไหนสำคัญ ไฟล์ที่ดีจะสั้น บอกว่าความล้มเหลวของ repo นั้นหน้าตาเป็นอย่างไร (ตัวอย่างในบล็อกคือ ถ้าเป็นเอกสาร ความล้มเหลวคือ “it lies” ถ้าเป็น config คือ “it misroutes”), จำกัดจำนวน nit, ระบุ path ที่ข้ามได้ และให้อ้างไฟล์กับบรรทัดเป็นหลักฐาน ท้ายบล็อกมีเช็กลิสต์ เช่น เพิ่มหัวข้อ “Testing / Risk / How to revert” ใน PR template, เริ่ม AI reviewer ที่ repo เดียวแล้วปรับ REVIEW.md สักสองสามสัปดาห์, ใช้ CODEOWNERS กับ branch protection บังคับให้งาน auth, billing, CI และ installer ต้องมีคนดูเสมอ และใช้ merge queue, feature flag และ rollback ในขั้นตอนเดียว

บล็อกยอมรับข้อจำกัดไว้ด้วยว่ายังไม่มี circuit breaker ที่จะเข้มขึ้นอัตโนมัติเมื่อ revert เพิ่ม และวิศวกรในทีมอยากให้มีก่อนจะปล่อยโค้ดให้ merge โดยไม่มีคนดูมากกว่านี้

มุมมอง AI Curator

ควรอ่านบล็อกนี้ในฐานะทั้งคู่มือและบทความขายของ ตัวเลขทั้งหมดเป็นตัวเลขภายในที่ตรวจสอบจากภายนอกไม่ได้ และจบด้วยการประกาศ GA ของผลิตภัณฑ์ แต่หลักการส่วนใหญ่ไม่ได้ผูกกับ Anthropic เลย ได้แก่ แบ่งระดับความเสี่ยงตามตัวการเปลี่ยนแปลง, ไม่ให้ bot อนุมัติแทนคน, คนที่สั่ง agent ต้องรับผิดชอบ, สร้าง eval จาก incident ของตัวเอง และจำกัดรอบรีวิว ข้อสุดท้ายสำคัญที่สุดสำหรับทีมไทยที่เพิ่งเริ่มต่อ AI reviewer เข้ากับ coding agent เพราะค่าใช้จ่ายจากการปล่อยให้ agent สองตัววนกันทั้งคืนจะไปอยู่ในบิลโทเคนก่อนที่ใครจะรู้ตัว

เรื่องที่ควรคิดต่อคือฝั่งองค์กรที่มีกฎ “ต้องมีคนอ่านทุกบรรทัด” จากข้อกำกับ เช่น ธนาคารหรือหน่วยงานที่อยู่ใต้ ธปท. หรือ ก.ล.ต. บล็อกนี้เสนอว่าคำถามที่ถูกต้องคือ “ความเสี่ยงของการเปลี่ยนแปลงนี้คืออะไร และด่านไหนควรจับมัน” ไม่ใช่ “มีคนอ่านไหม” ซึ่งเป็นข้อโต้แย้งที่ฝ่าย compliance ต้องเห็นหลักฐานก่อนจะยอมรับ ทีมที่อยากไปทางนั้นควรเริ่มจากเก็บตัวเลข revert และ incident ของตัวเองให้ได้ก่อน เพราะ Anthropic เองก็ใช้ตัวเลขชุดนี้เป็นเงื่อนไขกำกับทุกการผ่อนกฎ

แหล่งข่าว

• How the Claude Code team does code review — claude.dev Blog
• Code Review for Claude Code — Claude Code Docs