Using AI to Tackle Technical Debt Efficiently

What is Technical Debt?

Technical Debt (Tech debt) คือหนี้ที่เราต้องจ่าย เกิดขึ้นจากการตัดสินใจระหว่างการทำซอฟต์แวร์

บางครั่งเราอาจจะเลือกทางง่ายและเร็ว เพื่อปล่อยฟีเจอร์ออกสู่ตลาดก่อนให้ทัน time to market แต่มันก็อาจจะไม่ได้เป็นโค้ดที่ดี และเราต้องกลับมาแก้

ปัญหาคือเราสามารถแบ่งเวลามาแก้หนี้นี้ได้ตลอด เพราะหากเรียงตามความสำคัญและเร่งด่วน งานพวกนี้มักได้อยู่ท้ายๆ ตลอด

AI as Your Diligent Team Member

แต่ปัญหานี้จะหมดไปเมื่อเรามี “พนักงานดีเด่น” ที่พร้อมทำงานนี้ให้เรา 24/7 และไม่เคยบ่นสักนิด และนั่นคือ AI เพื่อนรักของเรา

Why Tech Debt Work is Perfect for AI

งาน Tech Debt ส่วนใหญ่มันค่อนข้างชัดเจน

ไม่เพิ่มโค้ด/ลบโค้ด/refactor/ หรือทำ migration พวกนี้มันตรงไปตรงมา รู้ชัดว่าต้องทำอะไร ทำให้เรารีวิวงานที่ AI ทำได้ง่าย ผิดพลาดได้ง่าย

ตัวอย่างจากประสบการณ์: ฮงใช้ AI ทำลบโค้ดที่เกี่ยวกับ feature toggle โดยอธิบายว่าโค้ดส่วนไหนต้องถูกแก้ไข มี pattern ยังไง Cursor AI ก็สรุปพวกนั้น ลง rules เอง

Practical Use Cases

1️⃣ Endpoint Migration (Switch Call)

เมื่อเราต้องเปลี่ยนจากการ call service A เป็น B (กำหนดให้ว่า endpoint ใน Service B พร้อมใช้งานแล้ว)

การที่ระบบเราจะยิง request ไป service ต่างๆได้ทำได้ทั้ง:

1. เขียนเองตรงๆ กำหนด HTTP method, url, query, body
2. import Client lib มา (เราอาจจะ generate client เองหรือไม่ก็ได้)

เราให้ cursor AI อ่าน package ของ lib นั้นๆได้ ว่า มี endpoint อะไรบ้าง รับ parameter อะไร response เป็นอย่างไร

เมื่อ AI เข้าใจแล้ว เราก็อธิบายเพิ่มว่าต้องไปแก้ไข เพื่อสร้างเงื่อนไขในการ เปลี่ยน function call จาก service A -> B ได้

และเพิ่ม/แก้ไข/ลบ test file ให้เรียบร้อย

2️⃣ Endpoint Migration (API Endpoint)

ต่างจากด้านบนนิดนึง ตรงที่ เรากำลังจะให้มันช่วยสร้าง backend API endpoint เลย

โดยปกติเวลาเราเปิด cursor AI เราจะเปิดไปที่ folder ของ project นั้น แปลว่า workspace ของเรามี 1 project

แต่เราสามารถเปิดหลาย project ใน 1 workspace ได้ มันมี feature “Add Folder to Workspace” (ซึ่ง folder ของ project ไม่จำเป็นต้องอยู่ใกล้ๆกันจริงๆ)

เมื่อเราเปิดหลาย project พร้อมกันใน workspace เดียว cursor AI จะสามารถอ่านไฟล์ และมี context ของทั้ง 2+ project ได้

จาก usecase ของเราที่ต้องการทำ endpoint migration จาก service A -> B เราให้ AI อ่าน endpoint service A แล้วดูว่าจะมาสร้าง endpoint ใน service B อย่างไร

รีวิวแผนงานก่อนให้มัน execute

ซึ่งแน่นอนว่า service A และ B ไม่จำเป็นต้องเป็นภาษาเดียวกัน

Learning the Process

ครั้งแรกมันอาจจะดูยาก ซับซ้อน และเราอาจจะมีความรู้สึกว่าทำเองเร็วกว่า

แต่ถ้าเราทำได้แล้วครั้งหนึ่ง ครั้งถัดๆไปมันจะง่ายและเร็วขึ้น เมื่อมี know-how และบันทึก เป็น rules ไว้ ครั้งหน้าก็ต่อยอดจากของเดิมได้

Breaking Assumptions

ฮงเองก็เคยมีความคิดว่า “เรื่องแบบนี้ AI มันยังทำไม่ได้” แต่ว่ามันอาจจะเป็นสมมุติฐานที่ผิดก็ได้ ความจริงแล้วมันอาจจะเป็นว่า “มันทำได้ แต่ฮงไม่รู้ และไม่เคยได้ทดสอบความสามารถของมัน”

หลังจากได้ทดลอง มันก็ได้เปิดโลกความเป็นไปได้ของฮง และฮงอยากจะจุดประกาย ความเป็นไปได้เหล่านี้ให้กับเพื่อนๆด้วย

The Engineer’s Concern and Adaptation

AI เก่งขึ้น ประเภทของงานที่ AI ทำได้จะยิ่งมีมากขึ้นเรื่อยๆ ในฐานะ software engineer เราต้องปรับตัวและพัฒนาตัวเอง เพื่อให้สามารถส่งมอบ value ที่ AI ยังไม่สามารถให้ได้

เช่นการคิดถึงภาพรวมมากขึ้น และมองในระบบทีมหรือองค์กรมากขึ้น และทดลองไอเดียใหม่ๆ ที่จะใช้พัฒนาตัวเองและทีม แบบสนุกๆ

โดยส่วนตัวแล้วการแก้ปัญหาและเขียนโค้ดด้วยตัวเอง มันเป็นความสนุกที่ฮงไม่ค่อยอยากจะให้ AI พรากมันไป แต่เราเองก็ต้องปรับตัวในโลกที่มี AI

ฮงคิดว่าจะลดสัดส่วนการเขียนเองเป็น งานที่ฮงไม่เคยทำ และกำหนดระยะเวลาที่จะเขียนเอง เช่น 1 สัปดาห์ ต้องมีเขียนเองบ้าง เพื่อขัดเกลาทักษะให้ยังคงอยู่ และเอาเวลาที่ได้กลับมาไปพัฒนาตัวเอง

Closing Thoughts

ฮงหวังว่าบทความนี้จะมีประโยชน์กับเพื่อนๆนะครับ ถ้าเพื่อนๆมี usecase ไหนน่าสนใจมาแชร์กันได้นะครับ