Vibe Coding เหนื่อยแล้วใช่มั้ย · บทความ

เปิด Twitter มาเจอคนบ่นเรื่อง vibe coding ทุกวัน

"traded 1 hour of typing for 5 hours of architectural debugging"

"resulted in more outages than the previous 10 years"

"maintaining a codebase where half the logic was vibed into existence is a headache"

ฟังดูเหมือน vibe coding พัง

แต่จริงๆ มันไม่ได้พัง — คนใช้ผิด

ปัญหาไม่ใช่ตัว tool

ปัญหาคือคนเอา tool ที่ออกแบบมาให้ prototype ไปใช้ run production

Vibe coding เกิดมาเพื่อ validate idea เร็ว ไม่ได้เกิดมาเพื่อ replace software engineering

มันเหมือนเอา slide rule ไปสร้างตึก 40 ชั้น — ไม่ใช่ slide rule ผิด แต่ใช้ผิดงาน

สิ่งที่เห็นซ้ำจาก codebase ที่ "vibed into existence":

ไม่มี spec — สั่ง AI แบบ "ทำ login ให้หน่อย" ไม่บอกว่า auth flow เป็นยังไง session expire เมื่อไหร่ error case มีอะไรบ้าง
ไม่มี boundary — ทุกอย่างอยู่ file เดียว function เดียว AI มันก็ทำได้ แต่พอแก้ที่เดียว พังหมด
ไม่มี review — Accept All แล้วก็ deploy ไม่เคยอ่าน code ที่ AI เขียน
ไม่มี test — ไม่ใช่ว่าต้อง 100% coverage แต่ happy path ก็ไม่ได้ test

พอรวม 4 อย่างนี้ — ได้ codebase ที่ทำงานวันแรก แต่แก้ไม่ได้วันที่สอง

workflow ที่ใช้จริงตอนนี้ ไม่ได้พิเศษอะไร:

spec ก่อน code — บอก AI ว่า input อะไร output อะไร error case มีอะไร ก่อนเขียนแม้แต่บรรทัดเดียว

boundary ชัด — แยก module แยก responsibility ไม่ให้ AI ยัดทุกอย่างลง file เดียว

อ่านก่อน accept — ไม่ต้องอ่านทุกบรรทัด แต่ต้องเข้าใจ structure ที่ AI สร้าง

ให้ AI ตัวอื่น review — ก่อนขึ้น production ส่งให้ model อื่น roast ดูว่ามี blind spot ตรงไหน

ไม่มีอะไร magic ไม่มี framework พิเศษ แค่ทำสิ่งที่ dev ทำอยู่แล้ว — แต่ตอนนี้ต้องทำกับ AI ด้วย

คนที่บอกว่า vibe coding พัง กับคนที่บอกว่า vibe coding เปลี่ยนโลก

ทั้งสองฝั่งพูดถูก — แต่คนละ layer

Layer prototype → เปลี่ยนโลกจริง สร้าง MVP ได้ใน 1 วัน validate idea ก่อนเขียน code จริง

Layer production → ยังต้องการ engineering discipline เหมือนเดิม spec, review, test, boundary ไม่มีอะไรเปลี่ยน

ปัญหาคือคนเอา layer แรกไป deploy เป็น layer ที่สอง

vibe coding ไม่ได้เหนื่อย

ใช้ vibe coding ทำงานที่ไม่ใช่หน้าที่ของมัน ถึงเหนื่อย