AI không có trí tuệ, và bạn cũng sẽ đánh mất nó nếu phó mặc mọi thứ cho AI

Chỉ trong một tháng trở lại đây, tôi đã nghe đi nghe lại những câu như: "Tôi chưa viết một dòng code nào từ năm 2025", "Review code đã chết rồi", hay "Người ta không còn đọc code nữa".

Đúng là ngành công nghiệp phần mềm đang chuyển mình mạnh mẽ. Nhưng những cá nhân và tổ chức đang sập bẫy của việc không còn đọc và viết code chỉ đang tự đặt mình vào thế nguy hiểm mà thôi.

Vấn đề của những dự án "vibe code"

Sự thật là các dự án được viết theo kiểu vibe coding — tức để AI lo gần như toàn bộ việc sinh code — sẽ dần biến thành một mớ hỗn độn không thể bảo trì nổi. Lý do thì đơn giản nhưng rất khó khắc phục: khả năng bảo trì và kiến trúc tốt không có thước đo nào đủ tốt để đánh giá ngay lập tức, bởi phải mất hàng tháng, thậm chí hàng năm mới thấy được hệ quả của một kiến trúc tồi.

Chúng ta hoàn toàn có thể định nghĩa thế nào là code tồi: đó là code khó đọc, khó hiểu, khó phát triển khi tương lai đặt ra những yêu cầu mới. Loại code mà chỉ cần sửa một chỗ là chương trình vỡ theo những cách cực kỳ khó lường, hoặc làm hỏng logic ở một nơi hoàn toàn khác — giống như hiệu ứng cánh bướm. Loại code mà thêm một tính năng là cả một đại công trình vì phải sửa ở nhiều nơi, rồi vẫn quên vá chỗ nào đó và tạo ra sự bất nhất. Loại code mà các bất biến (invariant) của thiết kế không rõ ràng, còn tác giả ban đầu thì đã rời đi, không còn ai canh chừng để đảm bảo tính nhất quán. Loại code khó kiểm thử, đòi hỏi mock, phơi bày chi tiết triển khai, dẫn đến những bài test mong manh và cuối cùng cản trở chính việc tái cấu trúc cần thiết.

Và chúng ta đều biết một sự thật: phát hiện code tồi cần thời gian. Hàng tháng, hàng năm. Tất nhiên, những kỹ sư phần mềm dày dạn có cái "mũi" nghề nghiệp để ngửi ra mùi code (code smell) và hành động từ rất lâu trước khi hệ quả xấu lộ ra.

Trực giác của chuyên gia không thể đóng gói thành quy tắc

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 tôi luyện bằng mồ hôi và nước mắt: những đêm dài gỡ lỗi, xử lý sự cố production, và tự thề sẽ không bao giờ ngu ngốc lặp lại sai lầm cũ. Đó là loại trực giác không thể biến thành một danh sách quy tắc cứng nhắc, vì mọi thứ đều phụ thuộc vào ngữ cảnh. Chuyên gia không tương thích với cùng những quy tắc và công thức giúp người mới làm việc hiệu quả. Chuyên gia không tuân theo quy tắc — họ tạo ra quy tắc.

Và thế là chúng ta có một vấn đề lớn.

Vì sao AI khó lòng viết được code dễ bảo trì

Thứ nhất, AI không được huấn luyện về ý nghĩa của khả năng bảo trì code. Mọi phương pháp học tăng cường (reinforcement learning) đều cần một tín hiệu phần thưởng đo được ngay lập tức, chứ không phải chờ hàng tháng hay hàng năm. AI học quy tắc từ những cuốn sách giáo khoa vốn dành cho người mới. AI nhận diện mẫu từ code ngoài thực tế — và thẳng thắn mà nói, phần lớn code ngoài thực tế khá là tệ. Không tồn tại một hàm đánh giá (fitness function) nào cho code dễ bảo trì, ít nhất là chưa ai tìm ra, nếu tìm ra thì nó đã được tích hợp vào các công cụ linter từ lâu rồi.

Bạn có để ý AI "đơn giản hóa" code tệ đến mức nào không? Kể cả các mô hình tiên tiến nhất. Nó thậm chí không định nghĩa hàm cho đàng hoàng, mà có xu hướng tách một hàm lớn thành các hàm nhỏ không thực sự tái sử dụng được. Tách một hàm nhỏ ra khỏi hàm lớn là lựa chọn rất tồi nếu muốn hiểu hàm lớn bạn buộc phải đọc cả phần triển khai của hàm nhỏ vừa tách. Định nghĩa những hàm tái sử dụng được và làm sáng tỏ ý nghĩa là một loại nghệ thuật, đòi hỏi sự thành thạo. Phần lớn lập trình viên, vẫn ở mức "người mới nâng cao" theo mô hình Dreyfus, chưa làm được điều đó — 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 giữ quyền kiểm soát và học từ chính sai lầm của mình. Nhưng chúng ta đang thấy một xu hướng: người ta phó mặc cả việc viết lẫn việc đọc code cho AI.

Người dùng AI để code sẽ không bao giờ thành chuyên gia

Những người đó sẽ không bao giờ đạt tới trình độ thành thạo, bởi họ không còn đưa ra lựa chọn, không còn chịu trách nhiệm về sai lầm trong code, và không còn học được gì từ chính những sai lầm ấy. Giờ đây AI là kẻ mắc lỗi, nhưng AI không học từ lỗi của nó, và người phụ thuộc vào AI để viết code cũng chẳng học được gì.

Thật đáng sợ!

Đừng hiểu lầm tôi. Tôi cho rằng LLM là một công cụ tuyệt vời. Tôi không phải kẻ bài xích công nghệ — tôi đã tích hợp AI vào công việc hằng ngày, đồng thời chia sẻ những gì học được cho đồng nghiệp. Tôi sẵn lòng dùng LLM để xử lý hết những việc nhàm chán, hao mòn tinh thần mà ai cũng phải làm. Tôi cũng đang tận hưởng hiệu suất tăng lên rõ rệt. Nhưng xét cho cùng, nó chỉ là một công cụ, và 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 tôi, nó đã bắt đầu phai rồi — tin công nghệ hiện giờ thực sự khá là nhàm chán.

Dự đoán về tương lai

Con người vốn rất kém trong việc dự đoán. Tôi tin tương lai sẽ làm tất cả chúng ta bất ngờ. Nhưng tôi vẫn muốn đưa ra một dự đoán của riêng mình:

Trong tương lai, ngày càng nhiều công ty sẽ tự hào tuyên bố chính sách "NO-AI" như một lợi thế cạnh tranh. Và họ sẽ đúng.

"Nhưng dây chuyền lắp ráp tự động luôn hiệu quả hơn mà" — người ta nói vậy. Nhưng ngành phần mềm đặc biệt ở chỗ: chúng ta vốn đã tự động hóa ở quy mô lớn từ lâu, mọi thứ chúng ta làm đều là tự động hóa, LLM không phải phương tiện duy nhất và tùy ngữ cảnh, nó có thể chỉ là một sự xao lãng. "Bài toán lập trình" chưa hề được giải quyết theo bất kỳ nghĩa thực chất nào. Bạn có thể bảo LLM xây cho bạn một trình biên dịch C/C++, hoặc đơn giản là clone GCC hay LLVM về và có ngay một trình biên dịch tốt hơn, miễn phí. Và biết đâu có những cách dùng thời gian, nguồn lực tốt hơn là ngồi tái tạo lại đúng những ứng dụng CRUD giống nhau — nhu cầu và khát vọng của con người là vô hạn, đâu thiếu mục tiêu mới để theo đuổi.

Nếu các cá nhân và doanh nghiệp không bắt đầu có trách nhiệm trong việc dùng AI, hậu quả sẽ đến.

Với độc giả Việt Nam, câu chuyện này đặc biệt đáng lưu tâm khi làn sóng dùng AI để viết code đang lan rất nhanh trong các đội phát triển phần mềm, đặc biệt ở các công ty outsource và startup. Tốc độ tạo ra tính năng có thể tăng vọt trong ngắn hạn, nhưng chi phí bảo trì về sau — thứ vốn khó đo lường và dễ bị bỏ qua — mới là khoản nợ kỹ thuật thực sự. Việc duy trì thói quen đọc code, review code và chịu trách nhiệm cá nhân với từng dòng code vẫn là cách duy nhất để một lập trình viên trưởng thành thực sự.