Bạn Cần AI Giúp Giảm Chi Phí Bảo Trì, Không Chỉ Tăng Tốc Độ Viết Code

Tôi sẽ đi thẳng vào vấn đề: tác nhân AI viết code (AI coding agent) mà bạn đang sử dụng cần phải giúp giảm chi phí bảo trì cho bạn. Không phải giảm một chút xíu, mà là giảm đáng kể.

Nếu bạn viết code nhanh gấp đôi bây giờ, bạn tốt nhất nên hy vọng rằng chi phí bảo trì cũng giảm đi một nửa. Nếu năng suất tăng gấp ba, chi phí bảo trì phải giảm xuống một phần ba. Nếu không, bạn sẽ gặp rắc rối lớn. Bạn đang đánh đổi tốc độ nhất thời để lấy sự nô lệ dài hạn.

Tại sao lại như vậy? Hãy cùng đi tìm câu trả lời.

Năng suất được quyết định bởi chi phí bảo trì

Mỗi dòng code bạn viết đều cần được bảo trì: sửa lỗi, dọn dẹp, nâng cấp thư viện phụ thuộc, v.v. Tôi không đang nói về việc xây dựng tính năng mới hay cải tiến, chỉ là bảo trì thuần túy. Với mỗi tháng bạn dành để viết code, bạn sẽ mất một lượng thời gian nhất định trong năm following để bảo trì đoạn code đó, và cứ như vậy mãi mãi, miễn là code đó còn tồn tại.

Hãy tưởng tượng bạn hỏi một nhóm, nói khoảng 50 nhà phát triển, về chi phí bảo trì này. Sử dụng một kỹ thuật gọi là "Sự khôn ngoan của đám đông" (Wisdom of the Crowd), bạn có thể nhận được một câu trả lời khá chính xác.

Nhóm đó có thể nói với bạn rằng, với mỗi tháng dành để viết code, bạn sẽ mất:

• 10 ngày để bảo trì trong năm đầu tiên; và
• 5 ngày để bảo trì trong mỗi năm sau đó.

Nếu bạn là người cầu thị, bạn có thể dành hàng giờ để tạo một bảng tính mô hình hóa cách những ước tính này ảnh hưởng đến năng suất theo thời gian.

Biểu đồ tác động của chi phí bảo trì theo thời gian

Tháng đầu tiên của một dự án mới là tuyệt vời. Bạn dành toàn bộ thời gian để xây dựng các tính năng mới hào nhoáng. Tháng thứ hai thì kém hào nhoáng hơn một chút. Một phần thời gian của bạn — không nhiều, nhưng một chút — sẽ dành để sửa lỗi và dọn dẹp những sai sót thiết kế từ tháng đầu tiên. Đến tháng thứ ba, thì nhiều hơn một chút. Và tháng thứ tư, thứ năm, thứ sáu...

Cuối cùng, nó không còn tuyệt vời chút nào. Theo ước tính bảo trì của nhóm, sau 2,5 năm, bạn sẽ dành hơn một nửa thời gian để bảo trì. Sau mười năm, bạn gần như không thể làm gì khác nữa.

Bài học ở đây rất rõ ràng. Nếu bạn muốn một đội ngũ năng suất, bạn phải tập trung vào chi phí bảo trì của họ.

Vấn đề nằm ở đâu với AI?

Tất cả là ở đây.

Hãy nói rằng đội ngũ của bạn vừa bắt đầu sử dụng "Rock Lobster", khung lập trình tác nhân (agentic coding framework) mới nhất và tuyệt vời nhất, và nó giúp TĂNG ĐÔI!! lượng code đầu ra! Tuyệt vời! Tuy nhiên, code này khó hiểu hơn một chút, đội ngũ của bạn đang bị ngập trong các pull request, và có thể bạn... ừm... thực sự không đọc code trước khi nhấn nút phê duyệt. Bạn chỉ lướt qua nó trong các cuộc họp nhàm chán, và điều đó chắc chắn là đủ tốt, đúng không? LGTM (Looks Good To Me), cứ làm đi!

Vậy bây giờ bạn đang sản xuất khối lượng công việc của hai tháng trong một tháng, và giả sử rằng chi phí bảo trì cho mỗi "tháng" đầu ra đó đã tăng gấp đôi. Chi phí bảo trì của tháng sau sẽ tăng gấp bốn lần.

Ối.

Khoảng năm tháng sau khi bạn bắt đầu sử dụng Rock Lobster, năng suất của bạn quay trở lại điểm xuất phát, và vài tháng sau đó, nó thậm chí còn tệ hơn so với việc bạn chưa từng chạm vào Rock Lobster.

Tôi không nói rằng AI của bạn làm tăng gấp đôi chi phí bảo trì hay năng suất. Đây là một ví dụ cực đoan. Nhưng ngay cả khi AI của bạn tạo ra code dễ bảo trì như code do con người viết, thì lợi ích về năng suất cũng không kéo dài.

Bạn có thể rời đi bất cứ lúc nào bạn thích... Nhưng không bao giờ thoát ra được

Các tác nhân AI rất đắt đỏ và chúng ngày càng đắt hơn. Một khi "nước ép" từ tác nhân không còn xứng đáng với công sức bỏ ra, bạn có thể quyết định tiết kiệm tiền và quay lại viết code theo cách cũ. Như người thời đồ đá. Dùng ngón tay.

Ha! Trò đùa lại nằm trên bạn rồi! Khi bạn ngừng sử dụng tác nhân, tất cả lợi ích về năng suất biến mất... nhưng chi phí bảo trì thêm vào thì không! Miễn là đoạn code đó vẫn còn đó, bạn bị mắc kẹt với năng suất thấp hơn so với việc bạn chưa từng đụng đến tác nhân đó.

Con đường thoát

Toán học chỉ hoạt động nếu LLM giảm chi phí bảo trì của bạn, và giảm chính xác tỷ lệ nghịch với tốc độ thêm code mới. Nếu bạn tăng gấp đôi đầu ra và chi phí bảo trì cho đầu ra đó cũng tăng gấp đôi, thì hai nhân hai có nghĩa là bạn đã tăng gấp bốn lần chi phí bảo trì. Nếu bạn tăng gấp đôi đầu ra và giữ chi phí bảo trì không đổi, hai nhân một có nghĩa là bạn vẫn đã tăng gấp đôi chi phí bảo trì.

Thay vào đó, bạn phải đảo ngược năng suất của mình. Nếu bạn tạo ra gấp đôi lượng code, bạn cần code có chi phí bảo trì giảm đi một nửa. Gấp ba lượng code, thì chỉ còn một phần ba chi phí bảo trì.

Đó là bí mật để thành công. Tận hưởng mọi lợi ích, không bị ràng buộc.

Chúng ta có thể giết con quái vật này không?

Tôi không biết. Tất cả những gì tôi đọc từ các nguồn tin tức uy tín đều cho biết các tác nhân viết code làm tăng chi phí bảo trì. Một số người nói rằng chúng giúp họ hiểu các hệ thống lớn tốt hơn. Nhưng những sự giảm lớn về chi phí, ở mức độ chúng ta cần thấy thì không. Hết sức trái ngược.

Đó là một vấn đề. Mô hình không phải là đại diện hoàn hảo cho thực tế, nhưng thông điệp tổng thể là đúng. Bạn cần AI giúp giảm chi phí bảo trì, và tỷ lệ thuận với mức tăng tốc độ bạn có được từ code mới. Nếu không có nó, bạn sẽ gặp rắc rối. Bạn đang đánh đổi tốc độ nhất thời để lấy sự nô lệ dài hạn.

Vì vậy, vâng, hãy tiếp tục theo đuổi việc cải thiện tốc độ viết code của bạn. Nhưng hãy dành cũng nhiều thời gian để theo đuổi việc cải thiện chi phí bảo trì của bạn. Nếu không, bạn cũng sẽ bị mắc kẹt trong "Hotel California".

Một nơi tuyệt vời. Một gương mặt xinh đẹp.

Dù có vẻ như vậy, nhưng điều này không có ý định là một bài bài bác AI. Có những đòn bẩy khác để kéo, chẳng hạn như AI làm cho việc bảo trì本身 năng suất hơn, ngay cả khi nó không làm code dễ bảo trì hơn. Tôi khuyến khích bạn sao chép bảng tính và chơi với tất cả các đòn bẩy trong mô hình. Hãy xem điều gì xảy ra khi bạn thay đổi các giả định để phù hợp với tình huống thực tế của bạn.