- คำถามที่น่าสนใจว่าการให้ AI รีวิวโค้ด ที่ AI เขียนขึ้นเอง นั้นเหมาะสมหรือไม่
- บอตอย่าง Devin AI กำลัง เขียน PR ได้มากที่สุด และก็มีกรณีที่ให้ AI เป็นผู้รีวิวเพิ่มขึ้นเรื่อย ๆ
- ยังมีข้อโต้แย้งว่า LLM ไม่มีสถานะ (stateless) และ มีโครงสร้างภายในต่างกันระหว่างตอนรีวิวกับตอนเขียน จึงสามารถแยกบทบาทกันได้
- โค้ดที่ AI สร้างขึ้นก่อให้เกิดบั๊กคนละประเภทกับที่คนมักทำ และ AI ก็ มีประสิทธิภาพมากกว่าในการหาบั๊กเหล่านั้น
- สรุปแล้ว AI รีวิวมีข้อได้เปรียบต่อการตรวจจับข้อผิดพลาดจริง มากกว่าการรีวิวโดยมนุษย์ แต่การตัดสินใจเชิงสถาปัตยกรรมและสไตล์ไกด์ของมนุษย์ก็ยังสำคัญ
AI สามารถรีวิวโค้ดของตัวเองได้หรือไม่?
- บริษัทส่วนใหญ่ยึดหลัก ผู้เขียน ≠ ผู้รีวิว
- แต่ AI ที่อิง LLM ไม่มีสถานะและตัดสินใหม่ทุกครั้งตามคำขอ
- กล่าวคือ แม้จะใช้เอนจินเดียวกัน ก็อาจมองว่า การเขียนกับการรีวิวเป็น “รถคนละคัน” ได้
Scaffolding: โครงสร้างของการรีวิวโดย AI
- AI สำหรับงานรีวิวจะทำ เวิร์กโฟลว์เฉพาะทาง ดังนี้:
- วิเคราะห์ code diff
- ตรวจจับบั๊ก
- เขียนคอมเมนต์และประเมินระดับความรุนแรง
- อ้างอิงเอกสารของ codebase และไฟล์ที่เกี่ยวข้อง
- ในทางกลับกัน AI สำหรับสร้างโค้ด ทำงานในบริบทที่ต่างออกไปโดยสิ้นเชิง ดังนั้น การรีวิวกับการสร้างจึงต่างกันในเชิงหน้าที่
มนุษย์เองก็เป็น "เอนจินเดียวกัน"
- แม้ผู้เขียน PR กับผู้รีวิวจะเป็นคนละคน แต่ก็ล้วนมาจาก สติปัญญามนุษย์แบบเดียวกัน
- พวกเขาอยู่ในบริษัทเดียวกัน และมี ความรู้กับประสบการณ์คล้ายกัน จากการฝึกฝนแบบเดียวกัน
- ท้ายที่สุดแล้ว ทั้ง AI และมนุษย์ก็คล้ายกันในแง่ “เอนจินเดียวกัน แต่คนละกรณีใช้งาน”
โค้ด AI ต้องการการรีวิวที่ละเอียดกว่าเดิม
-
คุณภาพของโค้ด AI ต่ำกว่านิดหน่อย
- AI เร็วก็จริง แต่เพราะ ข้อจำกัดของพรอมป์ต์ ทำให้การส่งต่อความต้องการไม่แม่นยำ
- แม้แต่นักพัฒนาที่เก่งก็ยัง รีวิวโค้ด AI ไม่ละเอียดเท่ากับโค้ดที่ตัวเองเขียน
- ผลลัพธ์คือ คุณภาพโดยรวมถูกดึงลง และมาบรรจบที่ระดับกลาง ๆ
-
บั๊กของ AI มนุษย์หายากกว่า
- บั๊กที่ AI สร้างขึ้นเป็น ประเภทที่มนุษย์ปกติไม่ค่อยทำ
- ตัวอย่าง: การแก้บรรทัดที่ไม่คาดคิด, ความผิดพลาดเล็กน้อยในเงื่อนไข เป็นต้น
- ตามการทดสอบภายในของ Greptile:
- AI (Sonnet) พบ 32 จาก 209 บั๊กระดับ “Hard”
- นักพัฒนามนุษย์ พบได้เฉลี่ยเพียง 5~7 รายการ
บทสรุป
- การให้ AI รีวิวโค้ดของตัวเองนั้น เป็นไปได้และมีความหมายในเชิงเทคนิค
- AI เก่งกว่ามนุษย์ในการตรวจจับบั๊ก และมีประโยชน์ต่อการรีวิวจริง
- อย่างไรก็ตาม การ ตีความเจตนา การตัดสินใจด้านการออกแบบ และการตัดสินเรื่องสไตล์โค้ด ของมนุษย์ยังคงสำคัญ
- เกณฑ์ดั้งเดิมเรื่องผู้เขียน ≠ ผู้รีวิว อาจจำเป็นต้อง ตีความใหม่สำหรับ AI
3 ความคิดเห็น
น่าจะลองรีวิวโดยสลับใช้โมเดล LLM ไปเรื่อยๆ ดูนะครับ เช่น ใช้โมเดล A เขียนโค้ด แล้วให้โมเดล B, C, D มารีวิว
อ๊ะ บริษัทเราก็ทำแบบนี้ครับ เวลาเปิด PR ของโค้ดที่เขียนด้วย Cursor (Claude) เราจะให้ ChatGPT รีวิวให้ แล้วก็บอกว่าเอาล่ะ จากนี้ไปสู้กันเองนะ คนเริ่มร้องว้าวกันตั้งแต่ o4-mini แล้วครับ ใน Cursor เองก็ลองได้เลยแบบเปลี่ยนโมเดลแล้วส่งคำขอ
ความคิดเห็นจาก Hacker News
ฉันอยากเน้นประเด็นนี้: วิศวกรมักไม่ได้ตรวจโค้ดที่ AI สร้างขึ้นอย่างละเอียดเท่ากับโค้ดที่ตัวเองเขียน เหตุผลคือ LLM สร้างโค้ดได้เร็วกว่าอัตราการพิมพ์มาก ดังนั้นเวลาที่เราเขียนโค้ดเอง เราจะตรวจทานไปโดยธรรมชาติ แต่ถ้า AI เป็นคนสร้าง กระบวนการนั้นมักถูกข้ามไป ที่น่าสนใจก็คือ สำหรับวิศวกรระดับทั่วไป AI กลับช่วยยกระดับคุณภาพโค้ดได้ด้วย ยิ่งใช้ AI มากขึ้น วิศวกรที่เก่งกับไม่เก่งก็อาจผลิตโค้ดที่มีระดับใกล้เคียงกันมากขึ้นเรื่อย ๆ มันน่าสนุกเสมอที่ในแต่ละขั้นของการรีวิวโค้ด การออกแบบ และการเขียนโค้ด วิธีคิดจะแตกต่างกัน
แต่ละคนมีรูปแบบการทำงานร่วมกับเครื่องมือไม่เหมือนกัน จึงมีวิธีที่เหมาะกับแต่ละคนต่างกัน สำหรับฉัน การรีวิวง่ายกว่าการเขียนโค้ด เวลาลงมือเขียนเองต้องคิดบริบทนอกเหนือจาก codebase เยอะมาก แต่เวลารีวิวสามารถโฟกัสบริบทลงไปที่ codebase ได้เลย จึงจับแพตเทิร์นได้เร็วกว่า น่าเสียดายที่ LLM ยังอยู่ระดับวิศวกรจูเนียร์ เลยต้องใช้แรงและพลังกับการรีวิว PR มากขึ้น
วิศวกรที่ดีไม่ได้แปลว่าจะเป็นคนเขียนโค้ดที่ดีเสมอไป
ถ้าใช้บอตและพรอมป์ต์คนละชุดสำหรับรีวิวโค้ดกับสำหรับเขียนโค้ดด้วย AI จะช่วยเจอข้อผิดพลาดได้มากขึ้นมาก แม้จะวนซ้ำด้วยเครื่องมือเดิมหลายรอบ ก็ยังอาจเจอปัญหาใหม่ได้ ทั้งมนุษย์และ AI ต่างก็ไม่สามารถสร้างโค้ดที่สมบูรณ์แบบได้ตั้งแต่ครั้งเดียว ตอนนี้เครื่องมือ AI พัฒนาจนถึงขั้นทดสอบโค้ดของตัวเองและทำ pre-review ได้แล้ว แต่ฉันเชื่อว่าการให้ทั้งคนและ AI รีวิวโค้ดใน PR นั้นไม่มีทางเป็นโทษ แม้แต่กับเครื่องมือที่ฉันทำเองชื่อ Kamara ฉันก็ยังเจอปัญหาในโค้ดที่มันเขียนเองบ่อย ๆ เหมือนกัน ยังมีปัญหาแบบในตัวอย่างของ greptile ที่เสนอจุดแก้ไขผิดตำแหน่งไปเลยอยู่บ้าง แต่ก็ค่อย ๆ ควบคุมได้ดีขึ้น ยังไม่มีเครื่องมือไหนสมบูรณ์แบบ 100% และกว่าจะถึงวันที่ AI takeover ทุกอย่างได้จริงก็คงต้องใช้เวลาอีกหน่อย
ตอนเริ่ม OpenHands (ชื่อเดิม OpenDevin) PR ที่ AI สร้างจะถูกส่งขึ้นมาด้วยชื่อบัญชี AI ซึ่งทำให้เกิดปัญหาร้ายแรงสองข้อ: 1) คนที่เรียกใช้ AI สามารถ merge ได้ทันทีโดยไม่ต้องรีวิวโค้ด ทำให้โค้ดที่ไม่ได้ตรวจสอบอาจถูก deploy ออกไป 2) ไม่มีเจ้าของ PR ที่ชัดเจน จึงไม่รู้ว่าจะให้ใครรับผิดชอบหาก PR ไม่ถูก merge หรือถ้าเกิดปัญหาขึ้นมา เพราะงั้นเราจึงเปลี่ยนกลยุทธ์ให้ทุก PR มีมนุษย์เป็น owner และให้มีแค่ commit เท่านั้นที่ใช้ชื่อ AI ส่วนตัว PR เองเป็นความรับผิดชอบของมนุษย์ทั้งหมด
ประเด็นที่ว่า LLM หา bug ได้เก่งก็น่าสนใจ ฉันสงสัยว่ากว่าจะได้อัตราการตรวจจับ bug จริงที่สูงนั้น มี false positive เกิดขึ้นมากแค่ไหน เพราะจากประสบการณ์ของฉัน LLM มักตอบว่ามี bug ทั้งที่จริงไม่มี
เห็นด้วยมาก เวลาไปถามอะไร ChatGPT แล้วฉันไม่ชอบข้อเสนอของมัน ถ้าพูดว่า "ตรงนั้นฉันว่าไม่ค่อยใช่นะ?" มันก็เปลี่ยนคำตอบทันที ทั้งที่คำตอบแรกอาจถูกอยู่ก็ได้ แต่ถ้าผู้ใช้ดูไม่มั่นใจ มันก็สั่นคลอนง่าย เลยทำให้การตรวจสอบเครื่องมือให้ถูกต้องทำได้ไม่ง่าย
ในกรณีนี้ แต่ละไฟล์มี bug แค่จุดเดียว และบอตก็ถูกสั่งให้หาให้ได้อย่างแม่นยำเพียงหนึ่งจุดเท่านั้น สิ่งที่ได้ทั้งหมดเป็น false positive คือมันสร้าง bug ขึ้นมาในจุดที่ไม่มีปัญหาอะไรเลย
ความแตกต่างของเครื่องมือ AI code review ในตลาดตอนนี้อยู่ที่การจูนอัตราส่วนสัญญาณต่อสัญญาณรบกวนนี่เอง บางตัวแม่นยำกว่ามากและมี false positive น้อยกว่า
หน้าที่สำคัญที่สุดของโปรแกรมเมอร์คือการสร้างโค้ดที่ตัวเองมั่นใจและทำงานได้ถูกต้อง จะใช้ LLM หรือไม่ไม่ใช่ประเด็น สิ่งสำคัญคือเวลาส่ง PR ขึ้นไป คุณต้องมีท่าทีว่า "ฉันมั่นใจว่าการเปลี่ยนแปลงนี้แก้ปัญหาได้ และฉันเอาชื่อเสียงของตัวเองเป็นประกันได้" เพราะฉะนั้นไม่ว่าจะเป็นคนหรือ AI PR ก็ควรมีผู้ตรวจทานคนที่สองเสมอ
ฉันคิดว่าชื่อเสียงนี่แหละคือหัวใจ ไม่ใช่แค่เรื่องการเขียนโค้ด แต่รวมถึงงานเขียนภาษาธรรมชาติด้วย ต่อไปนี้ไม่ใช่ผู้เขียน แต่เป็นผู้เผยแพร่ที่จะต้องรับผิดชอบต่อเนื้อหา ไม่ว่าจะเป็นแชตบอตแค่ 5% หรือ 95% ถ้ามีปัญหาเกิดขึ้น ก็ควรตำหนิฉันซึ่งเป็นคนโพสต์ ไม่ใช่ยกข้ออ้างว่า "แชตบอตเป็นคนทำ"
นี่ยกตัวอย่างพวกวิศวกรอัตโนมัติเต็มรูปแบบอย่าง Devin เท่านั้น สถานการณ์เลยต่างจากวิศวกรทั่วไปอยู่เล็กน้อย
ทุกวันนี้มีวิศวกรจำนวนมากโยนโค้ดคุณภาพแย่ที่ AI สร้างมาแบบไม่รับผิดชอบ แล้วหวังให้เพื่อนร่วมงานช่วยจับปัญหาให้ สมัยก่อนเรื่องแบบนี้เกิดน้อยกว่า เพราะตัวการสร้างโค้ดเองยังเป็นงานที่ใช้แรงมาก
ฉันเห็นด้วยอย่างมากกับคำพูดที่ว่าหน้าที่ของคุณคือสร้างโค้ดที่เชื่อถือได้ แต่ถึงก่อนยุค AI มาตรฐานโค้ดที่ดีก็ไม่ได้ถูกยึดถือกันดีอยู่แล้ว เราเริ่มมองการเขียนโค้ดเป็นแค่เครื่องมือหรือช่องทางหาเงิน เดิมทีมันเคยมีความสนุกของการแก้ปัญหาและเปลี่ยนโลก แต่ตอนนี้เราไปโฟกัสกับการหาเงินให้เร็วหรือสร้างคูเมืองป้องกันตัวเอง สิ่งสำคัญไม่ใช่ว่าโค้ดสวยไหม แต่คือมันแก้ปัญหาได้อย่างมีชั้นเชิงหรือเปล่า AI อาจทำให้วัฒนธรรมนี้แย่ลงได้ แต่ท้ายที่สุดทุกอย่างขึ้นอยู่กับว่าเราใช้มันอย่างไร
มีเรื่องที่ฉันสงสัย ถ้า PR แก้ปัญหาหลักได้หมดแล้ว แต่มี bug เล็กน้อยปนอยู่ แบบนี้จะถือว่าเป็นการเสียเวลาหรือเปล่า อยากเห็นตัวอย่าง
การรีวิวโค้ดคือขั้นตอนที่ช้าที่สุดในงานวิศวกรรม ฉันเองก็เขียนโค้ดได้เร็วโดยไม่ต้องพึ่ง AI แต่การรีวิวไม่ได้เร็วขึ้น เพราะงั้นฉันเลยให้ AI ช่วยรีวิวล่วงหน้าก่อน เพื่อประหยัดเวลาของเพื่อนร่วมทีม และจับ bug ได้ตั้งแต่ก่อนส่ง ทำให้เวลาจากเขียนเสร็จจน deploy ลดลงได้เป็นวัน ๆ AI จับได้ทั้ง bug ที่เห็นชัดและความผิดพลาดที่ซ่อนอยู่ และเคยเจอถึงขั้น bug ลึก ๆ จริงด้วย ฉันใช้ workflow ที่คัดลอก diff ด้วย git cli กับ xclip แล้วเอาไปแปะในโมเดลสาย reasoning อย่าง o3 เพื่อขอรีวิว
ข้อดีอย่างหนึ่งของ AI คือมันเขียน unit test จำนวนมากได้เร็วกว่าคนมาก และยังแก้ปัญหาที่มันเจอเองได้ด้วย workflow ในอุดมคติไม่ใช่แค่รีวิวโค้ด แต่คือให้ AI รันทดสอบอัตโนมัติเองด้วย และตรวจให้แน่ใจว่าทุกอย่างผ่านสเปกที่กำหนด การมีเทสต์มากเกินไปอาจทำให้ refactor ยากขึ้นภายหลังได้ เช่น เทสต์ที่ผูกกับรายละเอียด implementation มากเกินไป และเวลาไม่อยากเก็บก็อาจทิ้งเฉพาะเทสต์ที่ AI เขียนได้
ฉันชอบมากที่สามารถสร้าง unit test ใหม่ได้ทุกครั้งที่ต้องการ ตอนส่งรีวิว ฉันรู้สึกพอใจมากกับขนาดของ diff และยังประหยัดเวลาจากงานเขียนเทสต์ที่น่าเบื่อ ทำให้ไปทำอย่างอื่นได้มากขึ้น
ตอนนี้งานเขียนโปรแกรมก็ยังมีงานจุกจิกน่ารำคาญเหลืออยู่ แต่ในอุดมคติ AI ควรช่วยลดความไร้ประสิทธิภาพพวกนี้ เพื่อให้มนุษย์ไปโฟกัสกับงานสร้างสรรค์ได้ อย่างไรก็ตาม ในความเป็นจริง AI กำลังรุกล้ำไปถึงงานสร้างสรรค์ระดับสูงขึ้นเรื่อย ๆ เช่นกัน
ที่จริงถึงไม่ใช้ AI ก็สามารถใช้เฟรมเวิร์ก property-based testing เพื่อสร้างเทสต์อัตโนมัติจากอินพุตจำนวนมหาศาลได้อยู่แล้ว
ตอนรีวิวโค้ดฉันมีกฎอยู่อย่างหนึ่ง: ถ้าฉันไม่มั่นใจว่าตัวเองจะดูแลมันต่อเองได้ในอนาคต ฉันจะไม่ approve ถ้าใช้ LLM ทั้งในการเขียนและรีวิวโค้ด ก็อาจมองได้ว่าเรากำลังเอาหลักความรับผิดชอบแบบเดียวกันไปใช้กับเครื่องมือด้วย แต่เอาเข้าจริงฉันไม่ค่อยมั่นใจว่าจะอยู่กับสภาพแบบนั้นได้นาน
อยากรู้ว่ามีใครเคยลองใช้ pipeline ที่ให้ LLM ตัวหนึ่งสร้างสคริปต์ Gherkin จาก requirement แล้วให้ LLM อีกตัวสร้างโค้ดจากสคริปต์นั้น จากนั้นใช้ Cucumber ตรวจผลลัพธ์บ้างไหม ไม่ว่าอย่างไรทั้งสคริปต์ Gherkin และโค้ดก็คงยังต้องรีวิวอยู่ดี แต่ฉันอยากรู้ว่ามีโค้ดประเภทไหนบ้างที่สร้างด้วยวิธีนี้ไม่ได้ ฉันมอง AI เหมือนเป็นนักพัฒนาคนหนึ่ง และเหมือนกับนักพัฒนามนุษย์ มันก็น่าจะมีด้านที่ทำได้ไม่ดีอย่างชัดเจน
สุดท้ายแล้ว ผู้เขียนที่ส่ง PR ขึ้นมาต้องรับผิดชอบต่อผลกระทบและผลลัพธ์ของโค้ดตัวเองอยู่ดี เมื่อ AI coding แพร่หลายขึ้นและมีวิศวกรจูเนียร์มากขึ้น ความรับผิดชอบนี้ยิ่งสำคัญ การให้ AI ทำหน้าที่เป็นด่านรีวิวรอบแรกถือว่าสมเหตุสมผล แต่ผู้รีวิวที่เป็นมนุษย์ก็ยังจำเป็นเพื่อเพิ่มความเข้าใจ codebase จากมุมมองภายนอก และช่วยค้นหาปัญหาในระดับที่สูงกว่า สรุปคือ โครงสร้างที่เหมาะสมที่สุดคือให้ AI รีวิวรอบแรก ให้วิศวกรอีกคนรีวิวในมิติของบริบทหรือการทำงานร่วมกัน และท้ายที่สุดผู้เขียนต้องเป็นผู้รับผิดชอบต่อทุกผลลัพธ์