Vấn đề không phải là viết mã, mà là không biết "bắt đầu từ đâu"

Nhiều nhiệm vụ phát triển phần mềm của chúng tôi thường bắt đầu theo một kịch bản rất giống nhau: một mô tả trên Jira mơ hồ, mất 20–30 phút chỉ để hiểu xem thực sự cần làm gì, sau đó nhảy qua lại giữa các tệp tin trong kho mã (codebase) để tìm điểm nhập phù hợp.

Nếu đó là một khu vực mã nguồn lạ, dễ dàng mất từ 1–2 tiếng trước khi viết được dòng code đầu tiên. Hoặc bạn đi hỏi người đã hiểu rõ vấn đề. Cách này ổn, nhưng không thể mở rộng quy mô (scale). Và điều này không hiếm gặp, nó trở nên khá bình thường.

Điểm mấu chốt của vấn đề

Chúng ta liên tục trả giá cho cùng một việc: hiểu ngữ cảnh, tìm ra các mẫu thiết kế (patterns), và học lại cách mọi thứ được thực hiện. Không có gì quá phức tạp, chỉ là công việc lặp đi lặp lại. Và nó phụ thuộc nặng nề vào việc: ai là người đã nắm rõ phần hệ thống này.

Giải pháp

Chúng tôi không cố gắng "tạo mã nhanh hơn". Thay vào đó, chúng tôi tập trung vào: hiểu + thực thi như một dòng chảy duy nhất. Không phải phép thuật, chỉ là cấu trúc.

1. Cung cấp ngữ cảnh hệ thống thực tế cho tác nhân (agent.md)

Một điểm nhập có cấu trúc (khoảng 500 dòng) bao gồm:

• Kiến trúc và các mẫu thiết kế.
• Các quy ước (mã, kiểm thử, ghi log).
• Cách mở rộng hệ thống.
• Các khu vực rủi ro và những cạm bẫy thường gặp.

Điều này loại bỏ nhu cầu "tự tìm hiểu mọi thứ từ con số 0".

2. Xây dựng prompt tùy chỉnh thực sự biết tư duy

Không chỉ là "tạo mã". Prompt sẽ thực hiện các bước sau:

• Hiểu nhiệm vụ (loại, phạm vi, ý định).
• Ước tính độ phức tạp.
• Quyết định xem nó có nên được giải quyết bởi tác nhân hay không.
• Tìm các phần liên quan của kho mã.
• Đề xuất các phương án triển khai.
• Xây dựng kế hoạch từng bước.
• Làm nổi bật các rủi ro.
• Tạo danh sách kiểm tra xác minh.

Nếu nhiệm vụ quá phức tạp, nó sẽ chia nhỏ thành các phần dễ quản lý hơn.

3. Sử dụng tác nhân ở nơi nó thực sự có ý nghĩa

Nếu độ phức tạp ở mức thấp/trung bình, prompt sẽ gợi ý rõ ràng việc sử dụng tác nhân. Lúc này, tác nhân đã có sẵn:

• Ngữ cảnh hệ thống.
• Các mẫu thiết kế đúng đắn.
• Một kế hoạch rõ ràng.

Vì vậy, nó có thể tạo ra:

• Mã nguồn phù hợp với kho lưu trữ.
• Bài kiểm thử cho chức năng mới.
• Bài kiểm thử hồi quy (regression tests) cho hành vi hiện có.

Không hoàn hảo, nhưng đủ tốt để loại bỏ phần lớn công việc thủ công lặp lại.

Kết quả đạt được

• Các nhiệm vụ ước tính mất 6–8 tiếng thường chỉ còn 2–3 tiếng.
• Các nhiệm vụ đơn giản giảm từ khoảng 1 tiếng xuống còn vài phút.
• Ít cần phải "tìm hiểu mọi thứ" trước khi bắt đầu hơn.

Điều này hoạt động vì:

• Ngữ cảnh được cung cấp ngay từ đầu.
• Việc triển khai được xử lý một phần.
• Các lỗi phổ biến được giảm thiểu.

Nhưng sự thay đổi chính nằm ở:

• Ít gánh nặng tinh thần (mental overhead) hơn.
• Bắt đầu nhanh hơn.
• Ít bị gián đoạn hơn.

Bài học rút ra

Hầu hết các đội ngũ không gặp vấn đề về viết mã. Họ gặp vấn đề về "thời gian để hiểu" (time-to-understanding).

Nếu mọi nhiệm vụ đều bắt đầu bằng việc đào bới hệ thống và học lại các mẫu thiết kế, đó chính là nút thắt thực sự. AI sẽ hữu ích khi:

• Nó hiểu hệ thống của bạn.
• Và được sử dụng có chọn lọc.

Tôi thấy rất nhiều trường hợp: Các đội ngũ hoặc không sử dụng AI, hoặc cố gắng sử dụng nó ở khắp mọi nơi. Cách tiếp cận nào cũng không hiệu quả.