- เป็นความจริงที่เครื่องมือ LLM ช่วยเพิ่มประสิทธิภาพการพัฒนา
- แต่ในระยะยาว เมื่อพึ่งพาเครื่องมือเหล่านี้มากขึ้น ความสามารถในการแก้ปัญหาด้วยตัวเองก็ลดลง
- ความรู้สึกสำเร็จที่ได้จากกระบวนการเขียนโค้ดหายไป และแทนที่จะมุ่งแก้ปัญหา กลับกลายเป็นการรอคำตอบจาก AI
ความหลงใหลและจิตวิญญาณแห่งความท้าทายในการพัฒนาที่อ่อนลง
- บางคนไม่ได้สนุกกับการเขียนโค้ดโดยตัวมันเอง → ในกรณีนั้น งานสายพัฒนาอาจไม่ใช่ทางที่เหมาะ
- วิศวกรที่เก่งที่สุดที่ฉันเคยพบ ต่างก็สร้างเครื่องมือหรือซอฟต์แวร์ด้วยความสมัครใจแม้ในวันหยุดสุดสัปดาห์ และไล่ตามนวัตกรรมอยู่เสมอ
- การปรับปรุงประสิทธิภาพของระบบจะทำได้ก็ต่อเมื่อมีความเข้าใจในระดับรากฐาน มิฉะนั้นก็ไม่ต่างจากการลองแบบสุ่ม
ปรากฏการณ์ 'Copilot Lag'
- 'Copilot Lag' หมายถึงภาวะที่ต้องรอคำสั่งถัดไปจาก AI
- คล้ายกับนักพัฒนามือใหม่ที่รอคำสั่งจากรุ่นพี่
- เมื่อใช้ GitHub Copilot ไปเรื่อย ๆ ก็อาจลืมแม้แต่องค์ประกอบพื้นฐานของภาษาและไวยากรณ์
- ความเร็วที่เพิ่มขึ้นในระยะสั้น ทำให้ความรู้ในระยะยาวค่อย ๆ เสื่อมถอย
LLM อาจรบกวนกระบวนการเรียนรู้
- ตอนศึกษา "Writing An Interpreter In Go" ของ Thorsten Ball แม้ Copilot จะสร้างโค้ดให้ได้ แต่ก็ไม่ได้ทำให้ได้ความสามารถในการเขียนมันขึ้นมาใหม่ด้วยตัวเอง
- ทำให้พลาดแนวคิดสำคัญอย่างการจัดการหน่วยความจำหรือการออกแบบที่ขับเคลื่อนด้วยข้อมูล
- โค้ดที่ AI สร้างขึ้นอาจดูเหมือนถูกต้องจากภายนอก แต่ถ้าไม่เข้าใจหลักการพื้นฐาน ก็แทบไม่มีความหมาย
วิธีใช้ LLM ให้มีประสิทธิภาพ
- LLM สามารถใช้ให้เป็นประโยชน์ได้เหมือนเสิร์ชเอนจิน
- สามารถอ้างอิงคำตอบของ LLM ได้ เหมือนกับเวลาค้นหาใน Stack Overflow
- แต่ LLM ไม่ได้สะท้อนความรู้ของผู้เชี่ยวชาญจริง ๆ แบบตรงไปตรงมา และสร้างคำตอบจากแพตเทิร์นที่เรียนรู้กับลำดับโทเค็น → จึงมีข้อผิดพลาดมาก
- อย่ารับคำตอบของ LLM มาใช้ตรง ๆ แต่ต้อง วิเคราะห์ว่าทำไมจึงแนะนำแนวทางนั้น
- เมื่อมีเรื่องที่ไม่รู้ ต้องค้นคว้าและเรียนรู้ด้วยตัวเอง
- เวลาศึกษาภาษาใหม่ ๆ (เช่น Zig) การจดบันทึกสิ่งที่เรียนรู้ไว้จะมีประโยชน์
- บันทึกเหล่านั้นสามารถใช้เป็นเอกสารอ้างอิงในการเรียนรู้ และยังช่วยได้เมื่อต้องแบ่งปันกับผู้อื่น
บทสรุป
- เครื่องมือ AI มีประโยชน์ แต่หากพึ่งพาอย่างมืดบอด ก็อาจให้ผลลัพธ์ตรงกันข้าม
- สิ่งสำคัญคือการเข้าใจหลักการของแนวทางแก้ปัญหาที่ AI เสนอ และมีท่าทีที่จะเรียนรู้ด้วยตัวเอง
- สุดท้ายแล้ว ประเด็นสำคัญคือการรักษาความสามารถในการแก้ปัญหาเชิงรากฐานไว้ โดยไม่พึ่งพาเครื่องมือมากเกินไป
29 ความคิดเห็น
อืม... ดูเหมือนว่าสุดท้ายแล้วมันเป็นความต่างของมุมมองว่าจะมอง AI เป็นเครื่องมือหรือเป็นสติปัญญา.. สำหรับผม สิ่งที่เห็นด้วยกับบทความนี้ไม่ได้ก็เพราะอย่างที่พูดไว้ในคอมเมนต์ด้านล่าง การมองนักพัฒนาแค่ในระดับโค้ดนั้นเป็นความคิดที่ผิดตั้งแต่ต้น และในอดีตตอนที่การปฏิวัติอุตสาหกรรมเกิดขึ้นในอังกฤษ เหล่าเกษตรกรก็โวยวายกันว่าเราจะอดตาย แต่ผลลัพธ์คือมันสร้างงานได้มากขึ้นและมอบประโยชน์มากมายให้มนุษยชาติ นอกจากนี้ ตอนที่คอมพิวเตอร์ปรากฏขึ้นในอดีต ก็เคยมีคนพูดว่ามนุษย์จะค่อย ๆ โง่ลงเพราะคอมพิวเตอร์ แต่สุดท้ายเรากลับแก้ปัญหางานได้มากขึ้นในเวลาที่เร็วขึ้น และผู้คนก็ฉลาดขึ้นกว่าเดิม
ปัจจุบัน LLM รวมถึง deep research ยังไม่มีประโยชน์มากนักกับการแก้ปัญหาระดับสูง (เช่น การพัฒนาอัลกอริทึมระดับงานวิจัย)
การเขียนโค้ดที่ต้องเข้าใจการปรับแต่งประสิทธิภาพขั้นสุด การทำงานของระบบที่หลากหลาย และประเด็นทางเทคนิคต่าง ๆ ก็ยังต้องอาศัยฝีมือมนุษย์เช่นกัน นักพัฒนาไม่ใช่แค่โปรแกรมเมอร์ธรรมดา แต่เป็นผู้แก้ปัญหา สักวันหนึ่งการแก้ปัญหาแบบ end to end อาจทำได้ แต่ตอนนี้มันช่วยประหยัดเวลาที่ต้องใช้กับการพิมพ์และการเขียนโปรแกรมง่าย ๆ ทำให้เอาเวลาไปทุ่มกับวิธีเข้าหาปัญหาที่ยากกว่าได้มากขึ้น ดังนั้นในแง่ประสิทธิภาพการทำงาน ผมมองว่าเป็นเรื่องบวก
ดูเหมือนว่าตั้งแต่เมื่อไรไม่รู้ ผมใช้มันในแนวคิดคล้ายกับการรีวิวโค้ดบ่อยมาก คือรับข้อเสนอแนะของโค้ดมาคุยกันเรื่องทิศทางของโค้ด คิดและเสนอวิธีที่ดีกว่า แล้วถ้าได้ผลลัพธ์ที่ผมพอใจ ก็จะนำไปใช้อ้างอิงครับ
ตรรกะของแอปพลิเคชันทั้งหมดและตรรกะทางธุรกิจ มนุษย์ต้องเป็นคนคิดเอง
ถ้าจำกัดบทบาทของนักพัฒนาไว้แค่การเขียนโค้ด ก็ย่อมเกิดความกังวลแบบนี้ขึ้นมาได้ จริง ๆ แล้วนักพัฒนาทำงานมากกว่านั้น แม้อาจมองว่าการพึ่งพา AI ในส่วนของการเขียนโค้ดเป็นการทำให้คนโง่ลง แต่ก็อาจมองได้เช่นกันว่ามันช่วยให้พวกเขาไปโฟกัสกับส่วนอื่นได้มากขึ้น
ดึ๊ตตยาอี... ฉันเป็นนักพัฒนาโง่ ๆ...
เคยมีคนพูดเหมือนกันว่า Unity ทำให้นักพัฒนาเกมโง่ลง แต่สุดท้ายทุกคนก็ไม่ได้โง่ลง แถมยังต้องไปเรียนรู้อะไรอย่างอื่นเพิ่มอีกเยอะ เลยกลายเป็นว่างานยิ่งเยอะขึ้น 555
มีแต่งานเพิ่มขึ้น... เป็นไปได้ยังไงเนี่ย..
ผมไม่ค่อยเห็นด้วยกับคำพูดที่ว่า AI กำลังทำให้นักพัฒนากลายเป็นคนโง่...
เพราะหลังจากนำ AI เข้ามาใช้แล้ว ผลิตภาพก็เพิ่มขึ้นอย่างก้าวกระโดดจริง ๆ
นี่ไง คนโง่
ทุกวันนี้เหมือนเป็นโลกที่ถ้าไม่เห็นด้วยกับความคิดที่ว่า AI ทำได้ทุกอย่าง ก็จะโดนด่าซะแล้ว
ถ้าเป็นฟีเจอร์ของไลบรารีที่เราไม่เคยรู้มาก่อน หรือพวกเชลล์สคริปต์ที่นึกไม่ออกในทันที แบบนั้นก็ยังพอได้ แต่เพราะมันมักปนฟีเจอร์ที่ deprecated ไปแล้ว หรือ
functionที่ไม่มีอยู่จริงมาด้วย สุดท้ายก็เสียเวลาไปกับการดีบักหมด> อย่ารับคำตอบของ LLM มาตรง ๆ แต่ต้องวิเคราะห์ด้วยว่าทำไมถึงแนะนำแนวทางแบบนั้น
ผมคิดว่าคำพูดนี้คือประเด็นสำคัญ
ผมรู้สึกว่าเครื่องมือต่าง ๆ มักนำมาทั้งการขยายขอบเขตความคิดและการทำลายความคิดไปพร้อมกันเสมอ เราควรจะก้าวต่อไปสู่การขยายความคิดในระดับที่สูงขึ้นผ่านการทำลายความคิดนั้น แต่ในช่วงเวลาที่เรายังไม่ได้เตรียมพร้อม ปัญหาแบบนี้ก็มักจะตามมาอยู่เสมอ
ดังนั้น เวลาพูดถึงการใช้เครื่องมือ สุดท้ายแล้วก็ดูเหมือนว่าเราจะต้องมีความกังวลลักษณะนี้ติดตามมาด้วยเสมอ ผมคิดว่านี่เป็นกระบวนการที่จำเป็น แทนที่จะปฏิเสธมันไปเลยหรือใช้อย่างมืดบอด ผมคิดว่าสิ่งที่เหมาะสมกว่าคือการมุ่งเน้นว่าเราควรใช้เครื่องมือนี้อย่างไร และจะใช้เครื่องมือเหล่านี้เพื่อทุ่มทรัพยากรให้กับส่วนที่สำคัญกว่าในระดับพื้นฐานได้อย่างไร
(cursor ใช้งานเกิน 1,000 ครั้งต่อเดือน...)
คุณคิมแดรี ผมมีคำแนะนำที่อยากบอกสักหน่อย ไม่ใช่อย่างอื่นเลย แต่อย่าใช้ฟังก์ชัน Excel มากเกินไปเลยนะครับ ถ้ามีความสะดวกสบาย ความเสี่ยงก็ย่อมเพิ่มขึ้นด้วย จะจับวัวก็มีมีดที่เหมาะกับงานนั้น แล้วถ้าจะจับไก่จำเป็นต้องใช้มีดไหม? สิ่งที่ง่ายอาจเป็นคำตอบก็ได้ครับ
บทความข้างบนก็คือ Excel function เวอร์ชัน GPT นั่นแหละ 555
ความเห็นของผมคือ การคิดเลขในใจอาจเร็วได้ และเครื่องคิดเลขก็มีประโยชน์ แต่คอมพิวเตอร์ไม่ใช่มีดสำหรับฆ่าวัวหรอกหรือ เลยขอแสดงความคิดเห็นครับ
ผมจะไม่ใช้ chatGPT อีกต่อไป
ผมเองก็เคยเขียนบทความแนวคล้าย ๆ กันไว้เหมือนกัน
แม้จะเห็นได้ชัดว่ามันช่วยเพิ่มประสิทธิภาพการทำงานได้ แต่ผมคิดว่าเราควรหลีกเลี่ยงการฝากสมองไว้กับมันโดยสิ้นเชิง
ผมยังคงเป็นสาวกตัวยงของ Cursor และ Anthropic อยู่เหมือนเดิม แต่ถึงจุดหนึ่งก็พบว่าตัวเองค่อย ๆ เลิกใช้โหมด agent ที่เคยตื่นเต้นมาก แล้วเปลี่ยนมาใช้โหมด ask เพื่อถามเรื่องสถาปัตยกรรมและวิธีการนำไปใช้ก่อน จากนั้นจะยอมรับข้อเสนอการแก้ไขจาก AI ทีละจุดก็ต่อเมื่อเข้าใจและเห็นด้วยอย่างเพียงพอแล้วเท่านั้น
ระหว่างที่วิศวกร 2 คนต่างคนต่างใช้โหมด agent รีแฟกเตอร์และเพิ่มองค์ประกอบให้กับโมดูลที่ไม่ได้ใหญ่ขนาดนั้นนัก (แต่ค่อนข้างสำคัญกับโปรเจกต์งานของพวกเรา) ผมได้เผชิญด้วยตัวเองกับสถานการณ์ที่โค้ดซึ่งตั้งใจจะจัดระเบียบสถาปัตยกรรม กลับทำให้ทั้งความอ่านง่ายและโครงสร้างยิ่งเละเทะกว่าเดิม จนทำให้ผมเปลี่ยนมาเป็นแบบนี้
ผมก็ใช้งานแบบนี้เหมือนกันครับ ถ้าเป็นภาษาที่ไม่เคยแตะเลยจริง ๆ ก็จะใช้โหมด agent แต่ถ้าเป็นภาษาที่พอรู้จักอยู่แล้ว สุดท้ายก็จะเริ่มจากเช็กก่อนว่าเป็นโค้ดที่สมเหตุสมผลและพอรับได้ไหม
แทนที่จะบอกว่า AI กำลังทำให้นักพัฒนากลายเป็นคนโง่…
นักพัฒนาที่โง่ ต่อให้ใช้ AI ก็ยังเป็นนักพัฒนาที่โง่อยู่ดี…
Garbage in Garbage out
พูดได้ถูกต้องมากเลยครับ 555
เห็นด้วยครับ ดูเหมือนว่านี่จะเป็นเครื่องมือเพิ่มประสิทธิภาพการทำงานที่พอใช้งานได้อีกชิ้นหนึ่ง ซึ่งไม่ได้แย่ไปหมดหรือดีไปหมดเสียทีเดียว
เห็นด้วยครับ
ก่อนหน้านี้ผมก็พูดอยู่บ่อย ๆ ว่า นักพัฒนาไม่ใช่ว่านักพัฒนาทุกคนจะเหมือนกันหมด
ดูเหมือนว่าคำพูดนี้จะถูกต้อง...
พูดค่อนข้างแรง แต่ก็ไม่ถึงกับผิดทั้งหมดนะครับ อยู่ในบริบทเดียวกับที่ว่า.. คำถามที่ดีจะนำไปสู่คำตอบที่ดี
ดูเหมือนว่าผู้เขียนกำลังพูดถึงการใช้งานแบบพึ่งพาเครื่องมือ AI อย่างเดียวโดยไม่ไตร่ตรองนะครับ
ความเห็นส่วนตัวของผมคือ ถ้าการใช้ AI ช่วยเพิ่มประสิทธิภาพในการทำงานได้
ก็ควรนำมาใช้อย่างจริงจังเพื่อลดงานที่ทำซ้ำ ๆ
แล้วนำเวลาที่ได้กลับคืนมาไปลงทุนกับขอบเขตที่กว้างขึ้น (เช่น นักพัฒนาแบ็กเอนด์ขยายไปถึงฟรอนต์เอนด์หรือการพัฒนาแอป) หรือ
ในทิศทางที่ช่วยให้เติบโตมากขึ้นอย่างการออกแบบสถาปัตยกรรม น่าจะเป็นแนวทางที่เหมาะสมกว่า
จากภาพรวมของเนื้อหาทั้งหมด ผมคิดว่าผู้เขียนก็น่าจะเห็นด้วยกับความเห็นข้างต้น
แต่บางครั้งก็มีนักพัฒนาบางท่านที่ปฏิเสธ AI ไปเลยอยู่เหมือนกัน เลยขอเขียนตอบไว้สักสองสามบรรทัดครับ.. ฮ่าๆ
.
ผมก็เห็นด้วยเหมือนกันครับ ทำให้นึกถึงบทความที่บอกว่าอย่าใช้ฟังก์ชันของ Excel
ผมคิดว่าถ้าใช้ความสามารถที่มีอยู่ให้เป็นเพื่อเพิ่มประสิทธิภาพให้สูงขึ้น ก็ถือว่าได้ประโยชน์ครับ
เห็นด้วยครับ ^^
ความเห็นบน Hacker News