- มีนักพัฒนาบางส่วนที่ยังประสบปัญหาในการสร้าง คุณค่าที่ชัดเจน จากการใช้ Coding LLM
- ผู้ใช้บางรายยังไม่พอใจกับ คุณภาพของผลลัพธ์ ที่ LLM สร้างขึ้น
- ในกรณีของ ข้อกำหนดที่เฉพาะเจาะจง หรือปัญหาที่ซับซ้อน LLM มักให้ผลลัพธ์ได้ไม่ถึงความคาดหวัง
- ในทางกลับกัน สำหรับ งานอัตโนมัติ แบบง่าย ๆ หรืองานที่ทำซ้ำ กลับยังให้ความสะดวกได้ในระดับหนึ่ง
- นักพัฒนากำลังมองหาวิธีปรับปรุงผ่าน prompt engineering และการปรับเวิร์กโฟลว์
พูดคุยถึงความยากในการใช้ Coding LLM และวิธีปรับปรุง
คุณค่าที่ยังมีข้อจำกัดของ LLM
- ช่วงหลังมานี้ นักพัฒนาจำนวนมากกำลังทดลองใช้ Coding LLM อย่าง ChatGPT, GitHub Copilot และ Claude ในหลายรูปแบบ
- แต่ผู้ใช้จำนวนไม่น้อยกลับพบว่ายังไม่รู้สึกถึง การเพิ่มผลิตภาพอย่างเป็นรูปธรรม ตามที่คาดหวัง
- โดยเฉพาะในงานอย่างการเขียนอัลกอริทึมที่ซับซ้อน การจัดโครงสร้างโค้ดขนาดใหญ่ หรือการออกแบบสถาปัตยกรรมของโปรเจกต์ โค้ดที่ LLM แนะนำมักแยกส่วนหรือไม่มีประสิทธิภาพ
ความไม่พอใจต่อคุณภาพของผลลัพธ์
- นักพัฒนาบางส่วนระบุว่าโค้ดที่ LLM ให้มามี บั๊ก หรือให้ผลลัพธ์ที่ไม่แม่นยำเพราะเข้าใจบริบทได้ไม่เพียงพอ
- หลายครั้งคำอธิบายหรือการวิเคราะห์ก็ยังไม่เพียงพอ หรือโค้ดไม่สะท้อนความซับซ้อนและบริบทของโปรเจกต์ได้อย่างเหมาะสม
การช่วยเหลือในงานที่ใช้งานง่าย
- ในด้าน ระบบอัตโนมัติระดับพื้นฐาน เช่น การสร้างโค้ดสั้น ๆ งานที่ทำซ้ำ หรือการแก้ปัญหาไวยากรณ์ง่าย ๆ ยังเห็นความสะดวกได้อย่างชัดเจน
- การนำไปใช้กับงานประจำอย่าง unit test, refactoring หรือการปรับสไตล์โค้ด ได้รับการประเมินว่าใช้งานได้ดี
ความพยายามเพื่อการปรับปรุง
- นักพัฒนาบางคนกำลังนำเทคนิค prompt engineering มาใช้อย่างจริงจังเพื่อให้ได้ผลลัพธ์ที่ดีกว่าเดิม
- หลายคนกำลังทดลองรูปแบบการใช้ LLM ที่เหมาะกับเวิร์กโฟลว์ของตนเอง รวมถึงการผสานกับเครื่องมือโอเพนซอร์สหลายตัว
บทสรุปและสิ่งที่ได้เรียนรู้
- ณ ตอนนี้ หลายคนยอมรับว่า LLM ยังไม่สามารถเป็นทางออกแบบ万能สำหรับทุกความต้องการด้านการพัฒนาได้
- ชุมชนและนักพัฒนากำลังแบ่งปันประสบการณ์ร่วมกัน เพื่อค้นหาทั้ง กลยุทธ์การใช้งานที่มีประสิทธิภาพ และแนวทางรับมือกับข้อจำกัดเหล่านี้
1 ความคิดเห็น
ความเห็นจาก Hacker News
รู้สึกเหมือนว่านักพัฒนามีอยู่สองประเภท ประเภทหนึ่งคือคนที่พูดว่า LLM เป็นซูเปอร์พาวเวอร์เต็มรูปแบบสำหรับการเขียนโค้ด และอ้างว่าประสิทธิภาพการทำงานเพิ่มขึ้น 100 เท่า ส่วนอีกประเภทมองว่ามันเป็นเครื่องมือที่ค่อนข้างจุกจิก ต้องคอยลงแรงและประคับประคองมาก กว่าจะได้ผลลัพธ์ธรรมดา ๆ ออกมา แต่ถ้า LLM ช่วยเพิ่มผลิตภาพแบบพลิกโลกให้กับคนกลุ่มแรกได้จริงขนาดนั้น ก็อดสงสัยไม่ได้ว่าทำไมคนเหล่านั้นยังไม่กวาดตลาดและถล่มคู่แข่งไปหมดแล้ว
เวลาทำงานแบบกรีนฟิลด์ ฉันรู้สึกว่าผลิตภาพเพิ่มขึ้นได้ถึง 100 เท่าจริง ๆ จาก LLM ตัวอย่างเช่น การเพิ่มโครงสร้างพื้นฐานให้แอป React อย่างหลายหน้า, Redux store, auth ฯลฯ มันปั่นออกมาให้ได้ในไม่กี่นาที แค่บอกว่า "เพิ่ม X ให้หน่อย" ส่วนใหญ่ก็ได้ผลลัพธ์ที่ดี แต่พอเป็นการดูแลระบบเดิม การเพิ่มฟีเจอร์ซับซ้อน หรือสถานการณ์ที่ความรู้โดเมนสำคัญ LLM กลับแทบไม่มีประโยชน์ มันดีสำหรับ autocomplete โค้ดหรือช่วยเติมฟังก์ชัน แต่พอถึงขั้นทำฟีเจอร์ทั้งก้อน มันชนเพดานได้ง่าย ในกรณีแบบนี้ เวลาที่ใช้สั่ง LLM กับเวลาที่ฉันเขียนเองแทบพอ ๆ กัน ดังนั้นปกติฉันจะเขียน stub code ตามโครงสร้างที่ต้องการไว้ก่อน แล้วให้ LLM เติมแค่ช่องว่าง คนที่พูดว่ามันเพิ่มผลิตภาพ 100 เท่า น่าจะยังเจอแต่ส่วนที่ง่าย หรือยังไม่ชนกับความยากจริง ๆ ในความเป็นจริง งาน 90% มักง่าย และ 10% สุดท้ายต่างหากที่โหดจริง ซึ่ง LLM ทำส่วนนั้นไม่ได้ดี
พูดแบบประชดนิด ๆ คนที่บอกว่าผลิตภาพเพิ่ม 100 เท่า จริง ๆ แล้วคือเอาตัวเลขเล็ก ๆ ไปคูณ 100 มากกว่า LLM ช่วยมหาศาลในขั้นรีเสิร์ช ตัวอย่างเช่น ไม่นานมานี้ฉันต้องเขียนโค้ด linear algebra ที่เฉพาะทางมากสำหรับบางโดเมน และใช้ไลบรารีอย่าง LAPACK ไม่ได้เลยต้องเขียนเอง ในสถานการณ์แบบนี้ การใช้ LLM แทนหนังสืออ้างอิงแล้วให้มันสรุปข้อมูลที่ต้องการให้ทีเดียว ช่วยย่นเวลาในการค้นคว้าได้ 100 เท่าจริง แต่พอให้ LLM เขียนโค้ดจริง มันแอบใส่ความผิดพลาดละเอียด ๆ ที่ถ้าไม่ใช่ผู้เชี่ยวชาญอาจมองไม่ออก รุ่นน้องอาจปล่อยผ่านได้เลย ฉันให้ความสำคัญกับการรีวิวโค้ดมาก ดังนั้นต่อให้ LLM ดีขึ้นอีก ความเร็วในการเขียนโค้ดเองคงไม่ได้เพิ่มขึ้นมากนัก แต่ในขั้นสำรวจและสรุปเพื่อหาว่าควรเขียนโค้ดแบบไหน มันช่วยเร่งความเร็วได้มาก สุดท้ายแล้วคุณค่าที่แท้จริงของโลกคือการสร้างสรรค์และนวัตกรรม ซึ่งฉันคิดว่ายังเป็นหน้าที่ของมนุษย์ LLM จะเป็นผู้ช่วยสำคัญก็จริง แต่โค้ดมูลค่าสูงก็ควรเขียนเอง
จริง ๆ แล้วบางคนก็ไม่ได้อยู่ในสองกลุ่มนั้น ไม่ถึงกับ 100 เท่า แต่ก็ไม่ได้ฝืนใช้ขนาดนั้น ฉันเขียนโค้ดแบบมืออาชีพมาเกิน 30 ปี และตลอดเวลาก็ต้องคอยค้นอะไรบางอย่างอยู่เสมอ ลืมภาษาหรือไวยากรณ์เฉพาะบ่อยมากด้วย เพราะหลายงานต้องสลับใช้หลายภาษา เมื่อก่อนก็ต้องคุ้ย reference book, manual หรือบางทีก็แหล่งข้อมูลที่ลำบากกว่านั้น พอมีเสิร์ชเอนจินอย่าง Google ก็ดีขึ้นหน่อย แพลตฟอร์มอย่าง Stack Overflow ก็มีประสิทธิภาพยิ่งกว่า ตอนนี้ LLM ก็เป็นอีกก้าวหนึ่ง บางครั้งคำแนะนำจาก autocomplete ก็คือเบาะแสที่ฉันกำลังหาอยู่พอดี แน่นอนว่าสิ่งที่ไม่จำเป็นก็ข้ามได้ แต่ข้อดีคืออินเทอร์เฟซแบบแชตทำให้ถามตอบได้โต้ตอบกว่าการค้นหาผ่าน Google หรือ SO มาก
ฉันกำลังเรียนคณิตศาสตร์ด้วย Math Academy, ChatGPT และ YouTube โดยเฉพาะ 3Blue1Brown และช่องแนวนี้ ถ้าไม่มีชุดเครื่องมือนี้คงทรมานมาก แต่ตอนนี้กลับสนุก ตอนที่เคยเรียนคอร์สคล้ายกันที่ University of Amsterdam สมัยก่อน ChatGPT ยังไม่ฉลาดเท่านี้ เลยลำบากกว่ามาก ChatGPT ตอบคำถามที่แม้แต่ครูก็อาจตอบยากได้ ซึ่งเหมาะมากกับคนอย่างฉันที่ต้องเข้าใจบริบททางวัฒนธรรมของคณิตศาสตร์ถึงจะอินและแก้ปัญหาแบบสร้างสรรค์ได้ เช่น ฉันเคยถามว่าทำไมมุมถึงใช้ตัว m มันก็บอกว่ามาจากคำว่า measure ในเชิงประวัติศาสตร์ ทำให้ตอนนี้ฉันกลับไปโฟกัสที่แก่นของคณิตศาสตร์ได้อีกครั้ง สูตรคำนวณความแปรปรวนแบบลัดก็อธิบายให้เข้าใจง่ายด้วย มันไม่ใช่เครื่องมือยึดครองโลกอะไรหรอก แต่ช่วยให้ฉันได้เรียนรู้สิ่งที่เดิมอาจไม่มีทางได้เรียน แน่นอนว่า YouTube กับ Math Academy ก็มีบทบาทมากเช่นกัน
LLM ให้ซูเปอร์พาวเวอร์กับคนที่รู้กว้างหลายด้าน แต่ไม่ได้เป็นผู้เชี่ยวชาญทุกเรื่อง ถ้าคุณเจาะลึกอยู่ในโดเมนเดียวและทำแค่นั้นตลอด มันอาจไม่ค่อยมีประโยชน์ ตัวอย่างเช่น ในสถานการณ์ที่แต่ละโปรเจกต์ต้องใช้เรื่อง deploy แค่ครั้งเดียว จนไม่มี specialist ด้านนี้เฉพาะ การใช้ LLM ช่วยเขียน Dockerfile นั้นยอดเยี่ยมมาก มันยังช่วยแก้ syntax error เล็ก ๆ น้อย ๆ หรือปัญหาจุกจิกได้เร็วกว่ากูเกิลอีกด้วย การให้ LLM วิเคราะห์ architectural trade-off แล้วเราค่อยตัดสินใจเอง ก็ช่วยเพิ่มผลิตภาพได้เหมือนกัน แต่ต้องบีบขอบเขตใน prompt ให้ดีเพื่อกันไม่ให้มันทำเรื่องโง่ ๆ และในความเป็นจริงมันก็ยังชอบแต่ง API ที่ไม่มีอยู่จริงหรือทำพลาดแบบไม่น่าเชื่ออยู่เสมอ จึงต้องแก้ไปมาเป็นรอบ ๆ ถึงอย่างนั้นต่อให้ต้องวนแก้ ก็ยังได้เปรียบด้านความเร็วอยู่
ฉันเองก็ใช้ LLM หลายแบบ ช่วยทั้งดีบักเรื่องเล็ก ๆ, shell script, เขียนโค้ด, ถามคำถาม ฯลฯ เรื่องส่วนตัวฉันใช้ทั้ง Claude, OpenAI รวมถึง Google หรือ Perplexity แล้วเลือกตัวที่ให้ผลดีที่สุด เรื่องงานก็ใช้ Claude, OpenAI, Google ผ่าน VSCode กับ Copilot หรือแพลตฟอร์มภายในบริษัท และลอง Copilot Studio อยู่บ้าง ทำงานแบบนี้มาเกินปีครึ่งแล้ว ไม่ได้ใช้ทุกเครื่องมืออย่างต่อเนื่องทั้งหมด แต่ภาพรวมของฉันคือแบบนี้ แน่นอนว่า LLM ทำให้ผลิตภาพดีขึ้น ฉันได้ลองหลายภาษาโปรแกรม เข้าใจหัวข้อต่าง ๆ ดีขึ้น และมีบางงานที่ง่ายขึ้นมากจริง ๆ แต่ไม่ว่ารุ่นโมเดลหรือเวอร์ชันไหนก็ตาม พองานเริ่มซับซ้อน ต้องเดินทางของตัวเอง หรือเกินระดับการประกอบชิ้นส่วนธรรมดา ๆ มันจะพังเหมือนกันหมด บางครั้งเวลาที่เสียไปกับการแก้ผลลัพธ์มั่วของ LLM ก็กลบเวลาที่ประหยัดได้ในช่วงแรกไปหมด ถ้าจะสรุปแบบซื่อสัตย์ตอนนี้ LLM มีประโยชน์กับ autocomplete โค้ดเล็ก ๆ, การดีบัก, การอธิบาย แค่นั้น มันยังไม่คุกคามงานของเราในทันที
เวลาเรียนไลบรารี, API หรือภาษาใหม่ ๆ LLM ช่วยได้มากจริง ๆ เช่น วิธี render ข้อความใน OpenGL ถ้าถาม LLM ตรง ๆ มักเร็วกว่าการไปอ่านเอกสารทางการมหึมาที่กระจัดกระจายมั่วซั่ว หรือเวลาต้องเขียน boilerplate ที่ซ้ำซากน่าเบื่อและไม่มีโค้ดเดิมให้ดูเป็นตัวอย่าง LLM ก็มีประโยชน์ แต่ในส่วนโค้ดเฉพาะตัวของบริการฉัน ซึ่งเป็นสิ่งที่ฉันมองว่าเป็น 'งานจริง' นั้น LLM ไม่ได้มีประโยชน์สูงมากในความหมายของการ "เขียนโค้ดแทน" ในฐานะวิศวกรอาวุโส เวลาที่หมดไปกับการเขียนโค้ดจริง ๆ มีน้อยมาก สิ่งสำคัญคือการออกแบบโครงสร้าง, refactor legacy, ปัญหาประสิทธิภาพ, การดีบักบั๊กหายาก ฯลฯ LLM เร่งได้แค่ความเร็วในการเขียนโค้ดซ้ำ ๆ ดังนั้นถ้าคุณไม่ได้เริ่มโปรเจกต์ใหม่จากศูนย์ทุกสัปดาห์ มันก็อาจไม่ได้มีประโยชน์มากนัก ถ้าทุกวันนี้ยังต้องเขียน boilerplate เยอะอยู่ บางทีควรคิดถึงวิธีแก้ที่ต้นเหตุอย่างอื่นด้วย ไม่ใช่พึ่ง LLM อย่างเดียว
ในการอ่านเอกสารทางการที่เละเทะแล้วอธิบายให้เข้าใจ LLM เก่งกว่านักเขียนโปรแกรมทั่วไปอย่างชัดเจน ในด้านนี้มันเพิ่มคุณค่าได้จริง อีกอย่างก็มีภาษาที่ boilerplate เยอะเกินไปจริง ๆ ไม่ใช่หรือ
ไม่มี silver bullet และส่วนที่ยากจริงคือการทำให้สิ่งต่าง ๆ กลายเป็นแนวคิดที่จัดการได้ Mythical man-month เป็นงานเขียนสำคัญ ควรหาอ่านเพิ่ม
ไม่มี silver bullet น่าแปลกที่พวกเรายังลืมคำแนะนำสั้น ๆ ของ Fred Brooks อยู่เรื่อย ๆ ถ้าไม่คาดหวังเกินจริง และเข้าใจว่าในข้อมูลฝึกมีโค้ดที่มีบั๊กมากมาย ดังนั้น LLM ก็ย่อมมีบั๊กตามไปด้วย การใช้งานมันจะมีประโยชน์ขึ้นมาก อย่าโยนการออกแบบทิ้งให้มันทั้งหมด งานเตรียมการอย่างการแยกฟังก์ชันควรทำเอง แล้วใช้ LLM เพื่อลดงานน่าเบื่อหรือช่วยในพื้นที่ที่ไม่คุ้นเคย แต่ถึงจะเป็นโค้ดที่ LLM สร้างให้ ถ้าจะรับผิดชอบมัน ความรู้และการตรวจสอบของเราเองก็ยังเป็นเงื่อนไขสำคัญ ต่อให้โค้ดจาก LLM ดูสมบูรณ์แค่ไหน ก็อาจมีข้อบกพร่องซ่อนอยู่ จึงต้องเรียนรู้และพัฒนาทักษะต่อไป พร้อมตั้งข้อสงสัยไว้เสมอ ต้องไม่เชื่อมันแบบหมดใจเด็ดขาด
ยิ่งปัญหามีขนาดใหญ่ขึ้น ก็ยิ่งชัดว่า LLM ใช้ไม่ได้ มันยอดเยี่ยมกับงานซ้ำ ๆ หรือการ find & replace ที่ซับซ้อน กับโค้ดแบบ routine และชัดเจน เช่น เติม CRUD methods ให้ API resource มันมีประโยชน์มาก ช่วงนี้ฉันยังลองให้ Claude Opus 4 รีวิวแพตช์ของฉันด้วย บางทีก็จับข้อผิดพลาดได้ และช่วยเตือนว่ายังมีอะไรที่ฉันควรทำ แต่พอข้ามจุดวิกฤตของความซับซ้อนเมื่อไร คุณค่าของ LLM จะตกฮวบ เช่น ถ้าต้องแก้หลายไฟล์ขนาดค่อนข้างใหญ่ คุณก็มักเริ่มอนุมานได้เองตามธรรมชาติอยู่แล้วว่าต้องแก้ไฟล์ไหนบ้าง ถึงอย่างนั้นการใช้ LLM เป็น 'rubber duck' ก็ไม่เลว ถ้า AI ทำได้ก็ดี ถ้าไม่ได้ฉันก็ทำต่อเองทันที สุดท้ายแล้ว LLM ช่วยได้แค่ช่วงต้น และงานแก้ไขส่วนใหญ่ฉันก็ต้องทำเองอยู่ดี มันช่วยวางโครงแบบคร่าว ๆ ให้ แล้วฉันค่อยปรับให้เป็นแบบที่ต้องการ ซึ่งง่ายกว่าการเริ่มจากศูนย์ ถ้า LLM แสดงชัดว่าลำบาก ฉันก็ไม่ฝืนสั่งมันต่อ ถ้ามันเดาผิดเพราะสเปกกำกวม ก็ชี้ให้เห็น และถ้ายังทำไม่ได้ก็จบที่ฉันทำเอง
ประสบการณ์ของฉันก็คล้ายกัน ฉันเห็นคุณค่าของ LLM ในจุดต่อไปนี้ มันสร้าง React component หรือหน้าเพจที่ค่อนข้างอิสระได้ดีมาก ถ้าใช้คู่กับ UI library ยอดนิยม ฟังก์ชันบริสุทธิ์ที่นิยามชัดเจน มันก็สร้างได้ค่อนข้างน่าเชื่อถือและตรวจสอบง่าย boilerplate ของเฟรมเวิร์กชื่อดังมันทำได้ง่ายและดีจริง ๆ แต่คนรอบตัวชอบเล่าว่าพวกเขามีประสบการณ์ end-to-end ที่ทรงพลังมาก ขณะที่ของฉันไม่เป็นแบบนั้นเลยจนเริ่มรู้สึกจะบ้า ต่อให้พยายามมากแค่ไหน พอเป็นฟีเจอร์เต็มหน่วย LLM จะพังแบบหมดรูป เครื่องมืออย่าง aider ยังทำฟีเจอร์ template email ง่าย ๆ บน Next.js ไม่ได้เลย ถ้าแยกงานเป็นชิ้นเล็ก ๆ แล้วสั่งทีละอย่างก็ดีขึ้นนิดหน่อย แต่โค้ดเดิมกลับยิ่งพังขึ้นเรื่อย ๆ ต่อให้อธิบายปัญหาให้ฟัง ยิ่ง prompt ต่อก็ยิ่งเพี้ยน สุดท้ายฉันเลยพยายามแก้ด้วยมือ แต่โค้ดก็เละไปหมดแล้ว
ฉันเคยถูกเพื่อนสาย vibe coder บอกว่า "มาตรฐานฉันสูงเกินไป" ฉันคิดว่า vibe coder โดยพื้นฐานแล้วไม่ได้ตรวจโค้ดจริงจัง จึงไม่มีมาตรฐานคุณภาพ ถ้า vibe coding ใช้ได้ผลจริง บริษัทอย่าง Google AI ที่มีงบ GPU, TPU มหาศาลและโมเดล AI ล่าสุด ก็น่าจะปรับปรุงผลิตภัณฑ์ได้เร็วกว่ามนุษย์แบบทิ้งห่างไปแล้ว ถ้าเรื่องนั้นเกิดขึ้นจริง งานของเราคงไม่ได้ค่อย ๆ ง่ายขึ้น แต่เราจะรู้จากข่าวใหญ่แบบไม่คาดคิดก่อน และกว่าจะมารู้ว่าต้นเหตุคือ AI ก็คงทีหลังอีกมาก
LLM เหมาะกับโค้ดใช้ครั้งเดียว สำหรับงานพัฒนา, บำรุงรักษา, ดีบัก, แก้ไข มันไม่ได้ง่ายทั้งหมด เพราะโค้ดส่วนใหญ่จริง ๆ แล้วเป็นโค้ด 'ใช้แล้วทิ้ง' มากกว่าจะเป็นผลิตภัณฑ์ จึงเหมาะกับตรงนั้น แม้จะเอาแนวคิดแบบฟาสต์ฟู้ด, โรงงานประกอบ, การผลิตอัตโนมัติมาเทียบ ก็ยังต่างกันมาก ของจากเครื่องจักรในโรงงานแม่นยำเกิน 99.99% จึงไว้ใจได้ แต่ LLM ต้องให้ฉันตรวจทุกขั้นตอนเอง และถ้าไม่ตรวจมันก็มักใช้การไม่ได้ LLM ไม่สามารถทำงานอัตโนมัติไร้คนเฝ้า 24 ชั่วโมงจนสำเร็จได้ นี่จึงเป็นเหตุผลว่าทำไมมันยังไม่แย่งงานในตอนนี้
ฉันไม่มีทางโยนปัญหาซับซ้อนทั้งก้อนให้ LLM แล้วรอรับผลลัพธ์กลับมาเด็ดขาด นั่นไม่ใช่จุดแข็งของมัน คุณค่าที่แท้จริงของ LLM คือการให้ 'คำใบ้' เพื่อช่วยให้เดินหน้าต่อได้ และข้ามส่วนที่ง่ายแต่กินเวลาไปได้ เมื่อสองสามวันก่อนฉันต้องเขียนข้อความ log และ LLM ก็เสนอรูปแบบโค้ดที่จัด format ได้สวยกว่าที่ฉันคิดไว้ทันที ทำให้งานที่ปกติใช้ 15 นาทีเสร็จอย่างยอดเยี่ยมใน 30 วินาที ความสำเร็จเล็ก ๆ แบบนี้แหละที่สะสมจนเกิดคุณค่า