AI พาเราพุ่งชนความซับซ้อนเร็วขึ้น

AI พาเราพุ่งชนความซับซ้อนเร็วขึ้น

AI ไม่ได้ทำให้ Software ง่ายขึ้น

มันแค่ทำให้เราเข้าสู่ช่วงที่ยากของ S-Curve เร็วขึ้น

ในช่วงหลายปีที่ผ่านมา ตั้งแต่การเปิดตัวของ ChatGPT และเครื่องมืออย่าง GitHub Copilot
หลายคนเริ่มพูดเหมือนกันว่า

“ตอนนี้เขียน software ง่ายขึ้นมาก”

มันจริง…แต่ก็ไม่จริงทั้งหมด

AI ทำให้การ เขียนโค้ดเร็วขึ้นอย่างมหาศาล
แต่สิ่งที่หลายทีมเริ่มรู้สึกคือ

ระบบกลับ ยากขึ้นกว่าเดิม

เพื่อเข้าใจสิ่งนี้ เราต้องกลับไปดูกราฟหนึ่งที่ใช้กันมานานคือ คณิตศาสตร์ของ S-Curve (Logistic Curve)

https://innospective.net/why-s-curves-are-probably-the-most-important-concept-in-entrepreneurship/
Why S-Curves Are Probably the Most Important Concept in Entrepreneurship

S-Curve อธิบายว่าเทคโนโลยีใหม่ ๆ เติบโตอย่างไร

ช่วงแรก
การเติบโตช้ามาก

ช่วงกลาง
การเติบโตพุ่งขึ้นอย่างรวดเร็ว

ช่วงท้าย
เริ่มอิ่มตัวและเติบโตช้าลง

แนวคิดนี้มาจากทฤษฎี Diffusion of Innovations ของ Everett Rogers

และมันไม่ได้ใช้แค่กับการยอมรับเทคโนโลยีของผู้ใช้เท่านั้น

มันใช้กับ ความซับซ้อนของระบบซอฟต์แวร์ ได้อีกด้วย


จุดที่ยากที่สุดของ S-Curve

สิ่งที่น่าสนใจคือ

จุดที่ ยากที่สุด ไม่ใช่ตอนเริ่มต้น

แต่มันคือ ช่วงกลางของ S-Curve

ช่วงที่ระบบเริ่มเติบโตเร็วที่สุด

ตอนเริ่มต้น

  • ระบบยังเล็ก
  • ทีมยังเล็ก
  • feature ยังไม่เยอะ
  • architecture ยัง simple

ตัวอย่างเช่น

monolith
1 database
few APIs

ทุกอย่างดูง่าย

ยกเว้นบางที่ ที่เริ่มจาก “Service-based” architecture แต่คิดว่ากำลังทำ Microservices

แต่เมื่อ product เริ่มโต

สิ่งที่เกิดขึ้นคือ

  • user เพิ่มขึ้น
  • feature เพิ่มขึ้น
  • สมาชิกของ team เพิ่มขึ้น
  • integration เพิ่มขึ้น

ระบบเริ่มต้องมี

  • distributed services
  • caching
  • message queues
  • observability
  • data pipelines

และไม่ทันไร

ระบบที่เคยง่าย กลายเป็น สัตว์ประหลาดที่ซับซ้อน

นี่คือช่วงที่หลายทีมเรียกกันเล่น ๆ ว่า

The “Oh shit” phase

AI ทำให้เราวิ่งเข้าสู่ช่วงนี้เร็วขึ้น

ก่อนยุค AI

ความเร็วในการสร้าง features ถูกจำกัดด้วย human bandwidth

แต่หลังจากมี AI

developer สามารถ

  • generate code
  • scaffold project
  • เขียน integration
  • ทดลอง idea ใหม่

ได้เร็วกว่าเดิมมาก

ผลลัพธ์คือ

feature explosion

และเมื่อ feature เพิ่มขึ้นเร็ว

สิ่งที่ตามมาคือ

integration explosion

และสุดท้าย

system complexity explosion

AI ลด cost ของการเขียน code

แต่ไม่ได้ลด cost ของการเข้าใจระบบ


ปัญหาที่ AI ไม่ได้แก้

AI ช่วยเขียน

  • function
  • class
  • API

ได้ดีขึ้น

แต่สิ่งที่ยังยากเหมือนเดิมคือ

  • architecture decision
  • domain modeling
  • distributed system design
  • data consistency
  • long-term maintainability

ถ้าปัญหาที่เราเจอต้องใช้สิ่งเหล่านี้ในการแก้ปัญหาจริง ๆ นั่นคือสิ่งที่ Fred Brooks เรียกว่า

Essential Complexity

ในบทความคลาสสิก
No Silver Bullet

ซึ่งหมายถึง

ความซับซ้อนที่ไม่สามารถกำจัดได้

AI อาจช่วยลด accidental complexity (หรือจริงๆอาจจะเพิ่มด้วยซ้ำในบางกรณี)

แต่ essential complexity ยังคงอยู่


สิ่งที่กำลังเกิดขึ้นกับ developers

AI ไม่ได้แทน developer

แต่มันกำลัง เปลี่ยน distribution ของ skill ที่มีค่า

developer ที่โฟกัสแค่ writing code อาจเริ่มถูกแทนที่

แต่ developer ที่เก่งเรื่อง

system thinking
architecture
problem framing

กลับมี leverage มากขึ้น

เพราะเมื่อ code ถูกสร้างได้ง่าย

สิ่งที่สำคัญขึ้นคือการตัดสินใจว่าเราควรสร้างอะไร


สุดท้ายแล้ว AI ไม่ได้เปลี่ยนความจริงพื้นฐานของ software engineering

เครื่องมือใหม่ทุกยุค
ทำให้การสร้างสิ่งต่าง ๆ ง่ายขึ้น

แต่เมื่อการสร้างง่ายขึ้น
มนุษย์จะสร้าง ระบบที่ใหญ่ขึ้น

และเมื่อระบบใหญ่ขึ้น
ความซับซ้อนก็จะกลับมาในระดับที่สูงกว่าเดิม

AI ก็ไม่ต่างกัน

มันไม่ได้ทำให้ software engineering ง่ายขึ้น

มันแค่ทำให้เรา

ไปถึงความซับซ้อนระดับถัดไปเร็วขึ้น

และในโลกที่ AI สามารถเขียนโค้ดได้

ทักษะที่มีค่าที่สุดของ developer
อาจไม่ใช่การเขียนโค้ดอีกต่อไป

แต่คือ

การเข้าใจว่า “ไม่ควรสร้างอะไร”

AI makes code cheap.

But understanding systems
is becoming the most expensive skill
in software engineering.


หากบทความนี้มีประโยชน์

คุณสามารถติดตาม Late Night with Uncle Quin ได้ทาง

ที่ที่เราคุยกันเรื่อง software, engineering mindset และอนาคตของ developer

แบบไม่ต้องใส่สูท

แต่ใส่ความจริงของวงการเข้าไปเต็ม ๆ

Read more

Tuple: ปรัชญาของการปูเสื่อ และศิลปะแห่งการไม่ตั้งชื่อ

Tuple: ปรัชญาของการปูเสื่อ และศิลปะแห่งการไม่ตั้งชื่อ

ในโลกของการเขียนโปรแกรม เรามักถูกสอนให้เป็น “นักจัดระเบียบ” เราสร้างคลาส สร้าง Struct ตั้งชื่อตัวแปรให้สื่อความหมาย (Clean Code) แต่บางครั้ง ความเคร่งครัดที่มากเกินไปอาจกลายเป็นพันธนาการที่ทำให้ Code ของเราอุ้ยอ้ายโดยไม่จำเป็น 1. Naming Fatigue: ภาระของการมีตัวตน ลองนึกภาพคุณได้

By Santi
The Art of Early Return: วินัยแห่งการ “คัดออก” เพื่อสมองที่โล่งกว่าเดิม 10 เท่า

The Art of Early Return: วินัยแห่งการ “คัดออก” เพื่อสมองที่โล่งกว่าเดิม 10 เท่า

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

By Santi
The Logic Trap: เมื่อ “ความถูกต้อง” กลายเป็นอาวุธที่ทำลายทีมซอฟต์แวร์

The Logic Trap: เมื่อ “ความถูกต้อง” กลายเป็นอาวุธที่ทำลายทีมซอฟต์แวร์

ในโลกของการพัฒนาซอฟต์แวร์ เราถูกสอนให้เทิดทูน Logic เป็นพระเจ้า เราใช้เหตุผลในการคัดเลือก Stack, ใช้ความถูกต้องในการทำ Code Review และใช้ตัวเลขในการวาง Roadmap แต่เคยสงสัยไหมครับ? ทั้งที่เราพูดเรื่องที่ “ถูกต้อง” และเป็น “ความจริง” ทุกประการ ทำไมผลลัพธ์ในห้องประชุ

By Santi
Change Management ต้องทำไหมนะ แล้วทำตอนไหน

Change Management ต้องทำไหมนะ แล้วทำตอนไหน

เนื่องจากช่วงนี้ได้ทำงานกับลูกค้าที่มีการเปลี่ยนแปลงทาง scope ของงานเยอะมาก อารมณ์แบบตอน baseline เป็นแบบนึง พอจะเลือกงานมาทำจริงๆ เรียกว่าเปลี่ยนไปตาม strategy ขององค์กรเลยก็ว่าได้ ในฐานะที่เราเป็นกลุ่มนักพัฒนา ที่ยังจำเป็นต้องควบคุมงบประมาณ กำหนด scope และต้องตอบให้ได้ว่า

By Thanthiya Phatharamalai