Mình từng để AI chọn angle bài viết, còn mình ngồi bấm chạy lại test sau mỗi lần sửa code. Tự động hoá công việc bằng AI kiểu đó là làm ngược. Máy nhận phần cần phán đoán, mình ôm phần lặp đi lặp lại. Mất một năm mình mới nhìn ra.
Mình ra lệnh, agent gõ phím
Mình không đọc code. Mọi thay đổi trong các sản phẩm mình đang chạy đều do agent sửa file và chạy lệnh. Vì thế mình thấy rõ chỗ máy làm tốt và chỗ máy làm hỏng, không bị cuốn vào chi tiết kỹ thuật. Chỗ máy làm hỏng gần như luôn là chỗ mình giao sai loại việc.
Ban đầu mình tưởng vấn đề nằm ở model. Model yếu thì kết quả tệ, đổi model khá hơn là xong. Hoá ra vấn đề nằm ở cách mình chia việc. Cùng một model, giao đúng loại việc thì nó chạy sạch nhiều tuần liền, giao sai loại việc thì tuần nào mình cũng phải dọn tay.
Câu hỏi mình tự đặt trước khi bật thứ gì lên: nếu máy làm sai, ai phát hiện, và sau bao lâu.
Trước khi tự động hoá công việc bằng AI
Câu hỏi đó xếp mọi việc vào bốn nhóm, theo khả năng bạn biết mình vừa bị sai. Số nhóm càng cao thì cái sai càng khó nhìn thấy. Một việc rất khó mà sai thì đỏ ngay vẫn an toàn hơn một việc dễ mà sai thì im lặng.
Nhóm 1: việc lặp lại, đúng sai rõ ràng
Kết quả của nhóm này kiểm được bằng máy. Chạy xong thì hoặc xanh hoặc đỏ, không có vùng xám ở giữa. Đây cũng là nhóm mình bỏ quên lâu nhất, vì nó nhàm.
Việc rõ nhất của mình ở đây là chạy lại test sau mỗi lần sửa. Trước mình bấm tay rồi ngồi đợi. Bây giờ agent tự chạy và tự sửa cho tới khi xanh, mình chỉ nhìn dòng cuối cùng.
Nhóm này giao hết, không cần người duyệt, vì bản thân test đã là người duyệt rồi.
Nhóm 2: việc lặp lại nhưng sai thì tốn tiền
Vẫn lặp lại, vẫn kiểm được, nhưng hậu quả lệch hẳn về một phía. Làm đúng thì tiết kiệm vài phút. Làm sai thì mất tiền thật, hoặc deploy một thứ hỏng lên bản đang chạy.
Cách của mình ở nhóm này: máy chuẩn bị toàn bộ, mình bấm nút cuối. Máy làm hết phần việc rồi dừng lại và đợi.
Chi phí của cách này là vài giây mỗi lần. Đổi lại, mình không còn phải biết tin xấu qua tin nhắn của người dùng.
Nhóm 3: việc cần phán đoán, chỉ làm một lần
Chọn hướng đi cho một sản phẩm. Quyết định bỏ một tính năng đang có người dùng. Loại việc này làm một lần, không có mẫu để lặp, và không có test nào chấm được.
Máy vẫn có ích, nhưng vai trò khác hẳn: nó đi tìm tư liệu và tóm tắt lại cái đã có, còn người vẫn là bên quyết.
Mình từng giao hẳn nhóm này cho máy. Kết quả không sai, chỉ nhạt. Mình đổ lỗi cho prompt, viết lại kỹ hơn vẫn nhạt. Nhạt thì không ai báo lỗi, nên mình mất khá lâu mới nhận ra đang đọc chính mình bị pha loãng.
Prompt viết kỹ hơn không cứu được nhóm 3, nhưng nó cứu được nhóm 1 và nhóm 2 rất nhiều. Cách mình tả việc cho agent nằm ở bài giao việc cho AI agent.
Nhóm 4: việc không ai kiểm chứng được
Đây là nhóm nguy hiểm, vì máy làm kém thì không có tín hiệu nào phát ra. Không có màu đỏ, không có ai phàn nàn.
Nhóm này đừng tự động hoá. Nếu vẫn muốn tự động, phải có cách tự mình nhìn thấy kết quả, thay vì nghe máy báo lại.
Cách thử để biết việc thuộc nhóm nào
Hai vế của câu hỏi trên phải điền được bằng một cái tên và một khoảng thời gian. "Chắc là có ai đó thấy" không tính là điền.

Điền được cả hai vế thì việc đó thuộc nhóm 1 hoặc nhóm 2. Vế nào bỏ trống thì nó rơi xuống nhóm 4, kể cả khi việc đó nghe đơn giản. Mình từng xếp nhầm vài việc lên nhóm 1 chỉ vì chúng dễ, và cả hai lần hỏng dưới đây đều bắt đầu từ đó.
Xếp nhóm xong thì tới câu hỏi kế: trong nhóm 1 nên chọn việc nào để giao đầu tiên. Mình trả lời riêng ở bài nên tự động hoá việc gì trước.
Việc mình đã giao và việc mình rút lại
Danh sách thật đang chạy:
- Soạn draft bài viết: giao hẳn cho máy.
- Chạy lại test sau mỗi thay đổi: giao hẳn cho máy.
- Quét tech debt hằng tuần: giao hẳn cho máy.
- Tự tuyên bố "đã kiểm tra xong": từng giao, và đã rút lại.
Máy tự khai đã kiểm tra xong là thứ mình không kiểm chứng được. Nó nói, mình tin, hết chuyện. Lời khai đó thuộc nhóm 4, mà mình xếp nó vào nhóm 1 suốt một thời gian dài.
Bây giờ luật là chạy lại test thật, rồi đọc exit code hoặc một dòng kết quả bằng mắt trước khi coi là xong. Mấy ghi chép cùng mạch mình để ở chủ đề Tự động hoá.
Lần hỏng mình nhớ nhất
Mình có một background job, đáng lẽ chạy hằng ngày mà không cần ai ngồi canh. Việc của nó là đồng bộ bộ luật làm việc của mình sang một công cụ khác.
Nó chưa bao giờ được đặt lịch cron, nên nó chỉ chạy đúng những lần mình gõ tay. Mỗi lần như vậy, nó chạy sạch, in ra dòng thành công, và mình yên tâm đi làm việc khác. Giữa các lần đó, nó nằm im.
Không ai phát hiện suốt nhiều tuần. Lý do rất tầm thường: nó ghi log vào một file không ai mở ra đọc. File đó vẫn có nội dung, mỗi lần mình gõ tay lại thêm một dòng trông bình thường. Đoạn code chạy đúng. Thứ hỏng là niềm tin của mình rằng nó đang chạy hằng ngày.
Mình sửa bằng cách gắn cho nó một dấu vết mình soi được mỗi tuần, thay vì để nó tự viết log cho chính nó. Kiểu hỏng im lặng này mình mổ riêng ở bài khi máy làm sai mà không ai biết.

Thứ tự động mà hỏng âm thầm còn tệ hơn thứ mình chưa tự động. Việc tay không chạy thì bạn biết ngay hôm đó, vì bạn là người phải ngồi làm nó.
Dependency hỏng tệ hơn dependency thiếu
Lần thứ hai thì phát hiện nhanh hơn, nhưng khó chịu không kém. Một dependency cài hỏng làm bước build index của ô tìm kiếm chết ngay từ dòng đầu tiên.
Lỗi có hiện ra. Nhưng nó nằm lẫn trong một dòng log giữa đống chữ khác, không làm build dừng lại, không báo đỏ.
Nếu dependency đó thiếu hẳn, cả build đã đứng lại và mình biết trong vòng một phút. Vì nó có mặt nhưng hỏng, hệ thống vẫn chạy tiếp, chỉ là rỗng một phần bên trong.
Từ hôm đó mình xếp "cài hỏng" vào nhóm 4 chứ không phải nhóm 1. Cái này mình cũng chưa chắc đúng cho mọi trường hợp, nhưng xếp cao hơn thì an toàn hơn.
Nút publish mình không giao cho máy
Blog này do máy soạn draft. Mình biên tập lại, rồi mình bấm publish.
Quy tắc đó đứng được là nhờ cách chặn. Con bot chỉ có quyền tạo draft. Quyền publish bị chặn server-side, không phải giấu cái nút đi trong admin panel.
Giấu nút là một thoả thuận. Chặn server-side là một cái luật. Nếu bạn định để AI viết bài, đây là chỗ nên làm chặt tay nhất. Mình mô tả kỹ hơn trong quy trình để AI viết bài.
Công cụ mình dùng để ra lệnh cho agent là Claude Code, mình viết riêng một bài Claude Code là gì. Tài liệu gốc nằm ở trang hướng dẫn chính thức của Anthropic.
Mỗi việc tự động phải tự chứng minh
Mỗi việc giao cho máy phải kèm một cách chứng minh nó vừa chạy thật. Log không tính. Log là thứ dễ giả nhất trong nhà: một cron job đã chết vẫn để lại file log trông hoàn toàn bình thường.
Chứng minh là một dấu vết mà nếu việc không chạy thì nó biến mất. Dấu vết đó có thể là một screenshot mới, hoặc một dòng kết quả test kèm exit code thật mà mình đọc được bằng mắt.
Vì vậy mình đo chất lượng tự động hoá công việc bằng AI bằng số việc mình chứng minh được là nó vừa chạy. Số việc đã giao cho máy không nói lên gì.
Ai không nên làm theo
Nếu bạn làm một mình và chưa có quy trình kiểm chứng, đừng bắt đầu bằng tự động hoá công việc bằng AI.
Máy không sửa được một quy trình hỏng. Nó nhân bản quy trình đó lên, nhanh hơn và im lặng hơn. Cái sai của bạn kịp ra kết quả trước khi bạn kịp nhìn thấy nó.
Thứ tự mình khuyên: làm tay cho tới khi bạn biết việc nào đúng, việc nào sai. Rồi mới xếp nhóm. Rồi mới giao máy, bắt đầu từ nhóm 1.
Còn nếu bạn đã có chỗ kiểm chứng, hôm nay hãy mở danh sách việc ra và đánh số nhóm cho từng dòng. Việc nào bạn không điền nổi câu "sai thì ai phát hiện", việc đó ở lại trong tay bạn thêm một thời gian.



