- Việc sử dụng công cụ lập trình AI làm gia tăng "nợ mã nguồn"
- Trong hai công ty có cùng sản phẩm và doanh thu, công ty vận hành với 100.000 dòng mã sẽ dễ hiểu và dễ chỉnh sửa hơn nhiều so với công ty có 1 triệu dòng mã
- Nghĩa là càng nhiều mã thì nợ càng chồng chất, và việc tạo mã bằng AI tuy nâng cao năng suất nhưng đồng thời cũng có thể được hiểu là hành vi làm tăng nợ
- Nợ có hai mặt tích cực/tiêu cực
- Tích cực: cho phép tăng trưởng nhanh trong ngắn hạn
- Tiêu cực: về dài hạn, nếu quản lý thất bại thì có thể dẫn đến nguy cơ sụp đổ của dự án
- Nói cách khác, nợ có thể tốt hoặc xấu, có thể có lãi hoặc không có lãi, có thể giúp tăng trưởng nhanh nhưng cũng có thể khiến dự án sụp đổ
- Điều quan trọng không phải là có dùng công cụ hay không, mà là thái độ quản lý có trách nhiệm
- Cần vừa đảm bảo khả năng tiếp cận dễ dàng với công cụ, vừa cân nhắc chất lượng của mã được tạo ra và chi phí dài hạn
5 bình luận
Nếu mã rất dài nhưng vẫn có thể dễ dàng giải thích nó "làm gì" thì đó không phải là nợ kỹ thuật.
Ý ở đây là việc sử dụng AI một cách bừa bãi khiến điều đó trở nên khó khăn, nên mới nói nó tạo ra nợ kỹ thuật.
https://github.com/kelseyhightower/nocode
Dù trong bài không nói rõ ràng, nhưng liệu có thể hiểu rằng khi dùng AI để viết code, vì không quen thuộc như code do con người tự tay viết nên nó có thể trở thành một khoản nợ hay không?
Ý kiến Hacker News
Bề ngoài, cảm giác việc đo mọi thứ bằng số dòng mã (LOC) là một cách nhìn phiến diện. Nếu Company A có 1 triệu dòng mã được tổ chức gọn gàng, sạch sẽ và tài liệu hóa tốt hơn nhiều, thì đó có thể vẫn là tình trạng tốt hơn Company B với 100 nghìn dòng mã viết cẩu thả. Cốt lõi là vấn đề không nằm ở mã mà ở độ phức tạp, còn số dòng chỉ là một chỉ số đo độ phức tạp ở mức gần đúng. Mã là tài sản. Đó là đầu ra và cũng là tài sản của một công ty phần mềm. Tất nhiên, tài sản càng nhiều thì độ phức tạp cũng tăng lên, nhưng điều đó quá hiển nhiên. Cũng giống như không thể chỉ nhìn mạng lưới đường cao tốc của Mỹ như một thứ hoàn toàn tiêu cực chỉ vì nó phức tạp và khó bảo trì. Ngay cả khi gác vấn đề AI sang một bên, rốt cuộc luận điểm của tác giả chỉ là kết luận cơ bản mà ai cũng biết: "độ phức tạp càng ít càng tốt". Vì vậy, điểm quan trọng nhất của bài này có thể được rút gọn thành: "hãy chắc chắn rằng các công cụ lập trình AI không thêm độ phức tạp không cần thiết vào mã hoàn chỉnh"
Tôi lại nghĩ độ phức tạp không phải là điểm mấu chốt ở đây. Nếu giả sử đã có một doanh nghiệp phần mềm còn sống tốt và suy ngược lại, thì về nguyên tắc mọi chi phí (mua sắm, lương bổng, v.v.) đều nên được giảm càng nhiều càng tốt. Người ta nói phức tạp tệ hơn đơn giản, nhưng đó là vì khi thực sự phức tạp thì nó đắt hơn. Tuy nhiên, điều quan trọng cuối cùng vẫn là bản thân chi phí, dù là ngắn hạn hay dài hạn, vốn hay vận hành. Vấn đề thực sự là mã do LLM tạo ra có làm giảm chi phí hay lại làm tăng chi phí. Kích thước mã, độ phức tạp, cùng vô số biến số khác mà OP hay bạn chưa nhắc đến, đều quan trọng
Tôi thường nhìn độ phức tạp của hàm bằng cyclomatic complexity. Tôi dùng SwiftLint để đo độ phức tạp và gắn cờ khi vượt ngưỡng. Thỉnh thoảng tôi cũng tách đại ra, nhưng thường vẫn cố tìm cách làm nó đơn giản hơn. Các file của tôi khá dài, nhưng tôi cố giữ tỷ lệ chú thích và mã khoảng 50:50. Nếu đưa cho LLM một prompt yêu cầu giảm độ phức tạp và tăng chú thích, có lẽ nó sẽ làm khá ổn
Mã giống như hóa chất dễ bay hơi: vừa là tài sản vừa là nợ. Nếu dùng đúng cách và nhanh chóng thì có thể kiếm ra tiền, nhưng nếu bỏ mặc hoặc làm tràn ra thì nó thành nợ. Mã nguồn không tự xuống cấp, nhưng khi mục tiêu và quy trình của tổ chức thay đổi, "mức độ phù hợp với mục đích" của nó cũng liên tục thay đổi
Tôi thấy chủ đề "Tại sao chúng ta không thể làm ra phần mềm đơn giản?" khá thú vị. Điểm gây ấn tượng là nhận xét về độ phức tạp: "khi các hệ thống tương tác với nhau thì độ phức tạp xuất hiện. Hệ thống phức tạp có thể lao đến sự phi lý, nhưng cũng có thể tạo ra tính sáng tạo bất ngờ"
Tôi nghĩ tài sản là chính phần mềm, chứ không phải mã là tài sản, giống như tài sản của đường cao tốc là hạ tầng hoàn chỉnh chứ không phải bê tông. Chất lượng bê tông ảnh hưởng đến mức suy giảm giá trị (khấu hao) và chi phí bảo trì của tài sản, từ đó lại ảnh hưởng đến giá trị tài sản. Ở đây nhất định cũng phải xét theo góc nhìn quản trị rủi ro
Ở đầu sự nghiệp, tôi từng nghĩ viết nhiều mã là điều quan trọng. Sau 20 năm, giờ tôi lại tự hào hơn về việc xóa được nhiều mã hơn. Từ góc nhìn của một kỹ sư bảo mật, mã không chỉ là nợ mà còn là rủi ro. Đặc biệt, phụ thuộc vào thư viện bên ngoài là một rủi ro lớn. Gần đây tôi cùng một đồng nghiệp viết một Linux init system nhỏ chưa đến 600 dòng chỉ dùng thư viện chuẩn của Rust, và nó đang được dùng trong production ở nhiều tổ chức. Không có dependency, khởi động cũng xong trong chưa đến 1 giây. Tôi thấy rằng vẫn có thể làm ra một máy chủ Linux kiểu appliance mà không cần systemd và hàng triệu dòng mã C. Nếu tự làm, lượng mã ít hơn rất nhiều và có thể hiểu hoàn toàn toàn bộ hệ thống
Tôi nghĩ kịch bản tệ nhất của mã do AI tạo ra hiện ra rõ hơn ở các dự án cá nhân, hơn là từ góc nhìn công ty. Tôi có thể tự viết 10.000 dòng mã tốt mà mình hiểu rõ, hoặc có thể làm nhanh gấp mấy lần để cho ra 20.000 dòng mã đầy vấn đề. Cá nhân tôi cố cân bằng ở đâu đó giữa hai thái cực đó. Nếu cứ tiếp tục mở rộng phát triển, thì tôi nghĩ thời gian lãng phí ở trường hợp đầu cuối cùng cũng là một thiệt hại
Tôi tin luôn tồn tại một điểm cân bằng. Với tôi, việc giao cho AI tạo mã thực tế chỉ giới hạn ở những đoạn mã tự khép kín như script Bash hay Python. Những script này chỉ tương tác với command line nên ranh giới rõ ràng và dễ quản lý. Loại mã như vậy thường viết xong là tôi không bao giờ nhìn lại nữa. Nhưng tạo mã cho domain cốt lõi của công việc bằng AI thì không mấy ý nghĩa nên tôi không làm vậy. Dù sao cũng phải code review, và điều tôi thực sự cần là những trường hợp mà tôi có thể xác minh được tính dễ bảo trì của mã. Nếu không phải là tình huống có thể vứt bỏ nguyên đoạn mã đó hoặc chỉ cần xem qua đơn giản, thì không cần dùng công cụ tạo mã. Nếu AI có thể đóng vai product owner, hiểu được tổn thất kinh doanh thực tế và còn cải thiện được nó, thì câu chuyện sẽ khác, nhưng khi đó lại phải lo cả rủi ro người dùng biến mất
Tôi cũng vậy, mỗi lần tin tưởng giao quá nhiều mã cho AI thì sớm muộn gì tôi cũng phải trả giá đắt bằng năng suất đã mất. Nếu một ứng dụng mà mọi thứ đều được làm kiểu vibe coding, thì có lẽ năng lực quan trọng nhất là khả năng phán đoán "liệu tính năng này có thực sự cần thiết không?". Việc debug spaghetti code mà hoàn toàn không hiểu từng dòng đang làm gì chắc hẳn là cực kỳ đau đớn
Bạn nói đã mất thời gian trong trường hợp thứ nhất, nhưng trường hợp thứ hai (mã tệ hơn, nhanh hơn) rốt cuộc cũng là mất thời gian. Bản chất vẫn là tìm ra điểm ở giữa
Mã ngắn gọn nhưng đặt tên biến sai hoặc quá khôn lỏi thì còn tệ hơn nhiều so với mã dài dòng hơn, được tài liệu hóa tốt và có tên biến phong phú. Nợ cuối cùng tỷ lệ thuận với thời gian cần để hiểu, sửa và mở rộng mã. Số dòng mã cũng không phải chỉ số có thể đo hoàn hảo món nợ này. Nếu mọi điều kiện thực sự như nhau, thì giảm lượng mã có thể làm hy sinh tính dễ đọc, và nợ thậm chí còn tăng lên. Vì vậy, có lẽ nói rằng "sự thiếu vắng lý thuyết mới là nợ" sẽ đúng hơn. Thậm chí từ góc nhìn LLM, mã ngắn còn có thể là nợ. Lý do là việc dùng LLM làm giảm tối đa quá trình xây dựng lý thuyết, đặc biệt trong bối cảnh hiện tại khi AI chưa thể tự xây dựng một lý thuyết về toàn bộ dự án rồi truyền đạt đúng đắn cho kỹ sư
Tôi thích xem lập trình là quá trình xây dựng lý thuyết. Đặc biệt với chương trình phục vụ kinh doanh thì lý thuyết đó phải lấy kinh doanh làm trung tâm. Ví dụ, tôi nghĩ nhất định phải có các góc nhìn như: "có thể tuyển lập trình viên cho codebase này một cách dễ dàng không", "mô hình kinh doanh ổn định đến đâu", "mức độ quan trọng về mặt kinh doanh của từng tính năng là gì"
Tự nhiên tôi nảy ra một ý. Không biết có thể hỏi AI về tên biến/mô tả hàm trong mã hay không. Từ trước đến nay tôi mới chỉ dùng AI để sinh mã
Trong số những công ty tôi gắn bó lâu năm, có nơi không có tài sản mã tự thân nhưng hoạt động kinh doanh cốt lõi lại phụ thuộc vào các dịch vụ enterprise 3rd party bên ngoài. Điều tôi thắc mắc là trong trường hợp này, phải đo lượng mã thực sự là bao nhiêu như thế nào? Ví dụ, nếu phụ thuộc vào một nhà cung cấp SaaS legacy, thì số dòng mã bên đó có nên được xem là nợ của chúng ta không?
Theo tôi, rủi ro lớn nhất khi phụ thuộc vào dịch vụ 3rd party là bên đó phá sản hoặc sau sáp nhập, mua lại thì điều kiện dịch vụ thay đổi. Phần lớn trường hợp là chúng ta phải dùng dịch vụ của những startup chỉ có vốn lớn nhưng bản thân dịch vụ lại chưa thực sự tự đứng vững
Tôi hoàn toàn đồng cảm với điểm này. Công ty cũ của tôi từng dùng một SaaS email marketing, mã tích hợp do chúng tôi viết chỉ có khoảng 500 dòng, nhưng vì dịch vụ có quá nhiều vấn đề nên chúng tôi vất vả chữa cháy khủng khiếp. Cuối cùng chúng tôi chỉ tái triển khai riêng những tính năng mình cần và đưa in-house, nhờ đó tiết kiệm được rất nhiều chi phí và công sức, dù số dòng mã tăng thêm khoảng 3.000 dòng
Tôi không thực sự hiểu.
Rõ ràng mã đúng là một tài sản, nhưng giống như phần cứng, nó bị khấu hao giá trị bởi nhiều nguyên nhân khác nhau (lỗi, thay đổi trong ngành phần mềm/phần cứng, v.v.). Càng có nhiều mã phần mềm thì chi phí khấu hao hàng năm càng tăng. Nếu không quản lý đủ tốt (ví dụ: lượng mã quá nhiều so với số lập trình viên), thì về sau chi phí sửa lỗi sẽ tăng theo cấp số nhân. Như thể có thêm cả "lãi suất" gắn vào khái niệm khấu hao. Vì vậy tôi hiểu vì sao người ta dùng từ "nợ", nhưng đó không phải là một khái niệm hoàn toàn trùng khít
Dĩ nhiên tôi nghĩ kho lưu trữ hoàn hảo nhất là cái này
Trước đây, thành tích đáng tự hào của tôi là xóa ròng 20 nghìn dòng mã mỗi tháng. Vài năm trước tôi định thử lại điều đó với một đội 20 lập trình viên remote, nhưng pull request đổ về nhiều đến mức tôi không thể theo kịp. Giờ tôi pair programming với Claude Code và GPT, và cảm giác hoàn toàn là vế sau. Tôi nghĩ ở đây có cơ hội refactor thông minh. Chỉ là có lẽ cần nhiều ngữ cảnh hơn. Tôi đã thử mấy việc kiểu này với mã legacy bằng Cursor và Claude opus 4.1, nhưng ngay cả một triệu token cũng không đủ. Có lẽ làm kiểu dịch giữa LLM cá nhân và LLM dùng chung thì sao nhỉ, không biết có ai có kinh nghiệm như vậy không
Có vẻ chẳng mấy ai đặt ra câu hỏi rất quan trọng là: "lượng mã tối thiểu tuyệt đối cần thiết để triển khai hoàn chỉnh tính năng X là bao nhiêu?". Tất nhiên không thể trả lời chính xác, nhưng chính cách nghĩ như vậy giúp tạo ra một tư duy hiệu quả. Trong khi đó, người ta lại rất quan tâm đến những thứ như formal verification vốn không thực sự quan trọng. Formal verification nếu không xét đến lượng mã khả thi tối thiểu thì ngược lại còn lãng phí và vô nghĩa. Và người ta thường mặc định mã do kỹ sư viết ra đều là tốt, trong khi thực tế phần lớn lại thêm vào những lớp trừu tượng và độ phức tạp không cần thiết, khiến công việc còn nhiều hơn. Một phần đáng kể của software engineering thực ra lại tạo ra giá trị âm. Dĩ nhiên có cả giá trị dương lẫn âm trộn lẫn, nên việc đánh giá càng khó hơn