เมื่อใช้เอเจนต์เขียนโค้ด AI อย่างจริงจัง สิ่งแรกที่น่าตกใจไม่ใช่ความฉลาด
แต่คือคำถามนี้:
“มันเลิกงานตอนไหน?”
กลางวันค้นคว้า เย็นลงมือทำ กลางคืนทดสอบ หลังเที่ยงคืนส่งบั๊กให้ พอตื่นเช้ามาก็ยังแก้อะไรบางอย่างอยู่
ถ้าเป็นทีมมนุษย์ จะมีเรื่องกะกลางคืน OT การส่งต่องาน ความเหนื่อย และการจัดตาราง แต่ AI มีข้อจำกัดอีกแบบ: แพ็กเกจ โควตา บริบท เครื่องมือ และความเสถียรของระบบ
พอใช้งานหนักก็เกิดเรื่องแปลก:
โควตาหนึ่งสัปดาห์อาจหมดในไม่กี่วัน
ตอนแรกดูเหมือนเยอะมาก แต่ไม่นานระบบก็เหมือนกำลังบอกว่า “สัปดาห์นี้ใช้งานหนักเกินไปแล้ว”
กฎหมายแรงงานไม่ได้หายไป แค่กลับมาในชื่อ rate limit
0. ตัวชี้วัดสำคัญคือ throughput ไม่ใช่ชั่วโมงทำงาน
แทนที่จะถามว่า AI ทำงานกี่ชั่วโมง ควรถามว่า:
- ตรวจสอบได้กี่เรื่อง
- แก้ไฟล์กี่ไฟล์
- รันทดสอบกี่ครั้ง
- ปิดปัญหาได้กี่รายการ
- ผลลัพธ์กี่ชิ้นถึง production
- กี่ชิ้นติดค้าง
AI สามารถค้นหา เปรียบเทียบ แก้ไข และทดสอบซ้ำได้รวดเร็ว สิ่งสำคัญคือ งานที่มีประโยชน์ผ่าน pipeline จนจบได้เท่าไร
1. ความแปลกของการทำงาน 24 ชั่วโมงไม่ใช่กะดึกที่ถูก
ระบบมนุษย์ 24/7 ต้องมีเวร โบนัสกลางคืน การส่งต่องาน และคนสำรอง
AI ส่วนใหญ่ทำงานภายใต้ข้อจำกัดผลิตภัณฑ์เดิมทั้งกลางวันและกลางคืน
สิ่งแปลกไม่ใช่ “ทำงานกลางคืนได้”
แต่คือ หน่วยงานเดิมทำต่อได้โดยไม่ต้องเปลี่ยนกะ
ความผิดพลาดก็มาในรูปอื่น เช่น บริบทไม่พอ สมมติฐานผิด เครื่องมือล้มเหลว หรือเข้าใจสเปกไม่ครบ
2. โควตามากขึ้นทำให้ปริมาณงานมากขึ้น
เมื่อเพดานเพิ่ม ผู้ใช้ก็หยุดประหยัด
งานที่เคยทำเองก็โยนให้ AI
จาก “ช่วยค้นหน่อย” กลายเป็น:
ค้นหา→ลงมือทำ→ทดสอบ→แก้→ทดสอบใหม่→ดู log→แก้อีกรอบ
ดังนั้นโควตาที่ใหญ่ขึ้นมากก็ยังหมดได้เร็ว
นี่ไม่จำเป็นต้องแปลว่าความจุน้อย
เมื่อ supply เพิ่ม demand สำหรับงาน AI ก็เพิ่มตาม
3. ช่วงรอการรีเซ็ตกลายเป็น buffer
ระหว่างรอสามารถ:
- บันทึกปัญหาใหม่
- จัดขั้นตอนทำซ้ำ
- เก็บ log
- จัดกลุ่มสาเหตุ
- เรียงลำดับ batch ถัดไป
พอโควตากลับมา ค่อยประมวลผลเป็นชุด
จากแชตแบบ real-time กลายเป็น โรงงานแบบ batch
4. โหมดคุณภาพสูงเหมาะกับการ escalation
โหมดคุณภาพสูงอาจกินโควตาหนัก
แต่คุ้มเมื่อปัญหาตันจริง
เหมาะกับ:
- ไล่ root cause
- จัด dependency
- วางลำดับแก้ไข
- ป้องกันการเกิดซ้ำ
- ออกแบบ monitoring
สรุปคือใช้กับ การวางแผนในภาวะไม่แน่นอน
งานทั่วไปใช้โหมดปกติ ติดจริงค่อย escalate ให้โหมด premium ทำ diagnosis และ plan จากนั้นกลับไป execute ด้วยโหมดปกติ
5. AI ยิ่งเร็ว คอขวดยิ่งย้ายที่
pipeline อาจเป็น:
สร้าง → บันทึก → แปลง → เผยแพร่ → production → ตรวจสอบ
หากขั้นหนึ่งพัง ความเร็วของขั้นก่อนหน้าก็ไร้ค่า
สร้าง 100 ชิ้น แต่ขึ้น production 99 ชิ้น อีก 1 ชิ้นกลายเป็นสต็อก
ถ้าเกิดซ้ำ นี่คือ ปัญหา yield
6. “บทความไม่ขึ้น” อาจไม่ใช่ปัญหาการสร้าง
อาจพังที่:
- การบันทึก
- metadata
- localization
- publication queue
- deploy
- verification
- listing page
จึงต้องมี counter ทุกขั้น
สร้าง 120 → บันทึก 120 → เข้า queue 118 → ตรวจใน production 116
สี่ชิ้นที่หายจะมองเห็นได้
ล้มเหลวได้ แต่ห้ามหายเงียบ
7. โรงงาน AI 24 ชั่วโมงต้องมี auto recovery
ขั้นตอนที่ดี:
- ตรวจพบสิ่งที่หาย
- แยก ID
- จัดประเภท error
- retry หากปลอดภัย
- escalate เฉพาะที่พังซ้ำ
ไม่ต้องรันใหม่ทั้งหมด
ประมวลผลใหม่เฉพาะส่วนที่เสีย
8. บทบาทคนลดลงแต่ไม่หาย
คนยังต้องตัดสินใจ:
- อะไรสำคัญ
- ยอมรับ error ได้แค่ไหน
- อะไรไม่ควร automate
- เมื่อไรเลือกคุณภาพเหนือความเร็ว
- ปัญหาไหนควรใช้โหมด premium
คนเปลี่ยนจากผู้ทำงานเป็น ผู้ออกแบบสายการผลิต
9. สิ่งน่ากลัวไม่ใช่ AI ทำงานหนักเกินไป
สิ่งที่แย่กว่าคือใช้โควตาเยอะแล้วผลลัพธ์:
- หายกลางทาง
- ไม่ขึ้น production
- พังแบบมองไม่เห็น
- ทำ bug เดิมซ้ำ
- ใช้ premium กับงานจิปาถะ
หลักการคือ:
งานทั่วไปให้ถูกและเร็ว; คอขวดจริงค่อยใช้ premium; failure ต้องเห็น; สิ่งที่ retry ได้ให้กู้คืนอัตโนมัติ
เมื่อถึงจุดนี้ คุณไม่ได้แค่ใช้ AI
คุณกำลังออกแบบโรงงานที่ AI ทำงานได้
