- การผลิตโค้ดซับซ้อนจำนวนมากที่ AI สร้างขึ้นกำลังแพร่หลาย และปรากฏการณ์การสร้างโค้ดที่มนุษย์ไม่ได้อ่านก็กำลังกระจายไปทั่วทั้งอุตสาหกรรม
- ผู้บริหารใช้ การลดจำนวนพนักงานเพราะ AI มาเป็นข้ออ้าง และนักพัฒนาก็อยู่ในสถานการณ์ที่ถูกกดดันให้ต้องทำสัดส่วนโค้ดที่ AI สร้างให้ถึงเป้า
- ‘vibe coding’ ลักษณะนี้ก่อให้เกิดภาวะ ‘dark flow’ ที่คล้ายกับกลไกการเสพติดของการพนัน ทำให้เกิดภาพลวงตาว่ามีประสิทธิภาพสูงขึ้น
- มีผลการวิจัยว่า เมื่อใช้เครื่องมือเขียนโค้ดด้วย AI ผู้ใช้รู้สึกว่าผลิตภาพดีขึ้น 20% แต่จริง ๆ แล้วช้าลง 19%
- AI มีประโยชน์จริง แต่ ความคิด ความสร้างสรรค์ และความสามารถด้านวิศวกรรมซอฟต์แวร์ของมนุษย์ยังไม่ถูกแทนที่ และหากละทิ้งสิ่งเหล่านี้ก็อาจเสี่ยงต่อการถดถอยแทน
การแพร่กระจายของ vibe coding และการตระหนักถึงปัญหา
- vibe coding คือการผลิตโค้ดซับซ้อนจำนวนมากที่ AI สร้างขึ้น ซึ่งทำให้มนุษย์อ่านหรือบำรุงรักษาได้ยาก
- บางบริษัทอ้างว่า AI สามารถแทนงานของมนุษย์ได้ จึงใช้เป็นเหตุผลในการเลิกจ้าง
- นักพัฒนาถูกกดดันว่า หากทำสัดส่วนโค้ดที่ AI สร้างไม่ถึงเป้า ก็อาจเสียเปรียบในการประเมินผลงาน
- ทั้งนักเรียนและคนทำงานต่างเกิดปรากฏการณ์ลังเลที่จะพัฒนาตัวเอง ท่ามกลางความกังวลว่า “AI จะมาแทนงานของฉันในไม่ช้า”
- AI มีประโยชน์จริง แต่ต้องระวัง vibe coding และหากใช้ผิดทางก็อาจนำไปสู่ผลลัพธ์ด้านลบได้
ความต่างระหว่าง ‘flow’ และ ‘dark flow’
- ‘flow’ ที่นักจิตวิทยา Mihaly Csikszentmihalyi นิยามไว้ คือภาวะจดจ่ออย่างลึกซึ้งที่ความท้าทายและทักษะอยู่ในสมดุลกัน
- ในทางกลับกัน แม้แต่กิจกรรมที่ไม่เกี่ยวกับทักษะอย่างการพนันก็อาจก่อให้เกิดความจดจ่อได้ ซึ่งเข้าข่ายเป็น ‘flow ปลอม’
- เช่นกรณี Loss Disguised as a Win (LDW) ของสล็อตแมชชีน ที่จริง ๆ แล้วเป็นการขาดทุน แต่ทำให้เข้าใจผิดเหมือนชนะ
- งานวิจัยระบุว่า LDW ทำให้เกิดปฏิกิริยาทางสรีรวิทยาคล้ายกับการชนะจริง จึงเสริมแรงให้เกิดความหมกมุ่นแบบเสพติด
- ปรากฏการณ์นี้ถูกเรียกว่า ‘dark flow’ หรือ ‘junk flow’ ซึ่งหมายถึงความจดจ่อแบบเสพติดที่ไม่มีการเติบโตเกิดขึ้น
ความคล้ายกันระหว่าง vibe coding กับการพนัน
- นักพัฒนา Armin Ronacher กล่าวว่าหลังใช้เครื่องมือเขียนโค้ดด้วย AI เขาสร้างโค้ดได้มากมาย แต่แทบใช้จริงไม่ได้เลย
- นี่เป็นโครงสร้างภาพลวงตาที่คล้ายกับ**‘ชัยชนะแบบปลอม’** ในการพนัน
- vibe coding ขัดกับเงื่อนไขของ flow ในหลายจุด ดังนี้
- ไม่มีฟีดแบ็กที่ชัดเจนต่อผลงาน กลับกันยังมอบความรู้สึกสำเร็จที่ผิดพลาด
- ระดับความท้าทายกับระดับทักษะไม่สมดุลกัน
- ทำให้ผู้ใช้เชื่อว่าตนควบคุมผลลัพธ์ได้ ผ่าน ภาพลวงตาของการควบคุม
- คุณภาพของโค้ดที่ AI สร้างมักจะรู้ตัวว่ามีปัญหาก็หลังจากผ่านไปหลายสัปดาห์ และตอนนั้น บั๊กกับความซับซ้อนที่บำรุงรักษาไม่ได้ ก็จะค่อย ๆ ปรากฏออกมา
- ทั้ง LLM และสล็อตแมชชีนต่างก็ถูกออกแบบมาเพื่อขยายปฏิกิริยาทางจิตวิทยาของผู้ใช้ให้สูงสุด เพื่อชักจูงให้ใช้งานต่อเนื่อง
ภาพลวงตาเรื่องผลิตภาพ และ ‘ผู้เล่าที่ไม่น่าเชื่อถือ’
- จากงานวิจัยของ METR นักพัฒนาที่ใช้เครื่องมือ AI รู้สึกว่าตัวเองเร็วขึ้น 20% แต่จริง ๆ แล้วช้าลง 19%
- นี่หมายถึงความต่าง 40% ระหว่างประสิทธิภาพที่รับรู้กับประสิทธิภาพจริง
- แม้แต่งานเขียนที่ AI สร้างขึ้นก็อาจดูเผิน ๆ คล้ายกัน แต่คุณภาพด้อยกว่า
- บทความบล็อกของนักวิจัย AI คนหนึ่งหลังจากให้ AI เขียน กลับกลายเป็นสำนวนที่อ่านยากกว่าเดิม
- มนุษย์นั้นประเมินผลิตภาพของตนเองอย่างเป็นกลางได้ยาก และมีแนวโน้มจะประเมินสูงเกินจริงหลังใช้ AI
การคาดการณ์ที่ผิดพลาดและความเสี่ยงต่ออาชีพ
- การคาดการณ์ว่า AI จะมาแทนการเขียนโค้ดทั้งหมดนั้นพลาดซ้ำแล้วซ้ำเล่า
- Geoffrey Hinton เคยคาดว่า ภายในปี 2021 AI จะมาแทนแพทย์รังสีวิทยา แต่ก็ไม่เกิดขึ้นจริง
- Sundar Pichai และ Jeff Dean แห่ง Google เคยกล่าวว่า ภายในปี 2023 นักวิทยาศาสตร์ข้อมูลทุกคนจะใช้เครื่องมือออกแบบโครงข่ายประสาทอัตโนมัติ แต่ก็ไม่เกิดขึ้น
- Dario Amodei แห่ง Anthropic คาดว่า ภายในปลายปี 2025 AI จะเขียนโค้ด 90% ของทั้งหมด แต่ก็ไม่มีหลักฐานรองรับ
- ดังนั้นการหยุดพัฒนาทักษะของตนเอง เพราะเชื่อตามมุมมองที่เกินจริงเหล่านี้จึงเป็นเรื่องเสี่ยง
- ความเร็วของการพัฒนา AI ถูกประเมินสูงเกินจริงอย่างต่อเนื่อง มาโดยตลอด
ความสำคัญที่ยังคงอยู่ของความคิดและความสร้างสรรค์ของมนุษย์
- เอเจนต์เขียนโค้ดด้วย AI สามารถสร้างโค้ดที่ถูกต้องตามไวยากรณ์ได้ แต่
- ไม่สามารถทำการออกแบบ abstraction ที่มีประโยชน์ การทำโมดูลาร์ หรือการปรับปรุงโครงสร้างโค้ดได้
- กล่าวคือ การเขียนโค้ดถูกทำให้เป็นอัตโนมัติแล้ว แต่วิศวกรรมซอฟต์แวร์ยังไม่ถูกทำให้เป็นอัตโนมัติ
- ข้อความที่ AI สร้างขึ้นก็เช่นกัน แม้จะลื่นไหลตามไวยากรณ์ แต่ไม่ได้หมายความว่าจะขัดเกลาความคิดให้แม่นขึ้นหรือจับประเด็นสำคัญได้
- Jeremy Howard เตือนว่า “ถ้ามอบการคิดให้ AI ทั้งหมด เราจะสูญเสียความสามารถในการเรียนรู้และการเติบโต”
- AI มีประโยชน์ในฐานะเครื่องมือ แต่ไม่ได้มาแทนความสามารถแกนหลักของมนุษย์
6 ความคิดเห็น
เวลาเราประเมินความสามารถในการทำงานของคน จะมีองค์ประกอบที่เรียกว่า 'ทัศนคติ' อยู่ นอกเหนือจากแนวทางการทำงานและคำสั่งของหัวหน้าแล้ว ทัศนคติที่เจ้าตัวมีต่องานด้วยตัวเองก็สำคัญ ทัศนคตินั้นแสดงออกผ่านความสนใจอย่างต่อเนื่องต่อการทำงาน วิสัยทัศน์เชิงลึก และความรับผิดชอบ ในบรรดาสิ่งเหล่านี้ ความรับผิดชอบสำคัญที่สุด ปัญญาประดิษฐ์อาจเลียนแบบอย่างอื่นได้ แต่ไม่มีความรับผิดชอบ ปัญญาประดิษฐ์อาจประเมินผลลัพธ์ได้ แต่ไม่อาจประเมินความรับผิดชอบในกระบวนการได้
AI รู้ดีว่า 'ทำอย่างไร (How)' แต่ไม่รู้ว่าควรต้องทำไป 'ทำไม' ความใฝ่รู้ที่จะพยายามเข้าใจเป้าหมายพื้นฐานของงาน กล้ายอมรับการลองผิดลองถูกเพื่อค้นหาเส้นทางใหม่ และการตัดสินใจกำหนดทิศทางไปสู่เป้าหมายนั้น เป็นสิ่งที่มีเพียงมนุษย์เท่านั้นที่ทำได้ ความรับผิดชอบไม่ใช่การมุ่งแค่ผลลัพธ์ แต่คือท่าทีที่ไม่ละทิ้งเป้าหมายระหว่างกระบวนการ คอยตั้งคำถามและสำรวจค้นหาอย่างต่อเนื่อง
ความสามารถในการค้นหาวิธีอื่นอย่างสร้างสรรค์นอกเหนือจากคู่มือและคำสั่ง ก็มีรากฐานมาจากทัศนคติที่มีความรับผิดชอบเช่นกัน
เห็นด้วยอย่างมากครับ
ความคิดเห็นจาก Hacker News
ตอนนี้รู้สึกว่าอย่างแรกอันตรายกว่ามาก ทั้งบั๊กเพ้อเจ้อ สถาปัตยกรรมที่ตัน ปัญหาความปลอดภัย ความรู้สึกเป็นเจ้าของโค้ดที่ลดลง และการสูญเสียโอกาสในการเรียนรู้
ในทางกลับกัน ถ้าใช้ AI น้อยลง แม้ผลิตภาพจะลดลง แต่ความเข้าใจเชิงลึกต่อ codebase และการฝึกฝน อาจกลายเป็นทรัพย์สินที่มีค่ากว่าในระยะยาว
สำหรับผม สิ่งที่มีค่าที่สุดคือ ไอเดียสร้างสรรค์ ที่ได้จากการลงไปคลุกกับโค้ดด้วยตัวเอง
ถ้ายกให้ AI เร็วเกินไป ก็เสียดายที่พลาดโอกาสแบบนี้
เพราะงานซ้ำๆ น้อยลง สมองก็เหนื่อยน้อยลง และสามารถโฟกัสกับปัญหายากๆ ได้ จึงคิดไอเดียที่ดีกว่าออก
หัวใจสำคัญคือ การรักษารสนิยมและมาตรฐานที่ดีเอาไว้
ถ้าเตรียมแบบแผนและเอกสารไว้ละเอียดล่วงหน้า อัตราความสำเร็จก็สูงขึ้น
ส่วนที่ยากจริงไม่ใช่การ generate โค้ด แต่คือ ขั้นตอนการวางแผนและออกแบบ
แต่การใช้ LLM ช่วยทำเอกสารหรือเขียน boilerplate นั้นประหยัดเวลาได้มาก
บางคนพยายามทำแอปให้เสร็จในรวดเดียว บางคนใช้แค่ระดับ autocomplete ธรรมดา
เพราะมีวิธีใหม่ๆ โผล่มาเรื่อยๆ สิ่งที่ดีที่สุดคือ เปิดใจลองหลายแนวทาง
เทคโนโลยีใหม่ควร ทดสอบในหน่วยเล็กและค่อยๆ ขยายแบบเป็นขั้นเป็นตอน อยู่แล้ว
ปริมาณการใช้ AI ที่ถูกต้องคือ ‘เท่าที่ผ่านการพิสูจน์แล้ว’
การพยายามลากการถกเถียงนี้ไปในทางแบบ การเดิมพันของปาสกาล เป็นเรื่องน่าเศร้า และมักเป็นตรรกะของคนที่กำลังพยายามขายอะไรบางอย่าง
ถึง AI จะเขียนโค้ดได้ดี แต่ รูปแบบความล้มเหลวที่มองไม่เห็น อย่างข้อผิดพลาดเล็กน้อยในการคำนวณภาษีต่างหากที่อันตรายที่สุด
ตัวเลขผิดอาจถูกสะท้อนเข้าไปในระบบบัญชีจริงอย่างเงียบๆ
เพราะงั้นจึงใช้ AI แค่เป็น เครื่องมือ autocomplete ขั้นสูง — สถาปัตยกรรมและโดเมนลอจิกออกแบบเอง และใช้มันกับโค้ดซ้ำๆ หรือการทำ test scaffolding เท่านั้น
สุดท้ายปัญหาไม่ใช่ “โค้ดที่ AI เขียน” แต่คือ โค้ดที่ผมเองยังไม่เข้าใจ
LLM เขียนฟังก์ชันได้เก่ง แต่ตัดสินใจไม่ได้ว่าต้องมีฟังก์ชันอะไรบ้าง
สถาปัตยกรรมของโปรเจกต์จริงนั้นถูกสร้างขึ้นจากการ ชนกับคอขวดของโลกจริง
สิ่งที่ AI ช่วยมีแค่ความเร็วในการลงมือทำ ส่วนการตัดสินใจเชิงโครงสร้างยังเป็นหน้าที่ของมนุษย์ทั้งหมด
โดยเฉพาะ บั๊กเชิงโดเมน เป็นสิ่งที่ LLM ไม่มีทางจับได้
ท้ายที่สุดมนุษย์ต้องรับผิดชอบทั้งสถาปัตยกรรมและความรู้โดเมน
ถ้าสั่งมันแค่ ‘เขียนโค้ด’ อย่างเดียว มันก็ย่อมทำไม่ได้อยู่แล้วเพราะนั่นไม่ใช่เป้าหมาย
ตลอด 1 ปีที่ผ่านมา ผมเรียนรู้ทั้ง การออกแบบซอฟต์แวร์และ Vibe coding ไปพร้อมกัน
ผมอ่านหนังสือหลายเล่มเกี่ยวกับ DDD, Clean Architecture, Agile และกลายเป็นวิศวกรที่ดีขึ้นมาก
ต่อให้ใช้ AI ความรับผิดชอบต่อโค้ดก็ยังเป็นของผม
เราสามารถเติบโตทั้งสองด้านไปพร้อมกันได้
ต้องใช้เวลาและการฝึก แต่คุ้มค่าที่จะเรียนรู้ และไม่ได้มาแทนทักษะอื่น
เพราะสิ่งที่ LLM ทำได้ไม่ดีคือการตัดสินใจระดับสูงและการออกแบบโครงสร้าง
ระบบที่ออกแบบมาดีจะดึงประสิทธิภาพของ AI ออกมาได้สูงสุด
อีกทั้งการ เรียนรู้พาราไดม์ใหม่ๆ ยังช่วยให้เราตัดสินและปรับปรุงโค้ดที่ LLM สร้างได้ดีขึ้น
เทคนิคอย่าง BDD, PBT และ model checking เป็นเครื่องมือที่ช่วยให้ AI coding ปลอดภัยขึ้น
ภายนอกดูเหมือนชนะ แต่จริงๆ แล้วคือ ชัยชนะที่ปลอมตัวมาเป็นความพ่ายแพ้
มีคนเปรียบเปรยคำบรรยายนั้นว่าเหมือน ช่วงพุ่งขึ้นและร่วงลงของยาเสพติด
ถ้าจะใช้ LLM ให้ได้ผลจริง ต้องมีกล้ามเนื้อของทั้งสามบทบาทนี้ครบ
ถ้าคุณวาดภาพ UI/UX ที่ต้องการได้ชัด แม้โมเดลปัจจุบันก็ให้ผลลัพธ์ที่ดีพอได้
ตรงกันข้าม พรอมป์ต์แบบ “ช่วยทำคร่าวๆ ให้หน่อย” นั้นอันตราย
ต้องใช้งาน AI เหมือน ชุดเกราะเมคาขั้นสูง — เมื่อมนุษย์อยู่ในลูป มันถึงจะเร็วจริง
ความเร็วของการพัฒนาเทคโนโลยีสูงมาก จนสิ่งที่ปีก่อนยังยาก วันนี้กลายเป็นเรื่องเล็กไปแล้ว
แม้แต่เครื่องมือ AI ภายในที่เคยใช้ก็ยังถูกแทนที่ด้วย โมเดลโอเพนซอร์ส
ตอนนี้ให้ความรู้สึกเหมือนเป็นช่วงเวลาแบบ “Don’t Look Up เวอร์ชัน AI” — ทุกคนต้องรีบจัดวางตัวเองใหม่ให้เข้ากับยุค AI ก่อนจะสายเกินไป
เพื่อนคนหนึ่งสร้างผลิตภัณฑ์ด้วย Cursor อยู่ 3 เดือน แต่มีแต่ฟีเจอร์เยอะๆ และใช้งานจริงไม่ได้
ท้ายที่สุดปัญหาคือ ไม่มีคนที่เข้าใจโค้ด
แค่ sanity check ทางความคิด ขั้นพื้นฐานก็ยังไม่ทำ เป็นเรื่องที่เข้าใจยาก
ไม่สามารถทำการนามธรรมที่มีประโยชน์ การแยกเป็นโมดูล และการปรับปรุงโครงสร้างโค้ดได้
>> เห็นด้วยครับ