“ปัญหาไม่ได้อยู่ที่ AI เขียนโค้ดได้เร็วแค่ไหน แต่อยู่ที่มนุษย์จะตรวจทันหรือเปล่าต่างหาก”
เมื่อวานนั่งคุยกับเพื่อนร่วมงานแล้วอดคิดไม่ได้ ตอนนี้พวกเราแทบทุกคนใช้ agent เขียนโค้ดกันแบบเป็นเรื่องปกติ บางตัวก็ดีจริง บางตัวก็แบบ...เออ ผ่านๆ ไปเถอะ แต่ที่สะดุดใจจริงๆ คือตอนนี้ quality gate ของโปรเจกต์มันไม่ได้อยู่ที่การเขียนโค้ดแล้ว แต่มันไปอยู่ที่ขั้นตอน human review แทน เพราะโค้ดที่ AI สร้างมามันเยอะมากจนเราตามไม่ทันจริงๆ
ผมลองใช้เครื่องมือ AI review อย่าง coderabbit หรือ copilot รวมถึงการเอา claude code ไปจ่อที่ PR ก็พบว่ามันเก่งเรื่องหา bug หรือเรื่องสไตล์การเขียน แต่พอเป็นเรื่องเชิงสถาปัตยกรรมอย่างโค้ดซ้ำซ้อนกันหลายที่ การที่โมดูลมันผูกกันเกินไป หรือการแยกความรับผิดชอบไม่ชัดเจน พวกมันทำได้ไม่ดีเท่าไหร่ ต่อให้เราสั่ง prompt ไปตรงๆ ก็ยังได้ผลไม่เต็มที่ กว่าจะจับได้ก็ตอนที่เพื่อนมนุษย์นั่งไล่ดูเองนี่แหละ
ที่หนักกว่าคือตัว interface ของ GitHub PR เองก็เริ่มรับไม่ไหวแล้ว เดิมที review เล็กๆ ก็รู้สึกว่ามันไม่ลื่นไหลเท่าไหร่ พอตอนนี้ PR มันใหญ่ขึ้นเป็นเท่าตัวเพราะ AI ช่วยเขียน บวกกับมีเสียงรบกวนจากการ review อัตโนมัติของ agent แล้วก็คนที่เอาผลลัพธ์จาก agent มาวางเฉยๆ โดยไม่ได้กลั่นกรองอะไรเลย มันยิ่งรกและหาจุดสำคัญยากขึ้นไปอีก ผมรู้สึกว่าเรากำลังจมอยู่กับข้อมูลจำนวนมากโดยที่เครื่องมือเดิมไม่ได้ถูกออกแบบมาเพื่อรับมือกับขนาดแบบนี้
ส่วนตัวผมว่าการที่เราจะฝากความหวังให้ AI ช่วยตรวจ AI กันเองมันก็เหมือนเอาคนเดียวกันมาสอบข้อสอบตัวเอง มันไม่เห็นจุดบอดของตัวเองหรอก สิ่งที่เราน่าจะต้องการคือกระบวนการที่ทำให้มนุษย์เห็นภาพรวมของ PR ใหญ่ๆ ได้ง่ายขึ้น เช่น การบังคับให้แยกการ review เป็นเรื่อง logic กับเรื่อง architecture ออกจากกัน หรือเครื่องมือที่ช่วย diff โค้ดที่ AI เขียนเทียบกับโค้ดเดิมในโปรเจกต์ให้เห็นภาพว่ามันไปแตะอะไรบ้างโดยไม่ต้องไล่เปิดทีละไฟล์ อยากรู้ว่าเพื่อนๆ ในนี้ที่เจอปัญหาเดียวกัน มีวิธีหรือเครื่องมืออะไรที่ใช้แล้วเวิร์คจริงๆ ช่วยแนะนำกันหน่อยได้ไหมครับ โดยเฉพาะเรื่องการจัดการ PR ที่มีขนาดใหญ่มากๆ นี่น่ะ แล้วพวกที่ว่า "meat-proxying" นี่เพื่อนๆ มีวิธีจัดการกับคนที่ส่งงานโดยไม่อ่านเลยบ้างไหม หรือว่าเราต้องยอมรับมันเป็นเรื่องปกติของยุคนี้แล้ว?
เมื่อวานนั่งคุยกับเพื่อนร่วมงานแล้วอดคิดไม่ได้ ตอนนี้พวกเราแทบทุกคนใช้ agent เขียนโค้ดกันแบบเป็นเรื่องปกติ บางตัวก็ดีจริง บางตัวก็แบบ...เออ ผ่านๆ ไปเถอะ แต่ที่สะดุดใจจริงๆ คือตอนนี้ quality gate ของโปรเจกต์มันไม่ได้อยู่ที่การเขียนโค้ดแล้ว แต่มันไปอยู่ที่ขั้นตอน human review แทน เพราะโค้ดที่ AI สร้างมามันเยอะมากจนเราตามไม่ทันจริงๆ
ผมลองใช้เครื่องมือ AI review อย่าง coderabbit หรือ copilot รวมถึงการเอา claude code ไปจ่อที่ PR ก็พบว่ามันเก่งเรื่องหา bug หรือเรื่องสไตล์การเขียน แต่พอเป็นเรื่องเชิงสถาปัตยกรรมอย่างโค้ดซ้ำซ้อนกันหลายที่ การที่โมดูลมันผูกกันเกินไป หรือการแยกความรับผิดชอบไม่ชัดเจน พวกมันทำได้ไม่ดีเท่าไหร่ ต่อให้เราสั่ง prompt ไปตรงๆ ก็ยังได้ผลไม่เต็มที่ กว่าจะจับได้ก็ตอนที่เพื่อนมนุษย์นั่งไล่ดูเองนี่แหละ
ที่หนักกว่าคือตัว interface ของ GitHub PR เองก็เริ่มรับไม่ไหวแล้ว เดิมที review เล็กๆ ก็รู้สึกว่ามันไม่ลื่นไหลเท่าไหร่ พอตอนนี้ PR มันใหญ่ขึ้นเป็นเท่าตัวเพราะ AI ช่วยเขียน บวกกับมีเสียงรบกวนจากการ review อัตโนมัติของ agent แล้วก็คนที่เอาผลลัพธ์จาก agent มาวางเฉยๆ โดยไม่ได้กลั่นกรองอะไรเลย มันยิ่งรกและหาจุดสำคัญยากขึ้นไปอีก ผมรู้สึกว่าเรากำลังจมอยู่กับข้อมูลจำนวนมากโดยที่เครื่องมือเดิมไม่ได้ถูกออกแบบมาเพื่อรับมือกับขนาดแบบนี้
ส่วนตัวผมว่าการที่เราจะฝากความหวังให้ AI ช่วยตรวจ AI กันเองมันก็เหมือนเอาคนเดียวกันมาสอบข้อสอบตัวเอง มันไม่เห็นจุดบอดของตัวเองหรอก สิ่งที่เราน่าจะต้องการคือกระบวนการที่ทำให้มนุษย์เห็นภาพรวมของ PR ใหญ่ๆ ได้ง่ายขึ้น เช่น การบังคับให้แยกการ review เป็นเรื่อง logic กับเรื่อง architecture ออกจากกัน หรือเครื่องมือที่ช่วย diff โค้ดที่ AI เขียนเทียบกับโค้ดเดิมในโปรเจกต์ให้เห็นภาพว่ามันไปแตะอะไรบ้างโดยไม่ต้องไล่เปิดทีละไฟล์ อยากรู้ว่าเพื่อนๆ ในนี้ที่เจอปัญหาเดียวกัน มีวิธีหรือเครื่องมืออะไรที่ใช้แล้วเวิร์คจริงๆ ช่วยแนะนำกันหน่อยได้ไหมครับ โดยเฉพาะเรื่องการจัดการ PR ที่มีขนาดใหญ่มากๆ นี่น่ะ แล้วพวกที่ว่า "meat-proxying" นี่เพื่อนๆ มีวิธีจัดการกับคนที่ส่งงานโดยไม่อ่านเลยบ้างไหม หรือว่าเราต้องยอมรับมันเป็นเรื่องปกติของยุคนี้แล้ว?
ความคิดเห็น 1
กำลังโหลดความคิดเห็น...