10 คะแนน โดย GN⁺ 2026-03-21 | 10 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในยุคที่ AI เขียนโค้ด วิธี รีวิว Pull Request (PR) จำเป็นต้องเปลี่ยนแปลงในระดับรากฐาน และกระบวนการรีวิวปัจจุบันไม่สอดคล้องกับเวิร์กโฟลว์การเขียนโค้ดด้วย AI
  • เมื่อรีวิวเวอร์ถามว่า "ทำไมถึงทำแบบนี้?" โครงสร้างที่เกิดขึ้นคือ นักพัฒนากลับไปถาม AI อีกครั้งแล้วคัดลอกคำตอบมาแปะ ทำให้เกิดความไร้ประสิทธิภาพที่ มนุษย์เหลือเพียงบทบาทคนกลาง (middleman)
  • ควรใส่ decision log ของ AI ไว้ใน source control ควบคู่กับโค้ด เพื่อให้รีวิวเวอร์ตรวจดูบริบทได้โดยตรง
  • เวิร์กโฟลว์ที่ AI รับคอมเมนต์จากรีวิวเวอร์โดยตรงและ สร้าง patch กับคำตอบอัตโนมัติ นั้นทำได้แล้วในปัจจุบัน ด้วยการผสาน GitHub/GitLab webhook กับ MCP server
  • เอกสารออกแบบและแผนภาพสถาปัตยกรรมก็ควรถูกรวมไว้ใน source control ในรูปแบบที่ LLM แยกวิเคราะห์ได้ เช่น Markdown หรือ Mermaid และ "บริบทคือราชา"

ปัญหาของการรีวิวโค้ดในยุค AI

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

ความจำเป็นของ decision log

  • เวลาถามมนุษย์ว่า "ทำไม?" สิ่งที่เราถามคือ กระบวนการคิดภายใน ที่ไม่ได้รวมอยู่ใน PR
  • chain-of-thought ของ AI สามารถตรวจสอบย้อนหลังจากภายนอกได้ (externally auditable) และบันทึกการโต้ตอบกับ AI ก็ตรวจสอบได้เช่นกัน จึงควรใส่บริบทนี้ไว้ในการรีวิวและใน source control
  • ไม่จำเป็นต้อง commit ทุก token ที่เกิดขึ้นระหว่างการสร้าง PR โดยสามารถอ้างอิงแนวคิด episodes ของ Random Labs แล้วเก็บเฉพาะ transcript ของการเรียกเครื่องมือที่สำเร็จและข้อสรุป
    • แนวคิดนี้ขยายไปใช้กับสภาพแวดล้อมแบบ agent swarm ได้เช่นกัน โดยเชื่อม decision log เข้าด้วยกันก่อนถึงขั้น PR และจัดรูปแบบสุดท้าย

ข้อจำกัดของคอมเมนต์แบบอินไลน์

  • การเปลี่ยนแปลงไฟล์ซอร์ส แม้จะแก้แค่คอมเมนต์ ก็ยังต้อง รัน build pipeline ใหม่ (lint, compile, test)
  • transcript ของการตัดสินใจมีขนาด ใหญ่กว่าปริมาณที่คอมเมนต์อินไลน์ทั่วไปจะรองรับได้มาก
  • คอมเมนต์แบบเดิมอธิบายว่าโค้ดทำงานอย่างไรในตอนนี้ แต่ไม่ได้อธิบาย กระบวนการที่นำไปสู่การตัดสินใจนั้น

เวิร์กโฟลว์รีวิวแบบผสาน AI

  • เมื่อรีวิวเวอร์ใส่คอมเมนต์ AI ของนักพัฒนาควรรับโดยตรงและ สร้าง patch กับคำตอบอัตโนมัติ ได้
    • ปัจจุบันทำได้แล้วด้วยการผสาน GitHub/GitLab webhook กับ MCP server
    • คล้ายกับวิธีของ Devin AI หรือ Claude Code via GitLab Duo
  • สามารถตั้งค่าให้นักพัฒนาต้องอนุญาต AI ก่อน หรือให้ AI ตัดสินใจและดำเนินการได้เองทันที
  • นักพัฒนามนุษย์ก็ยังสามารถเขียนคอมเมนต์และแก้ไขด้วยตนเองได้เช่นกัน
  • ปัญหาที่คอมเมนต์รีวิวถูกนำไปแก้หลังจากผ่านไปหลายชั่วโมงหรือหลายวัน หรือไม่ถูกแก้เลยนั้น สามารถลดลงได้อย่างมาก

ความต้องการด้านเครื่องมือสำหรับรีวิวเวอร์

  • รีวิวเวอร์เองก็ควรสามารถ ถาม AI โดยตรงระหว่างตรวจ PR ได้ เหมือนกับการสำรวจ codebase
  • การที่ decision log ถูก check-in ไว้พร้อมโค้ดเป็นองค์ประกอบสำคัญของเป้าหมายนี้
  • ควรยังใช้ PR interface เดิมได้เหมือนเดิม แต่มี หน้าต่างสำหรับคุยกับ Codex หรือ Claude รวมอยู่ด้านข้างแบบเดียวกับสภาพแวดล้อมพัฒนาใน IDE
    • ตอนนี้ยังไม่มีเครื่องมือที่ลงตัวนัก จึงน่าจะดีถ้ามีใครสักคนสร้างขึ้นมา
  • ใน diff หากเจอไลบรารีที่ไม่รู้จัก ภาษาแปลกใหม่ หรือ best practice ที่ไม่คุ้นเคย ก็ควร ถามตอบกับ AI แบบส่วนตัว ก่อน แล้วค่อยตัดสินว่าจำเป็นต้องใส่คอมเมนต์รีวิวโค้ดหรือไม่
  • หากจำเป็นต้องคอมเมนต์ นั่นคือสัญญาณว่าใน decision log ยังมี ช่องว่าง (gap) อยู่ และควรอัปเดต log ก่อนอนุมัติ PR

ความสำคัญของเอกสารออกแบบและบริบท

  • ในการรีวิวแบบผสาน AI การที่รีวิวเวอร์ เสนอ patch โดยตรง ก็ทำได้ง่ายขึ้นมาก
  • ควรเพิ่มเอกสารออกแบบ, decision records และแผนภาพสถาปัตยกรรมลงใน source control ในรูปแบบที่ LLM แยกวิเคราะห์ได้ เช่น Markdown หรือ Mermaid
  • "บริบทคือราชา (Context is king)"

10 ความคิดเห็น

 
tomskang 2026-03-21

เหตุผลที่ PR ตายไป ดูเหมือนจะไม่ใช่เพราะตัว PR เอง แต่เป็นเพราะการสื่อสารที่หละหลวมของพวก Vibe coder มากกว่า

ควรต้องเล่าก่อนทั้งหมดไม่ใช่หรือว่า implement ด้วย flow แบบไหน มีวิธีอื่นอะไรบ้างและทำไมถึงไม่เลือกใช้ ทำไม package.lock ถึงต้องเปลี่ยน
ถ้าแค่เขียนไว้ใน PR Description ก็พอแล้วแท้ ๆ แต่กลับทำให้คนอื่นต้องคอยถามอยู่เรื่อย ๆ แบบนี้ ผมว่าการที่ coder แบบนั้นหายไปน่าจะดีกว่า

 
cafedead 2026-03-21

เห็นด้วยครับ เมื่อก่อน PR ให้ความรู้สึกว่าเราต้องรับผิดชอบต่อสิ่งที่เราสร้างขึ้นเอง
แต่ PR ของพวก vibe coder เหมือนกับว่า "ฉันก็ไม่รู้เหมือนกันว่าตัวเองสร้างอะไรไปบ้าง แต่ยังไงก็มีผลลัพธ์ออกมาแล้ว เพราะงั้นก็ให้นายประเมินแล้วหาปัญหาเอาเอง"

 
shakespeares 2026-03-22

เห็นด้วยครับ
สิ่งที่ควรคุยกันตั้งแต่แรกกลับถูกปล่อยให้กลายเป็นรูปแบบที่ไม่มีใครรับผิดชอบในภายหลัง

 
moregeek 2026-03-22

เห็นด้วยเลย น่าหงุดหงิดมากจนแทบทนไม่ไหว

 
shlee1503 2026-03-21

เห็นด้วยครับ

 
bus710 2026-03-22

ใน PR เดียวมีไฟล์ถูกแก้ตั้ง 500 ไฟล์ แต่คนส่งกลับบ่นว่าทำไมไม่รีวิวให้ภายใน 30 นาที
ในช่องคำอธิบายก็เขียนมาแค่ห้าหกบรรทัดแล้วจบ แบบนี้ต้องให้เชื่อแล้วกดอนุมัติเลยเหรอ...?

ทดสอบครบหมดแล้วใช่ไหม?
ครับ
โอเค ตั้งใจทำกันนะ

 
moregeek 2026-03-22

จะบอกว่าตายอีกทำไมนักหนา

 
kandk 2026-03-23

แบบนี้ตายกันหมดแน่!

 
redmi 2026-03-22

เหมือนว่าพอมีอะไรก็ชอบตั้งชื่อแนวว่า "ตายแล้ว" กันเยอะเกินไป
เลยรู้สึกว่ามันชวนให้ล้าอยู่เหมือนกัน

ผมเองก็คิดว่าเลิกฆ่าอะไรกันสักทีคงจะดี

 
xguru 2026-03-21

"ตายแล้ว; ทรงพระเจริญ"

บทความสไตล์นี้ดูจะมีเยอะเกินไปหน่อยนะครับ แต่ก็ยอมรับว่า AI กำลังเปลี่ยนแปลงทุกอย่างจริง ๆ