ผมมี AI worker ชื่อ Codex ที่รับงานจากไฟล์ — อ่าน spec เต็มทุกครั้ง แล้วทำตามทีละข้อ
วันหนึ่งผมสังเกตว่างาน Codex ออกมาหยาบผิดปกติ ทำไม layout ไม่ตรง proto ทำไมสีผิด ทำไม section ที่สั่งไว้หายไป
พอไล่ดูถึงรู้ว่า — Codex ไม่เคยเปิดอ่าน brief จริงมาตั้งแต่ task ที่ 6 มีทั้งหมด 16 task ที่ทำจากข้อความสั้นๆ แค่บรรทัดเดียว ไม่ใช่ spec เต็มที่เขียนไว้
ปัญหาไม่ได้อยู่ที่ Codex ปัญหาอยู่ที่ตัวส่งงานตายเงียบไปโดยไม่มีใครรู้
Watcher คืออะไร
ก่อนจะเล่าว่าพังยังไง ต้องเข้าใจก่อนว่ามันทำงานยังไง
ผมใช้ shell script ตัวหนึ่งชื่อ codex-watcher มันทำหน้าที่เดียว — scan โฟลเดอร์ทุก 5 วินาที หาไฟล์ task ที่มีคำว่า READY_FOR_CODEX แล้วส่งไปให้ AI worker พร้อมบอกว่า “อ่านไฟล์นี้แล้วทำตาม spec ทุกข้อ”
จุดสำคัญอยู่ตรงนี้ — watcher ไม่ได้ส่งแค่ข้อความสั้นๆ มันส่ง path ของไฟล์ทั้งหมดให้ Codex เปิดอ่านเอง เหมือนส่งลิงก์เอกสารให้ ไม่ใช่พิมพ์สรุปสั้นๆ ในแชท
ทำไมต้องทำแบบนี้ เพราะ AI worker ที่ได้แค่ข้อความสั้นจะเดาส่วนที่ขาดไปเอง แล้วสิ่งที่มันเดามักจะผิด
สร้างยังไง
ตัว script ไม่ซับซ้อน — bash ล้วน ไม่มี dependency พิเศษ ใช้ 3 อย่างคือ watch directory ที่จะ scan, target ที่จะส่งงานไป (Codex), และ callback target ที่จะรายงานกลับ
ผมรันมันผ่าน pm2 ซึ่งเป็น process manager ให้มันทำงาน 24 ชั่วโมง ถ้า script crash pm2 จะ restart ให้ ถ้า server reboot pm2 จะปลุกมันกลับมา
ฟังดูปลอดภัยใช่ไหม แต่ความจริงไม่ใช่
ทำงานยังไง — flow ปกติ
flow ที่ถูกต้องเป็นแบบนี้
ขั้นแรก เขียน task file ลงในโฟลเดอร์ที่ watcher จับตาดูอยู่ แต่ใส่สถานะเป็น HOLD ก่อน ยังไม่พร้อมส่ง เพราะต้องเช็คก่อนว่า Codex ว่างหรือยัง ถ้าส่งพร้อมกันหลายตัว Codex จะรับมาทับกันแล้วงานเละ
ขั้นที่สอง เมื่อ Codex ว่าง เปลี่ยนสถานะจาก HOLD เป็น READY
ขั้นที่สาม watcher จับการเปลี่ยนแปลงนี้ภายใน 5 วินาที แล้วส่ง path ไฟล์ไปให้ Codex พร้อมข้อความว่า “อ่านไฟล์นี้ ทำตาม spec ทุกข้อ ห้ามคิดเอง”
ขั้นที่สี่ Codex เปิดอ่านไฟล์ เห็น spec เต็ม เห็น proto reference เห็น hard rules แล้วทำงาน เสร็จแล้วส่ง DONE กลับมา
flow นี้สำคัญมากเพราะ Codex เห็น spec เต็มทุกครั้ง ไม่ต้องเดาอะไร
แล้วมันพังยังไง
watcher ที่รันอยู่ใน pm2 ตายเงียบไปตั้งแต่ task ที่ 6
pm2 ตั้ง restart เป็น 0 ไม่มี alert mechanism ไม่มี health check จับ ระบบ monitoring ที่ผมมีก็ไม่ได้เช็ค pm2 process status
ตั้งแต่นั้นเป็นต้นมา ทุก task ถูก dispatch ผ่านข้อความสั้นๆ ตรงๆ แทน — แบบพิมพ์สรุปในแชทส่งไป Codex ไม่เคยเปิดอ่าน task file ต้นฉบับอีกเลย
ผลลัพธ์คือ 16 task ที่ Codex ทำจากข้อมูลไม่ครบ layout ผิดจาก proto สีไม่ตรง section หายไป แต่งานยังออกมาได้ — แค่หยาบ ดูผ่านๆ อาจไม่รู้ว่าผิด
นี่คือสิ่งที่ผมเรียกว่า silent failure — ระบบไม่ได้หยุดทำงาน มันยังทำงานอยู่ แค่คุณภาพตกลงเรื่อยๆ โดยไม่มีใครรู้ จนกว่าจะมานั่งเทียบงานทีละชิ้นกับ spec เดิม
บทเรียนที่ได้
ผมเรียนรู้ 3 เรื่องจาก incident นี้
เรื่องแรก — infrastructure ต้องอยู่กับเจ้าของ ไม่ใช่คนกลาง watcher เดิมรันอยู่ใน scope ของ COO (ผู้ประสาน) แทนที่จะอยู่กับโปรเจคที่ใช้มันจริง พอมันตาย COO ไม่รู้ เพราะไม่ใช่งานที่เขาต้องดู แก้โดยย้ายให้แต่ละโปรเจครัน watcher ของตัวเอง
เรื่องที่สอง — HOLD ก่อน READY เสมอ ครั้งหนึ่งผมเขียน task file 3 ตัวพร้อมกันด้วยสถานะ READY ตั้งแต่แรก watcher จับไปทั้ง 3 ภายใน 5 วินาที dispatch พร้อมกันหมด ทั้งที่ Codex ยังทำงานค้างอยู่ ผลคือ burst dispatch ที่ทำให้งานชนกัน ต้องเขียน HOLD ก่อนเสมอ แล้วค่อย flip ทีละตัวเมื่อ Codex ว่าง
เรื่องที่สาม — silent death คือ failure mode ที่เลวร้ายที่สุด ถ้าระบบ crash แล้วหยุดทำงานเลย อย่างน้อยผมรู้ว่ามันพัง แต่ถ้ามันตายเงียบแล้วระบบยังทำงานต่อได้แบบด้อยคุณภาพ ผมอาจไม่รู้อีกนานมากว่าอะไรผิดพลาด
ใช้ vs ไม่ใช้ — ต่างกันแค่ไหน
จาก incident จริงใน session 62 ผมเห็นชัดเจน
เมื่อ watcher ทำงานปกติ Codex เปิดอ่าน spec เต็ม เห็น proto reference เห็น hard rules เห็น design system ที่ต้องตาม งานออกมาตรง brief ไม่ต้องแก้
เมื่อ watcher ตาย Codex ได้แค่ข้อความสั้นๆ ผ่านแชท — “ทำหน้านี้ให้หน่อย แก้สีตรงนี้” ไม่มี context ว่า proto เป็นยังไง design system กำหนดอะไร rule อะไรบ้างที่ห้ามทำ ผลคือ 3 ใน 7 task ของ batch นั้นออกมาเป็น PARTIAL ต้องทำซ้ำ
สิ่งที่น่ากลัวคือ Codex ไม่เคยบอกว่า “ผมไม่มีข้อมูลพอ” มันเดาส่วนที่ขาดไปเองแล้วทำ ดูเหมือนงานสำเร็จ แต่จริงๆ แล้วไม่ตรง spec ต้องคนมานั่งตรวจเทียบถึงจะรู้
สรุป
ระบบ watcher ไม่ได้ซับซ้อน — เป็นแค่ bash script 67 บรรทัดที่ scan folder ทุก 5 วินาที แต่ผลกระทบของมันใหญ่มาก เพราะมันคือ bridge ระหว่าง “spec ที่เขียนไว้ละเอียด” กับ “สิ่งที่ AI worker เห็นจริง”
พอ bridge นี้ขาด AI ก็ทำงานจากข้อมูลไม่ครบ ไม่บอกใคร ไม่หยุด ทำต่อไปเรื่อยๆ
ถ้าผมไม่เคย code มาก่อน สิ่งที่ผมเรียนรู้จาก experiment นี้คือ — ไม่ใช่ AI ที่ทำงานผิด แต่ระบบส่งงานที่ขาดไป 1 ชิ้น ก็พอทำให้ทุกอย่างเพี้ยนได้แล้ว
silent failure เป็น failure mode ที่เลวร้ายที่สุดในระบบ AI automation เพราะทุกอย่างดูเหมือนทำงานปกติ แค่คุณภาพค่อยๆ ตกลงเงียบๆ จนวันที่มานั่งดูงานจริงถึงรู้