Đào tạo đánh giá mã do AI tạo ra: làm thế nào để dạy các nhà phát triển cách kiểm tra những gì mô hình đã viết

Một lập trình viên yêu cầu trợ lý viết một hàm kiểm tra xem người dùng có được phép tải xuống báo cáo hay không. Mã biên dịch thành công. Bài kiểm tra trường hợp lý tưởng cũng đạt. Yêu cầu kéo (pull request) trông gọn gàng. Hai tuần sau, một đồng nghiệp nhận thấy rằng hàm này kiểm tra xem người dùng đã đăng nhập hay chưa, nhưng lại không bao giờ kiểm tra xem báo cáo đó có thuộc về người dùng đó hay không.

Đây là một tình huống minh họa, không phải là một sự cố đã được ghi nhận. Nó mô tả khoảng trống mà việc đào tạo rà soát mã do AI tạo ra cần phải lấp đầy: mã được tạo ra vượt qua kiểm tra cơ bản vẫn có thể chứa lỗi về quyền truy cập hoặc lỗi đồng thời, và người rà soát cần phải tìm ra lỗi đó và giải thích tại sao nó lại quan trọng.

Hướng dẫn này dành cho các trưởng nhóm hỗ trợ kỹ thuật và các quản lý kỹ thuật. Nó bao gồm cách mô tả vấn đề hiệu suất, chẩn đoán các thiếu sót, chuẩn bị và thực hành thiết kế, giải quyết một trường hợp cụ thể và đánh giá xem kỹ năng có thể áp dụng vào các đánh giá thực tế hay không. Nó cũng đề cập đến thiết kế đào tạo. Mọi lỗi, quy tắc kiểm thử và đánh giá trong chương trình của bạn đều cần được các kỹ sư cấp cao và nhóm bảo mật xác nhận.

Đào tạo đánh giá mã nguồn do AI tạo ra là gì?

Việc đào tạo đánh giá mã do AI tạo ra dạy các nhà phát triển cách đưa ra yêu cầu rõ ràng cho trợ lý, sau đó đánh giá và kiểm tra phản hồi: mã có chính xác không, có an toàn không, có hoạt động tốt dưới tải đồng thời không, có đủ hiệu quả không? Đây không phải là khóa học về một công cụ cụ thể nào. Nó đào tạo một thói quen đánh giá mã sẽ không thay đổi ngay cả khi công cụ thay đổi.

sự kiện nhanh chóng

1. Mô tả vấn đề về hiệu năng

Hãy bắt đầu với nhiệm vụ: kiểm tra mã nguồn được tạo ra và chứng minh rủi ro bằng các bài kiểm thử. Kiểm tra là đọc với thái độ nghi ngờ. Chứng minh là biến sự nghi ngờ thành bằng chứng, thường là một bài kiểm thử thất bại hoặc một bản sao cho thấy lỗi.

Nghiên cứu cho thấy lý do tại sao điều này cần được thực hành một cách có chủ đích. Trong một nghiên cứu về GitHub Copilot, Pearce và các đồng nghiệp đã tạo ra 1,689 chương trình trên 89 kịch bản được lựa chọn dựa trên các loại điểm yếu đã biết và phát hiện ra rằng khoảng 40% trong số đó dễ bị tổn thương (Pearce và các đồng nghiệp, 2021Đó là một công cụ ban đầu và một tập hợp các kịch bản cụ thể, vì vậy đừng coi con số đó là tỷ lệ dành cho các trợ lý hiện nay. Một nghiên cứu người dùng riêng biệt đã yêu cầu người tham gia viết mã có và không có trợ lý AI. Những người sử dụng trợ lý đã viết mã kém an toàn hơn đáng kể và có nhiều khả năng tin rằng mã của họ an toàn hơn.Perry và các đồng nghiệp, 2023Nghiên cứu tương tự cũng cho thấy những người tham gia ít tin tưởng trợ lý hơn và tương tác nhiều hơn với các lời nhắc của trợ lý sẽ ít gặp phải các vấn đề hơn.

Từ đó suy ra hai bài học về thiết kế chương trình đào tạo. Kết quả khả thi cần có người đánh giá tích cực. Và sự tự tin không phải là bằng chứng, vì vậy bài tập phải yêu cầu kiểm chứng, chứ không phải ý kiến ​​cá nhân.

Hãy viết bản mô tả hiệu năng chỉ trong một câu và nhờ quản lý kỹ thuật kiểm tra: "Với một thay đổi được tạo ra, nhà phát triển liệt kê các rủi ro về bảo mật, đồng thời và hiệu quả mà họ nhận thấy, và mô tả hoặc viết một bài kiểm thử để chứng minh điều đó đối với mỗi rủi ro."

2. Chẩn đoán những thiếu sót về kiến ​​thức và bối cảnh.

Trước khi bắt tay vào xây dựng bất cứ điều gì, hãy so sánh nhiệm vụ đó với những gì chương trình đào tạo hiện tại của bạn đang thực hành và đánh giá. Thông thường, ba câu hỏi sau sẽ giúp phân biệt lỗ hổng đào tạo với những vấn đề khác:

1. Liệu phương pháp hiện tại có sử dụng đúng nhiệm vụ thực tế? Nếu khóa đào tạo chỉ đề cập đến việc viết báo cáo đúng hạn mà không yêu cầu lập trình viên xem xét lại kết quả, thì không ai thực hành việc kiểm toán. Nếu bài đánh giá là bài kiểm tra trắc nghiệm về các quy tắc lập trình an toàn, thì nó chỉ đo lường khả năng ghi nhớ.
2. Yêu cầu về khả năng nhận thức là gì? Trong thang phân loại Bloom sửa đổi, việc đánh giá xem mã có an toàn hay không và lựa chọn bài kiểm tra chứng minh điều đó nằm ở cấp độ phân tích và đánh giá, trong khi việc thiết kế một lời nhắc tốt hơn hoặc một bản sửa lỗi đạt đến cấp độ sáng tạo. Việc ghép các hoạt động với các cấp độ đó được đề cập trong hướng dẫn của chúng tôi về Phù hợp các hoạt động học tập với Phân loại Bloom..
3. Liệu có điều gì khác ngoài kỹ năng đang cản trở bạn? Kiểm tra thời gian xem xét, công cụ và trách nhiệm. Nếu người đánh giá chỉ có năm phút cho mỗi yêu cầu kéo (pull request), thì việc đào tạo sẽ không tạo ra được một cuộc kiểm toán. Nếu không có phân tích tĩnh hoặc bộ công cụ kiểm thử trong quy trình, nhà phát triển có thể phát hiện ra rủi ro nhưng không thể chứng minh được nó. Báo cáo các nguyên nhân không liên quan đến đào tạo cho những người có thể khắc phục chúng.

3. Chuẩn bị và thực hành thiết kế

Khi bạn đã xác định được những thiếu sót nào mà đào tạo có thể khắc phục, hãy giao nhiệm vụ riêng biệt cho từng giai đoạn.

Sự chuẩn bị. Kiểm tra các điều kiện tiên quyết bằng một bài kiểm tra chẩn đoán ngắn: các loại điểm yếu phổ biến mà hệ thống của bạn gặp phải, cấu trúc các bài kiểm tra, danh sách kiểm tra đánh giá mà nhóm của bạn sử dụng. Tự học theo tốc độ riêng phù hợp với giai đoạn này. Bài kiểm tra ôn tập chỉ xác nhận các điều kiện tiên quyết.

Thực hành. Sử dụng các bài tập kiểm toán được xây dựng từ mã nguồn thực tế. Mỗi bài tập cần có một số lỗi nhỏ với nhiều loại khác nhau, chẳng hạn như thiếu kiểm tra quyền sở hữu, xung đột giữa hai yêu cầu và vòng lặp không hiệu quả, cùng với một số đoạn mã hoạt động tốt. Lập trình viên sẽ xem xét, nêu tên từng rủi ro, đánh giá mức độ nghiêm trọng và đề xuất bài kiểm thử để phát hiện ra lỗi đó. Hãy yêu cầu lý do, chứ không phải chỉ là danh sách số dòng mã.

Phản hồi. Hãy liên kết nó với các quyết định thay vì tổng điểm. Câu "Bạn đã phát hiện vòng lặp nhưng không phát hiện xung đột trên bộ đếm chung, và bài kiểm tra của bạn sẽ không phát hiện ra điều đó vì nó chạy các yêu cầu từng cái một" sẽ hữu ích hơn câu "Đã tìm thấy 2 trong số 3".

Nhập liệu trực tiếp hay xem xét không đồng bộ? Phản hồi trực tiếp mang lại giá trị cao nhất khi rủi ro không rõ ràng và các nhà phát triển học hỏi được nhiều điều từ việc nghe một kỹ sư cấp cao giải thích lý do tại sao họ lại chặn việc hợp nhất. Đánh giá không đồng bộ là đủ để so sánh những phát hiện của nhà phát triển với đánh giá có chú thích của chuyên gia. Nhiều nhóm sử dụng cả hai: chuẩn bị theo tốc độ cá nhân trước, sau đó là một buổi thảo luận có người hướng dẫn về các trường hợp khó.

4. Hãy cùng nhau tìm hiểu một ví dụ thực tế.

Ví dụ minh họa. Người quản lý kỹ thuật nên xác nhận trường hợp và tiêu chí trả lời trước khi sử dụng.

Trường hợp. Một endpoint được tạo ra sẽ trả về hóa đơn của khách hàng dựa trên ID hóa đơn. Nó kiểm tra xem người gọi có phiên làm việc hợp lệ hay không, sử dụng truy vấn tham số hóa và vượt qua bài kiểm tra cơ bản. Chức năng tương tự cũng tăng bộ đếm lượt tải xuống dùng chung mà không cần khóa.

Nhiệm vụ. Nhà phát triển nêu rõ từng rủi ro mà họ nhận thấy, xếp hạng chúng và mô tả bài kiểm tra có thể chứng minh cho từng rủi ro đó.

Lần thử đầu tiên. "Trông ổn. Truy vấn được tham số hóa và bài kiểm tra đạt." Nhà phát triển đã coi việc bài kiểm tra đạt là bằng chứng xác nhận và không đặt câu hỏi về những gì bài kiểm tra chưa bao gồm.

Phản hồi và thử lại. Người đánh giá yêu cầu nhà phát triển nêu rõ việc kiểm tra phiên chứng minh được điều gì và không chứng minh được điều gì. Yêu cầu thử lại đòi hỏi họ phải xem xét hai khách hàng khác nhau và hai yêu cầu đồng thời.

Một nỗ lực mạnh mẽ hơn. "Việc kiểm tra phiên chứng minh ai đang gọi, chứ không phải hóa đơn đó là của họ. Tôi sẽ viết một bài kiểm tra trong đó khách hàng A yêu cầu mã số hóa đơn của khách hàng B và mong đợi bị từ chối. Bộ đếm được tăng lên mà không cần đồng bộ hóa, vì vậy hai yêu cầu cùng lúc có thể làm mất bản cập nhật. Tôi sẽ chạy một bài kiểm tra đồng thời và so sánh số lượng. Bản thân truy vấn đã được tham số hóa, vì vậy tôi sẽ không dành thời gian cho việc đó." Lưu ý rằng câu trả lời này xếp hạng các rủi ro và gắn mỗi rủi ro với một bài kiểm tra.

Tại sao mỗi câu trả lời lại có thể chấp nhận được hoặc chưa đầy đủ. Hãy đánh giá từng trường hợp dựa trên các tiêu chí đã được phê duyệt, chứ không phải dựa trên sở thích cá nhân của người đánh giá. Lần thử đầu tiên thường theo thói quen nhưng lại bỏ qua bằng chứng. Lần thử tốt hơn sẽ cụ thể, ưu tiên và có thể kiểm chứng được.

5. Đánh giá năng lực và lập kế hoạch chuyển giao

Bằng chứng về năng lực là việc thể hiện khả năng thực hiện một bài tập mới mà người học chưa từng làm trước đó. Chấm điểm chất lượng và xác minh các lỗi liên quan. Một bảng tiêu chí đơn giản sử dụng thang điểm từ 0 đến 2 cho mỗi tiêu chí:

Thang điểm: 0 là không có hoặc không được hỗ trợ, 1 là một phần với những thiếu sót liên quan, và 2 là đầy đủ và được chứng minh dựa trên các tiêu chí đã thống nhất. Xác định riêng các lỗi nghiêm trọng, chẳng hạn như phê duyệt mã có đường dẫn truy cập không được bảo vệ, để điểm tổng thể không che giấu được lỗi đó. Bảng đánh giá này chỉ là đề xuất, không phải là tiêu chuẩn sẵn sàng đã được xác nhận: hãy điều chỉnh nó với người quản lý kỹ thuật và thử nghiệm thí điểm. Hướng dẫn của chúng tôi về... Thiết kế bài tập tương tác với phản hồi hữu ích Hướng dẫn cách viết phản hồi liên quan đến các quyết định.

Lên kế hoạch chuyển giao một cách cẩn thận. Sau bài tập, hãy ghép mỗi lập trình viên với một yêu cầu kéo (pull request) thực tế bao gồm mã được tạo tự động và cùng nhau xem xét kết quả, hoặc tiến hành một buổi đánh giá ngắn về một lần xem xét gần đây mà bỏ sót điều gì đó.

Trong trường hợp phương thức giao hàng tương tác giúp ích

Các định dạng tương tác rất hữu ích khi mọi người cần cam kết trước khi tham gia buổi thảo luận nhóm. Trong một buổi học trực tiếp, người điều phối có thể hiển thị một đoạn mã được tạo sẵn, yêu cầu mỗi lập trình viên nhập các rủi ro mà họ nhận thấy và bài kiểm tra mà họ sẽ viết, sau đó tiết lộ kết quả trước khi thảo luận. Bài tập tương tự cũng có thể được thực hiện theo hình thức tự học để chuẩn bị. AhaSlides hỗ trợ học tập tương tác và chuyển đổi giữa hình thức trực tiếp và tự học. Đây là một công cụ trình bày và học tập, không phải là nơi để chạy mã, vì vậy hãy chạy các bài tập mã trong môi trường của riêng bạn. Kiểm tra bất kỳ chức năng soạn thảo, phản hồi hoặc báo cáo cụ thể nào mà bạn dự định sử dụng so với quy trình làm việc của riêng bạn. Để được hướng dẫn về việc lựa chọn định dạng, hãy xem bài viết của chúng tôi về... Khi nào nên sử dụng phương pháp học tập thích ứng, tương tác và trực tiếp?.

Đo lường những gì đã thay đổi

Hãy quyết định trước những tiêu chí nào sẽ chứng minh các nhà phát triển có thể hoàn thành nhiệm vụ. So sánh chất lượng xác minh và việc phát hiện lỗi trong một bài tập chưa từng có tiền lệ với một tiêu chuẩn cơ bản. Xác định những người tham gia, mẫu số và thời gian. Nếu kết quả được cải thiện, hãy kiểm tra xem những thay đổi khác trong cùng kỳ là gì, chẳng hạn như quy tắc phân tích tĩnh mới, danh sách kiểm tra đánh giá được sửa đổi hoặc thay đổi người trợ lý, trước khi ghi nhận hiệu quả của khóa đào tạo.

Những ràng buộc có thể vẫn còn

• Đến giờ ôn tập rồi. Kiểm toán mất nhiều thời gian hơn so với việc chỉ xem qua, và thời hạn chót thường đẩy quá trình xem qua lại nhiều hơn.
• Dụng cụ. Nếu không có bộ công cụ kiểm tra hoặc quy trình quét trong quá trình vận hành, rất khó để xác định rủi ro.
• Thay đổi công cụ. Các trợ lý ảo thay đổi nhanh chóng, vì vậy hãy tập trung vào thói quen đánh giá, chứ không phải chỉ một sản phẩm cụ thể.
• Phạm vi bao phủ vụ việc. Một bài tập minh họa một vài loại lỗi. Điểm số không phản ánh chính xác khả năng đánh giá của lập trình viên nói chung.
• Chuyển khoản. Hiệu suất trong một buổi hội thảo không giống với hiệu suất khi phải xử lý công việc trong một hàng chờ đánh giá bận rộn.

Hãy nêu rõ những vấn đề này với nhà tài trợ từ sớm và lên kế hoạch khắc phục riêng biệt. Việc đào tạo giúp nhà phát triển cải thiện khả năng tìm ra và chứng minh lỗi. Nó không tạo ra thời gian hay công cụ cần thiết.

Các câu hỏi thường gặp

Đào tạo đánh giá mã nguồn do AI tạo ra là gì?

Nó dạy các nhà phát triển cách tạo yêu cầu, đánh giá và kiểm tra mã do trợ lý AI tạo ra, tìm ra các vấn đề về bảo mật, đồng thời và hiệu quả, đồng thời hỗ trợ mỗi vấn đề bằng một bài kiểm tra.

Mã được tạo tự động có kém an toàn hơn mã do con người viết không?

Các nghiên cứu chỉ ra rủi ro, nhưng kết quả phụ thuộc vào công cụ, nhiệm vụ và thiết kế nghiên cứu. Một nghiên cứu người dùng cho thấy những người tham gia có trợ lý đã viết mã kém an toàn hơn nhưng lại cảm thấy tự tin hơn về điều đó, đây là lý do cần rèn luyện thói quen xem xét lại mã.

Làm thế nào để đánh giá xem các nhà phát triển có thể kiểm tra mã nguồn được tạo ra hay không?

Đưa ra bài tập viết mã mới và chấm điểm chất lượng kiểm chứng cũng như việc phát hiện lỗi dựa trên các tiêu chí đã thống nhất. Bài kiểm tra về các quy tắc lập trình an toàn chỉ nhằm xác nhận các điều kiện tiên quyết.

Bạn có cần môi trường thử nghiệm mã nguồn (code sandbox) cho khóa đào tạo không?

Bạn cần một nơi để thực hiện các bài tập, thường là môi trường của chính bạn. Hãy kiểm tra xem bất kỳ công cụ nào bạn sử dụng có hỗ trợ những gì bạn cần trước khi bạn phụ thuộc vào nó.

Bắt đầu từ đâu

Hãy chọn một loại thay đổi được tạo ra thường xuyên trong mã nguồn của bạn. Viết báo cáo hiệu năng, nhờ quản lý kỹ thuật xác nhận các lỗi đã được cài đặt và các bài kiểm tra có thể phát hiện ra chúng, đồng thời soạn thảo một bảng đánh giá ba tiêu chí với thang điểm từ 0 đến 2 và danh sách các lỗi nghiêm trọng. Thử nghiệm với một nhóm nhỏ trước khi triển khai rộng rãi.

Để xem cách thức thực hiện một bài tập kiểm toán trực tiếp với nhóm của bạn và có thể tái sử dụng theo tốc độ riêng sau đó, hãy khám phá AhaSlides.