Mượn tạm ý niệm “mạt pháp”: hình thức vẫn còn, nhưng cái lõi dễ bị bỏ quên. Đây chỉ là một ẩn dụ, không phải một cách diễn giải giáo lý.
Một người bị từ chối vay, và cả phòng không ai giải thích nổi
Hãy hình dung một hệ thống duyệt vay vừa được đưa vào vận hành. Nó chạy đúng spec, test xanh, dashboard cũng xanh. Một khách hàng bị từ chối. Họ khiếu nại. Đến lúc ngồi lại, chẳng ai giải thích được vì sao hệ thống lại đi đến quyết định ấy.
Người làm sản phẩm nói rule đã được chốt. Người làm dữ liệu nói mô hình có độ chính xác tốt. Kỹ sư nói phần lớn code do AI hỗ trợ sinh ra, đã có test. Không ai làm sai một bước rõ ràng nào. Nhưng cũng không ai thực sự hiểu toàn bộ con đường dẫn đến kết quả đó.
Nỗi lo của người làm IT lúc này không đơn giản là: “AI viết code nhanh hơn mình.” Nó khó chịu hơn nhiều: nếu code có thể được sinh ra mà không cần hiểu, thì người hiểu còn được trả tiền cho điều gì?
Tôi tạm gọi đây là thời mạt code.
Không phải vì code đang biến mất. Trái lại, code chưa bao giờ nhiều như bây giờ. “Mạt code” là lúc code rẻ đến mức việc tạo ra nó không còn chứng minh nhiều về năng lực nữa.
Ba thời của code
Nếu mượn cấu trúc “ba thời” của ý niệm mạt pháp, có thể nhìn nghề lập trình như thế này.
Chánh code là thời viết và hiểu gần như là một. Với assembly hay C trong những hệ thống đầu tiên, không hiểu máy đang làm gì thì khó mà viết được một dòng chạy đúng. Viết code là một hành vi rất vật lý: bộ nhớ bao nhiêu, CPU làm gì, byte nằm ở đâu.
Tượng code là thời framework, thư viện, Stack Overflow và copy-paste. Mọi thứ trở nên dễ tiếp cận hơn, và đó là tiến bộ thật. Nhưng cũng từ đây, ta quen với chuyện chạy những đoạn code mình chưa từng đọc kỹ. Vẫn repo, vẫn commit, vẫn pull request; chỉ có khoảng cách giữa “viết” và “hiểu” ngày một xa.
Mạt code là khi hình thức ấy được sinh ra gần như vô hạn. Một prompt có thể thành một service, một trang web, một bộ test, một bản phân tích lỗi. Nhanh đến mức ta có thể lầm tưởng: thứ chạy được đương nhiên là thứ đã được hiểu.
AI không tạo ra sự tách rời ấy từ con số không. Nó chỉ đẩy một xu hướng cũ đến cực hạn, rồi đặt nó ngay trước mặt chúng ta.
Thứ gì đang mất giá?
Những việc mất giá nhanh nhất cũng là những việc AI làm tốt nhất: boilerplate, CRUD, giao diện phổ thông, tra cú pháp, hoặc biến một yêu cầu đã rõ thành code có thể chạy.
Điều đó không làm các kỹ năng ấy vô dụng. Một kỹ sư vẫn cần biết code để đọc, sửa và đánh giá code. Nhưng chúng không còn đủ để tạo ra khác biệt. Số dòng code, tốc độ gõ phím hay số feature ship trong một tuần vốn đã là những thước đo nghèo nàn; bây giờ chúng càng nghèo nàn hơn.
AI làm tốt khi mục tiêu rõ, dữ liệu đủ và tiêu chí đúng-sai có thể nêu cụ thể. Đời thật thì thường ngược lại: yêu cầu mơ hồ, dữ liệu bẩn, các mục tiêu đánh nhau, luật lệ đổi giữa chừng, và ngân sách thì không bao giờ đủ.
Quay lại hệ thống duyệt vay. AI có thể giúp viết nó. Nhưng AI không tự quyết định công ty nên ưu tiên lợi nhuận, khả năng tiếp cận tín dụng hay sự công bằng. Và khi một người bị từ chối oan, AI cũng không phải người ngồi xuống giải thích, sửa hậu quả, hay chịu mất niềm tin.
Tuy vậy, cũng không nên tự trấn an bằng câu “giá trị sẽ chuyển sang phán đoán”. Một ngành có thể tạo ra nhiều giá trị hơn trên mỗi người nhưng lại cần ít người hơn. Khả năng đó là có thật. Khả năng ngược lại cũng có thật: code rẻ hơn dẫn đến nhiều hệ thống hơn, và theo đó là nhiều gánh nặng vận hành, bảo mật, tích hợp và bảo trì hơn. Không ai biết trước cán cân sẽ nghiêng về đâu. Chỉ có một điều khá rõ: kiểu công việc cũ sẽ không quay lại nguyên vẹn.
Nút thắt mới: sinh thì dễ, thẩm định mới khó
Đây có lẽ là thay đổi quan trọng nhất.
Khả năng sinh code tăng cực nhanh. Khả năng đọc, hiểu và kiểm chứng nó của con người thì không tăng cùng tốc độ. Nút thắt của nghề vì thế chuyển từ sản xuất sang thẩm định.
Ai từng review một pull request vài trăm dòng do AI tạo ra đều biết cảm giác này. Code đặt tên đẹp, comment đầy đủ, cấu trúc có vẻ tử tế. Nó trơn tru đến mức dễ ru người review vào một cái gật đầu. Rồi lên production, một giả định nhỏ mà không ai hỏi tới mới bắt đầu vỡ.
Vì thế, có thể thời mạt code sẽ ưu ái người đọc code hơn người viết code. Người có giá trị là người nhìn vào năm trăm dòng “trông ổn” và hỏi được: giả định nào ở đây chưa được chứng minh? Điều gì sẽ xảy ra khi dữ liệu thiếu, dịch vụ chậm, người dùng làm điều bất thường?
Khi kinh sách có thể được in ra vô hạn, thứ hiếm không phải bản kinh. Thứ hiếm là người đọc hiểu. Ẩn dụ đó, tình cờ, lại khá đúng với code hôm nay.
Hai câu hỏi không thể lướt qua
“Chịu trách nhiệm” là năng lực thật, hay chỉ là chỗ luật pháp chưa thay đổi?
Đây là phản biện mạnh. Có thể con người còn đứng tên đơn giản vì luật chưa cho phép đổ trách nhiệm cho một hệ thống AI. Nếu luật thay đổi, “hào” này có thể hẹp đi rất nhanh.
Nhưng trách nhiệm không chỉ là chuyện ai bị kiện. Nó còn là niềm tin. Khi một quyết định gây hại, khách hàng, đồng nghiệp và xã hội cần một ai đó có thể giải thích, nghe phản hồi và thay đổi cách làm. Đó là một nhu cầu xã hội, không chỉ là thủ tục pháp lý. Dù vậy, ranh giới này chắc chắn sẽ còn dịch chuyển.
Nếu AI lấy mất việc của junior, senior mười năm nữa sẽ từ đâu ra?
Đây là nghịch lý rất thật. Phán đoán không tự nhiên xuất hiện; nó được tích lũy qua những việc nhỏ, những bug ngớ ngẩn, những lần deploy hỏng. Trong khi đó, chính những việc đó lại đang là phần đầu tiên bị tự động hóa.
Không có lời giải gọn. Nhưng con đường học nghề phải được thiết kế lại: junior không thể chỉ nhận prompt rồi nộp output. Họ cần được học cách kiểm chứng, cách quan sát hệ thống thật, và cách lần theo một quyết định đến tận giả định ban đầu. Đây là việc của senior và tổ chức, không phải một lời khuyên suông kiểu “tự nâng cấp bản thân”.
Vậy “tu” gì?
Không phải tu để đứng ngoài AI. Là tu để dùng nó mà không đánh mất khả năng phán đoán của mình.
Tu khả năng thẩm định. Đọc output của AI với một sự nghi ngờ có phương pháp. Viết test không phải để đủ checklist mà để chặn những giả định nguy hiểm. Xem log, quan sát production, và sau mỗi sự cố hỏi lại: điều gì ta đã tin mà không kiểm tra?
Tu sự rõ ràng và hiểu bối cảnh. Với AI, đề bài rõ thường đã là phần lớn lời giải. Hãy tập viết problem statement, tiêu chí thành công và các ràng buộc trước khi có dòng code đầu tiên. Đồng thời, đi sâu vào một lĩnh vực cụ thể — tài chính, logistics, giáo dục, y tế — đủ để hiểu vì sao một yêu cầu được đưa ra. Chỉ khi đó bạn mới có thể nói: “Yêu cầu này nghe hợp lý, nhưng chúng ta không nên làm nó theo cách này.”
Tu sự liêm chính. Không biết thì nói không biết. Đừng ship thứ mình không thể giải thích chỉ vì nó chạy và deadline đang sát. Sẽ có lúc phải chọn giữa “cứ deploy đi, nhìn cũng ổn” và “dừng lại, tôi chưa hiểu đoạn này”. Chọn phương án thứ hai đủ nhiều lần, bạn trở thành người mà đội ngũ muốn giao việc khó.
AI nên là đòn bẩy để ta thử nhanh hơn và hiểu nhanh hơn. Nó không nên là nơi ta gửi luôn năng lực suy nghĩ của mình.
Mạt code không phải ngày tàn của nghề
Ý niệm mạt pháp, nếu nhìn như một ẩn dụ, không phải lời mời gọi tuyệt vọng. Nó nhắc rằng khi hoàn cảnh đổi, cách thực hành cũng phải đổi.
Nghề lập trình không biến mất. Thứ đang dần kết thúc là thời ta nhầm việc gõ code với việc tạo ra giá trị.
Trong thời mạt code, có lẽ đừng cố trở thành người viết code nhanh nhất. Hãy cố trở thành người mà cả đội tìm đến khi hệ thống gặp chuyện: vì bạn hiểu điều đang xảy ra, biết câu hỏi cần hỏi, và dám đứng tên cho quyết định của mình.