Review code ngày càng đắt đỏ, viết lại code ngày càng rẻ rúng

Phần mềm16 tháng 6, 2026·3 phút đọc

Các mô hình ngôn ngữ lớn (LLM) có xu hướng tạo ra mã nguồn phức tạp hơn mức cần thiết, khiến quá trình review trở nên tốn kém hơn bao giờ hết. Tuy nhiên, nhờ khả năng của AI, việc viết lại và đơn giản hóa code hiện nay lại trở nên cực kỳ rẻ và nhanh chóng. Sự thay đổi trong kinh tế lập trình này đang buộc các nhà phát triển phải điều chỉnh quy trình làm việc của mình.

Các mô hình ngôn ngữ lớn (LLM) không hề lười biếng. Chúng không cắt góc vì cảm thấy giải pháp đơn giản là đủ tốt. Nếu chúng biết cách giải quyết vấn đề một cách triệt để, chúng sẽ làm vậy.

Một LLM mặc định sẽ tự xây dựng (build) khi lẽ ra nên sử dụng giải pháp có sẵn (buy). Không phải vì chúng không biết về các thư viện hiện có — chúng thường xuyên nhắc đến chúng — mà là vì đối với một LLM, việc viết hai trăm dòng mã thực thi có công sức nhận thức giống hệt như việc viết hai dòng lệnh import. Không có bản năng nào thúc đẩy chúng đi tìm con đường ngắn nhất. Con đường ngắn nhất đối với mô hình là triển khai nó hoàn toàn.

Do đó, việc review mã nguồn do AI tạo ra đã trở nên đắt đỏ hơn. Bạn đang đọc một đoạn mã về mặt kỹ thuật là đúng nhưng lại bị thiết kế quá mức (over-engineered), và bạn phải quyết định xem nên chấp nhận sự phức tạp đó hay yêu cầu sửa đổi. Quyết định này mất thời gian. Viết bình luận giải thích lý do trong quá trình review cũng mất thời gian. Và vì cùng một vấn đề lặp đi lặp lại, bạn phải trải qua cuộc hội thoại giống nhau mãi mãi.

Mặt khác, việc viết lại (rewrite) giờ đây lại rất rẻ. Nếu tôi phát hiện ra mã phức tạp hơn mức cần thiết, trong công việc của chính mình hoặc trong Pull Request của người khác, tôi sẽ yêu cầu AI đơn giản hóa nó, sử dụng thư viện, hoặc cắt bỏ các tính năng chưa cần thiết. Việc viết lại thường diễn ra nhanh chóng hơn. Mô hình đã tạo ra vấn đề cũng chính là cách nhanh nhất để khắc phục nó.

Kinh tế học của lập trình đã thay đổi. Reviewing hiện nay là bước tốn kém. Viết lại thì không.

Khối lượng công việc của tôi đã được tổ chức lại dựa trên thực tế này. Tôi dành nhiều thời gian hơn ở khâu lập kế hoạch ban đầu, quyết định những gì nên tồn tại, thư viện nào chúng ta sử dụng, phạm vi thực sự là gì, bởi vì đó là nơi tôi có thể ngăn chặn sự phức tạp trước khi nó được viết ra. Sau đó tôi triển khai, đẩy lên môi trường kiểm thử, xem xét những gì ở đó và xác định những gì không cần tồn tại hoặc có thể rút gọn từ trăm dòng xuống mười dòng. Sau đó tôi viết lại phần đó.

Nếu một thứ gì đó trong quá trình review cảm thấy quá mức, việc viết lại nó sau đó không còn là chi phí chìm (sunk cost) như trước đây. Điều đó đã thay đổi mức độ quyết liệt mà tôi phản đối. Chi phí để gắn cờ một vấn đề và lặp lại thấp hơn. Chi phí để cho nó qua thì vẫn như cũ.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗