AI agent สามารถสร้าง feature branch ทั้งหมดได้ในเวลาที่คุณดื่มกาแฟเสร็จเพียงแก้วเดียว โค้ดหลายพันบรรทัดปรากฏขึ้นหลังจากเขียน prompt ที่ดีเพียงครั้งเดียว ความเร็วนี้ไม่ได้เปลี่ยนความจริงพื้นฐานที่ว่า: โค้ดที่เข้าสู่ repository ของคุณยังคงต้องการการตัดสินใจจากมนุษย์ การรีวิวไม่ใช่ขั้นตอนการขัดเกลา แต่มันคือปราการกั้นระหว่างซอฟต์แวร์ที่ใช้งานได้จริงกับหนี้ทางเทคนิค (technical debt) ที่จะพอกพูนขึ้นอย่างเงียบเชียบ
ลักษณะของงานได้เปลี่ยนไปแล้ว เมื่อก่อนเราใช้พลังงานสมองไปกับการพิมพ์ logic ลงใน editor ทีละบรรทัด แต่ตอนนี้ภาระทางพุทธิปัญญา (cognitive load) ได้เปลี่ยนไปแล้ว ส่วนที่ยากไม่ใช่การเขียนโค้ดอีกต่อไป แต่มันคือการอ่าน การตั้งคำถาม และการตัดสินใจว่าโค้ดนั้นควรจะอยู่ในระบบของคุณจริงๆ หรือไม่
การเปลี่ยนแปลงนี้ต้องการแนวทางการทำ code review ที่แตกต่างออกไป และนี่คือวิธีที่ทีมควรปรับตัว
เป็นเจ้าของโค้ดก่อนที่ใครคนอื่นจะเห็นมัน
คุณต้องรีวิวโค้ดที่สร้างโดย AI ราวกับว่ามีคนแปลกหน้าส่งโค้ดนั้นเข้ามาใน branch ของคุณ ความแตกต่างนี้สำคัญมาก เมื่อคุณเขียนทุกบรรทัดด้วยมือ คุณจะเข้าใจบริบทโดยธรรมชาติ คุณรู้ว่าทำไม loop นั้นถึงเริ่มที่หนึ่งแทนที่จะเป็นศูนย์ แต่ตอนนี้คุณเปรียบเสมือน tech lead ที่ต้องคอยแนะนำผู้รับเหมาที่กระตือรือร้นเกินเหตุ ซึ่งทำงานเร็วอย่างไม่น่าเชื่อแต่ไม่เคยถามคำถามเพื่อความชัดเจนเลย
นั่นทำให้การทำ self-review กลายเป็นด่านที่สำคัญที่สุดในกระบวนการของคุณ ก่อนที่คุณจะสร้าง pull request ให้ถอยออกมาหนึ่งก้าวแล้วตั้งคำถามที่ยากๆ กับตัวเอง
โค้ดนั้นเคารพสถาปัตยกรรม (architecture) ของคุณหรือไม่? โค้ดที่ถูกสร้างขึ้นมักจะนำรูปแบบ (patterns) จากข้อมูลที่ใช้เทรนมาใช้ ซึ่งอาจไม่ตรงกับข้อกำหนด (conventions) ของคุณ มันอาจจะสร้าง service ใหม่ขึ้นมา ทั้งที่ทีมของคุณตกลงกันว่าจะเก็บ logic ไว้ใน monolith หรือมันอาจจะละเลยมาตรฐานการทำ logging ภายในของคุณ แล้วไปใช้คำสั่ง print ธรรมดาแทน
มันแก้ปัญหาได้ตรงจุดหรือไม่? โมเดล AI ถูกปรับแต่งมาเพื่อให้ทำตาม prompt ให้สำเร็จ ไม่ใช่เพื่อให้เข้าใจกรณีขอบเขต (edge cases) ของ ticket หาก issue ของคุณระบุถึงการจัดการการคืนเงินบางส่วน (partial refunds) โค้ดที่ถูกสร้างขึ้นอาจครอบคลุมแค่กรณีปกติ (happy path) และทิ้งความล้มเหลวในการกระทบยอด (reconciliation failure) ให้เป็นหน้าที่ของผู้ใช้งานจัดการเอง
งานเดียวกันนี้สามารถทำได้ด้วยโค้ดที่น้อยกว่านี้หรือไม่? AI มักจะมีแนวโน้มที่จะเขียนโค้ดเยิ่นเย้อ (verbosity) มันมักจะเขียน defensive wrappers, คอมเมนต์ที่ซ้ำซ้อน และการจัดการ error ที่ซับซ้อนจนบดบัง logic ที่แท้จริง จงมองหาวิธีการที่ทำซ้ำโครงสร้างเดิม, การ import ที่ไม่มีประโยชน์ หรือตัวแปรที่ไม่เคยมีการเปลี่ยนแปลงค่า (mutate) จงตัดส่วนเกินออกไป หากคุณสั่งให้ agent ทำการ simplify และ refactor คุณก็จะเรียนรู้วิธีการควบคุมมันด้วย คุณจะค้นพบว่าข้อจำกัดแบบไหนที่ช่วยตัดส่วนที่ไม่จำเป็นออกไป การปรับแต่งซ้ำๆ แบบนี้คือส่วนหนึ่งของงานคุณในตอนนี้ เพราะ pull request นั้นมีชื่อของคุณกำกับอยู่ คุณต้องรับผิดชอบในทุกบรรทัด
ให้เครื่องจักรช่วยสแกน แต่ต้องใช้สมองของคุณในการตัดสินใจ
เครื่องมือรีวิวอัตโนมัติควรอยู่ใน CI pipeline ของคุณ เครื่องมือรีวิวที่ขับเคลื่อนด้วย AI สมัยใหม่สามารถแจ้งเตือนความเสี่ยงด้านความปลอดภัย เช่น ช่องโหว่จากการฉีดคำสั่ง (injection vulnerabilities), ตรวจพบ edge cases ที่ยังไม่ได้รับการจัดการ และตรวจพบ dependencies ที่ล้าสมัยก่อนที่จะถูกนำไปใช้ใน production เครื่องมือเหล่านี้ขยายขอบเขตการทำงานได้ดีและไม่รู้จักเหน็ดเหนื่อย
จงใช้พวกมัน แต่อย่าไปเทิดทูนพวกมัน
เครื่องมือเหล่านี้ขาดบริบททางธุรกิจ (business context) เครื่องมือรีวิวอัตโนมัติอาจระบุว่าการ query ฐานข้อมูลมีความเสี่ยงเพราะใช้การต่อสตริง (string concatenation) โดยไม่รู้ว่า middleware ของคุณได้จัดการเรื่องการทำ sanitization ไว้ที่เลเยอร์อื่นแล้ว หรือมันอาจจะแนะนำให้เขียน algorithm ที่ปรับแต่งเองใหม่โดยใช้ library call โดยไม่รู้ว่า library เวอร์ชันที่คุณใช้อยู่นั้นมีการเปลี่ยนแปลงที่อาจทำให้ระบบพัง (breaking change) คำแนะนำเหล่านี้เป็นเพียงการคาดเดาอย่างมีหลักการตามรูปแบบที่พบ ไม่ใช่ความรู้ที่หยั่งรากลึกในผลิตภัณฑ์ของคุณ
อ่านคำแนะนำอย่างละเอียดเสมอ แล้วค่อยตัดสินใจ จงปฏิบัติกับคอมเมนต์อัตโนมัติในฐานะ "สัญญาณ" ไม่ใช่ "คำสั่ง"
นอกจากนี้ยังมีแง่มุมในทางปฏิบัติ