AI เขียน Code ให้แล้ว ควร Review อะไรเป็นพิเศษ
Code ที่ AI เขียนทำงานได้แล้ว ยังต้องตรวจอะไรอีก ลองตามฟังก์ชันดาวน์โหลดใบเสนอราคา ตั้งแต่ diff สิทธิ์เข้าถึง การจัดการ error ไปจนถึง dependency และ test ก่อน merge
ถ้า AI เขียนฟังก์ชันให้แล้ว เปิดหน้าเว็บได้ กดดาวน์โหลดได้ และ test ผ่าน เราควรดูอะไรต่อก่อนนำไปใช้จริงครับ
ผมจะเริ่มจากสิ่งที่ฟังก์ชันนั้นมีสิทธิ์แตะ โดยเฉพาะข้อมูลลูกค้า ลองใช้ตัวอย่างเว็บที่ให้ลูกค้าดาวน์โหลดใบเสนอราคาของตัวเอง งานที่ขอ AI ดูเล็กมาก แค่เพิ่มปุ่มกับทางดาวน์โหลดไฟล์ แต่ต้องตามให้ถึงว่าใครขอไฟล์ ระบบเลือกฉบับไหน และเกิดอะไรขึ้นเมื่อเลือกไม่ได้
GitHub ระบุในแนวทางของ Copilot ว่า code ที่เสนออาจผิดหรือไม่ตรงเจตนา จึงยังต้อง review และทดสอบ อย่าให้คำอธิบายที่อ่านลื่นของ AI แทนหลักฐานว่าระบบทำงานถูกแล้ว
เปิด diff แล้วตามให้ถึงไฟล์ที่ส่งข้อมูล
ก่อนอ่านทีละบรรทัด เขียนสิ่งที่ต้องได้ให้ชัดสักสองประโยค ลูกค้าดาวน์โหลดใบเสนอราคาของตัวเองได้ และได้เฉพาะฉบับที่ฝ่ายขายอนุมัติให้ส่ง เงื่อนไขเรื่องฉบับอนุมัตินี้เป็นกติกาสมมติของเว็บตัวอย่าง ต้องตกลงกับคนใช้งานก่อนนำไปใช้กับงานจริง
จากนั้นเปิด diff หรือส่วนที่เปลี่ยนใน Git ดูทั้งไฟล์ใหม่ ไฟล์ที่แก้ และไฟล์ที่ลบ ถ้าขอเพิ่มดาวน์โหลด แต่มีการเปลี่ยนตัวตรวจสิทธิ์ส่วนกลางหรือปิด test เดิมด้วย ก็ควรถามเหตุผลก่อน
ตามทางจากปุ่มไปยัง API ที่รับคำขอ จนถึงจุดเลือกและส่งไฟล์ ดูว่า code ใหม่ใช้ตัวตรวจสิทธิ์เดิมหรือสร้างอีกชุดที่กติกาต่างกัน ผมจะขอแยกงานจัดระเบียบ code ที่ไม่เกี่ยวออกก่อน เพื่อให้รอบนี้ตรวจผลกระทบได้ไหว
ล็อกอินผ่านแล้ว ยังต้องตรวจว่าเปิดเอกสารนี้ได้ไหม
Authentication คือการยืนยันว่าใครเข้ามา ส่วน authorisation คือคนนั้นทำอะไรได้ หน้าเว็บอาจรู้แล้วว่าเป็นลูกค้า ก แต่ทางดาวน์โหลดกลับเลือกใบเสนอราคาจากหมายเลขที่รับมาอย่างเดียว โดยไม่ได้ตรวจว่าเป็นของลูกค้า ก ด้วย
การซ่อนปุ่มช่วยเรื่องหน้าจอ แต่คน review ต้องดูว่าฝั่งที่ส่งข้อมูลตรวจสิทธิ์จริงหรือไม่ รวมถึงไฟล์ในที่เก็บว่ามีช่องทางเปิดตรงที่ข้ามกติกาหรือเปล่า OWASP แนะนำให้ตรวจสิทธิ์ทุกคำขอและปฏิเสธเป็นค่าเริ่มต้น เมื่อยังยืนยันสิทธิ์ไม่ได้ สำหรับตัวอย่างนี้ หน้าแสดงรายละเอียดกับทางดาวน์โหลดจึงต้องรักษากติกาเดียวกัน
หมายเลขลูกค้าที่หน้าเว็บส่งมาก็เป็นข้อมูลจากผู้ขอ ต้องผูกกับบัญชีที่ระบบยืนยันแล้วและตรวจความสัมพันธ์กับเอกสารฝั่ง server ด้วย
เมื่อสิทธิ์ถูกแล้ว ยังต้องดูว่าได้ไฟล์ถูกฉบับหรือไม่ เช่น code เลือกไฟล์ล่าสุด แต่ไฟล์ล่าสุดเป็นฉบับร่างที่ฝ่ายขายยังไม่อนุมัติ แบบนี้ไม่ได้รั่วข้ามลูกค้า แต่ก็ผิดงานอยู่ดี
เมื่อหาไฟล์ไม่ได้ อย่าให้ผลลัพธ์ดูเหมือนสำเร็จ
สมมติบริการตรวจสิทธิ์ไม่ตอบ ระบบควรหยุดส่งเอกสารและแจ้งว่าเปิดไม่ได้ตามกติกาที่ตกลงไว้ ต้องระวังทางลัดที่อนุญาตเมื่ออ่านสิทธิ์ไม่สำเร็จ หรือคืนไฟล์ตัวอย่างแทน เพราะอาจถูกทิ้งไว้จากช่วงทดลอง
ถ้าตรวจสิทธิ์ผ่านแต่พื้นที่เก็บไฟล์ขัดข้อง การจับ error แล้วคืนรายการว่างอาจทำให้ฝ่ายขายเข้าใจว่าลูกค้ายังไม่มีใบเสนอราคา ส่วนการแสดงข้อความสำเร็จทั้งที่ดาวน์โหลดไม่ครบก็พาคนใช้ตัดสินใจผิดได้ ลองดูทั้งผลที่ API ตอบและสิ่งที่หน้าจอแสดงเมื่อได้รับผลนั้น
แนวทาง Error Handling ของ OWASP แยกข้อความทั่วไปที่ตอบผู้ใช้ออกจากรายละเอียดสำหรับตรวจปัญหาภายใน เว็บตัวอย่างอาจให้เลขอ้างอิงคำขอเพื่อแจ้งผู้ดูแล โดย log ต้องแยกได้ว่าเสียตรงตรวจสิทธิ์หรืออ่านไฟล์ และเก็บเท่าที่จำเป็น ไม่เท token หรือเนื้อหาใบเสนอราคาลงไปทั้งหมด
Package กับ test ต้องตรวจนอกคำตอบของ AI ด้วย
ถ้า AI เพิ่ม library สำหรับ PDF ให้เปิดรายการ dependency และ lockfile ที่บันทึกรุ่นไปด้วย ตรวจชื่อ package แหล่งที่มา รุ่น และวิธีเรียกใช้กับเอกสารของผู้พัฒนา package นั้นจริง ๆ รวมถึงเงื่อนไขการใช้ อย่าติดตั้งตามชื่อที่ AI ให้มาเพียงอย่างเดียว
ผมจะดูด้วยว่าโครงการมีของเดิมที่ทำงานนี้ได้อยู่แล้วไหม ถ้าเพิ่มของใหม่เพื่อประหยัด code ไม่กี่บรรทัด แต่ต้องตามดูแลอีกตัวก็อาจไม่คุ้ม OWASP อธิบายการจัดการ dependency ตั้งแต่รู้ว่ามีอะไรใช้อยู่ไปจนถึงติดตามและจัดการช่องโหว่ ผลสแกนจึงช่วยตรวจบางส่วน ส่วนความเหมาะสมกับงานยังต้องพิจารณาเอง
สำหรับ test ให้ตั้งคำตอบจากกติกาที่คุยกันไว้ก่อน ไม่ใช้สิ่งที่ code ทำอยู่เป็นคำตอบตั้งต้น เพราะ AI อาจเขียนทั้ง code และ test ให้เห็นตรงกันในเงื่อนไขที่ผิด ใช้บัญชีและเอกสารสมมติในระบบทดสอบ แล้วเริ่มจากกรณีเหล่านี้
- ลูกค้า ก ได้ใบเสนอราคาฉบับที่อนุมัติของตัวเอง แม้จะมีฉบับร่างที่ใหม่กว่า
- ลูกค้า ข ไม่ได้รับข้อมูลของลูกค้า ก ทั้งทางหน้าอ่านและดาวน์โหลด
- ผู้ที่ยังไม่ล็อกอินหรือ session หมดอายุไม่ได้รับเนื้อหาเอกสาร
- เมื่อตรวจสิทธิ์ไม่ได้หรือที่เก็บไฟล์ขัดข้อง ระบบไม่ส่งไฟล์ทดแทนและไม่แสดงว่าสำเร็จ
ผลที่ควรดูคือเนื้อหาไฟล์และสถานะที่ผู้ใช้เห็นด้วย ไม่ใช่แค่คำขอจบโดยไม่มี error ถ้า test จำลองส่วนตรวจสิทธิ์ให้ตอบว่าอนุญาตตลอด ก็ยังไม่ได้ตรวจการตัดสินสิทธิ์จริง ต้องมีกรณีที่ใช้ส่วนตรวจสิทธิ์และที่เก็บไฟล์ร่วมกันในระบบทดสอบด้วย
รัน test เดิมที่เกี่ยวข้องเพื่อดูว่าฟังก์ชันอื่นเสียไปหรือไม่ และอ่าน diff ของ test ว่ามีการลบข้อยืนยันหรือเปลี่ยนค่าที่คาดหวังเพื่อให้ผ่านหรือเปล่า ให้ AI เสนอกรณีตกหล่นได้ โดยใช้ข้อมูลที่อนุญาตให้ส่งเข้าเครื่องมือและตรวจคำแนะนำเอง
ก่อน merge หรือรวมเข้ากับ code หลัก จดสั้น ๆ ว่าเปลี่ยนอะไร ทดสอบอะไร และส่วนไหนยังไม่ได้ตรวจ สำหรับเว็บใบเสนอราคานี้ ผมจะยอมให้ปุ่มมาช้าลงถ้ายังชี้ไม่ได้ว่าตรวจสิทธิ์ที่ไหนและเลือกไฟล์ฉบับใด เมื่อทีมอธิบายสองเรื่องนี้พร้อมผลทดสอบได้ การรับงานก็มีเหตุผลรองรับมากกว่าคำว่า “AI แก้ครบแล้ว” ครับ