Muốn chọn đúng trợ lý AI viết mã, bạn cần một danh sách tiêu chí viết ra trước và hai tuần dùng thử trên chính công việc hằng ngày, có ghi chép, thay vì vài buổi tối thử những bài toán mẫu. Bài toán mẫu ngắn, sạch, không dính tới dự án cũ nào; công việc thật thì đầy quy ước riêng, thư viện cũ và đoạn mã không ai dám đụng. Công cụ giỏi ở loại thứ nhất chưa chắc giỏi ở loại thứ hai.
Bài này đưa ra bảy tiêu chí theo thứ tự nên xét, từ những thứ loại ngay một công cụ (không hỗ trợ ngôn ngữ của bạn, điều khoản dữ liệu không hợp quy định công ty) tới những thứ chỉ cảm được sau nhiều ngày dùng (gợi ý có hợp tay không). Phần cuối là cách tổ chức hai tuần dùng thử để cuối kỳ bạn có số liệu của chính mình, không phải cảm giác.
Ba tiêu chí loại vòng ngoài
Ngôn ngữ và khuôn khổ bạn dùng thật. Hầu hết trợ lý làm tốt với Python, JavaScript, TypeScript, Java vì đây là những ngôn ngữ có nhiều mã công khai. Với PHP đời cũ, Dart, Kotlin, các ngôn ngữ ít phổ biến hơn hay khuôn khổ nội bộ, chất lượng chênh lệch rõ hơn. Đừng tin danh sách "hỗ trợ hơn năm mươi ngôn ngữ" trên trang giới thiệu; hỗ trợ nghĩa là có gợi ý, không có nghĩa là gợi ý tốt.
Trình soạn thảo và hệ điều hành. Kiểm công cụ có chạy trên trình soạn thảo cả nhóm đang dùng không, có đủ tính năng ở đó không. Nhiều sản phẩm làm bản cho trình soạn thảo phổ biến nhất trước, bản cho các trình soạn thảo khác ra sau và thiếu một số tính năng. Nếu bạn lập trình qua kết nối từ xa vào máy chủ, kiểm thêm công cụ có hoạt động trong chế độ đó không.
Điều khoản dữ liệu so với quy định nơi bạn làm. Đọc mục dữ liệu của gói bạn định dùng: mã gửi đi có được lưu không, lưu bao lâu, có dùng để huấn luyện mô hình không, có tắt được không, máy chủ đặt ở đâu. Nếu công ty có danh sách công cụ được duyệt, tiêu chí này quyết định luôn. Gói cá nhân và gói doanh nghiệp của cùng một hãng thường khác nhau ở chính mục này.
Bốn tiêu chí còn lại và cách kiểm từng tiêu chí
Qua được vòng ngoài, bốn tiêu chí dưới đây quyết định bạn có dùng lâu được không. Cột thứ ba là cách kiểm cụ thể trong lúc dùng thử.
| Tiêu chí | Câu hỏi cần trả lời | Cách kiểm khi dùng thử |
|---|---|---|
| Ngữ cảnh dự án | Công cụ hiểu dự án tới đâu: chỉ tệp đang mở hay cả kho mã | Hỏi "hàm này được gọi ở những chỗ nào" và đối chiếu với kết quả tìm kiếm của trình soạn thảo |
| Chi phí theo mức | Gói miễn phí, gói cá nhân, gói doanh nghiệp khác nhau ra sao; có hạn mức lượt dùng không | Ghi lại số lần chạm giới hạn trong hai tuần; đọc mục hạn mức của gói hiện hành |
| Làm việc nhóm | Có tài khoản tổ chức, quản trị tập trung, tệp hướng dẫn dùng chung không | Thử chia sẻ một tệp hướng dẫn dự án và xem công cụ có tuân theo không |
| Độ hợp tay | Gợi ý có đúng lúc, đúng độ dài, có làm chậm trình soạn thảo không | Đếm số gợi ý nhận và bỏ trong một buổi; để ý cảm giác bị cắt mạch |
Tiêu chí chi phí ở đây chỉ xét theo mức, không theo con số, vì bảng giá các hãng thay đổi liên tục. Điều cần biết là gói nào có giới hạn lượt dùng cho mô hình mạnh, vượt giới hạn thì công cụ chậm lại, chuyển sang mô hình nhỏ hơn hay tính thêm tiền.
Tiêu chí ngữ cảnh: phần khác biệt lớn nhất giữa các công cụ
Hai công cụ dùng cùng một mô hình có thể cho kết quả rất khác nhau, vì cái quyết định là công cụ đưa những gì vào cho mô hình đọc. Một công cụ chỉ thấy tệp đang mở sẽ gợi ý gọi hàm theo tên nó đoán; một công cụ tìm được định nghĩa thật của hàm trong tệp khác sẽ gợi ý đúng tham số. Khi dùng thử, đây là tiêu chí nên kiểm kỹ nhất.
Cách kiểm đơn giản: chọn một hàm có thật trong dự án, được gọi ở ba bốn nơi, rồi hỏi công cụ nó làm gì và ai gọi nó. So câu trả lời với kết quả tìm kiếm của chính trình soạn thảo. Tiếp theo, nhờ công cụ viết thêm một hàm mới dùng lại một tiện ích sẵn có trong dự án; công cụ tốt sẽ dùng tiện ích đó, công cụ kém sẽ viết lại từ đầu một bản na ná. Cuối cùng, thử với một tệp lớn vài nghìn dòng để xem công cụ có còn nhớ phần đầu tệp không.
Cũng để ý cách công cụ cho bạn kiểm soát ngữ cảnh: có chọn tệp đưa vào được không, có loại trừ thư mục được không, có đọc tệp hướng dẫn dự án không. Kiểm soát được ngữ cảnh vừa giúp kết quả tốt hơn, vừa giúp giữ các tệp nhạy cảm như cấu hình môi trường ra ngoài.
Tính trước đường lui trước khi gắn bó với một công cụ
Một câu hỏi ít người đặt ra lúc chọn: nếu sáu tháng sau phải bỏ công cụ này thì mất gì. Trợ lý chỉ đưa gợi ý trong trình soạn thảo gần như không để lại dấu vết, bỏ là xong. Công cụ đã được nhóm viết hàng chục tệp quy tắc theo định dạng riêng, đã gắn vào quy trình rà soát mã và tích hợp liên tục, thì chuyển đi tốn nhiều công hơn hẳn.
Cách giữ đường lui là ưu tiên những gì viết bằng chữ thường và để trong kho mã của chính bạn. Tệp hướng dẫn dự án viết bằng văn bản thuần, đặt ở thư mục gốc, có thể đổi tên hoặc chép sang định dạng công cụ khác trong vài phút. Câu lệnh mẫu hay dùng nên lưu thành tệp trong kho thay vì chỉ nằm trong lịch sử trò chuyện của một tài khoản. Kịch bản tự động hoá nên gọi công cụ qua một lớp nhỏ do nhóm tự viết, để đổi công cụ thì chỉ sửa một chỗ.
Tiêu chí này không loại công cụ nào, nhưng giúp bạn chọn cách dùng. Khi hai công cụ ngang nhau ở các tiêu chí khác, chọn công cụ để lại ít ràng buộc hơn. Thị trường còn đổi nhanh, công cụ đứng đầu năm nay chưa chắc còn hợp năm sau, và một nhóm chuyển đổi nhẹ nhàng luôn có lợi thế.
Tổ chức hai tuần dùng thử có ghi chép
Dùng thử chỉ có giá trị khi bạn so được trước và sau. Dưới đây là cách tổ chức gọn, mỗi ngày tốn thêm khoảng năm phút ghi chép.
- Trước khi bắt đầu, liệt kê năm loại việc bạn làm nhiều nhất trong tháng qua, ví dụ thêm API mới, sửa giao diện, viết câu SQL, viết kiểm thử, đọc mã của đồng nghiệp.
- Tạo một tệp ghi chép đơn giản với các cột: ngày, việc, công cụ giúp được gì, công cụ làm sai gì, thời gian ước tính tiết kiệm hoặc mất thêm.
- Tuần đầu chỉ dùng phần gợi ý và chat cơ bản, chưa đụng các tính năng nâng cao, để làm quen nhịp gợi ý.
- Tuần thứ hai thử các tính năng lớn hơn trên nhánh git riêng: sửa nhiều tệp, sinh kiểm thử, giải thích mã cũ.
- Mỗi lần công cụ đưa ra mã sai mà trông đúng, ghi lại cụ thể sai ở đâu và bạn phát hiện bằng cách nào.
- Cuối tuần thứ hai, đọc lại tệp ghi chép và chấm từng tiêu chí theo ba mức: tốt, tạm, không đạt.
Nếu thử hai công cụ, đừng chạy song song trong cùng thời gian vì sẽ không phân biệt được gợi ý của ai. Thử lần lượt, mỗi công cụ hai tuần, trên những loại việc giống nhau.
Đọc kết quả dùng thử cho trung thực
Cuối hai tuần, cảm giác thường thiên về công cụ mới: mọi thứ lạ đều có vẻ nhanh hơn. Tệp ghi chép giúp bạn cân lại. Hãy nhìn vào cột "làm sai gì" trước cột "giúp được gì". Một công cụ tiết kiệm mười phút mỗi ngày nhưng hai lần trong tuần đưa ra mã sai mà bạn chỉ phát hiện lúc chạy kiểm thử, cần được tính đủ cả thời gian gỡ lỗi đó.
Tiếp theo, xem công cụ giúp ở loại việc nào. Nếu nó chỉ giỏi ở những việc vốn đã nhanh, như viết lại vòng lặp hay đặt tên biến, lợi ích thật nhỏ hơn cảm nhận. Nếu nó giúp ở những việc tốn thời gian và chán, như viết kiểm thử cho mã cũ hay đọc hiểu mô-đun lạ, đó là lợi ích đáng tiền. Ví dụ giả định: một lập trình viên ghi được rằng công cụ giúp nhiều nhất ở việc viết câu SQL phức tạp và kém nhất ở giao diện, thì có thể chọn công cụ đó nhưng tắt bớt gợi ý khi làm giao diện.
Cuối cùng, hỏi thêm một người cùng nhóm đã thử. Hai bản ghi chép trên hai kiểu việc khác nhau cho bức tranh đầy đủ hơn hẳn một người. Nếu kết quả hai người trái ngược, thường là do khác loại việc chứ không phải ai đúng ai sai.
Dấu hiệu nên dừng sớm và đổi công cụ khác
Không cần đợi hết hai tuần nếu gặp những dấu hiệu dưới đây. Chúng cho thấy công cụ không hợp với dự án hoặc với cách bạn làm việc, chứ không phải bạn chưa quen.
- Công cụ liên tục gợi ý hàm, lớp hoặc tham số không tồn tại trong thư viện bạn dùng, kể cả sau khi bạn đã đưa tệp liên quan vào ngữ cảnh.
- Trình soạn thảo chậm rõ rệt, gõ bị trễ hoặc treo khi mở dự án lớn từ lúc cài công cụ.
- Điều khoản dữ liệu thay đổi trong lúc bạn dùng thử theo hướng không còn hợp quy định của công ty.
- Bạn thấy mình nhận gợi ý mà không đọc, vì đọc mất công hơn tự gõ. Đây là dấu hiệu gợi ý quá dài hoặc quá nhiều, nên chỉnh lại trước khi kết luận về công cụ.
- Công cụ không cho tắt hoặc loại trừ những tệp bạn không muốn gửi đi, như tệp biến môi trường hay thư mục chứa dữ liệu mẫu có thông tin thật.
Với dấu hiệu thứ tư, thử chỉnh độ dài và tần suất gợi ý trước; nhiều công cụ cho phép gợi ý chỉ hiện khi bạn bấm phím tắt. Với các dấu hiệu còn lại, đổi công cụ là hợp lý.
Câu hỏi thường gặp
Dùng thử trợ lý AI viết mã bao lâu thì đủ để quyết định?
Khoảng hai tuần trên công việc thật là vừa. Tuần đầu bạn còn đang quen nhịp gợi ý nên đánh giá dễ lệch; tuần thứ hai mới thấy rõ công cụ giúp ở việc nào và sai ở việc nào. Thử ngắn hơn thường chỉ đo được cảm giác mới lạ.
Có nên so trợ lý AI bằng các bài toán lập trình mẫu không?
Chỉ nên dùng để loại nhanh công cụ quá kém. Bài toán mẫu ngắn và sạch, không giống dự án thật có quy ước riêng, thư viện cũ và nhiều tệp liên quan. Kết quả quyết định nên đến từ việc thật bạn làm hằng ngày.
Gói miễn phí có đủ để đánh giá một công cụ không?
Đủ để đánh giá độ hợp tay và chất lượng gợi ý cơ bản, nhưng thường thiếu các tính năng nâng cao và có hạn mức lượt dùng. Nếu định mua gói trả phí, nên dùng thử đúng gói đó trong thời gian dùng thử nếu hãng cho phép, và đọc riêng phần điều khoản dữ liệu của gói.
Tiêu chí nào quan trọng nhất khi chọn trợ lý AI cho mã của công ty?
Điều khoản dữ liệu và quy định của công ty đứng đầu, vì nó loại ngay một công cụ dù gợi ý tốt đến đâu. Sau đó mới tới khả năng hiểu ngữ cảnh dự án, vì đây là phần khác biệt nhiều nhất giữa các công cụ dùng cùng loại mô hình.
Ghi chép khi dùng thử nên ghi những gì?
Ghi ngày, loại việc, công cụ giúp được gì, công cụ làm sai gì và bạn phát hiện sai bằng cách nào, kèm thời gian ước tính được hay mất. Phần ghi lỗi quan trọng hơn phần ghi lợi ích, vì lỗi trông đúng mà sai là thứ tốn thời gian nhất về sau.
Hai người trong nhóm đánh giá trái ngược nhau thì nghe ai?
Thường cả hai đều đúng với loại việc của mình. Đặt hai bản ghi chép cạnh nhau, xem mỗi người làm loại việc gì là ra. Nhóm có thể chọn công cụ hợp với phần việc chiếm nhiều thời gian nhất, rồi thống nhất cách tắt bớt gợi ý ở phần việc còn lại.