แล้วจะรู้ได้ไงว่าพร้อมขึ้น Prod? — ผมให้ AI ตัวอื่น Roast โค้ดก่อนขึ้น Production · บทความ

โพสต์ก่อนบอกว่าอย่า overengineer ตอนยังไม่มีลูกค้า

ship ก่อน เรียนรู้ก่อน แก้ทีหลัง

แต่หลายคนถามกลับมาว่า — แล้วถ้ามีลูกค้าจ่ายเงินแล้วล่ะ? code ห่วยๆ แบบเดิมยังใช้ได้อยู่มั้ย?

คำตอบคือไม่

เส้นแบ่งอยู่ตรงนี้: ตอนที่ user เริ่มจ่ายเงิน blast radius ของ bug เปลี่ยนทันที

ตอนทำคนเดียวทดลอง feature — bug ก็แค่ bug แก้แล้วจบ ไม่มีใครเห็น

แต่ตอนมี user จริง ใช้ของจริง จ่ายเงินจริง — bug ตัวเดียวอาจหมายถึง data หาย เงินหาย หรือ trust หายไปเลย

สิ่งที่เคยเป็น R2 (ย้อนง่าย ทำเลย) กลายเป็น R1 (ย้อนได้แต่เจ็บ) บางอันกลายเป็น R0 (ย้อนไม่ได้)

ปัญหาคือ — คุณจะเช็คยังไงก่อน deploy?

code review ตัวเอง? มองไม่เห็นจุดบอดตัวเอง คนเขียน code กับคนหาบั๊กไม่ควรเป็นคนเดียวกัน ทุกคนรู้อยู่แล้ว

แล้วถ้า AI เขียน code ให้? ปัญหาเดิม Claude เขียน code ให้ แล้วให้ Claude review code ตัวเอง มันก็จะบอกว่า "looks good" เพราะมันเห็นตรงกับ assumption ของตัวเอง

เหมือนถามคนเขียนข้อสอบว่าข้อสอบยากมั้ย — มันจะบอกว่าง่ายทุกครั้ง

ท่าที่ผมใช้: ให้ AI ตัวอื่นที่ไม่ได้เขียน code ตรวจก่อน deploy

Codex กับ system prompt แบบ counterweight

แค่โยน code แล้วบอก "หาบั๊ก" ไม่พอ ต้อง bake system prompt เข้าไปให้มันคิดแบบ senior engineer ที่กำลังจะ sign off ก่อนขึ้น production

system prompt ประมาณนี้:

You are a senior engineer doing a final review before production deployment.
Your job is to find what will break, not what looks good.
Check: input validation, error handling, race conditions, auth boundaries, data loss scenarios.
If you find nothing wrong, look harder. Something is always wrong.

Codex ไม่รู้จัก codebase ไม่รู้ว่า Claude assume อะไรไว้ มันจะถามคำถามที่ Claude ไม่เคยถาม

ตัวอย่างจริง: feature ใหม่ Claude เขียนทั้งหมด ก่อนขึ้น prod โยนเข้า Codex กับ counterweight prompt

เจอ 3 security issues ที่ Claude ไม่เคยพูดถึง

Claude "เข้าใจ" code ชุดนั้นดีเกินไป มันรู้ว่า intent คืออะไร เลยมองข้ามจุดที่ implementation ไม่ match intent

Codex ไม่มี context นั้น มันเห็นแค่ code ตรงหน้า เลยจับได้ว่า "ตรงนี้ไม่ได้ validate input เลยนะ" "ตรงนี้ error handling หายไป" "ตรงนี้ถ้า user ส่ง request ซ้ำ จะเกิดอะไร?"

จุดบอดเดียวกันกับที่เกิดกับทีม dev จริง — คนเขียน code มองไม่เห็นบั๊กของตัวเอง เพราะ mental model ในหัวบังอยู่

สรุปคือ ถ้าคุณจ่ายค่า Opus อยู่แล้ว ใช้ model อื่นมาตรวจงาน Opus ไม่เสียหาย

Codex ใช้ได้ฟรี เครื่องมือไม่ขาด ที่ขาดคือนิสัยที่จะทำก่อน deploy

กุญแจคือ system prompt — อย่าแค่บอก "review code นี้" ต้องบอกว่า "คุณคือ senior engineer ที่กำลังจะ sign off" ให้มันมี role ที่ชัด มันจะ review คนละมุมกับ "helpful assistant" ทันที

แต่อย่าใช้ท่านี้กับทุกอย่าง

prototype? ไม่ต้อง internal tool? ไม่ต้อง ทดลอง feature ตอนยังไม่มี user? ไม่ต้อง — อันนั้นยังอยู่ในโซน vibe coding ของโพสต์เมื่อวาน

ใช้ท่านี้ตอน:

deploy ที่แตะ user data
feature ที่เกี่ยวกับเงิน
อะไรก็ตามที่ถ้าพังแล้ว user เห็น

สองโพสต์นี้คือด้านตรงข้ามของเหรียญเดียวกัน

วันก่อน = เมื่อไหร่ต้องเร็ว
วันนี้ = เมื่อไหร่ต้องช้า

รู้ว่าเมื่อไหร่ต้องเร็ว เมื่อไหร่ต้องช้า = dev ที่อยู่ได้นาน