จดบันทึกการอ่านเรื่อง How the Claude Code team does code review

October 23, 2026 AI, Architecture, Review

จากบทความเรื่อง How the Claude Code team does code review
อธิบายว่าทีมพัฒนา Claude code ของ Anthropic ทำการ review code อย่างไร
มีแนวคิด และ ขั้นตอนการ review code ที่น่าสนใจอย่างไรบ้าง
ในโลกของ code จำนวนมากที่ถูกสร้างหรือ generate มาจาก AI Agent
ซึ่ง code จำนวน 90% ถูก generate ของมาจาก AI Agent
โดยทีมมีเป้าหมายเพื่อลด effort ของคนในการ review ลงไป
และลดความผิดพลาดต่าง ๆ ของ code ลงไปอีกด้วย
มาดูกันว่าทำอย่างไรกัน ?

เริ่มที่เป้าหมายของการทำ code review ก่อน

ซึ่งประกอบไปด้วย 2 เรื่องคือ

• ทำการหาและแก้ไขปัญหาต่าง ๆ ก่อนส่งมอบ
• ทำการ share ความรู้ต่าง ๆ ให้กับคนในทีม (จะได้ไม่เกิดปัญหาเรื่อง strong ownership)

จากบทความนี้จะเน้นที่ข้อแรกก่อน
คือการหาและแก้ไขปัญหา

คำถามที่น่าสนใจคือ “did a human read the code ?”

ถ้าเกิดปัญหาขึ้นมาจะทำการตรวจสอบอย่างไร ?
ใช้คน หรือ automation ?
อะไรคือสิ่งที่เหมาะสมที่สุด ?

จากคำถามและปัญหาเหล่านี้นั้น
จากเป็นขั้นตอนการทำงานแบบเดิม การ review code จะเกิดขึ้นก็ต่อเมื่อ
นักพัฒนาทำการ code เสร็จ
จากนั้นทำการเปิด PR
และรอเพื่อร่วมงานหรือคน review มาทำการ approve ต่อไป !!

ในปัจจุบันมันไม่ได้ทำตามขั้นตอนแบบนี้แล้ว
แต่กลับเป็นการทำงานเหมือน spell checking หรือ check syntax ของ code เลย
นั่นคือการทำงานแบบ near real time หรือ fast feedback
โดย code จะถูกสร้าง review และ แก้ไขจาก Claude ไปเลย (AI Agent)
ก่อนที่จะส่งมาให้คนทำการ review อีกที
ส่งผลให้คนทำงาน ไม่ต้องมาดูปัญหาในระดับ low level อีกแล้ว
ให้ไปดูในระดับ high level แทนได้เลย
เช่นเรื่องของ business, architecture และ security เป็นต้น

ดังนั้นงานอะไรที่ automation ได้ก็ทำไป
ส่วนที่เหลือค่อยส่งมาให้คนทำหรือแก้ไขนั่นเอง
และคนในทีมก็ได้เจอปัญหาหรือความท้าทายใหม่ ๆ ในทุก ๆ วันอีกด้วย

ในการวัดผลว่าทำงานได้ดีหรือเทียบเท่าคนไหมนั้น
ใช้อัตราการ revert หรือยกเลิก PR นั้น ๆ หรือ การ comment และ รอ approve
มาใช้ในการวัดผลและตัดสินใจว่า ดีขึ้นหรือไม่ ?
ถ้าอัตราหรือเวลาเหล่านี้มันเยอะขึ้น
แสดงว่าเราแค่เปลี่ยนคนทำงานเท่านั้น ไม่ได้ปรับปรุงอะไรเลย
ความเร็วต้องมาพร้อมกับคุณภาพที่สูงด้วยเช่นกัน

สิ่งที่น่าสนใจมาก ๆ ในบทความนี้คือ The Life of Change

เริ่มตั้งแต่การแก้ไข code ในเครื่องของแต่ละคน
ไปจนถึงการส่งมอบขึ้น production
จะมีการทำงานเป็นขั้นตอนต่าง ๆ ดังนี้

• ก่อนที่จะเปิด PR ได้ ต้องทำการ verify ก่อน เช่น Claude ทำการ run test, build และ linting ให้ผ่านก่อน จากนั้นจะมี Agent อีกตัวทำการ review code ในส่วนที่เปลี่ยนแปลง ซึ่งจะทำการกำหนด rule ต่าง ๆ ไว้ในไฟล์ CLAUDE.md และ REVIEW.md
• เมื่อทำการเปิด PR มาแล้ว ในแต่ละ PR จะถูกดึงมาเข้า CI pipeline เพื่อทำการ build, packaging, linting และ test ใน platform ต่าง ๆ
• เมื่อผ่านแล้ว จะใช้ Claude code review ซึ่งเป็น Agent หลาย ๆ ตัวทำงานพร้อม ๆ กัน เพื่อหา bug และ verify หรือ vote ว่า bug ที่เจอเป็นอย่างไร รวมทั้งจัดลำดับความร้ายแรงของ bug ด้วย (/code-review)
• ต่อมาก็ทำ security review !! (/security-review)
• ทำการ approve ซึ่งมีการแบ่งกลุ่มของงานเพื่อทำการ approve ต่างกันไปอีกด้วย ทั้งไม่ต้องใช้คน หรือ ใช้คน 1 หรือ 2 คน (low -> medium -> high)
• เมื่อผ่านมาแล้วก็ทำการโยนเข้า queue เพื่อ merge ต่อไป
• เมื่อทำการ merge เสร็จแล้ว จะมีการใช้งานภายใน หรือ internal use ของพนักงานทุก ๆ คนนั่นเอง (eat your own dog food) ซึ่งเป็นคนกลุ่มแรกที่ได้ใช้งาน (จะมีการทำ feature flag ไว้ใช้เปิดปิด feature ต่าง ๆ)
• สุดท้ายก็ทำการ release ต่อไป

แสดงการทำงานดังรูป

สิ่งที่น่าสนใจคือ การปรับปรุงกระบวนการ review อย่างต่อเนื่อง

“Our code review process is constantly improving in a loop”

ตัวอย่างที่ยกมาคือ
ทุก ๆ incident หรือปัญหาบน production จะถูก eval เสมอ
โดยจะนำข้อมูลของ PR ที่ผ่านมา มาใช้ในการตัดสินใจด้วยว่า
incident เหล่านั้นจะต้องทำการแก้ไข หรือ ว่า revert ตาม PR ต่าง ๆ ไปเลย
ดังนั้นทุก ๆ incident มันคือการสร้างองค์ความรู้เพิ่มเติมอย่างต่อเนื่อง
มีขั้นตอนการทำงานดังรูป

อีกทั้งยังมีการวัดข้อมูลที่เป็น noise เช่นการแจ้งเตือน bug ที่ไม่จำเป็น
เพราะว่าจะทำให้เสียเวลาในการ review อย่างมาก
เนื่องจากการหา bug นั้นง่ายมาก ๆ แต่มันคือ bug จริง ๆ หรือไม่ ?
ตรงนี้เป็นสิ่งที่สำคัญมาก ๆ
ดังนั้นจะมีการตรวจสอบเรื่องนี้เสมอ
ยกตัวอย่าง ดูจากการ comment ของคน review ต่อ bug ต่าง ๆ ว่าเป็นอย่างไร
เช่นต้องทำการแก้ไข
เช่นมีการโต้แย้งว่าไม่ใช่ bug
เช่นบอกว่าข้ามไปได้เลย
จะช่วยลดการ review ลงไปอย่างมาก

ขั้นตอนการทำงานยังคงมีคนในเสมอ (Human in the Loop)

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

• การตัดสินใจว่าจะสร้างอะไร ทั้ง direction, taste และ scope ของงาน
• ทำการ review code ที่มีความเสี่ยงสูง ๆ เช่นเรื่องของ billing, auto update และ pipeline ของระบบ CI เป็นต้น
• ทำการ review architecture ของระบบ
• การตรวจสอบผลต่าง ๆ อย่างละเอียด ต้องระบุให้ได้ว่า การ review นั้นผิดพลาดจากอะไรบ้าง ทำการ review อย่างไร ด้วยคำสั่งหรือเครื่องมืออะไร ผลเป็นอย่างไร ถ้าไม่รู้เรื่องเหล่านี้ จำเป็นต้องกลับมาก review จริง ๆ ด้วยคน
• คนต้องรับผิดชอบต่อผลลัพธ์ที่ออกมาเสมอ ไม่ว่าใครจะเป็นคนสร้างสิ่งนั้นขึ้นมาก็ตาม

และยังมีคำแนะนำสำหรับการ change หรือการเปลี่ยนแปลงต่าง ๆ ดังนี้

• มีขนาดที่เล็ก ซึ่งทำให้ง่ายต่อการ review (เล็กอย่างไรต้องพูดคุยกัน)
• ทุก ๆ การเปลี่ยนแปลงต้องสามารถย้อนกลับ หรือ revert ได้เสมอ ได้ในไม่กี่นาที เช่นการใช้ flag หรือ feature flag นั่นเอง
• Code ที่มีความสำคัญหรือความเสี่ยงสูง จำเป้นต้องใช้คนเยอะขึ้นและมีขั้นตอนในการตรวจสอบมากยิ่งขึ้นเสมอ
• ระบบมี feedback loop ที่รวดเร็ว เพื่อทำให้แก้ไขได้อย่างรวดเร็ว และลดความเสี่ยงต่าง ๆ ของผู้ใช้ลงไป เช่น internal use (ใช้งานภายในก่อน)
• “Ownership is also shared” ตรงนี้สำคัญมาก ๆ มีช่องทางให้คนต่าง ๆ ทั้งในทีมและนอกทีม รู้ว่าแต่ละคนกำลังทำอะไร สร้างอะไร เพื่อ share knowledge และคุณภาพต่าง ๆ ของ code ในระบบงาน โดยที่ไม่ต้องมาตรวจสอบคุณภาพในช่วงท้ายที่ช้ามาก ๆ

ลองอ่านในรายละเอียดเพิ่มเติมได้ครับ
มีหลาย ๆ เรื่องที่น่าสนใจ ลองศึกษาและนำมาประยุกต์ใช้งานกันดู

Article by Somkiat Puisungnoen

To be Craftmanship