Ba tiếng làm việc với một AI agent trên dự án thật: nhật ký và số đo

Ký sự này đo từ hai nguồn có thể kiểm lại: lịch sử git của dự án blog này và lịch sử trò chuyện giữa người viết và AI agent (Claude Code). Không có số liệu nào được dựng lại.

Giới hạn nói trước: đây là một buổi làm việc, một dự án, một cặp người và agent, không có nhóm đối chứng. Ký sự cho thấy một bức tranh cụ thể, không chứng minh điều gì về mọi dự án.

---

Tóm tắt nhanh#

• Trong 3 giờ 18 phút giữa commit đầu và commit cuối, agent đã cùng người đưa ra 12 commit, tổng cộng 6.922 dòng được thêm hoặc xóa.
• Người gửi 33 tin nhắn: 11 lệnh commit, 7 yêu cầu việc mới và 15 tin báo lỗi hoặc yêu cầu làm lại (khoảng 45%).
• 7 trong 12 commit là sửa lại sau phản hồi, nhưng chúng chỉ gồm 323 dòng, tức khoảng 4,7% số dòng thay đổi. Lỗi nhỏ, nhưng tốn nhiều vòng.
• Lỗi người phát hiện phần lớn là điều mắt nhìn thấy: ô nằm lồng trong ô, chấm tròn bị cắt, chữ lọt sai ngôn ngữ, câu chữ cứng. Ít nhất bốn lỗi lọt qua kiểm tra tự động vì lúc đó chưa có phép kiểm đúng loại.
• Một lần agent sửa sai chỗ: nó di chuyển một nhãn trong khi nguyên nhân thật nằm ở khung ảnh. Đo trước khi sửa mới ra nguyên nhân.
• Bài học thực tế: mỗi lỗi nên để lại một phép kiểm mới và một dòng trong sổ tay của dự án.

---

1. Bối cảnh#

Dự án là blog tĩnh cá nhân này: nội dung Markdown, một bộ sinh trang viết tay, ba ngôn ngữ (Việt, Anh, Nhật) và các bộ slide. Trong buổi làm việc, người viết giao việc cho agent bằng tin nhắn, agent đọc và sửa file, chạy build, chạy script kiểm tra, rồi người xem kết quả trên trình duyệt và nhắn lại. Commit chỉ được tạo khi người ra lệnh.

Điều này khác với "agent chạy một mình cả đêm". Đây là kiểu người ngồi cạnh, phản hồi liên tục. Hãy nhớ khi đọc các con số.

---

2. Nhật ký các commit#

Thời gian lấy từ lịch sử git (giờ địa phương, cùng một ngày). "Loại" là tiền tố của commit.

Bốn bản giao lớn (11:26, 12:49, 14:15 và bản đầu 11:08) đều có sửa theo sau. Sau bộ slide nhóm, lần sửa đầu đến sau 6 phút. Sau gói SEO, lần sửa đầu đến sau 7 phút và lần sửa đúng nguyên nhân đến sau 11 phút.

---

3. Số đo#

Cách phân loại tin nhắn: "báo lỗi hoặc làm lại" là tin nói rằng kết quả vừa giao có lỗi, khó hiểu hoặc chưa đúng ý. "Việc mới" là yêu cầu thêm nội dung hay tính năng. Phân loại do tay, có thể có tranh luận ở vài tin.

Điều đáng chú ý nhất là tỷ lệ 7 trên 12 commit so với 4,7% số dòng. Phần lớn công sức nằm ở số vòng quay lại, không nằm ở khối lượng chữ.

---

4. Mười một lỗi người phát hiện#

Đây là các lỗi tiêu biểu mà người nhìn thấy trước agent. Cột cuối cho biết gốc rễ.

Phân nhóm: 4 lỗi về chữ, 2 về ngôn ngữ, 2 về điều nhìn thấy, 1 về trải nghiệm, 1 về thẩm mỹ, 1 về chẩn đoán sai nguyên nhân.

Điều đáng nói: không lỗi nào trong số này là lỗi logic của chương trình. Chúng nằm ở chỗ kết quả trông ra sao với một con mắt, nơi agent không có mắt để nhìn nếu người không cho nó ảnh, và nơi kiểm tra tự động chưa được dạy để nhìn.

---

5. Kiểm tra tự động có bắt được không?#

Agent có viết các script kiểm tra: kiểm bố cục slide (chữ tràn, đè nhau, tiêu đề xuống dòng), và sau đó kiểm chữ lọt ngôn ngữ. Những script này bắt được nhiều lỗi trước khi người thấy. Nhưng ít nhất bốn lỗi trong bảng trên lọt qua vì lúc đó chưa có phép kiểm đúng loại:

• Lỗi 7, 8, 10 và 11: kiểm tra bố cục báo "ổn" hoặc chưa tồn tại, nhưng người vẫn thấy sai. Kiểm tra bố cục không hỏi "chữ có lọt sai ngôn ngữ không", "trang có nêu đúng chủ đề không" hay "chấm tròn có bị cắt khi chuyển động không".

Mỗi lần như vậy, phản ứng đúng là thêm một phép kiểm mới: bước quét chữ lọt ngôn ngữ, phép đo khoảng cách giữa chấm tròn và nhãn ở bốn độ rộng, quy tắc "tiêu đề phải nêu chủ đề". Kiểm tra tự động tăng dần theo lỗi người gặp.

Lỗi số 11 đáng đọc kỹ. Phép đo khoảng cách báo không đè nhau, nhưng thủ phạm lại là khung SVG cắt hình khi chấm nhảy lên. Chỉ khi tái hiện lỗi ở đỉnh chuyển động và so hình với khung mới ra nguyên nhân. Bài học: đo trước khi sửa, và tái hiện đúng tình huống lỗi.

Đây cũng là cùng mô hình trong bài vì sao không nên tin AI tuyệt đối: kết quả trông hoàn chỉnh, kiểm tra nội bộ báo ổn, và người nhìn vào mới thấy điều sai.

---

6. Sáu điều rút ra#

1. Phản hồi của người chủ yếu về điều nhìn thấy và cảm nhận. Hình, chữ, tên gọi, bố cục. Hãy chuẩn bị cho agent cách xem được kết quả (ảnh chụp, đo bằng script) thay vì chờ người chỉ ra.
2. Chi phí nằm ở số vòng, không ở số dòng. Bảy commit sửa chỉ 323 dòng. Nếu muốn giảm chi phí, giảm số lần quay lại bằng cách nêu rõ "xong là thế nào" từ đầu.
3. Kiểm tra tự động chỉ bắt thứ nó được dạy bắt. Sau mỗi lỗi, thêm một phép kiểm. Nếu không, lỗi cùng loại sẽ quay lại.
4. Đo trước khi sửa. Lần sửa chấm tròn đầu tiên sai chỗ vì dựa vào phỏng đoán đầu tiên nghe hợp lý. Tái hiện lỗi ở trạng thái xấu nhất.
5. Agent làm theo chữ. Khi người nói "thay vì A, đang hướng tới B", agent chép lại nguyên văn thành tiêu đề. Hãy yêu cầu diễn đạt lại thay vì sao chép đề bài.
6. Ghi bài học vào sổ tay của dự án. Mỗi lỗi lặp lại thành một dòng trong tệp hướng dẫn (xem bài sổ tay cho AI). Dự án này hiện có bốn bộ hướng dẫn riêng và một tệp ghi chú chung, gần như mỗi mục sinh ra từ một lỗi ở trên.

---

7. Giới hạn của ký sự này#

• Một buổi, một dự án, một cặp. Không thể suy ra mức độ chung. Dự án là blog nội dung và giao diện, nơi lỗi nhìn thấy chiếm nhiều. Một dự án backend sẽ cho bức tranh khác.
• Không có đối chứng. Không biết nếu người tự làm một mình thì mất bao lâu, nên không kết luận agent nhanh hay chậm hơn. Bài về nghiên cứu METR đã nhắc: cảm giác nhanh không đồng nghĩa với nhanh.
• Phân loại thủ công. Tin nhắn và lỗi được phân loại bằng tay, một người khác có thể xếp khác đi vài mục.
• Thời gian lấy từ commit. Phiên làm việc thực tế dài hơn khoảng giữa hai commit, vì commit chỉ tạo khi người ra lệnh.
• Điều không đo: thời gian người dành để nhìn và gõ phản hồi, chất lượng bài viết theo người đọc, và chi phí dùng agent.

---

8. Hãy tự đo ở dự án của bạn#

Một bảng ghi nhỏ đủ để có số của riêng bạn. Mỗi việc giao cho agent là một dòng:

Kèm hai lệnh:

git log --format='%h %ad %s' --date=format:%H:%M --shortstat
git diff --shortstat <commit-trước-buổi-làm-việc> HEAD

Sau một tuần, đọc ba con số: bao nhiêu việc qua nhiều hơn hai vòng sửa, loại lỗi nào lặp lại nhiều nhất, và ai phát hiện phần lớn lỗi. Ba con số đó cho biết nên đầu tư vào kiểm tra tự động, vào sổ tay, hay vào cách giao việc.

---

9. Kết luận#

Trong ba tiếng, agent làm ra khối lượng lớn nhanh chóng, và người phải quay lại sửa nhiều lần trên những chi tiết nhỏ mà chỉ mắt người nhìn thấy. Cả hai điều cùng đúng. Giá trị của việc ngồi cạnh agent nằm ở chỗ biến mỗi lần sửa thành một phép kiểm hoặc một dòng sổ tay, để lần sau lỗi đó không cần người chỉ ra nữa.

Ký sự này chỉ là một mẫu, nhưng cách đo thì dùng lại được. Nếu bạn ghi lại một tuần của mình, những con số đó sẽ nói điều mà không báo cáo nào của người khác nói thay bạn được.

---

Nguồn tham khảo#

Số liệu lấy từ lịch sử git của kho mã dự án này (các commit từ 3791938 đến ec1bc85) và lịch sử trò chuyện của buổi làm việc. Bài viết liên quan trong kho:

• Vì sao không nên tin AI tuyệt đối (có nguồn về nghiên cứu METR, Stack Overflow Developer Survey 2025 và các nghiên cứu về mã do AI viết)
• Làm việc nhóm IT thời AI (có nguồn về Faros AI và DORA 2025)
• Duyệt code do AI viết
• Sổ tay cho AI

Tài liệu bên ngoài:

• git log và git diff (tài liệu chính thức, nguồn của các lệnh dùng để đo ở mục "Tự đo")
• Faros AI: nghiên cứu năng suất AI trong phòng thí nghiệm và ngoài thực tế và DORA 2025 là hai nguồn quy mô lớn để đối chiếu. Bài này chỉ là một mẫu nhỏ, không thay thế được chúng.