Làm thế nào để AI viết chậm hơn nhưng chính xác hơn: xem xét PR của nhiều mô hình, giảm thiểu khả năng gặp lỗi xuống mức thấp nhất

Trước đây, kỹ sư cấp cao của Microsoft Nolan Lawson sử dụng ba mô hình Claude、Codex、Cursor Bugbot để đồng bộ xem xét PR, xác minh chéo nhằm giảm tỷ lệ báo cáo sai gần như bằng không.
（Tiểu sử: Claude Code thông báo tăng giới hạn sử dụng Token hàng tuần thêm 50%! Trong hai tháng, Anthropic chiếm lĩnh hệ sinh thái nhà phát triển）
（Bổ sung nền: Stripe kích hoạt thử nghiệm thanh toán tự động bằng AI Agent: hỗ trợ thanh toán USDC trên chuỗi x402 của Base）

Mục lục bài viết

Chuyển đổi

• LLM sinh ra đã giỏi tìm lỗi
• Logic xác minh chéo qua nhiều mô hình
• Tốc độ giảm, chất lượng tăng

Chúng ta biết rằng lợi thế của lập trình AI là “tạo ra lượng lớn mã nhanh chóng”, nhưng độ chính xác còn cần bàn cãi. Kỹ sư cấp cao của Microsoft và Salesforce Nolan Lawson gần đây đã ghi lại một quy trình làm việc mới trên blog: anh dùng nhiều mô hình ngôn ngữ lớn đồng bộ xem xét từng pull request (yêu cầu hợp nhất mã, đơn giản là mỗi lần gửi mã mới vào dự án), mục đích là xác minh chéo để tìm ra lỗi thực sự, chứ không phải để tạo ra nhiều mã hơn nhanh chóng.

Quy trình này giúp lượng mã của anh không tăng lên, nhưng chất lượng mã rõ ràng được cải thiện.

LLM sinh ra đã giỏi tìm lỗi

Dự án Glasswing của Anthropic khởi động trong năm nay (cập nhật công khai hệ thống Mythos) cung cấp dữ liệu trực tiếp cho logic này.

Hệ thống này cho phép các agent LLM quét quy mô lớn mã nguồn mở thực tế. Kết quả là: sau khi quét hơn 1.000 dự án mã nguồn mở, hệ thống ước tính phát hiện 6.202 lỗ hổng mức độ nghiêm trọng cao hoặc quan trọng, tổng cộng 23.019 lỗ hổng (bao gồm cả mức độ thấp). Trong số 1.752 lỗ hổng được các công ty an ninh độc lập xác minh, 90.6% được xác nhận là vấn đề thực, 62.4% thuộc mức độ nghiêm trọng cao hoặc quan trọng.

Những con số này thể hiện một chuyển đổi căn bản: tìm lỗi không còn là rào cản, mà là xác minh và sửa chữa mới là vấn đề then chốt.

Trong báo cáo nghiên cứu, Anthropic rõ ràng viết: “Tiến bộ về an toàn phần mềm từng bị giới hạn bởi tốc độ phát hiện lỗ hổng, nay bị giới hạn bởi tốc độ xác minh, tiết lộ và sửa chữa.” Nói cách khác, AI đã đẩy giới hạn của vấn đề từ “phát hiện” sang “khả năng xử lý”.

Logic xác minh chéo qua nhiều mô hình

Phương pháp cốt lõi của Lawson là để nhiều mô hình của các nhà cung cấp khác nhau cùng chạy xét duyệt PR, thay vì dựa vào một mô hình duy nhất.

Bộ công cụ của anh gồm Claude code, Codex của OpenAI, và Cursor Bugbot, ba mô hình này đồng bộ xem xét hoàn toàn độc lập cùng một pull request, rồi tổng hợp tất cả kết quả, sắp xếp theo bốn mức độ nghiêm trọng: critical (quan trọng), high (cao), medium (trung bình), low (thấp).

Thiết kế xác minh chéo qua nhiều mô hình này có một đặc điểm then chốt: một mô hình dễ báo sai, nhưng nhiều mô hình khác nhau về dữ liệu huấn luyện và kiến trúc cùng chỉ ra một vấn đề, tỷ lệ báo sai sẽ giảm đáng kể, độ phủ cũng tăng lên. Theo lời Lawson: “Tỷ lệ báo sai gần như bằng không, tỷ lệ phát hiện lỗi rất cao.”

Quy trình quyết định của anh rất rõ ràng. Tất cả các vấn đề critical và high phải được sửa trước; các vấn đề medium và low sẽ được đánh giá riêng dựa trên “chi phí sửa” và “ảnh hưởng thực tế”, không đáng thì bỏ qua để không lãng phí tài nguyên phát triển; nếu một PR có quá nhiều vấn đề critical, sẽ bỏ luôn, không sửa chữa từng cái một nữa, mà làm lại toàn bộ.

Công nghệ xem xét PR của Lawson xuất phát từ một nghiên cứu phân tích hiệu suất của nhiều mô hình trong review mã: càng đa dạng mô hình, báo cáo cuối cùng càng chính xác, nguyên lý là “đa mô hình để giảm lệch”. Các mô hình có nền tảng huấn luyện khác nhau sẽ có xu hướng thiên lệch khác nhau đối với cùng một đoạn mã, đa số bỏ phiếu sẽ giúp lọc bỏ điểm mù của từng mô hình đơn lẻ.

Tốc độ giảm, chất lượng tăng

Sau khi áp dụng quy trình này, kết quả thực tế của Lawson là: lượng mã (số dòng) không tăng, thậm chí thường phát hiện ra các lỗi cũ đã có, buộc phải viết unit tests (kiểm thử tự động cho từng chức năng nhỏ), thời gian sửa lỗi cũ thường dài hơn nhiều so với phát triển chức năng mới.

Đây không phải kết quả anh mong đợi, nhưng theo góc nhìn khác, đó là tín hiệu mã nguồn đang được hệ thống hóa để nâng cao sức khỏe nền tảng.

Lawson gọi cách làm này là “coding có cảm giác chất lượng hơn”, cẩn trọng, có phương pháp, lấy chất lượng làm trung tâm.

Việc phổ biến các công cụ phát triển thường đặt “tốc độ” lên hàng đầu, nhưng kỹ sư thực sự cần giải quyết không chỉ là tốc độ. Mỗi dòng mã đều có chi phí bảo trì, có khả năng gặp vấn đề. Dùng AI để viết mã chậm hơn, nhưng giúp mỗi dòng mã tồn tại lâu hơn, ít gặp lỗi hơn.