เจาะประเด็น
AI / Architecture
เมื่อ AI กลายเป็น "กรรมการตัดสิน" สถาปัตยกรรมซอฟต์แวร์: กติกาเดิมใช้ไม่ได้แล้ว
ระบบตรวจสอบสถาปัตยกรรมแบบเดิมๆ ดูแค่ว่า "ผิดกฎไหม" แต่ตอนนี้ AI เริ่มตัดสินเรื่องที่ต้องใช้ดุลยพินิจแบบมนุษย์แล้ว
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ถ้าคุณเชื่อว่า "กฎตายตัว" กันสถาปัตยกรรมพังได้จริง ลองคิดใหม่ดู เพราะปัญหาที่ฆ่าระบบส่วนใหญ่ไม่ใช่การฝ่าฝืนกฎ แต่เป็น "เจตนา" ที่ค่อยๆ เบี้ยวไปต่างหาก
เรื่องนี้คืออะไร? พูดง่ายๆ คือทีมวิศวกรรมทั่วโลกใช้ "fitness functions" มาหลายปีแล้ว — มันคือชุดกฎอัตโนมัติที่คอยตรวจว่าสถาปัตยกรรมซอฟต์แวร์ยังอยู่ในกรอบที่ตกลงกันไว้หรือเปล่า เช่น ตรวจว่า service หนึ่งไม่เรียกหา database โดยตรง, ตรวจว่า response time ไม่เกิน 200ms, หรือตรวจว่าไม่มีใครแก้ไฟล์บางไฟล์ตรงๆ แบบมั่วๆ มันคือ "รั้ว" ที่มองเห็นได้ด้วยเครื่องมือ ไม่ต้องพึ่งคนมานั่งไล่ review โค้ดทุกบรรทัด
แต่ปัญหาคือ รั้วพวกนี้มันโง่ มันดูได้แค่ "ตัวเลข" กับ "กฎตายตัว" เท่านั้น มันไม่รู้ว่า "ความตั้งใจ" ของคนเขียนโค้ดคืออะไร ยกตัวอย่าง — คุณมีกฎว่า "ห้ามเรียก API ของบุคคลที่สามเกิน 10 ครั้งต่อนาที" แล้วจู่ๆ ฟีเจอร์ใหม่ต้องเรียก 11 ครั้งเพื่อให้ได้ข้อมูลที่ครบถ้วนตาม business requirement ใหม่ กติกาเดิมมันจะฟ้องว่า "ผิดกฎ!" ทันที ทั้งที่จริงๆ แล้วสถาปัตยกรรมมันยังดีอยู่ แค่กฎมันล้าสมัย
บทความจาก InfoQ ชิ้นนี้ชี้จุดอ่อนที่ใหญ่กว่านั้น — เรื่องที่วัดยากที่สุดในสถาปัตยกรรมไม่ใช่ "ความเร็ว" หรือ "จำนวนครั้ง" แต่เป็นเรื่องแบบ "ขอบเขตระหว่าง module ยังถูกต้องตามเจตนาเดิมไหม?" หรือ "สัญญาที่ให้ไว้ระหว่าง service ยังตรงกับที่ใช้งานจริงไหม?" หรือ "เอกสาร ADR ที่เขียนไว้ตั้งแต่ปีที่แล้ว ยังใช้ได้อยู่หรือเปล่า หรือมันเพี้ยนไปแล้ว?" พวกนี้เป็น "judgment-heavy concerns" — เรื่องที่ต้องใช้ดุลยพินิจ ไม่ใช่แค่เช็ค if-else
ทีมผู้เขียนซึ่งมาจากสาย architecture governance โดยตรง เสนอแนวคิดที่เรียกว่า "Agentic Fitness Functions" — เปลี่ยนจากกฎ deterministic ที่ตายตัว ไปเป็น "ตัวแทน AI" ที่ทำหน้าที่เหมือนกรรมการผู้เชี่ยวชาญ คอยประเมินสถาปัตยกรรมโดยเทียบกับ "rubric" (เกณฑ์การให้คะแนน) ที่มีเวอร์ชันและปรับปรุงได้เรื่อยๆ
แทนที่คุณจะเขียนกฎว่า "ต้องไม่มี circular dependency" (ซึ่งคนเขียนโค้ดหาทางเลี่ยงได้เสมอ) คุณให้ AI agent ดูว่า "โครงสร้างการเรียกระหว่าง module มันเริ่มบิดเบี้ยวจากที่ตกลงกันไว้ใน ADR ไหม?" และให้คะแนนออกมาเป็นระดับ เช่น "ยังดีอยู่" / "เริ่มเบี่ยง" / "ต้องแก้" — มันคือการเปลี่ยนจากการตรวจ "ผิด/ถูก" ไปเป็นการตรวจ "สุขภาพ" ของสถาปัตยกรรม
ฟังดูเข้าท่าใช่ไหม? แต่ขอพูดตรงๆ ตามสไตล์ — แนวคิดนี้ทั้งเจ๋งและน่ากลัวในเวลาเดียวกัน เจ๋งตรงที่มันแก้ปัญหาที่คนทำ architecture จริงๆ เจอทุกวัน: กฎตายตัวมัน "แข็ง" เกินไป ไม่ยืดหยุ่นตามบริบท และสุดท้ายทีมก็เริ่มมองข้ามมันเพราะ "เดี๋ยวค่อยแก้ทีหลัง" แต่ในทางกลับกัน มันก็เปิดประตูให้ "ความเห็น" ของ AI เข้ามามีอำนาจตัดสินใจในกระบวนการพัฒนาซอฟต์แวร์ ซึ่งถ้า rubric ที่ให้ AI ใช้นั้นเขียนได้ห่วย หรือมี bias แฝงอยู่ ผลลัพธ์ที่ได้คือ "ระบบที่ทำงานได้ตามกฎ แต่พังตามเจตนา" — ซึ่งแย่กว่าการมีกฎตายตัวที่ผิดอีก
อีกเรื่องที่ต้องจับตาคือ "versioned rubrics" — การมีเกณฑ์ประเมินหลายเวอร์ชันแปลว่าคุณต้องมีกระบวนการจัดการเวอร์ชันของ "ความคิด" ด้วย ใครเป็นคน approve ว่า rubric เวอร์ชันใหม่ดีพอ? ถ้า agent ให้คะแนนไม่ตรงกับที่ senior architect คิด ใครชนะ? คำถามพวกนี้ยังไม่มีคำตอบชัดเจนในบทความ แต่เป็นเรื่องที่ใครจะเอาไปใช้จริงต้องคิดให้ตก
Boundary Fidelity
AI ตรวจว่าแต่ละ module ยังอยู่ในขอบเขตที่ควรเป็นไหม หรือเริ่มแอบเรียกของที่ไม่ได้ตกลงกันไว้
Semantic Contract Drift
สัญญาระหว่าง service (เช่น "ส่ง userId ต้องได้ user object กลับมา") ยังตรงกันอยู่ไหม หรือเริ่มเพี้ยนทีละนิดโดยไม่มีใครสังเกต
Stale ADR Assumptions
เอกสารการตัดสินใจทางสถาปัตยกรรมที่เขียนไว้ตั้งแต่อดีต ยังตรงกับความเป็นจริงในโค้ดปัจจุบันไหม หรือกลายเป็นแค่ "นิทานก่อนนอน"
ประเด็นที่ผมคิดว่าสำคัญที่สุดจากบทความนี้คือการยกระดับจาก "การตรวจสอบ" ไปเป็น "การปรับปรุงอย่างต่อเนื่อง" — fitness functions เดิมคือเครื่องมือ "กันภัย" แต่ agentic fitness functions คือเครื่องมือ "นำทาง" ที่คอยบอกว่าสถาปัตยกรรมกำลังจะหลงทางก่อนที่มันจะหลงจริงๆ มันเปลี่ยนบทบาทของระบบ governance จากตำรวจเป็นโค้ช ซึ่งเป็น paradigm shift ที่น่าสนใจมาก
แน่นอนว่ายังเร็วไปที่จะบอกว่าแนวคิดนี้จะกลายเป็นมาตรฐานอุตสาหกรรม เพราะมันต้องพึ่งทั้งคุณภาพของ AI agent และวุฒิภาวะขององค์กรในการรับ "คำแนะนำ" จากเครื่องจักร แต่ทิศทางมันชัดเจน — โลกของซอฟต์แวร์เริ่มซับซ้อนเกินกว่าจะใช้ไม้บรรทัดวัดทุกอย่างได้
ฟันธงเลย — กติกาแบบ deterministic กำลังจะกลายเป็นแค่ "พื้นฐาน" ไม่ใช่ "จุดขาย" ของระบบ governance ที่ดีอีกต่อไป ใครที่ยังยึดติดกับการเขียนกฎ if-else ตรวจ architecture อยู่ จะเริ่มเห็นช่องว่างที่ AI เติมเต็มได้ชัดขึ้นเรื่อยๆ แต่คำถามที่ทุกคนต้องตอบให้ได้ก่อนกระโดดเข้าไปใช้คือ: คุณไว้ใจ "ดุลยพินิจ" ของ AI มากพอที่จะปล่อยให้มันตัดสินว่าสถาปัตยกรรมของคุณ "เบี่ยงเบน" หรือยัง?
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 4
กำลังโหลดความคิดเห็น...