ลัทธิบูชา vibe coding มันบ้าคลั่งเกินไป
(bramcohen.com)- จากเหตุการณ์ ซอร์สโค้ดของ Claude รั่วไหล ทำให้เห็นชัดว่าความงมงายใน "vibe coding" ส่งผลเสียต่อคุณภาพของโปรเจกต์จริงอย่างไร
- Vibe coding ยึดหลักว่าจะไม่เปิดดูภายในโค้ดเลยแม้แต่น้อย แต่สิ่งนี้เป็นเพียง ความเชื่อล้วน ๆ เท่านั้น เพราะในทางปฏิบัติย่อมต้องมีการออกแบบโครงสร้างโดยมนุษย์ เช่น ไฟล์แผนงาน, สกิล, กฎต่าง ๆ
- AI เก่งมากในการจัดการโค้ดซ้ำซ้อนและหนี้ทางเทคนิค แต่ถ้าจะใช้ให้เกิดประโยชน์ มนุษย์ต้องลงไปดูโค้ดเอง ระบุปัญหา แล้วอธิบายให้ AI เข้าใจ
- AI แทบไม่ค่อยรับรู้ได้เองว่า "มีสปาเกตตีโค้ดอยู่ตรงนี้ ควรจัดระเบียบ" และจะให้ผลลัพธ์คุณภาพสูงได้เมื่อมนุษย์ ให้ทิศทางและบริบทก่อน
- อย่างที่ประโยค "ซอฟต์แวร์แย่ ๆ คือผลจากการตัดสินใจของนักพัฒนา" สะท้อนให้เห็นว่า คุณภาพที่ตกต่ำไม่ใช่เพราะ AI แต่เป็น ผลจากการตัดสินใจ
- กล่าวคือ คุณภาพซอฟต์แวร์ที่ลดลงไม่ใช่ความผิดของ AI แต่เป็นทางเลือกที่นักพัฒนาเป็นผู้เลือกเอง
ปัญหาจากซอร์สโค้ด Claude รั่วไหลและ vibe coding
- ซอร์สโค้ดของ Claude รั่วไหลออกมา และถูกผู้คนจำนวนมากล้อเลียนเพราะ คุณภาพโค้ดต่ำ
- สาเหตุของปัญหานี้ถูกชี้ไปที่ การ dogfooding มากเกินไป หรือวัฒนธรรมการใช้ผลิตภัณฑ์ของตัวเองแบบเชื่อมั่นจนเกินเหตุ
- การใช้ของตัวเองเป็นหลักนั้นเป็นไอเดียที่ดี แต่ก็อาจกลายสภาพเป็นกิจกรรมเชิงลัทธิที่ก้าวข้ามขอบเขตของเหตุผลได้
แก่นแท้ของ vibe coding
- Vibe coding คือแนวทางที่ยึดหลักว่า ไม่เข้าไปมีส่วนร่วมอะไรกับภายในโค้ดเลย และไม่แม้แต่จะเปิดดูมัน
- แต่ vibe coding แบบบริสุทธิ์เป็นเพียงมายาคติ (Myth) — ในความเป็นจริงย่อมมีเฟรมเวิร์กที่มนุษย์สร้างขึ้น เช่น ไฟล์แผนงาน (รายการสิ่งที่ต้องทำ), สกิล, กฎต่าง ๆ อยู่เสมอ และหากไม่มีโครงสร้างเหล่านี้ AI จะทำงานได้แย่มาก
- แม้โค้ดจะเขียนเป็นภาษาอังกฤษและใคร ๆ ก็อ่านได้ แต่กลับมีตรรกะแบบว่า "การดูภายในถือว่าผิดกติกา" จนนักพัฒนาปฏิเสธที่จะตรวจสอบด้วยตัวเอง
- ในความเป็นจริง เมื่อมีมนุษย์เพียงคนเดียวลองตรวจดูโค้ด ก็พบว่า มีความซ้ำซ้อนขนาดใหญ่ระหว่าง agent กับ tool ซึ่งเป็นปัญหาที่ถ้ามีใครสักคนมองผ่าน ๆ สักนิดก็น่าจะสังเกตได้ง่าย
AI กับการจัดการหนี้ทางเทคนิค
- โปรเจกต์ซอฟต์แวร์มักเริ่มต้นมาพร้อมกับ หนี้ทางเทคนิค และในอดีตบางครั้งต้องใช้เวลาถึง 1 ปีเพียงเพื่อจัดระเบียบสิ่งเหล่านี้
- หากใช้ AI งานจัดระเบียบนี้อาจเสร็จได้ภายในไม่กี่สัปดาห์ หรือค่อย ๆ ลดลงไปพร้อมกับการพัฒนาฟีเจอร์ใหม่
- AI เก่งมากในการจัดระเบียบโค้ด แต่ยังขาดความสามารถในการตรวจจับปัญหาด้วยตัวเอง — ผลลัพธ์ที่ดีจะเกิดขึ้นเมื่อมนุษย์บอกว่า "ตรงนี้มีสปาเกตตีโค้ด" และให้แนวทางกำกับ
วิธีใช้ AI ที่ถูกต้อง — แนวทางแบบอิงการสนทนา
- วิธีที่ถูกต้องในการแก้ปัญหาความซ้ำซ้อน มีการเสนอขั้นตอนดังนี้:
- ทำรายการของสิ่งที่อยู่ทั้งฝั่ง agent และฝั่ง tool
- ตรวจดูตัวอย่างแล้วตัดสินว่าแต่ละรายการเป็น agent หรือ tool
- พูดคุยเกณฑ์โดยรวมและกำหนดแนวทางทั่วไป
- ตรวจสอบทุกรายการแล้วแก้รายการที่ถูกจัดหมวดผิด
- สำหรับรายการที่มีอยู่ทั้งสองฝั่ง ให้นำสองเวอร์ชันมาเทียบแล้วรวมให้เป็นหนึ่งเดียว
- โหมด Ask ถูกสร้างมาเพื่อกระบวนการนี้ โดยหัวใจสำคัญคือการพิจารณาตัวอย่างร่วมกัน และแก้ไขจุดที่ AI พยายามเห็นด้วยมากเกินไปจนผิดพลาด
- หลังจากสนทนามากพอ อาจรู้สึกว่า AI ให้ผลลัพธ์ที่ดูเหมือน one-shot แต่ที่จริงแล้วผลลัพธ์นั้นตั้งอยู่บนปฏิสัมพันธ์กับมนุษย์จำนวนมากก่อนหน้า
- ทีม Claude ใช้ dogfooding แบบสุดโต่งโดยไม่ผ่านกระบวนการนี้ และถึงขั้น ปฏิเสธแม้แต่ความพยายามขั้นต่ำในการเปิดดูภายในโค้ดชั่วครู่เพื่ออธิบายปัญหา
กรณีใช้งานจริง
- ตัวอย่างเวิร์กโฟลว์ของผู้เขียน: เริ่มบทสนทนาด้วยการพูดว่า "มาช่วยตรวจสอบโค้ดที่ไม่มีทางถูกเรียกใช้ใน codebase นี้กัน" หรือ "ฟังก์ชันนี้อ่านแล้วปวดตา"
- จากนั้นคุยต่อไปเรื่อย ๆ จนได้ทิศทางที่ลงมือทำได้ อธิบายสิ่งที่ต้องทำ แล้วถกกันต่อจน AI เลิกพูดอะไรโง่ ๆ
- หลังจากนั้นจึงวางแผนและรันบิลด์ ซึ่งเป็นวิธีทำงานในชีวิตประจำวัน
คุณภาพซอฟต์แวร์คือเรื่องของการเลือก
- การใช้ AI ไม่ได้หมายความว่าจะต้อง ยอมรับซอฟต์แวร์คุณภาพต่ำ
- ไลบรารีที่สร้างโดยนักพัฒนาซึ่งได้ค่าตอบแทนสูงเกินจริงและไม่ได้ใช้ AI ก็อาจมีคุณภาพแย่ได้เช่นกัน
- ซอฟต์แวร์แย่ ๆ คือการตัดสินใจที่เราลงมือเลือกเอง และเราควรรับผิดชอบต่อมันพร้อมมุ่งไปสู่คุณภาพที่ดีกว่า
9 ความคิดเห็น
บรรยากาศแบบที่ทำ
FULL AUTO MATIONด้วย AI AGENT ให้สร้างโค้ด, merge, review, verify จนเป็นอัตโนมัติเต็มรูปแบบ แล้วทำให้ทุกอย่างประกอบเป็นโค้ดได้เอง แทบไม่ต้องใส่ใจอะไรเลย นาน ๆ ทีค่อยให้ดีเวลลอปเปอร์เข้าไปแทรกแซงตอนที่เอเจนต์ตีกันเอง แล้วก็ทำเหมือนว่ามันจบครบหมดแล้ว จนถึงขั้นมองนักพัฒนาที่ทำแบบนั้นไม่ได้ว่าเป็นพวกผิดปกติที่ตามเทรนด์ไม่ทัน มันถูกพูดกันจนเกลื่อน...พอมาดูพวกที่ปกติก็เอาแต่พ่นโค้ด boilerplate ซ้ำ ๆ เขียนแต่โค้ดแพตเทิร์นเดิมต่อเนื่องแล้วรับเงินเดือนสูงลิ่ว พอถึงเวลามาอ้าปากบอกว่าเดี๋ยวนี้ไม่ต้องเขียนโค้ดแล้วเพราะ AI ยิ่งดูน่าสมเพชสุด ๆต้องคอยกำกับแบบละเอียดแม้แต่ในส่วนเล็กน้อยมาก ๆ ถึงจะได้โค้ดที่คุณภาพพอดูดีขึ้นมา ผมคิดว่าการทำให้เป็นอัตโนมัติเต็มรูปแบบนั้นเป็นไปไม่ได้เลย นอกจากกรณีผลิตโค้ด boilerplate จำนวนมากจริง ๆ คนที่พูดถึงความเป็นอิสระเต็มรูปแบบมีอยู่สองแบบ ไม่ก็ไม่ค่อยรู้อะไรจริง หรือไม่ก็เป็นพวกต้มตุ๋น
โปรเจกต์ที่เสร็จครึ่งๆ กลางๆ กำลังล้นทะลัก…
คนที่รู้การเขียนโปรแกรมแค่ครึ่งเดียวก็พากันคลั่งไคล้…
มองว่า
dogfoodingเป็นด็อกพุดดิงน่าจะเหมาะกว่าที่จะมองว่าเป็นการกินรวบคนเดียวครับdog食...
หัวข้อกับเนื้อหาคนละเรื่องกัน...?
ดูเหมือนเป็นการตำหนิแบบสรุปเอาเองว่า vibe coding เท่ากับไม่ทำ code review แล้วก็เอาเหตุผลต่าง ๆ มาปะติดปะต่อประกอบ
ยิ่งไปกว่านั้น การเอา Claude Code มาโยงก็ไม่มีเหตุผลเลย ถ้าจะเข้มงวดเรื่องคุณภาพในระดับนั้น เช่น ยึดหลักวิศวกรรมแบบวิศวกรระดับผู้ดูแล Linux จริง ๆ ก็จะไม่เข้าไปมองปัญหาคุณภาพโค้ดแบบฉาบฉวยเป็นชิ้น ๆ แบบนี้ ส่วนใหญ่แทบจะเป็นการเข้าหาเชิงโฆษณาชวนเชื่อ มากกว่าจะมาจากการได้ลองทดสอบด้วยตัวเอง แต่เป็นแนว ๆ ได้ยินเขาพูดต่อกันมาว่าเป็นแบบนั้น
มันคล้ายกับการบอกว่าดีไซน์ตึกของ Samsung ไม่ค่อยดี แล้วบอกว่ายังอีกไกลกว่าจะตาม Sony ทัน
ตอนที่ลองใช้ Claude Code ครั้งแรก ผมไปบอกเพื่อนต่างชาติว่า "ฉันเพิ่งลอง vibe coding ครั้งแรก!" แต่พอพวกเขาฟังที่ผมเล่า ก็กลับตอบว่า "ไม่สิ แบบนั้นไม่ใช่ vibe coding นะ vibe coding จริง ๆ คือการไม่เปิดดูโค้ดเลยต่างหาก" ดูเหมือนว่า 'vibe coding' ที่มักพูดกันในบ้านเราจะมีความหมายกว้างกว่านิยามที่ใช้กันในตะวันตกมาก สำหรับ vibe coding ที่พูดกันบน Hacker News นิยามว่าเป็น 'ไม่ทำ code review' น่าจะตรงที่สุด
ความคิดเห็นจาก Hacker News
มันแปลกที่คนยกคุณภาพซอร์สที่รั่วของ Claude Code มาเป็นตัวอย่างว่า ‘vibe coding’ ล้มเหลว
สำหรับผมกลับมองว่ามันพิสูจน์ตรงกันข้าม คือคุณสามารถสร้างผลิตภัณฑ์ที่ดังและประสบความสำเร็จได้ แม้จะละเมิดกฎของ “โค้ดที่ดี” แบบดั้งเดิม
บ่อยครั้งโค้ดที่ทำแบบขัดตาทัพเพราะเดดไลน์ก็ยังค้างอยู่ในโปรดักชันแบบนั้นต่อไป
แม้แต่โปรเจกต์ส่วนตัว คอมมิตแรก ๆ ก็เละเทะ แล้วค่อยไปเปิดกิ่งสำหรับเก็บงานทีหลัง
แต่ในบริษัทแทบไม่มีเวลาทำฉบับร่างที่สองหรือสาม สุดท้ายฉบับแรกจึงถูกปล่อยใช้งาน
พูดตรง ๆ ผมก็กลัวเหมือนกันว่าโค้ดที่มีชื่อผมแปะอยู่จะหลุดออกไป แต่ความจริงมันก็เป็นแบบนี้
ถ้าตอนแก้โค้ดแล้วเริ่มรู้สึกว่า “อันนี้มันฝืน ๆ” การรีบแก้ตรงนั้นเลยสุดท้ายจะประหยัดเวลากว่า
สำหรับ LLM ผมยังมีประสบการณ์ไม่มากพอเลยยังไม่กล้าฟันธง
Claude Code โดยแก่นแล้วเป็นผลิตภัณฑ์ที่ค่อนข้างเรียบง่าย และคุณค่าที่แท้จริงอยู่ที่ตัวโมเดลเอง
กล่าวคือมันเป็น ผลิตภัณฑ์ความเสี่ยงต่ำ ที่ถึงคุณภาพโค้ดจะไม่สูงก็ไม่ใช่ปัญหาใหญ่ เลยเกิดกรณีแบบนี้ได้
มันก็ไม่ได้ขัดกับแนวคิด “Vibe coding” แต่อย่างใด โครงสร้างคือให้แค่ไอเดียเชิงนามธรรมระดับสูง แล้ว AI เป็นคนเขียนโค้ดจริง
Claude Code อยู่ในระดับ AI Level 7 (มนุษย์เขียนสเปก บอตเขียนโค้ด) และผู้เขียนบอกว่าระดับ 6 ดีกว่า
แต่ละคนก็มีระดับที่เหมาะกับตัวเองต่างกัน บางคนมองว่าต่ำกว่าระดับ 5 คือขีดจำกัด ขณะที่บางคนคิดว่าเกินระดับ 2 ก็อันตรายแล้ว
ระดับที่เหมาะสมเปลี่ยนไปตามความซับซ้อนและความใหม่ของแต่ละโดเมน
ตัวอย่างเช่น แอปที่ผมทำ ส่วนอัลกอริทึมเป็น Level 0, UI เป็น Level 7, ส่วนมิดเดิลแวร์ก็อยู่กลาง ๆ
ทักษะจริงคือการหาระดับที่เหมาะกับแต่ละบริเวณของโค้ด
ถ้าเป็นภาษาแบบไดนามิก เกินกว่านี้ผมจะไม่มั่นใจแล้ว ถ้าจะไปถึง Level 7 ขึ้นไป ผมคิดว่าควรย้ายไปภาษาแบบ static type ให้หมดจะดีกว่า
การเขียนโค้ดจะเหลือเป็นงานเฉพาะทางแบบช่างตีเหล็ก ส่วนใหญ่จะถูกทำให้เป็นอัตโนมัติ
แต่ข้อดีคือคนคนเดียวจะทำงานได้เท่ากับทั้งทีมในอดีต
เพราะมันล่อตาล่อใจมากที่จะรับฟีเจอร์มาใช้โดยที่ยังไม่เข้าใจกลไกการทำงานทั้งหมด
คนเขียนบทความนี้คือผู้ก่อตั้ง BitTorrent ไม่ใช่แค่บล็อกเกอร์ธรรมดา
การใช้งาน Claude Code ที่ผมชอบที่สุดคือการ ยกระดับคุณภาพโค้ด
งานที่ถ้าให้คนทำจะดูเหมือนเสียเวลา พอเป็น AI ทำให้แทบฟรีก็โอเคเลย
เช่นจัดระเบียบแพตเทิร์นของเทสต์ที่ซ้ำ ๆ, รักษาความสม่ำเสมอของ JSON serialization, ลบโค้ดซ้ำ
ผลลัพธ์คือโค้ดเบสเล็กลงและดูแลง่ายขึ้น คล้าย ๆ linting ขนาดใหญ่
จากนั้นก็เอาผลของแต่ละโมเดลมาตรวจไขว้กัน แล้วให้ Opus สรุปรายการสุดท้ายเพื่อแก้
แม้จะมีการเปลี่ยนแปลงที่ไม่จำเป็นเยอะ แต่ปัญหาที่มันจับได้ก็มีประโยชน์จริง
มุมมองเรื่อง “Dogfooding” น่าสนใจ
ประเด็นไม่ใช่คุณภาพโค้ด แต่คือผู้ใช้สามารถ ประเมินผลลัพธ์จาก AI แบบวิพากษ์วิจารณ์ ได้หรือไม่
การที่วิศวกรมีประสบการณ์ยังคงใช้วิจารณญาณของตัวเองพร้อมกับ AI กับการปล่อยให้ AI ตัดสินแทน เป็นคนละเรื่องกันโดยสิ้นเชิง
ปัญหาคือเครื่องมือแยกสองอย่างนี้ไม่ออก และการตลาดก็มุ่งไปหากลุ่มหลัง
คนที่สนับสนุน ‘Vibe coding’ บอกว่าคุณภาพโค้ดไม่สำคัญ เพราะ LLM สามารถ ทำซ้ำ (iteration) ได้เร็วกว่า manusia มาก
มนุษย์มีต้นทุนสูงในแต่ละขั้นตอน (เขียน–ตรวจสอบ–แก้ไข) แต่ LLM ทำซ้ำได้เร็วด้วยแค่ต้นทุนโทเคน
แต่ผมยังสงสัยกับแนวทางนี้ เพราะเห็นกรณีที่พังมามากเกินไป
ถึงอย่างนั้น ถ้า LLM พัฒนาต่อไปอีก คนกลุ่มนั้นอาจพูดถูกก็ได้
ในสเปกตรัมของ “Vibe coding” มีอยู่สองขั้ว
ขั้วหนึ่งคือคนที่ไม่มีพื้นฐานเทคนิคแต่ชอบเพราะมันน่าตื่นตา อีกขั้วคือพวก เกลียด AI
ระหว่างนั้นมีคนกลางที่เงียบแต่มีประสิทธิภาพสูง พวกเขามองโลกในแง่ดีแต่ก็มีประสบการณ์มาก
ช่วง 6 เดือนที่ผ่านมา ผมใช้เครดิต Claude Code ไปราว $2500 และแม้งานส่วนใหญ่จะไม่ได้ปล่อยใช้งานจริง ผมก็ยังได้ คุณค่ามหาศาล
ผมไม่เห็นด้วยกับคำกล่าวที่ว่า “Claude Code ใช้การไม่ได้”
เว็บแอปส่วนใหญ่ก็เป็นแค่ CRUD ง่าย ๆ เท่านั้น 99% ของบริษัทไม่ได้มีผู้ใช้ถึง 50,000 คนด้วยซ้ำ
บริษัทที่ผมเคยทำงานด้วยต้องรันโปรแกรมวันละ 22 ชั่วโมงเพราะโค้ดไม่มีประสิทธิภาพ
ปรากฏการณ์นี้ทำให้นึกถึง ทฤษฎีนวัตกรรมของ Clayton Christensen
บริษัทเดิม ๆ มักพอใจกับผลิตภัณฑ์ปัจจุบันที่ทำกำไรสูง จึงมองข้ามเทคโนโลยีใหม่ที่คุณภาพต่ำกว่า แต่สุดท้ายเทคโนโลยีนั้นจะพัฒนาไปจนพลิกตลาด
ตอนนี้ Claude Code ก็อยู่ในระดับ “ดีพอแล้ว” และถ้า AI พัฒนาต่อไปเรื่อย ๆ สุดท้ายมันก็จะเหนือกว่าการเขียนโค้ดด้วยมือ
คนรอบ ๆ ‘Vibe coding’ แบ่งได้หลายกลุ่ม
① คนที่มีผลประโยชน์ทางการเงิน ② นักพัฒนาที่เหนื่อยหน่ายกับการเขียนโค้ด ③ มือใหม่ที่เพิ่งได้สร้างอะไรบางอย่างเป็นครั้งแรก
กลุ่ม ② ไม่อยากเรียนรู้อะไรใหม่ ๆ ส่วนกลุ่ม ③ กำลังสัมผัสความสุขของการสร้างสรรค์อย่างจริงใจ
AI coding อาจเป็น เส้นทางเริ่มต้น ที่ดีสำหรับคนเหล่านี้
ผมก็เป็นแบบนั้น ผมรักการเขียนโค้ดมา 30 ปี แต่เวลาที่ต้องใช้เพื่อทำสิ่งที่จินตนาการไว้ให้เป็นจริงมันนานเกินไป
ตอนนี้ช่องว่างนั้นหายไปแล้ว เลยรู้สึกเหมือนได้รับอิสรภาพ เป้าหมายคือเรียนรู้วิธีเร่งความเร็วโดยยังรักษาคุณภาพไว้ได้
เราไปลอกปัญหาของบริษัทใหญ่มาใช้ทั้งชุด จน productivity ลดลงและความเหนื่อยล้าเพิ่มขึ้น
ตอนนี้เพราะ AI เราสามารถเมินความซับซ้อนพวกนั้นและไปเอาผลลัพธ์ตรง ๆ ได้เลย
ต่อให้มีเฟรมเวิร์กใหม่หรือวิธี deploy แบบใหม่ออกมา ก็ไม่จำเป็นต้องสนใจ AI จัดการให้หมด
ทุกครั้งที่มีการผลัดเปลี่ยนรุ่นของเทคโนโลยี ความขัดแย้งแบบนี้ก็เกิดซ้ำเสมอ