AI viết code làm giảm chất lượng? Vấn đề nằm ở cách bạn quản lý chất lượng

Khi các công cụ lập trình bằng AI như Claude, Copilot hay Codex ngày càng phổ biến, một câu hỏi quen thuộc lại xuất hiện: "AI giúp viết nhiều code hơn, nhưng liệu chất lượng có bị kéo xuống không?"

Câu trả lời là có, nếu bạn cứ thế gộp pull request (PR) một cách mù quáng rồi đẩy thẳng lên môi trường production. Nhưng nếu bạn xây dựng một quy trình quản lý chất lượng nhiều lớp một cách bài bản, hoàn toàn có thể giữ số lượng lỗi ổn định — thậm chí giảm đi — trong khi vẫn tăng năng suất gấp 2 đến 2,5 lần.

Dưới đây là mô hình phòng thủ theo lớp đã được kiểm chứng trong thực tế, cả ở đội ngũ tác giả lẫn nhiều nơi khác.

Lớp 1: Xác định yêu cầu cho đúng

Một trong những bất ngờ lớn nhất khi chuyển sang phát triển dựa trên đặc tả (spec-driven development) là số lượng lỗi trong code mới giảm mạnh.

Trước đây, khi xây dựng một tính năng mới, các đội thường dành tới một phần ba tổng thời gian cho giai đoạn "đánh bóng" sau phát triển — tức là tìm và sửa đủ loại lỗi. Nguyên nhân phần lớn đến từ việc không lường trước các tương tác, trường hợp biên, hoặc đơn giản là lập trình viên mệt mỏi nên không suy nghĩ kỹ.

Điểm mấu chốt giúp giảm lỗi là để AI rà soát lại yêu cầu hoặc thiết kế kỹ thuật, tìm ra các lỗ hổng, trường hợp biên và tương tác bất ngờ với code hiện có.

AI không biết mệt, và khi được nhắc đúng cách, nó ít có khả năng bỏ cuộc trong việc săn tìm vấn đề tiềm ẩn hơn con người.

Tuy nhiên, đôi khi AI tỏ ra quá hăng hái, nên bạn vẫn cần tự kiểm tra lại các đề xuất chỉnh sửa để đảm bảo nó không "bịa" ra vấn đề không tồn tại.

Lớp 2: Kiểm thử đơn vị với độ phủ trên 95%

Các tác nhân lập trình (coding agent) hiện nay khiến phát triển hướng kiểm thử (TDD) trở nên dễ dàng đến mức không còn lý do gì để bỏ qua. Nhưng phải làm đúng cách: đừng để AI viết ra những bài kiểm thử "xanh" cho chính những lỗi nó vừa thêm vào.

Quy trình hiệu quả thường như sau:

• Yêu cầu AI suy nghĩ kỹ về các kịch bản và trường hợp kiểm thử dựa trên yêu cầu
• Viết các trường hợp kiểm thử
• Viết phần triển khai
• Chạy kiểm thử và sửa mọi vấn đề phát sinh
• Bổ sung phần độ phủ còn thiếu, vẫn luôn bám sát yêu cầu ban đầu

Vì AI đã lo phần viết kiểm thử, bạn không còn lý do để trì hoãn việc hướng tới độ phủ gần như toàn bộ.

Lớp 3: Kiểm thử thủ công

Không gì có thể thay thế việc một con người thực sự dùng thử tính năng — dù là bạn, QA hay PM — đi qua mọi trường hợp biên và xem liệu mọi thứ có hoạt động đúng như mong đợi không.

Các bài kiểm thử thủ công này tốn khá nhiều thời gian, đặc biệt khi việc thiết lập kịch bản mất công. Đây chính là lý do khiến năng suất chỉ tăng khoảng 2-3 lần thay vì gấp 10 lần — dù vẫn còn dư địa để tự động hóa ở bước này.

Lớp 4: Kiểm thử đầu-cuối tự động toàn diện

Kiểm thử đầu-cuối (E2E) có thể coi là quan trọng nhất trong toàn bộ mã nguồn, bởi chúng xác minh rằng thay đổi mới không làm hỏng chức năng cũ mà người dùng cuối đang trải nghiệm.

Lý tưởng nhất, chúng nên chạy trên PR, trên môi trường test/stage và cả trên production sau mỗi lần triển khai. AI giúp việc viết kiểm thử E2E dễ hơn, nhưng để hiệu quả, nó cần truy cập được các công cụ hoặc máy chủ MCP để gỡ lỗi khi kiểm thử thất bại — ví dụ công cụ trình duyệt hoặc quyền truy cập log.

Cần lưu ý: kiểm thử E2E không thể thay thế kiểm thử thủ công, vì chúng chỉ là một phép kiểm tra thô, chưa đầy đủ.

Lớp 5: Các lượt rà soát chất lượng code do AI thực hiện

Các tác nhân lập trình không giỏi tuân theo những chỉ dẫn phức tạp trong file cấu hình. Nhưng chúng lại làm khá tốt nếu bạn thêm một lượt riêng để tìm và sửa từng loại vấn đề cụ thể:

• Lỗ hổng bảo mật
• Code quá phức tạp hoặc trùng lặp
• Tuân thủ quy tắc đặt tên, tổ chức file, định dạng
• Một lượt đánh giá tổng quát tìm lỗi logic
• Comment quá dài viết theo kiểu "văn AI" thay vì ngôn ngữ tự nhiên
• Bất kỳ vấn đề cụ thể nào khác bạn muốn xử lý

Những lượt này gần như "miễn phí" khi gắn vào quy trình lập kế hoạch hoặc triển khai, chỉ tốn thêm khoảng 5-15 phút mà không cần bạn để mắt liên tục.

Lớp 6: Rà soát PR bởi cả người và AI

Với những chỉnh sửa nhỏ và sửa lỗi đơn giản, rà soát bởi con người có thể trở thành tùy chọn — miễn là các lớp phòng thủ khác vẫn hoạt động.

Nhưng với những thay đổi phức tạp, việc con người xem lại code do AI viết vẫn rất cần thiết. Tác giả vẫn thường xuyên phát hiện những lỗi ở tầm vĩ mô, tương tác bất lợi bị bỏ sót giữa các tính năng, và cả những lựa chọn từ ngữ kỳ quặc.

Điểm thú vị là các lượt rà soát bằng AI bổ sung rất hiệu quả. Trên một đội ngũ hiện tại, cả Claude và Cursor cùng rà soát PR, và đáng ngạc nhiên là mỗi công cụ tìm ra những vấn đề khác nhau. Bạn có thể thêm các lượt rà soát tùy chỉnh theo góc độ bảo mật, hiệu quả, tương tác với repo khác. Tuy nhiên, AI đôi khi quá "soi mói", nên cần một lượt khác để lọc bỏ những bình luận vô nghĩa.

Lớp 7: Giám sát và cảnh báo

Sau khi code lên production, tối thiểu nên có người định kỳ xem log, theo dõi bản ghi phiên người dùng trong công cụ như Fullstory, hoặc kiểm tra các bảng điều khiển theo dõi tỷ lệ lỗi và độ trễ.

Tốt hơn nữa là dùng dịch vụ theo dõi lỗi như Sentry hoặc Error Reporting của GCP để phát hiện và loại bỏ trùng lặp lỗi. Cách tốt nhất là để AI tự chẩn đoán lỗi, tìm nguyên nhân gốc và tạo PR đề xuất sửa chữa.

Kết luận

Ý tưởng chính rất rõ ràng: với một bộ lớp phòng thủ phù hợp, năng suất tăng không nhất thiết phải đánh đổi bằng độ tin cậy. Ngược lại, các tác nhân lập trình khiến việc thêm nhiều lớp kiểm tra sâu hơn trở nên rẻ hơn bao giờ hết — nhiều kiểm thử hơn, nhiều lượt rà soát hơn, chẩn đoán sự cố production nhanh hơn.

Vậy nên, nếu bạn đủ tập trung vào chất lượng, việc tăng gấp đôi tốc độ giao hàng mà vẫn kiểm soát — hoặc thậm chí giảm — số lượng lỗi là hoàn toàn khả thi.