Lập trình bằng AI làm giảm chất lượng code? Giải pháp phòng thủ 7 lớp từ chuyên gia

Một quan điểm phổ biến mà tôi thường thấy về các coding agent là: “Chắc chắn là AI giúp bạn xuất ra nhiều code hơn, nhưng liệu chất lượng có bị giảm sút không?”

Chắc chắn là có nếu bạn chỉ mù quáng merge các PR và đẩy chúng thẳng lên môi trường production. Nhưng nếu bạn áp dụng một cách tiếp cận có tư duy và phân lớp để quản lý chất lượng, tôi nhận thấy rằng hoàn toàn có thể không chỉ giữ ổn định số lượng lỗi mà thực tế còn giảm được chúng—trong khi vẫn tăng năng suất lên gấp 2-3 lần.

Nhiều lớp phòng thủ này về cơ bản vẫn giống như trước thời Claude/Copilot/Codex/v.v. (mặc dù giờ đây chúng được AI hỗ trợ thực hiện dễ dàng hơn), trong khi một số khác lại là những lớp mới. Dưới đây là thiết lập phòng thủ mà tôi đã thấy được sử dụng thành công trong thực tế, cả ở đội ngũ của tôi và những nơi khác.

Một trong những bất ngờ lớn nhất sau khi tôi bắt đầu sử dụng spec-driven development (phát triển dựa trên đặc tả) là sự sụt giảm các lỗi trong phần code mới viết. Trước khi áp dụng spec-driven development, khi xây dựng, ví dụ như một tính năng mới, các đội ngũ tôi từng làm việc thường dành tới một phần ba tổng nỗ lực cho việc “đánh bóng” sau phát triển, tức là phát hiện và sửa các loại lỗi khác nhau. Nhiều lỗi trong số đó xảy ra do chúng tôi không lường trước được một số tương tác và trường hợp biên (edge cases), hoặc do lập trình viên mệt mỏi vào ngày hôm đó nên không suy nghĩ thấu đáo, hoặc do designer hay PM không tính toán kỹ các kịch bản nhất định. Một số lỗi đã bị bỏ sót và lọt vào môi trường production.

Sau khi tôi bắt đầu sử dụng spec-driven development, số lượng các lỗi này trong code của tôi đã giảm mạnh, và tôi cũng thấy sự sụt giảm tương tự đối với một số (nhưng không phải tất cả) đồng nghiệp của mình. Theo những gì tôi có thể nhận thấy, nguyên nhân chính của sự sụt giảm này là một bước cụ thể trong quy trình: yêu cầu AI xem xét các yêu cầu hoặc thiết kế kỹ thuật để tìm ra bất kỳ lỗ hổng, trường hợp biên, tương tác không mong muốn với code hiện có hoặc các vấn đề tương tự khác.

AI không biết mệt mỏi và khi được prompt đúng cách, nó ít có khả năng bỏ cuộc trong việc săn tìm các vấn đề tiềm ẩn. Thậm chí, đôi khi nó còn quá nhiệt tình, và tôi phải xem xét kỹ các đề xuất chỉnh sửa yêu cầu của nó để đảm bảo rằng nó không tự tạo ra những vấn đề không tồn tại.

Các coding agent hiện nay làm cho test-driven development (TDD) trở nên đơn giản đến mức không có lý do gì để không thực hiện nó. Tuy nhiên, cần phải thực hiện đúng cách: bạn không muốn agent mù quáng viết các bài test vượt qua (passing tests) cho bất kỳ lỗi nào mà nó vừa thêm vào code. Vì vậy, các kỹ năng lập kế hoạch và triển khai tốt nhất mà tôi từng thấy thường tuân theo mô hình này:

Yêu cầu agent suy nghĩ thấu đáo về các kịch bản kiểm thử và các 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,

Kiểm thử phần triển khai dựa trên các trường hợp kiểm thử và sửa bất kỳ vấn đề nào phát sinh,

Có thể bổ sung các khoảng trống độ bao phủ (coverage gaps) còn lại—nhưng một lần nữa, phải luôn ghi nhớ các yêu cầu.

Ngoài ra, với việc các agent viết các bài test, không có lý do gì để không hướng tới độ bao phủ gần như toàn diện hoặc trì hoãn việc bổ sung các unit test còn thiếu.

Vẫn không có gì thay thế được con người (bạn, QA, PM hoặc ai đó) thực sự dùng thử tính năng, đi qua tất cả các trường hợp biên và xem liệu mọi thứ có hoạt động như mong đợi hay bạn cần thực hiện các thay đổi.

Các bài kiểm thử thủ công này có thể mất một thời gian, đặc biệt nếu các kịch bản kiểm thử cần nỗ lực để thiết lập. Đây là một trong những bước cho đến nay chỉ mang lại mức tăng năng suất khiêm tốn, và đó là lý do chính khiến sản lượng của tôi chỉ tăng 2-3 lần thay vì khoảng 10 lần. Mặc dù bây giờ nghĩ lại, có thể có một vài cơ hội để tự động hóa ở đây mà tôi đã bỏ lỡ.

End-to-end (E2E) test được cho là những bài kiểm thử quan trọng nhất trong codebase vì chúng xác minh rằng các thay đổi mới không làm hỏng bất kỳ chức năng hiện có nào mà người dùng cuối trải nghiệm. Lý tưởng nhất là chúng chạy trên các PR, trong môi trường test/stage và trong môi trường production sau mỗi lần triển khai. Lý tưởng nhất là chúng cũng được duy trì bởi chính những lập trình viên viết code thông thường, nhưng tôi hiểu rằng một số tổ chức không thực sự được thiết lập cho việc đó.

AI thực sự giúp việc viết E2E test dễ dàng hơn, nhưng để thực hiện hiệu quả, nó cần quyền truy cập vào các công cụ hoặc MCP server cho phép nó debug các lỗi kiểm thử—ví dụ: công cụ trình duyệt hoặc quyền truy cập MCP vào các file log. Tuy nhiên, cần lưu ý rằng E2E test không thay thế cho kiểm thử thủ công vì chúng chỉ là một bước kiểm tra sơ bộ, không đầy đủ để đảm bảo không có gì quan trọng bị hỏng.

Tôi nhận thấy các coding agent không giỏi trong việc tuân theo các hướng dẫn phức tạp trong AGENTS.md hoặc CLAUDE.md. Nhưng chúng làm khá tốt nếu bạn thêm một lượt chạy riêng để tìm và sửa các vấn đề cụ thể. Đó có thể là:

Các vấn đề bảo mật,

Tìm code quá phức tạp hoặc bị trùng lặp,

Tuân thủ các quy tắc đặt tên, tổ chức file hoặc định dạng,

Một lượt review code tổng quát để tìm bất kỳ vấn đề nào về logic,

Các bình luận quá dài được viết bằng "AI-ese" thay vì tiếng Anh thông thường,

Bất kỳ điều cụ thể nào khác mà bạn muốn tìm và sửa.

Nếu được thêm vào các kỹ năng lập kế hoạch hoặc triển khai, đây có thể coi là những phần bổ sung "miễn phí", chỉ tốn thêm khoảng 5-15 phút vào thời gian triển khai mà không cần thêm sự chú ý nào khác.

Chúng cũng có thể được thêm vào các lượt review PR nếu bạn muốn xem qua các bình luận trước khi áp dụng bất kỳ bản sửa lỗi nào.

Tôi nghĩ mình đang dần tin rằng đối với những chỉnh sửa nhỏ và sửa lỗi đơn giản, việc review của con người có thể trở nên không bắt buộc. Với điều kiện là các lớp phòng thủ khác vẫn được duy trì.

Nhưng đối với các thay đổi phức tạp, tôi thấy rằng việc review code do AI viết vẫn là cần thiết. Tôi vẫn thường xuyên phát hiện ra những sai lầm ở bức tranh toàn cảnh, các tương tác bất lợi bị bỏ sót với các tính năng khác, các cách triển khai quá phức tạp hoặc chưa tối ưu và các vấn đề khác. Chưa kể đến việc lựa chọn từ ngữ kỳ lạ như "mint" thay vì "generate" hoặc "stamp" thay vì "set."

AI code review cũng là một sự bổ sung thực sự tuyệt vời. Trong đội ngũ hiện tại của tôi, chúng tôi chạy cả Claude và Cursor review trên các PR, và đáng ngạc nhiên là mỗi cái đều tìm ra những vấn đề khác nhau. Bạn cũng có thể thêm các lượt review tùy chỉnh khác từ nhiều góc độ, như bảo mật, hiệu suất, tương tác với các repo khác, v.v., mặc dù hãy lưu ý rằng AI có thể quá soi mói trong các bài review của nó, vì vậy điều quan trọng là phải có một lượt chạy mà một agent khác sẽ loại bỏ các bình luận PR do AI tạo ra mà thực sự không có ý nghĩa.

Khi code đã ở môi trường production, tối thiểu là nên có người định kỳ lướt qua các file log hoặc xem các bản ghi thao tác người dùng trong các công cụ như Fullstory, hoặc xem xét các bảng điều khiển theo dõi tỷ lệ lỗi, độ trễ và các vấn đề khác.

Tốt hơn nữa là sử dụng một 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ỏ các lỗi trùng lặp.

Tuy nhiên, cách tiếp cận tốt nhất là để Claude/Cursor/bất cứ thứ gì tự động chẩn đoán các lỗi này, tìm ra nguyên nhân gốc rễ và tạo các PR với bản sửa lỗi được đề xuất.

Tôi chắc chắn mình đã bỏ sót các thành phần quan trọng khác để duy trì chất lượng cao, nhưng ý tưởng chính là với bộ lớp phòng thủ phù hợp, năng suất tăng lên không nhất thiết phải đánh đổi bằng độ tin cậy. Nếu có thì các coding agent hiện nay giúp việc thêm các kiểm tra nhiều hơn và sâu hơn trở nên rẻ hơn trước: nhiều bài test hơn, nhiều lượt review hơn, chẩn đoán lỗi production nhanh hơn.

Vì vậy, nếu bạn tập trung đủ vào chất lượng, tôi nghĩ hoàn toàn có thể tăng gấp đôi tốc độ phân phối trong khi vẫn kiểm soát được các lỗi. Hoặc thậm chí là giảm bớt chúng.