เมื่อไรไม่ควร Vibe Code: ข้อจำกัดและความเสี่ยง

Vibe Coding ทำให้เราได้ของที่รันได้เร็วมาก จนบางครั้งเผลอใช้มันกับทุกงาน ทั้งที่งานบางประเภทถ้าพลาดแล้วเสียหายเป็นเงิน เป็นข้อมูลของคนอื่น หรือเป็นความเชื่อใจของลูกค้า บทความนี้ไม่ได้บอกว่าห้ามใช้ AI แต่จะชี้ว่างานแบบไหนที่ "ปล่อยให้ AI เขียนแล้วดูแค่ผลลัพธ์" ไม่ได้ เพราะอะไร และมีทางเลือกอะไรที่ยังได้ความเร็วจาก AI โดยไม่ต้องรับความเสี่ยงแบบไม่รู้ตัว ท้ายบทมีตารางช่วยตัดสินใจที่นำไปใช้ในทีมได้เลย

ทำไมบางงานถึงไม่เหมาะกับ Vibe Coding

หัวใจของ Vibe Coding คือการตัดสินจากผลลัพธ์ที่มองเห็น ถ้าหน้าจอแสดงถูก ปุ่มกดได้ ก็ถือว่าผ่าน ปัญหาคือข้อผิดพลาดที่อันตรายที่สุดมักมองไม่เห็นจากหน้าจอ เช่น ปัดเศษผิดไปหนึ่งสตางค์ในบางกรณี, API ที่ไม่ตรวจสิทธิ์เมื่อเปลี่ยนเลข id, หรือ log ที่เก็บเลขบัตรประชาชนไว้เป็นข้อความธรรมดา ทั้งหมดนี้ "ทำงานได้" ในการลองครั้งแรก

เกณฑ์ง่าย ๆ ที่ใช้ได้คือถามสองข้อ

• ถ้าโค้ดนี้ผิด ใครเสียหาย และแก้คืนได้ไหม ถ้าเสียหายแค่เราและลบทิ้งได้ Vibe Coding ก็โอเค ถ้ากระทบผู้ใช้หรือแก้คืนไม่ได้ ต้องเปลี่ยนวิธี
• ข้อผิดพลาดจะถูกพบจากการลองใช้ปกติไหม ถ้าข้อผิดพลาดซ่อนอยู่ในกรณีขอบหรือในพฤติกรรมของผู้ไม่หวังดี การดูแค่ผลลัพธ์ไม่พอ

ระบบเงินและตัวเลขที่ต้องแม่นยำ

ระบบชำระเงิน, ใบแจ้งหนี้, ภาษี, เงินเดือน, คะแนนสะสม ทุกอย่างที่เป็นตัวเลขแล้วมีคนเอาไปใช้ตัดสินเรื่องเงิน ไม่ควร vibe code เหตุผลไม่ใช่เพราะ AI เขียนไม่เป็น แต่เพราะรายละเอียดเล็ก ๆ ที่ผิดนั้นดูไม่ออกจากหน้าจอ ตัวอย่างที่พบบ่อยคือการใช้ float คำนวณเงิน

// แบบที่มักได้จากการขอเร็ว ๆ: ใช้ float แล้วปัดตอนแสดงผล
$total = $price * $qty * 1.07;
echo number_format($total, 2);

// แบบที่ควรใช้: เก็บเป็นสตางค์ (int) หรือใช้ BCMath กับสตริงทศนิยม
$subtotal = bcmul('199.99', '3', 2);          // "599.97"
$vat      = bcmul($subtotal, '0.07', 4);       // ยังไม่ปัด
$vat      = bcadd($vat, '0.005', 2);           // ปัดครึ่งขึ้น 2 ตำแหน่ง (สำหรับค่าบวก)
$total    = bcadd($subtotal, $vat, 2);

แม้แต่ตัวอย่างที่สองก็ยังมีคำถามเชิงธุรกิจที่ AI ตอบแทนเราไม่ได้ เช่น ปัด VAT ต่อรายการหรือต่อบิล, ปัดแบบไหน, ราคาที่แสดงรวม VAT แล้วหรือยัง คำตอบมาจากฝ่ายบัญชีหรือข้อกำหนดของธุรกิจ ไม่ใช่จาก prompt ส่วนเรื่อง idempotency ของการชำระเงิน การกันจ่ายซ้ำ และการกระทบยอดกับ payment gateway ยิ่งต้องออกแบบและทดสอบอย่างตั้งใจ

ระบบความปลอดภัยและข้อมูลส่วนบุคคล

งานกลุ่มนี้ได้แก่ ระบบล็อกอิน, การรีเซ็ตรหัสผ่าน, การจัดการ session และ token, การกำหนดสิทธิ์, การเข้ารหัส, การอัปโหลดไฟล์ และทุกจุดที่แตะข้อมูลส่วนบุคคล

โค้ดด้านความปลอดภัยมีลักษณะเฉพาะคือ "ทำงานได้" กับ "ปลอดภัย" เป็นคนละเรื่องกัน ฟอร์มล็อกอินที่ไม่จำกัดจำนวนครั้ง, ลิงก์รีเซ็ตรหัสผ่านที่ไม่หมดอายุ, การเทียบ token ด้วย == แทน hash_equals() ล้วนใช้งานได้ปกติจนวันที่มีคนโจมตี ข้อแนะนำคือ

• ใช้ของที่ framework มีให้ก่อน เช่น Yii::$app->security->generatePasswordHash(), validatePassword(), CSRF validation และ AccessControl แทนการให้ AI เขียนกลไกใหม่
• ถ้าต้องเขียนเพิ่ม ให้ AI ช่วยร่างได้ แต่ต้องมีคนที่เข้าใจเรื่องนั้นตรวจ และเทียบกับแนวทางของ OWASP
• ห้ามแปะข้อมูลส่วนบุคคลจริงหรือ secret ลงใน prompt เพื่อให้ AI ช่วย debug ให้ใช้ข้อมูลตัวอย่างแทน

สำหรับระบบที่เก็บข้อมูลส่วนบุคคลของคนไทย ยังมีเรื่อง PDPA เข้ามาเกี่ยว เช่น การเก็บเท่าที่จำเป็น ระยะเวลาเก็บ และสิทธิ์ของเจ้าของข้อมูล ซึ่งเป็นการตัดสินใจเชิงกฎหมายและนโยบายขององค์กร (ข้อความในบทความนี้ไม่ใช่คำแนะนำทางกฎหมาย ควรปรึกษาผู้รับผิดชอบด้านกฎหมายหรือ DPO ขององค์กร) AI อาจช่วยร่างโค้ดลบหรือ mask ข้อมูลได้ แต่ไม่ควรเป็นผู้กำหนดว่าต้องเก็บอะไรนานเท่าไร

โค้ดที่ไม่มีใครในทีมเข้าใจ

ความเสี่ยงที่ถูกพูดถึงน้อยกว่าเรื่องความปลอดภัย แต่สร้างความเสียหายระยะยาวพอกัน คือโค้ดที่ไม่มีใครอธิบายได้ว่าทำงานอย่างไร เมื่อเกิดปัญหาตอนตีสองบน production คนที่ต้องแก้คือคนในทีม ไม่ใช่ AI และถ้าไม่มีใครเข้าใจโค้ด การแก้ก็จะกลายเป็นการให้ AI เดาซ้ำไปเรื่อย ๆ ซึ่งอาจสร้างปัญหาใหม่

สัญญาณเตือนว่าโค้ดเริ่มเข้าข่ายนี้:

• ตอบไม่ได้ว่าฟังก์ชันนี้มีไว้ทำไม หรือทำไมต้องมีเงื่อนไขนี้
• ไม่มีใครกล้าแก้ไฟล์บางไฟล์ เพราะไม่รู้ว่าจะกระทบอะไร
• มี dependency ที่ไม่มีใครจำได้ว่าเพิ่มเข้ามาเพราะอะไร

กฎที่ใช้ได้จริงคือ "โค้ดที่ merge ต้องมีคนอธิบายได้อย่างน้อยหนึ่งคน" ถ้าคนเปิด PR อธิบายไม่ได้ ให้ถือว่ายังไม่พร้อม review

หนี้ทางเทคนิคที่สะสมเร็วกว่าที่คิด

AI สร้างโค้ดได้เร็วกว่าที่คนอ่านทัน และโค้ดทุกบรรทัดคือภาระในการดูแล ถ้าเราใช้ Vibe Coding กับระบบที่จะอยู่หลายปี หนี้ทางเทคนิคจะสะสมในรูปแบบเหล่านี้

• โค้ดซ้ำ AI มักเขียนใหม่แทนที่จะเรียกใช้ฟังก์ชันที่มีอยู่แล้ว เพราะไม่เห็นทั้งโปรเจกต์
• ไม่มี test เมื่อโค้ดถูกตัดสินจากการลองกดดู ก็มักไม่มี test มารองรับการแก้ไขครั้งต่อไป
• โครงสร้างไม่สม่ำเสมอ ไฟล์หนึ่งใช้ ActiveRecord อีกไฟล์ใช้ SQL ดิบ อีกไฟล์ใช้ Query Builder
• dependency เกินจำเป็น เพิ่มแพ็กเกจเพื่อทำเรื่องที่ PHP ทำได้อยู่แล้ว

หนี้ที่ตั้งใจกู้ไม่ได้แย่เสมอไป เช่น ทำต้นแบบเพื่อทดสอบไอเดีย แล้วเขียนใหม่เมื่อไอเดียผ่าน ปัญหาคือการเผลอเอาต้นแบบขึ้น production แล้วต่อเติมไปเรื่อย ๆ

ทางเลือกแทน Vibe Coding และตารางตัดสินใจ

เมื่องานเข้าข่ายเสี่ยง ไม่ได้แปลว่าต้องเลิกใช้ AI แต่เปลี่ยนวิธีใช้

• AI-assisted แบบ review ทุกบรรทัด ให้ AI ร่าง เราอ่าน แก้ เขียน test และรับผิดชอบเอง
• เขียน test ก่อน กำหนดพฤติกรรมที่ถูกต้องเป็น test แล้วค่อยให้ AI เขียนโค้ดให้ผ่าน กรณีขอบเรื่องเงินควรเป็น test ที่คนเขียนเอง
• Spike แล้วทิ้ง ใช้ Vibe Coding ทำต้นแบบเพื่อเรียนรู้ แล้วเขียนเวอร์ชันจริงใหม่ด้วยความเข้าใจที่ได้
• ใช้ไลบรารีที่ผ่านการใช้งานจริง แทนการให้ AI เขียนกลไกเข้ารหัสหรือ parser เอง
• ใช้ AI เป็นผู้ตรวจ ไม่ใช่ผู้เขียน ให้ AI ช่วยหาช่องโหว่หรือกรณีที่ลืมในโค้ดที่คนเขียน

สรุป

• ใช้ Vibe Coding เมื่อความผิดพลาดกระทบแค่เราและแก้คืนได้ง่าย
• ระบบเงิน ความปลอดภัย และข้อมูลส่วนบุคคล ต้องใช้ AI แบบมีคน review และมี test ที่อิงกฎธุรกิจ
• โค้ดที่ merge ต้องมีคนในทีมอธิบายได้ ไม่อย่างนั้นจะกลายเป็นภาระตอนเกิดปัญหา
• ต้นแบบที่ vibe code ไว้ควรถูกเขียนใหม่หรือ refactor อย่างตั้งใจก่อนขึ้น production
• ทางเลือกมีหลายแบบ ตั้งแต่เขียน test ก่อน, spike แล้วทิ้ง ไปจนถึงใช้ AI เป็นผู้ตรวจ

ลองทำ

ลิสต์โมดูลในโปรเจกต์ที่คุณดูแลอยู่ 5–10 โมดูล แล้วจัดแต่ละโมดูลลงตารางตัดสินใจด้านบนว่าอยู่ระดับไหน จากนั้นเลือกหนึ่งโมดูลที่อยู่กลุ่ม "ไม่ควร" และเขียนกฎการใช้ AI สำหรับโมดูลนั้น 3 ข้อ เช่น ต้องมี test อะไรบ้าง ใครต้อง review และข้อมูลแบบไหนที่ห้ามใส่ใน prompt แล้วนำไปคุยกับทีม