เลือกเทคโนโลยีที่น่าเบื่อ, Revisited (2025)

• หลักการ "Choose Boring Technology" ที่ให้โฟกัสกับเทคโนโลยีสแตกที่ตรวจสอบได้ มีความสำคัญยิ่งขึ้นในยุคของเครื่องมือเขียนโค้ดด้วย AI
• องค์กรควรใช้ "innovation tokens" ที่มีอยู่อย่างจำกัดอย่างมีกลยุทธ์กับเทคโนโลยีที่พิสูจน์ความน่าเชื่อถือแล้ว
• เครื่องมือเขียนโค้ดด้วย AI สมัยใหม่สามารถสร้าง โค้ดที่ดูน่าเชื่อถือ สำหรับแทบทุกเทคโนโลยีสแตกได้ แต่ถ้ามีเทคโนโลยีมากกว่าหนึ่งอย่างที่ผู้ใช้ไม่รู้จักมารวมกัน จะไม่สามารถตรวจสอบความผิดพลาดได้
• ในเทคโนโลยีสแตกที่คุ้นเคยอยู่แล้ว เครื่องมือเขียนโค้ดด้วย AI จะทำงานเป็น force multiplier (เครื่องมือขยายศักยภาพ) แต่ในเทคโนโลยีที่ไม่รู้จัก มันจะกลายเป็นเพียงเครื่องมือให้พึ่งพา
• ยิ่งคุณภาพของโค้ดที่ AI สร้างสูงขึ้น ก็ยิ่งตรวจพบปัญหาได้ยากขึ้น ทำให้คุณค่าของ ความเข้าใจอย่างลึกซึ้ง ในเทคโนโลยียิ่งเพิ่มขึ้น

---

การยืนยันหลักการ Choose Boring Technology อีกครั้ง

• มุมมองที่เห็นด้วยกับบทความ "Choose Boring Technology" ของ Dan McKinley เมื่อ 10 ปีก่อน ยังคงไม่เปลี่ยนไปแม้เวลาจะผ่านไปอีกสิบปี
  • เมื่อเริ่มโปรเจ็กต์ใหม่ ต้องถามก่อนว่า "นี่เป็นข้ออ้างเพื่อเรียนรู้สิ่งใหม่ หรือกำลังพยายามแก้ปัญหาอยู่กันแน่"
  • ถ้าจะเรียนรู้สิ่งใหม่ ให้จำกัดปัจจัยที่ยังไม่รู้ไว้ เพียงหนึ่งอย่าง แต่ถ้ากำลังแก้ปัญหา ให้ยึดเทคโนโลยีที่รู้จักอยู่แล้ว
• การมาของ LLM และเครื่องมือเขียนโค้ดด้วย agentic AI ทำให้หลักการนี้ยิ่ง critical มากขึ้น

ข้อโต้แย้งหลักของ McKinley

• องค์กรมี "innovation tokens" อยู่จำกัด และควรใช้มันอย่างมีกลยุทธ์กับเทคโนโลยีที่มั่นคงและเข้าใจดีแล้ว มากกว่ากับเทคโนโลยีใหม่ที่น่าตื่นเต้นแต่ยังไม่ผ่านการพิสูจน์
• เทคโนโลยีที่น่าเบื่อมี โหมดความล้มเหลว (failure modes) ที่รู้กันอยู่แล้ว มีความสามารถที่เข้าใจดี และมีความน่าเชื่อถือในการปฏิบัติการที่พิสูจน์แล้ว
  • เวลาเกิดเหตุขัดข้องตอนตี 3 การดีบักเทคโนโลยีที่มีคำตอบอยู่ใน Stack Overflow ย่อมดีกว่าการบุกเบิกดินแดนที่ไม่รู้จัก
• หลักการนี้เป็นจริงในปี 2015 และยังคงเป็นจริงในวันนี้

เครื่องมือเขียนโค้ดด้วย AI ในฐานะตัวแปรใหม่

• เครื่องมือเขียนโค้ดด้วย AI สมัยใหม่สามารถสร้างโค้ดที่ดูเหมือนผู้เชี่ยวชาญเขียนได้สำหรับแทบทุกเทคโนโลยีสแตกที่นึกออก
  • ถ้าขอให้ Claude หรือ Copilot สร้าง Kubernetes-based microservices, GraphQL federation หรือการใช้งาน JavaScript framework รุ่นใหม่ล่าสุด ก็จะได้โค้ดที่ทำตามกฎและรันได้กลับมา
• หากใช้เทคโนโลยีมากกว่าสองอย่างที่ตัวเองไม่รู้จัก ก็แทบไม่มีทางตรวจสอบได้เลยว่า AI กำลังให้ผลลัพธ์ที่ผิดอยู่หรือไม่
  • แม้ LLM จะมีความสามารถน่าประทับใจ แต่ก็ยัง hallucinate (หลอนข้อมูล) ในรายละเอียดเชิงเทคนิคได้
• มีการพบเห็นกรณีที่วิศวกรยอมรับโค้ดมีปัญหาที่ AI สร้างมาโดยตรง
  • เช่น การใช้ API ที่ deprecated แล้ว, การทำ security antipatterns, หรือปัญหาประสิทธิภาพแบบละเอียดอ่อนที่เพิ่งเผยออกมาเมื่อเจอโหลดระดับโปรดักชัน
  • โค้ดอาจดูถูกต้อง ใช้การตั้งชื่อตามกฎ และมี error handling ที่เหมาะสม แต่ก็ยังผิดในแบบที่มีแต่คนที่คุ้นเคยกับเทคโนโลยีนั้นเท่านั้นที่จะจับได้

เทคโนโลยีที่ไม่รู้จัก + โค้ดจาก AI = การคูณของความไม่แน่นอน

• เมื่อรวมเทคโนโลยีที่ไม่คุ้นเคยเข้ากับโค้ดที่ AI สร้างขึ้น ผลลัพธ์ไม่ใช่การบวกตัวแปรที่ไม่รู้ แต่เป็นการ คูณ ความไม่แน่นอน
  • ไม่รู้ว่าการเลือก framework เหมาะสมหรือไม่
  • ไม่รู้ว่าการ implement ของ AI ทำตาม best practice หรือไม่
  • ไม่รู้ว่าส่วนไหนของโค้ดที่สร้างขึ้นเป็น boilerplate และส่วนไหนคือ business logic หลัก
  • ไม่รู้ว่าควรเฝ้าระวังโหมดความล้มเหลวแบบใด
• นี่ไม่ใช่แค่ cargo-culting ธรรมดา แต่เป็นปัญหาระดับ "cargo-culting times 2,356"

จุดที่เทคโนโลยีที่น่าเบื่อกับ AI สร้างซินเนอร์จีกัน

• เมื่อเข้าใจสแตกพื้นฐานอยู่แล้ว เครื่องมือเขียนโค้ดด้วย AI จะทรงพลังมาก
  • เพราะรู้จัก Rails ดีพอ จึงจับได้เมื่อ Claude เสนอสิ่งที่น่าสงสัย (อาศัยความช่วยเหลือจาก context7)
  • เพราะเข้าใจลักษณะเฉพาะของ JavaScript จึง fact-check ข้อเสนอของ Copilot ได้
• AI จะเป็น force multiplier ในเทคโนโลยีที่เราเข้าใจอยู่แล้ว แต่จะกลายเป็นไม้ค้ำให้พึ่งพาในเทคโนโลยีที่เราไม่รู้จัก

แนวทางปฏิบัติในยุค AI

• เมื่อประเมินเทคโนโลยีใหม่ ให้ถามตัวเองก่อนว่า "ถ้า AI สร้างโค้ดสำหรับเทคโนโลยีนี้ขึ้นมา ฉันจะรีวิวมันได้อย่างเหมาะสมหรือไม่?"
  • ถ้าคำตอบคือ "ไม่ได้" ก็ไม่ควรใช้เทคโนโลยีนั้นในส่วนที่ mission-critical
• ถ้าตัดสินใจจะเรียนรู้สิ่งใหม่ (โดยมี innovation token ได้แค่หนึ่ง) ก็ควรใช้เวลาจริงเพื่อทำความเข้าใจมันให้ลึกพอที่จะ fact-check ข้อเสนอของ AI ได้
  • อย่าแค่คัดลอก-วางแล้วหวังว่ามันจะทำงาน
• จงต้านทานความยั่วยวนที่จะรับเทคโนโลยีใหม่หลายอย่างพร้อมกันโดยอ้างว่า AI ช่วยได้
  • AI ทำให้รู้สึกเหมือนสามารถจัดการภาษาใหม่, framework ใหม่ และ infrastructure ใหม่ได้พร้อมกัน แต่จริง ๆ แล้วไม่สามารถตรวจสอบสิ่งใดได้อย่างเหมาะสมเลย

ความเสี่ยงที่สูงขึ้นในยุค AI และบทสรุป

• ข้อเสนอเดิมของ "choose boring technology" คือการลดความซับซ้อนในการปฏิบัติการและภาระทางความคิด ซึ่งความกังวลนี้ยังคงใช้ได้อยู่
• ในยุค AI มีความเสี่ยงเพิ่มเติมคือ false confidence (ความมั่นใจลวง) ที่เกิดจาก AI ซึ่งสามารถสร้างโค้ดที่ดูเป็นมืออาชีพได้กับทุกสแตก
• คุณภาพของโค้ดที่ AI สร้างกลับทำให้การค้นหาปัญหายากขึ้น
  • ในอดีตโค้ดที่ไม่ดีมักดูแย่ให้เห็นชัด แต่ตอนนี้ต้องเข้าใจโดเมนอย่างเพียงพอจึงจะสังเกตเห็นปัญหาละเอียดอ่อนได้
• เวลาจะแก้ปัญหา ให้ใช้สิ่งที่รู้อยู่แล้ว และเวลาจะเรียนรู้สิ่งใหม่ ก็ให้โฟกัสกับการเรียนรู้อย่างแท้จริง อย่าสับสนระหว่างโค้ดที่ AI สร้างกับความเข้าใจ
• เทคโนโลยีที่น่าเบื่อที่สุดในสแตก อาจเป็นเทคโนโลยีที่คุณเข้าใจดีพอจะรู้ได้ว่าเมื่อไร AI กำลังผิด
  • ในโลกที่ AI สามารถสร้างโค้ดหลายพันบรรทัดด้วยความมั่นใจให้กับเทคโนโลยีที่คุณไม่เคยใช้มาก่อน คุณค่าของความเข้าใจนั้นยิ่งสูงกว่าที่เคย