Vibe Coding ทำให้สร้าง Software ง่ายขึ้น แต่คำถามที่ตามมาไม่ใช่เรื่อง Code
ผมคิดว่า vibe coding กำลังเปลี่ยนวิธีที่เรามอง Software ไปอย่างหนึ่ง
เมื่อก่อน ถ้าผมมี Idea ว่าอยากสร้าง App สักตัว สิ่งแรกที่ต้องคิดคือ “ใครจะเขียน?”
วันนี้คำถามนั้นเปลี่ยนไปมาก
เราอาจเริ่มจากการบอก AI ว่าอยากได้อะไร แล้วให้ AI ช่วยเขียน Code สร้าง Interface แก้ Bug และ Iterate ระบบไปเรื่อย ๆ
นี่คือสิ่งที่ทำให้ Vibe Coding น่าสนใจมาก
Google อธิบาย Vibe Coding ว่าเป็นแนวทางพัฒนา Software ที่ทำให้การสร้าง App เข้าถึงคนที่มีประสบการณ์ด้าน Programming น้อยลง โดยบทบาทของมนุษย์ขยับจากการเขียน Code ทีละบรรทัดไปสู่การกำหนดสิ่งที่ต้องการและให้ AI ช่วยสร้างระบบขึ้นมา Google Cloud
ผมเองก็เจอกับตัวเอง
ตอนงานแต่ง ผมลองทำ FaceSwap App ขึ้นมาตัวหนึ่งสำหรับให้แขกใช้ในงาน
AI ช่วยผมเขียนระบบ
ช่วยทำ FaceSwap
ช่วยทำฟีเจอร์ Upscale รูปภาพ
และสิ่งที่น่าสนใจที่สุดคือ
มันสร้างได้จริง
แต่พอผมเอา App ไป Deploy คำถามที่เกิดขึ้นกลับไม่ใช่
“AI เขียน Code ได้ดีแค่ไหน?”
แต่เป็น
“แล้ว Software ตัวนี้คุ้มค่าพอที่จะเปิดให้บริการต่อหรือเปล่า?”
นี่เป็นจุดที่ทำให้ผมเริ่มมอง Vibe Coding ต่างออกไป
Vibe Coding คืออะไร และทำไมมันเปลี่ยนเกมการสร้าง Software
ก่อนอื่นต้องแยกคำว่า Vibe Coding ออกจากคำว่า AI Coding เล็กน้อย
AI Coding เป็นคำกว้าง ๆ สำหรับการใช้ AI เข้ามาช่วยในกระบวนการเขียน Software
ส่วน Vibe Coding เป็นรูปแบบการทำงานที่ให้มนุษย์อธิบาย Intent หรือสิ่งที่ต้องการ แล้วให้ AI สร้างและปรับ Code จากการสนทนาและการทดลองเป็นหลัก
Martin Fowler อธิบาย Vibe Coding ในลักษณะที่มนุษย์กำหนดสิ่งที่ต้องการ สั่ง AI สร้าง ทดลองใช้งาน แล้ว Prompt ต่อเพื่อแก้ไข โดยไม่ได้จำเป็นต้องอ่าน Code ที่ AI สร้างทุกบรรทัด martinfowler.com
ผมคิดว่านี่คือการเปลี่ยน Interface ของ Software Development
เมื่อก่อนเราต้องเรียนรู้ภาษาที่ Computer เข้าใจ
วันนี้เราเริ่มต้นจากภาษาที่มนุษย์เข้าใจก่อน
แล้วให้ AI ช่วยแปลง Intent นั้นเป็น Software
ผลคือ Barrier ของการสร้าง Prototype ลดลงมาก
คนที่ไม่ใช่ Developer ก็สามารถทดลองสร้าง Web หรือ App ได้ง่ายขึ้น
และสำหรับ Developer เอง AI ก็ช่วยลดงานที่ต้องเขียนซ้ำ ๆ หรือช่วยเร่ง Iteration ได้
นี่คือเหตุผลที่ผมไม่ได้มองว่า Vibe Coding เป็นเรื่องที่ควรกลัว
ตรงกันข้าม
ผมคิดว่ามันเป็นเครื่องมือที่ทรงพลังมากสำหรับการทดลอง
แต่ปัญหาจะเริ่มเกิดขึ้นตอนที่เราเอา Mental Model ของ “Prototype” ไปใช้กับ “Production”
เพราะสองอย่างนี้มี Economics คนละแบบ
Case จริง: ผมสร้าง FaceSwap App สำหรับงานแต่งของตัวเอง
ตอนงานแต่ง ผมอยากทำอะไรสนุก ๆ ให้แขกในงาน
เลยลองสร้าง App สำหรับทำ FaceSwap
Concept ง่ายมาก
ให้คนถ่ายหรือ Upload รูป แล้วระบบนำไปประมวลผล ก่อนจะได้ภาพที่เอาไปใช้ต่อได้
สิ่งที่ผมอยากทดลองเพิ่มคือ Upscale
เพราะถ้าได้ภาพมาแล้ว เราก็อยากให้ภาพมี Resolution ที่ดีขึ้น
ผมใช้ AI ช่วยสร้าง Software ตัวนี้
และนี่เป็นส่วนที่ผมรู้สึกว่า AI ทำให้ทุกอย่างเปลี่ยนจริง ๆ
จาก Idea → ไปเป็น Software ที่ใช้งานได้
มันเร็วมาก
ผมไม่ต้องเริ่มจากการนั่งเขียนระบบทั้งหมดด้วยตัวเอง
ไม่ต้องสร้างทุก Component ด้วยมือ
ไม่ต้องใช้เวลานานแบบ Software Project แบบเดิม
AI ช่วยผม Iterate ไปทีละส่วน
และสุดท้าย
มันทำงาน
ถ้ามองแค่ Development Phase ผมสามารถพูดได้เต็มปากว่า
AI ทำให้การสร้าง Software ง่ายขึ้นจริง
แต่เรื่องที่ผมไม่ได้คิดหนักพอในตอนแรกคือ
แล้วหลังจากสร้างเสร็จล่ะ?
ปัญหาไม่ได้อยู่ที่ Build แต่อยู่ที่ Run
หลังจาก Deploy สิ่งหนึ่งที่เปลี่ยนทันทีคือ
Software ไม่ได้เป็นแค่ Code อีกต่อไป
มันกลายเป็น Service ที่ต้องใช้ Resource เพื่อให้ทำงาน
- Server ต้องทำงาน
- Database ต้องทำงาน
- Storage ต้องเก็บข้อมูล
- API ต้องถูกเรียก
- ระบบต้องรับ Request
- ระบบต้อง Process รูป
และบาง Feature ต้องใช้ Compute สูงกว่าที่เราคิด
ใน Case ของผม จุดที่ทำให้ต้นทุนสูงกว่าที่คาดคือ Upscale
หลายคนอาจสงสัยว่า
ทำไม App เล็ก ๆ ตัวหนึ่งถึงมีต้นทุนในการ Run สูงขนาดนั้น?
คำตอบคือ App ไม่ได้แค่รับรูปแล้วส่งกลับ
ทุกครั้งที่ผู้ใช้กด Upscale ระบบต้องใช้ Resource ในการประมวลผลค่อนข้างสูง โดยเฉพาะการ Upscale ระดับ X4 หรือ X8
Library ที่ใช้สำหรับ Upscale ก็มีขนาดใหญ่
ทำให้ Server ต้องใช้ Resource ที่สูงขึ้น ทั้งในด้าน Compute และ Memory เพื่อให้ระบบประมวลผลได้
ผมลองคิดวิธีลด Cost ด้วยการโหลด Library เฉพาะตอนที่มีการเรียกใช้งาน แล้วปล่อยออกจาก Memory เมื่อประมวลผลเสร็จ
ฟังดูดีในเชิง Infrastructure
แต่ปัญหาอีกอย่างก็เกิดขึ้น
มันช้าลง
เพราะทุกครั้งที่ต้องเรียก Feature ระบบต้องใช้เวลา Load Library ขึ้นมาใหม่
สุดท้ายจึงเกิด Trade-off ที่ผมคิดว่าน่าสนใจมาก
ถ้าผมอยากให้ระบบเร็วขึ้น → ต้องใช้ Resource มากขึ้น
ถ้าผมอยากลด Resource → User ต้องรอนานขึ้น
นี่ไม่ใช่ปัญหาเรื่อง “AI เขียน Code ไม่ดี”
มันเป็นปัญหาเรื่อง Economics ของ Software
และนี่คือจุดที่ทำให้ผมตัดสินใจเก็บ Project นี้ไว้ใช้บนเครื่องตัวเอง
เพราะเมื่อเทียบ
คุณค่าที่ได้
กับ
ต้นทุนในการเปิดให้บริการ
มันยังไม่คุ้ม
Software มีต้นทุนสองช่วง และ AI เก่งมากในการลดแค่ช่วงแรก
สิ่งที่ผมเริ่มมองเห็นจากเรื่องนี้คือ Software มี Cost Structure อย่างน้อยสองช่วง
Build — ต้นทุนในการสร้าง เช่น
- คน
- Developer
- Design
- Development Time
- AI Coding Tools
- Testing
- Prototype
Run — ต้นทุนในการให้ระบบทำงานต่อ เช่น
- Hosting
- Compute
- Database
- Storage
- Bandwidth
- AI API
- GPU
- Monitoring
- Security
- Maintenance
สิ่งที่ Vibe Coding ทำได้ดีมากคือการลด Friction ของ Build
แต่ไม่ได้หมายความว่า Cost ของ Run จะหายไปด้วย
นี่คือจุดที่ผมคิดว่าคนกำลังเอา Cost สองก้อนนี้มาปนกัน
และมันทำให้เกิดประโยคที่ฟังดูถูกต้องว่า
“AI ทำให้ Software ถูกลง”
แต่ถ้าถามว่า
“ถูกลงตรงไหน?”
คำตอบอาจเป็น
ถูกลงตอนสร้าง
ไม่ใช่
ถูกลงตลอดอายุของ Software
หลัง Deploy แล้ว ต้นทุนไม่ได้หายไป แต่มันเปลี่ยนรูป
ลองนึกภาพง่าย ๆ
ตอน Build คุณอาจใช้ AI Coding Tool เดือนหนึ่งในระดับค่า Subscription ที่ค่อนข้างคาดเดาได้
แต่หลังจาก Deploy สมการเปลี่ยนทันที
เพราะต้นทุนบางส่วนเริ่มผูกกับ Usage
ตัวอย่างที่เห็นได้จากบริการจริงคือ Supabase
ปัจจุบัน Supabase มี Free Plan และ Pro เริ่มต้นที่ $25 ต่อเดือน ขณะเดียวกัน Compute ของแต่ละ Project ก็มีโครงสร้างค่าใช้จ่ายเพิ่มเติมตาม Resource ที่เลือกใช้ และมีค่าใช้จ่ายตาม Usage บางประเภท เช่น Storage และ Egress Supabase
Vercel ก็ใช้แนวทางที่มี Usage Credit รวมอยู่ใน Pro Plan และมีระบบ Spend Management สำหรับจัดการการใช้งานเพิ่มเติม Vercel
ผมไม่ได้กำลังบอกว่า Vercel หรือ Supabase แพง
ประเด็นไม่ใช่เรื่องนั้น
ประเด็นคือ
เมื่อเราเอา Software ไปเปิดให้คนใช้จริง เรากำลังเข้าสู่โลกของ Usage-based Cost
และนี่ต่างจากตอน Build อย่างสิ้นเชิง
ตอน Build
“ผมใช้ AI ช่วยสร้างได้ไหม?”
แต่ตอน Run
“User หนึ่งคนสร้างต้นทุนให้ระบบเท่าไร?”
คำถามหลังนี้ต่างหากที่สำคัญ
Feature เดียวอาจเปลี่ยน Economics ของทั้ง App
นี่เป็นสิ่งที่ผมเจอเองกับ FaceSwap App
ถ้าผมทำแค่
Upload รูป → Save รูป
ต้นทุนอาจอยู่ในระดับหนึ่ง
แต่ถ้าผมเพิ่ม
Upload → FaceSwap → Upscale X4/X8 → Process → Store → Download
Economics เปลี่ยนทันที
เพราะ Feature แต่ละตัวไม่ได้มี Cost เท่ากัน
นี่เป็นเหตุผลว่าทำไมการคิด Software จาก Feature List อย่างเดียวอาจไม่พอ
เราอาจเขียน Requirement ว่า
“มีระบบ Upscale”
แต่ในมุม Business คำถามควรเป็น
- Upscale หนึ่งครั้งใช้ Compute เท่าไร?
- ถ้ามี 1,000 ครั้งต่อวันล่ะ?
- ถ้า User เพิ่ม 10 เท่าล่ะ?
- เราต้องเปิด Server ขนาดไหน?
- หรือควรใช้ API ภายนอกแทน?
นี่คือการเปลี่ยนจาก Feature Thinking ไปสู่ Unit Economics Thinking
และผมคิดว่านี่จะกลายเป็นทักษะสำคัญมากขึ้นเรื่อย ๆ ในยุค Vibe Coding
ปัญหาใหญ่กว่าค่า Server คือเราจะสร้าง Software มากเกินไป
สิ่งที่ผมสนใจกว่านั้นคือ
AI ไม่ได้แค่ทำให้ Software ถูกลง
มันกำลังทำให้ การตัดสินใจสร้าง Software ถูกลงด้วย
เมื่อก่อนถ้าผมมี Idea ใหม่
ผมต้องคิดเยอะ
เพราะการ Build มี Cost
ต้องหา Developer
ต้องทำ Brief
ต้อง Design
ต้อง Estimate
ต้องจัด Project
ต้อง Test
ดังนั้น Idea ที่ไม่สำคัญมากอาจถูกทิ้งไปตั้งแต่ต้น
แต่วันนี้
ผมอาจพูดกับ AI ว่า
“ลองสร้างให้หน่อย”
แล้วภายในเวลาไม่นานก็มี Prototype
ตรงนี้เป็นเรื่องดีมาก
เพราะทำให้เรา Experiment ได้มากขึ้น
แต่ก็มีด้านกลับ
เมื่อ Cost ของการทดลองต่ำลง
เราจะมีแนวโน้มทดลองมากขึ้น
และเมื่อการ Deploy ง่ายขึ้น
เราก็อาจเผลอเปิด Software ที่ไม่ควรเปิดให้บริการจริง
ผมคิดว่านี่คือ Hidden Cost ที่น่าสนใจของ Vibe Coding
ไม่ใช่แค่ Server
แต่คือ ต้นทุนของการตัดสินใจผิด
เรื่องนี้เชื่อมกับสิ่งที่ผมเคยเขียนไว้ใน MVP คืออะไร? ทำไมสำคัญกว่าเดิมในยุค Vibe Coding ว่าการทดลองที่ต้นทุนถูกลงไม่ได้แปลว่าทุก Prototype ควรถูก Deploy ให้กลายเป็น Product จริง
ก่อนให้ AI สร้าง ผมจะถาม 5 คำถามใหม่
ถ้าเป็นเมื่อก่อน เราอาจถามว่า
“AI ทำ App นี้ได้ไหม?”
วันนี้ผมคิดว่าควรถามเพิ่มอีก 5 ข้อ
ถ้าไม่มี User เลย เราต้องเสียเงินเท่าไร?
นี่เป็นคำถามง่ายที่สุด
แต่หลายคนไม่ได้ถาม
เพราะตอน Build เรามองแต่ความสามารถของระบบ
ไม่ได้มอง Idle Cost
ถ้า User เพิ่ม 10 เท่า Cost จะเพิ่มกี่เท่า?
นี่สำคัญมาก
เพราะ Software บางประเภทมี Cost ที่เพิ่มตาม User แบบค่อนข้างตรงไปตรงมา
แต่บางระบบอาจมี Compute หรือ AI Processing ที่ทำให้ต้นทุนเพิ่มเร็วกว่า User
User หนึ่งคนสร้างต้นทุนอะไรให้เราบ้าง?
ไม่ใช่แค่
“User คนนี้สร้าง Revenue เท่าไร?”
แต่ต้องถามด้วยว่า
“User คนนี้ทำให้เราต้องจ่ายอะไร?”
นี่คือ Unit Economics ของ Software
ถ้าหยุด Project 6 เดือน เรายัง Maintain มันได้ไหม?
Vibe Coding ทำให้สร้างเร็ว
แต่ Software ไม่ได้มีแค่วันแรก
ถ้าอีก 6 เดือน AI Model เปลี่ยน
Library เปลี่ยน
API เปลี่ยน
Dependency พัง
หรือ Infrastructure เปลี่ยน
เรายังเข้าใจระบบที่สร้างไว้หรือไม่?
นี่เป็นเหตุผลหนึ่งที่ Martin Fowler เตือนเรื่อง Maintainability, Correctness และ Security ของ Software ที่สร้างด้วย Vibe Coding และเสนอว่าแนวทางนี้เหมาะกับ Software บางประเภทที่มีขอบเขตและอายุการใช้งานจำกัด มากกว่าจะสมมติว่า Prototype ทุกตัวควรถูกนำไปใช้เป็น Production System ทันที martinfowler.com
คุณค่าที่ Software สร้างได้ มากกว่าต้นทุนในการ Run หรือเปล่า?
นี่คือคำถามสุดท้าย
และจริง ๆ แล้วสำคัญที่สุด
เพราะสุดท้าย Software ไม่ได้มีหน้าที่ “ทำงาน”
Software มีหน้าที่ สร้าง Value
ถ้าระบบสร้าง Value 10,000 บาทต่อเดือน แต่ต้องเสีย 30,000 บาทต่อเดือนเพื่อให้มันทำงาน
มันอาจเป็น Software ที่สร้างได้ดีมาก
แต่เป็น Business ที่ไม่คุ้ม
แล้วเรื่องนี้เกี่ยวอะไรกับ Marketing?
ผมคิดว่าตรงนี้น่าสนใจกว่าเรื่อง Software เสียอีก
เพราะ Marketing กำลังเข้าสู่สถานการณ์เดียวกัน
วันนี้เราสามารถสร้างสิ่งต่าง ๆ ได้เร็วขึ้นมาก
- Campaign Microsite
- Landing Page
- Chatbot
- Interactive Content
- Quiz
- AI Tool
- Internal Marketing Tool
- Personalization System
AI ช่วยลดเวลาและ Cost ของการ Production ได้
และผมเห็นว่านี่เป็นเรื่องดี
แต่สิ่งที่ต้องระวังคือ
Production Cost ลดลง ไม่ได้แปลว่า Marketing Cost ลดลงทั้งหมด
ลองคิด Campaign หนึ่งที่เราใช้ AI สร้าง Landing Page
สร้างเร็วขึ้น
แต่ถ้า Landing Page นั้นไม่มี Traffic
เราก็ยังต้องเสียเงินกับ Traffic
ถ้ามี Chatbot
แต่ไม่มีคนใช้
เราก็ยังอาจมี Infrastructure Cost
ถ้าใช้ AI Personalization
แต่ Incremental Conversion ไม่ได้เพิ่มตาม Cost
เราก็มี Technology ที่เก่ง
แต่ Business Case อาจไม่ดี
นี่คือเหตุผลที่ผมคิดว่า Marketer ในยุค AI ต้องขยับจาก
“สร้างอะไรได้บ้าง?”
ไปเป็น
“อะไรควรถูกสร้าง?”
ถ้าทีมของคุณกำลังตัดสินใจว่าจะใช้ AI สร้างอะไรต่อในงาน Marketing ทีม Spark Factor รับวางกลยุทธ์การตลาดและ Content ให้แบรนด์ ตั้งแต่ตั้งโจทย์ไปจนถึงเลือกว่าอะไรควรสร้างจริง ไม่ใช่แค่สร้างเพราะ AI ทำให้ทำง่ายขึ้น
Vibe Coding จึงไม่ใช่แค่เรื่อง Coding แต่มันคือเรื่องของ Decision Making
ผมคิดว่าความเข้าใจผิดอย่างหนึ่งเกี่ยวกับ Vibe Coding คือการมองว่ามันเป็น Technology ใหม่สำหรับ Developer
จริง ๆ แล้วมันกำลังเปลี่ยน Cost of Experimentation
เมื่อ Cost ในการสร้าง Prototype ลดลง
จำนวน Experiment ที่เราทำได้จะเพิ่มขึ้น
และเมื่อจำนวน Experiment เพิ่มขึ้น
ความสามารถในการเลือก Experiment ที่ควรทำจะสำคัญขึ้น
นี่ทำให้บทบาทของคนไม่ได้หายไป
แต่มันเปลี่ยน
จาก
“คนที่สร้าง Software”
ไปสู่
“คนที่ตัดสินใจว่า Software ไหนควรถูกสร้าง”
AI สามารถช่วย Build ได้
แต่ไม่ได้ช่วยตัดสินใจแทนว่า
ควร Run ต่อหรือไม่
Build ได้ ≠ Run คุ้ม
สุดท้ายผมเลยกลับมาที่ Mental Model เดิม
Build ได้ ≠ Run คุ้ม
ผมคิดว่านี่เป็นประโยคที่ควรอยู่ในหัวของทุกคนที่กำลังใช้ Vibe Coding
เพราะวันนี้เรามีเครื่องมือที่ทำให้ Software Creation ง่ายมาก
Google เองอธิบายว่า Vibe Coding กำลังทำให้การสร้าง Application เข้าถึงคนที่มีพื้นฐาน Programming น้อยลง ขณะที่เครื่องมือและบริการจำนวนมากก็ทำให้การสร้างและ Deploy Software ทำได้ง่ายขึ้นกว่าเดิม Google Cloud
แต่ความง่ายในการ Build ไม่ได้ลบกฎพื้นฐานของ Software Economics
ระบบยังต้องใช้ Compute
ข้อมูลยังต้องถูกเก็บ
Request ยังต้องถูกประมวลผล
AI ยังต้องถูกเรียก
Infrastructure ยังต้องถูกดูแล
และ Software ยังต้องสร้าง Value มากกว่าต้นทุนที่มันสร้างขึ้นมา
ดังนั้นผมไม่ได้คิดว่าเราควรหยุด Vibe Coding
ตรงกันข้าม
ผมคิดว่าเราควร Vibe Coding ให้มากขึ้นด้วยซ้ำ
แต่ต้องเปลี่ยนคำถามก่อนเริ่ม
จาก
“สร้างได้ไหม?”
เป็น
“ถ้าสร้างแล้ว เราจะ Run มันอย่างไร?”
และจาก
“AI เขียนได้เร็วแค่ไหน?”
เป็น
“ถ้า User มาเพิ่มขึ้น เราจะจ่ายเพิ่มเท่าไร?”
เพราะในโลกที่การ Build กำลังถูกลงเรื่อย ๆ
สิ่งที่แพงขึ้นอาจไม่ใช่การสร้าง
แต่คือการ สร้างสิ่งที่ไม่ควร Run ตั้งแต่แรก
สรุป: AI ทำให้ Build ถูกลง แต่ไม่ได้ทำให้ Software ถูกลงทั้งหมด
จาก Case เล็ก ๆ ของ FaceSwap App ในงานแต่งของผม สิ่งที่ผมได้กลับมาไม่ใช่แค่ App หนึ่งตัว
แต่เป็น Mental Model ใหม่เกี่ยวกับ Software
เมื่อก่อนผมมองว่า
Idea → Build → Done
วันนี้ผมเริ่มมองว่า
Idea → Build → Run → Value
AI ทำให้ขั้น Build ง่ายขึ้นมาก
และนั่นเป็นเรื่องดี
เพราะมันเปิดโอกาสให้เราทดลองสิ่งที่เมื่อก่อนไม่กล้าสร้าง
แต่ทันทีที่ Software ถูก Deploy
คำถามเปลี่ยน
เราไม่ได้กำลังถามแล้วว่า
“สร้างได้หรือเปล่า?”
เรากำลังถามว่า
“มันคุ้มค่าที่จะเปิดต่อหรือเปล่า?”
สำหรับผม นี่คือบทเรียนที่สำคัญที่สุดจาก Vibe Coding
อย่าดูแค่ว่า AI ทำให้เราสร้าง Software ได้เร็วแค่ไหน
ให้ดูด้วยว่า
Software ที่ AI ช่วยเราสร้างนั้น สร้าง Value ได้มากพอที่จะจ่ายค่าการมีอยู่ของมันหรือไม่
เพราะในวันที่ทุกคน Build ได้เร็วขึ้น
ความได้เปรียบอาจไม่ได้อยู่ที่ว่า
ใครสร้างได้เร็วที่สุด
แต่อยู่ที่ว่า
ใครรู้ว่าอะไรควรสร้าง และอะไรไม่ควรเปิดให้ Run
