Many people say AI will make software development much cheaper. They imagine models replacing engineers, finishing tasks in minutes. That story is tempting, but it is not entirely true. The economics of building software have shifted, not vanished. Technical debt did not evaporate when the first coding assistant shipped. We simply found a new way to finance it.
ใบแจ้งหนี้แบบเก่า: จำนวนพนักงาน (Head Count)
เป็นเวลาหลายทศวรรษที่หนี้ทางเทคนิค (technical debt) สร้างวงจรหายนะที่คุ้นเคย โค้ดเบส (codebase) จะเริ่มเปราะบาง ฟีเจอร์ที่เคยใช้เวลาทำเพียงไม่กี่วันเริ่มลากยาวเป็นสัปดาห์ เมื่อกำหนดการเลื่อนออกไป ฝ่ายบริหารก็เปิดรับสมัครพนักงานเพิ่ม ทีมที่ใหญ่ขึ้นกลับยิ่งทำให้ทุกอย่างช้าลง การประสานงานที่ซับซ้อนเพิ่มขึ้น การประชุม stand-up มีมากขึ้น และกฎของ Conway (Conway’s Law) ก็เริ่มทำงาน: ซอฟต์แวร์เริ่มสะท้อนถึงการสื่อสารที่ผิดพลาดของผู้คนที่สร้างมันขึ้นมา บั๊กหลุดรอดออกมามากขึ้น การแก้ไขแต่ละครั้ง (patch) ก็ยิ่งเพิ่มความซับซ้อนใหม่ๆ เข้าไป บริษัทต่างๆ ต้องจ่ายค่าความเสื่อมโทรมนี้ด้วยสกุลเงินเดียวที่พวกเขารู้จัก นั่นคือเงินเดือนของพนักงาน ต้นทุนนี้เห็นได้ชัดเจน มันปรากฏให้เห็นในทุกการตรวจสอบงบประมาณรายไตรมาส
ใบแจ้งหนี้แบบใหม่: Tokens และ Context
Generative AI ไม่ได้ทำลายวงจรนี้ แต่มันเพียงแค่เสนอแผนการชำระเงินทางเลือก แทนที่จะจ้างวิศวกรห้าคนเพื่อฝ่าฟันอุปสรรค บริษัทกลับเลือกที่จะรูดบัตรเครดิตเพื่อซื้อพลังการประมวลผล (compute) เพิ่มขึ้น อาการอาจจะดูต่างออกไป แต่โรคที่เป็นอยู่คือโรคเดิม
เมื่อโมเดลเริ่มทำงานผิดพลาด—เช่น การหลอน (hallucinating) เกี่ยวกับ internal API, การมองข้ามกรณีขอบเขต (edge cases) ที่สำคัญ, หรือการสร้างเทสต์ที่ผ่านด้วยเหตุผลที่ผิด—ปฏิกิริยาตอบโต้ที่เกิดขึ้นมักไม่ใช่การทำ refactor แต่เป็นการใช้เงินไปกับการทำ inference แทน ทีมต่างๆ จะซื้อการอัปเกรด context-window, สร้างลูปการลองใหม่แบบ multi-agent, ขยับไปใช้โมเดลระดับ frontier ที่ใหญ่ขึ้น หรือกดปุ่ม regenerate ซ้ำๆ จนกว่าผลลัพธ์ (diff) จะดูยอมรับได้ กลยุทธ์เหล่านี้ช่วยรักษาความเร็วที่เห็นได้ชัด (apparent velocity) ไว้ได้สักหนึ่งหรือสอง sprint ทำให้บอร์ด Jira ยังคงเป็นสีเขียว ในขณะเดียวกัน สถาปัตยกรรมที่แท้จริงกลับไม่ได้รับการแตะต้องเลย: ความสัมพันธ์ที่พันกันยุ่งเหยิงเหมือนเดิม, สถานะ global ที่เปลี่ยนแปลงได้ (mutable global state) เหมือนเดิม, และระบบ monolith ตัวเดิมที่ไม่มีใครในทีมปัจจุบันเข้าใจมันอย่างถ่องแท้
ทำไมโค้ดที่สกปรกถึงต้องจ่ายด้วย Tokens
โมเดลภาษาขนาดใหญ่ (LLMs) จะให้เหตุผลได้ดีที่สุดเมื่ออยู่กับ abstraction ที่สะอาดสะอ้าน อย่างไรก็ตาม คลังโค้ด (repositories) ส่วนใหญ่ในระดับองค์กรเปรียบเสมือนแหล่งโบราณคดี พวกมันเต็มไปด้วยการพึ่งพากันแบบเป็นวงกลม (circular package dependencies), ผลข้างเคียงที่ซ่อนอยู่ (hidden side effects) ในสคริปต์เริ่มต้นระบบ, และตรรกะทางธุรกิจ (business logic) ที่กระจายอยู่ตาม database triggers, middleware layers และ front-end components ในสภาพแวดล้อมเช่นนั้น โมเดลไม่ได้ใช้พลังงานไปกับการเขียนตรรกะใหม่ แต่มันเผาผลาญ tokens ไปกับการทำความเข้าใจ
พื้นที่ส่วนใหญ่ของ context window ขนาด 128,000 tokens อาจถูกใช้ไปเพียงเพื่อจดจำโครงสร้างของระบบไว้ในหน่วยความจำ ส่วนที่เหลือจึงเป็นสิ่งที่เหลือไว้สำหรับการแก้ปัญหาจริงๆ มันเหมือนกับการขอให้วิศวกรโครงสร้างออกแบบชั้นใหม่ ในขณะที่บังคับให้เขาต้องวาดพิมพ์เขียวของอาคารเดิมขึ้นมาใหม่จากความจำก่อนการคำนวณทุกครั้ง ผลลัพธ์ที่ได้คือทางออกที่ฉาบฉวย โมเดลจะสะท้อนความยุ่งเหยิงที่มันเห็น เพราะมันขาดอำนาจหรือบริบททางสถาปัตยกรรมที่จะเข้าไปจัดระเบียบห้องให้สะอาดก่อน
ผลลัพธ์ที่เร็วขึ้น แต่การส่งมอบที่ช้าลง
ความเร็วในการสร้าง (generation speed) ไม่ได้หมายถึงความเร็วในการส่งมอบ (shipping speed) หากสถาปัตยกรรมของคุณขาดความเป็นโมดูล (modularity) ทุกการเปลี่ยนแปลงที่สร้างโดย AI จะต้องผ่านการตรวจสอบโดยมนุษย์และการทำ regression testing อย่างละเอียด โมเดลอาจสร้าง pull requests ได้สิบรายการในบ่ายวันเดียว แต่ pull requests เหล่านั้นยังต้องผ่านสภาพแวดล้อมการรวมระบบ (integration environments), เครื่องมือสแกนความปลอดภัย, รายการตรวจสอบความสอดคล้อง (compliance checklists) และการทดสอบแบบ production canaries หากไม่มีขอบเขตของโมดูลที่ชัดเจน AI จะนำพาบั๊กเข้ามาด้วยความเร็วระดับเครื่องจักร มันสามารถแก้ไข utility ที่ใช้ร่วมกัน, อัปเดตจุดเรียกใช้งาน (call sites) ที่อยู่ห่างออกไปสามแห่งด้วยสมมติฐานที่ผิดพลาดเพียงเล็กน้อย และสร้างปัญหา race conditions ที่มนุษย์จะตรวจพบได้ก็ต่อเมื่อมีการแจ้งเตือนตอนตี 3 เท่านั้น คอขวดจึงย้ายจากคีย์บอร์ดไปอยู่ที่ pipeline การตรวจสอบ (validation pipeline) และ pipeline นั้นไม่ได้ถูกออกแบบมาเพื่อรองรับปริมาณการเปลี่ยนแปลงที่เพิ่มขึ้นถึงสิบเท่า
เพดานที่มองไม่เห็น
ในยุคก่อน AI ขีดจำกัดที่แท้จริงคือเรื่องงบประมาณการจ้างงาน ซึ่งอย่างน้อยก็อ่านค่าได้ง่ายบนสเปรดชีต แต่ในตอนนี้ ข้อจำกัดกลับถูกฝังอยู่ในรายการค่าใช้จ่ายที่ทีมการเงินแทบไม่ได้ติดตาม: ค่า inference, ค่าจัดเก็บ embedding, การขยาย context-window และสภาวะชะงักงันของการทดสอบอัตโนมัติ (automated-testing gridlock) ที่ทำให้ CI runners ทำงานไม่ได้ แดชบอร์ดแสดงประสิทธิภาพการทำงาน (productivity dashboards) ยังคงส่องแสงเป็นสีเขียว ในขณะที่ต้นทุนที่แท้จริงของแต่ละฟีเจอร์ใหม่กำลังพอกพูนขึ้นอย่างเงียบๆ
เอนโทรปีทางสถาปัตยกรรมคือตัวร้ายที่แท้จริงในเรื่องนี้ LLM ช่วยขยายการผลิตโค้ดได้อย่างยอดเยี่ยม แต่พวกมันไม่ได้ช่วยลดความซับซ้อน พวกมันไม่ได้ช่วยคลี่คลายความยุ่งเหยิงของ microservices, กำจัด dead code หรือยุบโครงสร้างลำดับชั้นการสืบทอด (inheritance hierarchies) เมื่อระบบก้าวข้ามจุดที่มนุษย์เริ่มยากที่จะทำความเข้าใจและใช้เหตุผลกับมันได้ AI ก็จะประสบปัญหาเช่นกัน ณ จุดหักเหดังกล่าว ต้นทุนจะพุ่งสูงขึ้นไม่ว่าคุณจะ