Thử nghiệm của một nhà phát triển với các công cụ lập trình hỗ trợ bởi AI đã gây ra cuộc tranh luận sôi nổi về việc liệu những công nghệ này có thực sự cải thiện năng suất hay tạo ra những vấn đề mới. Trải nghiệm được chia sẻ trong một bài blog chi tiết, tiết lộ cách mã nguồn do AI tạo ra có thể gây ra những lỗ hổng bảo mật nghiêm trọng đồng thời khiến các nhà phát triển ít quen thuộc hơn với codebase của chính họ.
Ban đầu nhà phát triển này từ chối sử dụng các công cụ AI nhưng cuối cùng đã thử chúng dưới áp lực từ nơi làm việc. Sau khi tạo ra 200 dòng mã xử lý hình ảnh chỉ trong 30 phút—một nhiệm vụ thường mất nhiều thời gian hơn—kết quả ban đầu có vẻ ấn tượng. Tuy nhiên, khi cùng công cụ AI đó được yêu cầu xem xét mã nguồn của chính nó để tìm các vấn đề bảo mật, nó phát hiện ra nhiều lỗ hổng nghiêm trọng bao gồm các cuộc tấn công directory traversal và khả năng ghi đè các tệp hệ thống.
Các Vấn Đề Bảo Mật Phổ Biến Của Công Cụ Lập Trình AI:
- Tấn công duyệt thư mục trái phép
- Thiếu giới hạn kích thước tệp
- Lỗ hổng ghi đè tệp hệ thống
- Thiếu xác thực đầu vào
- Kiểm soát truy cập không đầy đủ
Vấn đề điểm mù về bảo mật
Phát hiện đáng lo ngại nhất là AI đã biết về những rủi ro bảo mật này từ đầu nhưng không bao gồm các biện pháp bảo vệ trong mã nguồn gốc. Điều này tạo ra tình huống nguy hiểm khi các nhà phát triển không có kiến thức bảo mật sâu có thể triển khai mã nguồn dễ bị tấn công mà không nhận ra. Thảo luận cộng đồng cho thấy đây không phải là sự cố đơn lẻ—nhiều nhà phát triển báo cáo những trải nghiệm tương tự khi các công cụ AI tạo ra mã nguồn hoạt động nhưng có lỗi.
Khi cố gắng khắc phục các vấn đề bảo mật, nhà phát triển gặp phải một vấn đề khác: vì họ không tự viết mã nguồn, họ thiếu mô hình tư duy cần thiết để thực hiện thay đổi một cách hiệu quả. Điều này dẫn đến chu kỳ yêu cầu AI thực hiện nhiều sửa chữa hơn, càng làm họ xa rời việc hiểu codebase của chính mình.
Nghịch lý năng suất
Phản hồi từ cộng đồng làm nổi bật sự phân chia rõ rệt trong trải nghiệm với các công cụ lập trình AI. Một số nhà phát triển báo cáo tăng năng suất đáng kể, trong khi những người khác mô tả việc lãng phí thời gian để debug các vấn đề do AI tạo ra. Một nghiên cứu gần đây được đề cập trong các thảo luận phát hiện rằng các nhà phát triển có kinh nghiệm thực sự trở nên kém hiệu quả hơn 19% khi sử dụng các công cụ AI, trái ngược với nhiều tuyên bố về năng suất tự báo cáo.
LLM đã cho tôi mã nguồn tệ, khiến tôi trở nên thiếu hiểu biết về codebase của chính mình, và quá lười biếng để cố gắng tự sửa chữa. Và đồng thời, toàn bộ trải nghiệm cảm thấy mượt mà, không ma sát, trao quyền.
Cuộc tranh luận thường tập trung vào prompt engineering—kỹ năng tạo ra các hướng dẫn tốt hơn cho các công cụ AI. Những người ủng hộ cho rằng kết quả kém xuất phát từ việc prompting không đầy đủ, trong khi những người chỉ trích chỉ ra rằng yêu cầu này khiến các công cụ kém đáng tin cậy hơn so với quảng cáo.
Kết quả Nghiên cứu về Năng suất Lập trình viên:
- Lập trình viên có kinh nghiệm: Giảm 19% năng suất khi sử dụng công cụ AI
- Lập trình viên mới: Báo cáo có tăng năng suất trong một số nghiên cứu
- Năng suất tự báo cáo so với năng suất được đo lường thường cho thấy kết quả mâu thuẫn
Mối lo ngại về suy giảm kỹ năng
Nhiều nhà phát triển có kinh nghiệm lo lắng rằng việc phụ thuộc quá nhiều vào các công cụ AI có thể làm xói mòn các kỹ năng lập trình cơ bản của họ. Tác giả gốc kết luận rằng rủi ro thực sự không phải là AI thay thế các nhà phát triển, mà là AI khiến các nhà phát triển phụ thuộc đến mức họ trở nên kém có khả năng giải quyết vấn đề một cách độc lập.
Tuy nhiên, một số thành viên cộng đồng ủng hộ cách tiếp cận cân bằng, sử dụng các công cụ AI như một công cụ nhân năng suất trong khi duy trì các kỹ năng cốt lõi thông qua thực hành có chủ đích. Họ đề xuất coi các công cụ AI như autocomplete nâng cao thay vì những người giải quyết vấn đề thông minh.
Thảo luận phản ánh những lo ngại rộng hơn về cách các công cụ AI có thể thay đổi bản chất của công việc phát triển phần mềm. Trong khi những công cụ này có thể tăng tốc một số nhiệm vụ nhất định, cộng đồng vẫn chia rẽ về việc liệu chúng có đại diện cho tiến bộ thực sự hay tạo ra các hình thức mới của technical debt cần được giải quyết sau này.