Khi dùng tác nhân lập trình AI thật sự nghiêm túc, điều gây bất ngờ đầu tiên không phải là trí thông minh.
Mà là:
“Bao giờ nó tan ca?”
Ban ngày nghiên cứu, chiều triển khai, tối kiểm thử, nửa đêm giao bug. Sáng hôm sau nó vẫn đang sửa gì đó.
Nếu là đội ngũ con người, ta sẽ phải lo ca đêm, làm thêm, bàn giao, mệt mỏi và lịch trực. Với AI, giới hạn chuyển thành gói sử dụng, quota, context, công cụ và độ tin cậy của hệ thống.
Dùng nặng còn tạo ra hiện tượng lạ:
hạn mức của cả tuần có thể hết chỉ sau vài ngày.
Ban đầu thấy rất rộng. Vài ngày sau hệ thống gần như nói: “Tuần này bạn đã bắt nó làm quá nhiều.”
Luật lao động biến mất rồi tái sinh thành rate limit.
0. Cần đo throughput, không phải số giờ
Thay vì hỏi AI chạy bao nhiêu giờ, hãy hỏi:
- hoàn thành bao nhiêu điều tra
- sửa bao nhiêu file
- chạy bao nhiêu test
- xử lý bao nhiêu sự cố
- bao nhiêu kết quả đến production
- bao nhiêu kết quả bị kẹt
AI có thể lặp việc tìm kiếm, so sánh, chỉnh sửa và kiểm thử rất nhanh. Chỉ số quan trọng là bao nhiêu công việc hữu ích đi hết pipeline.
1. Điều kỳ lạ của vận hành 24 giờ không phải ca đêm rẻ
Con người vận hành 24/7 cần ca trực, phụ cấp, bàn giao và dự phòng nhân sự.
AI thường chịu cùng giới hạn sản phẩm cả ngày lẫn đêm.
Điều lạ không phải “nó làm việc ban đêm”.
Mà là cùng một đơn vị có thể chạy liên tục mà không đổi ca.
Lỗi của AI cũng khác: thiếu context, giả định sai, tool lỗi hoặc hiểu sai yêu cầu.
2. Hạn mức tăng thì khối lượng công việc cũng tăng
Khi quota lớn hơn, người dùng ít tiết kiệm hơn.
Những việc từng tự làm cũng giao cho AI.
Một yêu cầu nghiên cứu nhanh biến thành:
nghiên cứu→triển khai→test→sửa→test lại→xem log→sửa tiếp.
Vì vậy quota lớn hơn nhiều vẫn có thể hết rất nhanh.
Không hẳn vì năng lực thiếu.
Nguồn cung tăng kéo theo nhu cầu sử dụng AI tăng.
3. Khoảng chờ phục hồi trở thành buffer
Trong thời gian chờ có thể:
- ghi lại lỗi mới
- chuẩn hóa bước tái hiện
- tích lũy log
- phân nhóm nguyên nhân
- ưu tiên batch tiếp theo
Khi quota quay lại, xử lý cả lô.
Từ hội thoại real-time chuyển thành nhà máy batch.
4. Chế độ chất lượng cao nên dùng để escalation
Chế độ suy luận chất lượng cao có thể tiêu tốn quota mạnh.
Nhưng rất đáng giá khi thực sự bị kẹt.
Dùng nó để:
- liệt kê nguyên nhân gốc
- lập bản đồ dependency
- thiết kế thứ tự sửa
- ngăn lỗi lặp lại
- chọn chỉ số giám sát
Nói cách khác, dùng cho lập kế hoạch trong tình huống bất định.
Việc thường: mode thường. Bị kẹt: escalate. Chẩn đoán và lập kế hoạch: premium. Thi hành: quay lại mode thường.
5. AI càng nhanh, bottleneck càng chuyển chỗ
Pipeline thường là:
tạo → lưu → chuyển đổi → xuất bản → production → xác minh.
Một bước không ổn định có thể làm mất giá trị của toàn bộ tốc độ phía trước.
Tạo 100, chỉ 99 lên production, 1 cái trở thành tồn kho.
Nếu lặp lại, đó là vấn đề yield.
6. “Bài không xuất hiện” chưa chắc là lỗi sinh nội dung
Có thể lỗi ở:
- lưu file
- metadata
- localization
- publication queue
- deploy
- verification
- trang danh sách
Mỗi bước cần có bộ đếm.
Tạo 120 → lưu 120 → vào queue 118 → xác minh 116
Bốn mục biến mất sẽ trở nên rõ ràng.
Lỗi có thể xảy ra; biến mất im lặng thì không được.
7. Nhà máy AI 24 giờ cần tự phục hồi
Quy trình lý tưởng:
- phát hiện thiếu
- cô lập ID
- phân loại lỗi
- retry nếu an toàn
- chỉ escalate lỗi lặp lại
Không chạy lại tất cả.
Chỉ xử lý lại phần bị hỏng.
8. Vai trò con người giảm nhưng không biến mất
Con người vẫn quyết định:
- điều gì quan trọng
- mức lỗi nào chấp nhận được
- việc gì không nên tự động hóa
- khi nào ưu tiên chất lượng
- lỗi nào đáng dùng premium
Vai trò chuyển thành thiết kế dây chuyền.
9. Điều đáng sợ không phải AI làm quá nhiều
Vấn đề thật là dùng nhiều quota nhưng kết quả:
- mất giữa pipeline
- không tới production
- lỗi mà không ai thấy
- lặp cùng một bug
- tốn premium cho việc vặt
Nguyên tắc tốt:
rẻ và nhanh cho việc thường; premium cho bottleneck; lỗi phải nhìn thấy; tự phục hồi khi có thể.
Đến đây, bạn không chỉ đang dùng AI.
Bạn đang thiết kế một nhà máy nơi AI có thể làm việc.
