- เมื่อไม่นานมานี้ ได้เกิดหมวดหมู่บริการใหม่ในวงการ IT ชื่อ "Vibe Coding Cleanup" :
Vibe Coding Cleanup as a Service
- เมื่อความจริงที่ว่า โค้ดที่ AI สร้างขึ้นส่วนใหญ่ไม่เหมาะกับการใช้งานจริงในโปรดักชัน เริ่มชัดเจนขึ้น ตลาดบริการใหม่สำหรับการจัดระเบียบและแก้ไขโค้ดเหล่านี้จึงเกิดขึ้น
- หลังจากที่ Andrej Karpathy ให้นิยาม “Vibe Coding” ในช่วงต้นปี 2025 แม้นักพัฒนา 92% จะใช้เครื่องมือ AI แต่ปัญหาคุณภาพโค้ดที่ลดลงและช่องโหว่ด้านความปลอดภัยก็ปรากฏอย่างรุนแรง
- ในทางปฏิบัติ นักพัฒนาจำนวนหนึ่งกำลังทำงานเฉพาะทางเพื่อแก้ไข ความไม่สอดคล้อง ความซ้ำซ้อน และตรรกะที่ไม่สมเหตุสมผล ที่ AI สร้างขึ้น โดยมีทั้งมาร์เก็ตเพลสเฉพาะทางและบริการที่ปรึกษาเริ่มแพร่หลาย
- AI เก่งกับงานเล็ก ๆ แต่ไม่สามารถคำนึงถึงบริบทของระบบได้ จึงก่อให้เกิด หนี้เชิงโครงสร้างและปัญหาความปลอดภัย จำนวนมาก และสิ่งนี้ก็กำลังสร้างโอกาสทางอุตสาหกรรมใหม่ที่เรียกว่า "เศรษฐกิจแห่งการจัดระเบียบ"
- หากองค์กรต้องการใช้ AI coding ให้ประสบความสำเร็จ ควรให้ AI รับหน้าที่ทำต้นแบบ แต่ต้อง ลงทุนในบุคลากรผู้เชี่ยวชาญด้านสถาปัตยกรรม ความปลอดภัย และกระบวนการจัดระเบียบทดสอบ
การเกิดขึ้นและการแพร่กระจายของ Vibe Coding
- ในช่วงต้นปี 2025 Andrej Karpathy ใช้คำว่า “Vibe Coding” จนแนวคิดนี้เริ่มเป็นที่ยอมรับ
- เป็นวิธีสร้างฟังก์ชันทั้งก้อนผ่านการสนทนาด้วยภาษาธรรมชาติ
- แพร่กระจายอย่างรวดเร็วพร้อมความคาดหวังว่าจะเพิ่มผลิตภาพได้ 10 เท่า
- ตามข้อมูลของ GitHub นักพัฒนา 92% ใช้เครื่องมือ AI coding
- Copilot สร้างโค้ดหลายพันล้านบรรทัดในแต่ละเดือน
- แต่จากการวิเคราะห์ของ GitClear พบว่าเมื่อใช้โค้ดจาก AI จะมี อัตราการเปลี่ยนแปลงโค้ดสูงขึ้น 41%
- โค้ดที่ถูกย้อนกลับหรือเขียนใหม่ภายใน 2 สัปดาห์เพิ่มขึ้นอย่างมาก
- งานวิจัยของ Stanford พบว่านักพัฒนาที่ใช้ AI ช่วยเขียนโค้ด เขียนโค้ดที่ปลอดภัยน้อยลงมากขึ้น แต่กลับ มีแนวโน้มเชื่อว่าโค้ดนั้นปลอดภัยกว่า
- เครื่องมือ AI ทำให้ anti-pattern หลายรูปแบบรุนแรงขึ้น จากปัญหาอย่างการไม่ตรวจสอบอินพุต การใช้ dependency ที่ล้าสมัย และการตัดสินใจด้านการออกแบบที่คลุมเครือ
ความเป็นจริงของเศรษฐกิจแห่งการจัดระเบียบ
- ช่วงหลังมานี้ ในวงการ IT ได้เกิด พื้นที่บริการใหม่ที่เรียกว่า Vibe Coding Cleanup ขึ้นอย่างเงียบ ๆ
- ในช่วงแรกมันเริ่มจากมุกประมาณว่า "ไปแก้โค้ดเละ ๆ ที่ AI สร้างมา" แต่ตอนนี้กำลังกลายเป็นโอกาสทางธุรกิจจริง
- จากการสำรวจของ 404 Media นักพัฒนาบางคนกำลัง สร้างเส้นทางอาชีพจากการจัดระเบียบโค้ด AI เพียงอย่างเดียว
- เป็นงานรื้อแก้ความไม่สอดคล้อง ความซ้ำซ้อน และตรรกะแปลก ๆ ที่ถูกเรียกว่า “AI spaghetti”
- Ulam Labs โฆษณา Vibe Coding Cleanup เป็นบริการหลัก
- ยังมีมาร์เก็ตเพลสเฉพาะทางชื่อ VibeCodeFixers.com เกิดขึ้นด้วย
- ภายในไม่กี่สัปดาห์ มีผู้เชี่ยวชาญสมัครเข้าร่วมมากกว่า 300 คน และมีการจับคู่โปรเจกต์หลายสิบรายการ
- ลูกค้าทั่วไปคือ “สตาร์ตอัปที่ใช้ OpenAI credits ไปหลายพันดอลลาร์และได้ต้นแบบที่ทำงานได้เพียงครึ่งเดียว”
ทำไมโค้ดจาก AI จึงล้มเหลว
- ปัญหาไม่ใช่ว่า AI เขียนโค้ดแย่ในตัวมันเอง แต่คือมัน ไม่เข้าใจบริบทของระบบและเขียนโค้ดที่ถูกปรับให้เหมาะกับจุดเล็ก ๆ เท่านั้น
- ผลลัพธ์คือเกิด รูปแบบที่ไม่สอดคล้อง ตรรกะซ้ำซ้อน และช่องโหว่ด้านความปลอดภัย สะสมจนกลายเป็นหนี้ทางเทคนิค
- งานวิจัยของ Georgetown University ระบุว่า อย่างน้อย 48% ของโค้ดที่ AI สร้างมีช่องโหว่ด้านความปลอดภัย
- เช่น การเปิดเผยข้อมูลลับ การใช้ไลบรารีเก่า และ race condition ที่เกิดขึ้นภายใต้ภาระงานสูง
- สิ่งที่ร้ายแรงกว่าคือ นักพัฒนาเองอาจเข้าใจโค้ดที่ AI สร้างได้ไม่เพียงพอ จึงตรวจพบปัญหาได้ไม่ดีนัก
- Thoughtworks เรียกสิ่งนี้ว่า “หนี้ด้านความสามารถ”
- คือภาวะที่ทีมสูญเสียความสามารถในการบำรุงรักษาโค้ดและตกอยู่ในภาวะพึ่งพา AI
โอกาสทางตลาด
- แม้ตลาดบริการ cleanup จะเติบโตอย่างรวดเร็ว แต่การประเมินตัวเลขที่ชัดเจนยังทำได้ยาก
- Gartner คาดว่า ภายในปี 2028 นักพัฒนาองค์กร 75% จะใช้ AI ช่วยเขียนโค้ด
- ทำให้คาดว่าโปรเจกต์ส่วนใหญ่จะมีความต้องการด้านการจัดระเบียบตามมา
- ต่อให้มีเพียงบางส่วนที่ต้อง cleanup ก็ยังเป็นตลาดใหม่ขนาดใหญ่มากในแง่ scale
- ในเชิงเศรษฐกิจก็น่าสนใจเช่นกัน
- สตาร์ตอัปสร้าง MVP ได้อย่างรวดเร็วด้วย AI แต่หลังจากนั้นก็ต้องใช้เวลาและต้นทุนในระดับใกล้เคียงกันเพื่อเก็บกวาดและจัดระเบียบ
- ถึงอย่างนั้นก็ยังเร็วกว่าการพัฒนาแบบดั้งเดิม
- ผู้เชี่ยวชาญด้านการจัดระเบียบคิดค่าบริการ 200~400 ดอลลาร์ต่อชั่วโมง
- บริการที่ถูกทำเป็นผลิตภัณฑ์ เช่น แพ็กเกจราคาเหมาจ่าย การตรวจสอบโค้ด AI และ pipeline แบบ “Vibe-to-Production” ก็กำลังขยายตัว
- Thoughtworks ระบุว่าในโปรเจกต์ที่ใช้ AI สัดส่วนการ refactor ลดลง ขณะที่ ความผันผวนของโค้ดเพิ่มขึ้น และจำเป็นต้องมีการจัดระเบียบครั้งใหญ่ก่อนนำขึ้นโปรดักชันจริง
- บริษัทที่ปรึกษาหลายแห่งเริ่มจ้างบุคลากรเฉพาะทางเพื่อรับบท cleanup หรือ remediation สำหรับโค้ด AI
- สรุปคือ ตลาด cleanup มีอยู่จริง กำลังเติบโตอย่างรวดเร็ว และยังมีพื้นที่ที่ยังไม่ถูกสำรวจอีกมาก
ผลกระทบต่อวิศวกรรมซอฟต์แวร์
- กำลังเกิด การเปลี่ยนแปลงเชิงพื้นฐาน ของวิธีพัฒนาซอฟต์แวร์
- กระบวนการพัฒนากำลังถูกปรับใหม่เป็น ระบบแบ่งงาน ที่ AI ทำการลงมือเขียน ส่วนมนุษย์ดูแลสถาปัตยกรรม การทดสอบ และการจัดระเบียบ
- Gergely Orosz เปรียบ เครื่องมือ AI ว่าเป็น "นักพัฒนาจูเนียร์ที่กระตือรือร้นมาก" โดยเน้นว่ามันเขียนโค้ดได้เร็ว แต่ต้องมีคนคอยกำกับเสมอ
- แต่ AI จะ คงอยู่ในระดับนักพัฒนาจูเนียร์ตลอดและไม่เติบโตเป็นซีเนียร์ ดังนั้นบทบาทของผู้เชี่ยวชาญด้านการจัดระเบียบจึงยังจำเป็นเสมอ
- เส้นทางอาชีพใหม่ก็เริ่มเปิดขึ้น
- นักพัฒนาจูเนียร์ที่ฝึกทักษะด้านการจัดระเบียบ อาจไปถึงระดับเงินเดือนแบบซีเนียร์ได้ในเวลา 2 ปี
- ซีเนียร์ที่เข้าใจทั้งจุดแข็งและข้อจำกัดของ AI สามารถสร้างมูลค่าสูงได้
- องค์กรที่ประสบความสำเร็จไม่ใช่องค์กรที่ใช้ AI มากที่สุด แต่คือองค์กรที่ สร้างกระบวนการจัดระเบียบอย่างเป็นระบบ
- องค์กรที่สร้าง กระบวนการ cleanup ที่แข็งแรง ได้ จะมีความได้เปรียบในการแข่งขันในตลาด
มุมมองของ Donado Labs
- Donado Labs เน้นย้ำจาก ประสบการณ์จำนวนมากในการจัดระเบียบ vibe code ว่า AI มีประโยชน์ต่อการเร่งงาน แต่จำเป็นต้องมีขั้นตอนจัดระเบียบโดยผู้เชี่ยวชาญเสมอ
- ใช้ AI สำหรับการทำต้นแบบและงานซ้ำ ๆ ส่วน สถาปัตยกรรมหลัก ความปลอดภัย และการทดสอบให้มนุษย์รับผิดชอบ
- ด้วยบริการ “Vibe to Production” บริษัทจึง ยกระดับต้นแบบจาก AI ให้พร้อมในระดับองค์กร
- ครอบคลุมถึงการทดสอบ การเสริมความปลอดภัย และการจัดทำเอกสาร
- องค์กรที่ใช้ AI coding ได้สำเร็จไม่ใช่องค์กรที่ใช้ AI มากที่สุด แต่คือ องค์กรที่ใช้ AI อย่างชาญฉลาดและยอมลงทุนกับการจัดระเบียบ
- หัวใจสำคัญคือการทำ cleanup ควบคู่ไปก่อนที่หนี้ทางเทคนิคจะสะสม
- ต่อคำกล่าวอ้างที่ว่า AI จะมาแทนโปรแกรมเมอร์ คำถามว่า "แล้วใครจะเป็นคนเก็บกวาดโค้ดนั้น?" คือ โอกาสทางธุรกิจที่แท้จริง
4 ความคิดเห็น
ช่วงแรก ๆ ของ GPT ก็มีคนที่ไปกดราคาคนรับจ้างเขียนโค้ด โดยบอกว่าสร้างต้นแบบด้วย AI มาแล้ว เหลือแค่ทำให้เสร็จนิดหน่อยเองใช่ไหม
> ผู้เชี่ยวชาญด้านการจัดระเบียบคิดค่าบริการ 200~400 ดอลลาร์ต่อชั่วโมง
แต่พูดกันตามตรง จะมีคนทำแบบนี้จริง ๆ เหรอ?
ก่อนหน้าที่ “บริการทำความสะอาด Vibe Coding” จะโผล่มา ผมก็เคยคิดเหมือนกันว่าถ้ามีบริการที่ช่วยจัดระเบียบโค้ดเละเทะก็คงดี แต่ก็มีคนทำมันขึ้นมาจนได้ อย่างไรก็ตาม คิดว่าคงไม่มีทางที่บริษัทเราจะนำมาใช้ T_T
เมื่อก่อนงานจ้างแก้นิ้วในภาพ AI เคยฮิตอยู่พักหนึ่ง.. แต่ตอนนี้แม้แต่งานแบบนั้นก็แทบไม่มีแล้ว
คิดว่า AI cleanup เองก็น่าจะเดินตามรอยเดียวกันนะ
ความเห็นจาก Hacker News
ฉันรับงานโปรเจกต์ "จัดระเบียบโครงสร้าง" ผ่านธุรกิจมาค่อนข้างนานแล้ว
เมื่อก่อนโค้ดที่แทบใช้งานไม่ได้มักมาจากเอเจนซีรับจ้างพัฒนา แต่ทุกวันนี้ดูเหมือนต้นตอจะย้ายมาเป็น LLM แล้ว
สุดท้ายก็เหมือนปัญหาเดิม ๆ วนซ้ำ
แค่เปลี่ยนวิธีลดต้นทุนเท่านั้น
แน่นอนว่ามีเหตุผลให้เลือกทางลัด แต่ปัญหาจริงจะเกิดขึ้นเมื่อคนไม่ตระหนักลึกพอว่ามันอาจมีต้นทุนตามมา
ไม่ว่าจะมาจากผู้จัดการ พนักงาน หรือแรงงานภายนอก ผลลัพธ์ก็คล้ายกัน
ฉันยังไม่เคยโฆษณาบริการปรับปรุงโครงสร้างแพลตฟอร์ม vibe coding แยกต่างหาก แต่บางทีตอนนี้อาจถึงเวลาลองแล้วก็ได้
ตลาดซอฟต์แวร์ในออสเตรเลียเล็กมาก เลยไม่ค่อยได้ยินผลลัพธ์ของการทดลองแบบนั้น
ผมคิดว่าความต่างระหว่าง vibe coding กับงานพัฒนาจ้างนอกอยู่ที่ปริมาณโค้ดที่ถูกผลิตออกมา
ครั้งหนึ่งผมลองให้ vibe coding สร้าง helper script ง่าย ๆ ถ้าผมเขียนเองก็คงมีแค่ราว 1/3 ของโค้ดนี้ และคงไม่แตะ edge case ส่วนใหญ่เลยด้วยซ้ำ (มีทั้งการจัดการ exception ที่เกินจำเป็น และบางส่วนก็ช่วยได้จริง)
สิ่งที่ผมทำมีแค่สแกนโค้ดแล้วลบบรรทัดลบไฟล์ temp บรรทัดหนึ่ง เพราะมันอาจลบ home directory โดยไม่ตั้งใจ
แต่พอไปทำงานข้อมูลเชิงลึกทีหลัง ก็พบว่าไฟล์ temp บางส่วนหายไป และมีโค้ดลบอยู่อีกสองจุด
จริง ๆ แล้วโค้ดมันเยอะเกินกว่าที่มนุษย์จะอ่านตรวจได้ครบอย่างเป็นจริงเป็นจัง
ถึงอย่างนั้น ในแง่ความเร็วก็มีประสิทธิภาพสูงมากจริง ๆ
ต่อจากนี้ผมคงให้ AI รันทดสอบใน sandbox มากกว่าจะมานั่งอ่านโค้ดอย่างละเอียด
โดยเฉพาะกับเครื่องมือที่มี "โหมดวางแผน" อย่าง Claude Code ความแตกต่างค่อนข้างชัด
ช่วงนี้ผมใช้ Claude Code ในบริษัทบ่อยมาก โดยจะเริ่มจากคุยในโหมดวางแผนก่อนเสมอว่า "จะ implement ยังไง" แล้วค่อย ๆ ปรับแผนรายละเอียดให้เป็นแบบที่ดีผ่านการคุยไม่กี่รอบ
หลังจากนั้น AI จะบอกอย่างชัดเจนว่าจะสร้างโค้ดอะไรบ้าง (พร้อม code diff) แล้วผมอนุมัติขั้นสุดท้ายก่อนถึงจะให้สร้างโค้ดจริง
ต่างจากตอนที่เคยรีวิวโค้ดจากทีม outsourced ก่อนหน้านี้ ซึ่งเป็น spaghetti code เละเทะที่แทบทำความเข้าใจไม่ได้เลย
ผมคิดว่าอย่างน้อยการใส่คำที่เกี่ยวกับ vibe-coding ไว้ในเว็บไซต์เพื่อ SEO ก็เป็นไอเดียที่ไม่เลว
ฉันก็คิดคล้าย ๆ กัน
แต่ถ้าโปรเจกต์หนึ่งถูก vibe-coded จนกลายเป็นโค้ดเต็มไปด้วยบั๊ก แล้วฉันเข้าไปแก้บั๊กและจัดโครงสร้างให้ แบบนั้นก็จบเลยหรือ?
ฉันสงสัยว่าบริษัทที่แต่แรกก็ไม่มีความเชี่ยวชาญพอจะตั้งระบบ จะดูแลรักษาต่อไปได้ยังไง
ผมมองว่าทั้งงานจ้างนอกและการพัฒนาด้วย LLM สุดท้ายต้องใช้ความสามารถคล้ายกัน
ก็คือพื้นฐานทางวิศวกรรมที่แน่นพอ เช่น การจัดความต้องการ การสื่อสาร การบริหารผู้มีส่วนได้ส่วนเสีย การนิยามสเปก การทดสอบ และการทำเอกสาร
ผมรู้สึกแปลกนิดหน่อยที่แนวคิดเรื่อง "vibe coding" ของ Karpathy กลายเป็นกระแสในลักษณะนี้
คิดว่าน่าจะเกิดขึ้นในหมู่คนที่แทบไม่มีประสบการณ์พัฒนาจริงมากกว่า
เท่าที่ผมจำได้ vibe coding คือสภาวะประมาณว่า "คุยกับ AI ไปเรื่อย ๆ แล้วก็ปล่อยให้มันสร้างโค้ดโดยแทบไม่ตรวจผลลัพธ์เลย เชื่อแค่ฟีลและไหลไปตามนั้น" เป็นวิธีแบบไม่ค่อยหันกลับไปดูโค้ดด้วยซ้ำ
ถ้าคุณแคร์คุณภาพของซอฟต์แวร์ที่ทำอย่างจริงจังแม้แต่นิดเดียว นี่เป็นวิธีที่แย่มาก
จะใช้กับมีมบนทวิตเตอร์ การทดลองเล่น ๆ เพื่อความพอใจส่วนตัว หรือสคริปต์เล็ก ๆ ที่ใช้ในบ้านก็พอว่าไปอย่าง แต่ถ้าจะพัฒนาผลิตภัณฑ์จริงจังก็ไม่มีเหตุผลเลย
ที่มันเป็นประเด็นได้ก็เพราะชื่อเรียกเท่ ๆ จากคนดังอย่าง Karpathy ถ้าเป็นคนอื่นพูดก็คงเงียบหายไป
ก่อนยุค AI นักพัฒนาจูเนียร์หรือนักพัฒนาที่ประสบการณ์ไม่มากก็เขียนโค้ดแบบนี้กันอยู่แล้ว
คือคัดลอกแปะมาจากที่ไหนสักแห่ง แค่ให้มันรันได้ แล้วถ้ามีบั๊กประหลาดหรือ core dump ก็สลับลำดับ source code ไปมาให้มันหายอย่างหวุดหวิด
สไตล์แบบนี้ในบริษัทอย่างน้อยก็อาจโดนเตือน ถูกจับเข้าแผนปรับปรุงผลงาน หรือหนักกว่านั้นก็อาจโดนให้ออก
คนที่ไม่ใช่มืออาชีพจำนวนมากมักไม่ได้ผลลัพธ์ที่ดีจากการสื่อสารกับวิศวกรซอฟต์แวร์
vibe coding ที่เกิดขึ้นจึงเป็นเหมือนการสะท้อนว่าเราส่งมอบซอฟต์แวร์แบบไหนกันมาตลอด
จริงอยู่ว่าคุณภาพซอฟต์แวร์ของสตาร์ตอัปที่ผมรู้จักซึ่งใช้ vibe coded นั้นเละเทะ แต่ถ้ามันทำงานตามที่พวกเขาต้องการได้ คุณภาพก็ยังไม่ใช่เรื่องสำคัญในช่วงนี้
ตราบใดที่คุณภาพซอฟต์แวร์ยังไม่สร้าง "ผลกระทบจริง" ต่อธุรกิจ พวกเขาก็คงไม่อยากรับความเสี่ยงจากการจ้างนักพัฒนามาทำให้ไอเดียของตัวเองเพี้ยนไป
สุดท้ายแล้ว ถึงมันจะห่วย แต่การได้ของที่ตัวเองต้องการใช้ได้ทันที ก็ยังดีกว่าซอฟต์แวร์สมบูรณ์แบบที่ไม่ใช่สิ่งที่ตัวเองต้องการ
ชอบหรือไม่ก็ตาม vibe coding คงไม่หายไปไหนในอนาคต
ส่วนตัวผมก็ไม่ได้เห็นด้วยกับแนวคิดนี้เท่าไร แต่ในองค์กรผมก็มักพูดกับเพื่อนร่วมงานว่า "อันนี้ทำแบบ vibe coded มา"
สำหรับพวกเรา มันหมายถึงประมาณว่า "โค้ดส่วนใหญ่ถูก generate ด้วย AI"
แต่ถึงอย่างนั้นก็ไม่มีทางเอาโค้ดแบบนี้ขึ้น production โดยไม่รีวิวเด็ดขาด
ก็แค่ใช้ในเชิงทดลองเบา ๆ ประมาณว่า 'ลองปั้นแอปเจ๋ง ๆ ด้วย vibe coding ดู'
ดูเหมือนว่า Karpathy ตั้งใจพูดถึง vibe coding ในฐานะ "การทดลองที่เป็นไปได้" ที่ลองเล่นดูได้และน่าสนุกที่จะดูว่ามันไปได้ไกลแค่ไหน
ผมไม่คิดว่าเขาตั้งใจแนะนำให้บริษัทสร้างผลิตภัณฑ์ด้วย vibe coding ล้วน ๆ
ผู้คนตีความบริบทของคำนี้กันตามใจตัวเองมากเกินไป
จริง ๆ Karpathy ก็อธิบายความหมายที่ตัวเองตั้งใจไว้ในวิดีโอ YouTube ด้วย
บทความที่เกี่ยวข้อง
YouTube ของ Karpathy: Software Is Changing (Again)
ผมคิดว่าความเข้าใจผิดยิ่งขยายใหญ่เพราะคนอยากเชื่อว่างานยาก ๆ จะทำได้ง่ายขึ้นแล้ว
เดิมทีผมก็ยังคิดว่าทวีตนั้นเป็นแค่เรื่องขำ ๆ หรือการสื่ออิสระแบบ "YOLO coding" มากกว่า ไม่ได้เป็นการแนะนำให้ใช้เป็นกระบวนการทำงานจริง
ก็แค่เขียนถ่ายทอดความรู้สึกโล่งแบบขำ ๆ ในตอนนั้นเท่านั้น
ตอนนี้ vibe coding แทบจะกลายเป็นคำที่ใช้ดูแคลนหรือประชดการช่วยเขียนโค้ดด้วย AI ทุกแบบไปแล้ว
ไม่ว่าเครื่องมือไหนก็ใช้ให้ดีก็ได้ ใช้ให้แย่ก็ได้ แต่ช่วงนี้มีมแนว "vibe coding มันโง่แค่ไหน" ได้คะแนนนิยมในออนไลน์เร็วมาก
เริ่มน่าเบื่อแล้ว
ประเด็นหลักของบทความคือคำกล่าวที่ว่า "สตาร์ตอัปใช้ vibe coding ทำ MVP ได้เร็วขึ้นหลายสัปดาห์ และสุดท้ายถึงต้องใช้เวลาและต้นทุนพอ ๆ กันมาทำความสะอาดทีหลัง ก็ยังเร็วกว่าการพัฒนาแบบดั้งเดิมอยู่ดี"
ผมสงสัยว่าจริงไหม
จากที่ผมเห็น ถ้านักพัฒนาเป็นคนทำเองแต่ใช้ AI ช่วยด้วย ความต่างด้านความเร็วอาจไม่มากนัก
โดยเฉพาะถ้ารู้อยู่แล้วว่า MVP หรือ prototype จะถูกเอาขึ้น production ต่อทันที การวางสถาปัตยกรรมให้ดีตั้งแต่แรกน่าจะคุ้มกว่าในระยะยาว
แต่คนฝั่งผลิตภัณฑ์และผู้บริหารส่วนใหญ่มักมองว่าเวลานี้เป็นความสูญเปล่า
ข้อดีจริงของ vibe coding คือทีมผลิตภัณฑ์สามารถลองสร้างสิ่งที่ต้องการเองได้ทันทีโดยไม่ต้องอธิบายให้นักพัฒนาฟัง
บางทีเครื่องมือผลิตภัณฑ์แบบ vibe coding ที่ช่วยให้สเปกและ prototype ชัดเจนขึ้น อาจมีตลาดมากกว่าการทำตัวโค้ดเสียอีก
เครื่องมือแบบนี้อาจให้สเปกที่ดีกว่าแก่นักพัฒนา และเปิดโอกาสให้ฝั่งธุรกิจมีส่วนร่วมและมีอำนาจนำมากขึ้นด้วย
สำหรับสตาร์ตอัป การออกสู่ตลาดสำคัญมากจนถึงขั้นที่ถึงแม้โดยรวมจะใช้เวลาและเงินมากกว่า ก็ยังสมเหตุสมผลที่จะยอมรับ technical debt เพื่อแลกกับการออกตัวได้เร็วกว่า
เพราะงั้นผู้คนจึงสะสม technical debt กัน
ตอนเริ่มต้น Twitter ก็เป็นเว็บแอปบน Ruby on Rails และทุกครั้งที่ Justin Bieber ทวีต เซิร์ฟเวอร์ก็มักล่มจน fail-whale โผล่มา
แต่พอเติบโตขึ้น สุดท้ายก็จ้างผู้เชี่ยวชาญมาสร้างใหม่ให้เป็นโครงสร้างที่แข็งแรงและขยายได้ดีกว่าอย่างจริงจัง
ผมว่าใช้กับระดับ prototype มากกว่า MVP น่าจะเหมาะกว่า
ถ้าองค์กรหรือบุคคลไม่มีวินัยพอที่จะไม่เอา prototype ขึ้น prod ก็ควรหลีกเลี่ยง vibe coding
ทุกคนน่าจะรู้ดีว่าการอธิบายให้ผู้บริหารบริษัทเข้าใจว่า "โค้ดเจ๋ง ๆ ที่ใช้อยู่ตอนนี้ข้างในเละจนต้องรื้อใหม่หมด" มันยากแค่ไหน
ในกรณีแบบนี้ เครื่องมือ no-code กลับปลอดภัยกว่ามาก
ความจริงคือ MVP หรือ prototype ส่วนใหญ่มักถูกดันขึ้น production ในไม่ช้า
ผมจำได้ว่ามีคนพูดไว้ว่า "ถ้าโค้ด MVP ไม่สกปรกจนแทบปวดใจ แสดงว่าคุณใช้เวลากับคุณภาพโค้ดมากเกินไป"
สุดท้ายโค้ดเฉพาะกิจพวกนี้ก็กลายเป็นแกนหลักของบริษัท
บริการที่เข้ามาทำแค่ปรับโครงสร้างแบบนี้อาจเรียกว่า "C-Suite cleanup as a Service" ก็ได้ แต่ถ้าโฆษณาแบบนั้นคงไม่มีใครจ้าง
พออ่านบทความก็รู้สึกชัดเลยว่าเป็นงานเขียนของ Claude แม้ไม่มี em-dash ก็ตาม
แน่นอนว่า OP คงใส่ทั้งความคิดและข้อมูลของตัวเองลงในพรอมป์ต์ แต่สำนวนและน้ำเสียงบางช่วงมันเหมือนสิ่งที่ LLM ชอบเขียนมากจนอ่านแล้วฝืดนิด ๆ
ผมเริ่มคิดว่างานเขียนสไตล์นี้อาจกลายเป็น "ภาษาสำนวนแบบ LLM" ที่ดูล้าสมัยในอนาคตก็ได้
ดูเหมือนว่าเดี๋ยวนี้บริการ vibe-writing cleanup as a service จะมาแรงแทนแล้ว
ผมใช้ em-dash บ่อยมากมาตั้งนานแล้ว แต่ตอนนี้เหมือนจะถึงยุคที่ต้องพยายามลดมันลงแล้ว
Microsoft Word จะเปลี่ยน hyphen เป็น em-dash ให้อัตโนมัติ
ผมมองว่า vibe coding คล้ายกับการทำงานประปาเองแบบ DIY
ลองทำเองแล้วถ้าน้ำแตกท่วมห้องน้ำ สุดท้ายก็ต้องเรียกช่างประปาฉุกเฉินมาจ่ายแพงอยู่ดี
ระหว่างนั้นคุณก็จะได้เรียนรู้มากขึ้นสำหรับครั้งหน้า
มองแบบนั้นก็ได้ แต่ช่างประปามืออาชีพเองก็ใช้เครื่องมือที่ช่วยงาน DIY ได้เก่งเหมือนกัน
ความต่างคือผู้เชี่ยวชาญรู้ว่าควรใช้มันเมื่อไรและแค่ไหน
ผมกลับรู้สึกว่ามันหนักกว่านั้นอีก
งานประปาอย่างน้อยคุณยังมองเห็นว่าเขากำลังทำอะไรอยู่ แต่กับ vibe code วันหนึ่งอยู่ ๆ อะไรบางอย่างก็หยุดทำงาน แล้วคุณไม่รู้ด้วยซ้ำว่าทำไม
ใน YouTube คุณยังเห็นช่างประปา DIY จำนวนมากที่ทำงานละเอียดกว่ามืออาชีพบางคนเสียอีก
มันน่าจะขึ้นอยู่กับว่า vibe coder จะได้เรียนรู้อะไรจริงจากประสบการณ์พวกนี้หรือเปล่า
คงต้องใช้เวลาดูกัน
ผมรู้สึกว่าอุปมานี้เหมาะมาก
เหมือนนายหน้าอสังหาริมทรัพย์ที่โดนกดดันจนต้องรีบทำงานประปาเองเพื่อขายบ้าน ผู้ก่อตั้งสตาร์ตอัปก็รีบเดโมอะไรสักอย่างเพื่อดึงความสนใจจากนักลงทุนและลูกค้า แล้วค่อยเรียกผู้เชี่ยวชาญจริงมาทำความสะอาดทีหลัง
ถ้าโชคดีก็อาจเลี่ยงหายนะครั้งใหญ่ได้ก่อนหน้านั้น
ผมแปลกใจที่รู้ว่าในวงการมีคำว่า Janitor Engineer อยู่แล้ว
อีกอย่าง ลิงก์ในบทความหลัง "Why AI code fails at scale" ดันเสียทั้งหมด ซึ่งยิ่งแปลกเพราะเป็นบทความใหม่ไม่นานนี้เอง
ขออย่าให้ใครรับไปในเชิงลบก็แล้วกัน
หลังจาก vibe coding กลายเป็นกระแส ผมเองก็มีแผนเกษียณแบบกึ่งล้อเล่นว่าจะไปเป็นที่ปรึกษา "all-organic-code" คอยคลี่และจัดระเบียบก้อนโค้ดที่ AI สร้างไว้อย่างมั่ว ๆ
สิ่งที่หายากจริง ๆ กลับเป็นโปรเจกต์ใหม่เอี่ยม (greenfield)
vibe coding กำลังบั่นทอนการทำเอกสารและความชัดเจนของสถาปัตยกรรมอย่างรวดเร็ว
บริษัทมองแค่ปริมาณ token ของโค้ดที่สร้างและความเร็วของ prototype เป็นตัวชี้วัดสำคัญ แล้วมองข้ามต้นทุนแฝงด้านการบำรุงรักษาและการ cleanup
ตอนนี้ทักษะที่แท้จริงไม่ใช่การสร้าง แต่เป็นการ cleanup
ความสามารถจริงคือการชี้นำให้ดีตั้งแต่ต้นเพื่อให้ได้ซอฟต์แวร์ที่ถูกต้อง
บางคนมอง Claude Code แล้วคิดว่า "นี่แหละเทคโนโลยีล่าสุด" แต่ถ้าจะทำให้ถูกต้องจริง ต้องเข้าไปมีส่วนร่วมมากกว่านั้นมาก
จริง ๆ แล้วมันไม่ได้ต่างจากวิศวกรรมแบบเดิมมากนัก
แก่นสำคัญคือทำต้นทุนให้ต่ำและตอบโจทย์ความต้องการ
ถ้าไม่ได้ระบุเรื่องการดูแลรักษาง่ายไว้อย่างชัดเจน คุณก็จะได้ผลลัพธ์ตามที่ตั้งใจไว้แต่แรกนั่นแหละ(?)
ทำไมถึงมองว่านี่คือความตายของการทำเอกสาร?
ก็สามารถเขียนเอกสารก่อนตั้งแต่แรก แล้วค่อยตรวจว่าหลังจากนั้นโค้ดสอดคล้องกับเอกสารหรือไม่ระหว่างพัฒนาได้
หรือจะให้โค้ดสร้างเอกสารออกมา แล้วค่อยรีวิวเองว่ามันเหมาะสมหรือไม่ก็ได้
บริษัทของเราทำงานกู้ระบบฉุกเฉินให้ลูกค้ามาหลายสิบปีแล้ว (เช่น ระบบล่มที่ทำให้เกิดความเสียหายทางการเงินร้ายแรง และลูกค้าแก้เองไม่ได้)
ในช่วงไม่กี่ปีที่ผ่านมา กรณีแบบนี้เพิ่มขึ้นค่อนข้างเร็วมาก
vibe code คล้าย legacy code ในหลายด้าน
คนไม่มั่นใจในโค้ดเลยไม่กล้าแก้ และทั้งคุณภาพภายในกับภายนอกก็ต่ำ
แต่ก็มีจุดต่างอยู่
ปริมาณโค้ดเมื่อเทียบกับอายุมันต่ำ แรงกดดันด้านกำหนดเวลาสูง และความคาดหวังก็ถูกเป่าจนเกินจริง
สิ่งที่คุ้มค่าที่สุดคือย้ายข้อผิดพลาดให้ไปเกิดก่อนช่วง runtime ให้ได้มากที่สุด ไม่ว่าจะในขั้น design หรือก่อน compile time
ปัญหาคือ AI ทำให้ทุกคนพุ่งไปถึง runtime เร็วเกินไป
เผื่อใครสนใจ บทความ "Vibe code is legacy code (val.town)" น่าอ่าน
โพสต์ HN ที่เกี่ยวข้อง
legacy code ก็ไม่ได้แปลว่าแย่เสมอไป
ส่วนมากมันแค่ซับซ้อนหรือมีเอกสารไม่พอ และสะสมแพตช์แก้ปัญหาเชิงปฏิบัติการเล็กใหญ่ไว้เป็นเวลานาน
หลายปัญหาในงานจริง (เช่น ความต้องการใหม่) ถูกสะท้อนอยู่ในนั้น จนทำให้มันยังรันระบบจริงได้ดี
ปัญหาเกิดตอนที่คนซึ่งคุ้นกับ codebase นี้หายไป หรือแม้แต่คนที่รู้ภาษาหรือเครื่องมือที่ใช้ในตอนนั้นก็ไม่มีแล้ว
ผมสงสัยว่า vibe coding ใช้กับภาษา strong-typed ได้มากแค่ไหน
ผมเห็นด้วยว่าเราสามารถปฏิบัติต่อโค้ดที่ทำแบบ vibe เหมือน legacy code ได้
แต่ก็สงสัยว่าผู้คนจะลังเลไม่กล้าแก้ vibe code มากขนาดเดียวกันจริงไหม
ผมเริ่มคิดว่าในอนาคตการ generate โค้ดด้วย LLM อาจหายไปก็ได้
บทความมักตั้งสมมติฐานว่าโค้ดจาก LLM จะถูกสร้างเสมอและต้อง cleanup เสมอ แต่ถ้าสุดท้ายต้นทุน LLM + ต้นทุน cleanup แพงกว่าเงินเดือนนักพัฒนาตลอด เราก็ควรย้อนกลับไปให้มนุษย์เขียนเองหรือเปล่า?
การให้ LLM generate โค้ดแล้วค่อยตรวจทีหลังเพื่อนำมาใช้นั้นไม่เหมือน vibe coding
vibe coding คือเอาโค้ดสำเร็จรูปมาใช้เลยโดยไม่ตรวจ
ทั้งสองแบบสุดท้ายก็คงไม่หายไปไหน
ทุกวันนี้ vibe coding ที่ขับเคลื่อนด้วย AI กำลังค่อย ๆ หมดกระแส
เพราะเดี๋ยวอีกไม่นานก็จะมี AI ที่เก่งกว่านี้ออกมาอีก
ถ้าเอาแต่ vibe coding ทั้งวัน สุดท้ายโครงสร้างต้นทุนอาจแบกรับไม่ไหว
สิ่งที่ทำให้ทุกคนตื่นเต้นเพราะมีระบบช่วยและสนับสนุนมากเกินไป อาจเป็นแค่ภาพลวงตา แล้วทีหลังทุกคนก็จะกลับมาตระหนักความจริงและต้องเจอช่วงเจ็บปวด
แต่แนวโน้มที่การเขียนโค้ดทุกกรณีจะถูกใส่เข้าไปเป็นเครื่องมือช่วยแบบ predictive completion และ auto-generation นั้นไม่มีวันหายไปแน่
ก็เหมือนสมัยก่อนเรายังเขียนโค้ดโดยไม่มี syntax highlighting กันได้ แต่ตอนนี้ไม่มีใครอยากกลับไปทำแบบนั้นแล้ว
การต้องพิมพ์ DFS เดิมซ้ำเป็นครั้งที่ 80 ไม่ได้ทำให้ศักดิ์ศรีความเป็นโปรแกรมเมอร์ของผมสูงขึ้นแต่อย่างใด