Đánh giá mã AI bằng cách xác minh ý định thay vì đọc các bản diff

Các kỹ sư tại Aviator đã tái cấu trúc quy trình đánh giá mã để xử lý mức tăng gấp bốn lần số lượng pull request do AI tạo ra. Bằng cách chuyển trọng tâm từ việc đọc từng dòng mã sang xác minh ý định, tiêu chí chấp nhận và các bất biến của hệ thống, nhóm đã giảm thời gian hợp nhất (merge) trung vị từ 2,1 ngày xuống còn 3,4 giờ. Cách tiếp cận này duy trì sự giám sát của con người trong khi tự động hóa các bước kiểm tra thường lệ, cho phép chín kỹ sư quản lý hơn 400 PR được hợp nhất mỗi tuần.

Điều gì đã xảy ra

Khi quy trình phát triển của Aviator chuyển từ mã do con người viết với sự hỗ trợ của AI sang mã do AI tạo ra dưới sự hướng dẫn của con người, khối lượng thay đổi đã tăng vọt. Số lượng pull request được hợp nhất hàng tuần nhảy vọt từ khoảng 100 lên hơn 400, với kích thước PR trung vị đạt tới 640 dòng. Con số này vượt qua ngưỡng 400 dòng, nơi mà khả năng phát hiện lỗi thường suy giảm. Các phương pháp đánh giá truyền thống không thể mở rộng quy mô: việc thêm một reviewer AI làm chôn vùi các quyết định thiết kế quan trọng dưới những góp ý nhỏ nhặt, trong khi áp dụng SLA đánh giá bốn giờ dẫn đến các phê duyệt rỗng tuếch khi các kỹ sư chỉ lướt qua để kịp hạn chót.

Nhóm nhận ra rằng bắt lỗi chưa bao giờ là mục tiêu chính của việc đánh giá mã. Dẫn chứng một nghiên cứu năm 2013 của Microsoft, họ lưu ý rằng chỉ 14% bình luận đánh giá đề cập đến các lỗi. Giá trị cốt lõi của việc đánh giá là chia sẻ kiến thức và duy trì mô hình tinh thần cập nhật về hệ thống. Với việc các tác nhân AI viết phần lớn mã, chức năng chuyển giao kiến thức này gặp rủi ro. Thay vì cố gắng đọc bản diff tốt hơn – thứ chỉ cho thấy cái gì đã thay đổi nhưng không giải thích tại sao – nhóm đã ngừng hoàn toàn việc đánh giá bản diff.

Cách thức hoạt động

Quy trình mới tách biệt các nhiệm vụ của việc đánh giá mã thành các giai đoạn riêng biệt do các cơ chế khác nhau đảm nhiệm. Thứ nhất, các tác nhân đánh giá đối chất lẫn nhau trước khi có PR, tranh luận về các chi tiết triển khai và ghi lại những điểm bất đồng. Chỉ những vấn đề chưa được giải quyết, chẳng hạn như quy ước đặt tên, mới được chuyển cho con người. Thứ hai, hệ thống nắm bắt ý định và tiêu chí chấp nhận trực tiếp từ phiên lập trình. Mỗi khi một kỹ sư sửa lỗi cho tác nhân hoặc trả lời câu hỏi của nó, những tương tác đó trở thành các tiêu chí có thể xác minh. Ý định giải thích lý do thực hiện thay đổi, trong khi tiêu chí chấp nhận định nghĩa cách nó nên hoạt động.

Thứ ba, nhóm đã mã hóa các bình luận đánh giá lặp đi lặp lại thành các bất biến của hệ thống. Bằng cách khai thác dữ liệu lịch sử đánh giá trong một năm, họ đã chắt lọc 11.400 bình luận thành 64 bất biến được phê duyệt, chẳng hạn như yêu cầu ghi nhật ký kiểm toán (audit-log) cho các thay đổi cấu hình. Những bất biến này được biên dịch thành các quy tắc xác định (deterministic rules) sử dụng các công cụ như ast-grep, chạy trong vài giây cùng với các kiểm tra mô hình xác suất. Cuối cùng, mọi tiêu chí chấp nhận đều được chứng minh bằng bằng chứng. Các tác nhân khởi động môi trường xem trước (preview environments) để chạy các kịch bản giống người dùng, ghi lại ảnh chụp màn hình và nhật ký để xác minh hành vi. Điều này cung cấp bằng chứng cụ thể rằng một tính năng hoạt động đúng như mong đợi, chứ không chỉ đơn thuần là vượt qua một bước kiểm tra CI.

Chi tiết chính

• Tăng trưởng thông lượng: Chín kỹ sư hiện nay hợp nhất gấp 4 lần số pull request mỗi tuần, tăng từ ~100 lên >400.
• Cải thiện tốc độ: Thời gian hợp nhất trung vị giảm từ 2,1 ngày xuống còn 3,4 giờ.
• Chỉ số chất lượng: Số lần revert (hoàn tác) trên mỗi 100 PR giảm 40%, cho thấy chất lượng mã ban đầu cao hơn.
• Hiệu quả đánh giá: Số chuỗi bình luận của con người trên mỗi PR giảm từ 6,2 xuống còn 1,3, chỉ tập trung vào các quyết định ở cấp độ cao.
• Tạo bất biến: 11.400 bình luận lịch sử đã được phân tích để tạo ra 64 bất biến được phê duyệt và 212 quy tắc ứng viên.
• Tốc độ xác minh: Mười chín bất biến chính chạy xác định trong 0,3 giây, cung cấp phản hồi nhanh mà không bị độ trễ của mô hình.

Tại sao điều này quan trọng

Đối với các nhóm kỹ thuật đang áp dụng các tác nhân lập trình AI, nghiên cứu tình huống này chứng minh rằng các nút thắt cổ chai trong đánh giá truyền thống có thể được giải quyết bằng cách thay đổi những gì con người đánh giá. Khi kích thước PR vượt quá giới hạn nhận thức của con người đối với việc kiểm tra chi tiết, việc dựa vào bản diff trở nên kém hiệu quả. Bằng cách tự động hóa việc xác minh các quy tắc và hành vi, các kỹ sư có thể tập trung vào các quyết định kiến trúc và hiểu biết về hệ thống. Sự chuyển dịch này bảo vệ khía cạnh chia sẻ kiến thức của việc đánh giá, vốn rất quan trọng cho khả năng bảo trì dài hạn, trong khi để máy móc xử lý việc xác thực các ràng buộc lặp đi lặp lại.

Cách tiếp cận này cũng nhấn mạnh tầm quan trọng của việc nắm bắt ý định ngay từ sớm trong chu kỳ phát triển. Khi các tiêu chí chấp nhận được rút ra từ các tương tác thời gian thực giữa kỹ sư và tác nhân AI, chúng phản ánh các yêu cầu thực tế chính xác hơn so với việc viết bài kiểm tra sau đó. Điều này đảm bảo rằng quy trình xác minh kiểm thử những gì quan trọng đối với logic kinh doanh, chứ không chỉ những gì dễ dàng tự động hóa. Các nhóm xây dựng quy trình làm việc gốc-AI (AI-native workflows) nên cân nhắc tách biệt việc thực thi quy tắc khỏi việc ra quyết định để duy trì tốc độ mà không hy sinh chất lượng.

Bạn có thể làm gì

• Kiểm toán bình luận đánh giá của bạn: Phân loại các bình luận PR trong quá khứ thành quy tắc, quyết định và các bản sửa lỗi một lần để xác định các ứng viên cho việc tự động hóa.
• Xác định các bất biến hệ thống: Trích xuất các ràng buộc lặp đi lặp lại từ codebase của bạn và mã hóa chúng thành các kiểm tra xác định sử dụng các công cụ như ast-grep.
• Nắm bắt ý định trong quá trình lập trình: Lưu trữ cuộc hội thoại giữa kỹ sư và tác nhân AI để tự động tạo ra các tiêu chí chấp nhận.
• Triển khai xác minh dựa trên bằng chứng: Sử dụng các tác nhân tự động để chạy các kịch bản giống người dùng trong môi trường xem trước và ghi lại nhật ký làm bằng chứng.
• Dịch chuyển trọng tâm đánh giá của con người: Đào tạo các reviewer bỏ qua việc đọc từng dòng trong bản diff và thay vào đó đánh giá ý định, bằng chứng và các quyết định thiết kế chưa được giải quyết.
• Tranh luận giữa các tác nhân trước PR: Cấu hình các tác nhân AI để tranh luận về các chi tiết triển khai trước khi tạo PR, tự động giải quyết các vấn đề nhỏ nhặt.