ต้นทุนการพัฒนาซอฟต์แวร์ลดลงถึง 90% แล้วหรือยัง?

 (martinalderson.com)
3 คะแนน โดย GN⁺ 2025-12-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเกิดขึ้นของเครื่องมือ Agentic Coding ทำให้ค่าใช้จ่ายด้านแรงงานในการพัฒนาซอฟต์แวร์ ลดลงอย่างรวดเร็ว
  • โปรเจกต์เว็บแอปภายในที่เคยใช้เวลาหนึ่งเดือน ตอนนี้สามารถเสร็จได้ภายใน หนึ่งสัปดาห์
  • เครื่องมืออย่าง Claude Code สามารถสร้างการทดสอบได้เป็นร้อยรายการในเวลาเพียงไม่กี่ชั่วโมง และสะท้อนการเปลี่ยนเป็นแบบที่ ทีมขนาดเล็กสร้างผลลัพธ์ขนาดใหญ่ได้
  • การลดต้นทุนทำให้เกิด Jevons Paradox (การระเบิดของอุปสงค์แฝง) ซึ่งอาจผลักดันให้มีองค์กรมากขึ้นในการสร้างซอฟต์แวร์แบบกำหนดเอง
  • ความรู้เชิงโดเมนของนักพัฒนาและความสามารถในการร่วมทำงานระหว่างมนุษย์กับเอเจนต์ กลายเป็นความได้เปรียบใหม่ และคาดว่าปี 2026 จะเห็นการเปลี่ยนผ่านอย่างรวดเร็วในหลายอุตสาหกรรม

การเปลี่ยนแปลงโครงสร้างต้นทุนการพัฒนาซอฟต์แวร์

  • การแพร่หลายของโอเพ่นซอร์สเป็นจุดเปลี่ยนครั้งแรกที่ลดต้นทุนเริ่มต้นในการพัฒนาซอฟต์แวร์
    • ในอดีต SQL Server และ Oracle ต้องเสียค่าลิขสิทธิ์หลายหมื่นดอลลาร์สหรัฐต่อปี แต่ MySQL ทำให้สามารถสร้างแอปพลิเคชันเครือข่ายได้ฟรี
  • ต่อมาการนำคลาวด์มาใช้ช่วยลดการลงทุนต้นทุนเริ่มต้นได้ แต่ผลประหยัดต้นทุนรวมยังคงจำกัด
  • ในช่วงหลายปีที่ผ่านมา TDD, Microservices, React Frontend ที่ซับซ้อน, Kubernetes กลับทำให้ความซับซ้อนเพิ่มขึ้น จนการลดต้นทุนหยุดชะงัก
  • ในทางตรงข้าม AI Agent ช่วยลดต้นทุนแรงงานในกระบวนการพัฒนาลงอย่างมาก

หลักฐานของการลดลง 90%

  • แม้ถึงต้นปี 2025 หลายคนยังมองว่าเครื่องมือการเขียนโค้ดด้วย AI ยังไม่ดี แต่ล่าสุด Agentic Coding CLI ได้พิสูจน์ประสิทธิภาพระดับสูงได้จริง
  • ตัวอย่างหนึ่งคือเครื่องมือภายในหนึ่งตัวที่มี โค้ดทดสอบมากกว่า 300 รายการ ถูกสร้างโดย Claude Code ภายในเวลาเพียงไม่กี่ชั่วโมง
  • โปรเจกต์ที่เคยใช้เวลาหนึ่งเดือนสามารถเสร็จได้ใน หนึ่งสัปดาห์
    • เวลาในการเขียนและนำไปใช้ลดลงมาก แต่เวลาในการคิด/ออกแบบยังคงเท่าเดิม
    • เมื่อทีมเล็กลง ภาระจากการสื่อสารระหว่างคนลดลงอย่างชัดเจน
  • ผลลัพธ์คือทีมขนาดเล็กสร้าง ผลิตภาพได้มากกว่า 10 เท่า

การระเบิดของอุปสงค์ที่แฝงอยู่

  • การลดต้นทุนเป็นผลจาก Jevons Paradox ซึ่งไม่ได้ลดความต้องการของอุตสาหกรรมทั้งระบบ แต่กลับขยายให้เพิ่มขึ้น
  • องค์กรหลายแห่งยังคงใช้กระบวนการทำงานแบบ Excel อยู่ และยังมีอุปสงค์แฝงในการย้ายมาทำเป็นแอป SaaS
  • หากโครงการเดิมที่เคยใช้ใบเสนอราคา 50,000 ดอลลาร์ลดลงเหลือระดับ 5,000 ดอลลาร์ แม้แต่โครงการที่ไม่จำเป็นยังกลายเป็นงานพัฒนาที่ทำได้
  • ดังนั้นปริมาณการผลิตรวมของอุตสาหกรรมการพัฒนาทั้งหมดอาจเพิ่มขึ้น

ความรู้โดเมนคือความได้เปรียบใหม่

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

ต้องเตรียมรับการเปลี่ยนแปลง

  • LLM และโมเดลเอเจนต์ พัฒนาขึ้นอย่างรวดเร็ว และเกณฑ์วัดผลเดิมไม่ทันอัปเดตตามความสามารถเหล่านี้
    • ตัวอย่างเช่น Opus 4.5 สามารถรักษาเซสชันได้อย่างเสถียรต่อเนื่อง 10~20 นาที
  • ด้วยการลงทุนโครงสร้างพื้นฐาน GPU ขนาดใหญ่ คาดว่าประสิทธิภาพของโมเดลในอนาคตจะเพิ่มขึ้นแบบก้าวกระโดด
  • นักพัฒนาบางคนยังคงพูดว่า “LLM มีข้อผิดพลาดสูง” หรือ “ไม่ช่วยประหยัดเวลา” แต่ความเห็นเชิงลบเหล่านี้ยิ่งแย่ลงเมื่อเทียบกับความจริงมากขึ้น
  • เหมือนกรณีวิศวกรเดสก์ท็อปที่มองข้าม iPhone ในปี 2007 หากปฏิเสธการเปลี่ยนแปลงอาจเสี่ยงถูกทิ้งไว้ข้างหลัง
  • บริษัทขนาดใหญ่มีโครงสร้างราชการจึงนำไปใช้ช้ากว่า แต่ ทีมขนาดเล็กสามารถนำไปใช้ได้ทันที
  • LLM มีประสิทธิผลไม่เฉพาะโครงการใหม่ แต่ยังสำหรับการวิเคราะห์และดูแลบำรุงรักษา codebase เดิม
    • โดยเฉพาะในการเข้าใจโครงสร้างโค้ดเก่า การค้นหาบั๊ก และการเสนอแนวทางแก้ไข ล้วนให้ประสิทธิภาพสูง
  • โดยสรุป มีความเป็นไปได้สูงว่าปี 2026 จะเป็นช่วงเปลี่ยนผ่านครั้งใหญ่ของวิธีการพัฒนา

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

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

 
GN⁺ 2025-12-09
ความคิดเห็นจาก Hacker News

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

  • ฉันเองก็ลองทำตามคำแนะนำที่ว่าให้ “ปรับตัวรับ AI coding อย่างจริงจัง” ดูแล้ว
    แต่เพราะทำงานสายหุ่นยนต์กับ embedded การใช้ AI ทำเว็บแอปหรือเกมเลยเป็นประสบการณ์ที่ น่าเบื่อและน่าอึดอัดมาก
    พอให้ Cursor ช่วยแก้ปัญหา มันกลับทำเละกว่าเดิม สุดท้ายเรียน Flask กับ JS เองยังมีประสิทธิภาพกว่ามาก
    AI เก่งมากในการค้นหาเอกสารหรือข้อความ error แต่การ “ปล่อยให้มันจับพวงมาลัย” ไม่ได้ช่วยอะไรเลย

    • ฉันก็มีประสบการณ์คล้ายกัน
      ยังสงสัยอยู่เลยว่าคำพูดที่ว่า AI ให้ “ประสิทธิภาพเพิ่ม 10 เท่า” นั้นจริงไหม
      ในความเป็นจริง การใช้มันเหมือน Google/Stack Overflow ที่อัปเกรดพลังแบบสุด ๆ ดูสมเหตุสมผลกว่า
      โค้ดส่วนใหญ่ฉันยังเขียนเอง และให้ AI ช่วยแค่งานซ้ำ ๆ ง่าย ๆ หรือเขียนสคริปต์เล็กน้อย
    • การให้ AI เขียนโค้ดแทนเป็น ทักษะที่ต้องฝึก
      ถ้าจะให้สำเร็จ คุณต้องสั่งและอธิบายให้ชัดเหมือนเป็น ‘เมนเทอร์’
      นิสัยสำคัญคือขอให้มันแก้ผ่านพรอมป์ต์โดยไม่ลงมือแตะเองทันที และกระบวนการนี้สุดท้ายก็ช่วยพัฒนา ทักษะการสื่อสาร

  • พอเห็นบทความแบบนี้ ก็ยิ่งชัดว่า มุมมองของทีมพัฒนาหน้างานกับผู้บริหารต่างกันมาก
    คนข้างบนมักคิดว่าตัวเองเข้าใจทั้งระบบจาก requirement ไม่กี่บรรทัด แต่จริง ๆ แล้วแทบไม่รู้เรื่อง dependency และบริบทเลย
    การที่ทีมพัฒนาที่ดีเปลี่ยน requirement ที่คลุมเครือให้กลายเป็นสินค้าจริงได้นี่แหละคือศิลปะ และตอนนี้ก็ยังไม่มีเทคโนโลยีไหนทำสิ่งนั้นแทนได้

  • ต้นทุนของการเขียนโค้ดแบบตรง ๆ ลดลง 90% แล้ว
    แต่การย่อยปัญหาให้กลายเป็นโค้ดที่เรียบง่ายยังต้องใช้ ประสบการณ์และเวลา มากเหมือนเดิม

    • งานพัฒนาส่วนใหญ่คือ การดูแลโค้ด legacy
      Claude Code เก่งมากในการทำความเข้าใจและแก้ไข codebase เก่า
      มันช่วยทั้งเรื่องเทสต์และ debugging จนรู้สึกว่าประสิทธิภาพเพิ่มขึ้น 10 เท่า
      ไม่ใช่แค่เขียนโค้ดได้เร็วขึ้น แต่ทำงานเหมือนเป็น สมองที่สองความเร็วสูง
    • ฉันเองก็เพราะ AI เลยเริ่มจัดการ งานอัตโนมัติเล็ก ๆ ที่เมื่อก่อนขี้เกียจทำ
      สามารถทำสคริปต์หรือ mini web service เพื่อแก้ปัญหาได้ภายในไม่ถึง 1 ชั่วโมง
    • เห็นด้วยว่าต้นทุนการทำแอป CRUD ลดลง 90%
      แต่จริง ๆ ก็คิดว่างานง่ายแบบนี้ ควรถูกทำให้เป็นอัตโนมัติได้ตั้งแต่ก่อนมี AI แล้ว
    • ต่อให้เป็นระบบซับซ้อน สุดท้ายมันก็คือ โครงสร้างที่ซ้อนกันเป็นชั้น ๆ ของโค้ดเรียบง่าย
      LLM ให้ความรู้สึกเหมือนอัปเกรดจากพลั่วหนึ่งอันเป็น รถขุด 10 คัน
      แต่ถ้าโปรเจกต์นั้นจะล้มเหลวอยู่แล้ว มันก็แค่ ล้มเหลวเร็วขึ้น เท่านั้น
    • ที่ว่าโค้ดเรียบง่ายหรือไม่นั้น สุดท้ายคือเรื่องของความคล้ายกับ แพตเทิร์นตัวอย่างบนอินเทอร์เน็ต มากแค่ไหน
      Claude Code เขียนโค้ดซับซ้อนได้ดี ตราบใดที่ยังอยู่ในแพตเทิร์นที่มันเคยเรียนรู้

  • ถ้า ต้นทุนการพัฒนาซอฟต์แวร์แบบสั่งทำลดลง 90% จริง,
    ตลาดก็ควรเต็มไปด้วย SaaS ราคาถูก แต่ความจริงไม่ได้เป็นแบบนั้น
    สุดท้ายดูเหมือนว่าการเขียนโค้ดไม่ใช่ปัญหาใหญ่ที่สุด

    • ใช่เลย ต้นทุนการดำเนินงานหลังพัฒนา สูงกว่ามาก
      ทั้งการบำรุงรักษา ความปลอดภัย การอัปเกรด โฮสติ้ง การซัพพอร์ตลูกค้า และการเพิ่มฟีเจอร์ใหม่
      สิ่งเหล่านี้ต่างหากคือคุณค่าจริงที่รวมอยู่ในค่าสมัคร SaaS
      ถ้า AI จะมาช่วยแก้ส่วนนี้ได้ด้วย ก็น่าจะต้องรออีก 3–5 ปี
    • เวลาที่นักพัฒนาใช้เขียนโค้ดจริง ๆ มีแค่ราวครึ่งหนึ่งของงานทั้งหมด
      ที่เหลือหมดไปกับการประชุม การประสานงาน การรอคอย ฯลฯ
      ต่อให้ต้นทุนการเขียนโค้ดลดลง 90% ต้นทุนรวมก็ยังเหลือเกินครึ่ง
      แถม AI ยัง สรุปภาษาธรรมชาติได้ไม่แม่นด้วยซ้ำ,
      เลยยิ่งน่าสงสัยว่ามันจะเข้าใจและเขียนความหมายของโค้ดได้ครบถ้วนจริงหรือไม่
      วิดีโอที่เกี่ยวข้อง: ลิงก์ YouTube
    • แค่โค้ดถูกลงก็ไม่ได้แปลว่าจะกลายเป็น ธุรกิจที่ดี
      ตอนนี้ก็มี SaaS ล้นตลาดอยู่แล้ว แต่ความจริงคือถึงฟีเจอร์จะดี การทำธุรกิจก็ยังยาก
    • SaaS เป็นงานที่ต้องใช้แรงมากกว่าแอปธรรมดา สองถึงสามเท่า
      งานวิศวกรรมจำนวนมากจริง ๆ แล้วทำไปเพื่อ vendor lock-in
    • สมมติฐานที่ว่าตลาดทำงานได้อย่างสมบูรณ์นั้นผิดตั้งแต่ต้น
      เพราะ การมองเห็นบนแพลตฟอร์ม ความน่าเชื่อถือ และการควบคุมโดยอัลกอริทึม ทำให้ SaaS หน้าใหม่โตได้ยาก
      บริษัทใหญ่ก็ลอกได้อย่างรวดเร็ว และผู้บริโภคก็ยิ่งไม่มีเงินมากขึ้น
      สุดท้ายตลาดไม่ได้ยุติธรรม และเพราะแบบนั้นหลายคนจึงเริ่มหันไปมอง พื้นที่ทางการเมือง

  • ถ้าเคยทำงานในบริษัทใหญ่ ก็คงไม่เห็นด้วยกับบทความแบบนี้
    ยกตัวอย่างอย่าง Shutterstock แค่คำขอธรรมดา ๆ ก็ต้อง ไปแตะ 5 ระบบ
    AI ช่วยเรื่องทำความเข้าใจและแก้โค้ดได้ก็จริง
    แต่การบอกว่าต้นทุนพัฒนารวมลดลง 90% นั้น ไม่จริงเลยแม้แต่นิดเดียว

    • แถมผู้เขียนยังเป็น “วิทยากรเวิร์กช็อปพัฒนา AI” อีกด้วย
      ดังนั้นบทความนี้จริง ๆ ก็แทบจะเป็น บทความประชาสัมพันธ์สำหรับลูกค้าองค์กร

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

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

  • รู้สึกว่า กฎ 90/90 ยังใช้ได้อยู่
    AI ช่วยเร่ง 90% แรกได้เร็ว แต่ 10% ที่เหลือนั่นแหละคือส่วนที่ยากจริง
    LLM มีประโยชน์ในช่วง งานขุดดินเปิดทาง แต่พอถึงขั้นเก็บรายละเอียดกลับกลายเป็นตัวถ่วง
    การทำเว็บไซต์ง่าย ๆ อาจดูเหมือนเวทมนตร์
    แต่ดูแล้วงานแบบนั้นในอนาคตคง เลี้ยงชีพได้ยากขึ้น

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

  • น่าแปลกที่หลายคนยังใช้ AI แค่เป็น แชตบอตเอาไว้คัดลอกแล้ววาง
    แต่ถ้าสั่งดี ๆ Claude Code สามารถ ทำซ้ำการทดลองที่ปกติต้องใช้เวลาหลายสัปดาห์ได้ในไม่กี่นาที
    ในงานจริง สิ่งสำคัญกว่าความสมบูรณ์แบบของโค้ดคือ การได้ผลลัพธ์อย่างรวดเร็ว
    แน่นอนว่า bug ด้านความปลอดภัยหรือความผิดพลาดใน business logic ยังเป็นความเสี่ยงอยู่
    ถ้ามีผู้เชี่ยวชาญด้านโดเมนทำงานร่วมด้วย ฉันคิดว่าปัญหาเหล่านี้จะค่อย ๆ ลดลง

    • แต่ถ้าไล่ตามแค่ผลลัพธ์เร็ว ๆ คุณภาพโค้ดก็จะตกฮวบ
      การรักษา สมดุลระหว่างการพัฒนาฟีเจอร์กับการดูแล codebase เป็นเรื่องสำคัญ
      และก็ยังไม่แน่ใจว่าเอเจนต์อย่าง Cursor จัดสมดุลตรงนี้ได้ดีแค่ไหน

  • หลังจากกระแส LLM บูมขึ้นมา ฉันเคยร่วมโปรเจกต์ที่พยายามแทนที่ Excel
    แต่ในความเป็นจริงมันคือ กรณีล้มเหลวที่คนไม่ใช่สายเทคนิคพยายามใช้ AI สร้างแอป
    นักวิเคราะห์ข้อมูลทำแอป Python แบบ ‘vibe coding’ แต่ไม่มีทั้ง state management และโครงสร้างก็เละเทะ
    สุดท้ายก็ได้ผลลัพธ์ระดับ หายนะ ที่ทำให้ข้อมูลลูกค้าถูกจัดการผิด ๆ
    องค์กรแบบนี้ไม่มีบุคลากรเทคนิคอยู่แล้ว ดังนั้น AI เลยยิ่ง เร่งความเสี่ยงให้เกิดเร็วขึ้น

    • แค่คำว่า “โปรเจกต์ modernize Excel ในยุค post-LLM” ก็ฟังดูเป็น ไอเดียชวนขนลุก แล้ว