รีวิวโค้ดที่คนเขียนกับโค้ดที่ AI เขียน ต้องเปลี่ยนวิธีตรวจตรงไหนบ้าง

ผู้ตรวจโค้ดคนหนึ่งเล่าว่าอนุมัติ Pull Request ที่ AI เขียนให้ภายในไม่กี่นาที เพราะโค้ดอ่านง่าย ตั้งชื่อตัวแปรดี มี Comment อธิบายทุกจุด ดูเป็นมืออาชีพกว่าที่คนในทีมเขียนเองด้วยซ้ำ แต่สองสัปดาห์ต่อมาก็พบว่าโค้ดชิ้นนั้นมีช่องโหว่ให้ผู้ใช้คนหนึ่งดูข้อมูลของผู้ใช้คนอื่นได้ เพราะ AI ลืมตรวจสอบสิทธิ์ก่อนดึงข้อมูลจากฐานข้อมูล ทั้งที่โค้ดหน้าตาดูสมบูรณ์แบบทุกอย่าง

เรื่องแบบนี้เกิดขึ้นบ่อยกว่าที่คิด เพราะโค้ดที่ AI เขียนมีความพิเศษอยู่อย่างหนึ่งคือมันมักอ่าน 'ดูน่าเชื่อถือ' มากกว่าที่ควรจะเป็น มีโครงสร้างเป็นระเบียบ มี Comment ครบ ทำให้ผู้ Review ลดการ์ดลงโดยไม่รู้ตัว ทั้งที่ความน่าเชื่อถือทางสายตากับความถูกต้องทางตรรกะเป็นคนละเรื่องกันเลย

บทความนี้จะพาไล่ดูว่าเมื่อ Review โค้ดที่ AI สร้าง ต้องเปลี่ยนวิธีคิดตรงไหนบ้างเมื่อเทียบกับการ Review โค้ดที่คนเขียนเอง ครอบคลุมทั้งด้าน Security, Logic ทางธุรกิจ, คุณภาพของ Test และ Dependency ที่มักถูกเพิ่มเข้ามาโดยไม่มีใครสังเกต

ทำไมการรีวิวโค้ด AI ต้องใช้วิธีคิดต่างจากเดิม

เมื่อคนในทีมเขียนโค้ด ผู้ Review มักรู้บริบทอยู่แล้วว่าคนคนนั้นถนัดอะไร มักพลาดจุดไหนเป็นประจำ และคุ้นกับสไตล์การเขียนที่ต่างกันไปในแต่ละคน แต่เมื่อ AI เป็นคนเขียน ผู้ Review จะไม่มีบริบทแบบนั้นเลย เพราะ AI ไม่มี 'สไตล์ที่คุ้นเคย' ตายตัว มันปรับรูปแบบไปตาม Prompt และ Context ที่ได้รับในแต่ละครั้ง ทำให้คาดเดาแนวโน้มความผิดพลาดล่วงหน้าได้ยากกว่า

อีกความต่างคือ AI ไม่มีความรู้สึกเป็นเจ้าของงาน มันไม่ลังเลที่จะเขียน Logic ที่ซับซ้อนเกินจำเป็นถ้า Prompt ดูเหมือนต้องการแบบนั้น และมันไม่รู้สึกผิดถ้าทางลัดที่เลือกใช้จะสร้างปัญหาระยะยาว สิ่งเหล่านี้ทำให้ผู้ Review ต้องตั้งคำถามกับโค้ดของ AI ในมุมที่ต่างจากการ Review โค้ดของเพื่อนร่วมทีม

สิ่งที่ไม่เปลี่ยนคือมาตรฐานคุณภาพขั้นต่ำของทีมยังต้องเท่าเดิม ไม่ว่าใครจะเป็นคนเขียนโค้ดนั้นก็ตาม ความต่างอยู่ที่ 'จุดที่ต้องให้ความสนใจเป็นพิเศษ' มากกว่ามาตรฐานที่ใช้ตัดสิน

ตรวจ Security ให้ลึกกว่าที่ตาเห็น

จุดที่พลาดบ่อยที่สุดในโค้ดที่ AI เขียนคือการตรวจสอบสิทธิ์การเข้าถึงข้อมูล (Authorization) เพราะ AI มักโฟกัสที่ทำให้ Feature ทำงานได้ก่อน แล้วมองข้ามการตรวจว่าผู้ใช้ที่เรียกใช้งานมีสิทธิ์เข้าถึงข้อมูลนั้นจริงหรือไม่ ผู้ Review จึงต้องเช็กเป็นพิเศษว่าทุก Endpoint ที่ดึงหรือแก้ไขข้อมูล มีการตรวจสิทธิ์ก่อนเสมอ ไม่ใช่แค่ตรวจว่าล็อกอินอยู่หรือไม่

อีกจุดที่ต้องตรวจคือการจัดการ Input จากผู้ใช้ AI มักเขียนโค้ดที่รับ Input ตรง ๆ แล้วนำไปใช้งานทันทีโดยไม่มีการกรองหรือตรวจสอบความถูกต้องก่อน ซึ่งเปิดช่องให้เกิดปัญหาอย่างการฉีดคำสั่งแปลกปลอมเข้าไปในระบบได้ถ้าไม่มีการป้องกัน ผู้ Review ควรตรวจทุกจุดที่รับข้อมูลจากภายนอกว่ามีการตรวจสอบก่อนนำไปใช้เสมอ

สุดท้ายคือการจัดการข้อมูลอ่อนไหว เช่น รหัสผ่านหรือ Token ผู้ Review ควรตรวจว่า AI ไม่ได้เขียนโค้ด Log ข้อมูลเหล่านี้ออกมาแบบไม่ตั้งใจ เพราะเป็นความผิดพลาดที่พบได้บ่อยเมื่อ AI เขียนโค้ด Debug เพื่อช่วยตรวจสอบระหว่างพัฒนา แล้วไม่มีใครลบออกก่อนขึ้นระบบจริง

ตรวจ Logic ทางธุรกิจว่าตรงกับความตั้งใจจริงไหม

โค้ดที่ AI เขียนอาจทำงานได้โดยไม่มี Error เลย แต่ยังผิดได้ถ้า Logic ที่มันเลือกใช้ไม่ตรงกับกระบวนการทำงานจริงของธุรกิจ เช่น การคำนวณส่วนลดที่ AI เขียนถูกต้องตามหลักคณิตศาสตร์ แต่ลืมกรณีที่ลูกค้าใช้คูปองสองใบพร้อมกันซึ่งทีมไม่เคยระบุไว้ชัดเจนตั้งแต่ต้น ผู้ Review จึงต้องเทียบ Logic กับความเข้าใจของธุรกิจจริง ไม่ใช่แค่เทียบกับสิ่งที่เขียนไว้ใน Prompt

วิธีที่ช่วยได้มากคือย้อนกลับไปดูว่า Prompt หรือสเปกที่มอบให้ AI ครบถ้วนแค่ไหนตั้งแต่ต้น ถ้าใช้แนวทาง Spec Driven Development ตามที่อธิบายไว้ใน Spec Driven Development ด้วย AI การ Review Logic จะง่ายขึ้นมาก เพราะมีเอกสารอ้างอิงชัดว่าเจตนาจริงคืออะไร ต่างจากกรณีที่มี Prompt สั้น ๆ เพียงประโยคเดียวซึ่งเปิดช่องให้ AI ตีความเองได้กว้างเกินไป

จุดที่ควรระวังเป็นพิเศษคือกรณีขอบที่ไม่ได้พูดถึงตรง ๆ ใน Prompt เช่น จะเกิดอะไรขึ้นถ้าข้อมูลว่างเปล่า จะเกิดอะไรขึ้นถ้าผู้ใช้กดปุ่มซ้ำสองครั้งติดกัน AI มักเลือกพฤติกรรมใดพฤติกรรมหนึ่งไปเองโดยไม่บอก ซึ่งอาจไม่ตรงกับสิ่งที่ธุรกิจต้องการจริง

ตรวจ Test ที่ AI เขียนมาให้ ไม่ใช่แค่ดูว่าเขียนครบหรือยัง

• อ่านชื่อของแต่ละ Test Case ว่าสื่อความหมายตรงกับสิ่งที่กำลังทดสอบจริงหรือไม่ ไม่ใช่แค่ชื่อทั่วไปที่ไม่บอกอะไร
• ตรวจว่า Test ยืนยันผลลัพธ์ที่ถูกต้องจริง ไม่ใช่แค่ยืนยันว่าโค้ดรันไม่พัง เพราะสองอย่างนี้ต่างกันมาก
• มองหาว่ามี Test ที่จงใจส่ง Input ผิดปกติเข้าไปทดสอบหรือไม่ ไม่ใช่มีแต่ Test ที่ใช้ข้อมูลถูกต้องสมบูรณ์แบบตลอด
• เช็กว่า Test Coverage สูงหรือต่ำไม่ได้บอกคุณภาพเสมอไป Test ที่ครอบคลุมเยอะแต่ยืนยันผิดจุดยังอันตรายกว่า Test น้อยแต่ตรงประเด็น
• ลองรัน Test เองด้วยมือสักหนึ่งสองเคสที่สำคัญที่สุด แทนที่จะเชื่อผลจากรายงานอัตโนมัติทั้งหมดโดยไม่สุ่มตรวจเลย

ตรวจ Dependency ใหม่ที่ AI แอบเพิ่มเข้ามา

AI มักเพิ่ม Library ใหม่เข้ามาในโปรเจกต์อย่างรวดเร็วเพื่อแก้ปัญหาให้เร็วที่สุด โดยไม่ได้อธิบายเหตุผลว่าทำไมต้องใช้ตัวนี้ หรือมีทางเลือกที่ทีมใช้อยู่แล้วซึ่งทำงานแบบเดียวกันได้หรือไม่ ผู้ Review ควรตั้งคำถามทุกครั้งที่เห็น Dependency ใหม่ในไฟล์ Package ว่าจำเป็นจริงหรือ AI แค่เลือกทางที่คุ้นเคยที่สุดจากข้อมูลที่มันเรียนรู้มา

อีกความเสี่ยงคือ Library ที่ AI เลือกอาจไม่ได้รับการดูแลต่อเนื่องแล้ว หรือมีช่องโหว่ความปลอดภัยที่รู้จักอยู่แล้วในเวอร์ชันที่ AI เลือกใช้ เพราะ AI ไม่ได้ตรวจสอบสถานะความปลอดภัยล่าสุดของทุก Library แบบเรียลไทม์เสมอไป ทีมควรมีขั้นตอนสแกนช่องโหว่ของ Dependency อัตโนมัติเป็นส่วนหนึ่งของ Workflow อยู่แล้ว ไม่ว่าคนหรือ AI จะเป็นคนเพิ่มเข้ามา

สุดท้ายควรพิจารณาว่า Dependency ใหม่นั้นเพิ่มขนาดโปรเจกต์หรือความซับซ้อนในการดูแลระยะยาวมากแค่ไหน บางครั้ง AI เลือกติดตั้ง Library ใหญ่ทั้งชุดเพื่อใช้แค่ฟังก์ชันเดียว ทั้งที่เขียนโค้ดเองสั้น ๆ ก็ทำได้เหมือนกันโดยไม่ต้องเพิ่มภาระ Dependency ให้โปรเจกต์

วิธีที่ทีมหลายแห่งใช้ได้ผลคือกำหนดรายชื่อ Library ที่อนุญาตให้ AI เลือกใช้ได้โดยไม่ต้องถามก่อนไว้ล่วงหน้า เช่น Library ที่ทีมคุ้นเคยและใช้อยู่แล้วในโปรเจกต์อื่น ส่วน Dependency ที่ไม่อยู่ในรายชื่อนี้ให้ AI ต้องอธิบายเหตุผลก่อนเสมอว่าทำไมของเดิมที่มีอยู่ทำงานแทนไม่ได้ วิธีนี้ช่วยลดจำนวน Dependency แปลกใหม่ที่เข้ามาโดยไม่มีใครตรวจสอบได้มาก โดยไม่ต้องเสียเวลาถกเถียงทุกครั้งที่มีการเพิ่ม Library

ตารางเทียบจุดโฟกัสเมื่อรีวิวโค้ดคนกับโค้ด AI

ใส่การตรวจแบบนี้เข้าไปใน Workflow ทีมได้อย่างไร

การเปลี่ยนวิธี Review ไม่จำเป็นต้องสร้างขั้นตอนใหม่ทั้งหมดแยกจาก Workflow เดิมของทีม สิ่งที่ทำได้คือเพิ่มหัวข้อเฉพาะสำหรับโค้ดที่มาจาก AI ไว้ในเทมเพลต Pull Request เดิม เช่น ระบุว่าเปลี่ยน Dependency อะไรบ้าง แตะ Endpoint ที่มีข้อมูลอ่อนไหวหรือไม่ เพื่อให้ผู้ Review รู้ตั้งแต่ต้นว่าควรโฟกัสจุดไหนเป็นพิเศษ

แนวทางนี้เชื่อมโยงกับภาพรวมของ Workflow ที่กว้างกว่า ซึ่งอธิบายไว้ใน AI Coding Workflow โดยขั้น Review ควรถูกกำหนดไว้ล่วงหน้าว่าเป็นด่านบังคับก่อนโค้ดจาก AI จะเข้าสู่ระบบจริงเสมอ ไม่ว่างานนั้นจะดูเร่งด่วนแค่ไหนก็ตาม เพราะการข้ามขั้นนี้ไปมักแพงกว่าเวลาที่ประหยัดได้ในระยะสั้น

ทีมที่ทำแบบนี้อย่างสม่ำเสมอมักพบว่าคุณภาพของ Prompt ที่ใช้สั่ง AI ดีขึ้นไปด้วยเมื่อเวลาผ่านไป เพราะคนที่ Review บ่อย ๆ จะเริ่มเห็นแพทเทิร์นว่า Prompt แบบไหนมักนำไปสู่ปัญหาแบบไหน แล้วนำความรู้นั้นย้อนกลับไปปรับปรุงวิธีเขียน Prompt ในรอบถัดไป

อีกสิ่งที่ควรทำคือเก็บตัวอย่างจริงของปัญหาที่เคยพบในโค้ด AI ไว้เป็นฐานความรู้ของทีม เช่น เคสที่ AI ลืมตรวจสิทธิ์ หรือเคสที่ AI เพิ่ม Dependency โดยไม่จำเป็น แล้วนำมาเล่าให้สมาชิกใหม่ในทีมฟังก่อนเริ่มรีวิวโค้ด AI ครั้งแรก จะช่วยย่นเวลาที่ทีมต้องเรียนรู้จุดพลาดซ้ำ ๆ ด้วยตัวเองทีละคน

สรุป

โค้ดที่ AI เขียนไม่ได้แย่กว่าหรือดีกว่าโค้ดที่คนเขียนเองเสมอไป แต่มันพลาดคนละแบบ ความน่าเชื่อถือทางสายตาที่โค้ด AI มักมีสูงกว่า ทำให้ผู้ Review ต้องตั้งใจมากขึ้นแทนที่จะลดการ์ดลงเพราะโค้ดดูสะอาด

สิ่งที่ควรทำต่อจากนี้คือทบทวนเทมเพลต Pull Request ของทีมว่ามีหัวข้อเฉพาะสำหรับโค้ดที่มาจาก AI หรือยัง ถ้ายังไม่มี ลองเพิ่มคำถามสั้น ๆ เช่น แตะข้อมูลอ่อนไหวหรือไม่ เพิ่ม Dependency ใหม่หรือไม่ เพื่อให้ผู้ Review รู้จุดที่ต้องโฟกัสตั้งแต่เห็นงานครั้งแรก

• โค้ดที่ AI เขียนต้องตรวจ Security เรื่องสิทธิ์การเข้าถึงข้อมูลเป็นพิเศษ เพราะเป็นจุดที่ AI มักลืมบ่อยที่สุด
• อย่าเชื่อ Test ที่ AI เขียนมาให้ทั้งหมด ต้องอ่านว่ายืนยันผลลัพธ์ที่ถูกต้องจริงหรือแค่ยืนยันว่าไม่พัง
• Dependency ใหม่ทุกตัวที่ AI เพิ่มเข้ามาต้องถูกถามเหตุผล ไม่ใช่ปล่อยผ่านเพราะเชื่อว่า AI เลือกให้ดีที่สุดแล้ว

คำถามที่พบบ่อย