Lập trình theo cảm hứng đã thay đổi đối tượng có thể tạo ra một ứng dụng trông như đang hoạt động. Một prompt có thể tạo các màn hình, kết nối API và lắp ghép một quy trình hợp lý trước khi một đội ngũ kỹ thuật truyền thống hoàn tất bản đánh giá thiết kế đầu tiên.
Tốc độ đó tạo ra một vấn đề mới trong tuyển dụng và triển khai: bản demo không còn là bằng chứng thuyết phục rằng phần mềm tốt. Các nhà tuyển dụng sẽ ngày càng đặt ra một câu hỏi khó hơn: hệ thống do AI xây dựng có hoạt động đúng khi đầu vào lộn xộn, các phần phụ thuộc bị lỗi, người dùng lặp lại thao tác và mô hình nền tảng thay đổi hay không?
Câu trả lời sẽ đến từ một chuẩn chất lượng trông ít giống sự trau chuốt về hình thức hơn mà giống việc kiểm chứng phần mềm có kỷ luật hơn. Những người nổi bật sẽ không chỉ cho thấy công cụ lập trình AI đã tạo ra gì. Họ sẽ cho thấy họ đã kiểm thử nó như thế nào, nó không thể làm gì một cách an toàn, và làm sao họ biết một thay đổi không làm hỏng thứ khác.
Điểm chuẩn là bằng chứng, không phải điểm trên bảng xếp hạng
Các điểm chuẩn cho tác nhân lập trình mã nguồn mở là những điểm khởi đầu hữu ích, nhưng chúng đo lường những năng lực khác nhau. SWE-bench sử dụng các vấn đề GitHub thực tế và ảnh chụp các kho mã, nên phù hợp với công việc bảo trì. Terminal-Bench kiểm thử tương tác với dòng lệnh. Những điểm chuẩn khác được liệt kê, bao gồm SlopCodeBench và ProgramBench, nhắm đến các khía cạnh khác nhau của mã được tạo ra và hành vi của tác nhân.
Các điểm chuẩn đó có thể giúp so sánh công cụ hoặc thiết lập đường cơ sở, nhưng nhà tuyển dụng nên thận trọng khi coi bất kỳ điểm số đơn lẻ nào là bằng chứng cho khả năng sẵn sàng đưa vào sản xuất. Một mô hình giải quyết được các vấn đề trong kho mã vẫn có thể tạo ra logic cấp quyền không an toàn. Một tác nhân hoàn thành được các tác vụ trên terminal vẫn có thể không duy trì được trạng thái trong một quy trình dài. Một ứng dụng web trau chuốt có thể vượt qua bản demo theo luồng thuận lợi nhưng xử lý sai việc thử lại hoặc các khoản thanh toán trùng lặp.
Vì vậy, một danh mục dự án hoặc bản đánh giá nội bộ đáng tin cậy nên bao gồm một tập đánh giá dành riêng cho tác vụ. Tập này có thể chứa các báo cáo lỗi tiêu biểu, hành trình người dùng thông thường, đầu vào sai định dạng, ranh giới quyền hạn, lỗi phần phụ thuộc và các lỗi hồi quy đã được sửa trước đó. Mỗi trường hợp nên có kết quả kỳ vọng rõ ràng, chứ không chỉ là một ảnh chụp màn hình trông đúng.
Bộ kiểm thử tối thiểu cho phần mềm do AI xây dựng
Đối với một ứng dụng nhỏ, có thể xây dựng một bộ kiểm tra chất lượng hữu ích mà không cần một phòng thí nghiệm nghiên cứu cầu kỳ:
- Kiểm thử chấp nhận: xác minh hành vi mà người dùng nhìn thấy trong những quy trình quan trọng nhất, bao gồm cả kết quả thành công và không thành công.
- Kiểm thử đơn vị và tích hợp: kiểm tra các quy tắc nghiệp vụ một cách riêng biệt và xác nhận rằng cơ sở dữ liệu, API, hàng đợi và việc xác thực hoạt động cùng nhau như dự kiến.
- Kiểm thử tiêu cực: gửi các đầu vào bị thiếu, sai định dạng, quá lớn, trùng lặp và không được cấp quyền. Mã do AI tạo ra thường trông mạnh nhất trên luồng được nêu trong prompt, vì vậy những luồng không được yêu cầu mới là điều đáng quan tâm.
- Kiểm thử hồi quy: biến mọi lỗi được phát hiện thành một bài kiểm thử lâu dài. Một bản demo hiển thị màu xanh sau khi sửa lỗi là chưa đủ nếu cùng lỗi đó có thể quay lại trong thay đổi tiếp theo do AI tạo ra.
- Kiểm tra bảo mật: kiểm thử kiểm soát truy cập, xử lý bí mật, biện pháp phòng chống chèn mã, lỗ hổng phần phụ thuộc và việc nội dung không đáng tin cậy có thể ảnh hưởng đến các lệnh gọi công cụ hoặc hành động đặc quyền hay không.
- Kiểm tra vận hành: xác minh thời gian chờ, thử lại, tính bất biến theo thao tác, ghi nhật ký, cảnh báo và hành vi an toàn khi một phần phụ thuộc không khả dụng.
Điều này khá gần với tư duy kỹ thuật QA được mô tả trong bài viết của Stack Overflow về vòng đời phát triển phần mềm có tác nhân. Sự thay đổi quan trọng nằm ở văn hóa: đảm bảo chất lượng không phải là một cuộc kiểm tra cuối cùng sau khi AI viết xong mã. Đó là cấu trúc giúp việc tạo mã nhanh chóng đủ an toàn để sử dụng.
Kiểm thử việc điều phối, không chỉ kiểm thử đầu ra
Khi phần mềm bao gồm một tác nhân AI, các bài kiểm thử ứng dụng thông thường là cần thiết nhưng chưa đủ. Hệ thống có thể thất bại vì mô hình hiểu sai một yêu cầu, nhưng cũng có thể thất bại vì cơ chế điều phối xung quanh làm mất ngữ cảnh, gọi một công cụ hai lần, chấp nhận đầu ra có cấu trúc sai định dạng hoặc không bao giờ kết thúc.
Các lĩnh vực hồi quy trước khi triển khai được bản tin tổng hợp khuyến nghị là một danh sách kiểm tra thực tế: mất ngữ cảnh, tính bất biến theo thao tác của công cụ, chèn prompt, đầu ra có cấu trúc, không kết thúc, grounding trong truy xuất thông tin và khôi phục trạng thái. Đây đều là những thuộc tính kỹ thuật có thể kiểm thử.
Ví dụ, một bài kiểm thử có thể chạy cùng một yêu cầu hai lần và xác nhận rằng lần thứ hai không tạo ra đơn hàng trùng lặp. Một bài khác có thể ngắt tác nhân giữa chừng trong một quy trình, khởi động lại và xác minh rằng nó tiếp tục từ một trạng thái hợp lệ thay vì lặp lại một hành động không thể đảo ngược. Một bài kiểm thử truy xuất có thể yêu cầu hệ thống chỉ trích dẫn hoặc trả về thông tin từ một tập nguồn được phê duyệt. Một bài kiểm thử đầu ra có cấu trúc có thể cung cấp một phản hồi không hợp lệ và xác nhận rằng ứng dụng từ chối phản hồi đó một cách an toàn thay vì âm thầm coi nó là dữ liệu hợp lệ.
Các hệ thống chạy dài và đa tác nhân đặc biệt cần các bản ghi lỗi rõ ràng. Các nhà nghiên cứu đang nghiên cứu việc quy kết lỗi tự động vì có thể khó xác định tác nhân nào gây ra lỗi và lỗi xảy ra ở thời điểm nào trong một chuỗi tương tác dài. Về mặt thực tiễn, các đội ngũ nên lưu giữ các lệnh gọi công cụ, đầu vào, đầu ra, phiên bản mô hình, dấu thời gian, chuyển đổi trạng thái và quyết định cuối cùng trong một dấu vết kiểm toán có cân nhắc đến quyền riêng tư. Nếu không có bằng chứng đó, một bài kiểm thử đỏ cho bạn biết rằng có lỗi xảy ra nhưng không cho biết nên bắt đầu sửa từ đâu.
Khả năng tái lập sẽ trở thành lợi thế nghề nghiệp
Mã do AI tạo ra có tính biến động. Chạy lại có thể tạo ra một cách triển khai khác; bản cập nhật mô hình có thể thay đổi hành vi; sự cố ngừng hoạt động của nhà cung cấp có thể làm thay đổi định tuyến hoặc độ trễ. Vì vậy, nhà tuyển dụng sẽ coi trọng những ứng viên có thể khiến các đánh giá được lặp lại.
Điều đó có nghĩa là cố định các ảnh chụp mô hình khi có thể, ghi lại prompt và cấu hình, kiểm soát tính ngẫu nhiên khi nền tảng cho phép, đồng thời chạy nhiều lần thử đối với những tác vụ có kết quả biến thiên. Bản tin tổng hợp đặc biệt chỉ ra rằng ảnh chụp được cố định, nhiệt độ thấp hoặc bằng không khi có thể, và các cổng CI/CD có giới hạn độ tin cậy là những biện pháp bảo vệ hữu ích.
Một báo cáo thực tế ít nhất nên phân biệt ba kết quả:
- Tỷ lệ đạt: có bao nhiêu trường hợp thành công.
- Tính nhất quán: cùng một trường hợp thành công thường xuyên đến mức nào qua các lần chạy lặp lại.
- Mức độ nghiêm trọng: liệu các lỗi chỉ mang tính hình thức, gây bất tiện, làm hỏng dữ liệu, liên quan đến bảo mật, hay có khả năng dẫn đến một hành động bên ngoài không an toàn.
Một hệ thống vượt qua 19 trên 20 phép kiểm tra định dạng có rủi ro thấp chưa chắc đã tốt hơn một hệ thống vượt qua 18 trên 20 trường hợp nhưng không bao giờ vượt qua ranh giới ủy quyền. Tiêu chuẩn chất lượng phải đánh trọng số cho các lỗi theo hậu quả của chúng.
Việc đánh giá của con người nên nhắm vào rủi ro, không phải từng dòng
Mục đích của tự động hóa tốt hơn không phải là buộc một người phải đọc lại mọi token do AI tạo ra. Mục đích là hướng sự chú ý của con người vào những quyết định mà các phép kiểm tra không thể hoàn toàn xác định.
Người đánh giá nên tập trung vào xác thực và phân quyền, việc lưu giữ dữ liệu, các hành động tài chính hoặc hợp đồng, quyền riêng tư, hoạt động di chuyển dữ liệu, khôi phục lỗi, quyền của bên thứ ba và những thay đổi ảnh hưởng đến chính bộ công cụ đánh giá hệ thống. Đối với một tác nhân, họ cũng nên xem xét tác nhân đó được phép gọi những công cụ nào, mỗi công cụ có thể truy cập dữ liệu gì và liệu có cần phê duyệt trước khi thực hiện một hành động không thể đảo ngược hay không.
Các phần khác biệt hiển thị, quy trình phê duyệt, các cuộc trò chuyện được lưu trữ và nhật ký kiểm toán—những tính năng được nhấn mạnh trong phần mô tả của Slack Code về hoạt động lập trình AI cộng tác—cho thấy một kỳ vọng rộng hơn: lịch sử phần mềm được tạo ra như thế nào sẽ trở nên quan trọng. Người đánh giá phải có khả năng hiểu yêu cầu, kiểm tra thay đổi được tạo ra, xem bằng chứng kiểm thử và xác định ai đã phê duyệt việc triển khai.
Bản ghi đó không phải là thủ tục hành chính chỉ vì lợi ích của chính nó. Nó giúp phân biệt một màn trình diễn ấn tượng với một thay đổi được kiểm soát mà người khác có thể duy trì.
Nên đưa gì vào hồ sơ năng lực hoặc buổi phỏng vấn
Đối với ứng viên, minh chứng thuyết phục nhất là một hệ thống nhỏ với câu chuyện chất lượng được thể hiện rõ ràng một cách có chủ ý. Hãy bao gồm kho mã, hướng dẫn thiết lập, ghi chú kiến trúc, các lệnh kiểm thử, những trường hợp kiểm thử tiêu biểu, các hạn chế đã biết và một báo cáo ngắn về lỗi. Hãy cho thấy một hoặc hai lỗi đã được phát hiện và chuyển thành các bài kiểm thử hồi quy. Giải thích đã sử dụng mô hình hoặc tác nhân lập trình nào, nhưng không coi công cụ đó là tác giả của các quyết định kỹ thuật.
Nếu ứng dụng sử dụng một tác nhân, hãy ghi lại các quyền của công cụ, mô hình trạng thái, chính sách thử lại, điều kiện kết thúc và các điểm cần con người phê duyệt. Nếu sử dụng cơ chế truy xuất, hãy cho thấy các nguồn được lựa chọn như thế nào và điều gì xảy ra khi thiếu bằng chứng. Nếu gọi các dịch vụ bên ngoài, hãy minh họa cách hệ thống xử lý thời gian chờ và các yêu cầu trùng lặp.
Đừng khẳng định độ tin cậy chỉ dựa trên một bản ghi thành công duy nhất. Một khẳng định có thể kiểm chứng sẽ giống như sau: “Qua 30 lần chạy được ghi lại của 12 kịch bản này, hệ thống đáp ứng các tiêu chí nghiệm thu trong 28 lần; hai lần thất bại liên quan đến dữ liệu ngày tháng không rõ ràng và cả hai đều đã được ghi chép.” Bản thân con số không quan trọng bằng phương pháp, các ranh giới và sự trung thực về những gì vẫn chưa được kiểm thử.
Định nghĩa mới về tốc độ
AI làm giảm chi phí tạo ra phiên bản đầu tiên. Nó không loại bỏ chi phí để biết liệu phiên bản đó có đáng tin hay không. Trên thực tế, việc tạo nhanh hơn có thể khiến hoạt động đánh giá trở nên quan trọng hơn, vì nhiều thay đổi chưa được xem xét có thể tích tụ giữa các lần triển khai.
Chuyên gia thời kỳ hậu lập trình theo cảm hứng sẽ được đánh giá qua vòng lặp sau: xác định hành vi, tạo hoặc sửa đổi mã, kiểm thử các trường hợp thực tế và đối nghịch, kiểm tra các quyết định có rủi ro cao, ghi lại lỗi và cải thiện hệ thống mà không làm mất bằng chứng. Các bộ đánh giá có thể giúp so sánh năng lực. Các thực hành QA quyết định liệu năng lực đó có trở thành phần mềm đáng tin cậy hay không.
Vì vậy, tiêu chuẩn chất lượng không phải là “Bạn có thể tạo một ứng dụng bằng AI không?” mà là “Bạn có thể chứng minh ứng dụng làm gì, phát hiện khi nào nó ngừng làm điều đó và thiết kế các giới hạn để ngăn một lỗi trở thành sự cố không?”
