เหตุใดการรีวิวโค้ด AI จึงไม่อาจเป็นข้อโต้แย้งที่สมเหตุสมผล

 (softwaremaxims.com)
1 คะแนน โดย GN⁺ 1 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แนวทางที่บอกว่ามนุษย์แค่ตรวจทานข้อผิดพลาดที่พบบ่อยของเครื่องมือเขียนโค้ดแบบ LLM ทั้งหมดก็พอ เป็นเรื่องยากที่จะรับประกันทั้งคุณภาพและประสิทธิภาพการผลิตไปพร้อมกัน เพราะ ขีดจำกัดในการประมวลผลของ code review
  • งานวิจัยเชิงประจักษ์ระบุว่ารีวิวที่มีประสิทธิภาพมีเพดานอยู่ราว 1 ชั่วโมง·400 LOC ต่อครั้ง และเมื่อเกินกว่านี้ ความเหนื่อยล้าและสมาธิที่ลดลงจะทำให้ประสิทธิภาพในการตรวจพบข้อบกพร่องลดลงอย่างรวดเร็ว
  • หากใช้เกณฑ์นี้ ทุก ๆ 400 LOC ที่ LLM เขียนขึ้นจะต้องใช้เวลาตรวจทานอย่างเข้มข้นจากนักพัฒนาผู้ชำนาญ 1 ชั่วโมง ทำให้ปริมาณงานที่ทำได้จริงต่อวันอาจอยู่ที่ ต่ำกว่า 1,000 LOC
  • มีหลักฐานเบื้องต้นว่ามนุษย์ตรวจพบข้อบกพร่องในโค้ดที่ LLM สร้างได้น้อยลง แต่กลับมี ความมั่นใจสูงกว่า จึงยากจะมองว่าการรีวิวเพียงอย่างเดียวสามารถกรองข้อผิดพลาดได้เพียงพอ
  • จำเป็นต้องมี งานวิจัยเชิงประจักษ์ ที่วัดและทำซ้ำได้โดยตรงเกี่ยวกับอัตราการตรวจพบข้อบกพร่องของโค้ดจาก LLM, ความเร็วในการรีวิว และปริมาณที่ทำได้อย่างยั่งยืนต่อวัน เพื่อประเมินประสิทธิผลของเครื่องมือบนฐานหลักฐาน ไม่ใช่เรื่องเล่าเฉพาะกรณี

เหตุผลที่มองเครื่องมือเขียนโค้ดแบบ LLM อย่างกังขา

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

อุปมาเรื่อง ‘อินเทิร์น’ และแนวทางตรวจทานครบถ้วน

  • เครื่องมือเขียนโค้ดแบบ LLM มีความเสี่ยงต่อข้อผิดพลาดค่อนข้างสูง ด้วยเหตุผลอย่างโครงสร้างการทำงานและอินเทอร์เฟซการโต้ตอบ
    • อาจสร้าง hallucination หรือพิมพ์ผิดได้
    • อาจให้ผลลัพธ์ที่ไม่เกี่ยวข้องกับคำขอ หรือดำเนินงานไปตามเส้นทางอื่น
  • ผู้ใช้มักเปรียบเครื่องมือเหล่านี้กับ อินเทิร์น
    • ต้องคาดว่าผลลัพธ์จะผิดอยู่บ้าง
    • ต้องถือว่ามันทำงานโดยไม่ได้เข้าใจจริง ๆ ว่ากำลังทำอะไร
  • วิธีรับมือที่ใช้กันแพร่หลายคือให้ผู้มีประสบการณ์ รีวิวทั้งหมด เหมือนโค้ดของอินเทิร์นหรือนักพัฒนาระดับ junior
    • ตั้งอยู่บนสมมติฐานว่ามนุษย์รู้ดีกว่าและเป็นผู้รับผิดชอบขั้นสุดท้าย
    • ตามมาด้วยตรรกะว่าโค้ดทุกชิ้นที่จะเข้าสู่ codebase ก็เป็นสิ่งที่ต้องรีวิวอยู่แล้ว

ระดับการรีวิวที่จำเป็นต่อการกำกับดูแล LLM

  • ในอุตสาหกรรมและวรรณกรรมวิจัย คำว่า รีวิว ครอบคลุมแนวปฏิบัติหลายแบบที่ต่างกัน
  • การรีวิวแบบเบาและกระจายให้หลายคนมีประโยชน์ต่อการแบ่งปันความรู้เกี่ยวกับการเปลี่ยนแปลงและการบังคับใช้กฎพื้นผิว แต่ยังไม่เพียงพอเป็นเกณฑ์ในการกำกับดูแลโค้ดจาก LLM
  • ไม่ถึงกับต้องตรวจทุกบรรทัดอย่างเจ็บปวดนานหลายชั่วโมงแบบการตรวจสอบโดยคณะกรรมการในอดีต แต่จำเป็นต้องมี code review ที่ลึกและครบถ้วนพอสมควร
  • เพราะ LLM สามารถเขียนโค้ดที่ซับซ้อนได้ และข้อบกพร่องในซอฟต์แวร์มักซ่อนอยู่ในรายละเอียด การตรวจแบบผิวเผินจึงไม่เพียงพอ

ขีดจำกัดเชิงประจักษ์ที่ code review ต้องเผชิญ

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

การคำนวณ throughput เมื่อนำไปใช้กับโค้ดจาก LLM

  • หากต้องแก้ปัญหาโค้ดจาก LLM ด้วยการรีวิว แม้ในกรณีดีที่สุดก็ต้องใช้เวลาของนักพัฒนาผู้ชำนาญ 1 ชั่วโมงต่อโค้ดที่สร้างขึ้นทุก 400 LOC
  • เซสชันรีวิวที่นักพัฒนารองรับได้อยู่ที่ราว 10–40 ครั้งต่อสัปดาห์ และระหว่างแต่ละเซสชันต้องมีเวลาฟื้นตัวที่ไม่ทราบความยาว
    • เวลาฟื้นตัวอาจอย่างน้อย 1–2 ชั่วโมง แต่ไม่มีงานวิจัยโดยตรงรองรับ
  • เวลาที่ต้องใช้สมาธิเช่นนี้ยังต้องใช้กับการประชุม การออกแบบ การรับมือเหตุขัดข้อง และการคิดเกี่ยวกับโค้ดที่ต้องเขียนเองด้วย
  • ในกรณีดีที่สุด นักพัฒนาที่ใช้ LLM อาจเขียน·รีวิว·commit ได้วันละหลายพัน LOC
  • ในสถานการณ์ที่สมจริง ปริมาณงานต่อวันอาจอยู่ที่ ต่ำกว่า 1,000 LOC
    • รวมทั้ง boilerplate, test, migration และไฟล์ตั้งค่าทั้งหมด
    • ไฟล์ test เพียงไฟล์เดียวก็อาจเกิน 400 LOC ได้
  • แม้ในเงื่อนไขดีที่สุดที่โค้ดส่วนใหญ่เรียบง่ายและรีวิวง่าย การรีวิวก็ยังทำหน้าที่เป็น เพดาน ของการเพิ่มผลิตภาพ

ความแตกต่างระหว่างการรีวิวโค้ดมนุษย์กับโค้ด LLM

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

ต้นทุนที่เกิดขึ้นก่อนแก้ไขข้อบกพร่อง

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

ความย้อนแย้งของการมอบหมายโค้ดที่รีวิวยาก

  • ฝ่ายสนับสนุน LLM ชูจุดแข็งว่าเครื่องมือสามารถผลิตโค้ดที่มนุษย์รู้สึกเจ็บปวดในการเขียนแทนได้
  • กรณีหนึ่งเสนอให้ LLM เขียน Bash code 100% ที่จำเป็นในอนาคต
  • Shell script มีการ parse ที่หลวมและความหมายซ้อนทับกันมากเกินไป ทำให้การพิมพ์ punctuation ผิดเพียงตัวเดียวอาจไม่เป็นอันตราย หรืออาจนำไปสู่การลบทั้งคอมพิวเตอร์ก็ได้
  • โค้ดประเภทนี้สร้างข้อผิดพลาดได้ง่าย เข้าใจและรีวิวยาก และสังเกตความผิดพลาดร้ายแรงได้ยาก
  • แนวทางที่ให้เครื่องมือซึ่งสุ่มสร้างข้อผิดพลาดรับผิดชอบโค้ดที่รีวิวยากที่สุด แล้วให้มนุษย์ตรวจทีหลัง ยังไม่ได้พิสูจน์ก่อนว่าผลลัพธ์จาก LLM เป็นสิ่งที่ตรวจทานได้อย่างมีประสิทธิภาพจริง
  • ปัญหาคือการใช้ โค้ดที่รีวิวยากที่สุด เป็นกรณีใช้งานตัวแทน ทั้งที่ยังไม่ได้ตอบว่าการรีวิวแก้ข้อผิดพลาดได้หรือไม่ และยังเหลือการเพิ่มผลิตภาพมากพอหรือไม่

งานเชิงประจักษ์ที่ต้องพิสูจน์

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

การประเมินเชิงประจักษ์ของเครื่องมือมืออาชีพ ไม่ใช่เรื่องเล่า

  • เมื่อพิจารณาข้อเท็จจริงที่รู้เกี่ยวกับ code review แล้ว ยังยากที่จะยืนยันว่าเครื่องมือ LLM ที่ใช้อินเทอร์เฟซและกระบวนการปัจจุบันให้ประโยชน์อะไรแก่นักพัฒนามืออาชีพ
  • สิ่งที่น่าหงุดหงิดมากกว่าการที่ผู้ให้บริการนำเสนอเครื่องมือและกระบวนการที่ขัดกับหลักฐานซ้ำ ๆ คือท่าทีที่ไม่รับมือกับปัญหา แต่กลับปฏิบัติต่อผู้กังขาเหมือนเป็นฝ่ายผิดปกติ
  • รูปแบบที่เรื่องเล่าเฉพาะกรณีมีอิทธิพลเหนือหลักฐานเชิงประจักษ์เกิดซ้ำมาแล้วใน TDD, type system, การแยกองค์กร test·development, CI/CD และ DevOps
  • แทนที่จะพึ่งกรณีว่า “ครั้งนี้มันได้ผลกับฉัน” ควรทำ งานวิจัยจริง ตามแนวทางที่ทำให้เกิดหลักฐานเชิงประจักษ์ของ code review
  • หากจะปฏิบัติต่อเครื่องมือเขียนโค้ดแบบ LLM ในฐานะเครื่องมือพัฒนาระดับมืออาชีพ ก็ต้องตรวจสอบประสิทธิผลและข้อจำกัดโดยมี human factors และหลักฐานเชิงประจักษ์เป็นศูนย์กลาง

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

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

 
GN⁺ 1 일 전
ความเห็นจาก Lobste.rs

  • ความเร็วไม่จำเป็นต้องเป็นเป้าหมายเดียวเสมอไป การแก้บั๊กสามารถแยกเป็นคอมมิตเตรียมการต่างหากเพื่อนำไปรีวิวอย่างอิสระได้ รวมถึงปรับโครงสร้าง type ที่สามารถแสดงสถานะที่ผิดพลาดได้ และถ้าความน่าเชื่อถือของการทดสอบยังไม่พอ ก็สามารถลองใช้ property-based testing, fuzzing และวิธีการเชิงรูปนัย ได้
    เมื่อก่อนงานแบบนี้มักถูกรวมไว้ในคอมมิตเดียวหรือทิ้งเป็น TODO ของหนี้เทคนิค แต่ตอนนี้ ต้นทุนส่วนเพิ่ม ที่ต้องใช้เพื่อทำให้ถูกต้องจริง ๆ ต่ำลงอย่างน่าตกใจ แล้ว LLM เป็นเครื่องมือแบบเปิดกว้าง จึงคืนประโยชน์ได้มากเท่ากับคุณค่าที่ผู้ใช้ให้ความสำคัญ
    แม้จะมีความเสี่ยงที่ต้นแบบซึ่งทำไม่เสร็จและไปไม่ถึง production จะเพิ่มขึ้น แต่โดยรวมแล้วมันช่วยงานวิศวกรรมที่ให้ความสำคัญกับความเข้มงวดได้มาก

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

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

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

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

  • ปัญหาเริ่มตั้งแต่ข้อเขียนนี้ถูกเขียนขึ้นเมื่อเกือบ 1 ปีก่อนแล้ว ในช่วง 6 เดือนที่ผ่านมา โดยเฉพาะ 3 เดือนล่าสุด ประโยชน์ใช้สอยของโมเดลคลาวด์แบบเสียเงินรุ่นล่าสุดเพิ่มขึ้นมาก
    เหมือนกับ หลักการ MFIC ที่พัฒนามาจากงานตรวจสอบ เราควรเช็กว่ามีมาตรการควบคุมที่ป้องกันหมวดหมู่ความล้มเหลวทั้งหมดได้หรือไม่: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
    และยังต้องมีเครื่องมืออย่าง https://github.com/pmarreck/dirtree และ https://github.com/pmarreck/codescan ที่ช่วยคงบริบทของโค้ดและโครงสร้างโปรเจ็กต์เดิมไว้ ซึ่งมีประโยชน์กับนักพัฒนามนุษย์ที่ลืมหรือไม่คุ้นกับ codebase เช่นกัน
    ท้ายที่สุดแล้ว คุณจะใช้มันให้ถูกต้องและได้เปรียบ หรือจะเขียนโค้ดเฉพาะทางเอง พร้อมสร้างบั๊กและช่องโหว่ด้านความปลอดภัย แล้วโดนคู่แข่งที่เร็วกว่าแซงไปก็ได้ จากมุมของคนที่เคยใช้เวลา 2 คน-ปีกับ codebase Ruby on Rails ระดับล้านบรรทัดของ Desk.com ที่ถูกทิ้งไป โค้ดองค์กรเป็นของชั่วคราว จึงเข้ากันได้ดีกับโค้ดที่ LLM สร้าง
    ถ้าเป็น implementation ภายในของ Erlang ก็คงไว้ใจยาก แต่ก็ยังให้มันเขียนเป็นระดับฟังก์ชันแล้วนำมารีวิวได้ และบางครั้งผลก็อาจดีกว่าที่คาดไว้ ทางที่เหมาะคือไม่เลือกแค่อย่างใดอย่างหนึ่งระหว่างไม้นิตกับกี่ทอผ้า แต่ใช้ทั้งคู่ตามสถานการณ์

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

  • จากประสบการณ์ส่วนตัวและจากนักพัฒนาฝีมือดีที่ไว้ใจได้รอบตัว LLM ทำให้การเขียนโค้ดที่ดีกว่าและเร็วกว่าทำได้ซ้ำ ๆ ดังนั้นจึงยากจะรับบทความที่บอกว่าตามหลักฐานทางวิทยาศาสตร์มันไม่มีทางช่วยได้อย่างจริงจัง
    ต่อให้ไม่มีงานวิจัยแบบ peer-reviewed ผมก็เห็นมามากพอแล้ว และแม้ งานวิจัยของ METR ชิ้นหนึ่งจะโต้แย้งการประเมินเรื่องผลิตภาพที่เพิ่มขึ้นของนักพัฒนา ผมก็จะไม่เปลี่ยนข้อสรุปเดิม

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

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

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

  • แม้โมเดลแนวหน้าจะเขียนโค้ดได้มหาศาล แต่ผมแปลกใจที่คนไม่ค่อยสำรวจอย่างจริงจังถึง contribution เชิงลบ ที่เสนอให้ลบโค้ดออก อย่าง “The Best Code is No Code At All” - Jeff Atwood ถ้ามันสามารถช่วยคลี่และลดความซับซ้อนของ codebase ที่พองตัวจากชั้น abstraction หลายระดับ แล้วเสนอการลบบรรทัดโค้ดได้ ก็น่าจะสดใหม่ดี
    มันอาจทำได้แล้วก็ได้ แต่ผมยังไม่เคยเห็นด้วยตัวเอง

  • ขอแก้ไขว่าในหัวข้อ “The Limits Of Reviews” นั้นระบุความเร็วสูงสุดที่มีประสิทธิภาพไว้ที่ 400 บรรทัดต่อชั่วโมง ไม่ใช่ 400 บรรทัดต่อการรีวิวอย่างที่ผมคิดตอนแรก
    แต่ก็ยังสงสัยอยู่ดีว่าตัวเลข 1 ชั่วโมงกับ 400 บรรทัดนี้มาจากงานวิจัยด้าน code review ฉบับไหนกันแน่ ถ้าไม่ได้เก็บชื่อบทความไว้ก็ไม่จำเป็นต้องเสียเวลามากไปกับการย้อนหาใหม่

    • ผมเก็บข้อมูลอ้างอิงที่เกี่ยวข้องไว้ที่ไหนสักแห่ง จึงน่าจะตรวจสอบได้ ส่วนใหญ่ระบุเพดานไว้ที่ 100~200 บรรทัดต่อชั่วโมง แต่ก็มีงานวิจัยเก่าเยอะที่ศึกษายุคซึ่งภาษาโปรแกรมมีแนวโน้มเกิดบั๊กง่ายกว่าทุกวันนี้
      ตอนนี้ผมกำลังเดินทางอยู่ ไว้อีกสองสามวันช่วยสะกิดผมอีกที
    • ตัวเลข 400 บรรทัดต่อชั่วโมงดูน่าสงสัย ผมเลยลองคำนวณจากบันทึกงานของตัวเอง ช่วง 6 เดือนที่ผ่านมา ผมรีวิว PR 173 รายการ คิดเป็นการเปลี่ยนแปลงรวม 139,000 บรรทัด
      ถ้าจากเวลาทำงาน 40 ชั่วโมงต่อสัปดาห์ ใช้กับการรีวิว 25% ก็จะได้ราว 540 บรรทัดต่อชั่วโมง ถ้า 15% ก็ 900 บรรทัด และถ้า 5% ก็ 2,700 บรรทัด ปริมาณงานจริงน่าจะอยู่ที่ 500~1,000 บรรทัดต่อชั่วโมง ซึ่งก็ใกล้เคียงอยู่บ้างกับตัวเลขที่ไม่มีการอ้างแหล่งมาให้

  • ผมไม่ค่อยเข้าใจตรรกะที่ว่าโค้ดที่ AI สร้างควรถูกรีวิวมากกว่าหรือน้อยกว่าโค้ดที่มนุษย์เขียน เพราะเกณฑ์การอนุมัติเหมือนกัน จึงควร รีวิวในระดับเดียวกัน