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

ความสามารถใหม่ของ Codex Code Review เข้ามาช่วยตรงจุดนี้ โดยอ่านกติกาการตรวจงานที่ทีมเขียนไว้เองในไฟล์ AGENTS.md ซึ่งเป็นไฟล์เดียวกับที่ใช้ให้คำแนะนำตอนสั่งงาน แล้วนำกติกานั้นมาใช้ตรวจงานจริง เมื่อติงข้อใด ก็จะบอกด้วยว่าอ้างอิงจากกติกาข้อไหน คนส่งงานจึงเห็นเหตุผล ไม่ได้เห็นแค่คำติลอยๆ

เขียนงานเร็วขึ้น คอขวดเลยย้ายไปอยู่ที่คนตรวจ

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

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

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

ของที่ตัดสินว่างานพัง ไม่ได้อยู่ในงานที่ส่งมา

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

ตัวอย่างที่ OpenAI ยกมาจากโปรเจกต์ Codex เอง ระบบส่วนหนึ่งจะส่งข้อความแจ้งเหตุการณ์ชื่อ rawResponseItem/completed ให้ระบบอื่นคอยรับ แม้ชื่อนี้ยังมีสถานะว่าอยู่ในช่วงทดลอง แต่ Codex Cloud นำไปใช้กับงานจริงแล้ว

ถ้ามีคนเปลี่ยนชื่อจาก rawResponseItem/completed เป็น rawResponseItem/done โดยแก้เพียงบรรทัดเดียวในไฟล์ codex-rs/app-server-protocol/src/protocol/common.rs โค้ดจะยังคอมไพล์ผ่าน และเมื่ออ่านเฉพาะส่วนที่แก้ก็ดูเหมือนเป็นเพียงการปรับชื่อให้เรียบร้อย จึงไม่เห็นว่ามีอะไรผิด

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

คนที่รู้ว่าห้ามเปลี่ยนชื่อนี้คือคนที่ทำงานกับระบบส่วนนั้นมานาน ความรู้นี้ไม่ได้อยู่ในไฟล์ ไม่ได้อยู่ในเทสต์ และไม่ได้อยู่ในงานที่ส่งมาให้ตรวจ แต่อยู่ในความจำของคน

เวลาตรวจงาน สิ่งที่เห็นมีเพียงโค้ดที่เปลี่ยน ผลเทสต์ และคำอธิบายที่คนส่งเขียนแนบมา ซึ่งทั้งหมดอาจดูไม่มีปัญหา ส่วนเหตุผลที่การแก้ครั้งนี้จะทำให้ระบบพังกลับไม่ได้ปรากฏอยู่บนหน้าจอนั้น

ย้ายกติกาจากหัวคน ไปไว้ในไฟล์ที่ทีมมีอยู่แล้ว

ทางแก้ที่ Codex Code Review เสนอคือเขียนความรู้นั้นลงในไฟล์ AGENTS.md ซึ่งเป็นไฟล์เดียวกับที่ทีมใช้ให้คำแนะนำ AI ตอนสั่งงานอยู่แล้ว ทีมที่มีไฟล์นี้จึงไม่ต้องสร้างไฟล์ใหม่ เพียงเพิ่มหัวข้อกติกาการตรวจงานลงในไฟล์เดิม

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

หลักการวางไฟล์ก็ชัดเจน กติกาที่ใช้กับทั้งโปรเจกต์ให้เขียนไว้ในไฟล์ AGENTS.md ในโฟลเดอร์รากของโปรเจกต์ ส่วนกติกาที่ใช้กับบริการใดบริการหนึ่งโดยเฉพาะให้เขียนไว้ในไฟล์ AGENTS.md ของโฟลเดอร์นั้น วิธีนี้ช่วยไม่ให้คำสั่งที่ไม่เกี่ยวข้องปะปนกัน และทำให้รู้ชัดว่ากติกาข้อไหนเป็นของทีมใด

ตัวอย่างที่ใช้งานจริงอยู่ใน โปรเจกต์ Codex เอง ซึ่งเก็บกติกาการตรวจงานไว้ใน AGENTS.md ครอบคลุมทั้งข้อมูลที่โมเดลมองเห็นและการแก้ไขที่ทำให้ของเดิมพัง ส่วนกติกาสำหรับชื่อ rawResponseItem/* ทั้งชุดเขียนไว้สั้นๆ ดังนี้

## Code Review Rules
### Breaking changes
Search for breaking changes in external integration surfaces:
- raw response item events (`rawResponseItem/*`), even while experimental

เมื่อมีคนเปลี่ยนชื่อนั้นจริง Codex Code Review จะแจ้งให้คงชื่อ rawResponseItem/completed ไว้ พร้อมอธิบายว่า Codex Cloud รอรับเหตุการณ์ชื่อนี้อยู่ การเปลี่ยนชื่อจะทำให้ระบบส่วนนั้นพัง แม้เหตุการณ์ดังกล่าวจะยังมีสถานะทดลองก็ตาม จากนั้นจึงเสนอทางออกสองทางตามที่ระบุไว้ใน AGENTS.md คือคงชื่อเดิมไว้ หรือเพิ่มเหตุการณ์ชื่อใหม่โดยที่ระบบเดิมยังใช้ต่อได้

จุดที่ต่างจากคำติทั่วไปอยู่ในบรรทัดสุดท้าย เพราะระบุไฟล์ที่เก็บกติกาข้อนั้นไว้ คนอ่านจึงตามไปดูได้ว่ากติกาฉบับเต็มเขียนว่าอะไร ใครเป็นคนเขียน และหากเห็นว่าล้าสมัยแล้วก็แก้ในไฟล์ได้เลย ทีม Codex เพิ่มกติกาข้อนี้เองเพื่อป้องกันไม่ให้ Codex Cloud พัง

กติกาที่ใช้ได้จริง เขียนสั้นและเจาะจง

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

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

ตัวเลขจากชุดทดสอบของ OpenAI

OpenAI ทำชุดทดสอบเพื่อวัดผลเรื่องนี้ โดยนำงานที่รู้อยู่แล้วว่าผิดกติกาข้อใดมาปนกับงานที่ดูคล้ายกันแต่ไม่ได้ทำผิดกติกา ผลคือ Codex Code Review จับข้อที่ต้องเจอได้ 98% เมื่อมีกติกาให้อ่าน เทียบกับ 58.3% เมื่อไม่มีกติกาอยู่ในโปรเจกต์

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

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

เปิดใช้แล้วลองกับงานจริงหนึ่งชิ้น

ถ้าโปรเจกต์เปิด Code Review ไว้อยู่แล้ว จุดเริ่มคือเขียนกติกาสองถึงสามข้อลงในไฟล์ AGENTS.md ที่เกี่ยวข้อง แล้วเปิดงานทั่วไปของทีมหนึ่งชิ้นขึ้นมาให้ตรวจ

จากนั้นลองทดสอบสามกรณี

• งานที่ควรโดนติงตามกติกาข้อนั้น
• งานที่หน้าตาคล้ายกันแต่ปลอดภัย ไม่ควรโดนติง
• งานที่ไม่เกี่ยวกับกติกาข้อนั้นเลย

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

เมื่อต้องการตรวจงานในเครื่องตัวเอง สามารถเรียก Codex Code Review ด้วยคำสั่ง /review ได้ทั้งในแอป คอมมานด์ไลน์ และส่วนขยายของ IDE พร้อมเลือกได้ว่าจะให้ตรวจงานส่วนใด

• เทียบกับสายหลักที่จะเอางานไปรวม
• ตรวจไฟล์ที่แก้ค้างไว้ในเครื่อง ทั้งไฟล์ที่ยังไม่ได้ commit และไฟล์ที่ Git ยังไม่ได้ติดตาม
• ตรวจ commit ใด commit หนึ่งโดยเฉพาะ
• สั่งเองว่าให้ดูเรื่องอะไรเป็นพิเศษ

ผลที่ได้จะเรียงตามความสำคัญ พร้อมบอกว่าแต่ละข้อควรทำอะไรต่อ โดย Codex Code Review จะไม่แก้ไฟล์ในเครื่องให้เอง หน้าต่างตรวจงานจะแสดงขึ้นมาเฉพาะเมื่อโปรเจกต์ที่เปิดอยู่ใช้ Git เก็บประวัติการแก้ไขเท่านั้น

ในหน้าต่างนั้นยังเขียนความเห็นกำกับทีละบรรทัดได้ Codex จะใช้ความเห็นดังกล่าวเป็นคำสั่งว่าต้องแก้ตรงไหน จึงแก้เฉพาะจุดตามคำติงได้โดยไม่ต้องรื้อทั้งไฟล์ เชื่อมต่อ GitHub แล้วติดตั้ง GitHub CLI และล็อกอินด้วย gh auth login ให้เรียบร้อย จากนั้น Codex จะดึงข้อมูลงานที่รอรวม ทั้งความเห็นของคนตรวจและไฟล์ที่เปลี่ยน มาแสดงในแอปได้เลยโดยไม่ต้องสลับหน้าจอ

ยังเป็นผู้ตรวจเพิ่ม ไม่ได้มาแทนคนตรวจ

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

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

กติกาที่อยู่ในหัวคน จะหายไปพร้อมคนคนนั้น

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

ตราบใดที่กติกายังอยู่ในความจำของคน มันก็หายไปพร้อมกับคนที่ย้ายทีม และคนใหม่ต้องเริ่มเรียนรู้จากศูนย์ทุกครั้ง เมื่อเขียนกติกาลงในไฟล์ที่อยู่กับงาน คนที่เข้ามาทำงานส่วนนั้นจะเห็นกติกาตั้งแต่ต้น ไม่ว่าจะเป็นคนใหม่ในทีมหรือ AI ที่เพิ่งเห็นโปรเจกต์นี้เป็นครั้งแรก

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

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

ที่มา:

• บทความ Custom Code Review rules for Codex จาก OpenAI Developers
• เอกสารทางการของ Codex Code Review