สั่งให้ Claude เขียนเข้ม ๆ แล้วให้ Codex คอยจับผิด — แพตเทิร์นใช้งานจริงในการแบ่งงานสองเอเจนต์บนรีโปเดียวกัน

ช่วงนี้บน X และ Discord มีโพสต์แนว "ใช้ Claude Code กับ Codex ร่วมกัน" เพิ่มขึ้นอย่างเห็นได้ชัด ทุกคนบอกว่าดี ผมเลยลองติดตั้งและใช้งานทั้งสองเครื่องมือร่วมกันบนรีโปเดียวอยู่ราวหนึ่งเดือนเพื่อดูว่าจริงไหม พอจะเริ่มนำมาใช้จริงก็พบว่ามีจุดต้องตัดสินใจเยอะมาก ทั้งควรเริ่มเซ็ตอัปจากตรงไหน แบ่งงานให้สองเครื่องมืออย่างไรไม่ให้ชนกัน และ AGENTS.md กับ CLAUDE.md ควรใส่เนื้อหาเหมือนกันได้ไหม ผมเลยสรุปออกมาเป็นคอร์ส 8 บท เพื่อช่วยให้คนที่กำลังลังเลเพราะเจอปัญหาแบบเดียวกัน ลดการลองผิดลองถูกได้

เวิร์กโฟลว์แบบสองเอเจนต์นั้นเรียบง่าย ถ้าให้โมเดลเดียวเขียนโค้ดเองแล้วรีวิวโค้ดตัวเอง มันมักจะยอมรับสมมติฐานที่ตัวเองใช้ไปแล้ว ทำให้มองไม่เห็นช่องโหว่ โครงสร้างที่ใช้จึงเป็นการวางอีกโมเดลหนึ่งไว้ข้าง ๆ ในบทบาทรีวิวเวอร์แบบ advisory (ไม่บล็อก) โดยให้ Claude Code เป็นผู้เขียนหลัก และ Codex เป็นรีวิวเวอร์แบบ advisory ประเด็นสำคัญไม่ใช่ว่าฝั่งไหนฉลาดกว่า แต่คือทั้งสองเป็นคนละโมเดล และทันทีที่ทั้งคู่กลายเป็น gate ของกันและกัน เวิร์กโฟลว์จะพัง ดังนั้นกฎใหญ่ที่สุดคือห้ามทำให้ advisory กลายเป็นตัวบล็อกโดยเด็ดขาด

เบื้องหลัง — การเปลี่ยนแปลงที่ย้อนกลับมาทบทวนระหว่างสรุป

• คำถามเมื่อก่อน: "เครื่องมือ AI สำหรับเขียนโค้ดตัวไหนดีที่สุด"
• คำถามตอนนี้: "จะแบ่งงานให้มากกว่าสองเครื่องมืออย่างไร" และ "จะใช้เครื่องมือหนึ่งเติม blind spot ของอีกเครื่องมืออย่างไร"
• เมื่อ Claude Code มี slash command และ sub-agent, Codex แยก review/exec, และมีไฟล์คอนเท็กซ์อย่าง AGENTS.md ครบแล้ว การฝังโครงสร้างแบบคู่ลงไปในเวิร์กโฟลว์จึงกลายเป็นตัวเลือกที่ใช้งานได้จริงเป็นครั้งแรก

แก่นของแพตเทิร์นโครงสร้างคู่ (ส่วนที่น่าประทับใจหลังใช้งานหนึ่งเดือน)

• advisory ไม่ใช่ตัวบล็อกเด็ดขาด — ต่อให้ Codex จับ CRITICAL ได้ การ push ก็ยังต้องผ่าน ถ้ากลายเป็นตัวบล็อกเมื่อไร งานทั้งชุดจะหยุดทันทีเมื่อโมเดลล่ม และถ้า false positive เกิดขึ้นแค่ครั้งเดียว ผู้ใช้จะเริ่มข้าม hook ทั้งก้อนด้วย --no-verify
• อย่าใส่ CLAUDE.md / AGENTS.md ด้วยเนื้อหาเดียวกัน — ฝั่งผู้เขียนต้องบอกว่า "ควรสร้างอย่างไร" ส่วนฝั่งรีวิวเวอร์ต้องบอกว่า "ควรระแวงอะไร" ถ้าซ้ำกันเกิน 80% นั่นคือสัญญาณว่าจริง ๆ แล้วคุณยังไม่ได้แบ่งบทบาท
• แยก use case ของ codex review --base กับ codex exec ให้ชัด — review อ่าน git โดยตรงจึงสะอาดกว่า แต่ใน PR ใหญ่อาจระเบิดโทเค็น ส่วน exec ใส่ diff ลงใน prompt โดยตรงจึงคุมค่าใช้จ่ายได้ แพตเทิร์นคือถ้าเปลี่ยนเกิน 100 ไฟล์จะสลับไปใช้ exec
• แนวป้องกันสองชั้นสำหรับ secret ใน pre-push hook — file pattern (.env, *.pem, secrets/) ให้ abort การ push ส่วน inline regex (sk-, ghp_, AKIA…) ให้แค่เตือน กฎ "never block" ของ advisory เป็นกฎสำหรับเอาต์พุตของโมเดล แต่การ push ไฟล์ลับคืออุบัติเหตุด้านความปลอดภัยคนละเรื่อง ดังนั้นการบล็อกจึงถูกต้อง
• ดูดซับทั้งหมดด้วย graceful degradation wrapper ตัวเดียว — ใช้ JSON envelope เป็นพื้นฐาน + --raw Markdown, timeout แบบ bash-native และ exit 0 เสมอ ฝั่งที่เรียกใช้ดูแค่ status แล้วค่อยแตกแขนงการทำงาน

สิ่งที่เปลี่ยนไปหลังใช้มาหนึ่งเดือน

• บั๊กที่ถูกจับได้ก่อน merge เพิ่มขึ้นพอสมควร หลายครั้งที่ Claude มั่นใจว่า "เขียนมาดีแล้ว" แต่ Codex กลับชี้ race condition หรือ null check ที่ตกหล่นได้
• แทบไม่ค่อยมีแล้วที่วันถัดมาจะเปิด PR กลับมาดูแล้วคิดว่า "เอ๊ะ ทำไมเขียนแบบนี้นะ" เพราะมีอีกมุมมองหนึ่งเข้ามาแทรกก่อนแล้ว ทำให้ต้นทุนการรีวิวถดถอยลดลง
• ความเหนื่อยจากการ self-review โค้ดตัวเองลดลงชัดเจน ให้ความรู้สึกเหมือนมี human reviewer เพิ่มมาอีกคน
• สำหรับการเปลี่ยนแปลงที่ย้อนกลับยากอย่าง migration SQL หรือ flow การชำระเงิน การได้ให้อีกโมเดลหนึ่งตรวจซ้ำอีกครั้งก่อนลงจริง คือความต่างทางจิตใจที่ใหญ่ที่สุด

โครงสร้างคอร์ส (8 บท, 5 พาร์ต)

• Part 1 วิธีคิดการใช้สองเอเจนต์ร่วมกัน · 1 บท — blind spot ของเอเจนต์เดี่ยว, เกณฑ์ความคุ้มค่าของต้นทุน
• Part 2 สภาพแวดล้อมและคอนเท็กซ์ · 2 บท — เบสเซ็ตอัป VSCode + Claude Code + Codex CLI, การแบ่งบทบาท AGENTS.md vs CLAUDE.md
• Part 3 แพตเทิร์นการทำรีวิวอัตโนมัติ · 3 บท — advisory wrapper script, slash command multi-phase pipeline, pre-push hook automation
• Part 4 คู่มือการปฏิบัติการ · 1 บท — ต้นไม้การเลือกเครื่องมือตามประเภทงาน, ไกด์เรื่องต้นทุนและโมเดล, ส่วน Security & Privacy
• Part 5 Boilerplate · 1 บท — ชุดเทมเพลต wrapper, hook, CLAUDE.md/AGENTS.md ที่เอาไปลงในรีโปตัวเองได้ทันที

ความคิดที่เกิดขึ้นระหว่างสรุป

• คุณค่าที่แท้จริงของโครงสร้างคู่คือ "สองเครื่องมือไม่กลายเป็น gate ของกันและกัน" เพราะถ้ายอมให้บล็อกได้แม้ครั้งเดียว งานจะหยุดทันทีเมื่อฝั่งหนึ่งล่ม และถ้า false positive เกิดสักครั้ง ผู้ใช้จะเริ่มข้าม hook ทั้งชุด จนตัว hook เองหมดความหมาย
• ยิ่งเครื่องมือ AI เร็วขึ้นเท่าไร ปัจจัยตัดสินยิ่งดูเหมือนจะไม่ใช่ "ใช้เครื่องมืออะไร" แต่เป็น "จะเอา blind spot ของหลายเครื่องมือมาซ้อนทับปิดกันอย่างไร" ซึ่งมีโครงสร้างไม่ต่างจากเหตุผลที่เราขอ code review จากคนมากกว่าหนึ่งคน
• ใครที่ทำงานด้วยเครื่องมือ AI coding แล้วรู้สึกไม่มั่นใจเวลาให้ตัวเองกลับมาตรวจโค้ดตัวเอง หรือกำลังผัดวันว่าจะติดตั้ง Claude Code กับ Codex ใช้คู่กันดีไหม น่าจะเหมาะที่จะลองอ่านครับ ถ้ามีจุดไหนที่ผมเข้าใจหรือสรุปคลาดเคลื่อน ช่วยบอกในคอมเมนต์ได้เลย ผมจะนำไปปรับแก้

[ku9cu]

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

[neostom432]

พวกเราได้ลงตัวที่การใช้ทั้งสองตัวร่วมกัน

เราใส่เฟส cross-review ของ Codex ไว้ใน flow ของ slash command (/ship ในรูปแบบ วางแผน → ลงมือทำ → ตรวจสอบ → รีวิวโดย Codex → รายงาน) และในขณะเดียวกันก็ผูกรีวิวแบบเดียวกันไว้กับ pre-push hook ด้วย หากมีแค่ slash command เวลางานเร่งด่วนคนก็จะ push ไปเลยทำให้รีวิวหลุดไป แต่ถ้ามีแค่ hook ผลลัพธ์ก็จะออกมาตอนก่อน push เท่านั้นซึ่งช้าเกินไป

ทั้งสองเส้นทางนี้ไม่ได้เรียก Codex CLI โดยตรง แต่ให้ทั้งคู่เรียก bash script ที่ครอบไว้ครั้งหนึ่ง (codex-review.sh) เหมือนกัน สคริปต์นั้นจะจัดการ timeout, การตรวจสอบการยืนยันตัวตน, การตรวจสอบ secret และรูปแบบเอาต์พุตจากจุดเดียว ทำให้ไม่ว่าจะเป็น slash command หรือ hook ฝั่งที่เรียกใช้งานก็ดูสะอาดขึ้น

หัวใจสำคัญคือจะไม่บล็อกด้วยผลรีวิวของ Codex เด็ดขาด ต่อให้ CLI ล่มหรือมี CRITICAL ออกมา ก็ยังปล่อยให้ push ผ่านเหมือนเดิมแล้วแค่แสดงผลลัพธ์เท่านั้น เพราะถ้าทำให้บล็อกแม้เพียงครั้งเดียว เมื่อ Codex จับโค้ดที่จริง ๆ ไม่มีปัญหาผิด ผู้ใช้ก็จะหันไปใช้ตัวเลือกข้าม hook (git push --no-verify) เพื่อจะ push และถ้ามันกลายเป็นความเคยชิน ต่อให้มี hook อยู่ก็แทบไม่ต่างจากไม่มีการรันเลย ดังนั้นการตรวจที่ต้องบล็อกจริง ๆ (lint·type·test, การ push ไฟล์ secret) ควรแยกเป็น gate ต่างหาก และให้ความเห็นจากโมเดลเป็นเพียงข้อมูลอ้างอิงเท่านั้น

ตัวสคริปต์, slash command และเนื้อหา hook อยู่ในแทร็ก 4~6 แชปเตอร์ตามนั้นเลย ลองใช้อ้างอิงดูได้ครับ