Khi AI làm việc qua đêm: bottleneck mới không còn là tốc độ, mà là khả năng giao việc
Có một cách dùng AI mà tôi thấy đáng suy nghĩ hơn rất nhiều so với chuyện viết prompt hay hơn: giao cho AI một ca làm việc riêng, để nó xử lý những phần có thể chuẩn bị trước trong lúc mình không ngồi trước máy tính.
Azeem Azhar gọi mô hình ông đang thử là một “AI night shift”. Trong bài viết trên Fast Company, ông mô tả một agent trung tâm có nhiệm vụ điều phối nhiều agent khác nhau: nghiên cứu, phân tích, biên tập, dữ liệu, góc nhìn đầu tư và cả các agent hỗ trợ lập trình. Khi ông ngủ, hệ thống có thể tiếp tục xử lý các đầu việc đã được giao; sáng hôm sau, ông quay lại để đọc, kiểm tra và quyết định bước tiếp theo.
Nghe qua khá giống một câu chuyện về năng suất.
Nhưng điều tôi thấy thú vị hơn lại nằm ở phía sau: khi khả năng thực thi của AI tăng nhanh, bottleneck không biến mất. Nó chỉ chuyển chỗ.
Từ “làm không kịp”, chúng ta có thể chuyển sang một loạt vấn đề mới:
- không biết nên giao việc gì cho AI;
- chưa mô tả đủ bối cảnh để AI làm đúng;
- không biết nên cho AI quyền truy cập đến đâu;
- mất nhiều thời gian kiểm tra đầu ra;
- tạo quá nhiều kết quả nhưng không kịp ra quyết định;
- một người tăng tốc nhưng lại đẩy thêm việc sang những người còn lại trong team.
Đó mới là phần tôi nghĩ đáng mang về áp dụng vào công việc.
Tóm tắt nhanh
Nếu chỉ giữ lại vài ý từ mô hình “AI night shift”, tôi sẽ giữ 5 điểm này:
- AI đang đi từ hỏi–đáp sang giao việc. Giá trị không chỉ nằm ở câu trả lời tức thời, mà ở khả năng xử lý một chuỗi công việc có mục tiêu và bối cảnh.
- Một agent tốt cần nhiều hơn một prompt tốt. Nó cần hướng dẫn bền vững, hiểu dự án, biết ưu tiên, có tài nguyên và chỉ được cấp những quyền thực sự cần thiết.
- Tự chủ càng cao, rủi ro càng lớn. Agent có thể dùng email, lịch, codebase hay hệ thống quản lý công việc thì cũng có nhiều cách gây ra hậu quả hơn nếu hiểu sai.
- Vai trò của con người chuyển từ làm sang phán đoán. Khi lượng đầu ra tăng, việc quan trọng là biết cái gì đủ tốt để dùng, cái gì phải sửa, cái gì nên bỏ.
- Năng suất cá nhân chưa chắc là năng suất tổ chức. Nếu một người dùng AI tạo ra lượng việc quá lớn cho team, toàn hệ thống vẫn có thể chậm hơn.
1. Một “ca đêm AI” thực sự trông như thế nào?
Điểm đáng chú ý trong bài của Azeem Azhar không phải là một chatbot thức cả đêm để viết văn bản.
Ông xây một agent điều phối tên RMA. Agent này có bối cảnh về công việc, dự án và cách ông muốn mọi thứ được xử lý. Tùy đầu việc, nó có thể gọi các agent chuyên vai trò khác nhau để cùng xử lý.
Một số ví dụ được tác giả mô tả gồm:
- chuẩn bị một bản nghiên cứu về tình trạng thiếu helium;
- phân khúc khách hàng bằng cách mô phỏng nhiều kiểu người dùng khác nhau;
- kiểm tra bảo mật;
- cập nhật phần mềm và xử lý một số việc kỹ thuật lặp lại;
- phối hợp các agent viết code khi cần.
Sáng hôm sau, tác giả không bắt đầu từ trang trắng. Ông bắt đầu từ một tập kết quả đã được chuẩn bị trước.
Ở đây có một thay đổi khá lớn về cách dùng AI:
Cách cũ:
Tôi hỏi → AI trả lời → tôi đọc → tôi hỏi tiếp.
Cách mới:
Tôi định nghĩa mục tiêu → hệ thống chia việc → các agent xử lý song song → gom kết quả → tôi kiểm tra → tôi quyết định.
Khoảng cách giữa hai cách này không chỉ là “AI thông minh hơn”. Nó là một thay đổi về thiết kế workflow.
Nếu workflow không rõ, agent chỉ giúp tạo ra sự hỗn loạn nhanh hơn.
2. Một agent tốt không bắt đầu từ prompt, mà từ bối cảnh
Có một chi tiết tôi thấy rất đáng chú ý: hệ thống của Azhar không hoạt động dựa trên một prompt ngắn được viết lại mỗi ngày.
Ông mô tả các hướng dẫn bền vững dài hàng nghìn từ, chứa thông tin về team, dự án, cuốn sách đang viết, ưu tiên và cách ông muốn agent làm việc. Agent cũng có thể được kết nối với những nguồn như email, lịch, codebase, CRM hay hệ thống quản lý dự án.
Điều này gợi ra một nguyên tắc khá thực tế:
Muốn AI làm việc giống một cộng sự, trước hết phải cho nó đủ bối cảnh để hiểu công việc giống một cộng sự.
Tôi nghĩ đây cũng là lý do nhiều workflow AI hoạt động rất hay trong demo nhưng trở nên thất thường khi đưa vào công việc thật.
Ta thường đầu tư quá nhiều vào câu lệnh cuối cùng, nhưng lại thiếu những lớp nền quan trọng hơn:
Mục tiêu
AI cần biết đầu ra dùng để làm gì. Một bản phân tích để tham khảo khác với một bản sẽ dùng để quyết định ngân sách.
Bối cảnh
Cùng một yêu cầu “phân tích chiến dịch”, nhưng chiến dịch branding, lead generation và bán hàng trực tiếp có cách đọc dữ liệu khác nhau.
Nguyên tắc
Ví dụ: không bịa số liệu, không tự thay đổi production, không gửi email khi chưa duyệt, không đưa dữ liệu cá nhân vào hệ thống phân tích.
Tài nguyên
AI được đọc file nào? Được dùng công cụ gì? Dữ liệu nào là nguồn sự thật?
Quyền hạn
Được đọc nhưng không được ghi? Được tạo bản nháp nhưng không được gửi? Được thay đổi môi trường test nhưng không được chạm production?
Tôi thấy đây là một cách nhìn hữu ích hơn nhiều so với câu hỏi “prompt nào hay nhất?”.
3. “Time horizon” có thể là một thước đo đáng chú ý hơn benchmark
Trong bài viết, Azhar nhắc tới nghiên cứu của METR về time horizon — hiểu đơn giản là độ dài của một tác vụ mà một hệ thống AI có thể tự hoàn thành với mức độ tin cậy nhất định mà không cần con người can thiệp liên tục.
Ý tưởng này đáng chú ý vì nó gần với công việc thật hơn việc chỉ hỏi một model trả lời được bao nhiêu câu benchmark.
Một AI có thể trả lời rất hay trong 30 giây nhưng vẫn không hữu ích nếu nó không thể:
- giữ mục tiêu trong một chuỗi việc dài;
- nhớ ràng buộc;
- phát hiện khi thiếu dữ liệu;
- dùng đúng công cụ;
- dừng lại trước một hành động rủi ro;
- gom kết quả thành thứ con người có thể kiểm tra.
Tác giả gọi xu hướng mở rộng “tầm với nhận thức theo thời gian” này là một dạng Time Horizon law. Tôi xem đây là cách diễn giải của tác giả, không phải một định luật đã được xác lập.
Nhưng câu hỏi vận hành phía sau thì rất đáng dùng:
Một workflow hiện tại có thể giao cho AI tự chạy được bao lâu trước khi con người buộc phải can thiệp?
Nếu hôm nay câu trả lời là 5 phút, chưa chắc vấn đề nằm ở model. Có thể workflow đang thiếu dữ liệu, thiếu tiêu chí hoàn thành hoặc thiếu ranh giới quyền hạn.
4. Khi sản lượng tăng, kiểm tra phải chuyển thành phán đoán
Azhar mô tả một thay đổi trong buổi sáng của mình: thay vì kiểm tra tỉ mỉ từng chi tiết của mọi đầu ra, ông ngày càng phải làm một dạng validation — đánh giá xem kết quả có hợp lý, có đủ căn cứ và có phù hợp để dùng hay không.
Đây là chỗ tôi nghĩ vai trò con người không giảm đi, mà thay đổi.
Khi AI tạo ra một báo cáo trong vài phút, giá trị của con người không còn nằm nhiều ở việc gõ từng dòng báo cáo. Giá trị nằm ở những câu hỏi như:
- Phân tích này có đang trả lời đúng vấn đề không?
- Có bỏ sót dữ liệu quan trọng nào không?
- Kết luận nào là fact, kết luận nào chỉ là suy luận?
- Nếu hành động theo đề xuất này, rủi ro là gì?
- Có việc nào AI không có đủ bối cảnh để quyết định thay mình?
- Điều gì nên làm ngay, điều gì chỉ đáng đưa vào backlog?
Nói cách khác, khi chi phí tạo ra đầu ra giảm, giá trị của judgment tăng lên.
Và đây cũng là một cảnh báo nhỏ: nếu mình dùng AI quá nhiều nhưng khả năng phản biện, kiểm chứng và ra quyết định không tăng tương ứng, mình có thể tạo ra rất nhiều thứ “trông có vẻ đúng” mà không biết cái nào thực sự đáng dùng.
5. Năng suất cá nhân có thể biến thành áp lực của cả team
Đây có lẽ là phần tôi thích nhất trong bài.
Khi một người có thể dùng nhiều agent để nghiên cứu, viết, phân tích và chuẩn bị việc nhanh hơn trước, người đó có thể trở thành một “vòi nước công việc” đối với những người còn lại.
Ví dụ:
- AI giúp một manager tạo 20 đề xuất trong một buổi tối, nhưng team chỉ có khả năng review 3 đề xuất mỗi ngày.
- AI giúp marketer nghĩ ra 50 hướng thử nghiệm, nhưng designer và developer vẫn có giới hạn thời gian.
- AI giúp một người tạo ra nhiều ticket, tài liệu và yêu cầu hơn, nhưng mỗi ticket lại cần một người khác đọc và phản hồi.
Kết quả là người dùng AI cảm thấy mình nhanh hơn, trong khi toàn bộ hệ thống lại có thêm hàng đợi.
Tôi gọi đây là một dạng nợ phối hợp.
AI làm giảm chi phí sản xuất một đầu việc, nhưng không tự động làm giảm chi phí:
- thống nhất ưu tiên;
- trao đổi giữa người với người;
- duyệt rủi ro;
- quyết định ai chịu trách nhiệm;
- xử lý xung đột mục tiêu;
- hấp thụ thay đổi vào quy trình đang chạy.
Đây là lý do tôi nghĩ KPI kiểu “AI giúp tạo nhiều output hơn” chưa đủ.
Câu hỏi tốt hơn là:
Sau khi AI tạo ra đầu ra, hệ thống có biến nó thành quyết định hoặc hành động tốt hơn không?
Nếu không, mình chỉ đang tự động hóa việc tạo thêm backlog.
6. Nếu áp dụng vào công việc của mình, tôi sẽ bắt đầu nhỏ hơn rất nhiều
Tôi không nghĩ bước đầu hợp lý là dựng ngay một đội 10 agent chạy suốt đêm.
Nếu muốn thử mô hình này trong Marketing, Data, Automation hay vận hành website, tôi sẽ bắt đầu bằng một ca đêm tối giản gồm 5 lớp.
Lớp 1 — Hàng đợi công việc rõ ràng
Mỗi tối chỉ chọn 1–3 việc có đầu ra cụ thể.
Ví dụ:
- tổng hợp các thay đổi mới từ một nhóm nguồn đã chỉ định;
- kiểm tra log của một workflow và nhóm lỗi theo nguyên nhân;
- chuẩn bị draft phân tích một biến động dữ liệu;
- rà soát một bài Knowledge: nguồn, claim, metadata, internal link;
- tạo test case cho một automation mới.
Không giao kiểu “hãy tối ưu toàn bộ hệ thống”.
Lớp 2 — Bối cảnh bền vững
Thay vì nhét mọi thứ vào prompt mỗi lần chạy, hệ thống cần một bộ context ổn định:
- mục tiêu;
- nguồn dữ liệu nào đáng tin;
- định nghĩa metric;
- nguyên tắc thương hiệu;
- quy tắc bảo mật;
- format đầu ra;
- các quyết định đã chốt trước đó.
Đây là phần giúp AI bớt “thông minh ngẫu nhiên” và trở thành một quy trình có thể lặp lại.
Lớp 3 — Phân vai vừa đủ
Chỉ tách agent khi vai trò thật sự khác nhau.
Ví dụ một workflow nghiên cứu có thể chỉ cần:
- agent thu thập và chuẩn hóa nguồn;
- agent phản biện claim;
- agent tổng hợp thành bản draft.
Nếu một agent duy nhất làm được ổn, không cần tách thành năm agent cho đẹp sơ đồ.
Lớp 4 — Guardrail trước quyền hạn
Tôi sẽ chia hành động thành ba nhóm:
Có thể tự chạy: đọc dữ liệu, tổng hợp, phân loại, tạo draft, tạo checklist, đề xuất test case.
Cần review trước khi chạy: sửa file, tạo pull request, cập nhật dữ liệu dùng chung, thay đổi cấu hình test.
Không được tự quyết: deploy production, đổi ngân sách quảng cáo, gửi email ra ngoài, xóa dữ liệu, thay DNS, cấp quyền truy cập mới hoặc thực hiện hành động khó hoàn tác.
Một hệ thống càng tự chủ thì việc định nghĩa “không được làm gì” càng quan trọng.
Lớp 5 — Morning review có tiêu chí
Sáng hôm sau không chỉ hỏi “AI đã làm xong chưa?”.
Tôi sẽ review theo 5 câu:
- Đầu ra có đúng mục tiêu ban đầu không?
- Nguồn và dữ liệu có đủ tin cậy không?
- Có chỗ nào AI suy luận vượt quá bằng chứng không?
- Tôi chấp nhận, sửa hay bỏ kết quả này?
- Có hành động tiếp theo nào thực sự đáng đưa vào lịch làm việc không?
Sau vài tuần, chính dữ liệu review này mới cho biết workflow có đáng tự động hóa sâu hơn hay không.
7. Một dashboard cho AI Agent nên đo gì?
Nếu làm thật, tôi không muốn đo số lượng token, số agent hay số task hoàn thành như KPI chính.
Tôi quan tâm hơn đến các chỉ số vận hành như:
- Acceptance rate: bao nhiêu đầu ra được dùng mà không phải làm lại từ đầu?
- Rework rate: bao nhiêu đầu ra cần sửa lớn?
- Human review time: con người mất bao lâu để kiểm tra?
- Escalation rate: bao nhiêu việc agent biết dừng và chuyển cho người?
- Error severity: lỗi nếu có nghiêm trọng đến đâu?
- Decision throughput: workflow có giúp ra quyết định nhanh hơn hay chỉ tạo thêm tài liệu?
- Backlog created: AI có đang tạo thêm việc cho người khác nhiều hơn giá trị nó tiết kiệm không?
Không nhất thiết phải dựng dashboard ngay từ ngày đầu. Một Sheet đơn giản cũng đủ để ghi vài tuần đầu.
Điểm quan trọng là đo chất lượng của hệ thống giao việc, không chỉ đo sản lượng của AI.
8. Bài học lớn nhất: AI càng làm được nhiều, con người càng phải biết mình muốn gì
Một câu trong bài của Azhar khiến tôi suy nghĩ khá lâu: nỗi lo của ông dần chuyển từ “AI có đủ khả năng không?” sang “mình có đủ việc hữu ích để giao cho nó không?”.
Tôi nghĩ đây là một dấu hiệu quan trọng.
Trong giai đoạn chatbot, kỹ năng nổi bật là đặt câu hỏi.
Trong giai đoạn agent, kỹ năng có thể dịch chuyển sang:
- phân rã vấn đề;
- định nghĩa đầu ra;
- thiết kế context;
- phân quyền;
- đặt guardrail;
- kiểm chứng;
- ưu tiên;
- ra quyết định;
- phối hợp con người và máy.
AI có thể làm phần “chạy” ngày càng nhanh.
Nhưng để Từ Rối → Gọn → Chạy Được, phần khó vẫn bắt đầu từ con người: biết việc nào đáng làm, việc nào không cần làm, việc nào nên giao và việc nào phải giữ lại để tự mình phán đoán.
Đó có lẽ là lý do tôi không nhìn “AI night shift” như một mẹo tăng năng suất.
Tôi nhìn nó như một bài toán thiết kế hệ thống làm việc mới.
Nguồn tham khảo
- Azeem Azhar, “My AI night shift”, Fast Company, 29/06/2026: https://www.fastcompany.com/91549044/my-ai-night-shift