AI ของคุณเพิ่งสร้าง Technical Debt จำนวนมหาศาล
AI ถูกออกแบบมาให้ปรับปรุง codebase แต่กลับทำให้แย่ลง
นับตั้งแต่มีการคิดค้น version control ขึ้นมา นี่เป็นครั้งแรกที่ทีมงานทำงานได้เร็วขึ้น และพังมากขึ้น
AI ทำสามสิ่งให้ทีมวิศวกรรม เขียนโค้ดได้เร็วขึ้น จับข้อบกพร่องได้เร็วขึ้น และสร้างสิ่งที่ทีมปัจจุบันไม่สามารถสร้างได้ด้วยตัวเอง
อุตสาหกรรมเดิมพันทุกอย่างกับสิ่งแรก ความเร็ว โค้ดมากขึ้น เร็วขึ้น
ไม่มีใครถามว่าจะเกิดอะไรขึ้นเมื่อคุณเพิ่มผลลัพธ์ของทีมที่ครึ่งหนึ่งของ codebase ของตัวเองก็ไม่เข้าใจเป็นสามเท่า
ที่มา: https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
ผมเคยเห็นสิ่งนี้มาก่อน เราทุกคนเคยเห็น
ในช่วงปลายทศวรรษ 1990 Enterprise Java สัญญาว่าจะเขียนครั้งเดียว ทำงานได้ทุกที่ บริษัทต่างๆ ทุ่มทั้งสายผลิตภัณฑ์ลงไป J2EE, EJBs, middleware stacks
พอถึงปี 2005 การเปลี่ยนสีปุ่มในแอป Enterprise Java ทั่วไปต้องใช้ 14 ไฟล์ใน 6 package Martin Fowler เรียกมันว่า "โรคขององค์กร" บริษัทต่างๆ ไม่สามารถส่งมอบงานได้ พวกเขาจ้างใครก็ได้ที่เข้าใจระบบไม่ได้ พวกเขาเขียนใหม่ไม่ได้เพราะไม่สามารถจัดทำเอกสารว่าระบบเก่าทำอะไร
การแก้ไขใช้เวลาหนึ่งทศวรรษ เฟรมเวิร์กน้ำหนักเบา TDD CI Agile อุตสาหกรรมต้องสร้างเลเยอร์การจัดการขึ้นมาใหม่รอบเทคโนโลยี
AI กำลังทำสิ่งเดียวกันในไทม์ไลน์ที่ถูกบีบอัด
เราให้ความสามารถแก่นักพัฒนาทุกคนในการสร้างโค้ดหลายพันบรรทัดต่อวัน นักพัฒนาที่เขียน prompt อธิบายสิ่งที่มันสร้างไม่ได้ ผู้ตรวจสอบที่อนุมัติไม่ได้อ่านมัน และนักพัฒนาคนต่อไปที่รับช่วงต่อจะปฏิบัติต่อมันเหมือนกล่องดำ เพราะมันก็เป็นอย่างนั้น
ผมได้เห็นสิ่งนี้ทั้งใน brownfield codebase และ greenfield demo พวกมันพังในแบบเดียวกัน
นี่คือ 5 รูปแบบความล้มเหลวที่เราเห็นจากการทำงานจริง
5 รูปแบบความล้มเหลวของ AI กับ Codebase จริง
1. ปริมาณโค้ดที่ AI สร้างขึ้นคือ "การโยนคนเข้าไป" แบบใหม่
CTO ทุกคนซื้อที่นั่ง Cursor บอร์ดทุกแห่งถามหา ROI วงจร hype วิ่งครบรอบในเวลาไม่ถึงปี
แต่โค้ดที่มากขึ้นไม่เคยเป็นปัญหา
70% ของบริษัทใน Fortune 500 ยังคงใช้ซอฟต์แวร์ที่อายุเกินยี่สิบปี codebase เหล่านั้นทำงานช้าไม่ใช่เพราะนักพัฒนาพิมพ์ช้า แต่ช้าเพราะไม่มีใครในบริษัทที่ยังมีชีวิตอยู่เข้าใจกฎทางธุรกิจทั้งหมดที่ถูกเข้ารหัสในโค้ด
ให้ AI agent เข้าถึง codebase นั้น มันจะสร้างโค้ดที่ทำงานได้ ผ่านการทดสอบ และละเมิดสัญญาที่ไม่มีใครเคยบันทึกไว้
รายงาน DORA ปี 2026: เครื่องมือ AI ให้ผลลัพธ์ดีขึ้น 35-40% ในงาน greenfield ที่สะอาด ใน brownfield เครื่องมือเดียวกัน ได้ 10% หรือน้อยกว่า ช่องว่าง 4 เท่า
คอขวดคือความเข้าใจ AI ทำให้มันแย่ลง
2. Comprehension Debt คือ Technical Debt ตัวใหม่
GitClear วิเคราะห์การเปลี่ยนแปลงโค้ด 623 ล้านครั้ง การปรับโครงสร้างโค้ดเก่าลดลง 74% ตั้งแต่ปี 2023 เครื่องมือ AI สร้างโค้ดใหม่แทนที่จะใช้ซ้ำสิ่งที่มีอยู่ ผ่านการทดสอบ ปิด ticket ไม่มีการรวมเข้ากับระบบที่มีอยู่
Addy Osmani จาก Google ตั้งชื่อมันว่า Comprehension Debt: ช่องว่างระหว่างปริมาณโค้ดที่มีอยู่กับปริมาณที่มนุษย์คนใดคนหนึ่งเข้าใจ
ใน codebase อายุ 6 เดือน คุณฟื้นตัวได้ ในโมโนลิธอายุ 10 ปีที่มีการผสานรวมที่ไม่มีเอกสารและกฎทางธุรกิจที่กระจายอยู่ทั่วไฟล์หลายร้อยไฟล์ คุณฟื้นตัวไม่ได้
Technical Debt คือโค้ดที่คุณรู้ว่าไม่ดี Comprehension Debt คือโค้ดที่คุณไม่สามารถประเมินได้เลย AI เป็นเทคโนโลยีแรกที่สร้างแบบที่สองในระดับใหญ่
3. Review Theater คือการประทับตรายางแบบใหม่
PR 31% มากขึ้นที่ถูก merge โดยไม่มีการตรวจสอบในชุดข้อมูลนักพัฒนา 22,000 คนของ Faros AI เวลาตรวจสอบเฉลี่ยเพิ่มขึ้น 5 เท่าเพราะผู้ตรวจสอบตามปริมาณไม่ทัน
ผลลัพธ์มากขึ้น ควบคุมคุณภาพน้อยลง ไม่มีใครมีอำนาจชะลอมัน เราเห็นรูปแบบองค์กรนี้เป็นร้อยครั้งก่อนที่ AI จะมีอยู่ ตอนนี้มันทำงานด้วยความเร็วของเครื่องจักร
Anthropic พบว่านักพัฒนาที่ใช้ AI แบบมอบหมายงานเฉยๆ ได้คะแนนต่ำกว่า 40% ในการทดสอบความเข้าใจ แบบสอบถามเชิงรุก: 65%+ เครื่องมือเดียวกัน ตัวแปรคือมนุษย์
ทีมส่วนใหญ่ใช้ AI เพื่อหลีกเลี่ยงการคิด สิ่งนั้นจะตามมาทันคุณใน production
4. คนที่เข้าใจระบบมีแรงจูงใจน้อยที่สุดที่จะป้อนมันให้ AI
ผมคุยกับหัวหน้าฝ่ายวิศวกรรมของบริษัทซอฟต์แวร์ที่ได้รับการสนับสนุนจาก PE ซึ่งมีรายได้ประมาณ 15 ล้านเหรียญ ทีมของเขาลองใช้ Claude ภายใน คำพูดของเขา: "มันทำเรื่องงี่เง่าเยอะแยะ"
เขาถูกต้องที่กังขา
Ford ปล่อยให้วิศวกรที่มีประสบการณ์ลาออกก่อนที่ความรู้ของพวกเขาจะถูกใช้ฝึกระบบคุณภาพ สามปีและค่าใช้จ่ายในการรับประกันหลายพันล้านเหรียญต่อมา พวกเขาจ้างวิศวกรทหารผ่านศึกกลับมา 350 คน วิศวกรเหล่านั้นฝึก AI ใหม่ สร้างกระบวนการคุณภาพใหม่ ตอนนี้ Ford ขึ้นอันดับหนึ่งในการศึกษา Initial Quality Study ของ JD Power ปี 2026 เป็นครั้งแรกในรอบ 16 ปี
VP ฝ่ายวิศวกรรมฮาร์ดแวร์ของพวกเขา: พวกเขาคิดว่าการนำเข้าข้อกำหนดการออกแบบจะผลิตสินค้าคุณภาพสูง มันไม่เป็นเช่นนั้น ความเชี่ยวชาญในโดเมนต้องมาก่อน
คนที่ถือความรู้ของสถาบันได้เห็น "ประสิทธิภาพ" รอบที่แล้วที่ริเริ่ม พวกเขารู้ว่าเกิดอะไรขึ้นหลังจากที่กระบวนการถูกบันทึก สมาคมช่างฝีมือในยุคกลางเก็บวิธีการของพวกเขาเป็นความลับด้วยเหตุผลเดียวกัน
5. Codebase ที่ต้องการ AI มากที่สุดคือที่ที่ AI ทำงานได้แย่ที่สุด
แพลตฟอร์ม SaaS ระดับกลาง ระบบสุขภาพ ระบบหลังบ้านโลจิสติกส์ ผลิตภัณฑ์บริการทางการเงินที่สร้างโดยนักพัฒนาที่ลาออกไปหลายปีแล้ว
บริษัทเหล่านี้มีลูกค้าที่จ่ายเงิน รายได้จริง และกฎทางธุรกิจที่คุ้มค่าที่จะรักษาไว้ พวกเขามีพื้นที่ผิวที่ใหญ่ที่สุดสำหรับ AI ที่จะเร่งความเร็ว
เครื่องมือเขียนโค้ด AI ทุกตัวที่ขายในวันนี้สันนิษฐานว่า codebase สะอาด สถาปัตยกรรมเป็นโมดูลาร์ นักพัฒนาสามารถให้บริบทแก่ agent ได้เพียงพอ สมมติฐานนั้นพังทลายภายในโมโนลิธอายุ 10 ปีที่มีการผสานรวมที่ไม่มีเอกสารและกฎทางธุรกิจที่ไม่มีใครจำได้ว่าเขียน
74% ของโครงการริเริ่ม AI ไม่สามารถขยายเกิน pilot ตาม Gartner โมเดลทำงานได้ดี codebase ยังไม่พร้อมสำหรับมัน
อะไรที่แก้ไขได้จริง
เราพิสูจน์สิ่งนี้ในงานจริง วิศวกรสองคนบนแพลตฟอร์มโลจิสติกส์รุ่นเก่า 330 PR ที่ถูก merge ใน 6 เดือน ~90% เป็นโค้ดที่ AI สร้าง ลูกค้าเรียกพวกเขาว่าทีมที่มีประสิทธิภาพสูงสุด พวกเขาได้รับโบนัสตามดุลยพินิจสองครั้ง
ผลลัพธ์นั้นมาจากการเตรียมตัว ไม่ใช่โมเดลที่ดีกว่า สามสิ่งที่เกิดขึ้นก่อนที่ AI จะแตะโค้ดแม้แต่บรรทัดเดียว
จัดทำเอกสารก่อนเขียน prompt เราเรียกมันว่า Step Zero ก่อนที่ AI agent ใดๆ จะแตะ brownfield codebase คุณสแกนโค้ดที่มีอยู่ สร้างเอกสารที่ AI อ่านได้ ทำให้ระบบอ่านออกได้สำหรับเครื่องมือ agent ไม่สามารถใช้เหตุผลเกี่ยวกับสิ่งที่มันมองไม่เห็น การพลิกกลับของ Ford เริ่มต้นที่นี่ พวกเขานำคนที่เข้าใจระบบกลับมา จัดทำเอกสารสิ่งที่พวกเขารู้ จากนั้นจึงฝึก AI ใหม่
กำหนดโซน 80/20/0 80% ของ boilerplate (CRUD, การทดสอบ, คอนฟิก, เอกสาร): AI สร้างได้อย่างอิสระ 20% ของตรรกะทางธุรกิจและการผสานรวม: โหมด copilot, AI ร่าง, วิศวกรเขียนใหม่ 0% ของ auth, การชำระเงิน, การเข้ารหัส, การตัดสินใจด้านสถาปัตยกรรม: ไม่มี AI แตะต้องมัน วินัยนั้นป้องกันไม่ให้ comprehension debt ทวีคูณ
วัดผลก่อนขยายขนาด ต้นทุนต่อ commit รูปแบบการใช้งานโมเดล เปอร์เซ็นต์โค้ดจาก AI DORA metrics ทุกทีม Baseline ก่อน AI วัดผลหลังจากนั้น หากไม่มีข้อมูลนั้น คุณกำลังบินโดยสัญชาตญาณไปสู่ acceleration whiplash เดียวกันที่กระทบนักพัฒนา 22,000 คนในชุดข้อมูล Faros
สิ่งนี้กำลังจะไปทางไหน
Microsoft ทุ่มเงิน 2.5 พันล้านเหรียญ Amazon ทุ่ม 1 พันล้านเหรียญ Anthropic ระดมทุน 1.5 พันล้านเหรียญ OpenAI ระดมทุน 4 พันล้านเหรียญ ทั้งหมดมุ่งเป้าไปที่ปัญหาเดียวกัน: ทำให้ AI ทำงานภายในบริษัทที่มีอยู่แล้ว
ตลาดมุ่งเน้นไปที่ greenfield เพราะ demo ดูดีกว่า ผลกระทบทางวิศวกรรมที่ใหญ่ที่สุดจะมาจากบริษัทที่มี codebase น่าเกลียดที่สุด มีผลิตภัณฑ์เก่าแก่ที่สุด และมี pipeline ที่สร้างขึ้นก่อนที่ใครจะเคยได้ยินเกี่ยวกับ LLM
คอขวดคือระบบวิศวกรรมที่อยู่ใต้โมเดล
ป.ล. นี่คือสิ่งที่เราทำที่ Limestone Digital เราฝังทีมวิศวกรรม AI-native ลงใน codebase ที่มีอยู่ Step Zero, ระเบียบวินัยของโซน, โครงสร้างพื้นฐานการวัดผล หาก AI pilot ของคุณติดขัดใน brownfield codebase ส่ง DM หาผม
ติดต่อ: limestonedigital.com
