- antirez ผู้ก่อตั้ง Redis ใช้งาน AI และ LLM อยู่บ่อยครั้ง แต่เชื่อว่า ความสามารถในการแก้ปัญหาของมนุษย์ ณ เวลานี้ ยังนำหน้า LLM อยู่มาก
- เขาได้สัมผัสข้อจำกัดของ LLM โดยตรงระหว่างการแก้บั๊กที่ซับซ้อนใน Redis Vector Sets
- อัลกอริทึม ที่ LLM เสนอมักหยุดอยู่ที่แนวทางมาตรฐานหรือวิธีแก้ที่ค่อนข้างง่าย
- แนวทางเชิงสร้างสรรค์ ของนักพัฒนามนุษย์ได้เปรียบในการเสนอวิธีแก้ปัญหาที่แปลกใหม่ซึ่ง LLM เข้าถึงได้ยาก
- LLM มีประโยชน์มากในฐานะ เครื่องมือยืนยันไอเดียหรือคู่สนทนา แต่ความคิดสร้างสรรค์ขั้นสุดท้ายยังเป็นของมนุษย์
บทนำ: การเปรียบเทียบระหว่างมนุษย์กับ LLM
- ผมไม่ได้มีอคติใด ๆ ต่อ AI และ LLM เลย
- ผมใช้ LLM ในชีวิตประจำวันมาอย่างยาวนาน ทั้งทดสอบไอเดีย รีวิวโค้ด และสำรวจทางเลือกต่าง ๆ
- แม้ระดับของ AI ในปัจจุบันจะใช้งานได้จริงและน่าประทับใจอย่างชัดเจน แต่ก็ขอเน้นว่า ช่องว่างกับสติปัญญามนุษย์ ยังใหญ่พอสมควร
- ช่วงหลังผมรู้สึกว่าการถกเถียงเรื่อง AI แบบสมดุลทำได้ยากขึ้นเรื่อย ๆ จึงเขียนบทความนี้ขึ้นมา
กรณีบั๊กใน Redis Vector Sets
- ไม่นานมานี้ผมกำลังแก้บั๊กที่เกี่ยวข้องกับ Vector Sets ใน Redis
- ระหว่างที่เพื่อนร่วมงานใน Redis ไม่อยู่ ผมได้เพิ่มฟังก์ชันป้องกันเพิ่มเติมสำหรับความเสียหายของข้อมูลไฟล์ (RDB/RESTORE)
- โดยพื้นฐานแล้วฟังก์ชันนี้ปิดไว้เป็นค่าเริ่มต้น และเป็นตาข่ายนิรภัยเพิ่มเติมเพื่อป้องกันความเสียหายแม้เช็กซัมจะผ่าน
- ปัญหาเกิดขึ้นจากการปรับแต่งความเร็วในการ serialize การแทนกราฟของโครงสร้างข้อมูล HNSW ลงใน RDB
- วิธีคือเก็บลิสต์การเชื่อมต่อระหว่างโหนดเป็นจำนวนเต็ม แล้วค่อยกู้กลับเป็นพอยน์เตอร์ตอน deserialize
- เนื่องจากลักษณะเฉพาะของการ implement HNSW เอง (รับประกันการเชื่อมต่อสองทาง) หากกราฟหรือหน่วยความจำเสียหาย อาจเกิดปัญหาต่อไปนี้ได้
- มีการบันทึกว่า A เชื่อมต่อกับ B แต่ B ไม่ได้เชื่อมกลับมาที่ A (เช่น ความผิดพลาดของการกำหนดหมายเลข)
- เมื่อลบโหนด B หากละเมิดการเชื่อมต่อสองทาง ก็อาจเหลือลิงก์ A→B ค้างอยู่ และภายหลังเมื่อค้นหา B->A จะเกิดบั๊ก use-after-free
- หลังโหลดข้อมูลแล้ว จึงจำเป็นต้องตรวจสอบว่าลิงก์ทั้งหมดเป็นการเชื่อมต่อแบบ 'สองทาง' จริงหรือไม่
- หากใช้อัลกอริทึมแบบตรงไปตรงมา ความซับซ้อนจะเป็น O(N^2) และพบว่าความเร็วในการโหลดข้อมูลขนาดใหญ่ (~20 ล้านเวกเตอร์) เพิ่มจาก 45 วินาทีเป็น 90 วินาที หรือช้าลงเป็นสองเท่า
การนำ LLM มาใช้และข้อจำกัด
- ผมคุยกับ Gemini 2.5 PRO เพื่อถามหาวิธีที่มีประสิทธิภาพกว่า และตรวจสอบข้อเสนอของ LLM
- ข้อเสนอแรกของ LLM: เรียงลำดับลิสต์โหนดเพื่อนบ้านแล้วใช้ binary search (เป็นวิธีที่รู้จักกันดีอยู่แล้ว)
- ผมขอไอเดียเพิ่มเพราะวิธีนี้ช่วยได้ไม่มาก แต่ก็ไม่ได้คำตอบที่ดีกว่าเดิม
- วิธีทางเลือกที่ผมเสนอ: ใช้แฮชเทเบิลเพื่อลงทะเบียนและลบคู่ลิงก์ (A:B:X โดยจัดเรียงและตัดความต่างระหว่างสองทิศทางออก)
- LLM ก็มองว่าเป็นไอเดียที่ดี แต่ชี้ข้อเสียเรื่องประสิทธิภาพของการสร้างคีย์และการแฮช
- ผมเสนอเพิ่มเติมว่าให้จัดการคีย์ความยาวคงที่ด้วย
memcpy โดยไม่ใช้ snprintf เพื่อเพิ่มประสิทธิภาพ
ความคิดสร้างสรรค์ของมนุษย์ vs ข้อจำกัดของ LLM
- ผมเสนอไอเดียใช้งานเทคนิค XOR กับ accumulator โดยไม่ต้องใช้แฮชเทเบิล
- นำคู่พอยน์เตอร์ (รวมข้อมูลเลเวล) มา XOR สะสมไว้ใน accumulator; ถ้าเชื่อมต่อกันสองทางถูกต้องค่าจะหักล้างกันเป็น 0 แต่ถ้าขาดหายจะเหลือแพตเทิร์นไว้
- อย่างไรก็ตาม มีการชี้ถึงความเป็นไปได้ของการชนกันและความสามารถในการคาดเดาพอยน์เตอร์ (ซึ่ง LLM ก็เห็นด้วย)
- การปรับปรุงเพิ่มเติม: ผสาน seed แบบสุ่ม/การแฮช (murmur-128 และ seed จาก urandom) แล้วใช้ XOR กับ accumulator 128 บิต
- ตอนท้ายสามารถตัดสินได้ว่าการเชื่อมต่อสองทางสมบูรณ์หรือไม่จากการดูว่าค่า accumulator เป็น 0 หรือไม่
- LLM ประเมินว่าวิธีนี้ทั้งมีประสิทธิภาพและมีความทนทานสูงต่อข้อผิดพลาดทั่วไปและผู้โจมตีจากภายนอก
บทสรุป
- สุดท้ายผมจบการวิเคราะห์เพื่อใช้ตัดสินใจว่าจะนำวิธีนี้มาใช้หรือไม่โดยพิจารณาจากความน่าเชื่อถือ
- กรณีนี้ยืนยันว่า แนวทางเชิงสร้างสรรค์และไม่เป็นมาตรฐานของนักพัฒนามนุษย์ เหนือกว่าคำตอบที่มีข้อจำกัดซึ่ง LLM มอบให้
- LLM มีประโยชน์อย่างมากในฐานะ เครื่องมือยืนยันไอเดียและคู่สนทนาทางปัญญา ('smart rubber duck')
- อย่างไรก็ตาม ในด้าน ความสามารถในการสร้างวิธีแก้ปัญหาเชิงสร้างสรรค์ขั้นสุดท้าย มนุษย์ยังมีความได้เปรียบอย่างชัดเจน
7 ความคิดเห็น
อีกไม่นาน
redisก็คงจะตามไม่ทันแล้วให้ความรู้สึกเหมือนเอาจักรยานไปแข่งกับการวิ่งเลยนะครับ
antirez เป็นนักพัฒนามนุษย์ระดับท็อป 1% ครับ ผมคิดว่านักพัฒนามนุษย์ 1% นั้นจะยังคงเหนือกว่า LLM ต่อไป แต่สำหรับอีก 99% จะเป็นอย่างไรนั้นผมก็ไม่แน่ใจเหมือนกัน
ผมเคยพยายามแก้ปัญหาผ่าน AI แต่ล้มเหลวทั้งหมด สุดท้ายก็ต้องกลับมาแก้ปัญหาด้วยตัวเองอยู่หลายครั้ง
ที่ LLM ดูมีคุณภาพสูงและเหมือนมีความคิดสร้างสรรค์ ก็เพราะมันได้เรียนรู้จากงานเขียนลักษณะนั้น และเพื่อยกระดับผลลัพธ์ให้ดีขึ้น ก็มีนักวิทยาศาสตร์จำนวนมากช่วยตรวจสอบความรู้นั้นพร้อมทั้งยกระดับคุณภาพของข้อมูลสำหรับการฝึกฝนด้วย
แต่เมื่อเวลาผ่านไป เทรนด์ก็เปลี่ยนไป หรือในแต่ละสถานการณ์ก็ต้องการความคิดสร้างสรรค์ที่แตกต่างกัน สุดท้ายแล้วคนที่ใช้งานก็คงต้องแสดงความคิดสร้างสรรค์ให้เหมาะกับสถานการณ์ของตัวเองอยู่ดีไม่ใช่หรือครับ..
ความเห็นจาก Hacker News
ผมรู้สึกว่าตรงกับประสบการณ์ของตัวเองเป๊ะ จริง ๆ แล้วคุณค่าหลักที่ LLM assistant มอบให้ผมคือการทำหน้าที่เป็น ‘rubber duck’ ที่ค่อนข้างฉลาด บางครั้ง ‘เป็ด’ ตัวนี้ก็โต้แย้งความเห็นของผมได้ด้วย และถึงขั้นช่วยขัดเกลาความคิดของผมให้คมขึ้นกว่าเดิม (rubber duck debugging คืออะไร?) แต่ผมคิดว่าคำถามสำคัญที่ทุกคนอยากข้ามไปคือ ‘คุณค่าแบบนี้จะยังอยู่ต่อไปอีก 2 ปีข้างหน้าหรือเปล่า?’ ซึ่งผมเองก็ไม่รู้คำตอบเหมือนกัน
สำหรับผม LLM ไม่ใช่ rubber duck แต่เป็นเหมือน ‘เครื่องให้คำตอบผิด’ มีคำพูดกันว่าหนทางที่ดีที่สุดในการได้คำตอบบนอินเทอร์เน็ตคือโพสต์คำตอบที่ผิด สำหรับผมมันทำหน้าที่นั้นพอดี เวลาให้ LLM ทำงานง่าย ๆ แต่จุกจิกน่ารำคาญ มันมักจะให้ผลลัพธ์ผิดแบบมหาศาล จนผมหงุดหงิดและลุกขึ้นมาทำเองด้วยพลังแห่งความโมโห
เป็นเป็ดที่มั่นใจเกินเหตุ แสดงความมั่นใจมากเกินความสามารถจริง ผมเห็นคนจำนวนมากคุยกับ LLM แล้วหลงทาง
สำหรับผม LLM คล้ายกับนักพัฒนาจูเนียร์ที่ทำงานใต้ผม ซึ่งรู้ API ดีแต่ขาดสามัญสำนึกด้านสถาปัตยกรรม ผมต้องตรวจงานราว 3-4 รอบก่อนจะส่ง PR ส่วนใหญ่ให้ทีมรีวิว เพราะกังวลว่าจะมีความผิดพลาดประหลาด ๆ ข้อดีคือมันช่วยให้ผมเอาสมองไปโฟกัสเรื่องอื่นได้
คุณค่าแบบนี้จะยังอยู่ในอีก 2 ปีไหม? สำหรับผม ประเด็นใหญ่กว่าการ ‘ข้ามบทสนทนานี้ไป’ คือ ‘เราจะไปถึงอีก 2 ปีข้างหน้าแบบนั้นได้หรือเปล่า?’ โลกตอนนี้ไม่มั่นคงเกินกว่าจะคาดเดาได้แม้แต่ในอีก 6 เดือน
สำหรับผม LLM ให้ความรู้สึกเหมือนเพื่อนร่วม pair programming เป็นคู่สนทนาให้ลองคุยไอเดียด้วย เป็นคนช่วยรีวิวโค้ดและเสนอทางเลือกอื่น ๆ และผมก็ได้เรียนรู้จากการเห็นมันใช้ฟีเจอร์ที่ผมไม่เคยรู้มาก่อน
พออ่านคอมเมนต์ในนี้ไปเรื่อย ๆ จะรู้สึกว่าทุกคนแอบฝากความหวังไว้กับคำพูดแนว ‘มนุษย์ยังจำเป็นอยู่’ ‘LLM ดีบักไม่ได้’ หรือ ‘LLM พาหลงทาง’ อยู่บ้าง ซึ่งแน่นอนว่ามันก็จริง แต่การสร้างโค้ดอัตโนมัติที่เมื่อ 2 ปีก่อนยังเป็นไปไม่ได้ ตอนนี้พัฒนาไปไกลมากแล้ว และยังคงเดินหน้าเร็วต่อเนื่อง ต่อให้จากนี้อัตราการพัฒนาอาจช้าลงแบบ ‘กฎพาเรโต’ ผมก็ยังคิดว่ามันจะก้าวหน้าต่อไปแน่นอน ไม่นานมานี้ผมเล่าประสบการณ์ใน r/fpga ว่าใช้ LLM ช่วยทำ testbench เวอร์ชันแรกได้สำเร็จ แต่กลับเห็นคนที่ไม่เคยลองเองปัดทิ้งแม้แต่ความเป็นไปได้ ซึ่งทำให้ผมตกใจมาก
ทัศนคติแบบนี้พบได้บ่อยมากในหมู่คนทำวิชาชีพ ผมเพิ่งเข้าไป /r/law (subreddit ด้านกฎหมาย) และสัมผัสได้ทันทีถึงบรรยากาศที่ดูแคลนคำพูดของ Dario Amodei เกี่ยวกับ AI ในวงการกฎหมาย บางทีมันอาจเป็นทั้งกลไกการปรับตัวและความเคยชินกับสภาพเดิม แต่ผมคิดว่ามันเป็นเรื่องแย่มากในแง่ความสามารถในการรับมือกับการเปลี่ยนแปลงทางเศรษฐกิจและสังคมในอนาคต
คล้ายกับสมัยที่ assembly เป็นพื้นฐาน แล้วเมื่อภาษาโปรแกรมเริ่มปรากฏขึ้น เหล่าโปรแกรมเมอร์ก็เยาะเย้ยมันว่าไม่มีประสิทธิภาพ ไม่ยืดหยุ่น และทำให้ทุกอย่างง่ายเกินไป ทั้งที่จริง ๆ ก็ไม่ได้เกี่ยวกับข้อเท็จจริงมากนัก ปรากฏการณ์แบบนี้เป็นปฏิกิริยาธรรมชาติที่แทบไม่เกี่ยวกับคุณค่าที่แท้จริงของเทคโนโลยีใหม่เลย
LLM เคยโตแบบก้าวกระโดดอยู่พักหนึ่ง แต่โมเดลช่วงหลังกลับให้ความรู้สึกเหมือนถดถอยลงด้วยซ้ำ มันให้ผลดีในการสร้าง test code แต่ถ้าใช้ LLM ลึกเกินไปกับงานอย่างการทำฟีเจอร์ใหม่กลับยิ่งแปลก ใช้กับโปรเจกต์ใหม่หรือเว็บแอปง่าย ๆ ได้ผลดี แต่กับการรีแฟกเตอร์โค้ดขนาดใหญ่หรือ legacy code รวมถึงการเพิ่มฟีเจอร์ กลับไม่ได้ผลมากนัก เช่น ผมเห็น Claude หรือ ChatGPT มั่ว API ของ D3 ทั้งชุดอยู่บ่อย ๆ
สุดท้ายแล้วคุณก็กำลังสร้างสิ่งที่จะมาแทนตัวเองอยู่ ส่วนเพื่อนร่วมงานของคุณกำลังเดินอย่างระมัดระวัง
ChatGPT-4o แสดงความสามารถยอดเยี่ยมมากในการเขียน VHDL วันนี้ผมก็ยังเจอผลลัพธ์น่าทึ่งจากการใช้มันทำต้นแบบ low-level controller อยู่เลย
บริบทที่ต้องใช้ในการเขียนซอฟต์แวร์จริง ๆ ให้ดีนั้นมีมากเกินไปสำหรับ LLM ซอฟต์แวร์คือ ‘การแปลงธุรกิจให้เป็นโค้ด’ โดยตัวมันเอง LLM จะไปรู้เงื่อนไขพิเศษสารพัดที่ฝ่ายขายสัญญากับลูกค้า หรือกฎแฝงที่แต่ละแผนกใช้กันอยู่ได้อย่างไร ขอบเขตที่ LLM แก้ได้ตอนนี้ยังเป็นเรื่องทั่วไปและค่อนข้างจำกัด ถ้าเกิน 2 คลาส หรือเกิน 20-30 ไฟล์ แม้แต่ LLM ระดับท็อปก็เริ่มหลงและเสียโฟกัส พอมันรักษาบริบทไม่ได้ ก็เกิด code churn ที่ไม่จำเป็นเยอะมาก ถ้า LLM จะมาแทนนักพัฒนาตัวจริงได้ มันต้องรับบริบทได้มากกว่านี้มาก ต้องรวบรวมบริบทจากทั้งองค์กร และต้องรักษากระแสความคิดในโปรเจกต์ระยะยาวได้ พอปัญหาเหล่านี้เริ่มถูกแก้ได้จริงเมื่อไร ค่อยเริ่มกังวลกันตอนนั้น
ทุกครั้งที่ถกกันว่า LLM จะมาแทนนักพัฒนาได้ไหม คนมักลืมว่า software engineering ในโลกจริงมีอะไรให้ทำอีกเยอะมากนอกเหนือจากการเขียนโค้ด การเขียนโค้ดเป็นแค่ส่วนเล็ก ๆ สิ่งสำคัญคือทักษะทางสังคม การวิเคราะห์ความต้องการ และการค้นหาว่าลูกค้าต้องการอะไรกันแน่ ทั้งที่บ่อยครั้งลูกค้าเองก็ยังไม่รู้ว่าตัวเองต้องการอะไร ทำให้วิศวกรต้องลำบากช่วยกันค้นหา ถ้ามนุษย์ยังยากขนาดนี้ LLM ก็ยิ่งไม่น่าจะทำได้
สุดท้ายแล้วนี่คือปัญหาเรื่อง feedback loop หรือกระบวนการวนซ้ำอย่างรวดเร็วที่ลูกค้าได้ลองใช้จริงแล้วให้ความเห็นกลับมา UI แบบแชตนั้นยอดเยี่ยมมากสำหรับ feedback loop กับลูกค้า และ agent ก็สามารถสร้างเวอร์ชันใหม่ได้อย่างรวดเร็ว LLM สามารถทำ abstraction, ระบบคอมโพเนนต์ที่หลากหลาย, การออกแบบโครงสร้างทั้งหมด, ไปจนถึงการวิเคราะห์ความต้องการได้มากพอแล้ว ประเด็นสำคัญคือความเร็วของการวนซ้ำ โมเดลมีทั้งความเสถียรและ IQ ที่ดีขึ้นเรื่อย ๆ ขณะนี้ software engineering ทั้งกระบวนการได้เข้าสู่ช่วงอัตโนมัติแล้ว อีกประมาณ 5 ปี มนุษย์ที่ไม่ได้รับการช่วยเหลือจะกลายเป็นคอขวดขนาดใหญ่ ถ้าไม่ผสานกับ AI อย่างลึกซึ้งก็จะถูกทิ้งไว้ข้างหลังแน่นอน
นี่แหละคือปัญหาที่เคยเกิดขึ้นสมัยกระแส offshoring (เอาต์ซอร์สนักพัฒนาต่างประเทศ) ในยุค 2000 ทีมต่างประเทศแก้ไขตามคำขอหรือยกประเด็นปัญหาได้ยาก จึงทำแค่ตามที่สั่ง และสุดท้ายปัญหาก็กองสะสมขึ้นเรื่อย ๆ ผมคิดว่า AI ก็จะเจอเรื่องคล้ายกัน และผลก็น่าจะออกมาคล้ายกันด้วย
LLM ไม่ได้ทำ software engineering ตั้งแต่แรกอยู่แล้ว แต่ก็ไม่ใช่ว่าจะเป็นปัญหา เพราะจริง ๆ แล้วโปรแกรมที่ประสบความสำเร็จจำนวนมากก็ทำงานได้ดีโดยไม่ต้องมี ‘software engineering’ ด้วยซ้ำ โดยเฉพาะในสภาพแวดล้อมที่ไม่มีใครสนใจโครงสร้างต้นทุน cloud ด้วยซ้ำ ตรงกันข้าม ผมคิดว่าในอนาคต คนที่มีเซนส์ทางเทคนิคแบบพาร์ตเนอร์ธุรกิจด้าน IT จะสามารถสร้างแอปทั้งตัวได้เองโดยไม่ต้องพึ่งวิศวกรซอฟต์แวร์เลย ซึ่งในวงการพลังงานสีเขียวมันเกิดขึ้นจริงทุกวันอยู่แล้ว เพียงแต่ปัญหาจะมาระเบิดตอนที่ระบบต้องบำรุงรักษา ขยายขนาด หรือเพิ่มประสิทธิภาพ เมื่อนั้นแหละเรื่องอย่าง ‘จะใช้ list หรือ generator ใน Python’ ถึงจะเริ่มสำคัญ และเป็นจุดที่ต้องการ engineering จริง ๆ
อีก 5 ปีข้างหน้า เราอาจแทบไม่ต้องออกแบบโค้ดกันแล้วก็ได้ ตอนนี้แค่เทียบกับ 1 ปีก่อน ปริมาณการพิมพ์โค้ดของผมก็ลดลงมหาศาลแล้ว แต่ถึงอย่างนั้น มันก็ยังเป็นแค่ส่วนหนึ่งของกระบวนการ ไม่ได้แปลว่านักพัฒนาจะหายไปทั้งหมด
ในอีกด้านหนึ่ง บทบาทของ ‘coder’ แบบล้วน ๆ กำลังถูกแทนที่ไปมากจริง ๆ ซึ่งนี่เป็นจุดที่ LLM ทำได้ดี หลายคนเป็นโค้ดเดอร์ที่แทบไม่ใช้สมอง ทำแค่รับ ticket แนว “รับ API นี้แล้วคืนค่านั้นออกมา” โดยไม่เข้าใจความต้องการหรือวิเคราะห์อะไรเลย และส่วนนี้กำลังถูกกวาดแทนอย่างรวดเร็ว แม้ software engineering ที่แท้จริงจะเป็นอีกโลกหนึ่ง แต่ก็อย่ามองข้ามว่าความต้องการ coder แบบง่าย ๆ นั้นเคยมีสูงมาก
ประเด็นสำคัญมากคือมีเพียงมนุษย์เท่านั้นที่มีความสามารถด้านแนวคิดเชิงนามธรรมของโปรแกรมและการแก้ปัญหาอย่างสร้างสรรค์ โปรแกรมเมอร์คือสถาปนิกของตรรกะ และคอมพิวเตอร์คือสิ่งที่แปลงรูปแบบความคิดของมนุษย์ให้กลายเป็นคำสั่ง เครื่องมืออาจเลียนแบบมนุษย์และสร้างโค้ดสำหรับงานเฉพาะได้ดี แต่ยังแทนที่บทบาทการออกแบบเชิงนามธรรมระดับพื้นฐานและการสร้างระบบไม่ได้ หากวันหนึ่งโมเดลมีความสามารถไม่ใช่แค่เขียนโค้ด แต่สร้างทั้งโปรเจกต์ตามสเปกได้เลย บทบาทของนักพัฒนาก็จะเปลี่ยนไปอีกครั้ง
ต้องมองเสมอว่า ‘อะไรดีกว่า’ นั้นขึ้นอยู่กับแต่ละงาน LLM ตอนนี้เก่งกว่าผมมากแล้วในงานที่ซ้ำ ๆ และยึดตามรูปแบบตายตัว เช่น การจัด syntax ของ CSS ให้ถูก หรือวิธีเรียกใช้ไลบรารียอดนิยม เรื่องจุกจิกแบบนี้เมื่อก่อนกินเวลาผมมาก แต่ตอนนี้แทบจัดการได้ทันที เลยพอใจมาก
แต่ถ้าเป็นเรื่อง styling พื้นฐานจริง ๆ (ลึกกว่าระดับ CSS พื้นฐาน) ผลงานของ LLM กลับไม่ดีนัก ถ้าอธิบายเอฟเฟกต์ให้ชัดเจนได้ยาก หรืองานมีความละเอียดอ่อน มันก็มักให้ผลลัพธ์ที่สำคัญที่สุดไม่ได้ และมักติดอยู่กับวิธีเดียว
ในสิ่งที่ผมไม่เก่ง (SQL) LLM ดีกว่าผมมาก แต่ในสิ่งที่ผมรู้ดี (CSS) กลับแย่กว่า ตรงนี้เลยเห็นเกณฑ์ได้ชัด
ผมเห็นด้วยทั้งกับคำว่า “มันดีกว่านักพัฒนาส่วนใหญ่” และกับความคิดที่ว่า LLM ดูเก่งกว่าเพราะคนจำนวนมากทำ CSS ไม่เป็น จริง ๆ แล้วหลายคนเกลียด CSS เลยไม่เรียนมัน และฝืนใช้ไปงั้น ๆ จึงทำให้เกิดความเข้าใจผิด ถ้าบริษัทไม่มีงบจ้างผู้เชี่ยวชาญ CSS จริง ๆ LLM ก็พอเป็นทางเลือกได้ แต่ถ้ามีกำลังจะหาคนที่เก่งจริงมาใช้ LLM ก็เทียบกันไม่ได้อยู่แล้ว สุดท้ายคู่แข่งที่แท้จริงของ LLM ก็คือนักพัฒนาที่ฝีมือไม่ดี
การทำ autocomplete ด้วย LLM มีประโยชน์มากในภาษาหลักหรือขอบเขตที่เราไม่ได้รู้แม่นนัก แต่ถ้าไม่พัฒนาความสามารถแบบ ‘จำได้โดยอัตโนมัติ’ และพึ่ง LLM อย่างเดียว ก็เสี่ยงจะขาดทักษะในการประเมินสิ่งที่เครื่องมือนี้แนะนำ และจบลงกับวิธีแก้ปัญหาที่คุณภาพต่ำ
ผมดีใจที่มีคนกังวลเรื่อง ‘โค้ดที่ดี’ กันมาก แต่ก็กลัวว่ามันอาจไม่มีความหมายในโลกจริง เพราะอุตสาหกรรมซอฟต์แวร์ถูกโลกธุรกิจกลืนกินมานานแล้ว และผมเองก็ไม่แน่ใจด้วยซ้ำว่ามันเริ่มตั้งแต่เมื่อไร (ตั้งแต่ Bill Gates เขียน open letter ในปี 1976 หรือเปล่า?) ปัญหาที่แท้จริงคือผู้ถือหุ้นและผู้บริหารสนใจโค้ดน้อยลง ขอแค่กำไรขึ้นก็พอ ถ้าไม่มีแรงต้านทางวัฒนธรรมจากนักพัฒนาหรือผู้ใช้ โครงสร้างนี้ก็คงดำเนินต่อไป
เรื่องที่ว่าถ้าไม่มีแรงต้านทางวัฒนธรรมจากนักพัฒนาหรือผู้ใช้ก็จบกันนั้น ผมอยากเสริมว่ายังมีบริษัทที่สร้างโค้ดดี ๆ อยู่มาก และไม่ได้เละเทะกันไปหมด ปัญหาไม่ใช่แค่เรื่องคุณภาพโค้ด แต่เป็นคำถามเชิงจริยธรรมว่าคุณยอมรับเป้าหมายธุรกิจแบบทุนนิยมหรือไม่ ความสมดุลระหว่างซอฟต์แวร์ที่งดงามกับโลกความจริงต่างหากที่สำคัญที่สุด ผมเองก็เป็นทั้งนักพัฒนาและผู้ก่อตั้ง ชอบโอเพนซอร์ส ชอบ engineering แต่ก็อยากมีชีวิตที่สบายพอเหมือนกัน
โค้ดคือแรงขับของธุรกิจ โค้ดแย่ก็นำไปสู่ธุรกิจแย่ มีความต่างชัดเจนมากระหว่างทีมโฮสติ้ง (physical firewall, vmware, proxy ฯลฯ) กับ public cloud (QEMU, netfilter, อุปกรณ์เรียบง่าย ฯลฯ) ใครกลืนใคร และอนาคตจะเป็นอย่างไร ไม่มีใครทำนายได้
เมื่อคืนผมเสียเวลาไปหมดกับการงัดข้อกับ o3 เพราะทั้งชีวิตไม่เคยทำ Dockerfile มาก่อน เลยคิดว่าจะใส่ GitHub repository ให้ o3 แล้วปล่อยให้มันแก้ให้เอง สุดท้ายกลับต้องเสียเวลาหลายชั่วโมงไปกับการดีบักผลลัพธ์ของมัน มันชอบเติมสิ่งที่ไม่มีอยู่จริง ลบของที่ไม่มี หรือเอาหลายอย่างมาปนกัน มั่วแม้แต่แนวคิดพื้นฐานอย่างความต่างระหว่าง python3 กับ python สุดท้ายผมหัวร้อนเลยไปหา Google Docs อ่าน แล้วก็จัดการได้เร็วมาก บทเรียนคือ AI เป็นเครื่องมือที่ยอดเยี่ยม แต่ไม่ใช่ยาวิเศษ และต้องมีใครสักคน ‘ตื่นรู้’ คอยดูอยู่เสมอ
บริษัทที่ใช้ LLM·AI เพื่อเพิ่มผลิตภาพของพนักงานจะรุ่งเรือง ส่วนบริษัทที่พยายามแทนที่พนักงานไปเลยมีแนวโน้มจะล้มเหลว ในระยะสั้น CEO/ผู้บริหารอาจพอใจกับผลประกอบการระยะสั้น พร้อมกับค่อย ๆ กัดกินการเติบโตในอนาคตไปด้วยก็ได้
นั่นแหละคือคำตอบ ใช้ LLM เป็นผู้ช่วยของโปรแกรมเมอร์ต่างหากถึงจะเหมาะ การแทนที่แบบสมบูรณ์ทำไม่ได้ เส้นทางที่ถูกต้องคือยอมรับเทคโนโลยีอย่างพอดี
ผมว่าความคิดที่ว่าการแทนพนักงานอาจเพิ่มมูลค่าระยะสั้นและเป็นประโยชน์ต่อบริษัทก็น่าสนใจมาก กล่าวคือ ในระยะกลางถึงยาวมันอาจทำร้ายบริษัท แต่ชั่วคราวก็อาจดันราคาหุ้นขึ้นได้
code assistant เป็นเครื่องมือพื้นฐานร่วมที่จำเป็น แต่ไม่ใช่อาวุธสำหรับแทนคน ในยุคที่คู่แข่งก็ซื้อ subscription AI แบบเดียวกันได้ มันจึงแทนคนไม่ได้
แชร์ประสบการณ์จากหน้างาน - เมื่อก่อนเป็นนักพัฒนา ตอนนี้เป็นผู้จัดการแล้วแต่ก็ยังเขียนโค้ดอยู่ LLM assistant ช่วยได้ก็จริง แต่บางทีก็น่ารำคาญ เวลาอยู่ ๆ มันก็สาดข้อเสนอแนะโค้ดที่ไม่ได้คาดไว้ ทำให้ทิศทางหลุดจากความตั้งใจเดิม และยังต้องเสียเวลามารีวิวอีก คงเป็นปัญหาการตั้งค่า เพราะผมอยากเปลี่ยนค่าเริ่มต้นให้มันโผล่มาเฉพาะตอนที่ผมเรียกผ่านคำสั่งเอง สิ่งหนึ่งที่แน่นอนคือ ต่อให้จะให้ LLM เขียนทั้งโค้ดหรือทั้งฟังก์ชัน ก็ต้องผ่านการรีวิวของตัวเองอยู่ดี
ใน Zed editor มีฟีเจอร์โหมด ‘คำแนะนำแบบแผ่วเบา’ นี้อยู่ (ดูรายละเอียด) อยากให้ทุก editor มีโหมดแบบนี้
ช่วงนี้ทำหลายอย่างในสตาร์ตอัป เลยไม่ค่อยชอบ UI ที่ LLM สร้างนัก ถ้าเป็นพื้นฐานแบบ building blocks ยังมีประโยชน์ แต่ถ้าปล่อยให้ Claude จัดการ code block ยาว ๆ ทั้งก้อน ก็มักต้องแก้อยู่หลายรอบกว่าจะได้ผลลัพธ์ที่ผมต้องการ
https://freederia.com จะคงความสัมพันธ์แบบอยู่ร่วมกันไว้เช่นเดียวกับเว็บไซต์นักวิทยาศาสตร์ AI