Cách các bản dựng tự kiểm chứng chính mình

0:00 — một bản dựng hoàn tất. Tác nhân AI nói rằng nó đã xong, đó là một tuyên bố về việc viết code, không phải về việc code có hoạt động hay không. Mọi người dùng công cụ dựng AI đều từng cảm nhận khoảng cách giữa hai tuyên bố đó ít nhất một lần: mở bản xem trước, bấm vào nút thứ ba, không có gì xảy ra. Tôi đã từng thấy cả một phòng demo im lặng đúng vào khoảnh khắc đó. Vì vậy, trước khi bất kỳ con người nào nhìn thấy một bản dựng, nó phải trải qua khoảng sáu phút một chuỗi tác nhân tự tranh luận với chính mình. Đây là những gì thực sự diễn ra, được theo dõi qua một bản dựng mà chúng tôi chứng kiến trục trặc rồi được sửa.

0:02 — rà soát code bắt đầu. Không phải tác nhân đã viết code đọc lại bài tập của chính mình — mà là một tác nhân khác, prompt khác, không có lợi ích gì trong việc bản dựng có được thông qua hay không. Sự tách biệt đó quan trọng hơn vẻ ngoài của nó. Một tác nhân đã quyết định vào lúc 2:14 chiều rằng một lệnh gọi fetch không có xử lý lỗi là ổn thì vào 2:15 chiều vẫn sẽ nghĩ vậy nếu bạn yêu cầu nó kiểm tra chính công việc của mình. Một người rà soát mới, được yêu cầu "tìm ra chỗ hỏng, trích dẫn file," hành xử như một kỹ sư senior khó tính mà bạn thực sự muốn cho nhiệm vụ này. Trong một bản dựng trước đây, nó đã bắt được lỗi tổng giỏ hàng lặng lẽ không bao giờ cập nhật — `updateTotal` được định nghĩa trong `Cart.jsx` nhưng chưa bao giờ được nối với trình xử lý thay đổi số lượng, nên hàm này tồn tại và đơn giản là chưa bao giờ chạy. Đó là loại lỗi mà rà soát code sinh ra để bắt.

0:04 — kiểm toán bảo mật. Hẹp hơn so với tên gọi, một cách có chủ đích — đây không phải là kiểm thử xâm nhập, mà là truy tìm mẫu cho một số ít lỗi thực sự thường xuất hiện trong code do AI sinh ra. SQL nối chuỗi. Xác thực chỉ ở phía client mà lại được tin tưởng như thể đó là toàn bộ câu chuyện. Và món đặc sản: một API key gắn cứng, vì tác nhân viết tính năng đó không có sẵn quy ước biến môi trường trước mắt nên đã dùng luôn cách nào hoạt động được. Chúng tôi thấy lỗi này đủ thường xuyên đến mức nó gần như không còn gây bất ngờ nữa.

0:07 — liên kết và SEO. Không hào nhoáng, nhưng nó bắt được những thứ không ai để ý cho đến khi khách hàng nhận ra: một liên kết điều hướng trỏ tới /pricing trong khi trang thực sự được tạo tại /price, một mục sitemap cho một trang bị lỗi 404, một mô tả meta vẫn còn giữ nguyên văn bản giữ chỗ của mẫu. Không điều nào trong số đó làm hỏng bản build. Nhưng tất cả đều âm thầm phá hỏng điều mà hầu hết người dùng của chúng tôi xây dựng trang web để đạt được — được tìm thấy, được nhấp vào.

0:09 — khả năng tiếp cận. Đây là một lượt kiểm tra tự động bằng axe-core, không phải một cuộc kiểm toán thủ công đầy đủ, và cần thành thật về cái mà sự đánh đổi đó mang lại. axe-core bắt được tỷ lệ tương phản, thiếu văn bản thay thế cho ảnh, ô nhập liệu không có nhãn, bẫy thứ tự tab — lớp kiểm tra máy móc, chiếm khoảng 30-40% những gì một đánh giá WCAG đầy đủ sẽ phát hiện. Nó sẽ không bắt được trải nghiệm trình đọc màn hình tuy tuân thủ về mặt kỹ thuật nhưng thực sự gây khó hiểu khi sử dụng. Chúng tôi chọn chỉ tự động vì nó chạy trong vài giây và phần lớn những gì được triển khai qua đây là các trang marketing và công cụ nhỏ, không phải loại ứng dụng mà một cuộc kiểm toán thiếu sót có thể gây rủi ro thực sự cho ai đó.

0:11 — tính tuân thủ. Lớp này không hỏi "cái này có tốt không," mà hỏi "cái này có khớp với những gì đã hứa không." Kế hoạch nói bốn trang, bản dựng chỉ giao ba — tính tuân thủ là thứ nhận ra điều đó. Kế hoạch hứa một form liên hệ hoạt động, những gì được giao là một form không có hành động submit — cùng một lớp, cùng một cú bắt lỗi. Đây là lớp kiểm tra trực tiếp nhất chịu trách nhiệm với người dùng, vì nó đo lường dựa trên ý định đã nêu của người dùng, không phải một khái niệm chất lượng trừu tượng nào đó.

0:13 — kiểm tra trực tiếp trong trình duyệt, và đây là nơi bản dựng của chúng tôi thực sự bị hỏng. Lớp này khó giả mạo nhất vì nó không đọc code, mà điều khiển một trình duyệt thật — nhấp chuột, gõ chữ, chờ đợi, kiểm tra xem DOM có thay đổi đúng như mong đợi không. Bản dựng đang nói đến là một game idle, và game được kiểm tra kỹ hơn ở lớp này vì một game có thể hiển thị hoàn hảo từng pixel mà vẫn không chơi được — màn hình điểm số có thể trông hoàn hảo trong khi hoàn toàn tách rời khỏi logic tính điểm. Trình kiểm tra đã chơi thử. Điểm cập nhật bình thường. Âm thanh thì không phát ra tiếng nào.

Ba vòng, rồi leo thang

Phát hiện này không đến với chúng tôi dưới dạng báo cáo lỗi — nó được chuyển thẳng vào lượt sửa, và chuỗi tác nhân kiểm tra lại, tối đa ba vòng bên trong bản dựng. Vòng một: bản sửa đụng vào phần khởi tạo bộ trộn âm thanh, vốn đã ổn, nên âm thanh vẫn im lặng. Vòng hai: một bản sửa khác nhắm vào một trường hợp trạng thái tải trông có vẻ liên quan — và, điều này xảy ra thường xuyên hơn bạn tưởng — tạo ra một vấn đề mới nhỏ trong khi không giải quyết được vấn đề gốc. Vòng ba: vẫn im lặng, và đến lúc này bạn thường đang đối mặt với hoặc một vấn đề thực sự khó, hoặc một báo động giả, và đây là loại khó.

Vì vậy nền tảng tự leo thang. Nó xếp hàng một lượt sửa tiếp theo, được giới hạn hoàn toàn trong phát hiện còn tồn tại, làm việc trên một bản sao của bản dựng thay vì bản dựng gốc — nghĩa là lượt leo thang này có thể thất bại mà không khiến chúng tôi mất phiên bản đang hoạt động đã có sẵn. Lượt chạy đó tìm ra nguyên nhân thực sự: một cờ tắt tiếng được đặt trong một lượt gỡ lỗi trước đó mà chưa bao giờ được bật lại, nằm trong một file hoàn toàn khác với hai bản sửa trước đó đã đụng đến. Xóa cờ, kiểm tra lại, đạt. Không ai nhìn vào bản dựng này cho đến khi nó đã hoạt động.

Điều tôi sẽ bỏ qua lần sau

Vài tháng trước khi game idle đó chạy, chúng tôi đã thử một phiên bản mềm hơn của toàn bộ hệ thống — trình kiểm tra được phép nêu bất kỳ mối lo ngại nào, diễn đạt theo bất kỳ cách nào. Nó tạo ra các phát hiện như "cân nhắc tách phần này thành một hàm hỗ trợ" và "tên biến này có thể rõ ràng hơn," đọc lên nghe có vẻ cẩn trọng nhưng không sửa được gì. Các lượt sửa tốn cả vòng chỉ để đánh bóng câu chữ thay vì sửa những gì thực sự hỏng. Chúng tôi siết chặt quy tắc thành: nêu tên một file, mô tả một lỗi thất bại, hoặc không nói gì cả. Số lượng phát hiện từ trình kiểm tra giảm khoảng một nửa và gần như mọi thứ còn lại đều có thể hành động được. Nếu phải xây lại từ đầu, tôi sẽ bỏ qua hoàn toàn phiên bản mềm và đi thẳng vào quy tắc bằng chứng — chúng tôi không cần phải học bài học đó theo cách tốn kém, nhưng chúng tôi đã làm vậy.

Quy tắc này có một cái giá thực sự, và tôi sẽ không giả vờ là không có: một mối lo ngại mơ hồ-nhưng-đúng như "thiết kế API này sẽ gây rắc rối cho ai đó trong sáu tháng tới" giờ đây bị bỏ qua, vì trình kiểm tra không thể gắn nó với một lỗi thất bại cụ thể. Chúng tôi đã chấp nhận đánh đổi đó. Một chuỗi tác nhân cũng làm cả rà soát kiến trúc sẽ không đủ nhanh để chạy trên mọi bản dựng, và tốc độ chính là toàn bộ mục đích của việc chạy tự động thay vì nhờ con người làm việc này.

Tôi cũng sẽ bỏ qua việc thêm vòng thứ tư, nếu có ai hỏi. Chúng tôi đã điều chỉnh số vòng dựa trên các bản dựng thực tế, và giá trị gia tăng sau vòng ba giảm mạnh — vòng một giải quyết hầu hết các phát hiện có thể sửa được, vòng hai chủ yếu dọn dẹp các vấn đề do vòng một gây ra, và đến vòng ba những gì còn lại hoặc là thực sự khó, hoặc chưa bao giờ thực sự hỏng. Vòng thứ tư chủ yếu chỉ mua thêm thời gian chờ dài hơn cho cùng một kết quả.

Không có gì trong số này là miễn phí, và cũng không có gì là hoàn hảo tuyệt đối. Sáu lớp cộng thêm bất kể bao nhiêu vòng sửa lỗi cần thiết đều làm tăng thời gian thực tế cho mỗi lần build — sự khác biệt giữa hoàn tất trong chưa đầy một phút và hoàn tất sau vài phút. Chúng tôi tin đây là sự đánh đổi đúng đắn cho bất cứ thứ gì bạn sắp đưa ra trước khách hàng của chính mình, nhưng "nhanh" và "đã xác minh" kéo theo hai hướng ngược nhau, và chúng tôi chọn xác minh. Các trình xác minh cũng là LLM, nên đôi khi chúng gắn cờ cho thứ thực ra không hỏng, hoặc bỏ sót thứ thực sự có lỗi. Quy tắc bằng chứng và vòng lặp nhiều vòng là biện pháp phòng ngừa cho điều đó, không phải sự đảm bảo tuyệt đối.

Những gì bạn nhận được cuối cùng là một bản ghi: lớp nào đã chạy, phát hiện được gì, đã sửa những gì, và những gì còn lại cần bạn tự đánh giá. Bản ghi đó gần với sản phẩm thực hơn cả chính đoạn code — đó là sự khác biệt giữa tin tưởng một bản build vì nó trông có vẻ hoàn thiện và tin tưởng nó vì có điều gì đó mang tính đối kháng đã cố gắng phá vỡ nó trước và thất bại.