Việc tạo mã bằng tác nhân làm thay đổi đơn vị công việc. Thay vì một người viết và kiểm duyệt một PR nhỏ, một tác nhân có thể tạo ra hàng chục phương án triển khai, dựng bộ khung cho nhiều dịch vụ và tự động di chuyển mã. Kết quả là khối lượng và mức độ đa dạng tăng lên, khiến phạm vi cần kiểm duyệt rộng hơn. Các nhóm phải chịu hai áp lực: năng suất (liên tục phát hành tính năng) và an toàn (ngăn lỗi hồi quy hoặc sự cố chuỗi cung ứng). Phần này giải thích cách tự động hóa mở rộng phạm vi cần kiểm tra, vì sao người kiểm duyệt trở thành nút thắt cổ chai và những vai trò trong tổ chức chịu ảnh hưởng nhiều nhất: kỹ sư phát hành, nhóm bảo mật và người bảo trì các thư viện trọng yếu.

Kiểm thử xác nhận hành vi mong đợi trong các tình huống đã chọn và hiệu quả nhất trong việc ngăn lỗi hồi quy tương ứng với các bộ ca kiểm thử. Phân tích tĩnh và công cụ lint phát hiện lỗi kiểu, vấn đề bộ nhớ và nhiều trường hợp sử dụng API sai trước khi chạy chương trình. Đánh giá mã bằng AI giúp sàng lọc vấn đề về khả năng đọc hiểu, lỗi logic có thể xảy ra và hồi quy phong cách ở quy mô lớn, nhưng có thể bỏ sót lỗi ngữ nghĩa tinh vi hoặc logic bị bịa ra. Ngược lại, xác minh hình thức chứng minh các thuộc tính đúng với mọi đầu vào khi được cung cấp đặc tả chính xác. Trên thực tế: dùng kiểm thử để đảm bảo phạm vi hành vi, công cụ phân tích tĩnh để phát hiện vấn đề cấu trúc, đánh giá bằng AI để sàng lọc, và chứng minh để xác nhận các bất biến cũng như bảo đảm về tính đồng thời hoặc mật mã mà kiểm thử không thể bao quát hết bằng phương pháp thống kê.

Các phương pháp hình thức rất mạnh nhưng không áp dụng được cho mọi trường hợp. Chúng đòi hỏi đặc tả chính xác — một công việc thiết kế không hề đơn giản — và thường yêu cầu mã được viết theo một tập con phù hợp cho việc chứng minh hoặc có các hợp đồng được chú thích. Những phương pháp này ít hữu ích hơn với vấn đề bố cục giao diện, tinh chỉnh hiệu năng hoặc kỳ vọng hành vi phụ thuộc vào đầu vào thực tế khó xác định. Lạm dụng chứng minh có thể tạo ra nút thắt nếu nhóm cố xác minh hình thức các cơ sở mã lớn và thay đổi nhanh. Phần này trình bày những cạm bẫy thường gặp: đặc tả không còn khớp với mã, chi phí duy trì chứng minh, khó khăn khi tích hợp với CI và nguy cơ tạo cảm giác an toàn sai lầm khi đã có chứng minh nhưng các giả định lại thiếu chính xác.

Áp dụng quy trình nhiều lớp: 1) Tạo mã dựa trên đặc tả — viết hợp đồng API, kiểu dữ liệu và kiểm thử dựa trên thuộc tính chính xác trước khi yêu cầu tác nhân triển khai; 2) Tạo mã trong môi trường cách ly — chạy tác nhân trên các trình chạy CI riêng biệt, có công cụ đo đạc và làm mờ mã để kiểm thử các mô-đun được tạo; 3) Cổng kiểm tra tự động — yêu cầu kiểm thử đơn vị, tích hợp, dựa trên thuộc tính cùng các bước kiểm tra bảo mật của GitHub AI Scan trước khi con người đánh giá; 4) Chứng minh hình thức có trọng điểm — áp dụng cho các bất biến trọng yếu (đồng thuận, mật mã, phân quyền) hoặc mô-đun có phạm vi ảnh hưởng lớn; 5) Xác minh bởi con người — tập trung vào thiết kế, mức độ tuân thủ đặc tả và tư duy đối kháng thay vì kiểm tra từng dòng về tính chính xác. Tích hợp công cụ sao cho mỗi bước không gây tắc nghẽn và dễ theo dõi trên bảng điều khiển PR.

Hãy bắt đầu từ quy mô nhỏ: thử nghiệm chứng minh trên một dịch vụ trọng yếu, thu thập số liệu để đo khoảng thời gian phát sinh lỗi và thời gian kiểm duyệt, đồng thời đào tạo kỹ sư SRE và bảo mật về cách viết đặc tả cũng như bộ khung chứng minh. Tạo các vai trò mới hoặc luân phiên nhiệm vụ — chẳng hạn kỹ sư chứng minh hoặc người phụ trách xác minh — để chuyển yêu cầu sản phẩm thành các hợp đồng có thể kiểm tra bằng máy. Về lâu dài, có thể sẽ hình thành hai hướng: phần lớn mã được xác thực bằng công cụ nhanh, mang tính xác suất và người kiểm duyệt; một phần nhỏ các mô-đun có giá trị cao sẽ được củng cố bằng chứng minh hình thức. Sự kết hợp này duy trì tốc độ phát triển, đồng thời giảm đáng kể rủi ro hệ thống tại những nơi quan trọng nhất.