Vibe Code ก็คือ Legacy Code

 (blog.val.town)
24 คะแนน โดย GN⁺ 2025-07-31 | 12 ความคิดเห็น | แชร์ทาง WhatsApp
  • Vibe coding คือแนวทางการเขียนโค้ดอย่างรวดเร็วตามสัญชาตญาณโดยอาศัยความช่วยเหลือจาก AI ซึ่งสุดท้ายมักทิ้งโค้ดที่ตัวเองไม่เข้าใจไว้ นั่นคือ legacy code
  • Legacy code คือโค้ดที่ไม่มีใครเข้าใจ ก่อให้เกิดหนี้ทางเทคนิคและปัญหาด้านการบำรุงรักษา และมีโอกาสเกิดข้อผิดพลาดสูงเมื่อเพิ่มฟีเจอร์ใหม่
  • Vibe coding อาจเป็นวิธีพัฒนาที่รวดเร็วสำหรับ prototype หรือ โปรเจ็กต์ระยะสั้น แต่ไม่เหมาะกับโปรเจ็กต์ที่ต้องดูแลรักษาในระยะยาว
  • หากผู้ที่ไม่ใช่ผู้เชี่ยวชาญทำ vibe coding กับโปรเจ็กต์ขนาดใหญ่ ก็มีความเสี่ยงคล้ายกับ ให้บัตรเครดิตกับเด็ก
  • แม้ในปี 2025 การ พัฒนาร่วมกับ AI ก็ยังสำคัญที่จะต้องรักษาความรอบคอบและความเข้าใจเอาไว้

Vibe coding คืออะไร

  • Andrej Karpathy นิยามคำว่า "vibe coding" ว่าเป็นรูปแบบการเขียนโปรแกรมที่ AI เป็นคนเขียนโค้ด และผู้ใช้แทบไม่ต้องใส่ใจจนเหมือนลืมไปเลยว่าโค้ดมีอยู่
  • แนวทางนี้แตกต่างจากการพัฒนาซอฟต์แวร์แบบดั้งเดิม เพราะผู้พัฒนาสามารถได้ผลลัพธ์โดยไม่ต้องเข้าใจภายในของโค้ดที่ถูกเขียนขึ้นเลย

ปัญหาของ legacy code และหนี้ทางเทคนิค

  • โค้ดที่ไม่มีใครเข้าใจนั้นถือเป็น legacy code อยู่แล้ว
  • โค้ดลักษณะนี้ใช้เวลามากในการดูแลและแก้ไข และยังเพิ่มปัญหาอย่างมากทั้งเวลาเกิด bug หรือเมื่อต้อง เพิ่มฟีเจอร์ใหม่
  • มีการเน้นว่าแก่นแท้ของการเขียนโปรแกรมไม่ใช่การสร้างโค้ดให้มาก แต่คือการ สร้างทฤษฎีเชิงแนวคิด

Vibe coding กับการทำ prototype

  • Vibe coding ช่วยให้เริ่มต้นและพัฒนาได้อย่างรวดเร็วสำหรับการทำ prototype หรือ โปรเจ็กต์ใช้ครั้งเดียว
  • หากไม่จำเป็นต้องมีการดูแลต่อภายหลัง การไม่รู้ภายในของโค้ดก็อาจไม่ใช่ภาระใหญ่
  • ด้วยเหตุนี้มันจึงช่วยเพิ่มความเร็วในการพัฒนาได้มาก และเหมาะอย่างยิ่งกับการทดลองไอเดียใหม่

สเปกตรัมของความเข้าใจใน vibe coding

  • Vibe coding อยู่บนแนวคิดที่ว่ายิ่งผู้พัฒนาเข้าใจโค้ดน้อย ก็ยิ่ง ติด vibe มากขึ้น
  • โดยพื้นฐานแล้ว ยิ่งวิศวกรเข้าใจความต้องการได้ชัดเจนมากเท่าไร การทำ vibe coding ก็จะยิ่งลดลง
  • หากคนที่ไม่ใช่นักเขียนโปรแกรมขอให้เขียนโค้ดทั้งที่ไม่รู้แม้แต่ความต่างระหว่างเว็บกับแอปเนทีฟ หรือไม่รู้วิธีจัดเก็บข้อมูล โดยทั่วไปก็มักจะเกิด vibe coding มากขึ้น

Vibe coding โปรเจ็กต์ใหญ่โดยผู้ไม่เชี่ยวชาญ: คล้ายบัตรเครดิต

  • การที่ผู้ไม่เชี่ยวชาญพยายามสร้างและดูแลโปรเจ็กต์ขนาดใหญ่ด้วย vibe coding ก็คล้ายกับ ให้บัตรเครดิตกับเด็กโดยไม่อธิบายอะไรเลย
  • ตอนแรกทุกอย่างอาจดูง่ายไปหมด แต่หลังจากนั้นจะตามมาด้วยต้นทุนการบำรุงรักษาและปัญหาจำนวนมหาศาล
  • ท้ายที่สุดเมื่อ 'บิล' มาถึง หากไม่มีความสามารถพอจะแก้ปัญหา ก็อาจยิ่งทำให้สถานการณ์แย่ลง

การพัฒนาอย่างจริงจังในยุค AI ปี 2025

  • Andrej Karpathy เน้นว่าในการพัฒนาร่วมกับ AI จำเป็นต้องมี ความรอบคอบ และ ความระมัดระวัง รวมถึงท่าทีที่เรียนรู้จากโค้ดเดิมอย่างต่อเนื่อง
  • การป้องกันความมั่นใจเกินจริงของ AI และการใช้วิจารณญาณแบบมนุษย์เพื่อแยกแยะโค้ดที่ดีกับโค้ดที่ไม่ดีเป็นเรื่องสำคัญ
  • ไม่ควรปล่อยให้ AI ทำทั้งหมดเพียงลำพัง แต่ต้องอ่านและทำความเข้าใจโค้ดด้วยตัวเองเสมอ

การใช้เครื่องมือ AI ของ Val Town

  • Val Town ใช้ผู้ช่วย AI ชื่อ Townie เพื่อทำงานเขียนโค้ด รัน ตรวจสอบ และปรับปรุงซ้ำแบบอัตโนมัติ
  • Townie เป็นเครื่องมือที่เหมาะกับ vibe coding และสามารถใช้งานได้อย่างอิสระหรือควบคุมอย่างเข้มงวดตามวัตถุประสงค์
  • วิธีการพัฒนาร่วมกับ AI กำลังพัฒนาอย่างรวดเร็วมาก และความสำคัญของ รากฐานเชิงทฤษฎี ในการพัฒนาซอฟต์แวร์ที่ซับซ้อนก็จะยังคงอยู่ต่อไป

คำเตือนต่อการทำ vibe coding แบบไม่ยั้งคิดโดยผู้ไม่เชี่ยวชาญ

  • การที่ผู้ที่ไม่ใช่นักเขียนโปรแกรมใช้เงินหลายพันดอลลาร์เพื่อทำ vibe coding กับไอเดียแอปขนาดใหญ่ ไม่ใช่วิธีที่ดี
  • ท้ายที่สุดไม่ว่าอย่างไรก็ยังต้องมี สายตามนุษย์ ที่อ่านและวิเคราะห์ภายในของโค้ดโดยตรง และการออกแบบใหม่ให้ดีตั้งแต่ต้นมักมีประสิทธิภาพกว่าการไปแก้ legacy code ที่ไม่มีใครเข้าใจ

บทสรุปและคำแนะนำ

  • เมื่อสร้างซอฟต์แวร์ที่ซับซ้อน รากฐานเชิงทฤษฎี คือหัวใจสำคัญ
  • แม้วิธีการเขียนโปรแกรมจะเปลี่ยนแปลงอย่างรวดเร็วจากความก้าวหน้าของ AI แต่ความเชี่ยวชาญของนักพัฒนามนุษย์ก็ยังคงสำคัญ
  • หากผู้ไม่เชี่ยวชาญพยายามสร้างแอปขนาดใหญ่ด้วย AI สุดท้ายการอ่านโค้ดทั้งหมดและสร้างใหม่อาจเป็นทางเลือกที่ดีกว่า

บทความที่เกี่ยวข้อง

12 ความคิดเห็น

 
servent2616 2025-08-07

เป็นอุปมาเหมือนให้บัตรเครดิตกับเด็ก
เป็นการเปรียบเทียบที่เหมาะสมดี
หรืออาจเปรียบได้กับการให้มีดกับเด็กเหมือนกัน
 
actofvalor 2025-08-04

ถ้ามี AI สำหรับสร้างโค้ดที่ใส่คอมเมนต์ให้กับโค้ดที่ AI สร้างขึ้นพร้อมกัน และวาดแผนผังลำดับการทำงานของโค้ดให้ด้วย ก็น่าจะช่วยได้พอสมควรนะครับ
 
draupnir 2025-08-02

เป็นเรื่องที่รู้สึกเห็นด้วยมากทีเดียว ผมเองก็ได้เจอบางส่วนมาจริง ๆ เหมือนกัน…
และก็สงสัยเหมือนกันว่าส่วนนี้จะเปลี่ยนไปอย่างไรตามการเปลี่ยนแปลงของประสิทธิภาพโมเดล
 
optionzero 2025-08-02

เป็นคำพูดที่ตรงมากจนต้องตบเข่าฉาดแล้วผ่านไปเลย คนที่ไม่รู้เรื่องโค้ดเวลาใช้ vibe coding จะพูดว่า "ว้าว" แต่คนที่รู้โค้ดจะพูดว่า "ทำไม? แบบนี้"
 
qscwdv531 2025-08-02

สภาพคอมเมนต์นี่น่าเวทนาจริง ๆ
 
kgun9 2025-08-02

ถ้าอย่างนั้น รถยนต์ก็หมายความว่าเราจะไม่มีวันขับมันได้เลยจนกว่าจะเข้าใจโครงสร้างภายในทั้งหมดงั้นเหรอ?
 
onetoday 2025-08-06

การสร้างรถยนต์ทั้งที่ไม่เข้าใจโครงสร้างภายใน = การเขียนโค้ดแบบไวบ์
 
hackerst 2025-08-02

ก็ขี่ได้แหละ แต่คงสร้างเองไม่ได้หรอก
 
sinbumu 2025-08-01

ผมคิดว่านี่เป็นเรื่องของวิธีการและเทคโนโลยี คนที่บอกว่าไม่ควรใช้ AI แล้วต้องเขียนโค้ดด้วยมือแบบออร์แกนิกเท่านั้น ก็เหมือนพวกที่บอกว่าความจริงแท้คือต้องดีดลูกคิดแทนเครื่องคิดเลขวิศวกรรม หรือไม่ก็ต้องเขียนด้วยมืิอแทนการใช้ฟังก์ชันใน Excel
 
elbanic 2025-08-02

เป็นอุปมาอุปไมยที่ผิด เครื่องคิดเลขวิศวกรรมก็เหมือนกับเครื่องคิดเลขหรือ Excel ตรงที่ผลลัพธ์ถูกต้องตามค่าที่ป้อนเข้าไป หาก AI แสดงผลลัพธ์ออกมาตรงตามที่ผู้ใช้คาดการณ์ไว้ มันก็คงไม่ใช่เทคโนโลยีที่แตกต่างจากเทคโนโลยีใหม่มากมายที่ออกมาก่อนหน้านี้นัก นี่จึงเป็นเหตุผลด้วยว่าทำไมเมื่อเวลาผ่านไป ความกังวลเรื่องความปลอดภัยและ hallucination จึงยิ่งเพิ่มขึ้น กล่าวคือ Gen AI ไม่สามารถควบคุมได้ ต้องเข้าใจข้อจำกัดของ LLM ในปัจจุบัน และนำไปใช้ในจุดที่เหมาะสมเท่านั้น
 
tensun 2025-08-01

ตอนนี้การเขียนโค้ดแบบ vibe coding ยังอยู่ในระยะเริ่มต้น และมองว่าในปีหน้าหรืออีกสองปีข้างหน้ามันจะกลายเป็นระเบียบวิธีการพัฒนาที่สุกงอมมากขึ้น เช่นเดียวกับที่ devops กลายเป็น aidevops ผมคิดว่า aiagile หรือ vibeagile ก็น่าจะเกิดขึ้นเช่นกัน
 
GN⁺ 2025-07-31
ความเห็นจาก Hacker News

  • เป็นเรื่องเกี่ยวกับเพื่อนที่ไม่ใช่นักพัฒนา เพื่อนคนนี้เขียนโค้ด SaaS เปิดตัวเองเมื่อปีที่แล้ว และเริ่มมีรายได้จากการบอกต่อปากต่อปากกับอินบาวด์แทบล้วน ๆ โดยแทบไม่ต้องทำการตลาดเลย ใช้ Replit กับ Supabase ในการพัฒนา และพอนึกว่าตัวแอปค่อย ๆ ซับซ้อนขึ้นตามฟีดแบ็กลูกค้า ก็ยิ่งรู้สึกว่าน่าทึ่งมาก ในมุมมองของผม ตลาดนี้มีผู้เล่นเดิมอยู่สองราย และเพราะเพื่อนผมเสนอผลิตภัณฑ์ที่ทันสมัยกว่าพร้อมค่าสมาชิกรายเดือนที่ถูกกว่ามาก พวกนั้นคงไม่พอใจนัก (ผลิตภัณฑ์เดิมทั้งหมดเป็นซอฟต์แวร์เดสก์ท็อปสำหรับ Windows) เลยไปจ้างแฮ็กเกอร์มาโจมตี SaaS ของเพื่อนผม โดยแฮ็กเกอร์พวกนี้โจมตีโดยไม่เรียกค่าไถ่ใด ๆ น่าเสียดายที่เพื่อนผมรีบเขียนโค้ดทั้งที่ยังไม่มีประสบการณ์ เลยมีช่องโหว่มากมาย อย่างแรก โค้ดฝั่งฟรอนต์เอนด์เปิดเผยรายชื่อผู้ใช้ ทำให้แฮ็กเกอร์ส่งอีเมลหาลูกค้าทั้งหมดได้ อย่างที่สอง แฮ็กเกอร์ได้ Stripe key ไปและทำการคืนเงินให้ลูกค้าทั้งหมด อย่างที่สาม ตอนนี้แฮ็กเกอร์ก็ยังพยายามโจมตีแบบ XSS อยู่ และบางครั้งก็มีแท็กอย่าง <script>alert()</script> โผล่มาในฟิลด์ สรุปของผมคือ ถ้าคนไม่มีประสบการณ์มาทำ vibe-coding หนี้เทคนิคจะก่อตัวแทบจะทันที แต่ในขณะเดียวกัน การที่เพื่อนคนนี้พิสูจน์ได้ภายในไม่กี่เดือนว่ามีผลิตภัณฑ์ที่ไปต่อเชิงธุรกิจได้ ทั้งที่ไม่มีประสบการณ์ด้านวิศวกรรมเลย ก็ยังน่าทึ่งมาก ตอนนี้กำลังจ้างนักพัฒนาเข้ามาเก็บงานอยู่ ผมคิดว่าการพิสูจน์ศักยภาพทางธุรกิจได้ด้วยเงินลงทุนแค่ไม่กี่ร้อยดอลลาร์ แม้จะเป็นโค้ดที่หลวมและเปราะบางด้านความปลอดภัยแบบนี้ สุดท้ายแล้วกระบวนการนั้นก็คุ้มค่าอยู่ดี

    • ผมกลับรู้สึกว่าการตั้งสมมติฐานว่าเป็นฝีมือคู่แข่งนั้นเหมือนการปัดความรับผิดชอบมากกว่า ในความเป็นจริง ดูน่าเชื่อกว่ามากว่าแค่สแกนเนอร์หาช่องโหว่อัตโนมัติไปเจอเว็บเข้า แล้วเพราะมันหลวมมาก แฮ็กเกอร์เลยเข้ามาป่วนเล่น คนที่เห็นทราฟฟิก exploit แบบนี้บ่อย ๆ บนบริการที่ต่ออินเทอร์เน็ตคงรู้ดี

    • นี่แทบจะเทียบทางศีลธรรมได้กับการสร้างบ้านโดยไม่มีประสบการณ์วิศวกรรม แล้วมีใครสักคนมาเตะพังลงเฉย ๆ ปัญหาไม่ได้อยู่ที่ vibe coding เอง แต่อยู่ที่การขาดความรู้ที่จำเป็นต่อการตัดสินใจเรื่องสำคัญ ปัญหาแบบนี้อาจลามไปถึงความรับผิดทางกฎหมายได้ด้วย

    • ถ้าในตลาดมีผู้เล่นเดิมอยู่แล้ว การพิสูจน์ความเป็นไปได้ทางธุรกิจจำเป็นต้องใช้ MVP แบบนี้จริงหรือ? โดยแก่นแล้ว ถ้าขายถูกกว่า คนก็พร้อมจะย้ายจากผู้ให้บริการเดิมอยู่แล้ว จึงแทบไม่ต้องทดสอบเรื่องนี้เลย บทเรียนที่เพื่อนคุณได้คือ ลูกค้าบางส่วนอาจยอมจ่ายในช่วงแรก (แต่ยังไม่มีข้อมูลเรื่องการใช้งานซ้ำ) ทว่าสุดท้ายก็ต้องจ้างคนมาสร้างผลิตภัณฑ์จริงอยู่ดี และพอถึงตอนนั้นความได้เปรียบด้านราคาก็จะหายไป เมื่อถึงเวลาต้องทุ่มเรื่องการตลาดจริงจัง ก็น่าจะมีเรื่องให้คิดหนักอีกเยอะ สุดท้ายมันก็ย้ำบทเรียนเดิมว่า ไอเดียอย่างเดียวไม่มีค่าอะไร ความสามารถในการลงมือทำต่างหากที่สำคัญ

    • การที่เพื่อนคุณยังสามารถทำธุรกิจต่อไปได้โดยแทบไม่ต้องรับผิดชอบอะไรเลย นี่แหละคือปัญหาเชิงโครงสร้างของอุตสาหกรรมนี้ ถ้าโลกของซอฟต์แวร์ถูกกำกับเข้มเหมือนสาขาวิศวกรรมอื่น นักพัฒนาหรือบริษัทคงต้องรับผิดทางกฎหมายแน่จากการทำข้อมูลลูกค้ารั่ว

    • ถึงจะพิสูจน์ตัวธุรกิจได้ แต่จากมุมลูกค้า เรื่องนี้อาจเป็นความเสียหายมากกว่าผลดี พวกเขาจ่ายเงินเพื่อใช้งาน ขณะเดียวกันก็เอาข้อมูลสำคัญไปวางไว้ในที่ที่เปราะบางด้านความปลอดภัย และยังไม่ชัดด้วยซ้ำว่าผลิตภัณฑ์ทำงานได้ถูกต้องหรือไม่ ตอนนี้บอกว่าจะจ้างนักพัฒนามาเก็บงาน แต่คงไม่ง่ายอย่างที่คิด ผมสนับสนุน AI ในฐานะสื่อการเรียนรู้ เครื่องมือเพิ่มผลิตภาพ หรือแหล่งข้อมูลฝึกฝน แต่ถ้าไม่มีมนุษย์เข้ามาคั่นกลาง ผลลัพธ์อาจออกมาน่ากลัวมาก

  • ก่อนหน้านี้ก็เคยมีหลายครั้งที่คนไม่ใช่นักพัฒนาหรือแม้แต่นักพัฒนารุ่นจูเนียร์ สร้างและปล่อยแอปพลิเคชันได้ง่าย ๆ ด้วย Microsoft Access, Excel ฯลฯ ตอนนั้นก็มีทั้งข้อจำกัด ปัญหาเรื่องการขยายระบบ และฝันร้ายด้านการดูแลรักษาเหมือนกัน แต่ในอีกด้าน กระแสแบบนี้ก็ผลักให้มืออาชีพเร่งพัฒนาโซลูชันที่ดีกว่าเช่นกัน สมัย PC เริ่มแพร่หลายก็ไม่ต่างกัน นักพัฒนาเมนเฟรมต่างตกตะลึงกับโค้ดโลก PC ที่ “เละเทะ”

  • ผมทำงานเป็นวิศวกรซอฟต์แวร์มาเกือบสามสิบปีและอ่านคอมเมนต์ในโพสต์นี้ครบหมดแล้ว แต่ผมรู้สึกว่าเหตุผลแทบทั้งหมดที่ใช้วิจารณ์ vibe coding นั้น ใช้ได้เหมือนกันกับโค้ดเบสที่ “มนุษย์เขียน” เกือบทั้งหมดที่ผมเคยเห็นมาตลอด (แน่นอนว่ามีข้อยกเว้น)

    • ผมไม่เข้าใจว่าทำไมโปรโตไทป์ที่สร้างมาเพื่อทิ้งถึงถูกมองว่าแย่ มันคือขั้นตอนที่สำคัญที่สุดของการเริ่มต้นธุรกิจ เช่นเดียวกับ legacy code ในความเป็นจริง โค้ดส่วนใหญ่ที่สร้างรายได้อยู่ทุกวันนี้ ก็น่าจะถูกนักพัฒนาในองค์กรนั้นมองว่าเป็น legacy อยู่แล้ว

    • มีมุกขำ ๆ ว่า ทันทีที่ merge เข้า trunk ทุกอย่างก็กลายเป็น legacy code แล้ว

    • ผมเห็นด้วยบางส่วน แต่ปัญหาของ vibe coding คือ มันเปิดทางให้คนลุยแบบไม่ศึกษาอะไรให้ดีเสียก่อน โดยไม่เข้าใจโครงสร้างของ codebase เดิมหรือไม่ค้นคว้าว่าควรใช้วิธีแก้แบบไหน เมื่อวานนี้เองเพื่อนร่วมงานที่ไม่คุ้นกับ Rust ใช้ vibe coding ทำฟีเจอร์ใหม่ออกมา ภายนอกดูเหมือน “ใช้งานได้” แต่ข้างในเละมาก (ทำ synchronous I/O ใน tokio async context, มี lock, มีการทำ channel เอง ฯลฯ) ทั้งที่มี async abstraction ที่ปลอดภัยอยู่แล้ว ก็ยังไปสร้าง abstraction ใหม่ที่ผิด ๆ ขึ้นมา ถ้าเขาลองค้นเองหรือขอความช่วยเหลือตั้งแต่แรก ก็อาจอ้างอิงตัวอย่างจากโค้ดเดิมได้

  • โค้ดทุกชิ้นจะกลายเป็น legacy code ในสักวันหนึ่ง จากประสบการณ์ตอนผมเป็นจูเนียร์และตอนรีวิว production script หรือ service code ที่เพื่อนร่วมงานจูเนียร์เขียนไว้มากมาย มุมมองแบบสุดโต่งนี้แรงเกินไป ปัญหานี้เกิดซ้ำในแทบทุกองค์กร ผมเข้าใจการเขียนบทความวิจารณ์คุณภาพโค้ดที่มาจาก LLM แต่ถ้าใครใช้ทั้งอาชีพไปกับการแก้ ขยาย หรือรีแฟกเตอร์ระบบที่คนอื่นสร้างไว้ ก็น่าจะรู้ความจริงข้อนี้ดีกว่า ถ้าโลกวิศวกรรมซอฟต์แวร์ไม่เริ่มใช้มาตรฐานที่เข้มงวด ความสม่ำเสมอ การรับรอง ความรับผิด และผลลัพธ์จริง พร้อมความเสี่ยงทางกฎหมายแบบเดียวกับวิศวกรรมเครื่องกล การถกเถียงนี้ก็ไม่ค่อยมีความหมาย อุตสาหกรรม IT สมัยใหม่สร้างขึ้นบนปรัชญาตรงกันข้ามทั้งหมด คือ ‘agile’ และ ‘ทำเร็ว พังได้ไม่เป็นไร’ ปล่อยของเร็ว ออกแบบให้น้อย ดีพลอยถี่ ๆ ถ้ามีอะไรผิดก็ย้อนกลับ ถ้าระบบล่มก็เหมือน “ช่างมัน” ซอฟต์แวร์ถูกปฏิบัติราวกับเป็นของเล่น มีแค่ 1% ที่คงภูมิใจว่าทำถูกต้องจริง แต่ส่วนใหญ่ไม่ใช่แบบนั้น

    • คุณพูดถูกทั้งหมด และผมขอเสริมว่า โค้ดสุดท้ายแล้วก็ไม่ใช่วิทยาศาสตร์ มาตรฐานว่าโค้ดแบบไหนคือ “คำตอบที่ถูกต้อง” มันขึ้นกับบริบท โค้ดเป็นแค่เครื่องมือเพื่อให้ไปถึงเป้าหมาย

  • ตอนนี้มีเรื่องน่าสนใจเกิดขึ้น คนที่ไม่ค่อยเข้าใจวิศวกรรม และบางส่วนก็เข้าใจอยู่บ้างแต่ก็อธิบายไม่ถูก กำลังเผยแพร่ narrative ที่ผิดบนโลกออนไลน์ พวกเขาอ้างว่าตอนนี้นักพัฒนาจูเนียร์มีผลิตภาพเพิ่มขึ้น 10 เท่า และแม้แต่ PM ก็ deploy โค้ดเองได้แล้ว แต่ถ้าลองหลับตาแล้วนึกถึงโค้ดที่ออกมาจากสถานการณ์แบบนั้นสักครู่ มันคือ legacy code 100% และเป็นโค้ดที่ต้องถูกทิ้ง ประเด็นหลักไม่ใช่ AI หรือความสามารถของ PM ในการดึงโค้ดจาก Figma โดยตรง หรือการที่จูเนียร์พร่ำยิง prompt ปัญหาที่แท้จริงคือความคาดหวังกับความเป็นจริงมันห่างกัน เพราะคนแยกแยะศัพท์และแนวคิดที่นิยามกันมาหลายปีไม่ออก
    lean prototype กับ disposable prototype (ซึ่งยังไม่ใช่ MVP ด้วยซ้ำ) เป็นคนละอย่างกัน MVP จะสร้างได้ก็ต่อเมื่อ lean prototype ผ่านการพิสูจน์สำเร็จแล้ว และ product ก็ยังต่างจาก MVP อีก
    เครื่องมือ vibe coding เหมาะที่สุดสำหรับการทำ disposable prototype อย่างรวดเร็ว ส่วน IDE ที่ฝัง LLM เหมาะกับการสร้างผลิตภัณฑ์จริงมากกว่า ณ ตอนนี้ มีแต่วิศวกรตัวจริงเท่านั้นที่ใช้ LLM prompt เขียน lean prototype ได้ดี ส่วนที่เหลือกำลังสร้างแค่ซอฟต์แวร์ง่าย ๆ ที่ทำงานอยู่บนโค้ดใช้แล้วทิ้ง

    • ที่คุณบอกว่า “product ต่างจาก MVP” นี่ ผมอยากเอาไปบอกแทบทุกบริษัทที่ผมเคยทำงานด้วย ทุกวันนี้บอร์ดกับผู้บริหาร C-level มีท่าทีแบบ “ขออะไรสักอย่างออกมาภายในไตรมาสนี้” กันเต็มไปหมด นักพัฒนาเลยถูกผลักให้ทำ MVP แล้วกระโดดไปโปรเจกต์ถัดไปทันที ไม่ว่าจะเป็น vibe coding หรือไม่ก็ตาม ความจริงก็คือถ้ามันดูเหมือนฟีเจอร์เยอะ ตัวชี้วัดทางธุรกิจก็ขึ้นโดยไม่สนคุณภาพจริงนัก เอาเข้าจริง สภาพแวดล้อมที่วิศวกรตัวจริง (ดูเหมือนตอนนี้จะเรียกคนกลุ่มนี้ว่า “นักพัฒนา”) เป็นผู้นำการทำโปรโตไทป์นั้นมีน้อยมาก จะเห็นได้บ้างในเกมหรือบริษัทเทคบางแห่งเท่านั้น คนส่วนใหญ่โฟกัสแต่การผลิต MVP ล้วน ๆ vibe coding แค่ช่วยเร่งความเร็วในการปั๊ม MVP แต่คุณภาพก็ต้องแลกไปตามนั้น

    • แนวโน้มที่ “คำนิยามของคำ” ถูกใช้ปนเปกันแบบไร้เนื้อหานั้น ชัดขึ้นเรื่อย ๆ ในอุตสาหกรรมช่วง 10 ปีที่ผ่านมา คำเหล่านี้เดิมทีมีบริบทสะสมจากหนังสือมากมาย การถกเถียงจำนวนมหาศาล และช่วงเวลายาวนาน เวลา senior developer ใช้คำหนึ่งคำ มันบรรจุประสบการณ์และบริบทของข้อถกเถียงทั้งหมดไว้ แต่พอพนักงานใหม่เข้ามา เขาก็ “ลอก” คำพวกนี้ไปใช้แบบผิวเผินโดยไม่มีบริบทและไม่มีนิยาม ผลคือไม่มีใครรู้แล้วว่าคำแต่ละคำเดิมหมายถึงอะไร และทำไมมันถึงเหมาะกับสถานการณ์นั้น เช่น "'agile', 'technical debt', 'DevOps', และคำใหม่อย่าง ‘vibe coding'" เป็นต้น บน HN ก็มี โพสต์เรื่อง semantic drift ด้วย นี่เป็นปรากฏการณ์ที่พบได้บ่อยในวงการซอฟต์แวร์
      ตัวอย่างเชิงเทคนิคคือใน JavaScript คนมักใช้ 'object', 'JSON', 'dictionary', 'hashmap' ปนกันไปหมด ทั้งที่เดิมทีแต่ละคำมีความหมายต่างกัน แต่สำหรับนักพัฒนา JS จำนวนมาก มันถูกรวมเป็นแค่ ‘object’ คำเดียว ราวกับความละเอียดเชิงภาษาและแนวคิดทั้งหมดถูกบีบจนเหลือเพียง “พิกเซล” เดียว

    • เมื่อก่อนนักพัฒนาจะพูดกันว่าแต่ละคนมี “ทัศนคติ” ต่อโค้ดต่างกัน แต่ตอนนี้ความเหนื่อยล้าของนักพัฒนาเพิ่มขึ้นมหาศาลเพราะไม่มีใครเข้าใจโค้ดแล้ว สมัยก่อนถ้าเป็นแบบนี้ วิศวกรจะลงมือซ่อมส่วนที่พังให้กลับมามีประโยชน์ และสถาปนิกระบบจะช่วยลดความซับซ้อน แต่ในยุค LLM ตอนนี้ โค้ดหลั่งไหลออกมามากขึ้น 100 เท่า ขณะที่วิศวกรและสถาปนิกกลับถูกกันออกจากกระแสนี้โดยสิ้นเชิง นี่คือสภาพที่เรารับรู้กันอยู่ในปัจจุบัน
      ถ้าใครคิดวิธีทดสอบเพื่อแก้ปัญหานี้ได้ (ไม่ว่าจะเป็น TDD MCP server, DDD MCP server หรือ workflow/architecture แบบไหนก็ตาม) ก็อาจกลายเป็นสตาร์ตอัประดับหลายล้านล้านได้เลย ตอนนี้เราต้องการเครื่องมือที่ช่วยยกระดับและขยายประสิทธิภาพของ code review อย่างเร่งด่วน

    • ผมคิดว่าเราต้องนิยาม “ซอฟต์แวร์ที่ใช้งานได้” ให้ชัดกว่านี้ก่อน เช่น UI ที่ LLM สร้างขึ้นมามักดูเหมือนกันไปหมด และมักมีจุดผิดเล็ก ๆ หรือข้อผิดพลาดซ่อนอยู่ ทดสอบกับผู้ใช้ครั้งเดียวก็เจอปัญหาทันที อีกอย่าง UI แบบ generative มักหมกมุ่นกับเทรนด์จนไม่ค่อยสร้างอะไรใหม่จริง ๆ

    • คุณเคยเห็นวิธีที่บริษัทใหญ่เขียนโค้ดใช้ภายในไหม? มันแทบไม่ต่างจาก vibe coding เลยด้วยซ้ำ ถ้าเอา LLM ไปจูนให้ผ่าน pentest อย่างน้อยมันยังพยายามทำอะไรสักอย่าง แต่บริษัทใหญ่คือไม่สนใจเลย

  • ความจริงแล้วโค้ดทุกอย่างคือ legacy ดังนั้นการที่ vibe coding สร้างโค้ดจำนวนมากได้เร็ว จึงไม่ได้พิเศษอะไร สุดท้ายโค้ดที่ “ผมเขียนเองกับมือ” แต่ไม่มีใครเข้าใจก็เละพอกัน โค้ดทั้งหมดสุดท้ายก็เป็นภาระในแง่การบำรุงรักษา ไลบรารีก็ช่วยลดปัญหาได้แค่บางส่วน แต่ถ้ามันเปลี่ยนบ่อยหรืออินเทอร์เฟซล้าสมัย มันก็ยิ่งเป็น legacy ที่แย่กว่าเดิม
    คนที่เขียนโค้ดมานานพอ สุดท้ายมักลงเอยที่ข้อสรุปเดียวกันว่า คำตอบคือเขียนให้น้อยลง หรือโดยรวมแล้วลดความจำเป็นของมันลงให้ได้ ทุกความซับซ้อนสุดท้ายคือ “ปัญหาที่ตัวเราในอนาคตจะจำไม่ได้” ในทางปฏิบัติ ความต้องการก็เปลี่ยนไปเรื่อย ๆ และแม้แต่ความต้องการที่ผู้เชี่ยวชาญกำหนดก็อาจผิดได้ (และ “ผู้เชี่ยวชาญ” คนนั้นอาจเป็นตัวเราเองก็ได้)

    • ผมไม่เห็นด้วยกับข้ออ้างที่ว่า “โค้ดทั้งหมดคือ legacy” บางส่วนมีขนาดเล็ก และนักพัฒนายังถือทุกอย่างไว้ในหัวได้ครบ จึงยังเป็นโค้ดที่ “สดอยู่ตลอดเวลา” คำนิยามที่แท้จริงของ legacy คือ โค้ดขนาดใหญ่ที่ไม่มีใครในองค์กรเป็นเจ้าของอยู่ในปัจจุบัน และโค้ดจาก vibe coding ก็ผ่านสองเงื่อนไขนี้ตั้งแต่วินาทีที่มันถูกสร้าง

    • legacy หมายถึง สิ่งที่ไม่มีผู้มีส่วนได้เสียเหลืออยู่แล้ว จนทั้งการบำรุงรักษาและการทำความเข้าใจบริบทกลายเป็นเรื่องยาก

    • ผมอยากแก้ปัญหาด้วยโค้ดให้น้อยที่สุด ประเด็นคือทำอย่างไรให้โค้ดไม่กลายเป็นปัญหาของผมเอง หัวใจคือ abstraction รั่วแค่ไหน และ abstraction ที่ LLM สร้างตอนนี้แย่มาก จะดีขึ้นในอนาคตแค่ไหนยังตอบไม่ได้
      ผมอยากลงทุนในเครื่องมือที่ทำให้การเข้าใจโค้ดสนุก ง่าย และถูกลง เพื่อนผม Glen ทำโปรเจกต์หนึ่งที่น่าดูเป็นตัวอย่าง: https://glench.github.io/fuzzyset.js/ui/
      อย่างที่ Geoffrey Litt พูดไว้ LLM อาจมีประโยชน์กว่ามากในฐานะตัวช่วยทำ visualization ชั่วคราว, debugger และเครื่องมือช่วยให้เราเข้าใจโค้ดของตัวเอง

    • โค้ดทุกชิ้นมีความเสี่ยง แต่ไม่ใช่ทุกชิ้นจะเป็น legacy โค้ดที่ได้จาก vibe coding ให้ความรู้สึกว่าเป็น legacy ตั้งแต่แรก เพราะมันไม่มีทั้งบริบทและเจ้าของ

    • ถ้าจะโต้แย้งเรื่อง “ทุกโค้ดคือ legacy” สำหรับผม โปรเจกต์ที่ผมเข้าใจลึกมากจนชี้สาเหตุของบั๊กได้ทันที และจินตนาการการใส่ฟีเจอร์ใหม่ในหัวได้เลย แบบนั้นไม่ใช่ legacy

  • ผมคิดว่ายุคที่ “มองโค้ดแบบคณิตศาสตร์” จบไปแล้ว ซอฟต์แวร์ที่ใหญ่พอและเชื่อมโยงกับโลกจริง ไม่สามารถรับประกันได้แบบการพิสูจน์ทางคณิตศาสตร์ว่ามันเป็นจริงอย่างสมบูรณ์ ระบบในโลกจริงเป็นผลผลิตทางวิศวกรรมที่ต้องพึ่งการรับประกันเชิงรูปแบบบางส่วน การออกแบบจากประสบการณ์ การทดสอบเชิงทดลอง ความชำนาญ และเกณฑ์ด้านประสิทธิภาพ
    แนวโน้มนี้จะขยายลงไปถึงสคริปต์เล็กที่สุดด้วย ซอฟต์แวร์ส่วนใหญ่ไม่จำเป็นต้องพิสูจน์เชิงคณิตศาสตร์ด้วยซ้ำ แค่บรรลุวัตถุประสงค์ก็พอ ผมเคารพความประณีตของงานเขียนโปรแกรมอย่างเต็มที่ แต่ถึงเวลาแล้วที่จะต้องปล่อยบางส่วนของสิ่งนั้นไป
    สรุปแล้วอนาคตมีทางเลือกอยู่สองแบบ

  • โปรแกรม 100,000 บรรทัด พร้อมการทดสอบ 50,000 รายการ ที่รับประกันข้อกำหนดทั้งหมด แต่แทบไม่มีใครอ่านรู้เรื่อง ต้นทุนรวม 50,000 ดอลลาร์ (ค่า API token)

  • โปรแกรมที่มนุษย์ออกแบบเอง 30,000 บรรทัด มีการทดสอบ 3,000 รายการ abstraction สวยงาม ตอบโจทย์ข้อกำหนดเหมือนกัน ต้นทุนรวม 300,000 ดอลลาร์ (ค่าแรงนักพัฒนา)
    ถ้าผมเป็นผู้บริโภคซอฟต์แวร์ ไม่ได้สนใจรายละเอียดข้างในและดูแต่ราคา ผมเลือกอันที่ถูกกว่า 6 เท่าทันที

    • ต้องคิดถึงเวลาที่มีข้อกำหนดภายนอกใหม่เข้ามาแล้วจำเป็นต้องเปลี่ยนด้วย ถ้าเป็นกรณีนี้ และซอฟต์แวร์นั้นเป็นแกนหลักของธุรกิจ ก็อาจต้องเปลี่ยนผู้ให้บริการทันที นั่นจึงเป็นเหตุผลว่าทำไมทั้ง B2B และ B2C จึงต้องให้ความสำคัญกับการบำรุงรักษาและการสนับสนุน ซอฟต์แวร์ต้องตอบสนองต่อการเปลี่ยนแปลงได้เสมอ

    • เลยมีมุกว่า “โค้ดนี้มีแค่ผมกับ Copilot ที่เข้าใจ ตอนนี้เหลือแค่ Copilot ที่ยังเข้าใจ”

    • สำหรับประโยคที่ว่า “ระบบขนาดใหญ่พอและเชื่อมโยงโลกจริงไม่สามารถพิสูจน์ทางคณิตศาสตร์ได้ว่าถูกต้อง” คนที่ทำ formal verification อาจคัดค้านอย่างหนัก หรือไม่ก็อาจเห็นด้วยอยู่ลึก ๆ ก็ได้

    • ในสองสถานการณ์นี้ คุณต้องถามต่อว่า เวลาอัปเดตเวอร์ชันแล้ว แบบไหนถูกกว่าและเร็วกว่า ตอนนี้ผมยังคิดว่าโมเดลนักพัฒนามนุษย์ถูกกว่า แต่อนาคตก็ยังไม่แน่

    • เอาจริง ทั้งสองตัวเลือกนี้ผมแทบไม่เคยเห็นในโลกจริงเลย

  • ขั้นสุดยอดของวิวัฒนาการอาจเป็นภาษาโปรแกรมที่มุ่งเพื่อเครื่องโดยสมบูรณ์จนมนุษย์ไม่จำเป็นต้องอ่านอีกต่อไป LLM จะต้องแปลงเป็นภาษาที่คนอ่านง่ายอย่าง Python หรือ Swift ไปทำไม? ถ้ามีแค่ผลลัพธ์ที่พร้อมทำงานได้โดยตรง แนวคิดเรื่องการบำรุงรักษาก็ยิ่งหมดความหมาย ตอนนี้เรายังไม่ถึงจุดนั้น แต่ผมคิดว่าสุดท้ายแล้วเราน่าจะไปถึง

    • ซอฟต์แวร์ที่ดีต้องอยู่ในสภาพ “กำลังถูกบำรุงรักษา” เสมอ เพราะข้อกำหนดใหม่ ๆ จะเข้ามาไม่สิ้นสุด ความเชื่อที่ว่าดีพลอยฟีเจอร์ครั้งเดียวแล้วจบไปตลอดเป็นเรื่องชวนขำ โค้ด การทดสอบ และเอกสารที่ทำไว้เผื่อการเปลี่ยนแปลงในอนาคตจึงสำคัญมาก ถ้า LLM ผลิตโค้ดกล่องดำไร้ความหมายออกมาจำนวนมาก ผมว่าไม่มีอะไรน่ากลัวไปกว่านั้นแล้ว แนวคิดที่ว่า LLM จะไปถึงระดับเขียนโค้ดเท่ามนุษย์จนไม่มีใครต้องสนใจเรื่องนี้อีก เป็นเรื่องระดับนิยายวิทยาศาสตร์ การเขียนโค้ดเป็นเพียงส่วนหนึ่งของกระบวนการทั้งหมดในการสร้างซอฟต์แวร์ที่มีประโยชน์จริง

    • จริง ๆ แล้ว machine code ก็ใกล้แบบนั้นอยู่แล้วไม่ใช่หรือ? LLM ถูกปรับให้เหมาะกับอินเทอร์เฟซที่มนุษย์อ่านได้ นั่นจึงเป็นเหตุผลว่าทำไมมันสร้าง JSON และแทบไม่ใช้ BSON

    • ผมสงสัยจริง ๆ ว่าแนวคิดนี้แก้ปัญหาอะไรได้บ้าง แต่ปัญหาที่มันจะสร้างขึ้นมานั้นชัดเจนมาก

    • มันให้ความรู้สึกเหมือน LLM เรียนรู้จากโค้ดสำหรับมนุษย์ จากนั้นใส่กลับเป็นโค้ด แล้วค่อยรันโค้ดนั้นเพื่อให้ได้พฤติกรรมที่ต้องการ เป็นเหมือน “เกมส่งสาร” อีกรูปแบบหนึ่ง ทำไมไม่สร้างพฤติกรรมโดยตรงไปเลยล่ะ

    • ถ้าพูดถึงภาษาที่มนุษย์อ่านยาก Malbolge คือหนึ่งในตัวอย่างคลาสสิก แม้แต่โปรแกรม "Hello World" ตัวแรกก็ยังถูกสร้างด้วย genetic algorithm

  • ผมเป็นผู้เขียนต้นฉบับเอง ตื่นเต้นที่จะได้คุยกับทุกคน

  • คำว่า ‘vibe coding’ นี่เป็นคำที่สมบูรณ์แบบเกินไป คล้ายกับที่ ‘cloud computing’ ถูกขยายความหมายออกไปมหาศาล เดิมทีมันหมายถึงการเปิด EC2 instance แบบยืดหยุ่นเพื่อใช้งานแล้วทิ้งเมื่อเสร็จ แต่เพราะอุปมามันเข้าใจง่ายเกินไป สุดท้ายแม้แต่ Gmail ก็ถูกเรียกรวมว่าเป็น ‘คลาวด์’ ไปหมด