AI viết code nhanh: kiểm tra thế nào trước khi dùng?

Đoạn code tính tiền chạy ngon với giỏ hàng đầu tiên. Hai sản phẩm, một mã giảm giá, tổng tiền hiện đúng như mong đợi. Đến khi khách bỏ hết hàng, màn hình lại giữ nguyên số tiền cũ. Người viết nhìn đoạn code AI vừa tạo và nhận ra: chạy được một lần chưa có nghĩa là đã xử lý đúng.

Đây là tình huống giả định của Nam, một lập trình viên đang sửa trang đặt hàng. Câu chuyện không nhằm bắt lỗi một công cụ cụ thể. Nó cho thấy cách dùng AI để viết bản nháp, rồi kiểm tra bằng yêu cầu thực tế. Đích đến là đoạn code người khác đọc hiểu, kiểm chứng và bảo trì được.

Nói rõ đoạn code cần làm gì trước khi nhờ AI viết

Yêu cầu ban đầu của Nam chỉ có một dòng: viết hàm tính tổng giỏ hàng có giảm giá. Nghe rõ, nhưng còn quá nhiều chỗ trống. Giảm trước hay sau phí giao hàng? Mã có áp dụng cho mọi sản phẩm không? Giỏ rỗng trả về số không hay báo lỗi? AI phải tự đoán những điều chưa được nói.

Nam quay lại trao đổi với người phụ trách sản phẩm. Trong ví dụ này, mã giảm chỉ áp dụng cho tiền hàng, không áp dụng phí giao. Giỏ rỗng không được đặt đơn. Nhóm cũng đã có quy tắc xử lý tiền và làm tròn trong dự án. Phần code mới phải theo quy tắc ấy.

Prompt sau đó nêu đầu vào, kết quả mong đợi, các giới hạn và một đoạn triển khai tương tự đang hoạt động. Nam yêu cầu công cụ chỉ sửa phần liên quan. Khi thấy câu trả lời tự thêm một cách lưu tiền khác, cậu hỏi lại ngay. Viết thêm nhiều dòng không giúp ích nếu làm lệch cách hệ thống đang chạy.

Thử dữ liệu thường gặp rồi đến các ca dễ lỗi

Nam bắt đầu bằng giỏ có hai món với giá trị dễ tính bằng tay. Cậu ghi trước kết quả mong đợi, rồi mới chạy hàm. Sau đó là giỏ một món, giỏ rỗng và sản phẩm có số lượng bằng không. Những ca này bám vào hành vi người dùng và quy tắc nhóm vừa chốt.

Với mã giảm giá, Nam thử mã hợp lệ, mã không áp dụng cho món đang mua và trường hợp mức giảm vượt tiền hàng. Cách xử lý phải do yêu cầu quyết định. Nếu chưa có quy tắc, cậu đánh dấu để hỏi, thay vì chọn đại một kết quả rồi viết test chứng minh lựa chọn ấy đúng.

Cậu cũng thử thao tác đổi số lượng sau khi đã nhập mã. Lỗi lúc đầu xuất hiện ở đây: phần hiển thị chưa cập nhật theo giỏ mới. Chỉ kiểm tra riêng hàm tính sẽ bỏ sót vấn đề. Một luồng người dùng ngắn giúp nối kết quả tính toán với thứ khách thực sự nhìn thấy.

Đừng để bài kiểm tra lặp lại đúng giả định của AI

Nam có thể nhờ AI gợi ý thêm test, nhưng không nhận nguyên bộ mà bỏ qua việc đọc. Nếu cả code lẫn test cùng hiểu sai phí giao hàng, chúng vẫn có thể đồng ý với nhau rất vui vẻ. Màu xanh khi chạy test chỉ nói rằng code khớp với những điều đang được kiểm tra.

Cậu đối chiếu từng kết quả mong đợi với quy tắc đã xác nhận. Một đồng nghiệp đọc riêng bảng ví dụ trước khi xem phần triển khai. Người đó phát hiện một ca thiếu: khách xóa sản phẩm duy nhất được giảm giá nhưng mã vẫn hiện đang áp dụng. Đây là câu hỏi nghiệp vụ, không phải chuyện cú pháp.

Bộ kiểm tra tốt cần giúp phát hiện sai lệch có ý nghĩa. Không nhất thiết thêm hàng chục test chỉ để đủ số. Với mỗi ca, Nam viết một câu: nếu ca này lỗi, khách sẽ gặp chuyện gì? Câu trả lời khiến việc chọn test rõ hơn và giúp người review hiểu vì sao chúng tồn tại.

Nhìn rộng hơn một hàm đơn lẻ

Giá trị trên màn hình chưa phải toàn bộ đơn hàng. Nam lần theo dữ liệu từ lúc khách chọn món đến lúc máy chủ xác nhận. Cậu kiểm tra nơi lấy giá, nơi áp dụng mã và nơi lưu tổng tiền. Nếu hai nơi dùng hai bộ quy tắc khác nhau, sửa một hàm vẫn chưa giải quyết xong.

Cậu đọc phần đặt hàng đã có trong dự án thay vì tự dựng một luồng mới. Các quy tắc về quyền truy cập, dữ liệu đầu vào và phản hồi lỗi cũng cần được giữ đúng. Nếu thay đổi làm người dùng gặp thông báo khác, phía giao diện phải hiểu thông báo ấy để hiển thị được.

Những chỗ chưa thuộc phạm vi sửa được ghi lại riêng. Nam không tiện tay đổi cấu trúc cả trang thanh toán chỉ vì công cụ đề xuất. Một thay đổi nhỏ, có mục đích rõ sẽ dễ kiểm tra hơn. Nếu cần sửa rộng hơn, nhóm phải hiểu lý do và phần hành vi có thể bị ảnh hưởng.

Giữ bí mật và quyền truy cập khỏi prompt

Để giải thích lỗi, Nam tạo giỏ hàng mẫu thay vì chép đơn thật của khách. Cậu bỏ thông tin cá nhân, mã truy cập và dữ liệu không cần cho bài toán. Một ví dụ nhỏ nhưng đủ tái hiện lỗi thường hữu ích hơn cả đống nhật ký chứa những thứ người xem không cần biết.

Nếu công cụ có thể đọc hoặc sửa dự án, quyền được cấp cần phù hợp với công việc. Việc tạo một hàm tính toán không mặc nhiên cần truy cập môi trường đang phục vụ khách. Nhóm nên thống nhất công cụ được phép dùng và cách đưa dữ liệu vào trước khi mỗi người tự thử một kiểu.

Trong tài liệu về gợi ý code của GitHub Copilot, GitHub lưu ý code đúng cú pháp chưa chắc an toàn và cần được rà soát, kiểm tra. Nam xem đây là lời nhắc dành cho cả đoạn code nhìn rất gọn. Độ đẹp của bản nháp không thay thế việc hiểu nó đang làm gì.

Thông tin model là một dữ kiện, không phải kết luận

Một model mới có thể cho câu trả lời khác, nhưng tên model không quyết định đoạn code này đã đạt yêu cầu. Nam quan tâm hơn đến việc nó có dùng đúng thư viện, đúng phiên bản và đúng cách dự án tổ chức hay không. Những điều đó cần được đối chiếu với mã nguồn và tài liệu đang áp dụng.

Nếu công cụ gợi ý một hàm lạ, cậu tìm trong tài liệu chính thức trước khi thêm vào. Không thấy thì hỏi lại hoặc chọn cách đã được dự án sử dụng. Khi thử nhiều công cụ, Nam vẫn dùng cùng yêu cầu và bộ kiểm tra. Như vậy, việc so sánh có cơ sở hơn cảm giác câu trả lời nào nghe tự tin.

Xem kết quả kiểm tra trước khi nhận code

Trước khi gửi review, Nam chạy các kiểm tra phù hợp với phần đã sửa và xem kết quả thực tế. Cậu không ghi “đã test” chỉ vì công cụ nói nên chạy test. Phần mô tả thay đổi nêu lỗi ban đầu, cách xử lý và những ca đã kiểm tra, gồm cả thao tác xóa món khỏi giỏ.

Người nhận có thể đọc ghi chú bàn giao để biết phần nào đã hoàn thành và phần nào còn chờ xác nhận. Với Nam, AI giúp đi nhanh tới bản nháp. Công việc chỉ xong khi nhóm giải thích được vì sao bản sửa đúng và có bằng chứng kiểm tra phù hợp để người sau tin dùng.