- Phát triển có trợ lý AI đang khiến tốc độ tạo mã nhanh hơn tốc độ con người có thể hiểu, làm phát sinh “nợ nhận thức (cognitive debt)”
- Dù mã chạy bình thường và vượt qua kiểm thử, trạng thái chính lập trình viên cũng không hiểu cấu trúc và lý do của đoạn mã vẫn tiếp tục tích lũy
- Giới hạn trong việc rà soát của reviewer, sự thất thoát tri thức ngầm của tổ chức, sự thiếu hụt học tập ở lập trình viên mới đều làm khoản nợ này tăng nhanh
- Tổ chức chỉ đo các chỉ số thiên về tốc độ (DORA, story point, v.v.) nên không phát hiện được sự thiếu hụt về hiểu biết
- Khi khoảng cách giữa năng suất và mức độ thấu hiểu càng lớn, rủi ro dài hạn dẫn đến thất bại bảo trì, đứt gãy tri thức và sự chững lại trong phát triển của kỹ sư càng cao
Độ trễ thấu hiểu (The Comprehension Lag)
- Việc viết mã thủ công thực hiện đồng thời hai quá trình: sản xuất và hấp thụ, và ma sát của thao tác gõ phím thúc đẩy tư duy
- Khi viết mã, mô hình tinh thần và trực giác được hình thành một cách tự nhiên
- Phát triển có trợ lý AI tách rời quá trình này, khiến tốc độ đầu ra tăng vọt nhưng tốc độ thấu hiểu vẫn bị giới hạn bởi năng lực con người
- Khoảng cách giữa đầu ra và sự thấu hiểu này chính là nợ nhận thức; khác với nợ kỹ thuật, nó không hiện ra trong các chỉ số về tốc độ
- Vấn đề sẽ bộc lộ về sau qua các chỉ số độ tin cậy như MTTR tăng, tỷ lệ thay đổi thất bại tăng
Những gì tổ chức thực sự đo lường (What Organizations Actually Measure)
- Tổ chức chỉ đo các đầu ra hữu hình (số tính năng, commit, tốc độ review, v.v.)
- Trước đây, đầu ra và sự thấu hiểu gắn liền với nhau, nên người ta giả định rằng đã triển khai tính năng thì cũng có nghĩa là đã hiểu
- Nhưng trong thời đại AI, chỉ với mức hiểu biết bề mặt cũng có thể triển khai tính năng, nên giả định này không còn đúng nữa
- Các chỉ số của tổ chức không nắm bắt được sự thiếu hụt hiểu biết, khiến hệ thống đánh giá hiệu suất và khen thưởng bị méo mó
Thế khó của reviewer (The Reviewer’s Dilemma)
- Nhờ AI, junior có thể tạo mã nhanh hơn senior
- Reviewer cấp senior không có đủ thời gian để kiểm tra sâu một lượng mã khổng lồ, nên buộc phải hy sinh độ sâu của việc rà soát
- Kết quả là tiền đề “mã đã được review = mã đã được hiểu” bị phá vỡ
- Vì áp lực tổ chức ưu tiên tốc độ, văn hóa đề cao thông lượng hơn chất lượng review ngày càng mạnh lên
Mô hình kiệt sức (The Burnout Pattern)
- Kỹ sư dùng công cụ AI trải nghiệm một kiểu mệt mỏi nơi sản lượng cao và cảm giác thiếu chắc chắn cùng tồn tại
- Mã thì hoạt động, nhưng cảm giác bất an vì không thực sự hiểu hoàn toàn hệ thống do chính mình tạo ra vẫn kéo dài
- Hệ thống đánh giá thiên về tốc độ khiến việc đầu tư thời gian để hiểu sâu trở thành bất lợi, từ đó đẩy nhanh nợ nhận thức
Sự sụp đổ của ký ức tổ chức (When Organizational Memory Fails)
- Tri thức tổ chức được cấu thành từ tri thức tường minh đã được tài liệu hóa và tri thức ngầm nằm trong đầu lập trình viên
- Phát triển với AI rút ngắn quá trình hình thành tri thức ngầm (kinh nghiệm tự tay triển khai), khiến việc tích lũy tri thức không diễn ra
- Kết quả là hệ thống vẫn chạy, nhưng những người có thể hiểu nó thì ngày càng biến mất
- Khi sự cố xảy ra, tổ chức rơi vào trạng thái không ai có thể giải thích bối cảnh của hệ thống
Nợ nhận thức tích lũy như thế nào (How the Debt Compounds)
- Thứ nhất, mã càng cũ càng rủi ro — đoạn mã vốn đã chỉ được hiểu không đầy đủ khi viết ra sẽ trở nên hoàn toàn mờ đục
- Thứ hai, thời gian khôi phục khi xử lý sự cố tăng vọt — xuất hiện tình huống phải debug một “hộp đen do hộp đen tạo ra”
- Thứ ba, sự thiếu vắng các kỹ sư senior trong tương lai — do phụ thuộc vào AI, đường cong học tập biến mất, gây ra khoảng trống lãnh đạo dài hạn
Góc nhìn của giám đốc (The Director’s View)
- Ban điều hành chỉ nhìn thấy các tín hiệu tích cực như năng suất tăng, lịch trình rút ngắn, tối ưu hiệu quả nhân sự
- Vì không tồn tại chỉ số đo “độ sâu thấu hiểu” hay “khả năng giải thích”, nợ nhận thức không được báo cáo
- Do đó, ra quyết định dựa trên dữ liệu tuy hợp lý nhưng không đầy đủ, còn rủi ro thực tế thì bị che khuất
Giới hạn của mô hình này (Where This Model Breaks)
- Khái niệm nợ nhận thức không áp dụng giống nhau cho mọi loại công việc
- Nó có thể phù hợp với các tác vụ lặp lại đơn giản hoặc các thử nghiệm nhanh
- Trước đây mức độ hiểu biết vốn cũng khác nhau theo từng cá nhân, nên đây có thể không phải hiện tượng mới mà là sự dịch chuyển của phân bố
- Về sau, cũng có khả năng công cụ và tài liệu hóa được cải thiện để thu hẹp khoảng cách thấu hiểu
Vấn đề của đo lường (The Measurement Problem)
- Tổ chức chỉ tối ưu những gì có thể đo được
- Tốc độ thì đo được, nhưng sự thấu hiểu thì không thể đo
- Chừng nào sự thấu hiểu chưa được phản ánh vào hệ thống đánh giá, các động lực khuyến khích thiên về tốc độ sẽ còn được duy trì
- Đây không phải thất bại của cá nhân hay nhà quản lý, mà là kết quả của việc hệ thống đo lường từ thời kỳ trước không còn khớp với thực tế hiện tại
- Cuối cùng, khoảng cách này có thể sẽ bộc lộ qua chi phí bảo trì tăng, phản ứng sự cố chậm lại, lộ ra tính dễ tổn thương của hệ thống
- Bài viết khép lại với kết luận: “Hệ thống sẽ được tối ưu theo những gì nó đo lường. Nhưng những gì chúng ta đang đo lúc này không còn phản ánh điều thực sự quan trọng nữa”
3 bình luận
Dạo này tôi cũng đang có những suy nghĩ tương tự, nên hôm qua đã viết một bài blog liên quan đến nợ nhận thức. Có vẻ mọi người đều đang có những trăn trở tương tự.
Nên hiểu code như thế nào? Có phải cần đo lường bằng cách đưa ra các bài quiz dựa trên codebase nội bộ không?
Ý kiến trên Hacker News
Trải nghiệm vài tháng gần đây của tôi rất đồng cảm với nội dung bài viết
Dự án tôi làm vẫn tăng trưởng đều, nhưng số lượng kỹ sư lại giảm đi
Chúng tôi tăng phụ thuộc vào kiểm thử và chuyển sang phát triển dựa trên simulator. Việc xác minh trên hệ thống thực tế trở nên hiếm hơn, và mỗi lần như vậy lại phải xử lý những phần phức tạp nhất
Từ khoảng năm ngoái, tôi bắt đầu thấy rằng ngay cả những tính năng mình đã làm suốt vài tháng cũng nhanh chóng quên mất chi tiết. Điều đó đã xảy ra ngay cả trước khi coding agent được đưa vào nghiêm túc
Khi agent xuất hiện, việc review PR trở nên ngầm định hơn nhiều, khiến bối cảnh không còn đọng lại trong đầu nên phải chủ động tập trung hơn. Các thành viên khác trong nhóm cũng báo cáo trải nghiệm tương tự
Hiện giờ chúng tôi đang thử nhiều cách như commit cả kế hoạch của agent cùng với code. Nhờ vậy, quy trình đang trở nên có hệ thống và tường minh hơn
Tuy vậy, có vẻ như engineering manager hầu như không nhận thức được sự gia tăng tải nhận thức này
Giả định trong bài rằng “developer nhớ được code mình viết cách đây 6 tháng” là sai
Từ trước đến nay, việc hiểu code khi viết luôn dễ hơn khi đọc lại. Joel Spolsky cũng từng nói rằng “đọc code khó hơn viết code”
Vấn đề “code không ai hiểu được” đã tồn tại từ trước AI
Ví dụ như trường hợp xóa mã Pinball của Microsoft, có những đoạn code outsource cũ quá phức tạp đến mức chẳng ai hiểu nổi nên cuối cùng phải bỏ luôn tính năng đó
Trường hợp codebase Oracle RDBMS cũng tương tự
Cụm từ “một hệ thống hoạt động bình thường nhưng xa lạ” rất ấn tượng
Nó giống cảm giác khi developer chuyển sang làm manager. Càng xa code, mức độ hiểu càng trở nên trừu tượng và rời rạc
Câu “những kỹ sư muốn hiểu thật sâu lại tụt lại trên thước đo tốc độ” là điều đau nhất
Thị trường coi trọng tốc độ hơn chất lượng, và cuối cùng tạo ra một cấu trúc nơi kỹ sư thận trọng bị sa thải
Có lẽ giờ là lúc bước vào thời đại “LGTM, LLM”
Ngành này lúc nào cũng lao quá đà rồi sau đó mới tìm lại cân bằng. Vấn đề là kỳ vọng phi lý kiểu đòi năng suất gấp 20 lần nhưng vẫn phải chịu trách nhiệm 100%
Cuối cùng hoặc là phải từ bỏ sự thấu hiểu, hoặc chỉ chấp nhận mức tăng năng suất tối đa khoảng 20%
Tôi nhớ đến triết lý Worse Is Better của Richard Gabriel
Code AI thường chọn sự đơn giản hơn là tính chính xác, nhưng cách tiếp cận thực dụng kiểu “chỉ cần chạy được là thắng” có thể lại chiến thắng
Khi đã có một hệ thống chạy được, ta có thể cải tiến dần dần
Nhóm của chúng tôi cũng đã trải qua đúng hiện tượng mà bài viết nói trong 6 tháng qua
Câu trọng tâm rằng phát triển có AI hỗ trợ làm gián đoạn quá trình tích lũy tri thức ngầm là hoàn toàn chính xác
Tuy vậy, hiện tượng này cũng có thể chỉ là một giai đoạn chuyển tiếp tạm thời
Về lâu dài, LLM có thể sắp xếp cấu trúc code tốt hơn và cung cấp giá trị ở tầng meta, giúp con người chỉ cần hiểu sâu vào những thời điểm thật sự cần thiết
Nếu tài liệu hóa kém thì đội hỗ trợ sản phẩm cũng bị ảnh hưởng nặng
Khi khách hàng hỏi về cách sản phẩm hoạt động, nếu ngay cả kỹ sư cũng không hiểu rõ code mình viết thì rất khó trả lời
Nếu tốc độ cập nhật quá nhanh, các đội khác sẽ khó theo kịp
Khi ngôn ngữ bậc cao xuất hiện trước đây cũng từng có lo ngại tương tự, nhưng kết quả cuối cùng vẫn ổn
Vậy nếu LLM trừu tượng hóa luôn cả việc hiểu code thì có sao không?
Khác biệt nằm ở chỗ compiler là deterministic còn LLM là probabilistic