AI đã viết xong code thay bạn, nhưng không ai còn muốn nghiêm túc xem lại nữa

Tác giả: The Pragmatic Engineer

Biên dịch: TechFlow

Ghi chú từ TechFlow: AI viết code ngày càng nhanh, nhưng người review code vẫn là con người. Mâu thuẫn này đang trở thành một cuộc khủng hoảng: các kỹ sư bị nhấn chìm bởi các PR do AI tạo ra, hoặc là mệt mỏi đối phó dẫn đến review không kỹ, hoặc là thấy AI không báo lỗi thì cứ duyệt thẳng. Các công ty lớn đồng loạt xây dựng công cụ nội bộ để đối phó, nhưng hiện tại chưa ai có câu trả lời chuẩn.

Chào, tôi là Gergely, đây là một số phát hành miễn phí của Bản tin Pragmatic Engineer. Mỗi kỳ tôi đều đưa tin về các công ty công nghệ lớn và startup từ góc nhìn của các kỹ sư cấp cao và lãnh đạo kỹ thuật. Hôm nay chúng ta thảo luận một trong bốn chủ đề từ số The Pulse trước đây. Người dùng đăng ký đầy đủ đã nhận được bài viết này một tuần trước. Nếu email này được chuyển tiếp cho bạn, bạn có thể đăng ký tại đây.

Tôi nghe thấy nhiều lãnh đạo kỹ thuật quan tâm nhất đến một việc là làm thế nào để đối phó với khối lượng review code tăng liên tục. Chủ đề này đã tồn tại một thời gian, giờ đây những cuộc trò chuyện như vậy dường như ngày càng nhiều.

Đối với tôi, điều này bắt đầu từ tháng 1 năm nay, khi Opus 4.5 và GPT 5.4 bắt đầu viết nhiều code tốt hơn ở hầu hết các công ty. Khoảng từ thời điểm đó, những người cấp giám đốc bắt đầu thảo luận về việc nút thắt phát triển phần mềm đang chuyển từ giai đoạn coding sang giai đoạn review.

Sự bùng nổ của các công cụ review code AI

Từ tháng 2, các công cụ review code AI đã xuất hiện tăng trưởng bùng nổ để đối phó với tải tăng, các công cụ review code AI chuyên biệt như CodeRabbit, Greptile, Qodo, SonarQube (giờ còn có Gitar) đang được thử nghiệm và áp dụng bùng nổ. Còn có các công cụ do chính công cụ coding cung cấp, như Claude Code review, Cursor review, GitHub Copilot review. Sau đó các công cụ trước đây không liên quan đến review code nhưng có ngữ cảnh về codebase cũng đang tham gia lĩnh vực này, như Seer AI reviews của Sentry, Linear code reviews.

Các công ty lớn tự xây dựng công cụ nội bộ: Code Inbox của Uber

Các công ty lớn đang xây dựng công cụ nội bộ để cải thiện trải nghiệm review code. Code Inbox của Uber là một ví dụ:

Phân công thông minh là một tính năng trong Code Inbox, dùng để thúc đẩy quy trình review:

Hình: Cài đặt Phân công thông minh (Smart assignment) của Code Inbox, dùng để thúc đẩy quy trình review. Nguồn: The Pragmatic Engineer

Còn có chức năng Hồ sơ rủi ro, dùng để đánh giá tác động của thay đổi, và khuyến khích developer chú ý đặc biệt đến các thay đổi rủi ro cao:

Hình: Chức năng Hồ sơ rủi ro (Risk Profiles) của Code Inbox, ước tính rủi ro thay đổi code và nhắc nhở tập trung chú ý. Nguồn: The Pragmatic Engineer

Chúng tôi đã đưa tin về cách Uber sử dụng AI để phát triển phần mềm, và không chỉ Uber: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick) cùng nhiều công ty khác cũng đã xây dựng công cụ để làm cho quy trình review code của họ mượt mà hơn, vì họ nhận thấy triển khai nội bộ hiệu quả hơn so với giải pháp tích hợp từ nhà cung cấp.

Từ «Review» chuyển sang «Xác thực»

Một cách tiếp cận khác là suy nghĩ làm thế nào để xác thực code, thay vì review code. Nói thì dễ làm thì khó; về lý thuyết, testing triệt để nên có thể xác thực code hoạt động như kỳ vọng. Nhưng bao nhiêu test mới được tính là «triệt để»? Chúng ta đang nói về loại test nào? Integration test và End-to-end test cũng bao gồm không? Fuzzing test thì sao? Formal methods thì sao? Làm thế nào để xác thực test mới coverage chức năng như kỳ vọng? Chúng ta làm thế nào để kết nối tất cả những thứ này với observability?

Review quá mức đang làm kiệt quệ các kỹ sư

Quá nhiều review code triệt để đang làm các kỹ sư kiệt quệ, và dẫn đến chất lượng review giảm sút. Tôi nghe nhiều đồn thổi rằng các developer thấy người khác không còn có thể tâm huyết review code nữa, nếu AI code review không có ý kiến thực chất, thì họ duyệt thẳng. Đồng thời, những developer bỏ ra cùng năng lượng và thời gian để review code như trước đây cảm thấy bị nhấn chìm bởi các PR rác do AI tạo ra được gửi cho họ.

Vấn đề tồn tại, giải pháp vẫn là thử nghiệm

Vấn đề tồn tại, nhưng giải pháp cảm giác giống như là thử nghiệm hơn.