จุดที่มันล้มเหลว

จงซื่อสัตย์เกี่ยวกับข้อจำกัด เพราะนี่คือจุดที่ vibe coding แบบไร้การกำกับดูแลทำให้คนเจ็บตัว:

• ตรรกะที่ลึกและแปลกใหม่ อัลกอริทึมที่ละเอียดอ่อน การทำงานพร้อมกัน (concurrency) หรืออะไรก็ตามที่ถูกต้อง 95% หมายถึงพัง โมเดลจะมั่นใจแม้ในตอนที่มันผิด
• การเปลี่ยนแปลงข้ามไฟล์ที่กระจัดกระจาย มันหลุดร่องรอยของบริบทในโค้ดเบสขนาดใหญ่และแอบทำสิ่งที่มันมองไม่เห็นพังไปเงียบๆ
• ความปลอดภัยและเงิน การยืนยันตัวตน (auth) การชำระเงิน สิทธิ์การเข้าถึง หรืออะไรก็ตามที่บั๊กที่ดูสมเหตุสมผลจะมีผลลัพธ์จริง ตรวจสอบสิ่งเหล่านี้ราวกับว่างานของคุณขึ้นอยู่กับมัน เพราะมันอาจจะเป็นอย่างนั้นจริงๆ
• ปัญหาที่ระบุสเปกไม่ครบ ถ้า คุณ ไม่รู้ว่าความถูกต้องหน้าตาเป็นอย่างไร AI ก็อ่านใจคุณไม่ได้ สเปกขยะเข้า โค้ดขยะออก

รูปแบบความล้มเหลวเกือบทุกครั้งเหมือนกัน คือโค้ดที่ ดูเหมือน ถูกต้อง รันผ่านเส้นทางที่ราบรื่น (happy path) และผิดพลาดในแบบที่คุณคงจับได้ถ้าอ่านมัน ทางแก้คือขั้นตอนการตรวจสอบ ไม่มีทางข้ามมันไปได้

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

                  EASY TO VERIFY      HARD TO VERIFY
                ┌──────────────────┬──────────────────┐
   COMMON       │   PURE UPSIDE    │   go slower,     │
   PATTERN      │   (scaffold,     │   demand tests   │
                │    boilerplate)  │                  │
                ├──────────────────┼──────────────────┤
   RARE /       │   read it, but   │   DANGER ZONE    │
   NOVEL        │   doable         │   (novel logic,  │
                │                  │    auth, money)  │
                └──────────────────┴──────────────────┘

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