โค้ดคือหนี้ (Code is Debt)

 (tornikeo.com)
17 คะแนน โดย GN⁺ 2025-09-03 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • การใช้เครื่องมือเขียนโค้ดด้วย AI คือการเพิ่ม "หนี้โค้ด"
  • ในบรรดาสองบริษัทที่มีผลิตภัณฑ์และรายได้เท่ากัน บริษัทที่มี โค้ด 100,000 บรรทัด จะ เข้าใจและแก้ไขได้เร็วกว่า บริษัทที่มี โค้ด 1 ล้านบรรทัด อย่างมาก
  • กล่าวคือ ยิ่งมีโค้ดมาก หนี้ก็ยิ่งสะสมมากขึ้น และแม้การสร้างโค้ดด้วย AI จะเพิ่มผลิตภาพ แต่ก็อาจตีความได้ว่าเป็นการ เพิ่มหนี้ ไปพร้อมกัน
  • หนี้มีทั้ง ด้านบวก/ด้านลบ
    • ด้านบวก: ทำให้เติบโตอย่างรวดเร็วได้ในระยะสั้น
    • ด้านลบ: หากบริหารจัดการล้มเหลว ในระยะยาวอาจนำไปสู่ ความเสี่ยงของการล่มสลาย ของโครงการ
  • กล่าวคือ หนี้ อาจดีหรือแย่ก็ได้ อาจมีดอกเบี้ยหรือไม่มีก็ได้ สามารถเร่งการเติบโตได้ แต่ก็อาจทำให้โครงการ ล่มสลาย ได้เช่นกัน
  • สิ่งสำคัญไม่ใช่ว่า ใช้เครื่องมือหรือไม่ แต่คือท่าทีในการ บริหารจัดการอย่างมีความรับผิดชอบ
  • ควรรับประกันว่าเครื่องมือ เข้าถึงได้ง่าย ควบคู่ไปกับการคำนึงถึง คุณภาพของโค้ดที่สร้างขึ้นและต้นทุนระยะยาว

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

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

 
ndrgrd 2025-09-03

ถ้าโค้ดยาวมากแต่ยังอธิบายได้ง่ายว่า "มันทำอะไร" ก็ไม่ถือว่าเป็นหนี้

ที่บอกว่าการใช้ AI อย่างไม่ยั้งคิดสร้างหนี้ ก็เพราะมันทำให้การอธิบายสิ่งนั้นยากขึ้น
 
mulmuri 2025-09-03

แม้จะไม่ได้ระบุไว้อย่างชัดเจนในเนื้อหา แต่ก็อาจหมายถึงว่าเมื่อเขียนโค้ดด้วย AI มนุษย์จะไม่คุ้นเคยกับมันเท่าโค้ดที่เขียนเองโดยตรง จึงอาจกลายเป็นหนี้ทางเทคนิคได้หรือเปล่า?
 
GN⁺ 2025-09-03
ความคิดเห็นจาก Hacker News

  • โดยผิวเผิน การใช้จำนวนบรรทัดของโค้ด (LOC) เป็นตัววัดทุกอย่างนั้นดูตื้นเขิน ถ้า Company A มีโค้ด 1 ล้านบรรทัดที่สะอาด เป็นระเบียบ และมีเอกสารกำกับดีกว่ามาก ก็อาจถือว่าอยู่ในสถานการณ์ที่ดีกว่า Company B ที่มีโค้ด 1 แสนบรรทัดแต่เขียนได้ไม่ดี ประเด็นสำคัญไม่ใช่ตัวโค้ด แต่คือความซับซ้อน และจำนวนบรรทัดก็เป็นเพียงตัวชี้วัดคร่าว ๆ ของความซับซ้อนเท่านั้น โค้ดคือสินทรัพย์ เป็นทั้งผลผลิตและสินทรัพย์ของบริษัทซอฟต์แวร์ แน่นอนว่ายิ่งมีสินทรัพย์มาก ความซับซ้อนก็ยิ่งเพิ่มขึ้น แต่ก็เป็นเรื่องธรรมดามาก คงไม่อาจมองโครงข่ายทางหลวงของสหรัฐฯ ในแง่ลบทั้งหมดเพียงเพราะมันซับซ้อนและบำรุงรักษายาก ต่อให้ไม่นับประเด็น AI สุดท้ายข้อสรุปของผู้เขียนก็คือ “ยิ่งมีความซับซ้อนน้อยยิ่งดี” ซึ่งเป็นข้อสรุปพื้นฐานที่ใคร ๆ ก็รู้อยู่แล้ว ดังนั้นสาระสำคัญที่สุดของบทความนี้น่าจะย่อได้ว่า “ต้องคอยตรวจให้แน่ใจว่าเครื่องมือเขียนโค้ดด้วย AI ไม่ได้เพิ่มความซับซ้อนที่ไม่จำเป็นเข้าไปในโค้ดที่เสร็จแล้ว”

    • ฉันกลับคิดว่าความซับซ้อนไม่ใช่ประเด็นหลักตรงนี้ด้วยซ้ำ ถ้าสมมติว่ามีธุรกิจซอฟต์แวร์ที่อยู่รอดมาได้แล้ว แล้วลองคิดย้อนกลับ ต้นทุนทุกอย่าง (การจัดซื้อ เงินเดือน ฯลฯ) โดยหลักการแล้วควรลดให้ต่ำที่สุด ความซับซ้อนถูกมองว่าแย่กว่าความเรียบง่ายก็เพราะถ้ามันซับซ้อนจริง ๆ มันจะแพงกว่า แต่สุดท้ายสิ่งสำคัญจริง ๆ คือต้นทุนล้วน ๆ ไม่ว่าจะระยะสั้นหรือระยะยาว จะเป็นเงินทุนหรือค่าใช้จ่ายดำเนินงานก็ตาม ประเด็นที่แท้จริงคือโค้ดที่ LLM สร้างขึ้นช่วยลดต้นทุนหรือทำให้ต้นทุนสูงขึ้น ขนาดของโค้ด ความซับซ้อน และตัวแปรอีกนับไม่ถ้วนที่ทั้ง OP และคุณไม่ได้พูดถึง ล้วนสำคัญทั้งหมด

    • ฉันมักดูความซับซ้อนของฟังก์ชันด้วย cyclomatic complexity ใช้ SwiftLint วัดความซับซ้อนและให้มันแจ้งเมื่อเกินเกณฑ์ บางครั้งก็แยกฟังก์ชันแบบหยาบ ๆ บ้าง แต่โดยปกติจะพยายามหาวิธีทำให้มันง่ายขึ้นเสมอ ไฟล์ของฉันค่อนข้างยาว แต่พยายามรักษาสัดส่วนคอมเมนต์กับโค้ดให้ประมาณ 50:50 ถ้าให้พรอมป์ต์กับ LLM เพื่อลดความซับซ้อนและเพิ่มคอมเมนต์ ก็น่าจะทำได้ดีพอสมควร

    • โค้ดก็เหมือนสารเคมีระเหยง่าย เป็นทั้งสินทรัพย์และหนี้ ถ้าใช้อย่างถูกต้องและรวดเร็วก็ทำเงินได้ แต่ถ้าปล่อยทิ้งหรือทำหกรั่วไหลก็จะกลายเป็นหนี้ ซอร์สโค้ดไม่ได้เสื่อมสภาพเอง แต่เมื่อเป้าหมายและกระบวนการขององค์กรเปลี่ยนไป “ความเหมาะสมต่อวัตถุประสงค์” ก็เปลี่ยนตามไปเรื่อย ๆ

    • ฉันว่าหัวข้อ “ทำไมเราถึงสร้างซอฟต์แวร์ที่เรียบง่ายไม่ได้?” น่าสนใจดี ประเด็นเรื่องความซับซ้อนที่ว่า “เมื่อระบบต่าง ๆ โต้ตอบกัน ความซับซ้อนก็เกิดขึ้น ระบบที่ซับซ้อนอาจเลยเถิดไปในทางไร้เหตุผลได้ และอาจก่อให้เกิดความคิดสร้างสรรค์ที่ไม่คาดคิดด้วย” ฟังดูโดดเด่นมาก

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

  • ช่วงต้นอาชีพฉันเคยคิดว่าการเขียนโค้ดให้ได้เยอะ ๆ เป็นเรื่องสำคัญ ผ่านมา 20 ปี ตอนนี้ฉันกลับภูมิใจกับการลบโค้ดให้ได้มากกว่า ในมุมของวิศวกรความปลอดภัย โค้ดไม่ใช่แค่หนี้ แต่ยังเป็นความเสี่ยงด้วย โดยเฉพาะการพึ่งพาไลบรารีภายนอกที่เสี่ยงมาก ไม่นานมานี้ฉันกับเพื่อนร่วมงานเขียน Linux init system ขนาดเล็กไม่ถึง 600 บรรทัด โดยใช้แค่ Rust standard library และตอนนี้ก็ถูกใช้งานในโปรดักชันของหลายองค์กรแล้ว ไม่มี dependency และบูตเสร็จภายใน 1 วินาที ทำให้รู้สึกว่าเราไม่จำเป็นต้องมี systemd กับโค้ด C หลายล้านบรรทัด ก็สร้าง Linux server แบบ appliance ได้เหมือนกัน ถ้าทำเอง ปริมาณโค้ดจะน้อยกว่ามาก และเราสามารถเข้าใจทั้งระบบได้อย่างสมบูรณ์

    • ทำออกมาได้น่าทึ่งมาก แต่อยากรู้ว่าอาจมีอะไรตกหล่นไปหรือเปล่า

  • ฉันคิดว่าสถานการณ์เลวร้ายที่สุดของโค้ดที่ AI สร้างขึ้นจะเห็นชัดกว่าในโปรเจกต์ส่วนตัว มากกว่ามุมมองระดับบริษัท ฉันสามารถเขียนโค้ดดี ๆ 10,000 บรรทัดที่ตัวเองเข้าใจอย่างถ่องแท้ได้ หรือจะปั่นโค้ด 20,000 บรรทัดที่มีปัญหาออกมาอย่างรวดเร็วกว่าเดิมหลายเท่าก็ได้ สำหรับตัวฉันเอง พยายามหาสมดุลระหว่างสองแบบนี้ แต่ถ้าตั้งใจจะขยายการพัฒนาต่อไปเรื่อย ๆ ฉันคิดว่าเวลาที่เสียไปในกรณีแรกสุดท้ายก็อาจกลายเป็นต้นทุนที่เสียเปล่า

    • ฉันคิดว่ามันมีจุดกึ่งกลางอยู่เสมอ สำหรับฉัน การให้ AI สร้างโค้ดจริง ๆ เคยจำกัดอยู่แค่โค้ดที่จบในตัวเอง เช่นสคริปต์ Bash หรือ Python สคริปต์พวกนี้โต้ตอบกับแค่ command line ขอบเขตจึงชัดเจนและจัดการง่าย โค้ดแบบนี้เขียนครั้งเดียวแล้วแทบไม่ต้องกลับมาดูอีก แต่การให้ AI สร้างโค้ดโดเมนงานหลักไม่ได้มีความหมายมากนักเลย ฉันก็ยังต้องรีวิวโค้ดอยู่ดี และสิ่งที่ฉันต้องการจริง ๆ คือกรณีที่สามารถตรวจสอบความสามารถในการบำรุงรักษาของโค้ดได้ ถ้าไม่ใช่สถานการณ์ที่ทิ้งโค้ดได้เลย หรือแค่ตรวจดูแบบง่าย ๆ ก็พอ ก็ไม่มีเหตุผลต้องใช้เครื่องมือสร้างโค้ด ถ้า AI สามารถทำหน้าที่เป็น product owner เข้าใจความเสียหายทางธุรกิจจริง ๆ และปรับปรุงมันได้ด้วย เรื่องก็คงต่างออกไป แต่ถึงตอนนั้นก็คงต้องกังวลถึงความเสี่ยงที่ผู้ใช้อาจหายไปแทน

    • ฉันเองก็เคยเชื่อใจให้ AI เขียนโค้ดจำนวนมากเกินไป และทุกครั้งไม่ช้าก็เร็วก็ต้องชดใช้ด้วยผลผลิตที่หายไปอย่างเจ็บหนัก ถ้าแอปทั้งหมดสร้างแบบ vibe coding จริง ๆ ทักษะที่สำคัญที่สุดก็น่าจะเป็นความสามารถในการตัดสินว่า “เราต้องการฟีเจอร์นี้จริงไหม?” การดีบักสปาเกตตีโค้ดโดยไม่เข้าใจเลยว่าแต่ละบรรทัดทำหน้าที่อะไร น่าจะทรมานมากจริง ๆ

    • คุณบอกว่าเสียเวลาในกรณีแรก แต่กรณีที่สอง (โค้ดแย่กว่า แต่เร็วกว่า) ก็สุดท้ายเป็นการเสียเวลาเหมือนกัน ฉันคิดว่าประเด็นแก่นจริง ๆ คือการหาจุดกึ่งกลาง

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

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

    • จู่ ๆ ก็มีไอเดียขึ้นมา สงสัยว่าเราจะถาม AI ให้อธิบายชื่อตัวแปร/คำอธิบายฟังก์ชันในโค้ดได้ไหม จนถึงตอนนี้ฉันเคยใช้ AI แค่สร้างโค้ดเท่านั้น

  • บางบริษัทที่ฉันเคยทำงานนาน ๆ ไม่มีทรัพย์สินด้านโค้ดของตัวเองเลย แต่ธุรกิจหลักกลับพึ่งพาบริการ enterprise ของ 3rd party ภายนอก ประเด็นที่สงสัยคือ ในกรณีแบบนี้เราควรวัดว่า “มีโค้ดจริง ๆ เท่าไร” อย่างไร เช่นถ้าพึ่งพาผู้ให้บริการ SaaS แบบ legacy เราควรนับจำนวนบรรทัดโค้ดฝั่งนั้นเป็นหนี้ของเราด้วยไหม

    • สำหรับฉัน ความเสี่ยงใหญ่ที่สุดของการพึ่งพา 3rd party service คือฝั่งนั้นอาจล้ม หรือเงื่อนไขบริการเปลี่ยนไปเพราะการควบรวมกิจการ ส่วนใหญ่ก็มักเป็นกรณีที่เราจำเป็นต้องใช้บริการจากสตาร์ตอัปที่มีแค่เงินทุนเยอะ แต่ตัวบริการยังไม่สามารถยืนได้ด้วยตัวเองอย่างแท้จริง

    • เห็นด้วยกับประเด็นนี้มาก บริษัทเก่าของฉันเคยใช้ SaaS ด้าน email marketing แล้วถึงแม้โค้ด integration ที่เราสร้างจะมีแค่ประมาณ 500 บรรทัด เรากลับต้องเหนื่อยมากในการตามแก้ปัญหาของบริการนั้น สุดท้ายพอเราเลือกเอาเฉพาะฟีเจอร์ที่จำเป็นมาทำใหม่แล้วดึงกลับมาไว้ in-house ก็ประหยัดทั้งเงินและแรงไปมหาศาล แม้จำนวนบรรทัดโค้ดจะเพิ่มขึ้นราว 3,000 บรรทัดก็ตาม

  • ฉันยังไม่ค่อยเข้าใจ

    1. หมายความว่าเราไม่ต้องการโค้ดเลย จึงไม่ต้องการ AI coding ด้วยอย่างนั้นหรือ? ถ้าไม่ต้องการโค้ด การถกเถียงนี้ก็หมดความหมาย
    2. ถ้าตั้งสมมติฐานว่า AI สร้างโค้ดที่ทั้งเยอะและคุณภาพต่ำ แค่สมมติฐานนี้อย่างเดียวก็นำไปสู่ข้อสรุปว่าไม่ควรใช้ AI อยู่แล้ว แต่นี่เป็นสมมติฐานใหญ่ ไม่มีหลักฐานรองรับ และก็ไม่ใช่สิ่งที่บทความพูดด้วย ถ้าเปลี่ยนสมมติฐาน:
    3. ถ้า AI สร้างโค้ดที่น้อยกว่าและดีกว่าที่ฉันเขียนเองล่ะ? งั้นก็ควรใช้ไม่ใช่หรือ?
    4. ถ้า AI ให้คุณภาพเท่ากับที่ฉันทำเองแต่เร็วกว่า 50% ก็ยิ่งควรใช้ไม่ใช่หรือ?

  • โค้ดเป็นสินทรัพย์แน่นอน แต่เช่นเดียวกับฮาร์ดแวร์ มันก็มีการด้อยค่าจากหลายสาเหตุ (ข้อบกพร่อง การเปลี่ยนแปลงของอุตสาหกรรมซอฟต์แวร์/ฮาร์ดแวร์ ฯลฯ) ยิ่งมีซอฟต์แวร์โค้ดมาก ต้นทุนที่ต้องคิดค่าเสื่อมในแต่ละปีก็ยิ่งสูงขึ้น ถ้าบริหารจัดการไม่ดีพอ (เช่น มีโค้ดมากเกินไปเมื่อเทียบกับจำนวนนักพัฒนา) ค่าใช้จ่ายในการแก้ปัญหาในภายหลังก็จะพุ่งแบบทวีคูณ เหมือนแนวคิดค่าเสื่อมราคาที่มี “ดอกเบี้ย” เพิ่มเข้ามา ดังนั้นฉันจึงเข้าใจว่าทำไมถึงใช้คำว่า “หนี้” แต่ก็ไม่ใช่แนวคิดที่ตรงกันเสียทีเดียว

  • แน่นอนว่า repository ที่สมบูรณ์แบบที่สุดก็คืออันนี้

  • เมื่อก่อนฉันเคยภูมิใจกับการลบโค้ดได้เดือนละ 20,000 บรรทัดไม่ใช่บวกแต่เป็นลบ ไม่กี่ปีก่อนเคยพยายามทำแบบนั้นอีกครั้งกับทีมนักพัฒนารีโมต 20 คน แต่ pull request ไหลเข้ามาไม่หยุดจนตามไม่ทัน ตอนนี้ฉัน pair programming กับ Claude Code และ GPT แล้ว และมันให้ความรู้สึกเหมือนกรณีหลังมากกว่า ฉันคิดว่ามีโอกาสทำรีแฟกเตอร์แบบฉลาด ๆ อยู่ตรงนี้ เพียงแต่คงต้องการบริบทมากกว่านี้ ฉันเคยลองทำอะไรแบบนี้กับโค้ด legacy โดยใช้ Cursor และ Claude opus 4.1 แต่แม้กระทั่งหนึ่งล้านโทเคนก็ยังไม่พอ เลยคิดว่าบางทีการแปลระหว่าง personal LLM กับ shared LLM อาจช่วยได้ ไม่รู้ว่ามีใครเคยมีประสบการณ์แบบนี้บ้างไหม

  • ดูเหมือนจะไม่มีใครถามคำถามสำคัญมากอย่าง “ปริมาณโค้ดขั้นต่ำที่จำเป็นอย่างแท้จริงในการทำฟีเจอร์ X ให้สมบูรณ์คือเท่าไร?” แม้แน่นอนว่าจะตอบให้เป๊ะไม่ได้ แต่การคิดแบบนี้ช่วยสร้างกรอบความคิดที่มีประสิทธิภาพได้ ตรงกันข้าม ผู้คนกลับสนใจเรื่องอย่าง formal verification ซึ่งในทางปฏิบัติอาจไม่สำคัญนัก ถ้าไม่พิจารณาปริมาณโค้ดขั้นต่ำที่ทำให้ใช้งานได้จริง formal verification ก็อาจกลายเป็นเรื่องสิ้นเปลืองและไร้ความหมายได้ และคนมักคิดว่าโค้ดที่วิศวกรเขียนนั้นล้วนดี แต่ในความเป็นจริง ส่วนใหญ่มักเพิ่ม abstraction และความซับซ้อนที่ไม่จำเป็น ทำให้งานยิ่งมากขึ้น งานด้าน software engineering ส่วนไม่น้อยจึงให้คุณค่าเป็นลบด้วยซ้ำ แน่นอนว่ามันมีทั้งส่วนบวกและลบปะปนกันอยู่ จึงยิ่งตัดสินได้ยาก
 
2025-09-03
[ความคิดเห็นนี้ถูกซ่อน]