Vibe Coding ไม่ใช่ข้ออ้างสำหรับงานคุณภาพต่ำ

• Vibe coding ที่ขับเคลื่อนด้วย AI เป็นเรื่องน่าตื่นเต้น แต่ก็มีคำเตือนว่า ความเร็วที่ไร้คุณภาพนั้นอันตราย

"ขยับให้เร็วขึ้น แล้วพังให้มากขึ้น"
"vibe coding วิธีที่วิศวกรสองคนสามารถสร้างหนี้ทางเทคนิคได้เทียบเท่าคน 50 คน"

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

• หากจะยอมรับข้อดี AI-assisted coding ก็อาจเป็น game changer ได้จริง
• มัน ลดกำแพงการเข้าสู่วงการสำหรับโปรแกรมเมอร์หน้าใหม่หรือคนที่ไม่ใช่มืออาชีพ และช่วยให้พวกเขาสร้างซอฟต์แวร์ที่ทำงานได้ เพียงแค่อธิบายสิ่งที่ต้องการ
• สิ่งนี้ปลดปล่อยความคิดสร้างสรรค์ และทำให้ผู้คนจำนวนมากขึ้นสามารถ แก้ปัญหาของตัวเองได้โดยตรงด้วยซอฟต์แวร์แบบปรับแต่งเฉพาะ
• กระแสนี้ถูกมองว่าเป็นส่วนหนึ่งของเทรนด์ การ unbundling ของ personal software (ใช้เครื่องมือ AI ขนาดเล็กแทนแอปสำเร็จรูป)
• แม้แต่วิศวกรที่มีทักษะสูงก็ยังได้รับประโยชน์ได้

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

ความจริงที่ชวนอึดอัด: คุณภาพไม่ได้ตามมาเองโดยอัตโนมัติ

• แม้กระแส hype จะรุนแรง แต่ความสงสัยของนักพัฒนารุ่นเก๋าต่อ vibe coding ก็ไม่น้อยเช่นกัน
• คำวิจารณ์หลักมีอยู่ว่า: แค่ AI พ่นโค้ดออกมาได้เร็ว ไม่ได้แปลว่าโค้ดนั้นดี
• ที่จริงแล้ว การเชื่อและนำโค้ดที่ AI สร้างไปใช้ตรง ๆ อาจอันตรายไม่น้อย
• มุกที่ว่า “วิศวกรสองคนสร้างหนี้ทางเทคนิคได้เท่าคน 50 คน” ก็ไม่ได้เป็นแค่มุกล้วน ๆ
• โค้ด AI ที่ไม่ได้รับการตรวจทานสามารถขยายหนี้ทางเทคนิคในสเกลใหญ่ได้
  → หนี้นี้จะทำให้โค้ดเปราะบาง ดูแลรักษายาก และสร้างต้นทุนมหาศาลในระยะยาว

• โปรเจกต์ที่สร้างด้วย vibe coding มักดูดีจากภายนอก ("ทำงานได้นี่ งั้น deploy เลย!")
• แต่ในความเป็นจริง มันมักซ่อนความเสี่ยงอย่างเช่น:
  • ไม่มีการจัดการข้อผิดพลาด
  • ประสิทธิภาพต่ำ
  • แนวทางด้านความปลอดภัยไม่มั่นคง
  • โครงสร้างตรรกะอ่อนแอและแตกพังได้ง่าย
• โปรเจกต์แบบนี้ เหมือนโครงสร้างที่สร้างบนกองทราย
• และในคำที่ฉันชอบเรียกคือ “house of cards code” —
  ภายนอกดูเหมือนเสร็จสมบูรณ์ แต่พอเจอแรงกดดันในโลกจริงก็พังง่าย
• ถ้าคุณเคยเห็น ฟีเจอร์ใหญ่ชิ้นแรกของนักพัฒนาจูเนียร์ที่เกือบทำงานได้ แต่พังทันทีเมื่อเจออินพุตที่ไม่คาดคิดเพียงตัวเดียว คุณจะเข้าใจความรู้สึกนี้
• AI อาจสร้างโค้ดจำนวนมากได้อย่างรวดเร็ว แต่ปริมาณไม่ได้หมายถึงคุณภาพ

• "AI ก็เหมือนนักพัฒนาจูเนียร์ที่กระตือรือร้นมากคนหนึ่งซึ่งเพิ่งเข้าทีม"
• → แนวคิดนี้ถูกอธิบายไว้อย่างชัดเจนผ่านภาพประกอบของ Forrest Brazeal

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

• ความปลอดภัยก็เป็นอีกปัญหาใหญ่
• AI อาจสร้างโค้ดที่ภายนอกดูเหมือนทำงานได้ดี แต่ภายในอาจซ่อน ช่องโหว่ร้ายแรง อย่าง SQL injection ไว้
• หรืออาจมีการจัดการข้อผิดพลาดที่หละหลวม
• หากปัญหาเหล่านี้ ถูกนำขึ้น production โดยไม่ผ่านการรีวิวอย่างเข้มงวด ก็อาจนำไปสู่อุบัติเหตุจริงได้

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

• แน่นอนว่าทั้งหมดนี้ ไม่ได้แปลว่า AI เขียนโค้ดดี ๆ ไม่ได้เลย —
• AI บางครั้งก็สร้างโค้ดที่ยอดเยี่ยมได้
• แต่การตัดสินว่าโค้ดนั้นใช้ได้จริงหรือไม่ จำเป็นต้องมีสามสิ่งนี้เสมอ:
  • บริบท (context)
  • การตรวจสอบอย่างวิพากษ์ (scrutiny)
  • ประสบการณ์และความเชี่ยวชาญ (expertise)

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

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

AI ไม่ใช่ตัวแทน แต่เป็นอินเทิร์น (มนุษย์ต้องอยู่ในลูป)

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

• นักพัฒนาที่มีประสบการณ์มัก ทำตามกระบวนการนี้โดยสัญชาตญาณ
• เมื่อ AI เสนอโค้ดมา พวกเขาจะไม่กด “Accept” แล้วผ่านไปทันที แต่จะจัดการดังนี้:
  • อ่านและทำความเข้าใจโค้ดที่ AI เขียนก่อน — ปฏิบัติกับมันเหมือนโค้ดที่นักพัฒนาจูเนียร์เขียน
  • หากโค้ดเป็นก้อนเดียวหรือยุ่งเหยิง ให้แยกโมดูลและรีแฟกเตอร์ — แยกออกเป็นหน่วยที่เล็กลงและชัดเจนขึ้น
  • เติม exception handling หรือ edge case ที่ขาดไปด้วยตัวเอง — เช่น null check, การตรวจสอบอินพุต ซึ่ง AI มักพลาด
  • ทำให้ type ที่หลวม ๆ หรือ abstraction ที่ไม่สมบูรณ์แน่นขึ้น — เปลี่ยนสมมติฐานโดยนัยให้เป็นสัญญาที่ระบุชัด
  • ประเมินว่าสถาปัตยกรรมหรือวิธีที่ AI เลือกใช้นั้นไร้ประสิทธิภาพหรือไม่ — เช่น ประมวลผลแบบ brute force, การนำ global state เข้ามาใช้
  • เขียนเทสต์หรือทดสอบด้วยตนเอง — หาก AI สร้าง unit test มาให้ ก็ต้องตรวจด้วยว่าเทสต์นั้นใช้การได้จริงหรือไม่

• ผ่านกระบวนการทั้งหมดนี้ เราจึงใส่ ภูมิปัญญาทางวิศวกรรม (wisdom) ลงไปในโค้ดที่ AI สร้าง

• การผสมผสานนี้ทรงพลังมากได้ — AI มอบความเร็ว และ มนุษย์รับประกันความน่าเชื่อถือ

• อันที่จริง ทั้งงานวิจัยและประสบการณ์ในภาคปฏิบัติบ่งชี้ว่า นักพัฒนาอาวุโสได้คุณค่าจากเครื่องมือเขียนโค้ดด้วย AI มากกว่านักพัฒนาจูเนียร์

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

• ในทางกลับกัน นักพัฒนาจูเนียร์มีความเสี่ยงสูงที่จะ เชื่อ AI ผิด ๆ เหมือนเป็นผู้มีอำนาจสูงสุด

• ดังนั้นจึงเกิดกฎสำคัญข้อหนึ่ง:
  → โค้ดที่ AI เขียนต้องถูกรีวิวก่อนนำเข้าเสมอ
• เหมือนกับการรีวิว PR ของนักพัฒนาใหม่ คุณควร อ่านทีละบรรทัดและ merge ได้ก็ต่อเมื่อเข้าใจทั้งหมดแล้วเท่านั้น
• อย่าตั้งสมมติฐานว่า AI ฉลาดกว่า — ส่วนใหญ่แล้วไม่ใช่
• หากมีส่วนที่คุณไม่เข้าใจ:
  • ควรปรับ prompt ใหม่ให้ชัดเจนขึ้นแล้วขออีกครั้ง หรือ
  • เขียนโค้ดส่วนนั้นใหม่ด้วยตัวเองจะดีกว่า
• เอาต์พุตของ AI เป็นเพียง ‘ฉบับร่าง’ และต้องผ่านการรีวิวเสมอ
• หากเป็นสภาพแวดล้อมการพัฒนาแบบทีม:
  • ถ้ามีใครใช้ AI สร้างโค้ดขึ้นมา
  • คนนั้นต้องสามารถ อธิบายและปกป้องโค้ดนั้นได้ด้วยตัวเองในการรีวิว
  • “มันแค่ทำงานได้” ใช้ไม่ได้ — โค้ดที่แท้จริงต้องเป็นสิ่งที่มนุษย์เข้าใจและดูแลรักษาได้

• อีกหนึ่งแนวปฏิบัติที่ดี: มนุษย์ออกแบบ, AI ลงมือเขียน
• กล่าวคือ ใช้ AI เพื่อ ทำงานที่นิยามไว้แล้วให้เสร็จอย่างรวดเร็ว เช่น CRUD API
• ในทางกลับกัน คำขออย่าง “ช่วยออกแบบสถาปัตยกรรมไมโครเซอร์วิสที่ขยายระบบได้ให้หน่อย” เป็นสิ่งที่มนุษย์ควรทำ
• การออกแบบระดับสูงและการตัดสินใจสำคัญต้อง ยังคงเป็นหน้าที่ของมนุษย์
• สรุปคือ: ให้ AI รับงานซ้ำๆ ที่เป็น grunt work และให้มนุษย์รับงานที่ต้องใช้ความคิดและวิจารณญาณอย่าง brain work

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

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

กฎปฏิบัติจริงเพื่อทำ vibe coding ให้มีคุณภาพสูง

• จากที่คุยกันมาทั้งหมด ลอง สรุปเป็นกฎที่นำไปใช้ได้จริงและ best practices กัน
• มันอาจเรียกได้ว่าเป็นคู่มือยุคใหม่แบบ “เคลื่อนที่ให้เร็ว แต่ไม่ใช่พังทุกอย่าง”
• กฎเหล่านี้ทำหน้าที่เป็น ราวกันตกเพื่อรักษาคุณภาพ แม้จะทำ vibe coding ก็ตาม

• Rule 1: Always Review AI-Generated Code / ต้องรีวิวโค้ดที่ AI สร้างเสมอ
  • ไม่มีข้อยกเว้น โค้ดทุกชิ้นที่ AI เขียนต้อง ถูกรีวิวเหมือนโค้ดที่นักพัฒนารุ่นจูเนียร์เขียน
  • จะเป็นการรีวิวเองหรือให้เพื่อนร่วมทีมรีวิวก็ต้องทำ
  • ไม่ว่าจะเป็น Copilot, ChatGPT, Cursor หรือ AI ตัวไหนก็เหมือนกัน
  • ถ้าไม่มีเวลารีวิว ก็แปลว่าไม่มีเวลาจะใช้โค้ดนั้นเช่นกัน
  • การ merge โค้ดจาก AI โดยไม่รีวิว เท่ากับรับความเสี่ยงนั้นเข้ามาเต็มๆ
• Rule 2: Establish Coding Standards and Follow Them / ตั้งมาตรฐานการเขียนโค้ดและปฏิบัติตาม
  • AI จะสะท้อนรูปแบบโค้ดที่มันเรียนรู้มา ดังนั้นหาก ทีมไม่มีมาตรฐานที่สม่ำเสมอ คุณภาพก็จะเหวี่ยงขึ้นลง
  • ต้องกำหนด style guide, รูปแบบสถาปัตยกรรม และกฎการเขียนโค้ดของทีมให้ชัดเจน
  • เช่น “ทุกฟังก์ชันต้องมี JSDoc และ unit test” → โค้ดที่ AI สร้างก็ต้องใช้กฎเดียวกัน
  • ในโปรเจกต์ที่ใช้โครงสร้างแบบแยกชั้นหรือ layered architecture
    ต้องรีแฟกเตอร์เพื่อไม่ให้ AI เอา DB call ไปใส่ไว้ในโค้ด UI
  • แนะนำให้นำ กฎ lint หรือ static analysis มาใช้เพื่อจับความผิดพลาดที่ AI มักทำ เช่น ฟังก์ชันซับซ้อนเกินไป หรือการใช้ API ที่ deprecated แล้ว
• Rule 3: Use AI for Acceleration, Not Autopilot / AI เป็นตัวเร่ง ไม่ใช่นักบินอัตโนมัติ
  • ควรใช้ vibe coding เพื่อ เร่งงานที่เรารู้อยู่แล้วให้เสร็จไวขึ้น
  • ตัวอย่างการใช้งานที่ดี:
    • สร้าง boilerplate
    • scaffold คอมโพเนนต์
    • แปลงภาษา
    • เขียนโครงอัลกอริทึมง่ายๆ
  • ตัวอย่างการใช้งานที่เสี่ยง:
    • ให้ AI ออกแบบทั้งโมดูลจากคำอธิบายที่กำกวม
    • พยายามสร้างโค้ดในโดเมนที่ตัวเองไม่เข้าใจ
  • หากโค้ดนั้นจะอยู่ในระบบอย่างถาวร ต้อง เปลี่ยนจากโหมด vibe เป็นโหมด engineering อย่างแน่นอน
• Rule 4: Test, Test, Test / ต้องทดสอบเสมอ ไม่มีข้อยกเว้น
  • แค่เพราะ AI เป็นคนสร้างโค้ด ไม่ได้แปลว่า โค้ดนั้นจะถูกต้องโดยอัตโนมัติ
  • ต้องเขียนเทสต์สำหรับทุกเส้นทางหลัก
  • ถ้า AI ช่วยสร้างเทสต์มาด้วย ก็ต้องตรวจด้วยว่าเทสต์นั้นใช้ได้จริงหรือไม่
  • โดยเฉพาะฟีเจอร์ UI หรือส่วนที่มี input จากผู้ใช้มาก ต้อง คลิกทดสอบเองและทดสอบ input ผิดรูปแบบด้วย
  • แอปที่ vibe-coded มัก ทำงานได้ดีเฉพาะ happy path แต่เปราะบางเมื่อเจอ input ที่เป็นข้อยกเว้น
• Rule 5: Iterate and Refine / ทำซ้ำและขัดเกลา
  • หากผลลัพธ์แรกที่ AI ให้มายังไม่น่าพอใจ อย่าปล่อยผ่าน ให้ ลองใหม่หรือรีแฟกเตอร์ต่อ
  • vibe coding เป็น กระบวนการแบบวนซ้ำที่ขับเคลื่อนด้วยบทสนทนา
  • เช่น:
    • “ช่วยทำโค้ดนี้ให้กระชับกว่านี้”
    • “ช่วยแยกเป็นฟังก์ชันเล็กๆ” เป็นต้น โดยปรับ prompt ใหม่
  • หรือจะรีแฟกเตอร์เอง → หาจุดที่ต้องแก้ → prompt ใหม่ → วนซ้ำ
  • กลยุทธ์การทำงานเป็นรอบๆ ร่วมกับ AI แบบนี้มีประสิทธิภาพมาก
• Rule 6: Know When to Say No / ต้องรู้ว่าเมื่อไรควรปฏิเสธ
  • vibe coding ไม่ใช่คำตอบที่ดีที่สุดเสมอไป
  • หากเป็นงานออกแบบสำคัญหรือสถานการณ์ที่เกี่ยวข้องกับความปลอดภัย การเขียนเองมักดีกว่า
  • เช่น:
    • โมดูลด้านความปลอดภัยควรออกแบบเอง แล้วใช้ AI แค่บางส่วน
    • ถ้า AI ตอบปัญหาง่ายๆ ออกมาอย่างซับซ้อนเกินไป เขียนเองอาจเร็วกกว่า
  • เมื่อ AI แก้ปัญหาไม่ได้จริง อย่าดื้อใช้ต่อ ให้สลับกลับไปโหมดทำเอง
  • “เพราะ AI ทำให้” ไม่ใช่ข้ออ้างว่าเราจะไม่ต้องเข้าใจโค้ดของตัวเองก็ได้
• Rule 7: Document and Share Knowledge / ทำเอกสารและแบ่งปันความรู้
  • โค้ดที่ AI สร้างก็ต้อง มีเอกสารประกอบพอๆ กับโค้ดที่เขียนเอง (และบางครั้งอาจต้องมากกว่า)
  • หากมีการตัดสินใจที่ไม่ตรงไปตรงมาหรือการนำไปใช้ที่ผิดไปจากปกติ ต้องใส่คอมเมนต์ไว้
  • ต้องสื่อสารให้เพื่อนร่วมทีมทราบอย่างชัดเจนว่าส่วนไหนเป็นโค้ดที่ AI สร้าง
  • บางทีมจะ เก็บ prompt ที่ใช้กับโค้ด AI สำคัญไว้ตามเดิม → ช่วยเรื่องดีบักได้มาก

• ด้วยการทำตามกฎเหล่านี้ ทีมจะใช้ประโยชน์จาก productivity ของ vibe coding ได้สูงสุด พร้อมกับ ลดความเสี่ยงให้ต่ำที่สุด
• หัวใจสำคัญคือ AI ไม่ได้มาแทนมนุษย์ แต่ เข้ามาเสริมกัน
• AI เร่งงานซ้ำๆ ส่วนมนุษย์รับหน้าที่ด้าน การคิดเชิงวิพากษ์และความคิดสร้างสรรค์
• เรากำลังอยู่ในยุคที่มนุษย์และ AI ร่วมกันสร้างโค้ด (co-create)

กรณีที่ vibe coding ทำงานได้ดี vs กรณีที่พังไม่เป็นท่า

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

• 👍 สถานการณ์ที่ได้ผลดี (Great Use Cases)
  • Rapid prototyping (การทำต้นแบบอย่างรวดเร็ว)
    → คือจุดที่ vibe coding โดดเด่นที่สุด เมื่อมีไอเดียแอปหรือฟีเจอร์ขนาดเล็ก
    → สามารถใช้ AI assistant เพื่อสร้าง proof of concept หรือต้นแบบได้อย่างรวดเร็ว
    → โค้ดจะยังไม่เนี้ยบนักก็ไม่เป็นไร — หัวใจสำคัญคือ การตรวจสอบไอเดีย
    → มีหลายกรณีที่ใช้ AI เพียงอย่างเดียวสร้างแอปในโปรเจ็กต์ช่วงสุดสัปดาห์แล้วทดสอบแนวคิด
  • One-off scripts / Internal tools (สคริปต์ใช้ครั้งเดียว, เครื่องมือภายใน)
    → เช่น การ parse ไฟล์ล็อก, ทำงานส่วนตัวให้เป็นอัตโนมัติ, แดชบอร์ดภายใน
    → ในสภาพแวดล้อมที่แม้ล้มเหลวก็ไม่ได้มีความเสี่ยงสูง vibe coding ช่วยประหยัดเวลาได้อย่างมีประสิทธิภาพ
    → ในสถานการณ์ที่ไม่ต้องการคุณภาพระดับ production ก็สามารถสร้างสิ่งที่ “ใช้ได้ทันที” ได้อย่างรวดเร็ว
  • Learning and exploration (การเรียนรู้และการทดลอง)
    → เวลาเรียนภาษาใหม่หรือ API ใหม่ สามารถขอให้ AI สร้างตัวอย่างให้ได้
    → แม้จะไม่ใช่โค้ดที่สมบูรณ์แบบ ก็ยังเพียงพอในฐานะสื่อสำหรับการเรียนรู้
    → ให้ความรู้สึกเหมือนมี TA เสมือนจริง ที่ลองหลายแนวทางให้ดู แล้วให้มนุษย์นำไปขัดเกลาต่อ
  • Boilerplate-heavy tasks (งานที่มี boilerplate จำนวนมาก)
    → ตัวอย่าง: สร้าง data class ที่คล้ายกัน 10 ตัว, ทำ CRUD
    → หากโครงสร้างชัดเจน AI สามารถทำตามแพตเทิร์นที่ซ้ำ ๆ ได้อย่างแม่นยำ
    → ช่วยให้งานเชิงกลไกผ่านไปได้อย่างรวดเร็ว และให้มนุษย์ไปโฟกัสกับส่วนที่สำคัญกว่า
• 👎 สถานการณ์ที่เกิดปัญหาได้ (Not-So-Great Use Cases)
  • Enterprise software / Complex systems (ซอฟต์แวร์ระดับองค์กร, ระบบที่ซับซ้อน)
    → ระบบที่มี business logic ซับซ้อน, concurrency, security และข้อกำหนดด้าน compliance
    → AI จะไม่รู้เงื่อนไขเหล่านั้นหากไม่ได้บอกไว้อย่างชัดเจน และแม้รู้ก็อาจสะท้อนไปในผลลัพธ์ได้ไม่เพียงพอ
    → ตัวอย่าง: ระบบชำระเงินฟินเทค, ซอฟต์แวร์ควบคุมอากาศยานและอวกาศ ไม่ควรปล่อยให้ AI จัดการเพียงลำพังโดยเด็ดขาด
    → ในสภาพแวดล้อมแบบนี้ AI ช่วยได้เพียงบางส่วน และคุณภาพสุดท้ายยังต้องพึ่งพา QA และความเชี่ยวชาญของมนุษย์
  • Long-term maintainability (การดูแลรักษาในระยะยาว)
    → สำหรับ codebase ที่จะอยู่ต่อไปอีกหลายปี โครงสร้างตั้งแต่ต้นเป็นเรื่องสำคัญ
    → โค้ดที่สร้างแบบปะผุด้วย AI มัก ขาดความสม่ำเสมอ และกลายเป็นภาระหนักในการดูแลต่อ
    → สู้ใช้เวลาตั้งแต่ช่วงแรกเพื่อวาง framework และการออกแบบที่ชัดเจน จะดีกว่า
    → ผู้ใช้ยุคแรกจำนวนมากแชร์ประสบการณ์ว่า เวลาที่ประหยัดได้จาก vibe coding
    สุดท้ายต้อง จ่ายคืนไปกับการ refactor และเก็บงานในภายหลัง
  • Critical algorithms / Optimizations (อัลกอริทึมสมรรถนะสูงหรืองาน optimization)
    → ตัวอย่าง: การจัดการหน่วยความจำแบบ custom, อัลกอริทึมเรียงลำดับความเร็วสูงมาก
    → AI อาจทำได้โอเคกับอินพุตขนาดเล็ก แต่ยังขาดการคำนึงถึงเรื่องการ scale
    → อาจช้าลงหรือทำงานผิดพลาดโดยไม่มีสัญญาณเตือน
    → ส่วนงานลักษณะนี้ยังคงต้องการ ความคิดสร้างสรรค์และความเข้าใจเชิงลึกของมนุษย์
  • Explainability and clarity (ความชัดเจนและความสามารถในการอธิบาย)
    → ในสถานการณ์ที่โค้ด ต้องอ่านเข้าใจได้ชัดเจนสำหรับนักพัฒนาคนอื่นหรือผู้ตรวจสอบ
    → หาก AI ทำ abstraction มากเกินไปหรือใช้วิธีที่ซับซ้อนเกินจำเป็น จะทำให้ ความอ่านง่ายและการดูแลรักษาลดลงอย่างมาก
    → ปัจจุบัน AI ไม่ได้มุ่งไปที่ “โค้ดสั้น กระชับ” เสมอไป → บางครั้ง verbose เกินไปหรือทำ abstraction โดยไม่จำเป็น
    → ในกรณีแบบนี้ จำเป็นต้องมีการ refactor และการเขียนโค้ดให้ชัดเจนโดยมนุษย์
• สรุปคือ vibe coding เป็นเครื่องมือเร่งความเร็วที่ทรงพลัง แต่ไม่ใช่ยาวิเศษแก้ได้ทุกอย่าง

• มันมีประสิทธิภาพมากในงานที่ความเร็วสำคัญ และผลลัพธ์สามารถแก้ซ้ำได้หลายรอบ
• ในทางกลับกัน การ โยนซอฟต์แวร์ที่ mission-critical ให้ AI ทำครั้งเดียวจบเป็นความเสี่ยง
• ถ้าจะเปรียบเทียบก็คือ: ให้คนขับรถแข่งไปขับรถโรงเรียน — เป็นเครื่องมือที่ดี แต่ใช้ผิดงาน

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

บทสรุป: vibe อย่างระมัดระวัง – สนุกกับความเร็ว แต่อย่าทิ้งความประณีตแบบช่างฝีมือ

• vibe coding และการพัฒนาซอฟต์แวร์ด้วย AI หมายถึงการก้าวกระโดดครั้งใหญ่ของวิวัฒนาการด้านเครื่องมือ
• กระแสนี้ ไม่ใช่แฟชั่นชั่วคราว แต่เป็นความจริงที่ปักหลักแล้ว และจะยิ่งประณีตขึ้นในอนาคต
• ทีมวิศวกรรมที่มองไปข้างหน้าไม่ควรเมินเฉยต่อเรื่องนี้
• เช่นเดียวกับที่เครื่องมืออัตโนมัติหรือ framework ระดับสูงในอดีตเคยแซงแนวทางพัฒนาแบบเดิม
  ทีมที่ใช้ AI ได้ดีมีแนวโน้มสูงที่จะเหนือกว่าทีมที่ไม่ใช้
• ข้อความของบทความนี้ไม่ใช่การปฏิเสธ vibe coding —
  → แต่คือการ เข้าหามันอย่างมีสติ โดยยังรักษาพื้นฐานของวิศวกรรมเอาไว้

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

• แนวทางปฏิบัติสำหรับผู้นำด้านเทคโนโลยีและผู้จัดการ:
  → ต้องปลูกฝังวัฒนธรรมในทีมว่า AI คือ เครื่องมือที่ต้องใช้อย่างมีความรับผิดชอบ
  • สนับสนุน vibe coding ได้ แต่ก็ต้องตั้ง ความคาดหวังและกติกาที่ชัดเจนเพื่อปกป้อง codebase ไปพร้อมกัน
  • โค้ดที่ AI สร้างก็ต้องถูกนำเข้าสู่กระบวนการ code review เสมอ
    • และสร้างวัฒนธรรมที่คำถามว่า “เข้าใจโค้ดนี้ไหม?” เป็นเรื่องธรรมชาติ
  • ลงทุนในการยกระดับทักษะเพื่อให้ทั้งทีม ร่วมงานกับ AI ได้อย่างมีประสิทธิภาพ
    • เช่น ทักษะการเขียน prompt ที่ดี วิธีประเมินข้อเสนอจาก AI และชุดทักษะใหม่อื่น ๆ
  • นี่คือการเปลี่ยนผ่านเชิงกระบวนทัศน์แบบเดียวกับการเปลี่ยนไปใช้ภาษาระดับสูงหรือการนำ Git มาใช้ในอดีต
    → ทีมที่ปรับตัวได้เร็วจะได้เปรียบ

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

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

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

• ทีมที่ซึมซับหลักการนี้ได้ จะไม่ได้แค่ทำงานเร็วขึ้นเท่านั้น
  → แต่จะสามารถสร้าง ซอฟต์แวร์ที่มีคุณค่าพอจะอยู่รอดได้ยาวนาน

> Happy coding — และ ให้ vibe สูง แต่คุณภาพต้องสูงกว่า.

[tested]

+1
เห็นด้วยครับ

[iolothebard]

คำเตือน: เนื้อหายาวมาก

[GN⁺]

ความเห็นจาก Hacker News

• มีการนิยามความหมายของ "vibe coding" ใหม่

  • ทวีตต้นฉบับพูดถึงการยอมรับโค้ดที่ AI สร้างขึ้นโดยไม่สนใจคุณภาพ และถ้าผลลัพธ์ไม่เป็นไปตามต้องการก็สุ่มลองใหม่ไปเรื่อย ๆ
  • สงสัยว่าตอนนี้ผู้คนใช้คำนี้ในความหมายว่า "มอบหมายงานวงกว้างให้ AI agent" หรือไม่

• กระแส hype เรื่อง AI coding สูงเกินไปจนรู้สึกว่าในทางปฏิบัติไม่สามารถทำได้ตามที่คาดหวัง

  • เคยมอบหมายการเขียน unit test สำหรับ codebase ที่ซับซ้อนให้แอป AI coding แต่ล้มเหลวถึง 80%
  • นักพัฒนามนุษย์ที่มีประสบการณ์ยังสามารถใช้สิ่งนี้เป็นจุดตั้งต้นได้ และช่วยลดงานซ้ำ ๆ
  • ตอนนี้ AI มีประโยชน์ในการเร่งงานที่ทำซ้ำ แต่ยังแทนที่นักพัฒนามนุษย์ไม่ได้

• ทำให้นึกถึงช่วงต้นทศวรรษ 2000 ที่บริษัทยักษ์ใหญ่พยายาม outsource งานพัฒนาไปยังประเทศรายได้ต่ำ

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

• การปฏิบัติต่อ AI เหมือนเป็นนักพัฒนาระดับ junior ในทีมอาจใช้เวลามากกว่าเดิม

  • โค้ดที่ AI สร้างขึ้นดูเหมือนน่าเชื่อถือ แต่ในความเป็นจริงอาจมีปัญหา จึงต้องระวัง

• ขึ้นอยู่กับ use case

  • ในฐานะ consultant ส่วนใหญ่ทำงานด้าน business process automation และการเชื่อมต่อระบบคลาวด์
  • การทำงานร่วมกับ AI agent กลายเป็น game changer และทำให้โฟกัสกับการเขียนข้อกำหนดทางเทคนิคและ code review ได้
  • ทำให้ทำอะไรได้มากขึ้นภายใต้งบประมาณจำกัด และคุณภาพของผลลัพธ์ก็ดีขึ้นมาก

• มีมุมมองที่หลากหลายเกี่ยวกับคุณภาพซอฟต์แวร์

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

• มีคำถามว่า AI-assisted coding จะส่งผลลบต่อการเติบโตของนักพัฒนาหรือไม่

  • สงสัยว่าในระยะยาวความต้องการนักพัฒนาจะเพิ่มขึ้น หรือในระยะสั้นจะลดลง

• ใช้ vibe coding เพื่อประเมินความยากของงาน

  • สร้าง prototype และทดสอบไลบรารีเพื่อดูว่าสามารถแก้ปัญหาได้หรือไม่
  • บางครั้ง LLM ก็แนะนำพารามิเตอร์หรือฟังก์ชันที่ผิด แต่ก็ยังช่วยประหยัดเวลาได้

• ผู้คนมีแนวโน้มจะประหยัดพลังงาน และ vibe coding ทำให้การพัฒนาแบบลงแรงน้อยเป็นไปได้

  • ไม่เหมาะกับโปรเจ็กต์สำคัญ แต่ก็อาจมีประโยชน์กับโปรเจ็กต์ส่วนตัว

• ทั้งบทความดูเหมือนเป็นการขยายความประโยคที่ว่า "มนุษย์ควรตรวจทานก่อนนำ vibe code ไป deploy ขึ้น production"