เครื่องมือเขียนโค้ดด้วย AI เปลี่ยนกระบวนการ code review ของทีมคุณอย่างไร?

Question

IT Interview Practice · Accepted Answer

เมื่อ AI เขียนโค้ดสัดส่วนใหญ่ **review กลายเป็น quality gate หลัก — และคอขวดใหม่** กระบวนการเปลี่ยนจากการจับ style/typo ไปเป็นการ **verify เจตนา, ความถูกต้อง, และความปลอดภัยของโค้ดที่ไม่มีมนุษย์เขียนทีละบรรทัด**

**แบบจำลองความคิด:** การ review diff ของ AI เหมือนการ review PR ของจูเนียร์ที่มั่นใจ — มัน *ดู* ถูกต้องแต่อาจผิดแบบแนบเนียน; คุณ review **เหตุผลและเคสขอบ** ไม่ใช่แค่ syntax

## สิ่งที่เปลี่ยนไป

- **ปริมาณและความเร็วสูงขึ้น → review คือคอคอด** ผลักการตรวจราคาถูกไปให้ CI (lint, types, tests, security scan) เพื่อให้มนุษย์ใช้ความสนใจไปกับ design, ความถูกต้อง, และความปลอดภัย
- **โฟกัสย้ายไปที่เจตนาและเคสขอบ** มันแก้ปัญหา *ที่ถูกต้อง* ไหม? จัดการกับ failure ไหม? มีช่องโหว่ความปลอดภัยซ่อนอยู่ไหม (injection, secret รั่ว, dependency ไม่ปลอดภัย, licensing)?
- **ความรับผิดชอบของผู้เขียน** ใครก็ตามที่ submit โค้ด AI ก็ **เป็นเจ้าของ** มัน — "AI เขียนให้" ไม่ใช่ข้อแก้ตัว ผู้เขียน verify และอธิบายมันได้ *ก่อน* ขอ review
- **PR เล็กลง** diff ที่ review ง่ายสำคัญยิ่งขึ้นเมื่อปริมาณ output สูง

## มุมมองของผู้สัมภาษณ์

ผู้สัมภาษณ์ตรวจว่าคุณปฏิบัติต่อ output ของ AI ว่าต้อง review **มากขึ้น** ไหม, automate การตรวจราคาถูกไหม, และคงความรับผิดชอบของมนุษย์ไหม คำตอบที่ **อ่อน**: "โค้ด AI มักจะโอเค เราเลย merge เร็วขึ้น" คำตอบที่ **แข็งแรง**: review คือ gate, CI automate lint/test/security, มนุษย์ review เจตนา + เคสขอบ, และผู้ submit เป็นเจ้าของโค้ด

## Trade-offs

Review เข้มเกินไปลบล้างความเร็วที่ได้มา; หลวมเกินไปสร้างหนี้ด้านคุณภาพ/ความปลอดภัย สร้างสมดุลด้วย **automation + risk-based review** — แตะเบา ๆ สำหรับ boilerplate, review ลึกสำหรับ path ที่อ่อนไหวด้านความปลอดภัย

สิ่งที่เปลี่ยนไป

มุมมองของผู้สัมภาษณ์

Trade-offs

คำถามที่เกี่ยวข้อง