เราต้องหยุดเรียกทุกอย่างว่า Vibe Coding

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

ความแตกต่างไม่ได้อยู่ที่เครื่องมือ หรือปริมาณโค้ดที่ AI เขียนให้คุณ. มันเกี่ยวกับสัญญาที่คุณรับกับผลลัพธ์ของคุณ: ว่าคุณสามารถอธิบายสิ่งที่คุณเพิ่งปล่อยสู่โลกได้หรือไม่ได้

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

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

วิธีที่ “Vibe Coding” สูญเสียความหมาย

คำว่า “vibe coding” ถูกตั้งขึ้นในเดือนกุมภาพันธ์ 2025 โดย Andrej Karpathy ผู้ร่วมก่อตั้ง OpenAI ตัวอย่างของเขาถูกตั้งใจให้ดูสบาย ๆ: โครงการสุดสัปดาห์ที่ทำแบบ “ทิ้งไว้” โดยกด “Accept All” อัตโนมัติ ไม่สนใจความแตกต่างและให้โค้ดเติบโตเกินกว่าที่เขาเข้าใจ

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

สิ่งที่บ่งบอกคือ Karpathy ในที่สุดก็ยอมรับ ความเห็นนั้น ปีหนึ่งต่อมา เขาแนะนำคำใหม่ สำหรับงานที่มีวินัยมากขึ้นกับเอเจนต์โค้ด เขาอธิบาย “agentic engineering” ว่าเป็นกระบวนการทำงานที่นักพัฒนากำหนดและดูแลเอเจนต์ แทนที่จะยอมรับสิ่งที่พวกมันสร้าง ความแตกต่างนี้สำคัญ: การพัฒนาที่ได้รับความช่วยเหลือจาก AI อย่างมืออาชีพต้องการการวางแผน, การตรวจสอบและความรับผิดชอบในแบบที่ Vibe coding อย่างสบาย ๆ ไม่ได้มี

เส้นแบ่งคือความรับผิดชอบ

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

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

ดังนั้น ประสบการณ์เพียงอย่างเดียวไม่อธิบายทั้งหมด มันเกี่ยวกับการที่คุณพร้อมจะรับผิดชอบต่อสิ่งที่ AI สร้าง นั่นคือการตัดสินใจที่นักพัฒนาต้องทำซ้ำ ๆ ในทุกโครงการ

อะไรจะเกิดขึ้นเมื่อการควบคุมหายไป

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

ปัญหาเดียวกัน – ซอฟต์แวร์ดูทำงานได้แต่ตรรกะการอนุญาตยังผิดพลาดอย่างอันตราย – ปรากฏในแอปที่สร้างบนแพลตฟอร์ม Lovable: การวิจัยด้านความปลอดภัยพบว่าตรรกะการอนุญาตถูกกลับด้าน ทำให้ผู้ใช้ที่ล็อกอินถูกล็อกเอาไว้ แต่ผู้โจมตีที่ไม่ได้รับอนุญาตสามารถเข้าถึงได้อย่างอิสระ ส่งผลกระทบต่อผู้ใช้กว่า 18,000 ราย รวมถึงนักเรียน

นี่ไม่ใช่กรณีแยกที่เกิดกับโครงการ “แย่” เท่านั้น ตามรายงาน DORA ของ Google ในปี 2025 90% ของนักพัฒนาตอนนี้ใช้ AI ในงาน และประมาณหนึ่งในสามรายงานว่ามีความเชื่อมั่นน้อยหรือไม่มีต่อสิ่งที่ AI สร้าง

การใช้ AI ตอนนี้แพร่หลาย แม้ว่าความเชื่อมั่นยังจำกัด และนั่นทำให้การตรวจสอบอย่างรอบคอบเป็นสิ่งสำคัญโดยเฉพาะเมื่อโค้ดที่สร้างมาจัดการการรับรองตัวตน, สิทธิ์ หรือข้อมูลที่ละเอียดอ่อน

การควบคุมถูกสร้างเป็นชั้น ๆ ไม่ได้ทำทั้งหมดพร้อมกัน

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

กระบวนการทำงานของฉันกลายเป็นโครงสร้างมากขึ้นเมื่อโครงการมีความสำคัญมากขึ้น แทนที่จะพึ่งพา prompt เพียงอย่างเดียว ฉันเริ่มเตรียมสเปคก่อนสร้างอะไรเลย ฉันบันทึกความต้องการทางธุรกิจ, stack เทคโนโลยีและการบูรณาการ จากนั้นจึงเขียน unit test และ Playwright test สำหรับเส้นทางผู้ใช้หลัก

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

นิสัยนั้นทำให้พบปัญหาในโครงการหนึ่ง AI นำไลบรารีที่ไม่เข้ากันกับเวอร์ชันของเฟรมเวิร์คที่ฉันใช้เข้ามา แอปไม่ได้ล่มโดยตรง ดังนั้นความไม่เข้ากันอาจไม่ถูกสังเกตได้ หากพบภายหลังจะทำให้สาเหตุยากต่อการระบุ

เมื่อเทียบกับกรณี Tea และ Lovable นี้เป็นปัญหาธรรมดา ฉันพบเร็ว แก้ไขและเดินต่อ นั่นคือสิ่งที่การตรวจสอบมักเป็นในทางปฏิบัติ ส่วนใหญ่แล้วมันป้องกันปัญหาเล็ก ๆ จากการเติบโตเป็นปัญหาใหญ่

ฉันไม่สงสัยในโค้ดเพียงเพราะ AI สร้างมัน ฉันก็ไม่เชื่อมั่นในโค้ดเพียงเพราะแอปทำงาน การทดสอบและการตรวจสอบคือวิธีที่ฉันยืนยันว่ามันทำงานตามที่ตั้งใจ

จาก Vibe Coding ไปสู่ Agentic Engineering

การย้ายของ Karpathy จาก “vibe coding” ไปสู่ “agentic engineering” ไม่ได้เป็นแค่การเปลี่ยนคำศัพท์ “Agentic engineering” ให้เรามีชื่อที่มีประโยชน์มากขึ้นสำหรับทิศทางของการพัฒนามืออาชีพ นักพัฒนาจะเขียนโค้ดน้อยลงเอง แต่ความรับผิดชอบไม่ลดลง มันเปลี่ยนงานของพวกเขาไปสู่การกำหนดว่าระบบควรทำอะไร, ควบคุมเอเจนต์, ทดสอบผลลัพธ์และตัดสินใจว่าอะไรปลอดภัยที่จะปล่อย

อันตรายไม่ได้อยู่ที่ AI สร้างโค้ดเร็วเกินไป. เมื่อการสร้างเร็วเกินกว่าที่เราจะเข้าใจ ผลผลิตที่ดูเหมือนมีประสิทธิภาพอาจซ่อนความเสี่ยงที่ไม่มีใครตรวจสอบอย่างถ้วนถี่

กฎที่ควรเก็บไว้

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

AI อาจเขียนโค้ดส่วนใหญ่ แต่ไม่สามารถรับผิดชอบต่อการปล่อยมันได้ สิ่งนั้นยังคงเป็นความรับผิดชอบของเรา