Rachel Laycock kể một câu chuyện tại hội nghị FOSE mà đọng lại lâu hơn hầu hết giai thoại hội nghị khác: một business user xây một công cụ nội bộ hoàn chỉnh bằng AI agent, ngay trên sân khấu, trực tiếp — hoàn thiện, chạy được, và theo mọi tín hiệu nhìn thấy được, đã xong. Câu hỏi tiếp theo hiển nhiên từ khán phòng là một biến thể của “vậy giờ ai cũng tự xây phần mềm được rồi phải không?” Câu trả lời của bà là không, và lý lẽ đằng sau chữ “không” đó là một tư duy lãnh đạo kỹ thuật hay hơn phần lớn những gì đã được viết về “AI dân chủ hóa việc phát triển phần mềm” trong năm nay.

Câu nói đóng khung lại tất cả

Điểm thực sự của Laycock không phải là công cụ đó tệ, hay citizen builder giờ không thể tạo ra phần mềm thật bằng agent — rõ ràng họ làm được. Điểm của bà là một demo chạy được trả lời một câu hỏi hẹp hơn nhiều so với vẻ ngoài của nó: cái này có xây được không. Nó không nói gì về câu hỏi thứ hai quyết định liệu công cụ đó có nên tồn tại trong hệ thống của công ty hay không: cái này có xứng đáng chạy trong production, với quyền truy cập dữ liệu, kỳ vọng uptime và bán kính ảnh hưởng đi kèm hay không. Cách bà phân vai ai trả lời câu hỏi nào chính là phần đáng học theo nhất: citizens build, agents execute, experts govern (công dân xây, agent thực thi, chuyên gia quản trị). Và câu nói bên dưới đó là câu mình cứ quay lại nghĩ mãi — “Tổ chức không vận hành bằng code. Chúng vận hành bằng lòng tin.” Một công cụ chạy được là một tuyên bố về code. Một công cụ an toàn để phụ thuộc vào là một tuyên bố về lòng tin, và tuyên bố về lòng tin cần một kiểu chủ sở hữu khác với người vừa prompt ra phiên bản chạy được đầu tiên.

Đây không phải lập luận chống lại phần mềm do citizen xây, và cũng không phải rào cản khoác áo quản trị. Đây là một tuyên bố về việc quyết định nào có thể giao phó cho việc output của agent trông đúng, và quyết định nào cần một người có thẩm quyền và bối cảnh thực sự đưa ra — một ranh giới mà công cụ agentic làm cho cấp bách hơn, không phải kém đi, vì ngưỡng “demo chạy ổn” đã trở nên dễ vượt qua hơn rất nhiều trong năm nay, trong khi ngưỡng “cái này xứng đáng nằm trong production” thì không hề dịch chuyển.

Vì sao đây là hơn cả một bài nói chuyện

Lý do cách đóng khung này hữu ích chứ không chỉ gọn gàng là nó khớp thẳng với một chế độ thất bại mà nhiều tổ chức kỹ thuật đã đang âm thầm trải qua: output của agent giờ đủ tốt đến mức nút thắt cổ chai của việc review đã dịch chuyển. Trước đây câu hỏi là “chúng ta xây cái này đủ nhanh không.” Giờ câu hỏi là “chúng ta có thể nhận ra, đủ nhanh, cái nào trong số những gì đã xây nhanh thực sự ổn để giữ lại.” Một demo vượt qua ngưỡng đó không nói gì về cách xử lý dữ liệu, về chuyện gì xảy ra khi một edge case mà demo chưa từng chạm tới xuất hiện ở tuần thứ ba, về ai chịu trách nhiệm khi nó gãy lúc 2 giờ sáng, hay về việc nó có âm thầm nhân bản một năng lực mà ba team khác đã sở hữu dưới tên gọi khác hay không. Không điều nào trong số đó xuất hiện trong một demo trực tiếp, theo đúng bản chất — demo được tối ưu để cho bạn thấy happy path.

Một playbook guardrail, không phải một khẩu hiệu

Biến “citizens build, agents execute, experts govern” thành thứ thực sự chạy được đòi hỏi gọi tên ai làm gì ở mỗi vai trong ba vai đó, và điểm chuyển giao nằm ở đâu:

1. Cho citizen builder một sân chơi có giới hạn, không phải quyền truy cập mở vào hệ thống production. Công cụ trong câu chuyện của Laycock nên tồn tại — trong một môi trường sandbox với dữ liệu tổng hợp hoặc đã ẩn danh, được team sẽ sở hữu nó nếu nó “tốt nghiệp” nhìn thấy. Sai lầm không nằm ở việc citizen xây dựng; nó nằm ở việc citizen xây trực tiếp trên hệ thống có dữ liệu khách hàng thật mà không có cổng review nào giữa “chạy được” và “đang live.”

2. Biến “agent thực thi” và “chạy trong production” thành hai trạng thái khác nhau với một cổng tường minh ở giữa, không phải hai cái tên cho cùng một thứ. Việc một agent hoàn thành một tác vụ và việc một con người phê duyệt output của tác vụ đó cho production không phải cùng một sự kiện, và coi chúng là cùng một sự kiện chính là khoảng trống mà sự cố OpenAI–Hugging Face (mình đã viết riêng trong tuần này) cho thấy bạn không nên bỏ qua. Vai trò “execute” của agent trong khung của Laycock được giới hạn ở làm việc, không phải quyết định việc đã xong.

3. Gọi tên chuyên gia review trước khi công cụ ra mắt, không phải sau khi có chuyện gãy. “Sẽ có ai đó review” không phải là một control; một người hoặc team cụ thể có thẩm quyền nói không mới là control. Nếu ngay lúc này không ai gọi tên được người đó cho một công cụ cụ thể, công cụ đó không có chủ sở hữu quản trị — nó có một khoảng trống quản trị đang khoác áo một tính năng đã hoàn thiện.

4. Định tuyến theo bán kính ảnh hưởng, không phải theo cách công cụ được xây. Một dashboard nội bộ do citizen xây, chỉ đọc từ một reporting replica read-only, cần review nhẹ hơn nhiều so với một service do agent xây ghi vào database đối diện khách hàng, bất kể cái nào dùng nhiều AI hơn. Coi “được AI tạo ra” là tín hiệu rủi ro thay vì “cái này có thể chạm tới những gì” là chẩn đoán sai rủi ro thực sự.

5. Coi review của chuyên gia là việc liên tục, không phải một cổng một lần. Phần mềm “tốt nghiệp” review từ tháng Sáu và chưa được ai nhìn lại từ đó là rủi ro đang trôi dạt, đặc biệt khi một agent vẫn đang chủ động chỉnh sửa nó. Vai trò quản trị không kết thúc ở lúc ra mắt; nó lặp lại theo nhịp gắn với mức độ hệ thống đó vẫn còn đang thay đổi.

Phần cộng hưởng với cách mình thực sự đang làm việc

Mình chạy một phần đáng kể output vận hành của chính mình — pipeline xuất bản của blog này, một tech digest, một product-lead digest — qua các scheduled agent thực thi không giám sát qua đêm và giao lại cho mình một sản phẩm hoàn chỉnh để review vào buổi sáng. Đó gần như đúng y hệt vai trò “agent thực thi” của Laycock: mình viết spec một lần (một prompt, một template, một tập ràng buộc nguồn), agent làm việc trong lúc mình không theo dõi, và mình là chuyên gia quyết định thứ trả về có đủ tiêu chuẩn để thực sự xuất bản hay không. Lý do việc này chạy được mà không cần mình canh từng lượt chạy không phải vì agent đáng tin cậy một cách trừu tượng — mà vì ranh giới giữa “agent đã xong” và “cái này đang live” luôn có một điểm quyết định của con người nằm ở giữa, mỗi lần, và điểm quyết định đó có thẩm quyền thật để từ chối, không chỉ đóng dấu cho qua. Framework của Laycock không mô tả một trạng thái tương lai xa nào đó của độ trưởng thành quản trị AI. Nó mô tả cái hình dạng mà nhiều người trong chúng ta đã tự bước vào theo bản năng, một khi agent bắt đầu tạo ra đủ nhiều output để việc review mọi thứ thủ công không còn là nút thắt nữa, và quyết định cái gì đáng review kỹ trở thành công việc thực sự.

Phần khó chịu khi thực sự áp dụng điều này là nó đặt tên cho vai trò mà hầu hết tổ chức hiện đang để ngầm định: phải có ai đó là chuyên gia quản trị, một cách có chủ đích, cho mọi hạng mục hệ thống mà agent chạm vào mà bạn đang vận hành — và nếu bạn không gọi tên được người đó cho một công cụ cụ thể, bạn không có một khoảng trống quản trị đã được giảm thiểu, bạn có một khoảng trống chưa từng được nhìn tới.