- Về dài hạn, chi phí bảo trì quyết định năng suất nhiều hơn tốc độ viết mã mới
- Trong mô hình ví dụ, sau 2 năm rưỡi, công việc bảo trì chiếm hơn một nửa tổng thời gian
- Nếu agent AI vừa làm tăng sản lượng vừa làm tăng chi phí bảo trì, hiệu quả sẽ nhanh chóng biến mất
- Ngay cả khi ngừng dùng agent, chi phí bảo trì bổ sung của phần mã đã tạo ra vẫn tiếp tục tồn tại
- Nếu sản lượng tăng gấp đôi, chi phí bảo trì trên mỗi đơn vị mã cũng phải giảm một nửa
Chi phí bảo trì quyết định năng suất
- Mọi thời gian dùng để viết mã đều tiếp tục tạo ra thời gian bảo trì về sau như sửa lỗi, dọn dẹp, nâng cấp dependency
- Chỉ xét phần bảo trì lặp lại hằng năm miễn là mã còn tồn tại, không tính tính năng mới hay công việc cải tiến
- Ước tính ví dụ giả định rằng cứ mỗi 1 tháng viết mã thì trong năm đầu sẽ tốn 10 ngày bảo trì, và mỗi năm sau đó tốn 5 ngày
- Tác giả cho rằng nếu hỏi khoảng 50 lập trình viên về chi phí bảo trì theo cách Wisdom of the Crowd, có thể nhận được câu trả lời khá chính xác
- Theo mô hình bảng tính được xây dựng từ giả định này, ở giai đoạn đầu của dự án mới, phần lớn thời gian được dùng cho phát triển tính năng, nhưng theo thời gian tỷ trọng bảo trì mã cũ ngày càng tăng
- Trong ước tính đó, sau 2 năm rưỡi thời gian dành cho bảo trì vượt quá một nửa tổng thời gian, và sau 10 năm thì gần như rất khó làm được việc khác
- Nếu hạ ước tính bảo trì xuống một nửa thì có thể kéo dài thêm 3 năm trước khi chạm mốc 50%; nếu tăng gấp đôi thì năng suất sẽ rơi xuống dưới 50% chỉ trong chưa đầy 1 năm
- Nếu muốn có một đội ngũ làm việc hiệu quả, cần tập trung vào chi phí bảo trì hơn là tốc độ viết mã mới
Mô hình có thể sai, nhưng xu hướng thì đúng
- Ở các startup giai đoạn muộn, sau khoảng 5~9 năm đã xuất hiện vấn đề đội ngũ không còn hoàn thành công việc tử tế nữa, và điều này giống với mẫu hình trên đồ thị
- Lý do các đội ngũ thực tế có vẻ không tệ như biểu đồ có thể là vì chi phí bảo trì thấp hơn, hoặc vì vấn đề đã bị che đi bằng cách khác
- Những cách ứng phó có thể gồm: không sửa mọi lỗi, không nâng cấp mọi dependency, thêm người khi đội ngũ chậm lại rồi tiếp tục thêm nữa, hoặc bỏ toàn bộ để viết lại
- Có thể tranh luận về các con số chính xác, nhưng xu hướng lớn là năng suất giảm dần theo thời gian có vẻ đúng với trải nghiệm thực tế
Hiệu ứng nhân lên do AI coding agent tạo ra
- Ví dụ giả định framework coding dạng agent hiện đại Rock Lobster làm tăng gấp đôi sản lượng mã
- Đồng thời giả định rằng mã trở nên khó hiểu hơn một chút, cả nhóm bị quá tải bởi pull request, và không còn đọc kỹ mã trước khi phê duyệt
- Nếu trong một tháng tạo ra lượng mã tương đương hai tháng, và chi phí bảo trì của đầu ra đó cũng tăng gấp đôi, thì chi phí bảo trì của tháng tiếp theo sẽ tăng 4 lần
- Trong ví dụ cực đoan này, sau khoảng 5 tháng dùng Rock Lobster, năng suất quay về mức ban đầu, và vài tháng sau còn tệ hơn cả trường hợp không dùng nó
- Điều này không có nghĩa AI thực sự làm tăng gấp đôi năng suất hay chi phí bảo trì, mà nhấn mạnh rằng ngay cả khi khả năng bảo trì tương đương mã do con người viết, lợi ích năng suất cũng không kéo dài
Ngừng dùng agent cũng không xóa được chi phí bảo trì
- Coding agent có chi phí, và khi lợi ích của nó nhỏ hơn chi phí, người ta có thể muốn quay lại cách làm cũ
- Nếu ngừng dùng agent, lợi ích năng suất sẽ biến mất, nhưng chi phí bảo trì bổ sung của phần mã do agent tạo ra vẫn tồn tại chừng nào phần mã đó còn tồn tại
- Trong trường hợp này, bạn có thể bị kẹt ở mức năng suất thấp hơn cả khi chưa từng dùng agent
Phép toán chỉ đứng vững khi chi phí bảo trì giảm
- Chi phí bảo trì phải giảm đúng bằng nghịch đảo chính xác của tỷ lệ mà LLM làm tăng sản lượng mã thì phép tính năng suất tổng thể mới hợp lý
- Nếu sản lượng tăng gấp đôi và chi phí bảo trì của đầu ra đó cũng tăng gấp đôi, thì tổng chi phí bảo trì sẽ tăng 4 lần
- Nếu sản lượng tăng gấp đôi nhưng chi phí bảo trì trên mỗi đầu ra không đổi, thì tổng chi phí bảo trì vẫn tăng 2 lần
- Nếu sản lượng tăng gấp đôi thì chi phí bảo trì phải giảm một nửa; nếu sản lượng tăng gấp ba thì chi phí bảo trì phải giảm còn một phần ba
- Chỉ khi đáp ứng điều kiện này mới có thể vừa hưởng lợi về tốc độ vừa tránh bị trói buộc dài hạn
Lo ngại về coding agent hiện tại và những đòn bẩy khác có thể có
- Từ các nguồn như Hacker News, có vẻ xuất hiện nhiều tín hiệu cho thấy coding agent làm tăng chi phí bảo trì
- Một số người nói nó giúp hiểu các hệ thống lớn, nhưng theo tác giả thì chưa thấy mức giảm chi phí bảo trì đủ lớn cần thiết, thậm chí còn có vẻ ngược lại
- Mô hình không phản ánh hoàn hảo thực tế, nhưng thông điệp rằng AI phải giảm chi phí bảo trì tương xứng với tốc độ viết mã mới vẫn có giá trị
- Ngay cả khi theo đuổi việc cải thiện tốc độ coding, cũng cần dành từng ấy nỗ lực cho việc cải thiện chi phí bảo trì
- Đây không phải lập luận phản AI; ngoài việc nâng khả năng bảo trì của bản thân mã nguồn, vẫn có thể có những đòn bẩy khác như AI giúp chính các công việc bảo trì trở nên hiệu quả hơn
- Nếu muốn thay đổi các giả định cho phù hợp tình huống thực tế, bạn có thể sao chép bảng tính và điều chỉnh các biến trong mô hình
1 bình luận
Ý kiến trên Hacker News
Trong bài thuyết trình Dconf'24 Software as investment, họ đề xuất một khung nền tảng dựa trên các hàm giá trị có thể kết hợp cho từng mảnh phần mềm
Bản thân khung này không cần thay đổi gì đặc biệt vì AI, chỉ cần cập nhật mô hình chi phí riêng tùy theo việc AI làm tốt đến mức nào trong bảo trì
Có người nói AI tạo bug nhiều hơn 1,7 lần, nhưng có lẽ nó cũng sửa nhanh hơn, nên khó mà biết chắc
Nếu xem phần mềm là một khoản đầu tư, ta sẽ nói về “giá trị” thay vì “nợ kỹ thuật”, và nợ chỉ là tài sản có giá trị nhỏ hơn 0
Khi phần mềm rời khỏi thế giới biên lợi nhuận cao trước đây, ta cần định nghĩa thật chính xác phần mềm đáng để tồn tại về mặt kinh tế là gì
Trong phần mềm luôn có những chỗ lẽ ra có thể viết tốt hơn, và đó chính là nợ
Đây là một góc nhìn sâu sắc và tôi đồng ý
Đáng tiếc là tính dễ bảo trì thường bị bỏ vào cái rổ mang tên “yêu cầu phi chức năng”
Nhưng các yêu cầu phi chức năng như tính dễ bảo trì nên được xem là thứ bảo toàn và giúp việc chuyển giao các yêu cầu chức năng trong tương lai trở nên khả thi
Không nên chỉ đóng khung nó như chuyện “làm như thế nào” đối lập với việc phần mềm phải làm gì
Với những dự án mà việc liên tục bổ sung và cải tiến tính năng là quan trọng, thì ngoài giai đoạn rất ngắn ban đầu, tính dễ bảo trì thực tế gần như là một yêu cầu chức năng
Ngay khi đặt cho nó một cái tên riêng, bạn đã cho những người không thực sự hiểu nó cái cớ để quây riêng lại và hạ thấp ưu tiên
Chất lượng rất quan trọng, và nếu không duy trì nó, nó sẽ tác động vào báo cáo lãi lỗ rất nhanh và rất mạnh
Vì thế nó quan trọng ngang với bất kỳ yếu tố nào khác
Có thể dùng cách gọi của Kevlin Henney là đặc tính vận hành và đặc tính phát triển
Tính dễ bảo trì về bản chất là một đặc tính phát triển cốt lõi
Có thể họ có lộ trình sản phẩm 1~2 năm, nhưng nói thật thì những lộ trình như vậy thường gần với mục đích bán hàng hơn là kế hoạch kỹ thuật
Khi doanh thu chững lại, sản phẩm và kỹ thuật đổi hướng, và công ty càng ở giai đoạn đầu thì chuyện này càng hay xảy ra
Khi đã thoát khỏi chế độ startup thì lẽ ra phải ổn định hơn, nhưng nhiều công ty không làm vậy mà cứ lặp lại mô thức lập kế hoạch ngắn hạn
Kết quả là độ ổn định sản phẩm vẫn là ưu tiên thấp
Cuối cùng, có vẻ nhiều công ty либо không có nguồn lực để làm phần mềm tốt, либо thực sự không quan tâm
Khi xây dựng dự án của chúng tôi, tôi thấy AI rất nhanh, nhưng bug mà AI đưa vào lại kỳ lạ ở chỗ khó phát hiện
Không phải loại bug lộ liễu, mà là kiểu ba tuần sau trong môi trường production có thứ gì đó vỡ ra, lần theo mới thấy AI đã hiểu sai một chi tiết tinh vi nào đó
Thành thật mà nói, AI không hẳn làm giảm chi phí bảo trì mà dịch chuyển vị trí của chi phí
Thời gian viết giảm đi, thời gian review tăng lên
Mã do AI tạo ra, kể cả khi sai, vẫn trôi chảy và đầy tự tin, nên còn khó review hơn mã do người viết
Việc có lãi ròng hay không hoàn toàn phụ thuộc vào việc đội ngũ của bạn giỏi đọc mã đến mức nào hơn là giỏi viết mã
Theo kinh nghiệm của tôi, AI có giúp giảm chi phí bảo trì
Tuy vậy bối cảnh có thể rất quan trọng. Tôi đang xử lý nhiều dự án đã tồn tại hàng chục năm; ngoài phát triển tính năng mới, mã cũ và các dự án cũ bỗng trở nên dễ xử lý, dễ hiện đại hóa hơn rất nhiều, và trong nhiều trường hợp còn có thể loại bỏ hẳn
Phụ thuộc vào thư viện cũ và công cụ build cũ trong một số trường hợp đã được cập nhật, trong số khác thì đơn giản là bị gỡ bỏ; build nhanh hơn và cũng dễ hơn cho lập trình viên
Việc thiết lập và tự động hóa kiểm thử end-to-end cũng dễ hơn nhiều, DevOps cũng được cải thiện đáng kể, và việc chẩn đoán sự cố vận hành cũng tốt hơn hẳn
Có rất nhiều log và thông tin, cùng dashboard và giám sát tổng hợp để bắt những thứ quan trọng, nhưng giờ tôi có thể phân tích sâu hơn nhiều trên khoảng 50 dự án hệ thống đã triển khai
Luận điểm cốt lõi của bài là cứ mỗi 1 giờ phát triển tính năng “tạo thêm giá trị” thì phải làm bao nhiêu giờ bảo trì
Nên thứ nhất là không thể chỉ đo chi phí bảo trì mà phải nhìn vào tỷ lệ, và thứ hai là mã cũ đó ngay từ đầu đâu phải do AI viết
Nhưng ý của tác giả dường như là nếu mất quyền truy cập vào công cụ AI thì mọi thứ sẽ trở nên khó khăn hơn rất nhiều
Giống như đang dùng máy móc hạng nặng để chuyển núi cho nhẹ nhàng rồi lại phải quay về dùng dụng cụ cầm tay
Sự cố tăng lên cùng với số dòng mã được triển khai, và các sự cố cũng ngày càng nghiêm trọng hơn
Dĩ nhiên chúng tôi đã cải thiện rất nhiều mã cũ, xóa được nhiều hơn, có thể tự động hóa hiện đại hóa mã, chẩn đoán vấn đề cũng tốt hơn và có thêm lựa chọn giảm thiểu
Nhưng tất cả những điều đó vẫn không bù nổi quy mô áp đảo của lượng mã được triển khai khi chẳng ai thực sự hiểu rõ nó
Đội của chúng tôi dùng AI không chỉ để thêm mã mà còn để mạnh tay loại bỏ mã cũ đã bị bỏ quên
Những câu hỏi như “Còn ai dùng cái này không?” hay “Thứ này được gọi như thế nào?” trở nên dễ trả lời hơn nếu ném frontend, backend, cả codebase vào agent để nó tạo ra bản đồ của dự án phần mềm
IDE cũng làm được phần nào trong phạm vi một ngôn ngữ và thường là một dự án đơn lẻ, nhưng các ranh giới như RPC hay REST làm gãy nhiều công cụ IDE
Tôi rất thích câu hỏi này: nếu có thể chọn, bạn sẽ muốn một codebase như thế nào?
Chỉ cần nghĩ một chút thôi thì có lẽ bạn sẽ không muốn một codebase đầy ắp tính năng
Bạn sẽ muốn một codebase khá giống với cái đang có, nhưng dễ hiểu, dễ bảo trì và dễ mở rộng theo các bài toán kinh doanh trong tương lai
Một codebase “đang làm việc”, tức một codebase đang được bảo trì, đang giải quyết các vấn đề thực tế, và việc giải quyết những vấn đề đó luôn phải được ưu tiên hơn sự gọn gàng
Một codebase sạch sẽ thường là ví dụ trưng bày để đặt trên kệ ngắm hơn là thứ dùng để làm việc
Tôi muốn bổ sung hai điểm
Thứ nhất, phần mềm không chỉ có bảo trì kỹ thuật mà còn có hỗ trợ người dùng, và phần này cũng tăng lên khi phần mềm lớn dần
Thứ hai, tôi không tin chi phí bảo trì tăng theo tuyến tính
Kể cả nếu nó tăng tuyến tính, cuối cùng bạn cũng sẽ đến điểm phải dành toàn bộ thời gian cho bảo trì
Nếu phải bảo trì không chỉ từng phần mà cả cách các phần tương tác với nhau thì điều đó hoàn toàn có thể
Dấu hiệu mạnh nhất mà tôi thấy về việc AI có thực sự làm giảm chi phí bảo trì hay không là lập trình viên xem đầu ra của AI như bản nháp hay như sản phẩm cuối cùng
Khi dùng công cụ AI trên codebase hiện có, chẳng hạn để hiểu một module lạ, tạo refactor có mục tiêu, hay viết script migration, gánh nặng bảo trì thực sự giảm đi
Vì AI đang làm việc trên phần mã mà về mặt kiến trúc tôi đã hiểu sẵn, nên tôi có thể đánh giá đầu ra rất nhanh
Vấn đề xuất hiện khi AI tạo ra mã mới mà không ai hiểu thật sâu
Rồi sẽ có người phải bảo trì đoạn mã mà họ không viết cũng không thiết kế
Với mã do người khác viết, ít ra ta còn có thể suy ra ý đồ từ tên gọi, cấu trúc và lịch sử commit
Mã do AI tạo thường thiếu thứ ý đồ có thể đọc ra được đó, vì “tác giả” của nó không hề có một ý đồ nhất quán kéo dài trên toàn bộ tệp
Điểm mà bài viết nói đúng là không chỉ phải đo tốc độ mà còn phải đo cả chi phí bảo trì
Trên thực tế, nên theo dõi trong vài tháng chứ không phải vài ngày xem mã có AI hỗ trợ và mã do người viết tốn bao nhiêu thời gian để hiểu và tỷ lệ thất bại khi thay đổi là bao nhiêu
Review code cũng vậy
Tôi tự hỏi liệu AI có thể giúp review code dễ nhìn hơn không
Trong review mã do người viết, lập trình viên nhanh chóng học được cách tránh những thay đổi hình thức không cần thiết như reflow mã hoặc comment, đổi indent mà công cụ không thể ẩn đi, di chuyển hàm, hay xóa dòng
Cũng không nên refactor không cần thiết
Có lẽ nên tách review thành hai phần: thay đổi chức năng và thay đổi hình thức
Làm vậy review sẽ dễ hơn nhiều
Việc review sẽ bắt đầu từ giả định “không có gì được phép thay đổi”, và reviewer có thể pattern match
Nếu không thì reviewer phải đánh giá lại từng dòng mã để xác nhận rằng chẳng có gì thay đổi, và việc đó thật sự rất khó làm cho đúng
Các hệ thống quản lý phiên bản mà tôi từng dùng đều cho phép một hàng đợi các thay đổi được review một cách độc lập
Nếu trong lúc phát triển cần refactor, bạn tạo một commit để refactor, gửi đi review, rồi rebase phần việc đang làm và tiếp tục
Nếu cứ liên tục đẩy ra các thay đổi kiểu “CLEANUP:”, “REFACTOR_ONLY:” thì thay đổi cuối cùng sẽ nhỏ hơn rất nhiều so với một thay đổi quái vật khổng lồ
Reviewer sẽ biết ơn công sức đó
Với một tổ chức như vậy, việc chơi game chỉ số cũng có thể không trở thành điều độc hại
Có vẻ tác giả xuất phát từ giả định rằng con người phải xem xét kỹ mọi mã do AI tạo ra, và phải có khả năng hiểu cũng như bảo trì nó mà không cần trợ giúp của AI
Theo kinh nghiệm của tôi, mọi người không dùng AI như vậy
Lúc đầu thì có. Khi chưa tin tưởng nó và chưa học được cách prompt để ra kết quả mong muốn, họ dùng nó để tự động hóa phần nhàm chán, còn triển khai ban đầu hay pattern thì con người làm, AI lấp chỗ trống
Nó giống tự động hoàn thành được tăng cường hơn là một cuộc thay đổi lớn trong cách viết mã
Càng làm việc nhiều với AI, người ta càng bớt lo về đoạn mã mà AI thực sự tạo ra
Điều đó không có nghĩa là tốt. Nó có thể tạo bug, vấn đề hiệu năng, lỗ hổng bảo mật
Nhưng thực tế là vậy. Mã AI tạo có bug à? Bảo AI sửa đi
Mã AI tạo bị phình to và khó đọc à? Nếu quan tâm thì bảo AI sửa. Nhiều người không quan tâm
Khi con người rút hoàn toàn khỏi việc bảo trì mã, nhu cầu về mã có thể bảo trì cũng biến mất
Chúng ta chưa tới mức 100% như vậy, nhưng đang đi theo hướng đó
Ở nhiều công ty, vì “đủ tốt” nên việc chấp nhận rủi ro và YOLO vẫn đáng giá
Cá nhân tôi không tin AI đến mức không đọc mã nó tạo ra, nhưng tôi cũng không đọc từng dòng
Tôi xem test kỹ hơn phần mã được test, chú ý hơn tới các phần quan trọng về hiệu năng, và định hướng cấu trúc tổng thể
Nếu vẫn không đạt chuẩn thì tôi không tự bảo trì mà bảo AI sửa
Nếu bảo trì rẻ đến thế thì chi phí bảo trì sẽ không nằm trong mối quan tâm của tôi
Bài này nhấn mạnh khá tốt nhu cầu rằng agent hay công cụ hỗ trợ AI cần giúp được nhiều phần của phát triển phần mềm, chứ không chỉ đoạn ban đầu kiểu “hãy tạo widget mới”
Tác giả cho rằng nếu ai đó chỉ dùng agent hay công cụ hỗ trợ AI ở bước tạo widget mới, thì vì AI đẩy ra nhiều mã hơn, lượng mã phải bảo trì cũng tăng lên rất nhiều
Ngay cả khi chất lượng mã cao, theo thời gian chi phí bảo trì vẫn sẽ xuất hiện
Tuy nhiên, vấn đề mà tác giả nói tới dường như không hẳn là thứ mọi người đều sẽ gặp, mà phần lớn là vấn đề do chính họ tạo ra
Tình huống startup mà tác giả nêu ra — “hãy cứ làm cho nó chạy bằng mọi giá để kiểm chứng product-market fit và giữ khách hàng” — vốn dĩ từ trước đến nay đã luôn kéo theo chi phí bảo trì cao hơn về sau
Điều đó có phần hợp lý vì để xác nhận có kinh doanh được hay không, và nếu có thì tăng trưởng thật nhanh, người ta sẵn sàng đánh đổi chất lượng để lấy tốc độ
Tôi cũng cảm thấy tác giả có phần né tránh việc nói AI thực sự có thể giúp mảng bảo trì như thế nào
AI có thể rất hữu ích trong việc sửa các dependency cũ hay giải quyết những bug phiền toái nếu có sự dẫn dắt của con người
Đây là những việc thường khiến kỹ sư phần mềm cảm thấy như việc vặt, và cũng đúng là loại việc người ta muốn có AI hỗ trợ