ผู้เขียนแพลตฟอร์มประกันภัยที่มีอายุ 20 ปี ได้นำตั๋วสนับสนุน (support tickets) จำนวน 108 รายการมาผ่านกระบวนการ AI-agent pipeline ที่สร้างขึ้นเอง และผลลัพธ์ที่ได้คือเวิร์กโฟลว์ที่เปลี่ยนงานของนักพัฒนาอาวุโสที่ต้องใช้เวลาหลายชั่วโมง ให้เหลือเพียงไม่กี่นาที ซึ่งเป็นการเปลี่ยนแปลงที่อาจพลิกโฉมวิธีการที่องค์กรต่างๆ ใช้รักษาโค้ดรุ่นเก่า (legacy code) ให้คงอยู่ต่อไป
ทำไมระบบ Legacy ถึงมีความสำคัญมากกว่าโค้ดใหม่
แอปพลิเคชันประกันภัยที่กล่าวถึงนี้เป็นระบบ Monolith ที่มีโค้ดถึง 2.3 ล้านบรรทัด และมี PL/SQL packages ประมาณ 1,000 แพ็กเกจ ขนาดของมันเพียงอย่างเดียวก็ทำให้ไม่มีใครสามารถดูแลโค้ดทั้งหมดได้เพียงคนเดียว เมื่อรวมกับเขาวงกตของพารามิเตอร์การตั้งค่าเฉพาะสำหรับลูกค้าแต่ละราย เอกสารที่กระจัดกระจาย และคลังเก็บตั๋วที่ย้อนหลังไปถึงปี 2017 คอขวดที่แท้จริงจึงกลายเป็นการ "ค้นหาบริบท" (finding context) ไม่ใช่การเขียนโค้ด
กระแส AI ในปัจจุบันมักมุ่งเน้นไปที่การสร้างโค้ดใหม่สำหรับโปรเจกต์แบบ Greenfield แต่ในกรณีนี้ ส่วนที่ยากไม่ใช่ไวยากรณ์ของ PL/SQL แต่เป็นการระบุตำแหน่งของตรรกะ (logic) ที่ถูกต้อง การตั้งค่าที่เกี่ยวข้อง และตั๋วประวัติศาสตร์ที่อธิบายปัญหาไว้เป็นครั้งแรก นักพัฒนาที่มีประสบการณ์อาจต้องใช้เวลาหลายชั่วโมงในการรวบรวมเบาะแสจาก GitLab, SVN, wikis และตั๋วสนับสนุนเก่าๆ แต่ AI agent สามารถทำงานแบบเดียวกันนี้ได้ภายในไม่กี่นาที
เวิร์กโฟลว์ในการใช้งานจริง
เมื่อมีตั๋วใหม่เข้ามา ผู้เขียนจะรันคำสั่งเพียงคำสั่งเดียว จากนั้น agent จะ:
- ดึงข้อความในตั๋วและไฟล์แนบใดๆ ผ่าน ticket-system API
- ทำการค้นหาด้วย keyword และ vector search ทั่วทั้งคลังตั๋วเพื่อดึงกรณีที่คล้ายกันในอดีตขึ้นมา
- สอบถามไปยังคลังส่วนตัวของ SQL scripts ที่นำกลับมาใช้ใหม่ได้
- ตรวจสอบประวัติโค้ดในระบบควบคุมเวอร์ชัน (GitLab หรือ SVN)
ผลลัพธ์ทั้งหมดจะถูกรวบรวมไว้ในไฟล์เดียว ซึ่งจะแนะนำขั้นตอนต่อไปด้วย โดยปกติจะเป็นการแก้ไขโค้ด การร่างคำตอบสำหรับลูกค้า หรือการขอข้อมูลการวินิจฉัยเพิ่มเติม
ความสามารถที่มีมาในตัว
ผู้เขียนได้กำหนด "ทักษะ" (skills) 24 อย่างให้กับ agent โดยแบ่งออกเป็น 4 หมวดหมู่:
- การเข้าถึงบริบท (Context access) – การอ่าน API, คู่มือ และฐานข้อมูลเพื่อดึงข้อเท็จจริงที่เกี่ยวข้อง
- ความรู้เฉพาะทาง (Domain knowledge) – การตีความกฎการบัญชีประกันภัยและสถาปัตยกรรมของระบบ
- การเขียน (Writing) – การสร้างโค้ด PL/SQL snippets และจัดเตรียมสำหรับการติดตั้ง (deployment)
- เมตา (Meta) – การจดจำรูปแบบและสร้างทักษะใหม่โดยอัตโนมัติเมื่อจำเป็น
ทักษะเหล่านี้ช่วยให้ agent ทำหน้าที่เหมือนวิศวกรระดับจูเนียร์ที่ไม่เคยหลับใหล โดยสามารถระบุบรรทัดของโค้ดหรือการตั้งค่าที่ตั๋วอ้างถึงได้อย่างแม่นยำ
ตาข่ายความปลอดภัยที่สร้างไว้ในกระบวนการ
การทำงานอัตโนมัติในสภาพแวดล้อมการใช้งานจริง (production environment) จำเป็นต้องมีมาตรการป้องกัน ผู้เขียนใช้กฎง่ายๆ สองข้อ:
- การตรวจสอบแบบ Static (Static validation) – สคริปต์ที่สร้างขึ้นทุกตัวจะถูกรันผ่าน
EXPLAIN PLANกับ schema จริง เพื่อตรวจสอบไวยากรณ์หรือข้อผิดพลาดทางตรรกะโดยไม่ต้องรันโค้ดจริง - การยืนยันด้วยสองโมเดล (Dual-model confirmation) – AI agent ตัวที่สองที่เป็นอิสระจะตรวจสอบการเปลี่ยนแปลงใดๆ ที่ถือว่ามีความเสี่ยง หากทั้งสองโมเดลได้ข้อสรุปเดียวกัน ผู้เขียนจะดำเนินการต่อ มิฉะนั้น ตั๋วจะถูกส่งต่อไปยังการตรวจสอบด้วยตนเอง (manual review)
การตรวจสอบเหล่านี้ช่วยป้องกันไม่ให้กระบวนการกลายเป็น "กล่องดำ" (black box) ที่อาจทำให้ธุรกรรมประกันภัยที่สำคัญเสียหายโดยไม่ตั้งใจ
ประโยชน์ที่ทวีคูณ
ผลลัพธ์ของแต่ละตั๋วจะถูกแนบกลับไปยังบันทึกตั๋ว เพื่อสร้างฐานความรู้ที่มีชีวิต เมื่อปัญหาที่คล้ายกันเกิดขึ้นอีกในอีกไม่กี่เดือนหรือหลายปีต่อมา agent จะสามารถอ่านได้ไม่เพียงแค่แนวทางแก้ไขก่อนหน้า แต่ยังรวมถึงเหตุผลที่นำไปสู่การแก้ไขนั้นด้วย ในทางปฏิบัติ ทุกตั๋วที่ได้รับการแก้ไขจะกลายเป็นข้อมูลสำหรับฝึกฝน (training data) สำหรับตั๋วในอนาคต ซึ่งช่วยเร่งวงจรการทำงานให้เร็วขึ้นไปอีก
ข้อจำกัดตามความเป็นจริง
- ยังต้องมีการทดสอบด้วยตนเอง – ผู้เขียนยังคงต้องตรวจสอบการเปลี่ยนแปลงในสภาพแวดล้อมทดสอบ (test environment) ก่อนที่จะนำไปใช้งานจริง
- ยังไม่มีตัวชี้วัดที่ชัดเจน – แม้ว่าเวลาที่ประหยัดได้จะดูเหมือนมีจำนวนมาก แต่ผู้เขียนยังไม่ได้ระบุจำนวนชั่วโมงที่ลดลงอย่างชัดเจน
- การตั้งค่าส่วนบุคคล – การติดตั้งในปัจจุบันทำงานบนเวิร์กสเตชันเพียงเครื่องเดียว การขยายผลไปใช้ทั้งทีมจำเป็นต้องมีการวิศวกรรมเพิ่มเติม
ข้อจำกัดเหล่านี้ทำให้แนวทางนี้ยังไม่ใช่ผลิตภัณฑ์สำเร็จรูป (turnkey product) แต่มันไม่ได้ลดทอนความเข้าใจหลักที่ว่า: AI สามารถย่นระยะเวลาการรวบรวมบริบทจากหลายชั่วโมงให้เหลือเพียงไม่กี่นาที
สิ่งที่ต้องจับตามองต่อไป
การทดลองของผู้เขียนเป็นเพียงการพิสูจน์แนวคิด (proof-of-concept) มากกว่าจะเป็นข้อเสนอเชิงพาณิชย์ ขั้นตอนต่อไปที่สมเหตุสมผล ได้แก่:
- การกำหนดตัวชี้วัดให้เป็นทางการ – การติดตามเวลาในการแก้ไขปัญหา (ticket resolution time) ทั้งก่อนและหลังการใช้ AI pipeline เพื่อสร้างกรณีทางธุรกิจ (business case)
- การนำไปใช้งานในทีม – การจัดทำ agent ในรูปแบบบริการส่วนกลาง (shared service) เพื่อให้วิศวกรหลายคนสามารถใช้ประโยชน์จากฐานความรู้เดียวกันได้
- การรวมเข้ากับ CI/CD – การส่งสคริปต์ที่ผ่านการตรวจสอบแล้วเข้าสู่ continuous-integration pipeline โดยตรง จะช่วยปิดวงจรตั้งแต่การรับ ticket ไปจนถึงการนำขึ้นระบบจริง (production) โดยไม่ต้องมีการส่งต่องานด้วยมือ (manual hand-off)
หากการต่อยอดเหล่านี้ประสบความสำเร็จ โมเดลนี้อาจกลายเป็นต้นแบบสำหรับองค์กรอื่นๆ ที่กำลังรับมือกับฐานโค้ด (codebases) ขนาดใหญ่และซับซ้อน
บทสรุป
คุณค่าที่แท้จริงของ AI ในสภาพแวดล้อมแบบ legacy ไม่ใช่การเขียนโค้ดใหม่โดยอัตโนมัติ แต่คือการดึงบริบทที่ถูกต้องออกมาให้เห็นได้ในทันที ด้วยการเปลี่ยนงานสืบค้นข้อมูลที่ต้องใช้เวลาหลายชั่วโมงของนักพัฒนาอาวุโสให้เหลือเพียงไม่กี่นาที เวิร์กโฟลว์ของ AI-agent สามารถช่วยให้ระบบเก่าๆ ยังคงทำงานต่อไปได้ ลดค่าใช้จ่ายในการสนับสนุน และค่อยๆ สร้างคลังความรู้ที่เสริมสร้างตัวเองขึ้นมาอย่างต่อเนื่อง การทดลองนี้แสดงให้เห็นว่า สำหรับซอฟต์แวร์แบบ legacy การเพิ่มประสิทธิภาพการทำงานที่ยิ่งใหญ่ที่สุดมาจากการลดระยะเวลาในการค้นหาคำตอบ ไม่ใช่จากการสร้างโค้ดใหม่