เมื่อ AI ทำให้เรื่องง่ายให้กลายเป็นเรื่องยาก นำไปสู่ วิกฤต Over Engineering ในยุค Big Tech
1. ปฐมบท: ยุคที่ความซับซ้อนถูกเข้าใจผิดว่าเป็นความฉลาด
ในอดีต วิศวกรมีข้อจำกัดเรื่องทรัพยากร ต้นทุน และเวลา การจะทำอะไรสักอย่างให้สำเร็จต้องอาศัย "ความเรียบง่าย" (Simplicity) และ "ความพอดี" (Sufficiency) แต่ปัจจุบัน Big Tech กลับมีวัฒนธรรมว่า "ถ้าง่ายเกินไป แสดงว่าไม่ทันสมัย" และ AI ก็ยิ่งเติมเชื้อไฟนี้เข้าไป
2. AI: ผู้เร่งภาวะ Over Engineering ตัวฉกาจ
ก. แก้ปัญหาหนักเกินเหตุ (When all you have is a hammer...)
ปัจจุบัน ทันทีที่บริษัทเทคโนโลยีเจอปัญหา ทางออกแรกคือ "เราต้องใช้ Deep Learning" หรือ "ลอง Transform ดู"
แทนที่ใช้ Heuristic หรือ Logistic Regression ที่ให้ผลแค่ 95% พอใช้ได้ กลับเลือก LLM ขนาด 7B พารามิเตอร์ ที่ใช้ GPU ราคาแพง ผลลัพธ์อาจได้ 98% แต่ต้นทุนและเวลาทะลุเพดาน
ข. AI-generated complexity
นักพัฒนาเริ่มใช้ AI (เช่น Copilot, Cursor) เพื่อสร้างโค้ดที่ "ใช้งานได้" โดยไม่ต้องคิดโครงสร้างให้ดี โค้ดที่ได้มัก:
- ซับซ้อนเกินจริง
- มี Layers ของ Abstraction ที่ไม่จำเป็น
- รวม Design Pattern เข้าไปมากมายเพื่อความ "สะอาด" (แต่จริงๆคือสะอาดจนเว่อร์)
สุดท้ายบำรุงรักษายากกว่าเดิม
ค. Microservices กับ AIOps
ในยุคก่อน ถ้าอยากทำระบบแนะนำสินค้า แค่มีฟังก์ชันดึงข้อมูล User-based collaborative filtering ก็พอ
แต่เดี๋ยวนี้ Big Tech ต้องทำเป็น 20 microservices แต่ละตัวมี API, Kafka streaming, Kubernetes auto-scaling และ AIOps สำหรับตรวจจับความผิดปกติ ทั้งที่โหลดต่อวันยังไม่ถึงพัน request
3. Big Tech: ต้นตอและเหยื่อของ Over Engineering
ตัวอย่างจริง
-
Google เคยออกซอฟต์แวร์หลายตัว (Google Wave, Google+ หรือแม้แต่ Android APIs บางรุ่น) ที่ซับซ้อนเพราะออกแบบเผื่ออนาคตไกลเกินไป สุดท้ายไม่มีใครใช้ หรือถ้าใช้ก็บ่นว่าเรียนรู้ยาก
-
Amazon กับระบบ Internal Tool ต่างๆ มีเรื่องเล่าว่าทีมหนึ่งสร้างระบบขอวันลาโดยใช้ AWS Step Functions + DynamoDB + SNS + Lambda รวม 6 services ทั้งที่ความจริงใช้ spreadsheet + email ก็พอ
แต่ Big Tech ก็มีราคาที่ต้องจ่าย
- ต้นทุนมหาศาล - ค่า GPU, ค่า cluster, ค่าพลังงานเพราะรันโมเดลเท่ๆ แต่ไม่ได้ใช้ประโยชน์เต็มเม็ดเต็มหน่วย
- Developer burnout - เพราะต้องเรียนรู้ toolchain ยาวเหยียด แก้บั๊กในระบบที่ซับซ้อนยิ่งกว่าปัญหาตัวเองเสียอีก
- เวลาในการออกสู่ตลาด (Time-to-market) ช้าลง - เพราะทุกอย่างต้องเป็น perfect abstract architecture
4. Over Engineering ฆ่านวัตกรรมอย่างไร?
ถ้าทุกปัญหาถูกมองผ่านเลนส์ "AI และ Cloud Native" เท่านั้น จะเกิดการปิดโอกาสของทางออกที่ เรียบง่ายแต่ทรงพลัง เช่น
- การใช้ Bash script + cron job แทน Airflow บน K8s
- การเก็บ log ในไฟล์ข้อความแทน Elasticsearch cluster ตอน product ยังมี user แค่ 100 คน
- การใช้ SQL ธรรมดาแทน GraphQL + Federation + Apollo Studio
Over Engineering ทำให้ทีมหมด passion เพราะรู้สึกว่า "งานเล็กๆ ก็ดูยิ่งใหญ่อึดอัด"
5. ทางออก: กลับมาสู่ "YAGNI" และ "Gall's Law"
YAGNI (You Aren't Gonna Need It)
อย่าเพิ่มฟีเจอร์ สถาปัตยกรรม หรือ AI model ที่ "อาจจะต้องใช้ในอนาคต" จนกว่าจะถึงเวลา
Gall's Law
"ระบบที่ซับซ้อนที่ทำงานได้ มักสร้างจากระบบที่เรียบง่ายที่ทำงานได้" — ไม่ใช่กลับกัน
AI minimalism
ใช้ AI เฉพาะจุดที่มันเพิ่มมูลค่าได้ชัดเจน และ Cost-benefit สมเหตุสมผล เช่น ใช้ BERT ขนาดเล็กแทน GPT-4 เพื่อ classification ง่ายๆ
Big Tech ต้องเปลี่ยน culture
ให้รางวัลการออกแบบที่เรียบง่าย บำรุงรักษาง่าย ใช้ทรัพยากรน้อย ไม่ใช่แค่รางวัลนวัตกรรมซับซ้อนหรือใช้ AI ทุกอย่าง
6. สรุป
Over Engineering ในยุค AI และ Big Tech ไม่ใช่แค่เรื่องเทคนิค แต่เป็นวิกฤติทางความคิด ที่เกิดจาก:
- Ego ทางวิศวกรรม
- การตลาดเกินจริงของ AI
- ความกลัวที่จะถูกมองว่าล้าสมัย
ทางรอดคือ: "แก้ปัญหาวันนี้ด้วยวิธีที่พอดี พร้อมขยายในวันข้างหน้าเมื่อจำเป็น" ไม่ใช่สร้างปราสาทบนเมฆตั้งแต่ก้อนแรก
เพราะสุดท้ายแล้ว ลูกค้าสนใจแค่ ปัญหาของเขา "ถูกแก้" ได้รวดเร็ว ถูก และใช้งานง่าย แค่นั้น
"Simplicity is the ultimate sophistication." — Leonardo da Vinci
เรียบเรียง: บุญประเสริฐ ตรีรยาภิวัฒน์ — Engineer-turned Software Developer
ภาพประกอบ: 1
