AI không có trí tuệ và bạn cũng vậy: Tại sao AI thất bại trong việc duy trì mã nguồn?

Chỉ trong tháng vừa qua, tôi đã nghe những cụm từ này:

Chắc chắn là ngành công nghiệp đang chuyển mình, tuy nhiên, những cá nhân và tổ chức rơi vào cái bẫy không còn đọc và viết code nữa sẽ phải tự gánh chịu hậu quả.

Thực tế là, các dự án được tạo ra bằng "vibe-coding" (lập trình theo cảm hứng) sẽ dần trở thành một mớ hỗn độn không thể bảo trì. Lý do rất đơn giản nhưng lại khó khắc phục: khả năng bảo trì code và kiến trúc tốt không có các thước đo cụ thể mà chúng ta có thể áp dụng, bởi vì phải mất hàng tháng, thậm chí hàng năm, mới thấy được tác động của một kiến trúc tồi hoặc code không thể bảo trì.

Chúng ta chắc chắn có thể định nghĩa thế nào là code tồi: đó là loại code khó đọc, khó hiểu, khó phát triển cho bất kỳ yêu cầu nào trong tương lai. Đó là loại code mà khi thay đổi một thứ sẽ làm hỏng chương trình theo những cách rất phi định hướng, hoặc làm hỏng logic ở một nơi khác, cách xa vị trí bạn thay đổi, giống như "hiệu ứng cánh bướm". Đó là loại code mà việc thêm một tính năng trở thành một công việc nặng nề do phải thay đổi ở nhiều nơi nhưng vẫn quên cập nhật hết, dẫn đến sự thiếu nhất quán. Đó là loại code mà các bất biến (invariants) trong thiết kế không rõ ràng, với những tác giả ban đầu không còn ở đó để ngăn chặn các vi phạm và đảm bảo tính mạch lạc. Đó là loại code khó kiểm thử, đòi hỏi phải dùng mocks và làm lộ các chi tiết triển khai, dẫn đến những bài kiểm thử mong manh, cuối cùng ngăn cản việc tái cấu trúc (refactoring) có ý nghĩa.

Tuy nhiên, chúng ta biết một thực tế rằng phải mất thời gian mới nhận ra được code tồi. Hàng tháng, hàng năm. Tất nhiên, các kỹ sư phần mềm giàu kinh nghiệm có "khứu giác" để phát hiện ra các "code smells" (mùi code) và có thể hành động từ rất lâu trước khi những tác động xấu xuất hiện.

Những lập trình viên thành thạo, những chuyên gia, dựa vào trực giác được xây dựng bằng mồ hôi và nước mắt, qua những giờ làm việc dài đằng đẵng để debug và sửa lỗi trên môi trường production, tự thề với lòng mình sẽ không bao giờ lặp lại những sai lầm ngu ngốc trong quá khứ. Đó là loại trực giác không thể đúc kết thành một danh sách các quy tắc cứng nhắc, bởi vì mọi thứ đều phụ thuộc vào ngữ cảnh. Các chuyên gia không tương thích với những quy tắc và công thức vốn giúp người mới bắt đầu làm việc hiệu quả hơn. Chuyên gia không tuân theo quy tắc, họ tạo ra quy tắc.

Và thế là chúng ta gặp vấn đề…

Thứ nhất, AI không được huấn luyện về việc thế nào là code có khả năng bảo trì. Ví dụ, bất kỳ quá trình học tăng cường (reinforcement learning) nào cũng cần một tín hiệu phần thưởng có thể đo lường ngay lập tức, chứ không phải sau hàng tháng hay hàng năm. AI học các quy tắc từ những cuốn sách dành cho người mới bắt đầu. AI nhận diện các mẫu từ code thực tế, và hãy thành thật mà nói, hầu hết code thực tế đều khá tệ. Không có hàm mục tiêu (fitness function) nào bạn có thể định nghĩa cho code có khả năng bảo trì, ít nhất là không có hàm nào mà chúng ta có thể nhận diện được, nếu không thì nó đã được tích hợp sẵn vào các công cụ linter của chúng ta rồi.

Bạn có nhận thấy AI "đơn giản hóa" code tệ đến mức nào không? Đúng vậy, ngay cả các mô hình SOTA (hiện đại nhất). Nó thậm chí không thể định nghĩa các hàm một cách hợp lý, thay vào đó lại chọn chia nhỏ các hàm thành những hàm nhỏ hơn nhưng thực tế lại không thể tái sử dụng. Việc tách một hàm nhỏ từ một hàm lớn hơn là một lựa chọn rất tồi nếu để hiểu hàm lớn, bạn lại phải đọc cả phần triển khai của hàm nhỏ vừa tách ra đó. Định nghĩa các hàm có thể tái sử dụng và làm rõ nghĩa là một môn nghệ thuật, một môn nghệ thuật đòi hỏi sự tinh thông. Hầu hết các lập trình viên, vì vẫn đang ở mức "người mới bắt đầu nâng cao" (advanced beginners) trong mô hình Dreyfus, không có khả năng định nghĩa các hàm tốt, rõ ràng và có thể tái sử dụng, và AI hiện tại cũng vậy.

Điều này sẽ không quá tệ nếu con người vẫn nắm quyền kiểm soát và học hỏi từ những sai lầm đó. Nhưng chúng ta đang thấy một xu hướng con người dựa dẫm vào AI để viết, và thậm chí là đọc code.

Những người đó sẽ không bao giờ đạt đến sự tinh thông, bởi vì họ không còn đưa ra lựa chọn, không còn chịu trách nhiệm cho những sai lầm trong lập trình và không còn học hỏi từ những sai lầm đó nữa. Giờ đây, chính AI là bên gây ra lỗi, AI không học từ những sai lầm đó, và những người dựa vào AI để lập trình cũng vậy.

Ôi không!

Đừng hiểu lầm tôi, tôi nghĩ LLM là một công cụ tuyệt vời. Tôi không phải là người bài trừ công nghệ (Luddite), tôi đã tích hợp AI vào công việc hàng ngày của mình, đồng thời dạy lại cho đồng nghiệp những gì tôi đã học được. Tôi vui vẻ sử dụng LLM để xử lý tất cả những công việc nhàm chán, tẻ nhạt mà chúng ta phải đối mặt. Tôi cũng đang tận hưởng những lợi ích về hiệu suất mà nó mang lại. Nhưng cuối cùng, nó chỉ là một công cụ, và giống như mọi cuộc cách mạng khác, ánh hào quang của nó rồi cũng sẽ phai nhạt; theo ý kiến của tôi, điều đó đã bắt đầu rồi, vì ngay lúc này, tin tức công nghệ thực sự khá nhàm chán.

Con người thực sự rất tệ trong việc đưa ra dự đoán. Tôi tin rằng tương lai sẽ làm tất cả chúng ta ngạc nhiên. Nhưng, tôi sẽ đưa ra dự đoán của riêng mình…

Trong tương lai, chúng ta sẽ thấy ngày càng nhiều công ty tự hào khoe chính sách "NO-AI" (không dùng AI) như một lợi thế cạnh tranh. Và họ sẽ đúng.

Người ta nói rằng "các dây chuyền lắp ráp tự động luôn hiệu quả hơn", nhưng ngành công nghiệp phần mềm lại đặc biệt, bởi vì chúng ta luôn thực hiện tự động hóa ở quy mô lớn, mọi thứ chúng ta làm đều là tự động hóa, LLM không phải là phương tiện duy nhất cho việc đó, và tùy thuộc vào ngữ cảnh, nó thực sự có thể là một sự xao nhãng. "Lập trình" chưa bao giờ là một vấn đề đã được giải quyết theo bất kỳ nghĩa có ý nghĩa nào. Chắc chắn, bạn có thể yêu cầu LLM xây dựng cho bạn một trình biên dịch C/C++, hoặc bạn chỉ cần clone GCC hoặc LLVM, và bạn sẽ có một trình biên dịch C/C++ tốt hơn, miễn phí nữa. Và có lẽ có những cách tốt hơn để dành thời gian và nguồn lực thay vì tái tạo lại cùng những ứng dụng CRUD (nhu cầu và mong muốn của con người là vô tận, không bao giờ thiếu những mục tiêu mới để thực hiện).

Nếu con người và các công ty không bắt đầu có trách nhiệm với việc sử dụng nó, sẽ có những hậu quả xảy ra.