Sự phát triển của các trợ lý lập trình AI như Claude Code và Windsurf đã châm ngòi cho một cuộc tranh luận sôi nổi trong cộng đồng lập trình viên về việc liệu các lập trình viên có nên đọc và xem xét code do AI tạo ra trước khi đưa lên production hay không. Cuộc thảo luận tập trung xung quanh một câu hỏi cơ bản: liệu AI đã trở nên mạnh mẽ đến mức việc review code đang trở thành tùy chọn, hay việc bỏ qua bước này sẽ tạo ra những rủi ro nguy hiểm về bảo mật và kiến trúc?
Sự Chia Rẽ Về Định Nghĩa: Vibe Coding Là Gì?
Cộng đồng vẫn còn chia rẽ về việc vibe coding thực sự có nghĩa là gì. Định nghĩa gốc, được phổ biến bởi nhà nghiên cứu AI Andrej Karpathy , mô tả nó như việc lập trình mà không đọc code được tạo ra - về cơ bản là coi AI như một hộp đen tạo ra kết quả hoạt động. Tuy nhiên, nhiều lập trình viên hiện tại lại tranh luận cho một định nghĩa tiến hóa bao gồm việc lập trình dựa trên đối thoại có hướng dẫn, nơi con người xem xét đầu ra của AI.
Sự bất đồng về định nghĩa này phản ánh một căng thẳng sâu sắc hơn về các tiêu chuẩn nghề nghiệp. Một số lập trình viên ủng hộ việc đối xử với AI như một hệ thống tự động, trong khi những người khác khăng khăng rằng nó nên được quản lý như một lập trình viên junior có công việc cần sự giám sát và xem xét liên tục.
Lỗ Hổng Bảo Mật: Mối Nguy Hiểm Tiềm Ẩn
Một trong những lập luận thuyết phục nhất cho việc đọc code do AI tạo ra đến từ các mối quan ngại về bảo mật. Các hệ thống AI, dù ấn tượng, thường bỏ sót các triển khai bảo mật quan trọng như kiểm soát truy cập phù hợp và kiểm tra xác thực người dùng. Một lập trình viên gần đây đã chia sẻ một ví dụ trong đó AI tạo ra một API endpoint trả về bất kỳ dự án nào theo ID mà không xác minh liệu người dùng yêu cầu có thực sự sở hữu dự án đó hay không - một lỗ hổng ủy quyền điển hình.
Những khoảng trống bảo mật này xảy ra vì AI tập trung vào việc thực hiện yêu cầu trước mắt thay vì xem xét các tác động bảo mật rộng hơn. Không giống như các lập trình viên con người có thể tạm dừng giữa quá trình triển khai để xem xét các trường hợp đặc biệt, các hệ thống AI tạo code dựa trên các mẫu mà không có nhận thức bảo mật theo ngữ cảnh đến từ kinh nghiệm.
Danh sách kiểm tra đánh giá mã AI
Trước khi đẩy mã do AI tạo ra:
- Kiểm tra kiến trúc: Liệu điều này có tuân theo các mẫu đã thiết lập không?
- Đánh giá bảo mật: Tất cả tài nguyên có được phạm vi hóa đúng cách cho người dùng không?
- Kiểm thử: Chúng có thực sự kiểm tra hành vi có ý nghĩa không?
- Tài liệu: Bạn có hiểu được điều này sau 6 tháng nữa không?
- Xử lý lỗi: Các trường hợp biên có được bao phủ không?
- Hiệu suất: Có bất kỳ truy vấn N+1 rõ ràng hoặc không hiệu quả nào không?
- Chuyển giao kiến thức: Bạn có hiểu mã mới không?
Vấn Đề Kiến Trúc: Khi AI Đi Lệch Hướng
Ngay cả các hệ thống AI được cấu hình tốt cũng có thể dần dần làm xói mòn kiến trúc code thông qua những sự không nhất quán nhỏ tích tụ theo thời gian. Các lập trình viên báo cáo rằng các trợ lý AI đôi khi lệch khỏi các mẫu đã thiết lập, đặt logic nghiệp vụ trong controllers thay vì các lớp service, hoặc tạo ra chức năng trùng lặp làm phình to codebase.
Nếu bạn không phát hiện sớm, những sự không nhất quán nhỏ đó sẽ trở thành một phần của codebase—và trợ lý yêu thích của bạn sẽ bị cám dỗ để theo những ví dụ xấu đó trong tương lai.
Thách thức trở thành chu kỳ: AI học từ các mẫu code hiện có, vì vậy các lỗi kiến trúc được củng cố và lặp lại trong suốt dự án. Điều này tạo ra nợ kỹ thuật ngày càng tốn kém để sửa chữa khi codebase phát triển.
Nghịch Lý Năng Suất
Cuộc tranh luận cũng chạm đến những câu hỏi cơ bản về năng suất lập trình viên và việc học hỏi. Một số người cho rằng đọc code thực sự chậm hơn việc viết nó, gợi ý rằng việc xem xét đầu ra của AI không mang lại những lợi ích năng suất khiến các công cụ này trở nên hấp dẫn. Những người khác phản bác rằng việc hiểu code vẫn cần thiết cho kiến trúc phần mềm hiệu quả và khả năng bảo trì lâu dài.
Thú vị là, cuộc thảo luận tiết lộ các cách tiếp cận khác nhau dựa trên độ phức tạp của dự án. Nhiều lập trình viên báo cáo thành công khi sử dụng AI ở chế độ tự động chấp nhận cho các tính năng ngoại vi và tạo mẫu, trong khi duy trì các quy trình xem xét nghiêm ngặt cho logic nghiệp vụ cốt lõi và các thành phần quan trọng về bảo mật.
Hai Phương Pháp Phát Triển Có Hỗ Trợ AI
Tạo Mẫu Nhanh với Chế Độ Tự Động Chấp Nhận:
- Sử dụng cho các chủ đề chưa quen thuộc và khám phá
- Phù hợp cho việc xây dựng khung kiểm thử và khám phá thư viện
- Yêu cầu xem xét và điều chỉnh vào cuối phiên làm việc
- Tốt nhất cho các tính năng phụ và thành phần không quan trọng
Lập Trình Đồng Bộ cho Tính Năng Cốt Lõi:
- Phong cách lập trình cặp đôi không có chế độ tự động chấp nhận
- Mọi đề xuất của AI đều được xem xét trước khi triển khai
- Sử dụng cho logic nghiệp vụ cốt lõi và các luồng quan trọng
- Duy trì tính nhất quán về kiến trúc thông qua giám sát liên tục
Tương Lai Của Code Review
Khi các công cụ lập trình AI tiếp tục cải thiện, cộng đồng đối mặt với sự lựa chọn giữa việc chấp nhận phát triển hoàn toàn tự động hoặc duy trì sự giám sát của con người. Một số lập trình viên dự đoán rằng việc xem xét code do AI tạo ra cuối cùng sẽ trở nên không cần thiết như việc đọc code assembly do compiler tạo ra. Những người khác lập luận rằng phát triển phần mềm liên quan đến quá nhiều cân nhắc cụ thể về lĩnh vực và yêu cầu bảo mật để có thể tự động hóa hoàn toàn.
Cuộc tranh luận cuối cùng phản ánh những câu hỏi rộng hơn về vai trò của chuyên môn con người trong một thế giới được AI hỗ trợ. Trong khi AI có thể tạo ra code chức năng nhanh hơn bao giờ hết, trách nhiệm về kiến trúc, bảo mật và khả năng bảo trì lâu dài vẫn đòi hỏi sự phán đoán của con người và kiến thức chuyên môn.
Sự đồng thuận dường như đang nổi lên xung quanh một cách tiếp cận kết hợp: sử dụng AI để tăng tốc phát triển trong khi duy trì sự giám sát của con người cho các quyết định quan trọng. Liệu sự cân bằng này có được duy trì khi khả năng AI tiếp tục tiến bộ vẫn là một câu hỏi mở có thể sẽ định hình tương lai của phát triển phần mềm.
Tham khảo: Read That F*cking Code!