Mã do trợ lý AI viết thường trông gọn gàng và rất tự tin, chính vì vậy mà dễ được duyệt qua loa. Những chỗ hay sai là trường hợp biên bị bỏ qua, bảo mật lỏng lẻo, dùng thư viện hay cách làm đã cũ, làm quá tay những việc không được yêu cầu, và âm thầm đổi hành vi ở những chỗ không liên quan. Hãy đọc nó kỹ như đọc mã của một người mới vào nghề.
Chào bạn, đây là Nhà Lập Trình. Khi mã do chính mình gõ, bạn hiểu từng dòng vì bạn đã nghĩ ra nó. Khi mã do trợ lý viết, bạn chỉ thấy kết quả, không thấy quá trình. Và mã đó sẽ mang tên bạn khi đưa lên. Tập này kể những chỗ cần soi kỹ nhất.
Vì sao mã do AI viết dễ lọt qua?
Mã do trợ lý viết có một đặc điểm: nó trông rất chuyên nghiệp. Tên biến đẹp, có chú thích, có xử lý lỗi, định dạng gọn gàng. Mã của người mới thường trông lộn xộn, nên người xem lại tự nhiên đọc kỹ hơn. Mã trông chuyên nghiệp thì người xem có xu hướng tin.
Nhưng vẻ ngoài và sự đúng đắn là hai chuyện khác nhau. Trợ lý có thể viết một đoạn mã hoàn toàn trôi chảy mà sai logic ở một điều kiện nhỏ, hoặc gọi một hàm theo cách không đúng với phiên bản thư viện bạn đang dùng.
Thêm nữa, trợ lý viết rất nhanh và rất nhiều. Một lần có thể ra vài trăm dòng. Đọc kỹ vài trăm dòng mệt hơn nhiều so với viết mười dòng. Người ta có xu hướng đọc lướt, chạy thử thấy được, rồi cho qua.
Nguyên tắc đơn giản: mã do trợ lý viết, bạn chịu trách nhiệm như thể chính bạn viết. Nếu không đủ thời gian đọc kỹ, hãy yêu cầu nó viết ít hơn.
Trường hợp biên và giả định ngầm
Chỗ sai phổ biến nhất là trường hợp biên. Trợ lý thường viết tốt cho trường hợp bình thường, còn danh sách rỗng, dữ liệu thiếu, giá trị bằng không, ký tự tiếng Việt có dấu, múi giờ, thì hay bị bỏ qua hoặc xử lý qua loa.
Trợ lý cũng hay đặt giả định ngầm về dữ liệu. Nó giả định mọi khách hàng đều có số điện thoại, mọi ngày đều cùng một định dạng, mọi số tiền đều dương. Những giả định này không được nói ra, chỉ nằm ẩn trong mã.
Khi đọc lại, hãy đi qua danh sách câu hỏi biên: rỗng thì sao, thiếu thì sao, rất lớn thì sao, hai người cùng lúc thì sao, mạng đứt giữa chừng thì sao. Với mỗi câu, tìm trong mã xem có xử lý không.
Một mẹo hiệu quả: hỏi chính trợ lý liệt kê những giả định nó đã đặt ra và những trường hợp mã chưa xử lý. Rồi tự kiểm tra danh sách đó, và tự nghĩ thêm những trường hợp nó bỏ sót.
Bảo mật và cách làm cũ
Chỗ thứ hai cần soi là bảo mật. Trợ lý học từ rất nhiều mã trên mạng, trong đó có không ít mã viết ẩu. Nó có thể ghép chuỗi để tạo truy vấn thay vì dùng tham số, tắt kiểm tra chứng chỉ cho nhanh, đặt khoá bí mật thẳng vào mã làm ví dụ, hoặc bỏ qua kiểm tra quyền.
Những lỗi này không làm mã chạy sai khi thử, nên không lộ ra. Chỉ người đọc có ý thức bảo mật mới nhìn thấy.
Chỗ thứ ba là cách làm cũ. Trợ lý có thể dùng một hàm đã bị đánh dấu ngừng hỗ trợ, một thư viện đã bỏ hoang, một cách viết của phiên bản ngôn ngữ nhiều năm trước. Mã vẫn chạy, nhưng sẽ gây rắc rối khi nâng cấp.
Khi thấy trợ lý dùng một thư viện hay một hàm bạn chưa biết, hãy mở tài liệu chính thức ra kiểm tra. Đừng tin rằng nó tồn tại và hoạt động đúng như trợ lý nói. Mình có một tập riêng về chuyện trợ lý bịa ra thứ không tồn tại.
Làm quá tay và sửa lan ra ngoài
Một kiểu sai ít người để ý: trợ lý làm nhiều hơn được yêu cầu. Bạn nhờ sửa một lỗi trong hàm tính tiền, nó sửa lỗi đó, và tiện tay đổi tên vài biến, sắp xếp lại vài dòng, thêm một lớp xử lý lỗi, đổi cách định dạng số ở một hàm bên cạnh.
Mỗi thay đổi thêm có thể có lý do, nhưng chúng làm cho thay đổi của bạn khó xem lại, và có khi âm thầm đổi hành vi ở chỗ không ai yêu cầu. Cách định dạng số thay đổi, và báo cáo in ra khác đi mà không ai biết vì sao.
Khi xem lại, hãy so sánh trước và sau từng dòng, không chỉ đọc bản mới. Mọi dòng thay đổi phải có lý do liên quan tới yêu cầu. Dòng nào không liên quan, hãy bỏ, hoặc tách thành một thay đổi riêng nếu thấy thật sự có ích.
Nói rõ phạm vi khi giao việc cũng giúp: chỉ sửa lỗi này, không thay đổi gì khác. Nhiều trợ lý tôn trọng giới hạn này khá tốt khi được nói rõ.
Một quy trình đọc lại gọn
Mình gợi ý một quy trình ngắn. Một, đọc hiểu toàn bộ, dòng nào không hiểu thì hỏi hoặc tra cho tới khi hiểu. Không hiểu thì không đưa lên. Hai, so trước và sau, bỏ những thay đổi ngoài phạm vi.
Ba, đi qua danh sách trường hợp biên. Bốn, đi qua danh sách bảo mật: dữ liệu từ ngoài có được kiểm tra không, truy vấn có dùng tham số không, có bí mật nào trong mã không, có kiểm tra quyền không.
Năm, kiểm tra mọi thư viện và hàm lạ với tài liệu chính thức. Sáu, chạy thử với dữ liệu thật đã làm sạch, bao gồm những trường hợp khó. Và nếu được, viết thêm bài thử nghiệm cho những trường hợp đó.
Nghe thì dài, nhưng làm quen rồi sẽ nhanh. Và nó vẫn nhanh hơn nhiều so với tự viết từ đầu. Trợ lý giúp bạn tiết kiệm thời gian gõ, không giúp bạn tiết kiệm thời gian nghĩ.
Câu hỏi thường gặp
Mã do trợ lý AI viết có đáng tin không?
Thường chạy được với trường hợp bình thường, nhưng có thể sai ở trường hợp biên, bảo mật hoặc dùng cách làm cũ. Nên đọc lại kỹ như mã của một người mới trước khi dùng.
Ai chịu trách nhiệm khi mã do trợ lý AI viết gây lỗi?
Người đưa mã vào dự án chịu trách nhiệm như thể tự viết. Vì vậy cần hiểu từng dòng và kiểm tra kỹ trước khi đưa lên.
Làm sao phát hiện lỗi bảo mật trong mã AI viết?
Kiểm tra dữ liệu từ ngoài có được xác thực không, truy vấn có dùng tham số không, có bí mật nào trong mã không, có kiểm tra quyền và có tắt kiểm tra an toàn nào không.
Vì sao trợ lý AI hay sửa cả những chỗ không được yêu cầu?
Vì nó cố tỏ ra hữu ích và cải thiện những gì nó thấy. Nói rõ phạm vi khi giao việc và so sánh trước sau từng dòng khi xem lại để bỏ những thay đổi ngoài phạm vi.
Có nên nhờ trợ lý AI tự kiểm tra mã của nó không?
Có thể nhờ nó liệt kê giả định và trường hợp chưa xử lý, rất có ích. Nhưng đó không thay thế được việc chính bạn đọc lại và chạy thử.
