- แม้จะรู้สึกทึ่งกับการใช้ เครื่องมือเขียนโค้ดด้วย AI และค่อย ๆ มอบหมายงานที่ใหญ่ขึ้นเรื่อย ๆ แต่ก็พบว่าผลลัพธ์ยังขาด ความสม่ำเสมอและความสมบูรณ์เชิงโครงสร้าง
- ต่อให้เขียนสเปกอย่างละเอียด AI agent ก็ยังรักษาบริบทระยะยาวหรือพัฒนาแบบออกแบบต่อเนื่องไม่ได้ จนท้ายที่สุด codebase ทั้งหมดกลายเป็น ชุดของชิ้นส่วนที่ไม่เป็นเนื้อเดียวกัน
- ชิ้นส่วนโค้ดแต่ละส่วนอาจดูสมบูรณ์เมื่อมองแยกกัน แต่โดยรวมกลับเกิด ความยุ่งเหยิงเชิงโครงสร้าง (sloppy) และ การพังทลายของบริบท
- หลังผ่านประสบการณ์เหล่านี้ ผู้เขียนจึง ตัดสินว่าโค้ดที่ AI สร้างไม่สามารถรับประกันความเชื่อมั่นของผู้ใช้หรือการปกป้องข้อมูลได้ และหันกลับไปเขียนโค้ดด้วยตนเอง
- AI coding ยังมีประโยชน์อยู่ แต่ อาจก่อให้เกิด technical debt และการสูญเสียการควบคุมของนักพัฒนา จึงต้องใช้อย่างระมัดระวัง
ความตื่นเต้นในช่วงแรกของ AI coding และการตระหนักถึงข้อจำกัด
- ผู้ใช้ส่วนใหญ่มักเริ่มใช้ AI coding กับงานง่าย ๆ ก่อน แล้วค่อย ๆ มอบหมาย งานที่ซับซ้อนขึ้น พร้อมชื่นชมประสิทธิภาพของมัน
- แต่เมื่อผ่านไประยะหนึ่ง ข้อผิดพลาดและความไม่สม่ำเสมอของ AI จะเริ่มปรากฏ ทำให้เกิดช่องว่างระหว่างความคาดหวังกับความเป็นจริง
- เมื่อผลลัพธ์ไม่เป็นที่พอใจ ผู้ใช้มัก โทษว่าเป็นปัญหาที่ prompt ของตัวเอง และพยายามเขียนสเปกให้ละเอียดมากขึ้น
- แม้จะใช้เครื่องมืออย่าง Obsidian เพื่อเขียนเอกสารสเปกอย่างละเอียด แต่ AI ก็ยังไม่สามารถพัฒนาต่อยอดสิ่งนั้นในระยะยาวได้
ความล้มเหลวของแนวทางที่อิงสเปก
- ในการพัฒนาจริง เอกสารออกแบบคือ “เอกสารมีชีวิต” ที่เปลี่ยนแปลงอย่างต่อเนื่องระหว่างกระบวนการค้นพบและลงมือสร้าง
- แต่ AI agent กลับยึดติดกับสเปกเริ่มต้นจน ไม่สามารถปรับแก้อย่างยืดหยุ่นหรือตีความใหม่ได้
- ระหว่างรับมือกับโครงสร้างที่ซับซ้อน agent มักมีแนวโน้ม สูญเสียบริบททั้งหมดของปัญหา หรือฝืนเดินหน้าต่อแบบไม่สมเหตุสมผล
- ผลคือ แม้โค้ดจะดูสมบูรณ์จากภายนอก แต่กลับขาด ความสอดคล้องภายในและความสมบูรณ์ของโครงสร้าง
การพังทลายของคุณภาพโค้ดและข้อจำกัดของ ‘vibecoding’
- โค้ดที่ AI เขียนขึ้น อาจดูยอดเยี่ยมในบางส่วน แต่เมื่อมองทั้งระบบกลับกลายเป็น การผสมกันอย่างไร้ความหมาย
- หลังจากผู้เขียนตรวจดู codebase ทั้งหมด ก็พบว่าภายในนั้นมี ‘ความเละเทะล้วน ๆ (slop)’ อยู่จริง
- AI นั้น ซื่อตรงต่อ prompt และความสอดคล้องกับตัวเอง แต่ไม่ได้คำนึงถึง ความกลมกลืนของทั้งระบบหรือความสม่ำเสมอของแพตเทิร์นข้างเคียง
- ปรากฏการณ์นี้คล้ายกับ ‘vibewriting’ ที่บางย่อหน้าในนิยายเขียนได้ดี แต่ทั้ง chapter กลับเละไม่เป็นท่า
การหวนกลับสู่การพัฒนาโดยมีมนุษย์เป็นศูนย์กลาง
- ผู้เขียนตัดสินว่าโค้ดที่ AI สร้างขึ้น ไม่เหมาะจะนำไปปล่อยเป็นผลิตภัณฑ์หรือใช้ปกป้องข้อมูลผู้ใช้
- พร้อมกับความตั้งใจว่า “ฉันจะไม่โกหกผู้ใช้ด้วยโค้ดนี้” ผู้เขียนจึง กลับไปเขียนโค้ดด้วยตัวเอง
- เมื่อเขียนเอง ผู้เขียนรู้สึกได้ว่า ความเร็ว ความแม่นยำ ความคิดสร้างสรรค์ และผลิตภาพ กลับดีขึ้นเสียอีก
- หากประเมินจาก ประสิทธิภาพของการพัฒนาโดยรวม แทนที่จะดูแค่ความเร็วในการสร้างโค้ด ก็ยิ่งเห็นความได้เปรียบของมนุษย์ชัดเจน
การใช้ AI coding ต่อไป พร้อมข้อควรระวัง
- ผู้เขียนยังคงใช้ LLM แบบจำกัดขอบเขตในบางงาน (ประมาณ 40%)
- มันยังมีประโยชน์กับงานซ้ำ ๆ หรือการสร้างโค้ดง่าย ๆ แต่ technical debt และการลดลงของความเข้าใจโค้ด จะค่อย ๆ สะสม
- ในระยะยาว นักพัฒนาอาจ สูญเสีย mental model ของ codebase และเสี่ยงต่อการแก้ปัญหาไม่ได้หากไม่มี AI
- ระหว่างเดินทาง (เช่น รถไฟหรือเครื่องบิน) ก็อาจเกิดสถานการณ์ที่ การพึ่งพา AI ทำให้ผลิตภาพกลายเป็น 0% ได้
- นักพัฒนาคนอื่น ๆ ยังชี้ว่าแนวคิดที่ว่า “แค่เขียนสเปกให้ดีก็พอ” คือการจำลองโมเดล waterfall ขึ้นมาใหม่ ทั้งที่การพัฒนาจริงต้องอาศัย การสำรวจแบบสด ๆ และปฏิสัมพันธ์โต้ตอบ เป็นสำคัญ
บทสรุป
- AI coding ยังคงเป็นเครื่องมือที่ทรงพลัง แต่ ยังขาดความสามารถในการรักษาบริบทของทั้งระบบและความสม่ำเสมอเชิงโครงสร้าง
- การตัดสินใจเชิงสัญชาตญาณและความสามารถในการปรับตัวเฉพาะหน้า ของนักพัฒนามนุษย์ยังคงเป็นหัวใจสำคัญ และ
AI ควรถูกใช้เป็นเครื่องมือเสริมในรูปแบบที่ควบคุมอย่างระมัดระวัง
9 ความคิดเห็น
คอนเซ็ปต์ vibe coding เพิ่งถูกสร้างขึ้นมายังไม่ครบ 1 ปีเลย จะมาโพสต์อวดแนวโซเชียลอะไรนักหนาเนี่ย 555
ต้องใส่ใจกับการขัดเกลาสเปกด้วยนะครับ.. ถ้าทำสเปกตามหลักการซอฟต์แวร์วิศวกรรมที่เรียนกันมาแบบจริงจัง แล้วค่อยปรับแต่ง จากนั้นก็อัปเดตไปพร้อมกับทำ traceability management ระหว่างทำงาน ก็น่าจะดีครับ
ตอนทำโปรเจ็กต์ผมก็คอยอัปเดตทั้งเทมเพลตเอกสารสเปกและเวอร์ชันของพรอมป์ต์อยู่เสมอ แต่ช่วงนี้ก็เริ่มรู้สึกว่าคงต้องกลับไปศึกษาซอฟต์แวร์วิศวกรรมให้ลึกขึ้นแบบจริงจังแล้วมั้งครับ
ผู้เขียนยังคงใช้ LLM อย่างจำกัดกับงานบางส่วนอยู่ (ประมาณ 40%)
จากที่เขียนไว้แบบข้างต้น ดูเหมือนว่าผู้เขียนเองก็ไม่ได้มีความเห็นว่าจะต้องเลิกใช้ AI ไปทั้งหมด
ดูเหมือนว่าเราควรคิดต่อไปว่าจะใช้งานมันให้เกิดประโยชน์ได้อย่างไร การจะทิ้ง AI แล้วกลับไปพัฒนาแบบไม่ใช้มัน ผมคิดว่านั่นคือการค่อย ๆ ตามไม่ทัน
ผู้เขียนบทความนี้ก็ใช้วิธีการใช้งานให้เกิดประโยชน์ได้ดีอยู่แล้ว แต่ถึงอย่างนั้น ผมก็คิดว่าเราควรครุ่นคิดต่อไปในทิศทางที่จะใช้ AI ให้เก่งยิ่งขึ้น
(ตอนนี้ก็แค่ยังมีการลองผิดลองถูกอยู่อีกมาก...)
โปรดอัปเดตข้อกำหนด
ถูกต้องครับ สามารถทำโดยใส่ hook ไว้ให้พอ implementation เสร็จแล้วค่อยอัปเดตสเปกก็ได้ หรือถ้าไม่ทำแบบนั้นก็เพิ่ม command หรือ skill สำหรับอัปเดตสเปกแบบ manual เองก็ได้ 555
อา ไม่อยากแก่เลย
ความเห็นจาก Hacker News
ผมมองว่า การที่ AI เก่งเรื่องพื้นฐานมากเกินไป กลับเป็นเรื่องอันตราย
นักเรียนจะไม่เขียนโค้ดเองเพราะคิดว่า “AI ทำแทนได้” และผลคือพวกเขาไม่ได้เรียนรู้แนวคิดระดับกลางหรือยากผ่านการลงมือทำจริง
ในฐานะครู CS ผมย้ำกับนักเรียนว่า “ไม่ใช่เครื่องจักร แต่คุณต้องเป็นคนเขียนโค้ดเอง”
ใช้รถยกมายกน้ำหนักมันง่าย แต่กล้ามเนื้อไม่เกิด
ความเจ็บปวดระหว่างการเรียนรู้นี่แหละคือแก่นของการเติบโต
แน่นอนว่าในที่ทำงานผลลัพธ์สำคัญกว่า แต่ถึงอย่างนั้นก็ยังต้องการคนที่คิดเชิงนามธรรมระดับสูงได้
ผู้สมัครมีความรู้ทฤษฎีสมบูรณ์แบบ แต่กลับอธิบายหลักการทำงานของโค้ดที่ตัวเองเขียนไม่ได้เลย
สุดท้ายก็ยอมรับว่า “GenAI เป็นคนเขียนให้เกือบทั้งหมด” ซึ่ง ช่องว่างระหว่าง ‘สิ่งที่เรียนรู้’ กับ ‘สิ่งที่เคยทำเอง’ นั้นใหญ่มาก
การสอนว่าโค้ด ทำงานอย่างไร สำคัญกว่าการสอนว่า “จะเขียนโค้ดอย่างไร”
สมัยก่อนมีช่วงที่ต้องเขียน assembly เอง แต่ตอนนี้การเข้าใจ หลักการของ compiler มีคุณค่ามากกว่า
ในความเป็นจริงคนส่วนใหญ่คงไม่ได้สร้าง compiler หรือ OS เอง แต่การรู้หลักการของมันช่วยให้เข้าใจข้อจำกัดของภาษาโปรแกรมได้
ตอน compiler เพิ่งเกิดใหม่ ๆ ก็มีการถกเถียงแบบเดียวกัน และสุดท้ายเราก็ขยับขึ้นไปสู่ชั้น abstraction ที่สูงกว่า
การทำแค่ implementation อย่างเดียวไม่ได้ทำให้ความคิดลึกขึ้น
ถ้าโยน implementation ให้ AI หมด สุดท้ายก็จะกลายเป็น ‘คนตาบอดพากันหาทาง’
กระบวนการคิดผ่านการลงมือจัดการโค้ดด้วยตัวเองเป็นสิ่งจำเป็น
ผมไม่เห็นด้วยกับคำพูดที่ว่า “AI ทำงานเล็ก ๆ ได้ดี แต่ทำงานใหญ่ได้ดีกว่า”
ในทางปฏิบัติผมได้แต่ ผลลัพธ์ที่น่าผิดหวัง เสมอ
โค้ดทำงานไม่ถูกต้อง หรือไม่ก็ต้องคอยสั่งแก้ซ้ำไปซ้ำมา
ถ้า feedback loop ทำได้ยาก สุดท้ายตัวเราเองก็กลายเป็นแหล่ง feedback เพียงแหล่งเดียว และตอนนั้นแหละจะรู้สึกชัดถึงข้อจำกัดของ AI
เช่น ถ้าอธิบายโครงสร้าง TaskManager หรือกฎเรื่อง memory ownership ให้ชัด มันก็สร้างโค้ดที่ผ่านเทสต์ได้ดี
มีคนอย่าง Ryan Dahl ที่บอกว่า “ตอนนี้ไม่เขียนโค้ดเองแล้ว” แต่ที่ทำได้ก็เพราะขัดเกลาร่วมกันผ่าน feedback ซ้ำ ๆ เหมือนทำงานร่วมทีม
AI ต้องปฏิบัติกับมันเหมือนสอนเด็ก
ระบุ input, output, และข้อผิดพลาดที่คาดไว้ให้ชัด แล้วทดลองซ้ำ ๆ พร้อมปรับแก้
Claude ช่วยตั้งคำถาม ทำรีเสิร์ช และแม้แต่รีวิวโค้ดให้
ให้ความรู้สึกเหมือนกำลังเมนเทอร์ นักพัฒนาจูเนียร์ที่เก่งคนหนึ่ง
ตอนแรกผมลอง “vibe coding” ด้วยใจเปิดกว้าง แต่ยิ่งใช้ก็ยิ่งสงสัย
มันเหมาะกับโค้ดที่ซ้ำ ๆ และชัดเจน แต่ไม่เหมาะกับ business logic แกนหลัก
Claude มักจะเมินสเปก ทำตรรกะเดิมซ้ำหลายรอบ หรือบอกว่าจะแก้แต่สุดท้ายก็ปล่อยไว้เหมือนเดิม
ยังรู้สึกด้วยว่าโมเดลเหมือน ทื่อขึ้นเรื่อย ๆ
ตอนนี้ผมใช้มันแค่คุยเรื่องการออกแบบหรือช่วยดีบักเท่านั้น
ถ้ามี ‘ส่วนที่น่าเบื่อ’ ให้ AI มาเติมเยอะมาก ก็อาจแปลว่าโครงสร้างโค้ดตั้งต้นนั้นผิดอยู่แล้ว
ในจุดนี้ LLM ยังช่วยได้อยู่
นักพัฒนาหลายคนก็แค่รับแบบที่ออกแบบไว้แล้วมาลงมือทำ ดังนั้น AI จึงอาจช่วยเพิ่มความเร็วได้
ผมไม่เห็นด้วยกับข้ออ้างที่ว่า “AI สะท้อนการเปลี่ยนแปลงในการออกแบบไม่ได้”
ตรงกันข้าม ผมคิดว่า “นั่นแหละคือบทบาทของมนุษย์”
เช่น ถ้าสั่งให้เปลี่ยนโครงสร้าง API, AI ก็สามารถไล่หาส่วนที่เกี่ยวข้องทั้งหมด แก้ไข และรันเทสต์ให้ได้
บางทีก็ยึดติดกับรายละเอียด implementation มากไป หรือขาดการตรวจสอบเชิงแนวคิด
ถึงอย่างนั้น เทสต์ที่มนุษย์เขียนก็คล้ายกัน เลยพอเข้าใจได้
ถ้าไม่ได้เขียนโค้ดเอง เราจะไม่รู้สึกถึงส่วนหยาบและไม่สมดุลของ abstraction ซึ่งสุดท้ายจะนำไปสู่คุณภาพเชิงโครงสร้างที่ตกลง
ความต่างนี้เป็นตัวตัดสินความสมบูรณ์ของโค้ด
แต่สิ่งสำคัญคือความสามารถในการตัดสินว่า งานแบบไหนจำเป็นต้องมีการแทรกแซงด้วยมือจริง ๆ
แต่ก็ต้องใช้แพ็กเกจระดับสูงเท่านั้นถึงจะคุ้ม เช่น Claude Max ราคา 200 ดอลลาร์
ผมสงสัยกับคำพูดที่ว่า “ทำ vibe coding มาตั้งแต่ 2 ปีก่อน”
เพราะ Karpathy เพิ่งบัญญัติคำนี้เมื่อประมาณ 1 ปีก่อนเท่านั้น (ที่มา)
จุดที่น่าสนใจคือให้ GPT ออกแบบ API ที่ตัวเองจะใช้ แล้วค่อย implement ตามนั้น
แต่หลังจากนั้นก็มีการบอกว่าโมเดลรุ่นหลัง ๆ เริ่มบล็อกบทสนทนาเกี่ยวกับ การแก้ไขตัวเอง/การทำสำเนาตัวเอง
ไม่จำเป็นต้องเป็นเครื่องมือแบบ agent เต็มรูปแบบ แค่ใช้ ChatGPT หรือ Claude ก็ทำได้แล้ว
และตอนนี้ได้ผลลัพธ์ดีขึ้นเพราะ ร่วมงานกับ AI ตั้งแต่ขั้นรีเสิร์ช
ผมบอกนักเรียนเสมอว่า “ดูการแข่งกีฬาทางทีวีไม่ได้แปลว่าได้ออกกำลังกาย”
vibe coding ก็เช่นกัน มันมี ความภูมิใจจากการเขียนโค้ดด้วยมือตัวเอง ที่อย่างอื่นทดแทนไม่ได้
โค้ดแบบ ‘เสร็จไปครึ่งหนึ่ง’ ที่ AI สร้างให้กลับช่วยปลุกแรงจูงใจของผมขึ้นมาอีกครั้ง
ผมยังไม่แน่ใจว่าเหล่าวิศวกรตัวจริงจะทำ ‘vibe coding’ แบบไม่คิดหน้าคิดหลังจริงไหม
ของผมจะเป็น การค่อย ๆ แกะสลักโค้ดผ่านบทสนทนา มากกว่า
ผมบอก requirement, ทบทวนแบบร่างการออกแบบร่วมกับ AI, แล้วค่อย ๆ ทำให้โครงสร้างสมบูรณ์ขึ้นทีละนิด
กระบวนการนี้ช้า แต่ยังรักษาความลึกของการร่วมงานและการคิดได้
AI เสนอไอเดียใหม่จากการเรียนรู้โค้ดมหาศาล ส่วนผมใช้ประสบการณ์มาช่วยปรับให้เข้าที่
สุดท้าย AI ให้ความรู้สึกเหมือนเป็นเวอร์ชันขยายของผมเอง (me++)
ผมยังไม่พร้อมจะยกทั้งหมดให้ agent แบบเต็มตัว แต่ตอนนี้วิธีนี้มีประสิทธิผลที่สุด
ผมรู้สึกว่าโค้ดที่ AI เขียนนั้นเหมือน นิยายที่บางตอนยอดเยี่ยม แต่ทั้งเรื่องเละเทะ
ถ้ามองเป็นรายบทมันสมบูรณ์แบบ แต่พอมองทั้งบริบทกลับสับสน
ถ้าไม่ ก็ยากจะคาดหวังว่า codebase แบบ vibe-coded ที่ยาว 10,000 บรรทัดจะทำงานได้ดี
ถ้าไม่มีความคิดและอารมณ์ของมนุษย์สะท้อนอยู่ ประสบการณ์ผู้ใช้ก็จะเสียความสม่ำเสมอและเกิด แรงเสียดทานทางการรับรู้
เขาบอกว่าถ้าการออกแบบชัดเจน LLM จะช่วย เร่งงาน boilerplate ได้แบบก้าวกระโดด
แต่เรื่องการออกแบบยังเป็นหน้าที่ของมนุษย์
โปรเจ็กต์ของเขาดูได้จาก เวอร์ชันเปิดบน GitHub
ผมยอมรับว่าโค้ดที่ LLM สร้างนั้น บางส่วนยอดเยี่ยม แต่โครงสร้างโดยรวมอ่อน
แต่ถ้าเข้าใจ codebase และตรวจทานด้วยตัวเอง ก็ยังปรับแก้ให้ดีพอได้
vibe coding เหมาะมากกับ การทำ prototype
การทำให้เห็นภาพเร็ว แล้วค่อย refactor เพื่อขยายต่อภายหลัง เป็นวิธีที่ได้ผล
กล่าวคือ แนวคิดนี้มองว่าการดูแค่ผลลัพธ์แล้วตัดสินต่างหากคือ vibe coding ของจริง