โรงงานซอฟต์แวร์ต้องการรอบการตรวจสอบที่รวดเร็วยิ่งขึ้น: การเพิ่มประสิทธิภาพเส้นทางจาก PR ไปสู่การ merge

TL;DR

ในองค์กรวิศวกรรมแบบ AI-native การสร้างโค้ดไม่ใช่ขั้นตอนที่ช้าที่สุดในการส่งซอฟต์แวร์อีกต่อไป การรีวิว การตรวจสอบ การซ่อมแซม และการตัดสินใจโดยมนุษย์กลายเป็นจุดคอขวด และเป็นตัวกำหนดว่าองค์กรจะเคลื่อนที่ได้เร็วขึ้นแค่ไหน เครื่องมือเขียนโค้ด AI แบบ standalone อาจเพิ่มความเร็วได้ 30–40% แต่การจะก้าวกระโดดด้านปริมาณงานต้องปรับปรุงทุกอย่างที่เกิดขึ้นหลังจากเขียนโค้ดเสร็จ

ใน โพสต์ก่อนหน้าของเราเกี่ยวกับการแก้ปัญหาการรีวิวโค้ดด้วย Cosmos เราได้อธิบายระบบรีวิวที่ช่วยให้องค์กรวิศวกรรมของเราเพิ่มปริมาณโค้ดได้ 3 เท่า พร้อมลดเวลา merge โดยเฉลี่ยและรักษาคุณภาพไว้ ตั้งแต่นั้นมา เราได้ขยายระบบนั้นไปไกลกว่าการรีวิว สู่กระบวนการ PR-to-merge แบบครบวงจร: เอเจนต์เฉพาะทางจัดการงานเชิงกล ตรวจสอบความถูกต้อง และจัดการกับฟีดแบ็ก ขณะที่มนุษย์ให้การตัดสินใจและการถ่ายทอดความรู้ และเป็นผู้ตัดสินใจขั้นสุดท้ายในการ merge เสมอ

นี่คือ loop engineering: การปรับปรุงระบบทั้งหมดที่เปลี่ยนโค้ดที่สร้างขึ้นให้เป็นการเปลี่ยนแปลงที่ผ่านการตรวจสอบ เข้าใจ และพร้อม merge แทนที่จะปรับแต่งเครื่องมือใดเครื่องมือหนึ่งเพียงลำพัง

ทำไม "เครื่องมือรีวิวโค้ด AI" อย่างเดียวไม่พอ

เครื่องมือรีวิวโค้ด AI ทั่วไปอย่าง CodeRabbit หรือ Greptile วิเคราะห์ diff แล้วโพสต์คอมเมนต์ มีประโยชน์ แต่การรีวิวเป็นเพียงขั้นตอนเดียว ตัวถ่วงที่แท้จริงคือห่วงโซ่ของการส่งต่องานระหว่างมนุษย์:

• การสร้างเจตนาและสถาปัตยกรรมขึ้นมาใหม่
• การคัดกรองการเปลี่ยนแปลงที่มีความเสี่ยงต่ำ
• การนำฟีดแบ็กจากรีวิวไปปรับใช้
• การแก้ไข CI ที่ล้มเหลวและ merge conflicts
• การตรวจสอบพฤติกรรมของฟีเจอร์แบบ end-to-end
• การรวบรวมหลักฐานให้เพียงพอต่อการปล่อยซอฟต์แวร์อย่างปลอดภัย
• การรีวิวซ้ำหลังการ push แต่ละครั้ง

กระบวนการ PR-to-merge จะทำให้ Expert เฉพาะทางทำงานผ่านการรีวิว การซ่อมแซม การตรวจสอบ และการสนับสนุนการตัดสินใจ ไปจนกว่ามนุษย์จะ merge ได้อย่างมั่นใจ Expert แต่ละตัวในกลุ่มจะเป็นเจ้าของงานส่งต่อหนึ่งอย่างหรือมากกว่า เปลี่ยนลำดับงาน manual ที่กระจัดกระจายให้เป็นระบบที่ประสานงานกัน เป้าหมายคือการปรับ ทั้ง loop ให้เหมาะสมที่สุด: เวลาของมนุษย์ ต้นทุน คุณภาพ และความหน่วงของการ merge ไม่ใช่เวลาจนกว่าจะได้คอมเมนต์แรก

1. ภาพรวม: การออกแบบกระบวนการแบบครบวงจร

อ่านคำอธิบายภาพ

ALT

กระบวนการรีวิวโค้ดแบบ AI-native: เอเจนต์ค้นหาและแก้ไขบั๊ก ตรวจสอบการเปลี่ยนแปลง และประเมินนโยบาย มนุษย์ตัดสินใจในประเด็นที่ต้องใช้ดุลยพินิจและตัดสินใจ merge ขั้นสุดท้าย

ระบบเดิมของเราแยกการวิเคราะห์ความเสี่ยง (Risk Analyzer) การรีวิวความถูกต้องแบบทีละบรรทัด (Deep Reviewer) และการรีวิวการออกแบบที่นำโดยมนุษย์ (Pair Review) ออกจากกัน ระบบที่ขยายใหม่นี้เพิ่มการซ่อมแซม การตรวจสอบตอนรันไทม์ และการ auto-approval ที่ขยายขอบเขตมากขึ้น ซึ่งช่วยลดคอขวดที่มนุษย์ลงได้อีก สำหรับภาพรวมของ Cosmos และ Expert ที่ปรับแต่งได้ ดูได้จาก โพสต์ก่อนหน้าของเราเกี่ยวกับการแก้ปัญหาการรีวิวโค้ดด้วย Cosmos

Expert และความสามารถเฉพาะทาง ไม่ใช่ผู้รีวิวเอนกประสงค์ตัวเดียว

Expert หรือความสามารถ

หน้าที่รับผิดชอบ

Risk Analyzer

จำแนกระดับความเสี่ยงและใช้โยบาย auto-approval

Deep Reviewer

วิเคราะห์แบบละเอียดทีละบรรทัดเพื่อหาข้อบกพร่องด้านความถูกต้องที่เป็นรูปธรรม

Pair Reviewer

สร้างเจตนา สถาปัตยกรรม บริบทของผลิตภัณฑ์ และ tradeoffs ขึ้นมาใหม่

Memory Manager

จดจำฟีดแบ็กจาก PR และเซสชัน Pair Review เพื่อปรับปรุงการทำงานในครั้งต่อ ๆ ไป

Verifier

<sup>

ใหม่

</sup>

ทดสอบพฤติกรรมที่ได้รับผลกระทบแบบ end-to-end ในสภาพแวดล้อมทดสอบ (

บล็อก Verifier

)

PR Fixer

<sup>

ใหม่

</sup>

ซ่อมแซมข้อค้นพบจากการรีวิว CI ที่ล้มเหลว และ merge conflicts

Review Dashboard

<sup>

ใหม่

</sup>

สังเกตและสรุปสถานะของ expert

cosmos approve

<sup>

ใหม่

</sup>

ประเมินนโยบายการอนุมัติที่ปรับแต่งได้เมื่อผู้เขียนร้องขอ

ความแตกต่างระหว่าง Deep Reviewer และ Pair Reviewer มีความสำคัญเป็นพิเศษ:

• Deep Reviewer ถามว่า: "มีบั๊กเชิงรูปธรรมใน implementation นี้หรือไม่?" มันทำงานอัตโนมัติและตรวจ PR กับแนวทางใน AGENTS.md หรือ CLAUDE.md

• Pair Reviewer ถามว่า: "การเปลี่ยนแปลงนี้สมเหตุสมผลในระบบโดยรวมหรือไม่ และการตัดสินใจแบบไหนที่ต้องใช้ดุลยพินิจของมนุษย์?" มันทำงานแบบโต้ตอบกับมนุษย์ มนุษย์ยังสามารถสั่งให้มันติดตาม PR หลังจากโพสต์คอมเมนต์รีวิว และอนุมัติแทนตนได้เมื่อคอมเมนต์เหล่านั้นได้รับการจัดการแล้ว

ก่อนหน้านี้ PR Author Expert ทำงานสองบทบาท: เขียน PR และแก้ไขคอมเมนต์รีวิว CI ที่ล้มเหลว และงานติดตามอื่น ๆ ในการออกแบบแบบแยกส่วนนี้ PR Author หยุดที่การสร้าง draft PR และ PR Fixer เข้ามารับช่วงต่อ ทำให้ผู้ใช้ควบคุมวิธีการทำงานของ fixes ได้มากขึ้น และรองรับ PR ที่สร้างโดยไม่ใช้ PR Author

Review Dashboard รวมสถานะของ Expert คอมมิตที่รีวิวแล้ว หลักฐาน และการดำเนินการที่ทำได้ไว้ในมุมมองเดียว

2. การออกแบบให้มนุษย์อยู่ในกระบวนการ

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

ทำไมมนุษย์ยังต้องอยู่ในกระบวนการ

เอเจนต์สามารถทำงานวิเคราะห์เชิงกลและลงมือทำได้เป็นจำนวนมาก แต่พวกมันไม่มีบริบททางธุรกิจและองค์กรที่ครบถ้วน มนุษย์จึงยังจำเป็นสำหรับ:

• การตัดสินใจที่ต้องใช้ดุลยพินิจ: ตรรกะนี้ควรอยู่ฝั่ง frontend หรือ backend? tradeoff นี้เหมาะสมกับผลิตภัณฑ์หรือไม่? ความเสี่ยงนี้ยอมรับได้ในตอนนี้หรือไม่?

• การถ่ายทอดความรู้: การรีวิวเป็นหนึ่งในวิธีที่วิศวกรสร้างความเข้าใจร่วมกันเกี่ยวกับสถาปัตยกรรมและพฤติกรรมของผลิตภัณฑ์

• ความเป็นเจ้าของและความรับผิดชอบ: เอเจนต์ไม่ได้เป็นเจ้าของซอฟต์แวร์หลังจากที่ปล่อยออกไป มนุษย์นักพัฒนาและองค์กรวิศวกรรมต่างหากที่เป็นเจ้าของ ดังนั้นมนุษย์จึงเป็นผู้ตัดสินใจขั้นสุดท้ายและคลิก Merge เสมอ ไม่มี expert ตัวใด merge PR

เป้าหมายการออกแบบจึงเป็น:

เอเจนต์ทำงานเชิงกล มนุษย์ตัดสินใจเรื่องสำคัญ

เวิร์กโฟลว์ของผู้เขียนและผู้รีวิว: ก่อนและหลัง

เวิร์กโฟลว์แบบเดิม

เวิร์กโฟลว์แบบมีมนุษย์อยู่ในกระบวนการ

คัดกรองทุก PR ด้วยตนเองและระบุการเปลี่ยนแปลงที่มีความเสี่ยงต่ำ

ให้

Risk Analyzer

จำแนกความเสี่ยงและใช้โยบาย auto-approval ขององค์กร

อ่าน PR ทีละบรรทัด

เชื่อใจ

Deep Reviewer

ให้วิเคราะห์แบบละเอียดทีละบรรทัด

สร้างบริบท เจตนา และสถาปัตยกรรมขึ้นมาใหม่จาก diff

ใช้ข้อมูลสรุปจาก

Pair Reviewer

เพื่อทำความเข้าใจการเปลี่ยนแปลงและระบุประเด็นที่ต้องใช้ดุลยพินิจ

ติดตั้งและทดสอบฟีเจอร์ด้วยตนเอง

ตรวจสอบ

หลักฐานจาก Verifier:

สกรีนช็อต ล็อก trace และ output ที่บันทึกไว้

รีวิวทุก fix ใหม่ตั้งแต่ต้น

ให้

Pair Reviewer

ติดตามว่าคอมเมนต์ที่ได้รับอนุญาตได้รับการจัดการแล้วหรือยัง

คัดกรองฟีดแบ็ก ลงมือแก้ไข ซ่อม CI แก้ไข conflicts และอธิบายการเปลี่ยนแปลงแต่ละอย่าง

ให้

PR Fixer

—หรือ

PR Author

เมื่อมันดูแล lifecycle ทั้งหมด—จัดการงานติดตามเชิงกลและรายงานสิ่งที่เปลี่ยนไป

ค้นหาสถานะปัจจุบันจากคอมเมนต์และการตรวจสอบทั้งหมด

ใช้

Review Dashboard

เป็นจุดเริ่มต้น

รวบรวมหลักฐานการรีวิว ความเป็นเจ้าของ และการตรวจสอบด้วยตนเองก่อนขออนุมัติ

เรียกใช้

cosmos approve

เพื่อประเมินนโยบายการอนุมัติที่ตั้งค่าไว้กับหลักฐานปัจจุบัน

ตัดสินใจว่าจะ merge หรือไม่

ยังคงต้องตัดสินใจว่าจะ merge หรือไม่

แนวคิดเชิงเศรษฐศาสตร์ของการใช้ expert หลายตัว

Token ที่ช่วยลดเวลาของมนุษย์ในคอขวดของการรีวิวได้อย่างเป็นรูปธรรมนั้นคุ้มค่ากับการลงทุน เมื่อ Expert เปลี่ยนเวลารีวิวและการดูแล PR หลายชั่วโมงให้เหลือไม่กี่นาที พวกมันจะปลดปล่อยดุลยพินิจทางวิศวกรรมอันมีค่าให้ไปใช้กับการตัดสินใจสำคัญที่มีแต่มนุษย์เท่านั้นที่ทำได้ พร้อมกับช่วยให้ฟีเจอร์ถึงมือลูกค้าได้เร็วขึ้น

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

3. ต้นทุนและคุณภาพ: ปรับต้นทุนต่อผลลัพธ์ที่สำเร็จให้เหมาะสม

โมเดลที่ถูกที่สุดในแง่ราคาต่อ token มักเป็นความประหยัดที่หลอกลวง การพลาดบั๊ก การซ่อมที่แย่ หรือการลองใหม่ อาจมีต้นทุนแพงกว่าการทำให้ถูกต้องตั้งแต่ครั้งแรก เราวัดประสิทธิภาพกับงานตัวแทน และเลือกโมเดลต้นทุนต่ำสุดที่ผ่านเกณฑ์คุณภาพของ Expert แต่ละตัว ตาม หลักการ cost-per-success แบบเดียวกับที่เราใช้ทั่วทั้ง Cosmos

ปัจจุบัน เราใช้ GPT-5.6 Sol สำหรับงานที่ต้องใช้ดุลยพินิจหนัก เช่น การวิเคราะห์ความเสี่ยง การรีวิวแบบ Deep และ Pair และการซ่อมโค้ด ส่วนงานที่จำกัดขอบเขตและตรวจสอบได้เชิงกล เช่น การรวมข้อมูลใน dashboard และการติดตาม merge conflicts ใช้ GPT-5.6 Luna โมเดลที่มี cache TTL ยาวกว่ายังเหมาะกับเอเจนต์ที่ทำงานยาวนาน เพราะ input ที่ถูก cache มักได้ส่วนลด 90%

4. เส้นทางการอนุมัติที่ปรับแต่งได้ด้วย cosmos approve

Risk Analyzer สามารถอนุมัติการเปลี่ยนแปลงที่มีความเสี่ยงต่ำโดยธรรมชาติภายใต้นโยบายแบบอนุรักษ์นิยมได้เสมอมา ตอนนี้เรารองรับโหมดการอนุมัติแบบที่สองซึ่งปิดไว้โดยค่าเริ่มต้น สำหรับการเปลี่ยนแปลงอื่น ๆ

ผู้เขียน PR สามารถคอมเมนต์ cosmos approve เพื่อขอให้ประเมินตามนโยบายการอนุมัติ มนุษย์ยังคงเป็นเจ้าของและดำเนินการ merge ขั้นสุดท้าย

องค์กรกำหนดนโยบายการอนุมัติของตนเอง นโยบายภายในของเราตรวจสอบ:

1. ความเป็นเจ้าของ: ผู้ร้องขอคือผู้เขียน PR และผู้เขียนเป็น CODEOWNER ที่มีผลจริงสำหรับทุกไฟล์ที่ถูกแก้ไข

1. การรีวิวที่ HEAD ปัจจุบัน: ไม่มีข้อค้นพบจาก Deep Reviewer ที่ยังไม่ได้รับการแก้ไข ตัวบล็อกจาก Pair Reviewer หรือคอมเมนต์ของมนุษย์ที่ยังไม่ได้รับการจัดการ

1. ไม่มีหลักฐานตอนรันไทม์ที่ขัดแย้ง: Verifier ไม่ได้รายงานข้อบกพร่องที่ยังไม่ได้รับการจัดการกับคอมมิตปัจจุบัน

5. ความสามารถในการปรับแต่งเป็นส่วนหนึ่งของสถาปัตยกรรม

เราออกแบบกลุ่ม Expert ให้ทีมต่าง ๆ สามารถปรับแต่ง loop ได้ด้วย Cosmos Advisor

• กลุ่ม Expert: เพิ่ม ลบ หรือเปลี่ยน expert; เลือกโมเดลและ prompt สำหรับแต่ละหน้าที่

• การทำงาน: ตั้งค่า triggers เครื่องมือ integrations และสภาพแวดล้อมการตรวจสอบ

• การควบคุม: จำกัดว่าผู้ใดเรียกใช้การดำเนินการได้ และ expert แต่ละตัวเข้าถึง credentials repositories และระบบใดได้บ้าง

• นโยบาย: กำหนดกฎการอนุมัติ การตรวจสอบที่จำเป็น ข้อกำหนด CODEOWNER และหลักฐานที่ยอมรับได้

รูปแบบการดำเนินงานสำหรับการรีวิว PR แบบ AI-native

บทเรียนจากเวอร์ชันแรกของเราคือ การรีวิวโค้ดไม่สามารถ scale ได้ด้วยการให้มนุษย์อ่านโค้ดที่ AI สร้างให้เร็วขึ้น บทเรียนจากเวอร์ชันนี้กว้างกว่า: ไม่มีเอเจนต์รีวิวตัวใดตัวหนึ่งสามารถปรับเส้นทางทั้งหมดไปสู่การ merge ให้เหมาะสมที่สุดได้

PR-to-merge loop ที่ทำงานได้ดีต้องมี:

• ความเชี่ยวชาญเฉพาะของเอเจนต์: แยกงานด้านความเสี่ยง ความถูกต้อง ดุลยพินิจด้านการออกแบบ การตรวจสอบตอนรันไทม์ และการซ่อมแซมออกจากกัน

• ลดจุดตรวจของมนุษย์ให้น้อยที่สุด: ดึงมนุษย์เข้ามาเฉพาะการตัดสินใจเรื่องสำคัญและการถ่ายทอดความรู้

• หลักฐาน: ให้ผู้รีวิวเห็นหลักฐานที่ตรวจสอบได้ ไม่ใช่แค่ข้อสรุปที่ไม่มีข้อมูลสนับสนุน

• วงจรการซ่อมแซม: ให้ข้อค้นพบไหลกลับเข้าสู่การ implement โดยไม่ต้องรอการแทรกแซงด้วยมือ

• การสังเกตได้: ทำให้สถานะของกลุ่ม Expert ทั้งหมดอ่านเข้าใจได้ในที่เดียว

• วินัยด้านต้นทุน: ใช้โมเดลที่ถูกที่สุดที่ผ่านเกณฑ์คุณภาพสำหรับแต่ละหน้าที่

• การปรับแต่งได้: ปรับแต่ง loop ให้เข้ากับข้อกำหนดเฉพาะของแต่ละองค์กร

• ความเป็นเจ้าของโดยมนุษย์: ให้การตัดสินใจ merge ขั้นสุดท้ายอยู่กับคนที่รับผิดชอบซอฟต์แวร์

นี่คือ loop engineering ที่นำมาประยุกต์กับวงจรชีวิตของ PR: ปรับระบบที่ผลิตการเปลี่ยนแปลงที่ผ่านการตรวจสอบ เข้าใจ และพร้อม merge ให้เหมาะสมที่สุด ไม่ใช่ปรับปริมาณ output ของเอเจนต์ตัวใดตัวหนึ่ง

สร้าง PR-to-merge loop ของคุณเอง

Cosmos มอบบริบทที่ใช้ร่วมกัน ตัวควบคุมตอนรันไทม์ integrations และจุดตรวจของมนุษย์ให้ทีมวิศวกรรม เพื่อรันเอเจนต์ครอบคลุมการรีวิว การตรวจสอบ การซ่อมแซม และส่วนอื่น ๆ ของวงจรชีวิตซอฟต์แวร์

ลองใช้ Cosmos