Khi trí tuệ nhân tạo thay đổi cách viết phần mềm, các nhà phát triển đang vật lộn với một hậu quả không ngờ tới: một lượng lớn mã code chất lượng thấp đang tràn ngập, làm quá tải những người kiểm tra code và đe dọa chính nghề thủ công của lập trình. Thứ bắt đầu như một công cụ để tăng năng suất giờ đây đã trở thành nguồn căng thẳng trong các nhóm phát triển trên toàn thế giới.
Sự Trỗi Dậy của Code Rác do AI Tạo Ra
Trên khắp ngành công nghệ, các nhà phát triển đang báo cáo về sự gia tăng đáng kể của thứ mà nhiều người gọi là code rác AI - mã code được tạo ra bởi các mô hình ngôn ngữ lớn, trông có vẻ đúng về mặt hình thức nhưng chứa đựng những lỗi cơ bản. Vấn đề không chỉ là kỹ thuật; mà còn là văn hóa. Các nhà phát triển phụ thuộc quá nhiều vào công cụ AI đang tạo ra một khối lượng mã code khổng lồ mà không hoàn toàn hiểu những gì họ đang gửi đi để xem xét.
Một nhà phát triển đã nắm bắt được sự thất vọng mà nhiều người đang cảm thấy: Những đồng nghiệp kiểm tra code đang nhanh chóng mất trí khi họ nhận ra một sự thật nghiền nát rằng giờ đây họ là lớp kiểm soát chất lượng đầu tiên thay vì một trong những lớp cuối cùng. Những người kiểm tra thấy mình phải bắt tất cả mọi thứ, từ các hàm không sử dụng và các tham chiếu thư viện được bịa ra cho đến các lỗi thực thi rõ ràng lẽ ra phải được chính tác giả ban đầu phát hiện.
Các Vấn Đề Thường Gặp Trong Code Do AI Tạo Ra:
- Các hàm không được sử dụng và không bao giờ được gọi
- Tham chiếu đến các thư viện không tồn tại
- Các lỗi runtime hoặc compilation hiển nhiên
- Các mẫu code quá dài dòng và lặp lại
- Thiếu xử lý lỗi phù hợp
- Các thuật toán và cấu trúc dữ liệu không hiệu quả
Khoảng Trách Trách Nhiệm
Có lẽ xu hướng đáng lo ngại nhất là sự xuất hiện của thứ mà một số người gọi là văn hóa whoopsie (úi chà). Khi bị chất vấn về mã code có vấn đề, một số nhà phát triển né tránh trách nhiệm bằng những bình luận như Úi chà, Claude đã viết cái đó. AI ngốc nghếch thật, ha-ha. Thái độ này đại diện cho một sự thay đổi cơ bản trong cách các lập trình viên tiếp cận công việc của họ. Trong khi các nhà phát triển từng tự hào về việc sở hữu mã code của mình, thì một số giờ đây coi đầu ra do AI tạo ra là vấn đề của người khác.
Phản hồi từ cộng đồng đã rất rõ ràng: Nếu ai đó làm vậy một lần, họ sẽ nhận được một tin nhắn nghiêm khắc về điều đó. Nếu nó xảy ra lần thứ hai, nó sẽ bị từ chối và gửi đến quản lý của họ. Nhiều nhà phát triển có kinh nghiệm tranh luận rằng bất kể mã code được tạo ra như thế nào, người gửi nó vẫn phải chịu trách nhiệm về chất lượng của nó. Giải pháp, theo một bình luận viên, rất đơn giản: Cách giải quyết chỉ là từ chối commit đó với một tin nhắn 'dọn dẹp cái này ngay' ngay khi bạn phát hiện ra một số thứ nhảm nhí. Sự tin tưởng phải được kiếm!
Số liệu Năng suất So với Chất lượng
Việc thúc đẩy mã hóa có sự hỗ trợ của AI không diễn ra trong chân không. Các nhóm quản lý háo hức chứng minh những cải thiện về năng suất thường đang đo lường sai thứ. Như một nhà quan sát nhận xét, Người ném 'code rác' từ LLM vào GitHub có các số liệu tuyệt vời khi ban lãnh đạo nhìn vào mức độ sử dụng con trỏ, số dòng code, số PR, trong khi người chậm lại để thực sự đọc những gì người khác đang gửi giờ đây đang chìm ngập trong 'code rác' đến mức họ có ít thời gian hơn để tự mình sản xuất.
Điều này tạo ra một cấu trúc khuyến khích lệch lạc nơi số lượng lấn át chất lượng. Các nhà phát triển tạo ra hàng ngàn dòng code có sự hỗ trợ của AI trông có vẻ năng suất hơn những người cẩn thận xây dựng các giải pháp nhỏ hơn, hiệu quả hơn. Một nhà phát triển chỉ ra một điểm khác biệt then chốt: Những code do LLM viết hầu như hoàn toàn là thêm vào, trong khi những kỹ sư cao cấp giỏi thường loại bỏ nhiều code như họ thêm vào. Điều này vang vọng câu chuyện nổi tiếng từ những ngày đầu của Apple về việc số dòng code âm là một thước đo năng suất.
Chỉ số Tác động đến Nhóm:
- Thời gian review code tăng 3-5 lần đối với các bài nộp được tạo bởi AI
- Số dòng code trong pull request thường cao hơn 200-500% khi có sự hỗ trợ của AI
- Tỷ lệ lỗi trong code được tạo bởi AI: cao hơn 2-3 lần ở các lần nộp ban đầu
- Việc chuyển giao kiến thức giữa các thành viên trong nhóm giảm ước tính 40-60%
- Thời gian onboarding cho các developer mới tăng lên do độ phức tạp của code
Kết nối Con người Phai nhạt Dần
Ngoài chất lượng code, nhiều người lo ngại về ý nghĩa của AI đối với động lực nhóm và chia sẻ kiến thức. Những cách truyền thống mà các nhà phát triển học hỏi lẫn nhau - lập trình cặp, thảo luận kiến trúc và cố vấn - đang bị thay thế bởi các tương tác người-máy. Việc với tay lấy LLM thay vì con người khi chúng ta cần một người lập trình cặp, một ai đó để trao đổi giải pháp qua lại, tạo nguyên mẫu, phác thảo kiến trúc với, hoặc giúp trả lời các câu hỏi chuyên gia về những phần bí truyền của codebase đang trở nên phổ biến.
Sự thay đổi này có những hệ lụy sâu sắc đối với cách thức lan truyền kiến thức trong các tổ chức. Các nhà phát triển cấp dưới, những người lẽ ra đã học hỏi từ các đồng nghiệp cấp cao thông qua đánh giá code và cộng tác, giờ đây đang nhận được phản hồi chính từ các hệ thống AI. Sự hiểu biết sâu sắc đến từ việc giải thích các khái niệm phức tạp cho một con người khác đang bị mất đi.
Tìm Kiếm Sự Cân bằng Phù hợp
Không phải tất cả nhà phát triển đều kháng cự cuộc cách mạng AI. Một số đã tìm ra những cách hiệu quả để tích hợp các công cụ này vào quy trình làm việc của họ trong khi vẫn duy trì các tiêu chuẩn chất lượng. Một nhà phát triển chia sẻ hành trình của họ: Tôi đã trải qua lộ trình này: chỉ sử dụng AI cho những việc nhỏ, rất ấn tượng với nó → giao cho AI những nhiệm vụ lớn hơn → chế độ tự trị hoàn toàn → nhận ra rằng tôi vẫn cần suy nghĩ thấu đáo tất cả code → quay lại việc giao cho AI những nhiệm vụ nhỏ.
Cách tiếp cận thành công nhất dường như là sử dụng AI cho nghiên cứu, nguyên mẫu và code dùng một lần, trong khi vẫn giữ việc lập trình tổng quan trong tay con người. Như một nhà phát triển khác lưu ý, Tôi nhận thấy AI rất hữu ích cho nghiên cứu, nguyên mẫu và code dùng một lần kiểu 'cái này chạy được, nhưng hoàn toàn không thể chấp nhận trong môi trường production'. Đó là công việc tôi vẫn thường làm trước khi bắt tay vào giải pháp cuối cùng.
Các Cách Tiếp Cận của Nhà Phát Triển với AI Coding:
- Nghiên Cứu & Tạo Mẫu: Sử dụng AI cho code thăm dò và bằng chứng khái niệm
- Hỗ Trợ Các Tác Vụ Nhỏ: Sử dụng hạn chế cho các hàm hoặc tiện ích cụ thể
- Chế Độ Agentic Toàn Diện: Để AI xử lý toàn bộ tính năng với sự xem xét của con người
- Cách Tiếp Cận Kết Hợp: Kết hợp việc tạo code bằng AI với sự tinh chỉnh đáng kể của con người
- Kháng Cự: Tránh hoàn toàn các công cụ AI cho code sản xuất
Khủng hoảng Bản sắc Trở nên Sâu sắc Hơn
Đối với nhiều lập trình viên, đây không chỉ là về công cụ và năng suất - mà còn là về bản sắc. Nghề thủ công của lập trình, với sự tập trung sâu và sự hài lòng khi giải quyết vấn đề, là thứ đã thu hút nhiều người đến với lĩnh vực này. Như một nhà phát triển than thở, Ở một mức độ nào đó, tôi cảm thấy hơi bực bội vì thực tế là tôi không còn thực sự được làm sở thích của mình để kiếm sống nữa. Giờ nó đã trở thành một thứ hoàn toàn khác rồi.
Sự chia rẽ giữa những người coi lập trình là phương tiện để đạt được mục đích và những người coi nó là một nghề thủ công chưa bao giờ rộng hơn thế. Một số tranh luận rằng viết code là phương tiện để đạt được mục đích, không phải là bản thân mục đích, trong khi những người khác phản bác rằng giải quyết vấn đề là một kết quả của lập trình, không phải là mục đích của lập trình. Bất đồng triết lý này phản ánh những câu hỏi sâu sắc hơn về ý nghĩa của việc trở thành một lập trình viên trong thời đại AI.
Sự chuyển đổi của phát triển phần mềm thông qua AI đang tạo ra những căng thẳng cơ bản giữa năng suất và chất lượng, giữa lặp lại nhanh và hiểu biết sâu sắc. Khi ngành công nghiệp định hướng sự chuyển đổi này, các nhà phát triển đang bị buộc phải xem xét lại ý nghĩa của việc viết code tốt và trở thành một lập trình viên có trách nhiệm. Các công cụ có thể đang thay đổi, nhưng nhu cầu về phát triển phần mềm cẩn thận và suy nghĩ thấu đáo vẫn quan trọng như bao giờ hết.
Tham khảo: The Programmer Identity Crisis