ถ้ารีวิวโค้ดเก่ง ก็ใช้งาน AI เอเจนต์ได้เก่งด้วย

 (seangoedecke.com)
15 คะแนน โดย GN⁺ 2025-09-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากต้องการใช้งาน AI เอเจนต์ ให้เชี่ยวชาญ ทักษะ การรีวิวโค้ด คือสิ่งสำคัญ
  • โมเดลภาษาขนาดใหญ่เก่งเรื่อง การสร้างโค้ด แต่ยังขาด วิจารณญาณเชิงลึก จึงมักเสียเวลาไปกับทิศทางที่ผิด
  • การรีวิวจุกจิก ที่คอยทักแต่ไวยากรณ์ยิบย่อย หรือ การรีวิวแบบปั๊มตราผ่าน โดยไม่วิจารณ์ ไม่ได้ช่วยให้ใช้ AI ได้ดีขึ้น
  • การรีวิวโค้ดที่ดีต้องมี มุมมองเชิงโครงสร้าง เพื่อตรวจสอบว่ามี วิธีที่ดีกว่า หรือไม่ และช่วยหลีกเลี่ยงการออกแบบที่ซับซ้อนเกินไป
  • ท้ายที่สุดแล้ว AI coding คือโมเดลแบบ "Centaur Chess" ที่ผสานวิจารณญาณของมนุษย์เข้ากับประสิทธิภาพการผลิตของเครื่องจักร และความสามารถในการรีวิวโค้ดก็คือความสามารถในการใช้ AI นั่นเอง

ความสัมพันธ์ระหว่าง AI เอเจนต์กับการรีวิวโค้ด

  • การใช้ AI เอเจนต์อย่างถูกต้องก็คือกระบวนการ รีวิวโค้ด นั่นเอง
  • คนที่ รีวิวโค้ดเก่ง มักจะ ใช้เครื่องมือเขียนโค้ดด้วย AI ได้อย่างมีประสิทธิภาพ เช่น Claude Code, Codex และ Copilot

ทำไมทักษะรีวิวโค้ดจึงสำคัญ

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

ข้อจำกัดของ AI เอเจนต์และความผิดพลาดด้านการออกแบบ

  • ตัวอย่างเช่น ระหว่างพัฒนาโปรเจกต์ VicFlora Offline นั้น Codex ทุ่มความพยายามอย่างมากไปกับการ reverse engineer โค้ดฝั่ง frontend
    • ทั้งที่จริงแล้วมีวิธีเข้าถึงข้อมูลที่ง่ายกว่านั้น
    • เมื่อใช้ AI เอเจนต์ มักพบว่าประมาณชั่วโมงละครั้งจะมีช่วงที่มันทำงานบางอย่างน่าสงสัย
    • หากตรวจพบปัญหาแบบนี้แล้วเปลี่ยนทิศทางด้วยตนเอง ก็สามารถ ประหยัด เวลาได้หลายชั่วโมง
  • ในประสบการณ์การพัฒนาแอปอีกครั้งหนึ่ง AI เสนอให้สร้าง background infrastructure มากเกินจำเป็น แม้จะเป็นงาน ประมวลผลแบบขนาน ที่เรียบง่าย
    • ทั้งที่แค่จัดการแบบ non-blocking บน frontend ก็เพียงพอแล้ว แต่มันกลับพยายามนำสถาปัตยกรรมที่ซับซ้อนเข้ามา
    • การควบคุม AI อย่างต่อเนื่องเพื่อรักษา ความเรียบง่าย จึงเป็นเรื่องสำคัญ
  • หากผู้ที่ไม่ใช่ผู้เชี่ยวชาญ เชื่อ AI อย่างเดียวแล้วพัฒนา ความซับซ้อนและความไร้ประสิทธิภาพของ codebase จะสะสมขึ้น จนกลับทำให้ความสามารถในการแก้ปัญหาลดลงอย่างรวดเร็ว

แก่นแท้และผลของการรีวิวโค้ด

  • การทำงานร่วมกับ AI คล้ายกับการ ร่วมงานกับนักพัฒนารุ่นจูเนียร์ที่กระตือรือร้นแต่ประสบการณ์ยังน้อย
    • AI ไม่ได้เติบโตในด้าน วิจารณญาณ ตามกาลเวลา จึงต้องมีการสังเกตและกำกับอย่างต่อเนื่อง
  • ความผิดพลาดใหญ่ที่สุดของการรีวิวโค้ดคือดูแค่โค้ดที่เขียนมา แล้วไม่คิดว่ามี ทางเลือกที่ดีกว่า หรือไม่
    • การรีวิวโค้ดที่ดีที่สุดจะมองในเชิง โครงสร้าง และพิจารณาบริบทของทั้งระบบอย่างบูรณาการ
    • แทนที่จะสร้างระบบใหม่ที่ไม่จำเป็น ควรให้ความสำคัญกับการนำ ระบบเดิม กลับมาใช้ให้เกิดประโยชน์ก่อน
  • ผู้รีวิวแบบ 'nitpicky' ที่หมกมุ่นกับสไตล์โค้ดเล็กน้อยมากเกินไป อาจพลาดการใช้เครื่องมือ AI อย่างแท้จริง
  • หากรีวิวแบบ 'rubber-stamp' คือปล่อยผ่านโดยไม่วิจารณ์ ก็จะทำงานร่วมกับ AI/นักพัฒนาจูเนียร์ได้อย่างไม่มีประสิทธิภาพ

มุมมองต่อทักษะการใช้เครื่องมือ AI

  • เครื่องมือดั้งเดิมอย่าง git มีโครงสร้างและวิธีใช้งานที่ชัดเจน แต่ โครงสร้างพื้นฐานของ AI ยังไม่โปร่งใส
    • AI สามารถทำการประมวลผลได้แทบทุกประเภท
  • บางคนมองว่าการ ใช้เครื่องมือ AI แบบรอบด้าน คือความสามารถในการใช้ AI
    • แต่ในความเป็นจริง ผู้ใช้ที่ชำนาญย่อมดึงศักยภาพออกมาได้มากกว่า
  • ณ ตอนนี้ แม้ AI code agent จะช่วยงานได้หลากหลาย แต่ก็ยังต้องการ การกำกับดูแลอย่างใกล้ชิด
  • เช่นเดียวกับโมเดล "Centaur Chess" เมื่อทิศทางจากมนุษย์ที่มีทักษะรวมกับข้อเสนอจาก AI ก็จะสามารถบรรลุผลิตภาพที่ดีที่สุดได้
  • ทักษะการใช้ AI ในท้ายที่สุดขึ้นอยู่กับ ทักษะการรีวิวโค้ดและวิจารณญาณเชิงออกแบบอย่างมีวิจารณ์
  • ยิ่งมีทักษะรีวิวโค้ดดีเท่าไร ก็ยิ่งดึงประสิทธิภาพของเครื่องมือ agentic AI ออกมาได้มากเท่านั้น

ความคิดส่งท้ายและแนวโน้มในอนาคต

  • AI เอเจนต์อาจให้ความรู้สึกว่าเมื่อเวลาผ่านไปมันค่อย ๆ เก่งขึ้นจนคล้ายวิศวกรที่มีประสบการณ์มากขึ้น
  • ในอีกไม่กี่ปีข้างหน้า ประสบการณ์การทำงานร่วมกับ AI อาจพัฒนาไปจน ใกล้เคียงกับการร่วมงานกับวิศวกรระดับกลาง
  • ในปัจจุบัน การทดลองใช้เครื่องมือ AI หลายแบบ เช่น Codex, Claude Code, Copilot เป็นต้น เป็นสิ่งที่เหมาะสม และ ความสามารถในการกำกับดูแลอย่างมีวิจารณญาณ คือจุดแตกต่างที่สำคัญที่สุด

ความเห็นเพิ่มเติม

  • มีการถกเถียงกันใน Hacker News เป็นต้น ว่า “AI เอเจนต์มีประโยชน์ได้มากแค่ไหน”
    • ผู้เขียนไม่คิดว่า AI จะสามารถมีส่วนร่วมในระดับ Linux kernel ได้ด้วยการอาศัยแค่การรีวิวโค้ด
    • บางคนก็เห็นว่าวิธีรีวิวโค้ดในด้านสไตล์และการตั้งชื่อก็สำคัญเช่นกัน
    • แม้จะมีมุมมองวิพากษ์ต่อการนำประเด็นด้านดีไซน์มาคุยกันใน code review แต่ผู้เขียนไม่ได้มองว่านั่นเป็นเรื่องลบ

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

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

 
GN⁺ 2025-09-23
ความเห็นจาก Hacker News

  • ค่อนข้างน่าสงสัยมากกับแนวคิดที่ว่า ถึงกระบวนการจะแย่ แต่ถ้าคุมคุณภาพดีพอก็จะได้ผลลัพธ์ที่ดี ประมาณว่า “ต่อให้คายของมั่วๆ ออกมาเรื่อยๆ ถ้ามีคนคอยตรวจให้ก็โอเค” แต่ในความเป็นจริงผมไม่เคยเห็นว่ามันได้ผลจริง เคยมีความพยายามทำแบบนี้ในอุตสาหกรรมรถยนต์ของสหรัฐฯ แต่ก็นึกตัวอย่างที่สำเร็จไม่ออก ลองนึกภาพว่าถ้าหัวหน้าของผมบอกว่า “แทนที่จะเอาคนเก่ง 5 คน จะให้เอามือใหม่สุดๆ 25 คนมา แล้วรอให้บังเอิญได้งานที่พอใช้ได้ คุณไปตรวจทั้งหมดเองนะ” แบบนี้มันฟังไม่ขึ้นเลย แต่พอมี AI เข้ามาในสถานการณ์นี้ หลายคนกลับคิดว่า “อืม? หรือมันอาจจะเวิร์กก็ได้?” ตรงนี้แหละที่น่าแปลก

    • แค่รีวิวโค้ดของคนที่ประสบการณ์น้อยหรือไม่มีแรงจูงใจก็เหนื่อยมากอยู่แล้ว มันกินพลังทั้งทางสมองและอารมณ์มหาศาล พอรีวิวฟีเจอร์เดิมเป็นครั้งที่ 4 ก็เริ่มเอือม จนสุดท้ายยอมแพ้ในจุดที่คุณภาพมันคงไปได้ไม่ไกลกว่านี้แล้ว

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

    • วิวัฒนาการก็เป็นตัวอย่างของการกลายพันธุ์แบบสุ่มและการคัดเลือก หรือถ้าจะพูดให้กว้างกว่านั้น การมีอยู่ของสิ่งมีชีวิตที่ซับซ้อนทั้งหมดก็เป็นกรณีตัวอย่าง แม้มันไม่ใช่วิธีที่ผมชอบ แต่ผู้คนมักตื่นเต้นกับคำฮิตตามกระแสแล้วเอาไปลองใช้แบบสะเปะสะปะในที่ที่ไม่เหมาะ ในการผลิตชิ้นส่วนพลาสติกบางอย่างของเครื่องครัว ก็ยังมีวิธีที่ฉีดขึ้นรูปออกมาแบบคุณภาพแย่ๆ แล้วให้แรงงานรายวันใช้มีดแต่งแก้ด้วยมือก่อนแพ็ก ผมเองก็เคยทำงานชั่วคราวแบบนี้มาแล้ว แม้แต่ chip binning/การจัดการ yield ของเซมิคอนดักเตอร์ก็มองได้ว่าเป็นตัวอย่างที่มีอัตราความล้มเหลวสูงมาก มองไปรอบตัวในโลกจริงแล้ว กระบวนการที่น่าสงสัยแบบนี้ไม่ใช่เรื่องแปลก แต่กลับเป็นเรื่องปกติด้วยซ้ำ

    • พอเริ่มประเมินตัวเองว่า “ใช้ AI เก่ง” ก็จะเผลอหลงคิดว่า “ขอบเขตปัญหาที่ฉันแก้ได้กว้างขึ้นมหาศาล” ปรากฏการณ์นี้เกิดกับเทคโนโลยีอเนกประสงค์ทุกชนิด สมัยก่อนตอนกระแส genetic algorithm ก็บรรยากาศคล้ายกัน ทุกคนมองหาเครื่องมือแบบ “ใช้ได้สารพัด” แล้วก็เข้าใจผิดว่ามันเอาไปใช้ทำได้ทุกอย่าง ทั้งที่จริงคือพยายาม optimize โดยไม่มีบริบทอะไรเลย AI เป็นตัวอย่างที่ทำให้ปรากฏการณ์นี้รุนแรงขึ้นไปอีก

    • ต่อให้มีกระบวนการที่ดีแค่ไหน มันก็ไม่ได้ทำให้คุณเรียนรู้วิธีสร้างระบบที่ทำงานถูกต้องได้เอง รูปแบบที่เห็นซ้ำๆ คือทีมจะหลงทางกันอยู่นาน สุดท้ายวิศวกรที่รู้วิธีแก้ปัญหาจริงๆ ต้องลงมือเองเพื่อดึงทิศทางกลับมาให้ถูกต้อง

  • การทำให้ AI รักษาพารามิเตอร์ตามที่สั่งนั้นยากมาก มันชอบหลุดออกนอกทางแบบสุ่มตลอด ตอนทำ syntax highlighting สำหรับ nftables มีโทเค็น 230 ตัว สถานะ 2,500 สถานะ และ state transition เกิน 50,000 จุด ต่อให้ให้กฎชัดเจน 5 ข้อกับ AI มันก็ยังพลาดแบบสุ่มทุกที่ ไม่ใช่แค่ผลลัพธ์การเขียนโค้ด แม้แต่ Vimscript ง่ายๆ ก็ยังทำไม่ได้ สุดท้ายเลยใช้ AI แค่เพื่อช่วยทำเอกสารเท่านั้น ถึงอย่างนั้นมันก็เริ่มทำได้ดีพอสมควรในการอธิบายสิ่งที่แยกย่อยอย่าง rule, chain_block stmt, map_stmt_expr แค่คัดลอกรูปแบบไวยากรณ์ที่ผมต้องการมาใช้ก็พอ

  • การสร้างโค้ดด้วย AI มีประโยชน์มากพอสมควรในช่วงเริ่มต้นของโปรเจ็กต์ แต่กับโปรเจ็กต์ที่โตเต็มที่แล้ว ผมมีความกังวลอยู่ ไม่นานมานี้มีการ merge Postgres parser ขนาด 280k+ LOC เข้า Multigres โดยไม่มีการเปิดรีวิวต่อสาธารณะ เรื่องแบบนี้ควรระวังในระบบนิเวศโอเพนซอร์ส หลายคนพึ่งพาโปรเจ็กต์ลักษณะนี้เพื่อเรียนรู้และใช้อ้างอิง ถ้าเอาโค้ดจาก AI เข้าไปโดยไม่มีการรีวิวที่เหมาะสม มูลค่าเชิงการเรียนรู้และความน่าเชื่อถือของสิ่งที่คนอื่นต้องพึ่งพาก็จะลดลง การรีวิวโค้ดไม่ได้มีไว้แค่จับบั๊ก แต่เป็นแกนหลักให้ผู้ร่วมงานได้เรียนรู้ เข้าใจเหตุผลของการออกแบบ และสะสมความรู้ร่วมกัน ประเด็นไม่ใช่เรื่องความเร็ว แต่เป็นกระบวนการถ่ายทอดความรู้ ส่วนเรื่องระยะเวลาจนกว่าจะเปิด PR ต่อสาธารณะ ดูได้จากลิงก์นี้

    • ผมเป็นคนกำกับงานนี้เอง และยินดีรับฟีดแบ็กเกี่ยวกับแนวทางที่ดีกว่าเสมอ สิ่งที่ทำให้กรณีนี้พิเศษคือเป็นการใช้ LLM แปล Postgres C parser งานขนาดนี้ตรวจรีวิวทีละบรรทัดต่อเนื่องกันไม่ได้ จึงสร้างขั้นตอนแยกต่างหากเพื่อรับประกันความสอดคล้อง ตรวจละเอียดทุกวันอยู่สองเดือนเต็ม และยังยกเทสต์ส่วนใหญ่ของ Postgres มาพอร์ตสำเร็จ จึงมั่นใจเรื่องความถูกต้องในการทำงานได้เพียงพอ ปัจจุบัน Multigres ยังอยู่ในระยะเริ่มต้นมาก และจากนี้ก็วางแผนจะลองคัดลอก/แปลครั้งใหญ่กับโปรเจ็กต์อื่นอีก เช่น Vitess ถ้ามีข้อเสนอเพื่อปรับปรุงก็พร้อมรับ ผู้เขียนกำลังเตรียมบล็อกอธิบายกระบวนการทั้งหมดไว้ด้วย ลองติดตามได้ ส่วนตัวผมประหลาดใจมากกับผลลัพธ์ที่ทำได้ด้วยความช่วยเหลือของ LLM แน่นอนว่าต้องมีทักษะพอสมควร และคนนี้ก็เกินมาตรฐานทั้งหมดที่เสนอไว้ที่นี่

  • กระบวนการของผมคร่าวๆ เป็นแบบนี้

    1. บอกความต้องการกับ AI
    2. ให้ AI ถามกลับในส่วนที่ยังไม่ชัดเจน
    3. เมื่อไม่มีคำถามเพิ่มแล้ว ให้มันอธิบายความต้องการกลับมาในรูปแบบ PRD อย่างเป็นทางการ
    4. ผมวิจารณ์
    5. ให้มันเสนอ architecture ทางเลือก 2 แบบ
    6. ผมเลือกหนึ่งแบบแล้ววิจารณ์
    7. ให้มันเสนอรายการ TODO แบบละเอียด 2 ชุด
    8. ผมเลือกหนึ่งชุดแล้ววิจารณ์
    9. ให้มันเสนอวิธี implement 2 แบบสำหรับ TODO ข้อหนึ่ง
    10. ผมเลือกหนึ่งแบบแล้ววิจารณ์
    11. วนกลับไปข้อ 9
      ระหว่างทางก็ถ่าย snapshot ไว้เป็นช่วงๆ เพื่อย้อนกลับได้
      ทำแบบนี้แล้ว ถึงจะยังไม่ถึงระดับยอดเยี่ยม แต่ก็ได้ผลลัพธ์ที่อย่างน้อยใช้เป็น baseline สำหรับ implementation ของผมเองได้
      ข้อเสียคือกินเวลามหาศาล และใน 80% ของกรณี ผมก็ยังรู้สึกว่าเริ่มทำเองตั้งแต่แรกน่าจะเร็วกว่า

    • ฟังดูช้ากว่าทำคนเดียว เวลาใช้ AI เขียนโค้ด มันให้ความรู้สึกเหมือนดูผลงานของนักพัฒนาระดับกลางที่ “นั่งดื่มไปแก้วนึงแล้วลองทำตามโน้ตที่คุณเขียนให้แบบคร่าวๆ ดูนะ เป็นไง” แล้วใช้คืนวันเสาร์ทั้งคืนทำของสดออกมา พอเราบอกแค่ว่า “NO, ไม่ชอบ” แล้วถ้าทิศทางคร่าวๆ ยังพอใช้ได้ ก็เอามารีแฟกเตอร์ต่อ เหมือนจะเร็วกว่าการเริ่มเช้าวันจันทร์จากศูนย์นิดหน่อย

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

    • ผมทำงานในเลเยอร์ที่ต่ำกว่านี้หน่อย ปกติจะทำประมาณนี้:

      • สร้างอินเทอร์เฟซพื้นฐานเองก่อน หรือถ้ามีอยู่แล้วก็ไปขั้นถัดไป
      • ใช้ LLM เป็นเครื่องมือ autocomplete
      • อธิบายความต้องการ และบอกไฟล์ entry point ที่ต้องเปลี่ยน
      • ไม่ให้เป้าหมายทั้งหมดในครั้งเดียว แต่ให้ทีละขั้นทุกครั้ง
      • ถ้าเริ่มเห็นสัญญาณว่าจะออกนอกทาง ก็แทรกแซงทันทีเพื่อหยุด หรือถ้า AI ผิดก็ช่วยปรับทิศทาง
        โดยรวมแล้ว ถ้าให้เป้าหมายที่กว้างและยาวเกินไปในครั้งเดียว เอเจนต์มักจะตัดสินเวลาที่งานเสร็จผิดพลาดบ่อยมาก

    • ผมใช้กระบวนการคล้ายกันแต่เรียบง่ายกว่า ให้ PRD ไปก่อน บอก architecture คร่าวๆ ด้วย แล้วสั่งให้ implement แต่ละ component ตามแนวทางที่ต้องการ ถึงอย่างนั้นก็ยังใช้เวลามาก และทำเองก็น่าจะเร็วกว่า แต่ตอนนี้ผมเริ่มขี้เกียจไล่เขียนทีละบรรทัดเองแล้ว เลยคิดว่าจะให้ LLM ทำเป็นระดับฟังก์ชันดู

    • ถ้าใช้ AI แค่เพื่อบอกแนวทางคร่าวๆ ไลบรารี หรือคุณลักษณะของภาษา งานหลักที่เหลือผมทำเองน่าจะเร็วกว่าเยอะ

  • ถ้าคุณรีวิวโค้ดได้เก่ง บางทีอาจดีกว่าถ้าไม่ใช้ AI agent เลย

    • จากที่ผมต้องรีวิวโค้ดและแก้บั๊กให้เพื่อนร่วมงานที่หลงรักเอเจนต์อย่าง Claude Code ด้วยตัวเอง สิ่งที่ผมเจอคือโค้ดมักประหลาดเหมือนคนเขียนอยู่ในภาวะหลอน และคนที่เขียนก็มักอธิบายโค้ดตัวเองไม่ได้เลย ถึงอย่างนั้นผมก็เชื่อว่าน่าจะมีคนที่ทำโค้ดดีๆ ได้จริงอยู่บ้าง แต่สิ่งที่ผมเห็นมากับตาตัวเองล้วนแต่น่าผิดหวัง โชคดีที่บางคนก็ตระหนักได้เองและกลับไปหาวิธีทำงานที่เหมาะสมกว่า ทุกวันนี้ถ้ามองผลลัพธ์จาก workflow แบบ agent อย่างวิพากษ์วิจารณ์ คำตอบมันค่อนข้างชัด ผมคิดว่าคนที่รีวิวโค้ดเก่งจะไปถึงข้อสรุปนี้ได้เร็วกว่าเยอะ

    • ถ้าผมรีวิวโค้ดเก่ง ผมก็อยากพัฒนาทักษะนั้นต่อไปเรื่อยๆ

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

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

    • ที่จริงผมไม่ได้สนุกกับการ “เขียน” โค้ดโดยตัวมันเองเท่าไร ผมสนุกกับการแก้ปัญหา สร้างสิ่งใหม่ แยกระบบออกเป็นส่วนๆ แล้วประกอบกลับเป็นโครงสร้างที่ดีกว่า การใช้ LLM เขียนโค้ดทำให้รู้สึกว่าเปลี่ยนไอเดียให้กลายเป็นสิ่งที่จับต้องได้จริงเร็วขึ้นมาก โค้ดเดิมก็มี type safety ดีขึ้น เอกสารดีขึ้น และรีแฟกเตอร์ซับซ้อนได้ง่ายขึ้น ผมไม่ได้คาดหวังให้ LLM มาแก้ปัญหาแทน แต่คาดหวังเรื่องการรวบรวมบริบท การนำแพตเทิร์นกลับมาใช้ซ้ำ และการทำงานซ้ำๆ ให้เป็นอัตโนมัติ โดยเฉพาะเวลาโค้ดกระจายอยู่หลายไฟล์ ถ้า AI ช่วย generate ให้ได้ ก็แค่ตรวจแต่ละการเปลี่ยนแปลงก็สะดวกมาก

    • OpenAI Codex Cloud เพิ่มความสามารถด้านรีวิวโค้ดแล้ว และโมเดล GPT-5-Codex ใหม่ก็ถูกฝึกมาให้เด่นด้านการรีวิวโค้ด [แนะนำการอัปเกรด Codex], ส่วน Gemini และ Claude ก็มีทั้งฟีเจอร์รีวิวโค้ดที่เชื่อมกับ GitHub Actions และการเชื่อม GitHub ของ Claude เช่นกัน ฝั่ง GitHub เองก็เปิดตัวCopilot Code Review แล้ว ยังมีสตาร์ตอัปเฉพาะทางอีกมาก เช่น CodeRabbit, Greptile, Qodo Merge

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

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

    • ตอนต้นมีการพูดว่า “นักพัฒนาส่วนใหญ่ชอบสร้างของใหม่” แต่ในความเป็นจริงก็มีคนจำนวนมากที่ชอบทำงานบน codebase ที่คนอื่นสร้างไว้แล้ว โดยค่อยๆ ทำความเข้าใจแพตเทิร์นและโครงสร้าง จากนั้นปรับปรุงมันให้ดีขึ้น และก็ต้องคำนึงด้วยว่าบางคนอาจรู้สึกว่ากระบวนการสร้างของใหม่ทั้งหมดตั้งแต่ต้น (ออกแบบเริ่มต้น - วนซ้ำไม่รู้จบ) เหนื่อยกว่ามาก สำหรับคำถามที่ว่า “ทำไมถึงเอาความสนุกออกแล้วเพิ่มแต่ความไม่สนุก” คำตอบอาจเป็นเพราะคนไปโฟกัสกับจุดที่รู้สึกว่าผลต่อ productivity มากที่สุด ส่วน AI สำหรับรีวิวก็มีตัวเลือกอยู่แล้วหลายตัว เช่น CodeRabbit, GitLab Duo หรือแม้แต่เอา Git diff ใส่ RooCode เพื่อให้มันรีวิวโค้ดให้ก็ไม่ได้เกินความสามารถ

  • ชื่อบทความนี้ดูง่ายเกินไปหน่อย การรีวิวโค้ดกับการรีวิวการออกแบบไม่เหมือนกัน และสิ่งที่ลองทำกับ AI ก็ไม่ได้มีแค่สองอย่างนี้ การจะใช้ AI ให้ได้ดีต้องมีความรู้เฉพาะด้านนั้นด้วย ต่อให้มองแค่เรื่องโค้ด ความสามารถในการรีวิวอย่างเดียวก็ไม่พอ คุณต้องมีศักยภาพในการตรวจสอบได้ว่าสิ่งที่โยนให้ AI ทำนั้นถูกต้องหรือไม่ ไม่ว่าจะเป็นงานด้านไหนก็ตาม ในทางกลับกัน AI กลับมีประโยชน์ที่สุดตอนผมไปเจอภาษาหรือเฟรมเวิร์กที่ไม่ถนัด แต่ตอนนั้นผมเองก็รีวิวโค้ดเชิงลึกไม่ได้เหมือนกัน น่าสนใจเหมือนกันที่คำว่า “coding” กลับมาฮิตอีกครั้งในยุค AI/LLM ทุกวันนี้บริษัทต่างๆ ดูจะชอบวิศวกรมากกว่าคนที่เป็นแค่โคเดอร์ธรรมดา คืออยากได้คนที่ทำได้ทั้ง architecture, วิเคราะห์ความต้องการ, full-stack development และ operation

    • ตำแหน่งทางการของผมคือ “Software Engineer” แต่ในช่วง 5 ปีที่ผ่านมา

      1. ตั้งค่าและดูแล Kubernetes cluster ให้ทีมเอง
      2. ใช้ Docker หนักมาก
      3. พัฒนา CI/CD pipeline
      4. ทำ integration/ทดสอบมานับครั้งไม่ถ้วน
      5. ทำเอกสารความต้องการรวมถึงแผนภาพระบบต่างๆ จำนวนมาก
      6. งาน IT จิปาถะที่ทีม infrastructure ไม่ทำ
      7. แล้วก็แอบเขียนโค้ดบ้างเป็นบางครั้ง

    • การใช้ AI agent ให้ถูกต้องก็เหมือนกับกระบวนการรีวิว
      เพราะ LLM สามารถผลิตโค้ดได้มหาศาล แต่ยังไม่มีวิจารณญาณเชิงลึกแบบที่วิศวกรซอฟต์แวร์ที่เก่งจริงมี
      ดีกว่ามากถ้าจะแก้ทิศทางตั้งแต่เนิ่นๆ แทนที่จะปล่อยให้โค้ดกองพะเนินไปไกลในทิศทางที่เราไม่เข้าใจ เหมือนเวลาทำงานกับนักพัฒนาจูเนียร์ ควรคุยภาพใหญ่และดีไซน์ก่อน แล้วคอยดึงกลับตั้งแต่เนิ่นๆ เมื่อเริ่มออกนอกทาง เพราะถ้าปล่อยให้โค้ดยาว 100K โทเค็นสะสมขึ้นมาแล้วเพิ่งมารู้ว่าร้อยบรรทัดแรกผิด สุดท้ายคุณก็ต้องรื้อทั้งก้อนอยู่ดี

  • ผมชอบมากกับแนวคิดที่ว่าการรีวิวโค้ดร่วมกับเพื่อนร่วมงานช่วยยกระดับความรู้ร่วมและมาตรฐานทีมได้ แต่แค่คิดว่าจะต้องรีวิวโค้ดของ AI ที่ดื้อและไม่ให้ความร่วมมือก็เหมือนจะหมดไฟแล้ว

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