Nợ kỹ thuật, nợ nhận thức và nợ ý định: Tác động của AI lên phát triển phần mềm

Trong bối cảnh các mô hình ngôn ngữ lớn (LLM) ngày càng tạo ra lượng mã nguồn khổng lồ, cộng đồng công nghệ đang bắt đầu sử dụng khái niệm "Nợ nhận thức" (Cognitive Debt) để mô tả việc đội ngũ phát triển dần mất đi sự hiểu biết về hệ thống của mình. Martin Fowler đã chia sẻ những góc nhìn sâu sắc về vấn đề này, mở rộng khái niệm nợ công nghệ thành ba lớp riêng biệt ảnh hưởng đến sức khỏe của hệ thống.

Ba loại nợ trong phát triển phần mềm

Margaret-Anne Storey đề xuất cách tiếp cận ba lớp để đánh giá sức khỏe hệ thống:

Nợ kỹ thuật (Technical Debt) nằm ngay trong mã nguồn. Nó tích lũy khi các quyết định triển khai làm giảm khả năng thay đổi trong tương lai. Đây là khái niệm quen thuộc nhất, giới hạn cách thức hệ thống có thể tiến hóa.

Nợ nhận thức (Cognitive Debt) nằm ở con người. Nó xuất hiện khi sự hiểu biết chung về hệ thống bị xói mòn nhanh hơn tốc độ được bổ sung. Điều này giới hạn khả năng của đội ngũ trong việc lý luận và đưa ra các thay đổi có căn cứ. Khi AI viết code, con người dễ rơi vào trạng thái không hiểu sâu sắc về những gì đang chạy.

Nợ ý định (Intent Debt) nằm trong các tài liệu và sản phẩm (artifacts). Nó tích lũy khi các mục tiêu và ràng buộc hướng dẫn hệ thống không được ghi chép hoặc bảo trì tốt. Điều này khiến hệ thống không còn phản ánh đúng ý định ban đầu của người xây dựng, đồng thời cản trở cả con người và tác nhân AI trong việc phát triển hệ thống hiệu quả.

Hệ thống 3 và sự đầu hàng nhận thức

Bài viết cũng đề cập đến một nghiên cứu thú vị của Shaw và Nave từ Trường Wharton, họ đã thêm AI vào mô hình tư duy hai hệ thống của Kahneman (tư duy nhanh và chậm). Các tác giả đề xuất AI là Hệ thống 3.

Một hệ quả của việc có Hệ thống 3 này là sự xuất hiện của "đầu hàng nhận thức" (cognitive surrender). Đây là trạng thái dựa mù quáng vào lý luận nhân tạo từ bên ngoài, bỏ qua Hệ thống 2 (tư duy có chủ đích). Điều này khác biệt với "xả bớt nhận thức" (cognitive offloading) - nơi chúng ta chủ động ủy thác một phần tư duy để chiến lược hơn.

Từ viết mã sang xác minh

Ajey Gore đặt ra câu hỏi: Nếu các tác nhân AI (coding agents) làm cho việc viết mã trở nên miễn phí, thì điều gì sẽ trở nên đắt đỏ? Câu trả lời là: Xác minh (Verification).

Việc định nghĩa "đúng" (correct) là cực kỳ phức tạp và phụ thuộc vào ngữ cảnh. Ví dụ, thuật toán ước tính thời gian đến (ETA) cho giao thông tại Jakarta sẽ khác hoàn toàn so với TP.HCM. Việc phân bổ tài xế thành công không chỉ là một con số, mà là sự cân bằng giữa công bằng thu nhập, thời gian chờ của khách và hiệu quả sử dụng đội xe.

Đây chính là loại phán xét mà các tác nhân AI không thể thay thế con người. Do đó, vai trò của kỹ sư sẽ thay đổi:

• Thay vì hỏi "chúng ta đã triển khai gì?", các cuộc họp giao ban (standup) sẽ tập trung vào câu hỏi "chúng ta đã xác minh (validate) gì?".
• Thay vì theo dõi sản lượng mã nguồn, đội ngũ sẽ theo dõi xem kết quả có đúng hay không.
• Cấu trúc tổ chức sẽ chuyển dịch từ việc có nhiều kỹ sư xây dựng tính năng sang việc có nhiều người chuyên định nghĩa tiêu chí chấp nhận, thiết kế bài kiểm thử và giám sát kết quả.

Tương lai của mã nguồn

Cuối cùng, câu hỏi về việc liệu mã nguồn (source code) có còn tương lai hay không vẫn đang được tranh luận. Một số người thử nghiệm các ngôn ngữ mới dành riêng cho LLM, trong khi số khác tin rằng các ngôn ngữ hiện có với kiểu dữ liệu nghiêm ngặt (như TypeScript hay Rust) vẫn là lựa chọn tốt nhất.

Tuy nhiên, cốt lõi của lập trình không chỉ là cú pháp. Đó là việc định hình giải pháp và đặt tên (naming). Việc đặt tên tốt giúp cắt giảm sự phức tạp, biến mã nguồn thành sơ đồ mà mọi người có thể theo dõi. Đó là hành động sáng tạo liên tục để lộ ra cấu trúc của giải pháp, ánh xạ rõ ràng đến vấn đề đang được giải quyết.