ถ้าจะทำ vibe coding ทำไมไม่ทำด้วย C ล่ะ?
(stephenramsay.net)- vibe coding ใช้งานได้ผลดีจริง แต่ก็ทำให้เกิดโค้ดที่แม้แต่ผู้เขียนเองก็ไม่เข้าใจทั้งหมด จนทำให้ ความสนุกที่เป็นแก่นแท้ของการเขียนโปรแกรม ลดลง
- ภาษาโปรแกรมทุกภาษาคือ เครื่องมือที่ออกแบบมาเพื่อความสะดวกของมนุษย์ ไม่ใช่ของเครื่องจักร และข้อดีอย่างความปลอดภัย การทำ abstraction และความอ่านง่าย ก็ล้วนเป็นโครงสร้างเพื่อช่วยให้มนุษย์คิด
- ถ้าอย่างนั้น โค้ดที่ AI เขียนยังจำเป็นต้องใช้ภาษาที่เป็นมิตรกับมนุษย์หรือไม่? ผู้เขียนจึงเสนอ VOPL (Vibe-Oriented Programming Language) ซึ่งเป็นภาษาใหม่ที่เป็นมิตรกับเครื่องจักรและมี AI เป็นศูนย์กลาง
- ภาษานี้อาจมีได้หลายรูปแบบ เช่น pseudocode ที่รันได้จริง การขยายแนวคิดของ literate programming หรือรูปแบบที่อิงภาษาธรรมชาติแต่มีไวยากรณ์เฉพาะ
- เช่นเดียวกับช่วงเริ่มต้นของคอมพิวเตอร์แบบ stored-program การต่อต้านกระบวนทัศน์การคำนวณแบบใหม่คือประวัติศาสตร์ที่เกิดซ้ำ และ vibe coding อาจเป็นขั้นถัดไปของกระแสนั้น
ความตึงเครียดระหว่างการเขียนโปรแกรมกับ vibe coding
- สำหรับผู้เขียน การเขียนโปรแกรมคือ ความสนุก ไม่ใช่งาน และเป็นสิ่งที่หลงใหลมาตั้งแต่ปลายทศวรรษ 1990
- สอนการเขียนโปรแกรมมา 25 ปี และสิ่งที่ภูมิใจที่สุดคือ การเปลี่ยนคนที่ไม่ได้เรียนสายนี้ให้กลายเป็นโปรแกรมเมอร์
- เวลาที่เขียนโปรแกรม ผู้เขียนให้ความสำคัญกับ ความสุขจากการได้เข้าใจด้วยตัวเองระหว่างกระบวนการแก้ปัญหา
- แต่ vibe coding คือกระบวนการที่ AI เขียนโค้ดแทน จนทำให้ผู้เขียนโปรแกรมอาจอยู่ในสภาพที่ไม่เข้าใจผลลัพธ์ทั้งหมด
- มันให้ความรู้สึกเหมือน “โกง” อยู่บ้าง (แม้จะไม่ใช่แค่นั้น) และชวนให้รู้สึกขัดใจในแบบที่อธิบายได้ยาก
- ดูเหมือนว่าจะ พรากความสนุกของการเขียนโค้ดไปมากทีเดียว
- ถึงอย่างนั้น vibe coding ก็ ทำงานได้ดีพอจะสร้างระบบจริงที่มีคุณภาพสูงได้
- ไม่ได้เป็นแค่การแทนการค้นหา แต่ยังแก้ปัญหาที่เราไม่อยากลงมือเองได้อย่างแม่นยำ
- AI เก่งกว่ามนุษย์ในการไล่หาข้อผิดพลาดและจัดการหน่วยความจำ และผู้เขียนก็ยังประหลาดใจกับผลลัพธ์ที่ได้เมื่อโยนไอเดียโปรแกรมให้ AI อยู่ซ้ำๆ
ภาษาเดิมทีเป็นเครื่องมือสำหรับมนุษย์
- อย่างที่ Abelson & Sussman กล่าวไว้ใน Structure and Interpretation of Computer Programs ภาษาโปรแกรมคือสื่อกลางในการแสดงออกสำหรับมนุษย์
- โค้ดคือ “สิ่งที่เขียนให้อ่านโดยมนุษย์” และเครื่องจักรไม่ได้ต้องการความอ่านง่าย
- ภาษาโปรแกรมทุกภาษาได้รับการออกแบบให้เป็น สื่อที่ช่วยการคิดและการแสดงออกของมนุษย์
- ความปลอดภัยของ Rust, abstraction ของ C++, concurrency ของ Go ล้วนเป็น ความสามารถที่มีไว้เพื่อความสะดวกของมนุษย์ ไม่ใช่ของเครื่องจักร
- การจัดการหน่วยความจำ concurrency และ type safety ก็เป็นเพียง abstraction ที่ช่วยโครงสร้างการคิดของมนุษย์
- ดังนั้น ในยุคที่ AI เป็นผู้เขียนโค้ด การออกแบบภาษาแบบมนุษย์เป็นศูนย์กลางอาจไม่จำเป็นอีกต่อไป
ถ้าอย่างนั้น AI ต้องการภาษาลักษณะนี้ไหม? : ความหมายของข้อเสนอ “ทำ vibe coding ด้วย C”
- เมื่อทำ vibe coding มนุษย์ก็เขียนโปรแกรมในสภาพที่ ไม่ได้เข้าใจโค้ดทั้งหมดอย่างสมบูรณ์อยู่แล้ว
- ในสถานการณ์แบบนี้ เหตุผลที่จะคงไวยากรณ์ที่เป็นมิตรกับมนุษย์ไว้ก็อ่อนลง
- แทนที่จะใช้ภาษาที่เป็นมิตรกับมนุษย์ การเขียนตรงด้วย ภาษาที่เป็นมิตรกับเครื่องจักร (เช่น C หรือ assembly) อาจสมเหตุสมผลกว่า
- AI สามารถจัดการเรื่อง undefined behavior, การคืนหน่วยความจำ และ off-by-one ของ C ได้ ละเอียดกว่ามนุษย์
- คล้ายกับที่คอมไพเลอร์ทำ optimization ได้ดีกว่า มันแสดงให้เห็นถึง ความสามารถในการควบคุมการทำงานของโค้ดได้แม่นยำกว่ามนุษย์
- ดังนั้นจึงเกิดคำถามว่า เราควรมีภาษาที่เหมาะกับการใช้งานของ AI มากกว่านี้หรือไม่?
- ทำไมเรายังต้อง vibe coding ด้วยภาษาแบบ “มนุษย์เป็นศูนย์กลาง” อย่าง Python, Rust หรือ C++ อยู่ด้วย?
ข้อเสนอ VOPL (Vibe-Oriented Programming Language)
- ถ้าจะสร้างภาษาที่ตั้งอยู่บนสมมติฐานของ vibe coding ก็อาจจินตนาการถึงความเป็นไปได้แบบนี้
- ภาษา ระดับสูงมาก ที่ใกล้เคียงกับ pseudocode ที่รันได้จริง
- คล้าย literate programming เวอร์ชันสมบูรณ์ ที่ มนุษย์มีหน้าที่บรรยาย ส่วน AI สร้าง machine code
- โครงสร้างที่ดูเหมือนภาษาธรรมชาติ แต่มี “สำนวนเฉพาะ” บางอย่าง
- แนวคิดอย่างการแสดง concurrency ด้วย คำพูดในชีวิตประจำวัน (slang) แทนคำอย่าง
goroutine
- ทิศทางคือการออกแบบ ระบบการแสดงออกที่ยึดเครื่องจักรเป็นศูนย์กลาง เพื่อให้ AI เข้าใจปัญหาได้แม่นยำและสร้างโค้ดที่รันได้อย่างรวดเร็ว
- แม้จะมีปัญหาเรื่องการสอนภาษาใหม่ให้ AI แต่ปัจจุบันนักพัฒนาจำนวนมากก็โยน pseudocode ให้ AI แล้วคุยกันจนได้โค้ดอยู่แล้ว
จึงเป็นไปได้ว่า VOPL ในรูปแบบใดรูปแบบหนึ่งอาจกำลังถูกเรียนรู้อยู่แล้ว
การเปลี่ยนแปลงของการเขียนโปรแกรมในฐานะกิจกรรม
- “การเขียนโค้ดด้วยมือ” อาจถูกมองในอนาคตของการสอน vibe coder ว่าเป็น การศึกษาพื้นฐานแบบมอนเตสซอรี
- คล้ายกับการฝึกวาดรูปด้วยมือก่อนยุค Photoshop หรือการฝึกแก้สมการบนกระดาษที่ยังคงอยู่ในหลักสูตรแม้จะเข้าสู่ยุคเครื่องคิดเลขอิเล็กทรอนิกส์แล้ว
- การต่อต้านการมาถึงของกระบวนทัศน์ใหม่เกิดซ้ำมาตลอดในประวัติศาสตร์
- ตัวอย่างการต่อต้านในช่วงแรกของการนำคอมพิวเตอร์แบบ stored-program มาใช้ (ENIAC → EDVAC)
- แม้แต่ Grace Hopper เองก็เคยต้องต่อสู้กับคำวิจารณ์ที่ว่า “เครื่องจักรไม่สามารถเขียนคำสั่งให้เครื่องจักรได้”
ข้อความสรุป
- vibe coding คือความจริงแล้วในวันนี้ และอนาคตของการพัฒนาอาจเรียกร้องให้ ออกแบบภาษาใหม่ทั้งระบบ
- จากยุคของภาษาที่มนุษย์เป็นศูนย์กลาง ตอนนี้อาจถึงเวลาที่ต้องพูดกันอย่างจริงจังถึง ความเป็นไปได้ของการเปลี่ยนผ่านไปสู่ภาษาที่มี AI เป็นศูนย์กลาง
“Same vibe, as the kids say.” — ถ้าพูดแบบวัยรุ่นสมัยนี้ก็คือ vibe เดียวกันนั่นแหละ
4 ความคิดเห็น
จะโค้ดแบบ vibe coding ทั้งทีก็ทำด้วย C ไปเลยสิ?
การเชื่อว่าพอโค้ดด้วยโมเดลภาษาแล้วมันจะเสกการแสดงออกที่ใกล้เครื่องขึ้นมาให้เองอย่างกับเวทมนตร์นี่มันความคิดแบบอยากได้ของฟรีชัดๆ
ยิ่งมีข้อจำกัด งานก็ยิ่งออกมาดีได้ภายในข้อจำกัดนั้น
ถึง AI จะเป็นคนเขียนโค้ดให้ แต่ความรับผิดชอบต่อบริการก็ควรเป็นของนักพัฒนาอยู่ดีนะครับ/คะ เลยสงสัยว่าจะรับผิดชอบต่อโค้ดที่ตัวเองไม่เข้าใจได้จริงหรือเปล่า
"แม้จะทำ vibe coding ก็เถอะ แต่ถ้าอยากตรวจทานผลลัพธ์ได้ ก็ควรทำด้วยภาษาที่ตัวเองรู้จักดี"
ในคอมเมนต์มีประโยคที่สำคัญมากอยู่ครับ
ความคิดเห็นจาก Hacker News
ยิ่งรู้สึกชัดอีกครั้งว่างานสายพัฒนาซอฟต์แวร์นั้น หลากหลายมาก
ผมทำงานฝั่งแบ็กเอนด์ โดยเฉพาะการพัฒนา API และคอขวดด้านประสิทธิภาพที่ใหญ่ที่สุดคือคนส่วนมาก นิยามความต้องการได้ไม่ชัดเจน
พอไปถาม PM ก็มักเลี่ยงตอบ ส่วนฝั่งฟรอนต์เอนด์ก็นั่งรอให้แบ็กเอนด์ส่ง API มา
สุดท้ายสิ่งที่ยากที่สุดไม่ใช่การเขียนโค้ด แต่คือ กระบวนการคิดในการค้นหาและตีความความต้องการ
การเขียนโปรแกรมที่แท้จริงคือการนำระบบที่ตัวเองออกแบบไว้ไปสร้างให้มีชีวิตขึ้นมา
ถ้าเข้าใจผิดว่าการนั่งเขียนโค้ดในบริษัทคือ ‘Programming’ ทั้งหมด ก็ย่อมเกิดความเข้าใจคลาดเคลื่อนได้
แต่ดูเหมือนเขาอาจไม่มีประสบการณ์พัฒนาซอฟต์แวร์เชิงพาณิชย์ขนาดใหญ่มากนัก
คำทำนายเรื่อง “อนาคตของการเขียนโปรแกรม” ของเขาฟังดูดี แต่ในบริบทอุตสาหกรรมอาจมีข้อจำกัดอยู่บ้าง
(อ้างอิง: แนะนำ Stephen Ramsay)
สุดท้ายสิ่งสำคัญคือ กรอบความคิด และการได้สัมผัสเทคโนโลยีมากแค่ไหน
LLM ช่วยเพิ่มประสิทธิภาพให้ผมได้มาก โดยเฉพาะกับคนอย่างผมที่มี วิธีคิดเชิงสถาปัตยกรรม
สิ่งที่เมื่อก่อนใช้เวลาหลายเดือน ตอนนี้ทำเสร็จได้ในไม่กี่ชั่วโมง
ช่วงนี้ผมใช้ LLM แปลโค้ด Shockwave Lingo เก่า ๆ ไปเป็นภาษาสมัยใหม่เพื่อ กู้เกมเลกาซี กลับมา
ถ้าเราบอกว่า vibe coding คืออนาคต ก็เท่ากับยอมรับอยู่แล้วว่า AI ยังไม่สมบูรณ์
พอเราไปกำหนดความสามารถกับข้อจำกัดของ AI ตามจินตนาการ การถกเถียงก็จะคลุมเครือทันที
ต้องคุยกับผู้มีส่วนได้ส่วนเสียสี่ห้ารอบกว่าจะชัดเจน
ผมลองทำ vibe coding ด้วย C แล้ว แต่ก็ยังเกลียด C เหมือนเดิม
AI ก็เหมือนคนตรงที่ลืม free memory แล้วค่อยกลับมาแก้ทีหลัง
พอใช้ Rust แล้วสนุกกว่ามาก และการเข้าใจ ecosystem ของ dependencies ของภาษานั้นต่างหากที่เป็นทักษะจริง
AI ช่วยได้ดีในการไล่สำรวจ ‘ความรู้จากตำรา’ แบบนี้อย่างรวดเร็ว
ถ้าเป็น C ต้องคอยเช็กทีละจุดว่ามีการ free memory หรือยัง แต่ Rust แทบไม่ต้องกังวลเรื่องนี้
ต่อให้จะทำ vibe coding ผมก็คิดว่า Rust ที่มี กลไกความปลอดภัย ของภาษานั้นดีกว่ามาก
ความเป็นมิตรต่อมนุษย์ของ Python ก็ช่วย AI ไปด้วย
ตอนนี้เพราะ AI ทำให้การสร้าง UI หรือ utility ขึ้นมาใหม่เองง่ายกว่าเดิมมาก
และการ เขียนเฉพาะส่วนที่ต้องการประสิทธิภาพด้วย C++ ก็กลายเป็นเรื่องง่าย
ถ้าต้อง debug เองด้วย GDB คงเสียเวลามากกว่านี้เยอะ
มันช่วยรับภาระพวกงานน่าหงุดหงิดอย่างการจัดการสตริงหรือพอยน์เตอร์ได้ เลยค่อนข้างพอใจ
โค้ดที่ compiler สร้างมามักมีประสิทธิภาพดีกว่าเสมอ แต่ผมใช้ความผิดพลาดของ AI เป็น โอกาสในการเรียนรู้
ต่อให้เป็น local LLM ก็ยังเอามาช่วยทำ validation เรื่องการ free memory แบบอัตโนมัติได้
ก่อนหน้านี้มีการถกกันเรื่อง “Why AI Needs Hard Rules, Not Vibe Checks”
(ลิงก์)
เหตุผลที่ Rust เหมาะกับ vibe coding ก็เพราะมันมีฟีเจอร์ตรวจสอบฟรีอย่าง การรับประกันเรื่อง type และ lifetime
ถ้าไม่มีการตรวจสอบแบบนี้ LLM ก็สร้าง โค้ดที่ไม่ปลอดภัย ได้ง่ายมาก
การทำ abstraction ไม่ได้จำเป็นแค่กับมนุษย์ แต่จำเป็นกับ LLM ด้วย
เป็นภาษาที่ทุกฟังก์ชัน ตัวแปร type และ exception ต้องถูก ระบุสเปกอย่างเข้มงวด
อาจเขียนลำบาก แต่จะเป็นโครงสร้างที่อ่านและตรวจสอบได้ง่าย
มันพูดถึงความยากของการแปลที่ต้องรักษา เจตนา ของโค้ดไว้ ไม่ใช่แค่เส้นทางการทำงานตอนรัน
เครื่องมืออย่าง Shellcheck ก็ช่วยให้มือใหม่ทำงานได้ใกล้ระดับผู้เชี่ยวชาญแล้ว
ถ้าจะพัฒนาให้ดีขึ้นด้วย RL ก็ต้องสามารถตัดสินความถูกต้องสอดคล้องของโค้ดแบบอัตโนมัติได้
ถึงเวลาที่ภาษาเชิงตรรกะอย่าง Prolog ควรถูกหยิบกลับมามองใหม่
ถ้า LLM ยังสร้างโค้ดที่บั๊กเยอะ ไม่ว่าภาษาไหนผลลัพธ์ก็คงคล้ายกัน
ตอนแรก vibe coding มันน่าทึ่งมาก แต่ไม่นานก็พบว่า ลูปการแก้ไขไม่จบไม่สิ้น มันกัดกินสติอย่างแรง
มันเหมือนการไถฟีดอัลกอริทึมที่คอยดึงสมาธิออกไปเรื่อย ๆ
ตอนนี้ผมกลับมาเขียนเอง แล้วโยนแค่ส่วนที่น่าเบื่อให้ ChatGPT จัดการ
แถมก็ไม่ได้เรียนรู้อะไรด้วย
วิธีนี้ช่วยทำให้ requirement ชัดขึ้น และย้ายไปใช้ AI ตัวอื่นได้ง่ายด้วย
ผมยังสงสัยว่า LLM จะสร้าง โค้ด C ที่ไม่มี memory leak ได้จริงหรือเปล่า
แม้แต่นักพัฒนามนุษย์ก็ยังพลาดเรื่องนี้กันบ่อย และ LLM ที่เรียนจากข้อมูลคุณภาพต่ำก็ยิ่งเสี่ยงกว่า
ถ้าจะทำโปรแกรมที่ segfault ด้วย vibe coding แบบนี้ มันก็แค่ เสียเวลา
แทบไม่พังและคอมไพล์ผ่านเสมอ
มนุษย์เหนื่อยล้าได้ แต่ LLM ไม่เป็นแบบนั้น
ถ้าเอาโค้ด C ที่ดีมาฝึกซ้ำก็ยังมีช่องให้พัฒนาได้
AI จะหลีกเลี่ยง undefined behavior ใน C ได้งั้นเหรอ? ฟังแล้วยากจะเชื่อ
ถ้าเป็นโมเดลที่ถูกฝึกให้ทำพลาดแบบมนุษย์ มันก็มีโอกาสสร้างบั๊กแบบเดียวกันสูง
เพราะมันคาดเดาโทเค็นที่น่าจะเป็นไปได้มากที่สุด ความผิดพลาดที่พบบ่อยจึงลดลง
และยังหาสาเหตุของ crash ได้เก่งด้วย
ภาษาใหม่อย่าง Zig หรือ Rust ดีกว่ามาก
เหตุผลที่ vibe coding ทำให้ผม รู้สึกไม่สบายใจ ไม่ใช่แค่เพราะมันดูเหมือน ‘การโกง’
การเขียนโปรแกรมคือ ศิลปะที่มีวิญญาณ
แต่ละคนมีวิธีแก้ปัญหาไม่เหมือนกัน และนั่นแหละคือความคิดสร้างสรรค์
vibe coding ให้ความรู้สึกเหมือนเป็นการ ปล่อยให้เครื่องจักรดูดซับความคิดสร้างสรรค์นั้นไป
สุดท้ายทั้งความคิด การตัดสินใจ และความผิดพลาด ล้วนให้เครื่องทำแทนหมด
เคยมีข้อเสนอให้สร้าง “vibe-oriented programming language(VOP)” ขึ้นมา
แต่ถ้าจะทำภาษาเพื่อ LLM จริง ๆ มันควรจะ เข้มงวดและละเอียด มากกว่า
ถ้าไม่ระบุทุกเงื่อนไขและข้อยกเว้นให้ครบ ก็ควรคอมไพล์ไม่ผ่าน
มันอาจไม่สะดวกสำหรับมนุษย์ แต่สำหรับ LLM มันมีข้อดีคือ ช่วยลดความสับสน
เราต้องมีโครงสร้างที่มนุษย์อธิบายแนวคิด แล้ว AI ค่อยแปลงเป็นโค้ด
ถ้าคอมไพล์ผ่านครั้งหนึ่ง มันก็มักจะทำงานได้ถูกต้องแทบตลอด
ต่อให้จะทำ vibe coding ก็ต้องทำใน ภาษาที่ตัวเองรู้จักดี ถ้ายังอยากรีวิวผลลัพธ์ได้
ไม่อย่างนั้นก็อาจจะลองเล่นกับ brainfuck ไปเลยยังจะดีกว่า
พอมีคนถามว่า “งั้นลองทำด้วย x86 assembly ไหม?”
ก็ปฏิเสธไป เพราะ “ผมต้องสามารถรีวิวและต่อยอดมันได้ด้วยตัวเอง”
vibe coding แบบล้วน ๆ เป็นแค่ การทดลองทางความคิด ไม่ใช่เป้าหมายที่ใช้ได้จริง
สักวันหนึ่ง AI อาจรับหน้าที่ QA ได้ด้วย แต่ตอนนี้ ภาษาที่ปลอดภัยและการตรวจทานโดยมนุษย์ ยังจำเป็นอยู่
ตอนนี้ผมเป็นนักพัฒนาที่อยู่มานานจนเริ่มเหนื่อยกับการถกเถียงแบบนี้แล้ว