Vibe coding เร็วจริง แต่ขาดอะไรไปบ้าง

ขอพูดประเด็นก่อนเลยครับ

Vibe coding ทำให้เร็วขึ้นจริง ไม่ได้โม้

แต่สิ่งที่มักหายไประหว่างทาง คือความเข้าใจว่าระบบจริงทำงานยังไง ความปลอดภัย และความรู้สึกว่า "โค้ดนี้เป็นของเรา"

ความเร็วเราเห็นทันที ส่วนสิ่งที่หายไป เราจะเห็นตอนมันพังบน production

ผมไม่ได้เขียนโพสต์นี้เพื่อต่อต้าน AI นะครับ ผมใช้ Claude Code, Cursor และ Codex ทุกวัน ทั้งงานลูกค้าและ side project บล็อกนี้เองก็มีหลายส่วนที่ทำร่วมกับ agent

แค่อยากเล่าแบบตรง ๆ ว่าได้อะไร เสียอะไร และผมขีดเส้นไว้ตรงไหน

Vibe coding ที่ผมหมายถึง

นิยามสั้น ๆ ในแบบที่ผมใช้คือ พิมพ์สิ่งที่อยากได้ คุยกับ AI ไปเรื่อย ๆ แล้วรับโค้ดที่ได้มาใช้ โดยยังไม่ได้ลงลึกเรื่อง architecture หรือ edge case

กดรัน ใช้ได้ ไปต่อ

ไม่ได้อ่าน diff ทุกบรรทัด ไม่ได้ถามว่าทำไมเลือกวิธีนี้ ไม่ได้คิดว่าถ้า input แปลก ๆ เข้ามาจะเกิดอะไรขึ้น

ซึ่งต้องยอมรับว่า หลายครั้งมันก็โอเคจริง ๆ

สิ่งที่ได้มาแบบไม่ต้องเถียง

ข้อดีมีจริงครับ และผมได้ใช้ทุกสัปดาห์

Prototype เร็วมาก ไอเดียที่เมื่อก่อนต้องใช้เวลาหนึ่งสุดสัปดาห์ ตอนนี้ได้หน้าตาคร่าว ๆ ในชั่วโมงเดียว เอาไปคุยกับลูกค้าหรือทีมได้เลย

Side project ได้เกิดจริง หลายโปรเจกต์ที่ค้างอยู่ในหัวมาเป็นปี เพราะไม่มีแรงเริ่ม ตอนนี้ได้ขึ้นมาจริงเพราะต้นทุนการเริ่มต่ำลงมาก

Friction ตอนเริ่มหายไป ไม่ต้องนั่งตั้ง boilerplate ไม่ต้องจำ config ของ library ที่ไม่ได้แตะมาหกเดือน เข้าเรื่องที่อยากทำได้ทันที

สำหรับคนที่เวลาเขียนโค้ดเหลือน้อยแบบ PM อย่างผม ข้อนี้มีค่ามาก

สิ่งที่มักหายไป

ปัญหาคือ โค้ดที่ "รันได้" กับโค้ดที่ "พร้อมขึ้น production" เป็นคนละเรื่องกัน

และ vibe coding เก่งเรื่องแรกมากกว่าเรื่องหลัง

Security

เรื่องนี้น่ากลัวที่สุด เพราะมันไม่พังให้เห็น

ตัวอย่างที่ผมเจอเองจากการให้ agent ทำงาน

• API route ที่ทำงานถูกต้องทุกอย่าง แต่ลืมเช็กว่าผู้ใช้คนนี้มีสิทธิ์เข้าถึง record นั้นหรือเปล่า แค่เปลี่ยน id ใน URL ก็ดูข้อมูลคนอื่นได้
• API key ถูกเขียนลงไฟล์ config ตรง ๆ เพื่อให้ "รันได้ก่อน" แล้วเกือบหลุดเข้า commit
• Query ที่ต่อ string จาก input ผู้ใช้ เพราะ prompt บอกแค่ว่า "ทำ search ให้หน่อย"

ไม่มีอันไหนที่ AI ทำเพราะมันแย่ มันทำตามที่เราขอ แค่เราไม่ได้ขอเรื่องที่สำคัญที่สุด

Performance

ข้อมูลทดสอบสิบแถว ทุกอย่างเร็ว

พอข้อมูลจริงหนึ่งแสนแถว หน้า list เดียวยิง query ไปหลายร้อยครั้ง เพราะดึงข้อมูลทีละ record ใน loop

ตอน vibe เราไม่ค่อยเห็นปัญหาแบบนี้ เพราะมันไม่ได้ผิด มันแค่ช้าเมื่อโตขึ้น

Observability

โค้ดที่ได้จากการ vibe มักไม่มี log ที่มีประโยชน์ ไม่มี error tracking ไม่มีวิธีรู้ว่าระบบกำลังป่วย

วันที่มีปัญหา เราจะรู้จากลูกค้า ไม่ใช่จาก dashboard

Test strategy

AI เขียน test ได้ครับ แต่ถ้าไม่ได้คิดเรื่อง test เอง มักได้ test ที่เช็กว่าโค้ดทำสิ่งที่โค้ดทำ ไม่ใช่สิ่งที่ระบบควรทำ

ผ่านหมด เขียวหมด แต่ไม่ได้ป้องกันอะไรจริง

Ownership

ข้อนี้ผมว่าสำคัญที่สุดในระยะยาว

ตอนตีสอง production มีปัญหา คนที่ต้องตื่นมาแก้คือเรา ไม่ใช่ AI

ถ้าเราไม่เคยเข้าใจว่าโค้ดตรงนั้นทำงานยังไง เราจะเริ่มจากศูนย์ในเวลาที่แย่ที่สุด

ผมเคยเปิดโค้ดที่ตัวเอง vibe ไว้เมื่อสองเดือนก่อน แล้วรู้สึกเหมือนอ่านโค้ดคนอื่น แย่กว่านั้นคือ อ่านโค้ดคนอื่นยังถามเจ้าของได้ อันนี้ถามใครไม่ได้เลย

มุมของ PM และเดฟที่ใช้ AI ทุกวัน

สิ่งที่ผมเปลี่ยนไม่ใช่การเลิกใช้ AI แต่เป็นการเปลี่ยนบทบาทตัวเอง

จากคนเขียนโค้ด มาเป็นคน review และคนที่รู้ว่าระบบมีขอบเขตตรงไหน

อ่าน diff เสมอ ไม่ต้องอ่านทุกบรรทัดของ UI แต่ทุกจุดที่แตะ auth, data และเงิน ต้องอ่านเอง

รู้ boundary ของระบบ ข้อมูลเข้ามาจากไหน ใครเรียก API นี้ได้ อะไรเชื่อได้ อะไรเชื่อไม่ได้ ถ้าตอบไม่ได้ อย่าเพิ่ง merge

บอก AI เรื่องที่สำคัญตั้งแต่แรก แทนที่จะพิมพ์ว่า "ทำหน้า search" ลองพิมพ์ว่า "ทำหน้า search ใช้ parameterized query เช็กสิทธิ์ผู้ใช้ และรองรับข้อมูลหนึ่งแสนแถว" ผลต่างกันเยอะมาก

ถามว่าทำไม เวลา agent เลือกวิธีที่ไม่คุ้น ให้ถามจนเข้าใจ ถ้าอธิบายให้ตัวเองฟังไม่ได้ แปลว่ายังไม่ใช่ของเรา

รู้ว่าอะไรห้าม vibe ข้อนี้ผมแยกไว้ในหัวข้อถัดไป

เมื่อไหร่ vibe ได้ เมื่อไหร่ห้าม

นี่คือเส้นที่ผมใช้จริงตอนนี้ครับ

Vibe ได้เต็มที่

• Spike ทดลองว่าไอเดียหรือ library นี้ใช้ได้ไหม แล้วทิ้ง
• UI draft หน้าตาคร่าว ๆ เอาไปคุยกับลูกค้าหรือทีม
• Internal tool script ช่วยงานที่ใช้คนเดียวหรือในทีมเล็ก ไม่แตะข้อมูลลูกค้า
• Side project ช่วงแรก ที่ยังไม่มีผู้ใช้จริง
• งานที่พังแล้วไม่เสียหาย ย้อนกลับง่าย ไม่มีใครเดือดร้อน

ห้าม vibe ต้องลงไปเองทุกครั้ง

• Auth และ permission ใครเข้าได้ ใครเห็นอะไร
• Payment ทุกอย่างที่เกี่ยวกับเงิน
• Data migration แก้ schema ย้ายข้อมูล ลบข้อมูล
• Production infra config ของ server, DNS, environment variables, สิทธิ์ cloud
• โค้ดที่จัดการข้อมูลส่วนตัวของผู้ใช้

ไม่ได้แปลว่าห้ามใช้ AI ในงานพวกนี้นะครับ ผมยังใช้ agent ช่วยร่างอยู่ แต่จะไม่ปล่อยผ่านจนกว่าจะเข้าใจทุกบรรทัด และมีคนอ่านซ้ำ

เช็กลิสต์ก่อน merge โค้ดที่ได้จาก AI

ถ้าจะเอาไปใช้แค่ส่วนเดียว เอาส่วนนี้ไปครับ

• อ่าน diff แล้ว อธิบายได้ว่าแต่ละส่วนทำอะไร
• ไม่มี secret หรือ API key อยู่ในโค้ดหรือ commit
• ทุก endpoint เช็กสิทธิ์ ไม่ใช่แค่เช็กว่า login แล้ว
• Input จากผู้ใช้ไม่ถูกต่อเข้า query หรือ command ตรง ๆ
• ลองคิดแล้วว่าถ้าข้อมูลเยอะขึ้นร้อยเท่า จะเกิดอะไรขึ้น
• มี log หรือ error tracking พอให้รู้ว่าพังตรงไหน
• Test เช็กพฤติกรรมที่ระบบควรทำ ไม่ใช่แค่เช็กว่าโค้ดรันผ่าน
• ถ้าพังตอนตีสอง เรารู้ว่าต้องเริ่มดูจากตรงไหน

ข้อสุดท้ายเป็นตัววัดที่ผมชอบที่สุด ถ้าตอบไม่ได้ แปลว่าโค้ดนี้ยังไม่ใช่ของเรา

ท้ายที่สุด

AI ทำให้การเขียนโค้ดถูกลงมาก แต่ไม่ได้ทำให้ความรับผิดชอบถูกลงเลย

ความเร็วเป็นของจริง ใช้ให้เต็มที่ในที่ที่ควรใช้

แต่งานที่มีผู้ใช้จริง ข้อมูลจริง เงินจริง ยังต้องการคนที่เข้าใจระบบ และพร้อมเป็นเจ้าของมันตอนที่มันพัง

ผมยังเปิด Claude Code ทุกเช้าเหมือนเดิมครับ แค่ตอนนี้รู้แล้วว่าตรงไหนปล่อยให้มัน vibe ได้ และตรงไหนต้องนั่งอ่านเองทุกบรรทัด