ถอดบทเรียนระยะยาวเมื่อ AI เขียนโค้ด: สยบ 'โคลนก้อนใหญ่' ด้วยกลยุทธ์ Domain-Driven Design (DDD)

ความเร็วที่แลกมาด้วยความซับซ้อน: เมื่อ AI เป็นคนเขียนโค้ดแต่เราเป็นคนดูแล

ในยุคที่ Claude และ AI Coding Assistants สามารถสร้างเว็บไซต์ทั้งระบบได้ในเวลาไม่กี่ชั่วโมง ความตื่นเต้นในช่วงเริ่มต้นมักจะบดบังความจริงที่ต้องเผชิญในระยะยาว หลายโปรเจกต์ที่เริ่มต้นด้วยความเร็วสูงกลับต้องพบกับทางตันเมื่อระบบเริ่มใหญ่ขึ้น บั๊กที่แก้ไม่จบ และการเพิ่มฟีเจอร์ใหม่ที่ทำได้ยากขึ้นเรื่อยๆ ปรากฏการณ์นี้คือสิ่งที่หนังสือของ Vlad Khononov เรียกว่า Accidental Complexity หรือความซับซ้อนโดยไม่ตั้งใจ ซึ่งเกิดจากการที่ AI มักเขียนโค้ดในรูปแบบ Transaction Script หรือ Active Record ที่เน้นให้โปรแกรมทำงานได้ตามฟังก์ชัน (Functional Requirement) แต่ขาดการวางโครงสร้างที่รองรับการเปลี่ยนแปลงในอนาคต

ทำไมโค้ดจาก AI ถึงกลายเป็น 'โคลนก้อนใหญ่' (Big Ball of Mud)?

ปัญหาใหญ่ที่สุดเมื่อใช้ AI เขียนระบบโดยไม่มีการควบคุมสถาปัตยกรรมคือการขาด Consistency Boundary หรือขอบเขตความถูกต้องของข้อมูล AI มักจะสร้างฟังก์ชันการทำงานแยกส่วนกันโดยไม่มีภาพรวมของ Aggregate ทำให้เมื่อระบบขยายตัว โค้ดส่วนหนึ่งอาจไปขัดแย้งกับอีกส่วนหนึ่งจนกลายเป็น Distributed Big Ball of Mud หรือกองโคลนของโค้ดที่ยุ่งเหยิงกระจายตัว การพึ่งพา AI เพียงอย่างเดียวโดยไม่กำหนด Bounded Context ที่ชัดเจน จะทำให้ Model ของธุรกิจปนเปกันไปหมด ส่งผลให้ประสิทธิภาพ (Performance) และความปลอดภัย (Security) ถูกละเลยเพราะ AI มุ่งเน้นเพียงการตอบสนองต่อคำสั่ง Prompt ในขณะนั้นเท่านั้น

ใช้กลยุทธ์ DDD แบ่งแยกส่วนเพื่อความยั่งยืน: Core vs Generic Subdomain

หนึ่งในคำถามยอดฮิตคือเราควรเขียนโค้ดเองด้วย AI หรือใช้เครื่องมือสำเร็จรูปอย่าง WordPress + Elementor? คำตอบนี้สามารถหาได้จากการวิเคราะห์ Subdomains ตามหลักการของ DDD หากส่วนนั้นคือ Generic Subdomain เช่น หน้าประชาสัมพันธ์หรือบล็อกทั่วไป การใช้ WordPress คือทางเลือกที่ฉลาดกว่าเพราะมีโซลูชันที่ปลอดภัยและเสถียรอยู่แล้ว แต่ถ้าเป็น Core Subdomain ซึ่งเป็นหัวใจสำคัญที่สร้างความได้เปรียบทางธุรกิจ การเขียนโค้ดเอง (Custom-built) โดยมี AI เป็นผู้ช่วยภายใต้การกำกับดูแลของนักพัฒนาที่เข้าใจ Domain Model จะเป็นวิธีที่ยืดหยุ่นและคุ้มค่าที่สุดในระยะยาว

การสร้างระบบที่ยั่งยืนในยุค AI ไม่ใช่การเลิกใช้ AI แต่คือการปรับบทบาทจากผู้สั่งคำสั่ง (Prompt-giver) มาเป็น Software Architect ที่ใช้ AI เป็นเครื่องมือในการเจียระไนชิ้นงาน การใช้แนวคิด Evolutionary Design และการกำหนด Ubiquitous Language หรือภาษาร่วมที่ชัดเจนระหว่างธุรกิจและเทคนิค จะช่วยให้คุณสามารถดูแลรักษาระบบได้โดยไม่ต้อง 'รื้อใหม่' ทุกครั้งที่ต้องการเพิ่มฟีเจอร์ สรุปแล้ว AI คือช่างฝีมือที่ทรงพลัง แต่หน้าที่ในการออกแบบโครงสร้างรากฐานที่มั่นคงยังคงเป็นหน้าที่ของมนุษย์เพื่อให้ระบบเติบโตได้อย่างยั่งยืน