ข้ามไปยังเนื้อหา
บทความทั้งหมด

จาก 7 ปีเหลือ 7 วันด้วย Agentic AI

โดย Ghazi Triki · อ่าน 5 นาที

จากเจ็ดปีเหลือเจ็ดวัน
ในบทความนี้

หากคุณเคยเปิดสเปรดชีต COCOMO II แล้วเห็นว่ามันคาดการณ์ระยะเวลา 33 เดือนตามปฏิทินสำหรับโครงการที่ทีมของคุณส่งมอบได้ภายในสองสปรินต์ คุณย่อมรู้ปัญหาอยู่แล้ว นั่นคือ แบบจำลองการประมาณการทุกแบบที่ใช้กันอยู่ในปัจจุบันถูกปรับเทียบในโลกที่นักพัฒนาพิมพ์โค้ดทุกบรรทัดเอง การสลับบริบทมีต้นทุน และปฏิทินหยุดเดินตอน 17:00 น. โลกแบบนั้นไม่มีอยู่อีกต่อไปแล้ว เมื่อไม่นานมานี้ เราพัฒนาแอปพลิเคชันขนาด 286 KLOC จำนวน 672 ไฟล์ ซึ่งประกอบด้วยหลายระบบย่อยขึ้นใหม่ทั้งหมด ได้แก่ ชั้นโปรโตคอล ชั้นข้อมูล เอนจินเรนเดอร์ และการผสานรวมกับแพลตฟอร์ม และได้รุ่นอัลฟาที่พร้อมทดสอบภายใน 7 วัน ชุดแบบจำลองทั้งหมด (COCOMO Basic/Intermediate/Post-Architecture, Function Points, SLOC baseline, Putnam/SLIM) ให้ค่ามัธยฐานของการคาดการณ์ที่ 30.3 เดือนตามปฏิทิน ค่ามัธยฐานของตัวคูณผลิตภาพคือ 4,240× แม้แต่ค่าฐานที่อนุรักษ์นิยมที่สุด (25 SLOC ต่อนักพัฒนาต่อวันสำหรับระบบที่ซับซ้อน) ก็ยังคลาดเคลื่อนถึง 1,433× แบบจำลองเหล่านี้ไม่ได้ผิด แต่ถูกนำไปใช้อย่างไม่เหมาะสม ด้านล่างนี้คือการวิเคราะห์ทีละแบบจำลอง การปรับเทียบเชิงประจักษ์จากผู้พัฒนาคนเดียวกัน และสิ่งที่งานวิจัยแบบ RCT ช่วงปี 2024 ถึง 2026 บอกจริง ๆ ว่า Agentic AI ย่นระยะเวลาได้ในส่วนใด และส่วนใดที่ทำไม่ได้

โครงการที่ทำให้การประมาณการล้มเหลว

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

  • 286,662 SLOC (ประมาณ 286 KLOC) กระจายอยู่ใน 672 ไฟล์ซอร์ส
  • การเปลี่ยนแปลงรวม 1,329,399 บรรทัด แบ่งเป็นการเพิ่ม 862,488 บรรทัด และการลบ 466,911 บรรทัด
  • 700 คอมมิต ใน 7 วันที่มีการพัฒนาจริง จนได้รุ่นอัลฟาแรกที่พร้อมทดสอบ
  • รองรับหลายภาษาครบถ้วนกว่าหลายสิบภาษา
  • ระบบย่อยหลายระบบที่ไม่เกี่ยวข้องกันเลย ได้แก่ การจัดการโปรโตคอล การจัดการข้อมูล การเรนเดอร์ และการผสานรวมกับแพลตฟอร์ม ซึ่งสร้างขึ้นใหม่ทั้งหมดสำหรับสภาพแวดล้อมเป้าหมาย

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

สิ่งที่แบบจำลองการประมาณการคาดการณ์ เทียบกับสิ่งที่เกิดขึ้นจริง

เครื่องมือนี้รันแบบจำลองการประมาณการหลักทุกแบบในวรรณกรรมด้านวิศวกรรมซอฟต์แวร์ ได้แก่ COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached และ Embedded แบบปรับจูน), COCOMO II Post-Architecture (แบบปรับจูน), Function Points, SLOC Productivity Baseline และ Putnam/SLIM โดยปรับเทียบตามประเภทโครงการด้วยค่าคงที่ที่เผยแพร่ในเอกสารต้นฉบับ

แบบจำลองการประมาณการความพยายามที่คาดการณ์ระยะเวลาที่คาดการณ์เร็วกว่าเมื่อเทียบกับจริง
COCOMO Basic (Organic)913 คน-เดือน33.3 เดือน2,282×
COCOMO Basic (Semi-Detached)1,696 คน-เดือน33.7 เดือน4,240×
COCOMO Basic (Embedded)3,200 คน-เดือน33.1 เดือน8,000×
COCOMO Intermediate (Semi-Det., tuned)1,259 คน-เดือน30.4 เดือน3,148×
COCOMO Intermediate (Embedded, tuned)2,376 คน-เดือน30.1 เดือน5,940×
COCOMO II Post-Architecture (tuned)1,703 คน-เดือน30.3 เดือน4,257×
Function Points (ประมาณการคร่าว ๆ)17.9 คน-เดือน7.5 เดือน45×
SLOC Productivity Baseline (25 SLOC/dev-day)573 คน-เดือน573.3 เดือน1,433×
Putnam/SLIMข้ามไป (ระยะเวลาน้อยกว่า 30 วัน ทำให้ T 4/3 ให้ค่าพุ่งสูงเกินจริง)ไม่มีไม่มี

ค่ามัธยฐานของตัวคูณผลิตภาพจากทุกแบบจำลองคือ 4,240× แม้แต่แบบจำลองที่อนุรักษ์นิยมที่สุดก็ยังคาดการณ์ระยะเวลาส่งมอบที่ นานกว่าที่เกิดขึ้นจริงราว 1,400 เท่า ส่วนแบบจำลองที่มองในแง่ดีที่สุดอย่าง Function Points ก็ยังคาดการณ์ไว้ที่ 7.5 เดือนตามปฏิทิน ซึ่ง นานกว่า 45 เท่า เมื่อเทียบกับ 7 วันที่ใช้จริง แบบจำลองบอกว่าโครงการนี้ควรใช้เวลาตั้งแต่ 7 เดือนถึง 47 ปี แต่รุ่นอัลฟาพร้อมทดสอบได้ภายใน 7 วัน

แบบจำลองเองก็ให้ผลขัดแย้งกัน ต่างกันตั้งแต่ 50× ถึง 8,000×

แบบจำลองเหล่านี้ไม่ได้ให้ผลสอดคล้องกัน บนฐานโค้ดเดียวกันนี้ ค่าคาดการณ์มีตั้งแต่ 17.9 ถึง 3,200 คน-เดือน หรือ ต่างกันถึง 178 เท่า การเปรียบเทียบมาตรฐานในงาน SEAA 2013 ซึ่งทดสอบ COCOMO II, SEER-SEM, SLIM และ TruePlanning กับโครงการจริง 51 โครงการ พบค่า MMRE อยู่ที่ 50 ถึง 100% การประเมินในปี 2023 บนชุดข้อมูล COCOMO NASA พบค่า MMRE ใกล้ 1.0 และ PRED(0.25) = 0.0 หมายความว่าไม่มีโครงการใดเลยที่ประมาณการได้ภายในช่วงคลาดเคลื่อน 25% แบบจำลองเหล่านี้ไม่เคยถูกออกแบบมาสำหรับโครงการที่มี AI ช่วย แต่ขนาดของช่องว่าง แม้จะคำนึงถึงความไม่แม่นยำของแบบจำลองแล้ว ก็บอกเราว่ามีบางสิ่งเปลี่ยนไปในระดับโครงสร้าง

งานวิจัยบอกอะไรจริง ๆ เกี่ยวกับ Agentic AI และผลิตภาพของนักพัฒนา

ตัวเลข 4,240× นั้นสุดโต่ง และผมไม่ต้องการกล่าวเกินจริง การสร้างโครงโค้ดในโครงการใหม่ (greenfield) ทำให้ปริมาณการเปลี่ยนแปลงโค้ดสูงเกินจริง และ SLOC ก็เป็นตัวแทนของคุณค่าที่อ่อนแอ ดังนั้นเรามาดูวรรณกรรมที่ผ่านการพิจารณาโดยผู้ทรงคุณวุฒิกัน ผู้ช่วยแบบ Copilot ให้ประโยชน์จริงแต่ไม่มากนัก Peng และคณะ (2023) พบว่านักพัฒนาที่ใช้ AI เป็นคู่เขียนโปรแกรมทำงานเสร็จ เร็วขึ้น 55.8% (95% CI: 21 ถึง 89%) RCT ของ Microsoft/Accenture/Fortune 100 (2025) ซึ่งเป็นงานศึกษาที่ใหญ่ที่สุดจนถึงปัจจุบัน (n=4,867) พบว่า จำนวนงานที่ทำเสร็จเพิ่มขึ้น 26% RCT ภายในของ Google (2024) พบว่าเวลาที่ใช้ต่องานลดลงประมาณ 21% การทดลองภาคสนามของ BIS/Ant Group (2024) วัดได้ว่า ผลผลิตโค้ดเพิ่มขึ้น 55% ในกลุ่มพนักงานระดับเริ่มต้น สรุปอย่างตรงไปตรงมาคือ 1.26× ถึง 1.56× สำหรับงานที่เหมาะสม เป็นผลจริง แต่ไม่ถึงขั้นพลิกโฉม Agentic AI ทำงานในอีกระดับหนึ่ง รายงานทบทวน Devin ประจำปี 2025 ของ Cognition ระบุผลลัพธ์ของลูกค้าว่า เร็วขึ้น 10× ในการย้ายระบบ ETL, 14× ในการย้ายเวอร์ชัน Java และ 20× ในการแก้ไขช่องโหว่ด้านความปลอดภัย Nubank รายงานว่า ประสิทธิภาพดีขึ้น 12× และ ประหยัดต้นทุนได้ 20× ในการปรับโครงสร้างโค้ดหลายล้านบรรทัด ซึ่งเดิมประเมินว่าต้องใช้วิศวกรนับพันคนและเวลาหลายปี งานพอร์ตของเราอยู่ในช่วงนี้พอดี ฮิสโทแกรมของคอมมิตแสดงช่วงที่มีคอมมิตหนาแน่นในเวลา 22:00 น. 00:00 น. และ 01:00 น. ซึ่งเป็นลักษณะเฉพาะของเซสชันที่ขับเคลื่อนด้วยเอเจนต์ หลักฐานโต้แย้งก็มีอยู่จริง RCT ของ Metr.org ในปี 2025 (นักพัฒนาที่มีประสบการณ์ 16 คน 246 งาน บนโครงการที่พัฒนามานาน) พบว่า AI ทำให้เวลาทำงานเพิ่มขึ้น 19% กล่าวคือ AI ทำให้นักพัฒนาที่มีประสบการณ์ทำงานช้าลง บนฐานโค้ดที่คุ้นเคย งานศึกษาแบบ difference-in-differences ในปี 2026 ซึ่งศึกษา GitHub repo 807 แห่งที่นำเครื่องมือ AI มาใช้ (He และคณะ, MSR ’26) พบว่าความเร็วเพิ่มขึ้นเพียง "ชั่วคราว" ขณะที่ความซับซ้อนของโค้ดเพิ่มขึ้นอย่าง "ต่อเนื่อง" จนทำให้งานช้าลงในระยะยาว ชื่องานวิจัยบอกทุกอย่างไว้แล้ว: Speed at the Cost of Quality ข้อสรุปร่วมคือ AI ช่วยได้มากในงานพัฒนาใหม่ (greenfield) และงานที่มีโครงสร้างชัดเจน ช่วยได้พอประมาณในงานเติมโค้ด และอาจทำให้ความเร็วลดลงบนฐานโค้ดที่พัฒนามานาน หนี้ด้านคุณภาพมีอยู่จริง

เหตุใดแบบจำลองจึงล้มเหลว: การเปลี่ยนแปลงเชิงโครงสร้างสามประการ

ไม่มีปัจจัยต้นทุน (cost driver) ใดในแบบจำลองดั้งเดิมที่มีค่าตั้งสำหรับกรณี "นักพัฒนามีเอเจนต์อิสระที่ไม่เคยหลับ และจดจำฐานโค้ดทั้งหมดไว้ในบริบท" การเปลี่ยนแปลงสามประการต่อไปนี้ทำให้เส้นโค้งระยะเวลายุบตัวลง

  1. คอขวดจากการพิมพ์หมดไปแล้ว

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

  1. ต้นทุนการสลับบริบทกำลังลดลงอย่างมาก

มนุษย์ที่สลับไปมาระหว่างชั้นโปรโตคอล ชั้นข้อมูล และเอนจินเรนเดอร์ ต้องเสียต้นทุนในการโหลดบริบทใหม่ทุกครั้ง แต่เอเจนต์ที่อ่าน repository ทั้ง 672 ไฟล์แล้วจ่ายต้นทุนนี้เพียงครั้งเดียว ความไม่สมมาตรนี้ทบต้นอย่างรวดเร็วบนฐานโค้ดขนาดนี้

  1. ปฏิทินไม่ใช่คอขวดอีกต่อไป

แบบจำลองแปลงคน-เดือนเป็นเดือนตามปฏิทินด้วยสมการจัดกำลังคนที่สันนิษฐานว่าทำงานตามวันทำงานของมนุษย์ แต่เซสชันของเอเจนต์ทำงานต่อเนื่องข้ามคืน ฮิสโทแกรมของคอมมิตแสดงผลงานต่อเนื่องตั้งแต่ 07:00 น. ถึง 01:00 น. หรือ 18 ชั่วโมงที่มีการทำงาน ไม่ใช่ 8 ชั่วโมง

การปรับเทียบเชิงประจักษ์จากผู้พัฒนาคนเดียวกัน

เนื่องจากแบบจำลองเชิงพารามิเตอร์ให้ผลต่างกันหลายระดับขนาด ผมจึงทำการปรับเทียบเชิงประจักษ์ข้ามโครงการด้วย โดยเปรียบเทียบปริมาณการเปลี่ยนแปลงโค้ดของผมเองต่อคน-วัน ก่อนและหลังเริ่มใช้เครื่องมือ Agentic AI บน repository ใช้งานจริงอีกสามแห่งในระบบนิเวศเดียวกัน

โครงการก่อนใช้ AI (บรรทัด/วัน)ยุค AI (บรรทัด/วัน)ตัวคูณ
โครงการ A (โหลดบาลานเซอร์)6732,0563.1×
โครงการ B (บริการรายงาน)2392,1278.9×
โครงการ C (บริการประมวลผล)1,3229820.7×
รวม (ค่าเฉลี่ย / ค่ามัธยฐาน)ไม่มีไม่มี4.2× / 3.1×

ผู้พัฒนาคนเดียวกัน โดเมนเดียวกัน และเป็นงานบำรุงรักษาจริง ตัวคูณเชิงประจักษ์อยู่ที่ 3 ถึง 9× ซึ่งอนุรักษ์นิยมกว่าตัวเลข 4,240× ของโครงการใหม่อย่างมาก และสอดคล้องกับช่วงบนของงานวิจัยด้าน Agentic AI ที่เผยแพร่แล้ว มีโครงการหนึ่งที่ ช้าลง จริง ซึ่งแสดงว่าประโยชน์ที่ได้ขึ้นอยู่กับลักษณะงาน ไม่ได้เกิดขึ้นกับทุกงาน

ความหมายต่อการวางแผนโครงการ

หากคุณยังประมาณการโครงการซอฟต์แวร์ด้วยแบบจำลองที่ไม่ได้ปรับเทียบ และใช้ค่าฐาน 25 SLOC ต่อวัน การประมาณการงานที่มี AI ช่วยของคุณจะคลาดเคลื่อนตั้งแต่หนึ่งถึงสามระดับขนาด ต่อไปนี้คือสิ่งที่เราทำที่ RIADVICE

  1. ปรับเทียบกับประวัติของคุณเอง เปรียบเทียบผลผลิตโค้ดของคุณเองต่อคน-วัน ทั้งเมื่อใช้และไม่ใช้ AI วิธีนี้มีต้นทุนต่ำกว่า ตรงไปตรงมากว่า และให้ช่วง 3 ถึง 9× ที่คุณใช้อ้างอิงในแผนโครงการได้อย่างมีเหตุผล
  2. แยกงานพัฒนาใหม่ออกจากงานบำรุงรักษา ตัวคูณของ Agentic AI สูงที่สุดในงานพัฒนาใหม่และงานที่มีโครงสร้างชัดเจน และต่ำที่สุด (บางครั้งติดลบ) ในงานบำรุงรักษาฐานโค้ดที่พัฒนามานาน อย่าใช้ตัวเลขเดียวกับทั้งสองกรณี
  3. กันงบประมาณไว้สำหรับหนี้ด้านคุณภาพ ความเร็วที่ได้จาก AI มาพร้อมกับความซับซ้อนที่เพิ่มขึ้นอย่างต่อเนื่อง วางแผนช่วงเสริมความแข็งแกร่งของระบบและวัดผลอย่างเป็นระบบ โดยติดตามความซับซ้อนแบบ cyclomatic และตรวจหาโค้ดที่คัดลอกซ้ำในทุกการเผยแพร่
  4. ประมาณการทั้งเส้นโค้ง ไม่ใช่แค่ช่วงต้น ความเร็วที่เพิ่มขึ้น 10× แต่ทำให้ความหนาแน่นของข้อบกพร่องเพิ่มเป็นสองเท่า ไม่ใช่ประโยชน์ 10× จริง แต่เป็นการดึงกำหนดการให้เร็วขึ้นโดยแลกกับช่วงปรับเสถียรภาพที่ยาวขึ้น

บทสรุป

โครงการที่แบบจำลองการประมาณการทุกแบบบอกว่าควรใช้เวลา 7 เดือนถึง 47 ปี ได้รุ่นอัลฟาที่พร้อมทดสอบภายใน 7 วัน ค่ามัธยฐานของตัวคูณที่ 4,240× ไม่ควรกลายเป็นแผนโครงการของใคร แต่เป็นสัญญาณที่ชัดเจนว่า ระยะเวลา ของการพัฒนาซอฟต์แวร์ที่ซับซ้อนกำลังถูกบีบให้สั้นลงด้วยแรงเดียวกับที่บีบ ความพยายาม ให้ลดลง งานวิจัยที่เผยแพร่แสดงให้เห็นว่า AI ให้ผลตั้งแต่ การผลักเล็กน้อยที่ 1.26× ไปจนถึง การพุ่งขึ้น 20× โดยมีความเสี่ยงจริงที่จะ ได้ผลตอบแทนติดลบ บนฐานโค้ดที่พัฒนามานาน และมีต้นทุนด้านคุณภาพที่วัดได้ แบบจำลองที่บอกเราว่าโครงการนี้ควรใช้เวลาหลายทศวรรษ คือแบบจำลองเดียวกับที่ยังคงรันอยู่ในสเปรดชีตประมาณการขององค์กรต่าง ๆ ในปัจจุบัน คำถามไม่ใช่ว่า Agentic AI เปลี่ยนระยะเวลาของโครงการหรือไม่ เพราะงานวิจัยได้ตอบคำถามนั้นแล้ว คำถามคือแนวปฏิบัติด้านการประมาณการของคุณตามหลักฐานทันแล้วหรือยัง หากตัวเลขของคุณยังมาจากแบบจำลองปี 1981 ที่ปรับเทียบกับ COBOL และภาษาแอสเซมบลี ก็ถึงเวลาปรับเทียบใหม่ หรืออย่างน้อยก็เลิกเชื่อกำหนดการที่แบบจำลองนั้นพิมพ์ออกมา

"ยังมีช่องว่างอีกมากที่ต้องปรับปรุง เพื่อรับมือกับความท้าทายด้านการคาดการณ์ที่พบในทางปฏิบัติได้ดียิ่งขึ้น"

Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013

🏆 ความเชี่ยวชาญด้านวิศวกรรมและคลาวด์ที่ไว้วางใจได้

RIADVICE: พันธมิตรที่ไว้วางใจได้ด้านวิศวกรรมซอฟต์แวร์

เราออกแบบ สร้าง และปรับใช้ระบบซอฟต์แวร์ที่ซับซ้อน ด้วยวินัยทางวิศวกรรมและเครื่องมือที่พร้อมส่งมอบงานในยุค AI ตรงเวลา ตรงงบประมาณ และได้คุณภาพ

ดูข้อมูลเพิ่มเติมเกี่ยวกับบริการของเรา →

📚 แหล่งอ้างอิงและเอกสารอ่านเพิ่มเติม

บทความนี้อ้างอิงงานวิจัยที่ผ่านการพิจารณาโดยผู้ทรงคุณวุฒิ การทดลองแบบสุ่มที่มีกลุ่มควบคุม และรายงานภาคสนามจากอุตสาหกรรม เกี่ยวกับผลิตภาพของการพัฒนาซอฟต์แวร์โดยมี AI ช่วย และการประมาณการความพยายามในการพัฒนาซอฟต์แวร์

⚡ RIADVICE.com มอบงานวิศวกรรมที่ไว้วางใจได้ ความเชี่ยวชาญด้านคลาวด์ และโซลูชันซอฟต์แวร์ระดับองค์กร ตรงเวลา ตรงงบประมาณ และได้คุณภาพ

แชร์บทความนี้

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