Tại sao Code sạch vẫn quan trọng trong kỷ nguyên các tác nhân lập trình (AI Agents)?

Tại sao Code sạch vẫn quan trọng trong kỷ nguyên các tác nhân lập trình (AI Agents)?

Tóm tắt: Việc duy trì code sạch mang lại lợi ích kép cho cả lập trình viên con người và các tác nhân AI. Một cấu trúc mã nguồn tốt giúp giảm thiểu chi phí tính toán (token) và cải thiện hiệu suất làm việc của các mô hình ngôn ngữ lớn (LLM).

Sự tương đồng giữa con người và AI

Gần đây, tôi đã suy nghĩ về việc các tác nhân lập trình (coding agents) dù rất khác biệt với các lập trình viên con người, nhưng vẫn có những điểm tương đồng nhất định — năng suất của họ đều bị ảnh hưởng bởi trạng thái của cơ sở mã (codebase).

Robert Martin trong cuốn Clean Architecture đã nói về code có hai thuộc tính: giá trị (nó hoạt động, nó nhanh, v.v.) và cấu trúc (code được tổ chức như thế nào).

Trong khi giá trị là điều hiển nhiên với tất cả các bên liên quan, thì cấu trúc lại ít rõ ràng hơn. Cấu trúc kém có nghĩa là khó thêm tính năng mới hơn và lỗi sẽ nhân lên. Cuối cùng, nó làm mất đà và tốn tiền của công ty bạn. Đó không phải là vấn đề tức thời, mà là vấn đề dài hạn.

Đặc điểm của Code sạch

Code sạch có một số đặc điểm (nhưng hãy lưu ý rằng tất cả các đặc điểm này đều ảnh hưởng lẫn nhau):

• Khả năng đọc (Readability): Bất kỳ lập trình viên nào khác cũng có thể dễ dàng hiểu được chuyện gì đang xảy ra.
• Tính đơn giản (Simplicity): Nó hoàn thành công việc càng đơn giản càng tốt (nhưng không đơn giản hơn mức cần thiết).
• Tính mô đun (Modularity): Chia nhỏ code hợp lý thành các mô-đun, dù đó là lớp, hàm, tệp, thư mục hay vi dịch vụ.
• Khả năng kiểm thử (Testability): Viết bài kiểm thử (test) trở nên dễ dàng và thú vị.

Tất nhiên, nếu code có những đặc điểm này, việc thay đổi nó sẽ trở nên dễ dàng.

Code sạch và LLMs

Nhưng này, những ngày này chúng ta không cần quan tâm đến cấu trúc nữa đúng không? Chúng ta có LLMs để làm việc đó. Chúng ta thậm chí không cần đọc code nữa — chúng ta có thể tập trung vào kiểm tra kết quả đầu ra. Chúng ta cũng không đọc mã nhị phân đã biên dịch (compiled binary) mà, đúng không?

Chà, không hẳn.

Các tác nhân lập trình bị giới hạn bởi ngữ cảnh (context). Ngữ cảnh dài hơn có nghĩa là hiệu suất bị giảm, số lượng token sẽ tăng lên — và chi phí cũng sẽ tăng theo.

Ngữ cảnh về cơ bản là số lượng thứ mà máy móc có thể giữ trong bộ nhớ hoạt động của nó — nó không quá khác biệt so với tải nhận thức (cognitive load) của con người.

Giống như con người, code được tổ chức kém có nghĩa là các tác nhân cần đọc, "hiểu" và thay đổi nhiều tệp hơn mức cần thiết — làm ô nhiễm ngữ cảnh của chúng và tốn kém của bạn số token.

Nếu code của bạn được tổ chức đúng cách, việc triển khai một tính năng có thể chỉ yêu cầu mô hình đọc một vài tệp nhỏ và thực hiện thay đổi, thay vì phải đọc hàng chục tệp và đi vòng tròn.

Giống như bạn và tôi vậy.

Các bước thực tế

Tôi không có một giải pháp thần kỳ nào, nhưng đây là một số điều từ kinh nghiệm của tôi:

• Khi bạn giao một nhiệm vụ cho tác nhân của mình, hãy đảm bảo bạn cũng giải thích cách code nên được tổ chức. Không chỉ là giá trị, mà còn là cấu trúc.
• LLMs khá giỏi trong việc nắm bắt phong cách trong kho lưu trữ (repo) của bạn. Vì vậy, việc giữ cho nó sạch sẽ và có tổ chức đã giúp ích rất nhiều.
• Xem xét lại kết quả (Review). Tôi không nghĩ chúng ta có thể bỏ qua bước này vào lúc này. Theo quan điểm của tôi, một tác nhân không quan tâm đến cấu trúc, trừ khi bạn yêu cầu cụ thể. Nhưng ngay cả trong trường hợp đó, bạn vẫn phải xem xét lại các thay đổi.

"Context là cơ chế hoạt động của bộ nhớ — nó không quá khác biệt so với tải nhận thức của con người."

Kết luận là, dù bạn làm việc với đội ngũ con người hay các AI Agent, nguyên tắc "Clean Code" vẫn là nền tảng không thể thiếu để đảm bảo hiệu quả và tính bền vững của dự án.