การรีวิวโค้ดแบบเอเจนติก

• เมื่อความสามารถของ coding agent พุ่งขึ้นอย่างรวดเร็ว จุดที่ยากของงานวิศวกรรมก็ย้ายจาก การเขียนโค้ด ไปเป็น การตัดสินใจว่าจะเชื่อถือโค้ดนั้นได้หรือไม่ ทำให้ การรีวิวกลายเป็นงานที่มีเลเวอเรจสูงที่สุด
• AI เพิ่มปริมาณผลลัพธ์ได้อย่างมาก แต่กลับลดคุณภาพและความสามารถในการรีวิวลง จึงวัดพบช่องว่างที่ว่า โค้ดเพิ่มขึ้น 4 เท่า แต่คุณค่าจริงเพิ่มเพียงราว 10%
• ความเข้มข้นของการรีวิวที่ต้องใช้แตกต่างกันตาม blast radius (ขอบเขตผลกระทบ) ของการเปลี่ยนแปลง โดยนักพัฒนาเดี่ยวกับทีมดูแลระบบขนาดใหญ่ที่มีอายุ 10 ปี มีข้อจำกัดคนละแบบโดยสิ้นเชิง
• เอเจนต์มีการให้เหตุผล แต่เหตุผลนั้นไม่ได้แนบมากับ PR และถูกทิ้งไป ทำให้ผู้รีวิวต้องแบกรับภาระในการ สร้างเจตนา (intent) ที่หายไปขึ้นมาใหม่ตั้งแต่ต้น
• การเขียนถูกลงแล้ว แต่การทำความเข้าใจยังแพงเหมือนเดิม ดังนั้นทีมที่สร้าง ระบบรีวิวที่เชื่อถือได้ จะได้เปรียบในอนาคต

---

สิ่งที่ข้อมูลปี 2026 แสดงให้เห็นจริง ๆ

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

• การวัดของ Faros AI (ข้อมูลเดือนมีนาคม 2026)

  • ติดตามการเปลี่ยนผ่านจากการใช้ AI ต่ำไปสู่การใช้ AI สูงใน 4,000 ทีม นักพัฒนา 22,000 คน
  • ด้านบวก: นักพัฒนา merge PR ได้มากขึ้นและปิดงานได้มากขึ้น throughput ต่อวิศวกรสูงขึ้น
  • ตัวเลขด้านลบ
    • code churn เพิ่มขึ้น 861%
    • อัตรา incident ต่อ PR เพิ่มขึ้น 242.7%
    • อัตราข้อบกพร่องต่อคนพัฒนา จาก 9% → 54%
    • เวลารีวิวมัธยฐาน เพิ่มขึ้น 441.5% (ทั้งเวลาถึงรีวิวแรกและเวลารีวิวเฉลี่ยเพิ่มเกือบ 2 เท่า)
    • PR ที่ merge โดยไม่มีรีวิวเพิ่มขึ้น 31.3%
  • การ merge โดยไม่มีรีวิวไม่ใช่สิ่งที่ใครเลือก แต่เป็นผลจากการที่ผู้รีวิวตามปริมาณงานไม่ทัน จน การ merge โค้ดที่ไม่มีใครอ่านกลายเป็นเรื่องปกติ
  • แม้แต่ทีมที่มีแนวปฏิบัติด้านวิศวกรรมที่สุกงอมและมีวินัยก็โดนผลกระทบเหมือนกัน กระบวนการที่ดีป้องกันไม่ได้ (เพราะปริมาณงานเข้ามาเร็วกว่าอัตราที่จะออกแบบกระบวนการได้ทัน)

• งานวิจัยของ CodeRabbit (ธันวาคม 2025)

  • วิเคราะห์โอเพนซอร์ส PR 470 รายการ (ร่วมเขียนโดย AI 320, มนุษย์ล้วน 150) พบว่าการเปลี่ยนแปลงจาก AI มี ปัญหามากกว่าราว 1.7 เท่า
    • ปัญหาด้าน logic และความถูกต้องเพิ่มขึ้นราว 75%
    • ปัญหาด้านความปลอดภัยเพิ่มขึ้น 1.5~2 เท่า
    • ปัญหาด้านความอ่านง่ายเพิ่มขึ้นมากกว่า 3 เท่า
  • David Loker ผู้อำนวยการด้าน AI กล่าวว่า "มันเป็นจุดอ่อนที่คาดการณ์และวัดได้ และองค์กรต้องบรรเทาอย่างจริงจัง" — เพราะเป็นจุดอ่อนที่รู้แล้วและระบุตำแหน่งได้ จึงสามารถออกแบบกระบวนการรีวิวให้เล็งเป้าได้ตรง

• ข้อมูลผลิตภาพของ GitClear (ถึงปี 2025)

  • ผู้ใช้ที่ใช้ AI ทุกวันมี ผลผลิตดิบมากกว่าราว 4 เท่า เมื่อเทียบกับผู้ไม่ใช้ แต่เมื่อเทียบกับตัวเองเมื่อ 1 ปีก่อน ผลิตภาพจริงเพิ่มขึ้นเพียงราว 12%
  • โครงสร้างยังคงเป็นแบบที่มนุษย์ต้องรีวิวโค้ดมากขึ้น 4 เท่าทั้งหมด
  • Bill Harding ระบุชัดว่าแม้แต่ 12% นั้น ส่วนหนึ่งอาจมาจาก selection bias (นักพัฒนาที่เก่งกว่าไปรวมอยู่ในกลุ่มใช้ AI)

• รายงานของ GitHub

  • Copilot review ถูกใช้งานสะสม มากกว่า 60 ล้านครั้ง เพิ่มขึ้น 10 เท่าใน 1 ปี และมากกว่า 1 ใน 5 ของรีวิวบนแพลตฟอร์มมีเอเจนต์เข้ามาเกี่ยวข้อง
  • มันไม่ใช่วิธีปฏิบัติเฉพาะกลุ่มอีกต่อไป แต่เป็นวิธีที่โค้ดถูกสร้างขึ้นจริง
• ข้อมูล 4 ชุดและวิธีวิทยา 4 แบบกำลังบรรจบสู่ข้อสรุปเดียวกัน คือคอขวดไม่ได้หายไป แต่ ย้ายไปอยู่ที่ขั้นตอน verification

ทุกคนกำลังแก้ปัญหาคนละแบบ

• ข้อมูลเตือนภัยส่วนใหญ่ข้างต้นมาจาก enterprise telemetry และผู้ดูแลโอเพนซอร์สที่ถูกงานท่วม ซึ่งจำนวนมากไม่ตรงกับนักพัฒนาเดี่ยวที่กำลังสร้างของที่มีคนใช้น้อย

• ตัวแปร 3 ตัวที่กำหนดตำแหน่งของคุณ

  • blast radius: ถ้าพังแล้วจะเกิดอะไรขึ้น — อาจไม่เกิดอะไรเลย หรือเกิดผู้ใช้โกรธ สูญเสียเงิน หรือข้อมูล PII รั่วไหล
  • อายุของโค้ด: เป็น prototype ใช้ครั้งเดียวแล้วสัปดาห์หน้าก็ไม่แตะอีก หรือเป็น codebase ที่ต้องดูแลไปอีกหลายปี
  • จำนวนคนที่ต้องเข้าใจมัน: มีแค่ตัวคุณที่เก็บทั้งหมดไว้ในหัว หรือเป็นทีมที่แชร์ความเป็นเจ้าของกันตามกาลเวลา

• เดี่ยว, greenfield, ไม่มีผู้ใช้

  • บทบาทที่สองของการรีวิว คือการกระจายความรู้ในทีม ไม่มีอยู่จริง (เพราะคุณก็คือทีม)
  • ทางเลือกที่สมเหตุสมผลคือ พึ่งพา test และ automation อย่างมาก รีวิวเฉพาะส่วนที่สำคัญจริง ๆ ที่เหลือแตะเบา ๆ
  • แต่จะใช้ได้ก็ต่อเมื่อ test นั้นเป็นของจริง หากข้ามรีวิวไปโดยไม่มีตาข่ายนิรภัย งานไม่ได้หายไป แต่ ถูกเลื่อนไปจ่ายทีหลังด้วยต้นทุนที่แพงกว่า (defer)
  • "ไม่มีผู้ใช้" คือการอนุญาตให้เลื่อนการรีวิว ไม่ใช่อนุญาตให้ข้ามการตรวจสอบ

• จุดกึ่งกลางที่อันตราย

  • ทันทีที่โปรเจกต์เริ่มมีผู้ใช้ บทบาทการจับบั๊กจะสำคัญขึ้นทันที (เพราะบั๊กเริ่มทำร้ายคนจริง) และบทบาทการแชร์ความรู้ก็เปิดขึ้นด้วย
  • ถ้าทีมยังคงนิสัยแบบตอนทำคนเดียวต่อไปอีกหลายเดือนจนต้องมาทำ postmortem ตัวเลขของ Faros จะกลายเป็น dashboard ของทีมเอง

• องค์กรขนาดใหญ่, codebase เก่า, ผู้ใช้จำนวนมาก

  • ตัวเลขเตือนทั้งหมดจะมีผลเต็มแรง การเปลี่ยนแปลงที่ไม่มีใครเข้าใจจะกลายเป็น comprehension debt (หนี้ด้านความเข้าใจ) และสุดท้ายไปโผล่เป็น incident ตอน on-call ของใครบางคน
  • ประเด็นไม่ใช่ "องค์กรต้องระวัง ส่วนคนเดียวชิลได้" แต่คือ เป้าหมายของการรีวิวเปลี่ยนไปตามตำแหน่งของคุณ ดังนั้นกติกาก็ต้องเปลี่ยนด้วย
  • ถ้าเอา pipeline แบบ enterprise ที่มีหลายเอเจนต์และต้องมีหลักฐาน ไปใส่กับ prototype สองคนทำ ก็จะเกิดแรงเสียดทานไร้ประโยชน์ แต่ถ้าใช้แนวคิด "test ผ่านก็ deploy" กับระบบชำระเงิน ก็เท่ากับสร้างเครื่องผลิต incident ที่มีเครื่องหมายถูกสีเขียว

ตอนนี้การรีวิวทำหน้าที่อะไรจริง ๆ

• เวลามนุษย์เขียนโค้ด เจตนาจะติดมาฟรี ๆ และตัวเลือกอื่นที่ชั่งน้ำหนักแล้วทิ้งไปก็ยังอยู่ในหัวของผู้เขียน ดังนั้นการรีวิวเดิมทีคือการตรวจสอบเหตุผลนั้น
• เอเจนต์สมัยใหม่ก็ให้เหตุผลเช่นกัน และบางครั้งก็แสดง thinking trace ให้เห็น แต่เมื่อ diff ถูกสร้างขึ้น เหตุผลนั้นจะถูกทิ้งและไม่ได้แนบมากับ PR
• ยิ่งไปกว่านั้น สิ่งนั้นคือเหตุผลของเอเจนต์ในเรื่อง "จะ implement อย่างไร" ไม่ใช่การตัดสินของมนุษย์ในเรื่อง "นี่เป็นงานที่ถูกต้องตั้งแต่แรกหรือไม่"
• ผลคือการรีวิวเปลี่ยนจากการตรวจสอบเหตุผลที่อยู่ตรงหน้า ไปเป็น การสร้างเจตนาที่ไม่ได้ถูกบันทึกไว้ขึ้นมาใหม่ ทำให้ยากและช้ากว่าเดิม (ซึ่งอธิบายว่าทำไมจึงใช้เวลามากขึ้น 441%)

• AI Slop and the Software Commons (งานวิจัยปี 2026)

  • วิเคราะห์โพสต์ 1,154 รายการจาก 15 เธรดใน Reddit และ Hacker News
  • นักพัฒนาคนหนึ่งอธิบายว่าการรีวิว PR ของเอเจนต์ทำให้เขากลายเป็น "มนุษย์คนแรกที่ได้เห็นโค้ดนี้"
  • ในคำของงานวิจัย การรีวิว "ไม่ได้ถูกออกแบบมาเพื่อกู้คืนเจตนาที่หายไป"

• ทางแก้คือปัญหาด้านเครื่องมือ

  • เจตนาที่หายไปกู้คืนได้ — เพราะการให้เหตุผลนั้นมีอยู่ เพียงแต่ถูกทิ้งไป
  • ถ้าให้เอเจนต์อธิบายว่าตั้งใจทำอะไรและตัดอะไรทิ้งไปบ้าง แล้วเก็บไว้เป็น decision log (บันทึกการตัดสินใจ) ของ PR ต้นทุนในการสร้างความเข้าใจใหม่ส่วนใหญ่ก็จะหายไป
• การให้ "AI รีวิว AI" เพียงอย่างเดียวไม่ใช่คำตอบครบถ้วน แม้โมเดลตัวที่สองซึ่งมีความรู้พื้นหลังต่างกันจะจับบั๊กจริงได้มาก แต่ก็ยังให้ การตัดสินแบบมนุษย์ว่า "การเปลี่ยนแปลงนี้คุ้มค่าจะสร้างหรือไม่" ไม่ได้

เครื่องมือดีขึ้นแล้ว แต่ไม่ใช่เพราะเหตุผลที่โฆษณา

• เครื่องมือรีวิว AI เฉพาะทางตอนนี้ดีพอแล้ว และแนะนำว่าควรให้ทุกอย่างรวมถึง side project มีอย่างน้อย main coding agent ทำงานอยู่ (ถ้าเป็นไปได้ก็มี review agent เฉพาะทางด้วย)

• ลักษณะของเครื่องมือหลัก

  • CodeRabbit: ถูกใช้งานแพร่หลายที่สุด, ได้ F1 อันดับ 1 ใน Martian benchmark อิสระ (มกราคม~กุมภาพันธ์ 2026), precision ราว 49% และมี recall สูงสุดในอุตสาหกรรม
  • Greptile: ยอม precision เพื่อเอา recall ใน benchmark หนึ่งมีอัตราตรวจพบบั๊กราว 82% (เทียบกับ CodeRabbit 44%) แต่มี false positive มากกว่า
  • Anthropic Code Review: ผลลัพธ์ที่วิศวกรภายในระบุว่าผิดพลาดมีน้อยกว่า 1% และเพิ่มสัดส่วน PR ที่ได้รับการรีวิวจริงจาก 16% เป็น 54%

• การทดลองรันผู้รีวิว 4 ตัวแบบขนาน (ผลจากภายนอก vendor)

  • วิศวกรคนหนึ่งรัน CodeRabbit, Sentry Seer, Greptile และ Cursor BugBot แบบขนานกับ PR จริง 146 รายการตลอด 3 สัปดาห์ครึ่ง เจอสิ่งที่ต้องชี้รวม 679 รายการ
  • จากจุดที่ถูก flag แบบไม่ซ้ำกัน 617 จุด มี 93.4% ที่ถูกจับโดยเครื่องมือเพียงตัวเดียวเท่านั้น 6% ถูกจับโดยสองตัว สามตัวแทบไม่มี และ ไม่มีกรณีที่ทั้งสี่ตัวจับพร้อมกัน
  • ไม่มีครั้งไหนเลยที่ทั้งสี่เครื่องมือจะ flag บรรทัดเดียวกันพร้อมกัน
  • แต่ละตัวมีจุดแข็งต่างกัน: Greptile แทบไม่มี false positive ในด้านความถูกต้องและสถาปัตยกรรม, CodeRabbit มีตาข่ายกว้างที่สุดและแก้แบบ one-click ได้, Seer เด่นเรื่องความรุนแรงของปัญหาฝั่ง production
  • สิ่งสำคัญคือความหลากหลาย (heterogeneity) — ถ้าเป็นโมเดลตัวเดียวกัน 4 ชุด มันก็แค่ผู้รีวิวคนเดียวที่ค่าใช้จ่ายสูงขึ้น แต่ถ้าเป็นผู้รีวิว 4 แบบที่ต่างกันจริง จะเจอบั๊กที่ไม่มีตัวไหนหาได้ครบเพียงลำพัง

• แนวทางใช้งานจริง

  • อย่าเสียเวลาคิดว่าเครื่องมือไหนดีที่สุดเพียงตัวเดียว (ไม่มีแบบนั้น)
  • ในพื้นที่ความเสี่ยงสูง ให้ตั้งใจใช้สองตัวที่นิสัยต่างกันควบคู่กัน (การทดลองข้างต้นใช้ Greptile สำหรับความถูกต้องทั่วไป + Seer สำหรับความรุนแรงของปัญหา production)
  • ถ้าทำคนเดียว ผู้รีวิวที่ดีสักตัวกับ test ที่เป็นของจริงก็เพียงพอ
  • โดยไม่เกี่ยวกับการตลาด ต้องวัดบนโค้ดของตัวเองเสมอ เพราะผลลัพธ์ทั้งหมดผูกกับ codebase เฉพาะ

ควรให้ AI รับภาระการรีวิวมากขึ้นหรือไม่

• คำถามที่เมื่อ 1 ปีก่อนคงถูกมองว่านอกรีต ตอนนี้กลับถูกถามโดยวิศวกรที่มีประสบการณ์ — เครื่องจักรควรรับภาระรีวิวมากขึ้น หรืออาจถึงขั้นส่วนใหญ่เลยหรือไม่

• ความจริงที่ชวนอึดอัดว่า AI review ใช้งานได้

  • สิ่งที่ Anthropic พบมีน้อยกว่า 1% เท่านั้นที่ถูกระบุว่าเป็นข้อผิดพลาด มันจับบั๊กที่คนพลาด และไม่เหนื่อยแม้จะเป็น PR ที่ 30 ของวัน (ซึ่งเป็นช่วงที่มนุษย์ไว้ใจได้น้อยที่สุด)
  • ตรงกันข้าม มนุษย์ตามไม่ทัน — การ merge แบบไม่มีรีวิวเพิ่มขึ้น 31% และเวลารีวิวเพิ่มขึ้นระดับสามหลัก
  • กรอบที่ซื่อตรงกว่าคือไม่ใช่ "ควรให้ AI ทำมากขึ้นไหม" แต่คือ "AI กำลังทำอยู่แล้ว และคำถามคือเราจะ ทำอย่างตั้งใจ หรือจะปล่อยให้เป็นสภาพที่คนแกล้งทำเหมือนอ่านครบทุกอย่าง**"

• มุมมองของ loop engineering

  • สมมติฐานของแนวคิดนี้คือย้ายจากคนที่ป้อน prompt ให้เอเจนต์ ไปเป็น ระบบที่ป้อน prompt ให้เอเจนต์ โดยมี judge agent ที่ตัดสินว่างานเสร็จหรือยังเป็นแกนกลาง
  • ผู้รีวิวจึงกลายเป็นบทบาทถัดไปที่ถูกถอดออกจาก internal loop อย่างตั้งใจ ถัดจากการทำให้การเขียนเป็นอัตโนมัติ อีก 1 ปีต่อมาการตรวจสอบก็จะเป็นอัตโนมัติด้วย และมนุษย์ถูกดันขึ้นไปอยู่ระดับบนกว่าเดิม

• ความเสี่ยงของวงจรปิด

  • ถ้าเอเจนต์ตัวหนึ่งเขียน อีกตัวรีวิว แล้วตัวที่สามตัดสิน ก็จะเกิดวงจรปิดของโมเดลที่มี จุดบอดร่วมกัน (correlated blind spots) โดยเฉพาะถ้าเป็นตระกูลเดียวกันก็ยิ่งมีแนวโน้มจะเห็นตรงกันอย่างมั่นใจในจุดเดียวกัน
  • คำว่า "looks good" ที่มั่นใจโดยไม่มีมนุษย์เกี่ยวข้องเลยคือ ความมั่นใจที่ยืมมา (borrowed confidence) — ความมั่นใจของระบบกลายเป็นความมั่นใจของเรา ทั้งที่จริงแล้วไม่มีใครเข้าใจมันจริง

• มนุษย์ไม่ได้หายไป แต่เลื่อนขึ้นไปอีกชั้น

  • บทบาทเปลี่ยนจากการอ่านทุก diff ไปเป็นการถือครองส่วนที่ถ่ายโอนไปให้โมเดลไม่ได้ โดยมีความรับผิดชอบ (accountability) เป็นเรื่องสำคัญ
  • พื้นที่ที่มนุษย์ต้องเฝ้าไว้คือ: การตัดสินว่านี่คือการเปลี่ยนแปลงที่ถูกต้องจะทำหรือไม่, gate สำหรับงานที่มี blast radius สูงและพลาดแล้วแพง, และพฤติกรรมที่ไม่มีใครเขียนเป็นสเปกไว้ (เพราะโมเดลรีวิวได้แค่โค้ดที่มีอยู่ และแทบจะ flag ข้อกำหนดที่ไม่มีใครเขียนไว้ไม่ได้)
  • จาก human in the loop ไปสู่ human on the loop — แทนที่จะอ่านทุก PR มนุษย์จะคอยสุ่มตรวจ, spot-check, audit ระบบ และทุ่มความสนใจที่มีจำกัดไปยังจุดที่ถ้าพลาดแล้วเจ็บจริง

• กรณีของ Kun Chen (อดีตวิศวกร Meta ระดับ L8, นักสร้างเดี่ยว)

  • ปล่อย PR ราววันละ 40 รายการ และแทบหยุดทำ code review แบบเดิม รันเอเจนต์ 20~30 ตัวขนานกัน
  • เขาย้ายแรงไปไว้ที่ แผน (plan) — เขียนแผนละเอียดล่วงหน้า จากนั้นปล่อยให้เอเจนต์ทำงานหลายชั่วโมง คุณภาพของแผนเป็นตัวกำหนดว่าจะปล่อยอัตโนมัติได้นานแค่ไหน
  • เขาไม่ได้หยุดการตรวจสอบ แต่เขียนเจตนาไว้ก่อนด้วยตัวเอง ทำให้ปัญหา "มนุษย์คนแรกที่เห็นโค้ด" เบาลงครึ่งหนึ่ง (มนุษย์เข้าใจเหตุผลตั้งแต่ก่อน ไม่ใช่มาไล่เดาหลังจากนั้น)
  • เขาไม่ได้ทำงานโดยไม่มีตาข่ายนิรภัย — มี auto review gate ที่เรียกว่า No Mistakes คอยตรวจโค้ดก่อน merge และถ้าเอเจนต์ติดขัดก็รอการ escalate
  • แต่เขาเป็นนักสร้างเดี่ยว ไม่มีทั้งทีมใหญ่และระบบเก่าที่เต็มไปด้วยทุ่นระเบิด ดังนั้นเงื่อนไขของเขาไม่เหมือนคนอ่านส่วนใหญ่ — ถ้าเอาไปคัดลอกใช้กับทีมที่มีผู้ใช้จำนวนมาก ก็จะได้ตัวเลขแบบ Faros ปรากฏบน dashboard ของตัวเอง
• ข้อสรุปตามสเปกตรัมคือ: ถ้าทำคนเดียวและไม่มีผู้ใช้ การให้ AI ทำแทบทั้งหมดถือเป็นจุดยืนที่พอป้องกันได้ในปี 2026; แต่ถ้าเป็นระบบใหญ่และมีผู้ใช้มาก first pass, second pass และ 90% ของงานน่าเบื่อควรให้เครื่องทำ แต่ เส้นทางที่รับน้ำหนักระบบจริง (load-bearing paths) ยังต้องมีมนุษย์อยู่ และจำนวนมนุษย์ที่ต้องใส่ไม่ควรถูกกำหนดด้วยความรู้สึกผิด แต่กำหนดด้วย blast radius

แล้วควรทำอะไรจริง ๆ

• หลักการระดับองค์กรคือ: จับคู่ความพยายามในการรีวิวกับ ต้นทุนเมื่อผิดพลาด, ดึงงาน deterministic ราคาถูกมาไว้ข้างหน้าให้มากที่สุด และเก็บความสนใจของมนุษย์ไว้สำหรับงานที่มีแต่มนุษย์เท่านั้นที่ทำได้

• แบ่งชั้นตามความเสี่ยง ไม่ใช่ตามผู้เขียน (Tier by risk, not by author)

  • การเปลี่ยน config ใช้ linter กับการไล่ดูรอบเดียวก็พอ
  • การแก้เส้นทาง business logic หลักต้องใช้ชุดเต็ม: type, test, AI reviewer สองตัวที่ต่างกัน, มนุษย์เจ้าของระบบนั้น, และ security pass
  • อย่าใช้รีวิวหนักกับ boilerplate และอย่าให้การเปลี่ยนแปลงใหญ่ผ่านเพียงเพราะ test เป็นสีเขียว

• ตัดหางที่แพงให้เร็ว (Fast-fail the expensive tail)

  • งานวิจัย Early-Stage Prediction of Review Effort (มกราคม 2026) ศึกษา PR ที่เขียนโดยเอเจนต์ 33,707 รายการ
  • เอเจนต์เก่งกับการเปลี่ยนแปลงเล็กและนิยามชัด ทำให้ราว 28% ถูก merge แทบจะทันที แต่ทันทีที่เจอ feedback เชิงอัตวิสัย มันมักจะ "หายตัว (ghost)" และเลิกเล่นเกมตอบโต้ไปมา ซึ่งเป็นหัวใจของการรีวิว
  • ในงานวิจัยประกอบปี 2026 พบว่า reviewer dropout คิดเป็น 38% ของ agent PR ที่ถูกปฏิเสธ
  • นักวิจัยจึงสร้าง "circuit breaker" ที่ใช้สัญญาณราคาถูกอย่างชนิดไฟล์และขนาดแพตช์ เพื่อทำนาย PR ที่จะมีต้นทุนดูแลสูงก่อนให้มนุษย์เข้ามาดู และมันใช้ได้ผลดี

• ยกระดับเกณฑ์ว่าอะไรจึงคุ้มให้รีวิว

  • ทางแก้ไม่ใช่การล็อก repository แต่คือ ปฏิเสธการรีวิวการเปลี่ยนแปลงที่มาถึงโดยไม่มีหลักฐาน
  • สิ่งที่ต้องมีก่อนรีวิว: คำอธิบายจุดประสงค์ของการเปลี่ยนแปลง, diff ที่อ่านรู้เรื่องไม่ใช่ไฟล์ยาว 3,500 บรรทัดไร้คำอธิบาย, output ของ test, และหลักฐานว่าได้รันจริง
  • แทนที่คุณจะดูดซับงานแพงอย่างการสร้างเจตนาใหม่ไว้กับตัวเอง ก็โยนกลับไปให้ผู้ส่งซึ่งสามารถทำได้ถูกกว่า

• จงทำให้ PR เล็กอย่างตั้งใจ

  • PR จากเอเจนต์มีแนวโน้มใหญ่กว่า (ข้อมูล Faros พบว่าเฉลี่ย ใหญ่ขึ้น 51%) และการมีส่วนร่วมของผู้รีวิวเป็นหนึ่งในตัวทำนายที่แรงที่สุดว่า PR จะถูก merge หรือไม่
  • PR ที่ใหญ่และรีวิวไม่ได้ ควรถูกปฏิเสธทันที หรือแย่กว่านั้นคือถูก rubber-stamp ผ่านไป
  • สั่งเอเจนต์ให้สร้าง commit เล็ก ๆ diff ที่มนุษย์อ่านได้ตอนนี้ไม่ใช่แค่เรื่องมารยาท แต่เป็น ข้อจำกัดด้านการออกแบบ

• อ่านการเปลี่ยน test ให้ละเอียดกว่าการเปลี่ยนโค้ด

  • failure mode ของเอเจนต์ที่ต้องระวังคือ: เปลี่ยนพฤติกรรมแล้วไปเขียน assertion ใหม่ให้เข้ากับพฤติกรรมที่พังนั้น เพื่อ "ซ่อม" test
  • เครื่องหมายถูกสีเขียวบน test ที่แก้ไป 200 จุดไม่มีความหมาย จนกว่าจะยืนยันได้ว่าการแก้นั้นถูกต้อง diff ที่มีการเขียน test ใหม่จำนวนมากควรถูก flag แล้วอ่านก่อน
  • คุณค่าของ mutation testing คือ coverage บอกแค่ว่าบรรทัดนั้นถูกรันหรือไม่ แต่ mutation test บอกว่าเมื่อบรรทัดนั้นผิด test จะรู้ตัวหรือไม่

• ปฏิบัติกับ CI เหมือนกำแพงที่ขยับไม่ได้

  • จับตาแพตเทิร์นที่ GitHub เตือนผู้รีวิวไว้: test ที่ถูกลบ, lint ที่ถูกข้าม, threshold ของ coverage ที่ถูกลด, helper ที่ซ้ำทั้งที่มีอยู่แล้ว, และ input ที่ไม่น่าเชื่อถือซึ่งไหลเข้า prompt
  • ข้อสุดท้ายสำคัญเป็นพิเศษ — ฟีเจอร์ที่เอเจนต์สร้างขึ้นคือแหล่งกำเนิดใหม่ของ prompt injection ถ้าส่งข้อความที่ผู้ใช้ควบคุมได้เข้า LLM call ตรง ๆ ช่องโหว่จะไม่โผล่ใน diff แต่จะไปซ่อนอยู่ในข้อมูลที่เข้ามาทีหลัง
  • เอเจนต์มักทำให้ CI อ่อนลงได้โดยไม่เจตนาหากนั่นเป็นทางที่ถูกที่สุดในการผ่าน (เพราะ gradient descent จะหาทางที่ไปถึงสีเขียวถูกที่สุด) และ deterministic gate คือส่วนเดียวที่ประโยคมั่นใจสวยหรูไม่สามารถพลิกผลตัดสินได้ ดังนั้นต้องทำให้เข้มงวด

• การ merge ต้องมีมนุษย์เป็นเจ้าของ

  • โมเดลไม่สามารถถูกเรียกตัว (page) และไม่สามารถรับผิดชอบได้ ดังนั้นคนที่กดปุ่ม merge ต้องเป็นเจ้าของ
  • เมื่อ AI review พูดด้วยน้ำเสียงนิ่งและมั่นใจว่า "looks good" มันกำลังส่งต่อความมั่นใจที่ยังไม่ได้รับมาเสมอ
  • จงปฏิบัติกับ AI review ทุกครั้งในฐานะ sensor ไม่ใช่คำตัดสิน — เป็นข้อมูล ไม่ใช่การตัดสินใจ

ถ้าคุณบริหารทีม เรื่องนี้หมายความว่าอะไร

• ข้อจำกัดหลักของการส่งมอบไม่ใช่อีกต่อไปว่าเขียนโค้ดได้เร็วแค่ไหน แต่คือ คนที่องค์กรเชื่อถือได้จะมั่นใจในความถูกต้องของการเปลี่ยนแปลงได้เร็วแค่ไหน
• แผนที่มองว่าการสร้างคือคอขวดและมองว่าการรีวิวฟรี จะกลายเป็นสภาพที่ dashboard ความเร็วเป็นสีเขียวแต่ระบบค่อย ๆ ชะงักโดยเงียบ ๆ
• รายงานของ Faros ระบุชัดว่าแม้ผลผลิตจะเพิ่มขึ้น แต่งาน QA และงานรีวิวก็เพิ่มขึ้นตาม ดังนั้นการลดจำนวนคนในทีมวิศวกรรมด้วยเหตุผลว่า "AI ทำให้เราเร็วขึ้น" ก่อนจะปิดช่องว่างด้านรีวิวได้ ถือว่าเสี่ยง
• ภาษีวิศวกรอาวุโส ในรูปของเวลารีวิวที่เพิ่มขึ้นระดับสามหลัก จะตกหนักที่สุดกับคนที่ไม่ควรถูกทำให้เป็นคอขวดมากที่สุด และตัวชี้วัดที่นับแค่ PR ที่ merge แล้วจะมองไม่เห็นสิ่งนี้
• ผู้ดูแลโอเพนซอร์สคือกลุ่มที่ชนกำแพงนี้ก่อนและแรงที่สุด — กระแส contribution ที่ดูน่าเชื่อแต่กลวงเปล่าจะกินเวลาคัดกรองจริง แม้จะมาด้วยเจตนาดี และนี่คือสัญญาณเตือนแรก ส่วนองค์กรธุรกิจจะเป็นรายถัดไป
• องค์กรที่รับมือได้ดีจะไม่มอง capacity การรีวิวว่าเป็นพื้นที่ว่างที่ AI ปลดล็อกให้ แต่จะมองว่าเป็น ทรัพยากรจริง ที่ต้องวัด ปกป้อง และใช้จ่ายอย่างตั้งใจ

การเขียนถูกลง แต่การเข้าใจไม่ได้ถูกลงตาม

• อย่ารับคำตอบแบบสุดโต่งที่ใช้ได้กับทุกกรณี — สำหรับคนทำเดี่ยวและไม่มีผู้ใช้ เรื่อง churn และความกลัวเรื่องความซ้ำซ้อนแบบ enterprise อาจยังไม่ใช่ไฟที่ไหม้อยู่ตรงหน้า แต่เป็นความเสี่ยงในอนาคต ดังนั้นให้พึ่ง test และรีวิวเฉพาะของสำคัญ พร้อมยอมรับอย่างซื่อสัตย์ว่างานที่เลื่อนไปยังคงเป็นหนี้อยู่
• ถ้าคุณอยู่กับระบบใหญ่และผู้ใช้จำนวนมาก ตัวเลขเตือนทั้งหมดในบทความนี้กำลังพูดถึงคุณ และสิ่งเดียวที่ใช้ได้จริงคือการแบ่งชั้น, การบังคับขอหลักฐาน, กระบวนการรีวิวที่ตั้งใจให้หลากหลาย และมนุษย์ที่เป็นเจ้าของการ merge
• สิ่งที่ไม่เปลี่ยนตลอดทั้งสเปกตรัมคือเศรษฐศาสตร์พื้นฐาน — การเขียนถูกทำให้ราคาถูกลง แต่การทำความเข้าใจยังคงแพงเท่าเดิมอย่างที่เคยเป็นมา
• ทีมที่จะทำได้ดีในอนาคตไม่ใช่ทีมที่สร้างโค้ดได้มากที่สุด แต่คือทีมที่สร้าง ระบบรีวิวที่เชื่อถือได้จริง และไม่สับสนเด็ดขาดระหว่าง "test ผ่านแล้ว" กับ "มนุษย์เข้าใจว่าสิ่งนี้คืออะไรและทำไปทำไม"
• อย่างที่ Simon Willison พูดไว้ แก่นแท้ของงานคือการส่งมอบโค้ดที่พิสูจน์แล้วว่าใช้งานได้ — เอเจนต์ไม่ได้เปลี่ยนสิ่งนี้ แต่ทำให้การพิสูจน์กลายเป็นศูนย์กลางของงาน ไม่ใช่งานรอง
• ความสามารถในการเข้าใจระบบได้ลึกพอที่จะยืนรับผิดชอบอยู่ข้างหลังมัน คือทักษะที่ยั่งยืนและน่าสนใจที่สุดในซอฟต์แวร์ และนี่คือช่วงเวลาที่ดีที่สุดอย่างยิ่งในการเก่งเรื่องนี้ให้สุด