- บทความที่เน้นย้ำ ความสำคัญของการคิดในงานพัฒนาซอฟต์แวร์ ท่ามกลางการยอมรับเครื่องมือสร้างโค้ดด้วย LLM อย่างตื่นตัวในอุตสาหกรรม
- โค้ดที่สร้างอัตโนมัติเป็น แบบไม่กำหนดตายตัว (non-deterministic) และการทำงานภายในไม่โปร่งใส จึงต่างโดยพื้นฐานจากระบบกลไกอัตโนมัติที่รับประกันผลลัพธ์เดิมได้ทุกครั้ง
- LLM เรียนรู้จากโค้ดคุณภาพต่ำที่มีอยู่เดิมและทำผิดพลาดซ้ำแบบเดิม ก่อนจะถูกนำกลับไปใช้ฝึกอีกครั้ง เกิดเป็นปัญหา "ญาณวิทยาแบบตะขาบมนุษย์ (human centipede epistemology)"
- เมื่อมอบหมายการสร้างโค้ดให้เอเจนต์ บริบทที่ใช้ร่วมกันและ ความรับผิดชอบที่ตรวจสอบได้ ในการรีวิว PR จะอ่อนแอลง ส่งผลเสียต่อคุณภาพซอฟต์แวร์
- LLM มีประโยชน์ในงานจำกัด เช่น การทำต้นแบบ แต่การที่นักพัฒนา เอาต์ซอร์สแม้กระทั่งกระบวนการคิดเอง เป็นเรื่องเสี่ยง และจะดูแลรักษาต่อไม่ได้หากไม่มีความเข้าใจ
ความอึดอัดใจกับการสร้างโค้ดด้วย LLM
- แม้จะติดตามเทรนด์ใหม่ของวงการมาโดยตลอด และเคยแบ่งปันฟีเจอร์ใหม่ของ CSS และ JS กับเพื่อนร่วมงานอยู่เสมอ ก็ยังรู้สึก กังวลว่าจะตามไม่ทัน เมื่อการสร้างโค้ดด้วย LLM แพร่กระจายอย่างรวดเร็ว
- เคยใช้ Copilot และ Claude เป็น "spicy autocomplete" และเครื่องมือช่วยดีบัก แต่พอให้ทำงานที่ซับซ้อนขึ้นเพียงเล็กน้อย ผลลัพธ์กลับเละเทะ
- ต้องให้คอนเท็กซ์มากพอ แต่ถ้าให้มากเกินไปก็ล้น และยังต้องเขียน พรอมป์ตยาว ๆ เพื่อปลอบอัตตาของ LLM อย่างเช่น "คุณคือผู้เชี่ยวชาญด้านระบบกระจาย"
- หลายครั้ง เขียนโค้ดเอง ยังเร็วกว่าเสียเวลาขัดเกลาพรอมป์ต
- ผู้เขียนตั้งคำถามว่าเหตุใดวิศวกรจึงพยายามละทิ้งงานเขียนโค้ดซึ่งเป็นงานที่สนุก แล้วเหลือไว้เพียงงานรีวิวซึ่งน่าเบื่อ
ข้อโต้แย้งต่อคำกล่าวว่าเป็น "การจำลองการปฏิวัติอุตสาหกรรม"
- เช่นเดียวกับที่การปฏิวัติอุตสาหกรรม มีส่วนต่อการเปลี่ยนแปลงสภาพภูมิอากาศ ปัจจุบันก็เห็นรูปแบบคล้ายกันจาก การใช้พลังงานมหาศาล ของดาต้าเซ็นเตอร์ AI
- แม้ไฟฟ้าทั้งหมดจะไม่ได้มาจากเชื้อเพลิงฟอสซิล แต่การสร้างภาพอย่าง "พระเยซูกุ้ง" ก็ยังสิ้นเปลืองทรัพยากรอย่างมาก
- เครื่องจักรทำให้สินค้ามีราคาถูกและเข้าถึงได้กว้างขึ้น แต่ก็นำไปสู่ คุณภาพที่ลดลง จนเกิดโลกที่ซื้อกางเกงจาก SHEIN ได้ในราคาถูกกว่ากาแฟหนึ่งแก้ว
- ยิ่งเลวร้ายจาก การเสื่อมถอยของแรงงานฝีมือ การย้ายโรงงานไปยังประเทศค่าแรงต่ำ และการเอารัดเอาเปรียบแรงงาน
- โค้ดที่สร้างขึ้นมีลักษณะคล้าย แฟชั่นแบบฟาสต์แฟชั่น: ภายนอกดูใช้ได้ แต่พอเวลาผ่านไปก็เต็มไปด้วยรูรั่ว มัก หยิบยืมโค้ดของผู้อื่นมาโดยพลการ และยังส่งผลเสียต่อสิ่งแวดล้อม
- ความต่างสำคัญคือ ระบบกลไกผลิต ผลลัพธ์เดิมได้ทุกครั้ง และเมื่อมีปัญหาก็ยังตรวจดูภายในได้ แต่ผลลัพธ์จาก LLM นั้น ไม่กำหนดตายตัว และการทำงานภายในไม่โปร่งใส
- กระบวนการแบบเครื่องจักรที่ให้ผลลัพธ์ต่างกันทุกครั้งและปะปนด้วย ภาพหลอน (hallucination) นั้นไม่มีประโยชน์
ข้อโต้แย้งต่อคำกล่าวว่าเป็น "ชั้นใหม่ของการนามธรรม"
- เป็นความจริงที่เมื่อใช้ Java หรือ Go เราไม่จำเป็นต้องเรียนรู้แอสเซมบลี และรันไทม์ก็จัดการเรื่อง garbage collection หรือการจัดสรรหน่วยความจำให้
- แต่เรื่องอย่าง สถาปัตยกรรมระบบ ผลกระทบต่อ critical path การแลกเปลี่ยนระหว่างการดูแลรักษาง่ายกับความเร็วในการส่งมอบ ความเข้ากันได้กับเบราว์เซอร์ รวมถึง การเข้าถึง ความปลอดภัย และประสิทธิภาพ ยังเป็นสิ่งที่นักพัฒนาต้องคิดเองอยู่ดี
- จุดที่ LLM สร้างความเสียหายมากที่สุดคือเวลาที่วิศวกร เอาต์ซอร์สกระทั่งการคิดที่จำเป็นต่อการพัฒนาซอฟต์แวร์
- เนื่องจาก LLM ไม่มีความสามารถในการให้เหตุผล ถ้านักพัฒนาไม่คิด และ LLM ก็ไม่คิด ก็จะกลายเป็นสภาวะที่ ไม่มีใครคิดเลย
- กรณี คดี Horizon: บั๊กในซอฟต์แวร์ของ Post Office ทำให้พนักงานผู้บริสุทธิ์ถูกจำคุก และ มี 13 คนฆ่าตัวตาย
- ความรับผิดรับชอบ (accountability) ต่อซอฟต์แวร์จึงสำคัญกว่าที่เคย
โค้ดคุณภาพต่ำคือปัญหาที่รากฐาน
- นักพัฒนาที่เป็นมนุษย์เองก็ยังเขียนโค้ดที่เข้าถึงยาก ประสิทธิภาพต่ำ และพึ่งพา JavaScript มากเกินไป
- LLM ถูกฝึกด้วย โค้ดคุณภาพต่ำเหล่านี้เป็นข้อมูลฝึก (โดยไม่มีความยินยอมอย่างชัดเจน) จึงพ่นความผิดพลาดแบบเดิมออกมาซ้ำ
- โครงสร้างวนซ้ำที่ให้ LLM เรียนรู้จากโค้ดคุณภาพต่ำที่ LLM สร้างขึ้นเองอีกทอดหนึ่ง หรือที่เรียกว่า "ญาณวิทยาแบบตะขาบมนุษย์ (human centipede epistemology)"
- เมื่อคำนึงถึงผู้ใช้เทคโนโลยีช่วยเหลือ ผู้ใช้ที่มีอินเทอร์เน็ตคุณภาพต่ำ และผู้ที่ได้รับผลกระทบจาก การเหยียดเชื้อชาติของซอฟต์แวร์จดจำใบหน้า คุณภาพซอฟต์แวร์ในปัจจุบันยังไม่ดีพอ
- แทนที่จะเรียนรู้และปรับปรุงในฐานะมนุษย์ เรากลับ เอาต์ซอร์สความผิดพลาดให้แก่อัลกอริทึมที่ไร้การคิด
การรีวิว PR และการอ่อนแรงของบริบทร่วมกัน
- ประเด็นสำคัญจาก การบรรยายของ Jessica Rose และ Eda Eren ที่ FFConf คือ "โค้ดที่คุณไม่ได้เขียนเองคือโค้ดที่คุณไม่เข้าใจ และโค้ดที่คุณไม่เข้าใจคือโค้ดที่คุณดูแลรักษาไม่ได้"
- PR ที่เพื่อนร่วมงานเขียนมีระดับหนึ่งของ ความไว้วางใจและกระบวนการคิด แฝงอยู่ แต่ PR ที่สร้างโดย LLM ไม่มีหลักประกันแบบนั้น
- ผู้ดูแลโอเพนซอร์สจำนวนมากกำลังเผชิญกับ การพุ่งขึ้นของ PR คุณภาพต่ำที่สร้างโดย LLM
- บางบริษัทใช้วิธีขอให้ Claude แก้โค้ดผ่านแชตใน Slack แล้วให้คนเดิมอนุมัติ PR ที่สร้างขึ้นอัตโนมัติ
- ในกรณีนี้ ความรับผิดชอบจะไปกระจุกอยู่ที่ผู้รีวิวเพียงคนเดียว และเท่ากับเสียสายตาคู่ที่สองไป
- บริบทร่วมกัน (shared context) ภายในทีมก็ลดลงด้วย
- การรีวิว PR ไม่ได้มีไว้แค่ตรวจบั๊ก แต่เป็นกระบวนการ แบ่งปันความเข้าใจเกี่ยวกับโค้ดและการเปลี่ยนแปลง ด้วย
ไม่ได้ต่อต้านความก้าวหน้า แต่ต่อต้านกระแสโฆษณาเกินจริง
- ผู้เขียนไม่ได้ต่อต้าน LLM เอง แต่ต่อต้านการทำแบรนด์ในชื่อ "ปัญญาประดิษฐ์"
- LLM ไม่ได้ฉลาด และเป็นเพียงรูปแบบหนึ่งของแมชชีนเลิร์นนิง
- "Generative AI" คือ มาร์คอฟเชนที่ถูกสร้างมาอย่างดีมาก ซึ่งทำให้ผู้คนคาดหวังเกินจริง
- การใช้เพื่อทำต้นแบบ ไวร์เฟรม หรือเดโมแบบโต้ตอบได้อย่างรวดเร็ว ถือว่าสมเหตุสมผล
- ปัญหาคือการเชื่อว่า "vibe code" สามารถสร้างซอฟต์แวร์ระดับโปรดักชันได้ หรือการ มอบหมายแม้แต่กระบวนการคิดในงานเขียนโค้ด ออกไป
- ความเห็นของ Mikayla Maki ในบล็อก Zed: ควรปฏิบัติต่อเอเจนต์เหมือน ผู้มีส่วนร่วมภายนอกที่ยังไม่ไว้ใจ ใช้มันเฉพาะงานที่เรารู้อยู่แล้วว่าต้องทำอย่างไร และ การเข้าใจโค้ดเป็นสิ่งจำเป็น
- จะยังใช้ "spicy autocomplete" ต่อไป แต่จะ ไม่เอาต์ซอร์สการคิด และต้องจำให้ได้ว่าเหตุใดเราจึงรักงานนี้ตั้งแต่แรก
2 ความคิดเห็น
> โค้ดที่สร้างอัตโนมัติมีความไม่กำหนดแน่นอน (non-deterministic)
> คัดค้านการสร้างแบรนด์ด้วยคำว่า "ปัญญาประดิษฐ์"
นี่เป็นคำพูดที่สำคัญที่สุดจริง ๆ..
ใน GeekNews เองก็มีคนที่เปรียบเทียบกับเครื่องคิดเลขหรือกล้องอยู่เหมือนกัน แต่ถ้าแม้แต่นักพัฒนายังมีมุมมองแบบนี้ ก็ดูน่ากังวลมากว่าคนทั่วไปจะคิดกันอย่างไร
ความคิดเห็นจาก Hacker News
ตราบใดที่ AI ยังถูกมองว่าเป็นเพียงสินค้าเพื่อเพิ่มกำไรสูงสุดให้บริษัทยักษ์ใหญ่ ไม่ใช่ “จักรยานสำหรับจิตใจ” ก็ยากที่จะทำให้สภาพของ AI ในปัจจุบันดูชอบธรรมได้
โครงสร้างที่กวาดข้อมูลมาประมวลผลแล้วส่งกลับโดยไม่มีการเรียนรู้อย่างแท้จริงนั้นไม่เป็นผลดีต่อ การเติบโตทางความคิด ของมนุษย์
สุดท้ายแล้วหัวใจสำคัญคือการสร้างโมเดลรายได้ ไม่เช่นนั้นก็ไม่สามารถรักษา LLM คุณภาพสูงไว้ได้
ตอนนี้ฉันแทบจะ ไม่แก้ไขด้วยมือแล้ว แค่โยน URL ของตั๋วงานให้ Claude Code ก็แก้ได้เกือบทั้งหมดในครั้งเดียว
เชื่อว่าทีมที่ลงทุนกับวิธีนี้จะมี ประสิทธิภาพการทำงานสูงขึ้นมาก เมื่อเทียบกับทีมที่ไม่ทำ
LLM เป็นเทคโนโลยีที่ให้ประสบการณ์ต่างกันโดยสิ้นเชิงในแต่ละคน และมี อิสระในการพรอมป์ต์ สูงมาก
เวลาจะทำดีไซน์เฉพาะทาง บางทีก็เขียนเองเร็วกว่า
คำพูดที่ว่า “โค้ดที่ฉันไม่ได้เขียนเอง ฉันจะไม่มีวันเข้าใจ” นั้นไม่สมจริง
เป้าหมายของ code review ไม่ใช่ตัวตนของผู้เขียน แต่คือ การรับประกันความน่าเชื่อถือของระบบ
ไม่ว่าจะเป็นมนุษย์, AI หรือแม้แต่ โกลเดนรีทรีฟเวอร์ เป็นคนพิมพ์ก็ไม่สำคัญ
แต่แทนที่จะเสียเวลาไปกับการพยายามเข้าใจ PR ที่ AI สร้างขึ้น ฉันกลับรู้สึกว่าสู้ส่งพรอมป์ต์เองเพื่อให้ได้ผลลัพธ์ที่ต้องการจะดีกว่า
ถ้าพึ่งพา LLM นักพัฒนาจะเสีย โอกาสในการเรียนรู้โครงสร้างโปรเจกต์ และสุดท้ายก็จะมองระบบเป็นกล่องดำ
กระแสแบบนี้กำลังเปลี่ยนนักพัฒนาให้กลายเป็น “prompt kiddie”
เห็นด้วยกับคำพูดที่ว่า “แทนที่จะเสียเวลาแต่งพรอมป์ต์ ฉันขอเขียนโค้ดเองดีกว่า”
ปัญหาไม่ใช่ “การสร้าง” แต่เป็น การสร้างแบบไร้โครงสร้าง
กล่าวคือ แทนที่จะใช้พรอมป์ต์สด ๆ แบบเฉพาะหน้า ควรเข้าหาด้วย การประกอบเป็นหน่วยทักษะ (composition) ที่ชัดเจน
การต้องบอก AI ว่า “คุณคือผู้เชี่ยวชาญด้าน distributed systems” นั้นเป็นเรื่องของ ยุค GPT-3
ตอนนี้ด้วย เทคนิคการ fine-tuning และ post-processing จึงไม่จำเป็นต้องใช้พรอมป์ต์แบบกำหนดบทบาทเช่นนี้แล้ว
พอเห็นกระแสโค้ดที่สร้างด้วย LLM ก็เคยกังวลว่า “ฉันกำลังตามไม่ทันหรือเปล่า”
ที่ผ่านมาฉันใช้ Copilot กับ Claude แค่เป็น ตัวช่วย autocomplete แต่โค้ดที่ซับซ้อนก็ยังออกมาเละเทะเหมือนเดิม
แต่ช่วงนี้ เครื่องมือแบบเอเจนต์ สามารถค้นหาใน codebase หาข้อมูลจากเว็บ และปรับคอนเท็กซ์เองได้
สุดท้ายแล้ว ปัญหาคือ “คนที่บ่นทั้ง ๆ ที่ยังไม่เข้าใจเทคโนโลยีนี้ดีพอ”
ในความเป็นจริงมีโอกาสสูงว่าเป็นเพราะ ทักษะการเขียนพรอมป์ต์ไม่พอ
ที่มันดูเหมือน “คิด” ได้ ก็เพราะเครื่องมือรอบข้างช่วยทำการค้นหาและรันงานให้แบบอัตโนมัติ
สุดท้ายแล้วนี่คือ ระบบอัตโนมัติ ไม่ใช่ปัญญา
ทุกวันนี้โพสต์และคอมเมนต์จำนวนมากบน HN ให้ความรู้สึกเหมือน LLM เป็นคนเขียน
ไม่มีอะไรใหม่ และส่วนใหญ่ก็แค่พูด เหมารวมแบบผิวเผิน ซ้ำ ๆ
ดูจากข่าวช่วงหลัง ๆ แล้ว AI ก็ยัง ไม่สุกงอมพอ
เช่น Microsoft ปรับลดเป้ารายได้ของ Copilot และ
ปัญหาความปลอดภัยของ Moltbook
สุดท้ายแล้วคนส่วนใหญ่ก็ยัง ไม่เชื่อถือ AI
AI มีประโยชน์กับการสำรวจไอเดียหรือการเขียน boilerplate แต่ ความสามารถในการคิด ก็ยังเป็นแกนหลัก
AI คือ สิ่งล่อใจสูงสุด ที่จะมาคิดแทนมนุษย์ แต่ในระยะยาวก็เสี่ยงจะ ทำให้กล้ามเนื้อความคิดอ่อนแอลง
ถ้าใช้ไปสักระยะแล้วกลับมาลองเขียนโค้ดด้วยมือตามเดิม คุณจะรู้สึกได้ว่า ความลื่นไหลลดลง
อาจเป็นเพราะ Claude ดีกว่า Copilot ก็ได้ หรือปัญหาความปลอดภัยของ Moltbook อาจเป็น ชะตากรรมของบริการระยะเริ่มต้น
สุดท้ายผลลัพธ์จะสะท้อนออกมาจาก อัตราการอยู่รอดของบริษัทที่ใช้ AI เทียบกับบริษัทที่ไม่ใช้
เมื่อก่อนฉันเองก็คิดว่า “AI เป็นกล่องดำโง่ ๆ” แต่ในช่วง 6 เดือนที่ผ่านมา มุมมองเปลี่ยนไปอย่างสิ้นเชิง
ถ้าเรียนรู้อย่างถูกวิธี มันสามารถสร้างผลลัพธ์ที่น่าทึ่งได้
ตอนนี้ฉันมอง AI เป็น เครื่องขยายพลัง และใช้มันเป็นเครื่องมือเพื่อขยายความสามารถของตัวเอง