ความเสี่ยงของการสูญเสียคุณธรรมแห่งความขี้เกียจ

 (bcantrill.dtrace.org)
2 คะแนน โดย GN⁺ 17 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความขี้เกียจ ในการเขียนโปรแกรมไม่ใช่แค่ความเฉื่อยชา แต่ถูกนิยามว่าเป็น คุณธรรมทางปัญญาที่มุ่งสู่การนามธรรมและความเรียบง่าย
  • ความขี้เกียจที่แท้จริงคือ กระบวนการครุ่นคิดปัญหาอย่างลึกซึ้งเพื่อประหยัดเวลาในอนาคต และยังเป็นประโยชน์ต่อนักพัฒนารุ่นถัดไปด้วย
  • นามธรรมระดับสูงในยุคปัจจุบันและวัฒนธรรม ‘brogrammer’ ทำให้คุณธรรมนี้เลือนหายไป และถูกแทนที่ด้วย ความขยันจอมปลอม
  • LLM ทำให้แนวโน้มนี้รุนแรงยิ่งขึ้น จนกลายเป็น เครื่องมือของการผลิตเกินพอดี ที่ทำให้ผู้คนเข้าใจผิดว่าปริมาณโค้ดคือคุณค่า
  • ควรรักษา ความขี้เกียจเชิงคุณธรรม ที่เกิดจากเวลาซึ่งมนุษย์มีอยู่อย่างจำกัดไว้ และใช้ LLM เพื่อออกแบบ ระบบที่เรียบง่ายและยั่งยืน

ความขี้เกียจในฐานะคุณธรรมของโปรแกรมเมอร์ และความเสี่ยงจากการสูญเสียมันไป

  • Larry Wall เน้นย้ำว่า ในบรรดาคุณธรรมสามประการของโปรแกรมเมอร์ที่นำเสนอไว้ใน 『Programming Perl』 ได้แก่ ความขี้เกียจ (laziness), ความใจร้อน (impatience) และ ความหยิ่งทะนง (hubris) นั้น ความขี้เกียจมีความหมายลึกซึ้งที่สุด
    • ความขี้เกียจไม่ใช่เพียงการถ่อมตัวเชิงล้อเลียน แต่เป็นแนวคิดที่สื่อถึง ความจำเป็นและสุนทรียะของการนามธรรม
    • มันคือแรงผลักดันให้สร้างระบบให้เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ และทำให้เราทำงานได้มากขึ้นอย่างง่ายดายผ่านนามธรรมที่ทรงพลัง
  • ความขี้เกียจที่แท้จริงเป็นกระบวนการของ แรงงานทางปัญญา ที่ภายนอกอาจดูเหมือนการพักผ่อนแบบ ‘hammock-driven development’ แต่แท้จริงแล้วคือการครุ่นคิดปัญหาอย่างลึกซึ้งเพื่อประหยัดเวลาในอนาคต
    • เมื่อนามธรรมที่ถูกต้องถูกสร้างขึ้น มันจะเป็นประโยชน์ไม่เพียงต่อตัวนักพัฒนาเอง แต่ยังรวมถึง นักพัฒนารุ่นหลัง ด้วย
    • ความขี้เกียจลักษณะนี้ทำให้ซอฟต์แวร์เขียนได้ง่ายขึ้น และทำให้ระบบประกอบขึ้นได้ง่ายขึ้น

  • ยุคสมัยที่คุณธรรมแห่งความขี้เกียจกำลังหายไป

    • ตลอด 20 ปีที่ผ่านมา เมื่อขอบเขตของการสร้างซอฟต์แวร์กว้างขึ้น ก็มีคนจำนวนมากขึ้นที่ ไม่ได้มองว่าตัวเองเป็นโปรแกรมเมอร์
      • สำหรับคนกลุ่มนี้ คุณธรรมแห่งความขี้เกียจได้สูญเสียความหมายดั้งเดิมไป
    • การระเบิดของผลิตภาพ ที่เกิดจากนามธรรมระดับสูงในยุคใหม่ กลับยิ่งส่งเสริม ความขยันจอมปลอม (false industriousness)
      • สิ่งนี้ปรากฏออกมาในรูปของวัฒนธรรม ‘brogrammer’ และ ‘hustle porn’ ซึ่งแทนที่ความขี้เกียจแบบประชดประชันด้วย พฤติกรรมการเทโค้ดออกมาไม่รู้จบ

  • ความล้นเกินรูปแบบใหม่ที่ LLM นำมา

    • การมาถึงของ LLM (โมเดลภาษาขนาดใหญ่) ทำให้แนวโน้มนี้รุนแรงถึงขีดสุด
      • LLM เป็นเครื่องมือที่ขยายท่าทีการสร้างสรรค์ของมนุษย์ และทำหน้าที่เป็น สเตียรอยด์ของวัฒนธรรม ‘brogrammer’
    • ตัวอย่างเช่น Garry Tan กล่าวถึงการใช้ LLM เพื่อเขียนโค้ดได้ถึง 37,000 บรรทัดในหนึ่งวัน
      • เพื่อใช้เปรียบเทียบ โค้ดเบสทั้งหมดของ DTrace มีขนาดราว 60,000 บรรทัด
    • อย่างไรก็ตาม แนวทางเช่นนี้คือ ความชั่วร้ายที่ขาดคุณธรรมแห่งความขี้เกียจ และเผยให้เห็นความผิดพลาดของการตัดสินคุณค่าของซอฟต์แวร์จากปริมาณโค้ด

  • ข้อจำกัดของ LLM และคุณค่าของความขี้เกียจแบบมนุษย์

    • เนื่องจาก ต้นทุนแรงงานของ LLM เท่ากับ 0 มันจึงสร้าง ระบบที่ซับซ้อนได้อย่างไร้ขีดจำกัด โดยไม่คำนึงถึงการประหยัดเวลาในอนาคต
      • ผลลัพธ์คือระบบมีขนาดใหญ่และซับซ้อนขึ้น ตอบสนอง ตัวชี้วัดที่ขับเคลื่อนด้วยความทะนงตน แต่กลับทำลาย คุณภาพที่แท้จริง
    • ความขี้เกียจของมนุษย์เกิดจาก ข้อจำกัดของเวลาที่มีอยู่อย่างจำกัด และข้อจำกัดนี้เองที่บังคับให้เกิด การนามธรรมที่ชัดเจนและการออกแบบระบบที่เรียบง่ายขึ้น
      • วิศวกรรมที่ดีที่สุดล้วน เกิดจากข้อจำกัด และข้อจำกัดด้านเวลาของมนุษย์ก็ช่วย จำกัดภาระทางการรับรู้ และผลักดันให้แสวงหาความเรียบง่าย
      • LLM ไม่มีข้อจำกัดเช่นนี้ จึงไม่มีแรงจูงใจโดยธรรมชาติที่จะมุ่งไปสู่ความเรียบง่ายด้วยตัวเอง

  • แนวทางการใช้ LLM ในฐานะเครื่องมือ

    • LLM ยังคงสามารถมีบทบาทสำคัญได้ในฐานะ เครื่องมือทรงพลังของวิศวกรรมซอฟต์แวร์
      • ตามแนวทางการใช้ LLM ของ Oxide นั้น LLM เป็นเพียง เครื่องมือ และไม่อาจแทนที่คุณธรรมของมนุษย์ได้
    • LLM สามารถนำไปใช้แก้ปัญหาความขี้เกียจที่ไม่ก่อให้เกิดผลผลิต เช่น หนี้ทางเทคนิค (technical debt) หรือใช้เพื่อเสริม ความเข้มงวดทางวิศวกรรม
    • อย่างไรก็ตาม จุดมุ่งหมายของการใช้งานจะต้องมุ่งไปสู่การทำให้เกิด ‘ความขี้เกียจเชิงคุณธรรม’
      • กล่าวคือ ต้องใช้เพื่อสร้าง ระบบที่เรียบง่ายกว่าและทรงพลังกว่า เพื่อทิ้งผลลัพธ์ที่เป็นประโยชน์ไว้ให้แก่ นักพัฒนารุ่นต่อไป

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 17 일 전
ความคิดเห็นจาก Hacker News

  • แม้แต่ในสายงานของฉันอย่าง Computational Fluid Dynamics ก็ยังมีคนอวดจำนวนเทสต์เหมือนอวด LOC
    แต่พอดูใกล้ ๆ แล้ว เทสต์พวกนั้นก็ไม่ได้เข้มงวดอะไร และหละหลวมกว่าที่ฉันทำเองด้วยซ้ำ
    เทสต์ง่าย ๆ 1 ล้านรายการ ก็ไม่มีความหมาย ถ้ามันไม่ครอบคลุมส่วนสำคัญของโค้ด

    • ฉันเองก็ได้ตระหนักว่าต้องเขียนเทสต์ด้วยตัวเอง
      และเพื่อกันไม่ให้ Claude “แก้” เทสต์เวลาโค้ดใช้ไม่ได้ ฉันจะเช็กการเปลี่ยนแปลงของเทสต์ด้วย git diff เสมอ
      ถ้าคุมเทสต์ให้เข้มงวด Claude ก็ช่วยเขียนอัลกอริทึมจากเปเปอร์ยาก ๆ ได้ดีและประหยัดเวลาได้มาก แต่ก็ ต้องคอยประกบเยอะมาก
    • มันคล้าย reward hacking อยู่เหมือนกัน
      โมเดลกำลังเอาฟังก์ชันรางวัลอย่างเทสต์ไปใช้ในทางที่ผิดเพื่อ “ประกาศชัยชนะ”
      เดาว่าอาจมีแพตเทิร์นแบบนี้อยู่ในข้อมูล pretraining สำหรับ RL ด้วย
    • การทำให้ LLM สร้างเทสต์ที่ไม่โง่นั้นยากมาก
      มักได้เทสต์ไร้ประโยชน์อย่าง assert(1==1) มาเป็นร้อย ๆ อัน
      เลยต้องมี รายการข้อห้าม แยกไว้ว่า “ห้ามสร้างเทสต์แบบนี้”

  • หลังจากเขียนโค้ดเองมา 30 ปี ตอนนี้ฉันเปลี่ยนมาเป็น AI coding เต็มตัวแล้ว แต่ก็ยังรู้สึกแปลกที่คนเอา LOC หรือฟีเจอร์ของโค้ดที่ AI สร้างขึ้นมาเป็นผลงานของตัวเอง
    การอวดว่า “เขียนโค้ด” ไปหลายแสนบรรทัดในวันเดียว จริง ๆ แล้วก็แค่พิมพ์ พรอมต์ไม่กี่บรรทัด เองไม่ใช่หรือ

    • มันเป็นเหมือนสเปกตรัม
      งานแก้ไขที่เราตรวจอนุมัติเองก็พอจะนับเป็นผลงานได้บ้าง แต่ แอปแบบ vibe-coded ล้วน ๆ แทบไม่ได้มีส่วนร่วมอะไรเลย
      ฉันอยู่ประมาณตรงกลาง — ไม่ได้รีวิวทุกบรรทัดที่ AI สร้าง แต่เป็นคนคุมการออกแบบสถาปัตยกรรมและทิศทางการรีแฟกเตอร์
      ผลลัพธ์ก็ใกล้เคียงกับที่ฉันทำเอง แต่เสร็จได้เร็วกว่าเยอะ
    • ตอนนี้ที่ Meta มี กระดานจัดอันดับการใช้ AI แล้ว ว่าใครใช้ Claude token มากที่สุด
      ในมุมของ Anthropic ก็น่าจะยินดีไม่น้อยที่ Meta ใช้ Claude
    • จริง ๆ แล้วการมี LOC เยอะอาจเป็น สัญญาณของผลลัพธ์ที่ไม่ดี ก็ได้
    • บางคนแย้งว่า LoC ไม่มีความหมายในฐานะตัวชี้วัดคุณภาพ
      เพราะตอนนี้ทั้งการ implement, test และ maintenance ล้วนเป็นงานที่ เอเจนต์ทำ กันหมดแล้ว
      LoC จึงเป็นเพียง ตัวชี้วัดขีดความสามารถ ว่าเอเจนต์สามารถผลักดัน requirement ได้มากแค่ไหน
      ส่วนการรีวิวเชิงวิพากษ์ของมนุษย์ก็ยังสามารถป้อนกลับเข้าไปเป็น feedback ได้อยู่

  • คำพูดว่า “ควรใช้ abstraction ให้มากขึ้น” อาจเคยจริงในอดีต แต่ตอนนี้ฉันกลับรู้สึกว่าตรงกันข้าม
    ฉันชอบแนวคิด WET(Write Everything Twice) — เขียนซ้ำสองครั้งก่อน แล้วค่อยคิดเรื่อง abstraction ตอนครั้งที่สาม

    • เรื่องนี้มักถูกเรียกว่า Rule of Three ด้วย
      ดู บทความในวิกิ
    • ความงามที่แท้จริงของซอฟต์แวร์อยู่ที่ abstraction ที่ถูกต้อง
      นวัตกรรมอย่างระบบปฏิบัติการ, RDBMS และ cloud orchestration คือตัวอย่างของสิ่งนั้น
      แต่โค้ดส่วนใหญ่เป็นเพียง business logic ธรรมดา ซึ่ง abstraction มักกลายเป็นตัวขัดขวางมากกว่า
      เพราะแบบนั้นฉันจึงยึดหลักว่า “อย่าสร้างแพลตฟอร์ม จนกว่าจะพิสูจน์ได้จาก use case จริงสามแบบ”
    • การเขียนเกินสองครั้งก็เป็นเกณฑ์ที่ค่อนข้างต่ำ เลยคิดว่าไม่ได้ขัดกับคำคมจาก Perl แต่อย่างใด
    • การเขียนครั้งที่สองคือโอกาสในการปรับปรุง หลังจากเข้าใจปัญหาดีขึ้นแล้ว
      พอจะลองทำ abstraction ในครั้งที่สาม ก็ต้องระวัง Second-System Effect — ความมั่นใจเกินไปอาจนำไปสู่ระบบที่ซับซ้อนเกินจำเป็น
    • การเพิ่มขึ้นอย่างมหาศาลของ ชั้น abstraction ตั้งแต่ Programming Perl ปี 1991 เป็นต้นมานั้นน่าทึ่งมาก

  • มีการแชร์คำพูดอันโด่งดังของนายพลเยอรมัน Kurt von Hammerstein-Equord
    คนฉลาดและขยันเหมาะกับงานเสนาธิการ คนโง่และขี้เกียจเหมาะกับงานประจำวัน คนฉลาดและขี้เกียจเหมาะเป็นผู้นำ
    และ คนโง่แต่ขยันนั้นอันตราย จึงไม่ควรให้รับผิดชอบอะไรเด็ดขาด

    • มีคนตอบแบบติดตลกว่า แล้วพวก ขี้เกียจ 90% แบบฉัน อยู่ตรงไหนกันล่ะ

  • การอวดว่าใช้ LLM เขียนไป 200,000 LOC นั้นก็โง่พอ ๆ กับการเห็นแล้วหัวเราะเยาะว่า “โค้ดนี้ห่วยจัง”
    สุดท้ายสิ่งสำคัญคือ การสร้างคุณค่า ไม่ใช่ปริมาณโค้ดที่ปล่อยออกมา
    ฉันไม่รู้ว่า Garry Tan ได้สร้างสิ่งที่มีคุณค่าจริงหรือเปล่า

    • ถ้าคิดว่าคุณภาพโค้ดไม่สำคัญ นั่นเป็นเรื่องใหญ่มาก
      ดูกรณีอย่าง Horizon IT scandal ก็ได้ โค้ดแย่สร้างความเสียหายจริงได้
      ตามรีวิวของนักพัฒนาชาวโปแลนด์ Gregorein ที่วิเคราะห์โปรเจกต์ของ Garry แอปนั้นมีทั้ง test harness, แอป Hello World และไฟล์โลโก้ซ้ำซ้อน ปะปนกันมั่วไปหมด
      จึงอดกังวลไม่ได้ว่าโค้ดแบบนี้อาจขยายพื้นผิวการโจมตีด้านความปลอดภัยด้วยหรือไม่
    • Garry ไม่ใช่นักพัฒนาทั่วไป แต่เป็น CEO ของ YC
      เขาไม่ได้สนใจ LOC หรอก แค่โพสต์เพื่อ โปรโมต AI มากกว่า
    • ตัวชี้วัดที่แท้จริงคือ คุณค่า – ต้นทุน
      AI ช่วยลดต้นทุนการพัฒนาและการปฏิบัติการ แต่ก็เพิ่ม ต้นทุนแฝง อย่างความเสี่ยงด้านความปลอดภัยและกฎหมาย
      ฝ่ายที่เชียร์ AI มักพูดถึงแต่อย่างแรก
    • ไม่มีเวลามานั่งอ่าน 200,000 LOC เพื่อพิสูจน์ว่ามันเป็นไอเดียที่ไม่ดี
      นั่นควรเป็นสิ่งที่ vibe coder ต้องพิสูจน์เอง
      การเอา LOC มาอวดก็ยังถือว่าเป็นเรื่องโง่อยู่ดี
    • คำว่า “การสร้างคุณค่า” เองก็อาจอันตรายได้
      เช่นเดียวกับการเติบโตที่อิงเชื้อเพลิงฟอสซิล คุณค่าระยะสั้นอาจก่อให้เกิดต้นทุนระยะยาว

  • ช่วงหลัง ๆ เวลาดู PR หลายอัน ฉันมักเห็น LLM เสนอวิธีแก้ที่ผิด อยู่บ่อยครั้ง
    เช่น มีตัวแยก JSON อยู่แล้ว แต่กลับไปเขียน parser ขึ้นมาเอง
    ถ้าเป็นมนุษย์ก็คงรู้สึกว่า “นี่มันไม่มีประสิทธิภาพเกินไป” แต่ LLM ไม่มีความขี้เกียจ จึงขยันเดินไปผิดทาง

    • อีกอย่างคือมันแทบไม่รับรู้เลยว่ามีฟังก์ชันซ้ำอยู่ในโปรเจกต์
      ทั้งที่อย่าง formatTimestamp มีตั้งสามตัว และ grep แค่ครั้งเดียวก็รู้ได้ แต่มันกลับมองข้ามไป

  • เห็นด้วยกับคำพูดที่ว่า LLM ไม่ขี้เกียจ
    เพียงแต่ไม่แน่ใจว่านี่เป็นปัญหาถาวร หรือจะถูกแก้ได้ในโมเดลรุ่นถัดไปหรือใน CICD pipeline
    ฉันมักใช้พรอมต์ว่า หลังทำฟีเจอร์เสร็จแล้ว “ให้ตรวจดูว่ามีบั๊กหรือส่วนที่ควรรีแฟกเตอร์ไหม”
    ต่อไปอาจมีขั้นตอนอัตโนมัติที่ วิเคราะห์ commit ล่าสุดแล้วเสนอการทำให้เรียบง่ายขึ้น ก็ได้

    • แต่ถ้าบอกว่า “จงหา X” LLM ก็จะหาอะไรสักอย่างมาให้เสมอ
      เลยมีปัญหาว่า นิยามเงื่อนไขการจบงาน นั้นยาก
    • สุดท้ายปัญหาไม่ได้อยู่ที่ธรรมชาติของเครื่องมือ แต่อยู่ที่ ข้อจำกัดของวิธีใช้งาน
      ถ้าบอกให้ “เพิ่ม” มันก็เพิ่มอย่างเดียว ถ้าบอกให้ “ลด” มันก็ลด LOC
      ถ้ามอบงานก้อนใหญ่แล้วไม่รีวิว ก็มีโอกาสสูงที่จะสะสม code slop

  • LLM มีแนวโน้มจะทำ SPA เต็มรูปแบบ แทนโปรแกรม console output ง่าย ๆ
    และยังรักษาไฟล์ spec.md ให้กระชับไม่ได้ด้วย
    พอสั่งว่า “อัปเดตเอกสารนี้และทำให้เนื้อหาโดยรอบง่ายขึ้น” มันกลับทำให้ซับซ้อนกว่าเดิม
    สุดท้ายก็ต้อง ให้คนสรุปเอง ถึงจะได้เอกสารที่อ่านง่าย
    การแก้ไขผลลัพธ์จาก LLM เป็นเรื่องทรมาน และการเขียนเองช่วยให้ยังเข้าใจเนื้อหาอยู่

  • ถึงเวลาแล้วที่จะสอนบทเรียนคลาสสิกของการพัฒนาซอฟต์แวร์ให้กับ LLM และเหล่า vibe coder
    อย่างเรื่อง Negative 2000 Lines of Code ที่เตือนว่า หลายครั้ง การลดจำนวนโค้ดลงต่างหากคือความก้าวหน้าที่แท้จริง

  • แค่นึกว่าถ้าได้ทำงานกับผู้นำแบบนี้จะดีแค่ไหน
    การได้ร่วมงานกับ ผู้นำที่เข้าใจจริง นั้นเป็นโชคอย่างยิ่ง