Dành cho bất kỳ ai muốn thử đóng góp cho một dự án mã nguồn mở, kể cả người mới và người dùng AI nhiều. Không cần biết trước quy trình của cộng đồng. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần ví dụ git được đánh dấu để bỏ qua nếu bạn chưa cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay dự án thật. Bài không kể trải nghiệm đóng góp cá nhân của tôi, vì tôi không có trải nghiệm đó để kể. Phần ví dụ git được tôi chạy thật trên một kho thử trên máy. Cách các mô hình AI hoạt động bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ.

Tóm tắt nhanh#

• Người duy trì (maintainer) dự án mã nguồn mở đang nhận nhiều đóng góp kém chất lượng do AI sinh ra. Khảo sát của Linux Foundation Research (20/10/2026) ghi nhận người duy trì ước tính khoảng 25% pull request là "rác AI" (AI slop), và 31% ở dự án lớn.
• Một ví dụ cụ thể: dự án curl dừng chương trình thưởng lỗi từ cuối tháng 1/2026. Người duy trì chính cho biết tỷ lệ báo cáo lỗi bảo mật có thật rơi từ trên 15% xuống dưới 5%.
• Cách làm không làm phiền họ nằm trong bốn tuần: tuần 1 đọc và dùng dự án, tuần 2 chọn một việc nhỏ đã được chấp nhận và hỏi trước, tuần 3 làm một thay đổi nhỏ có test mà bạn tự giải thích được không cần AI, tuần 4 mở pull request rõ ràng, khai báo AI và nhận phản hồi bình tĩnh.
• Mỗi dự án có luật riêng và luật đổi nhanh. Có dự án cho dùng AI với điều kiện khai báo và hiểu, có dự án cấm hẳn. Bạn phải đọc luật của đúng dự án đó, không dựa vào bài này.
• Trong ví dụ git chạy thật của bài (Git 2.56.0), một thay đổi nhỏ đi qua ba bước: test trước, sửa sau, rồi sửa lại theo phản hồi. Lần chạy đầu của tôi còn báo "NO TESTS RAN", một lý do để luôn ghi số test đã chạy.
• Bị từ chối là chuyện thường. Mục tiêu bốn tuần không phải là được merge bằng mọi giá, mà là làm đúng cách để lần sau có người muốn đọc bài của bạn.

Từ khó, nói dễ#

Sau bài này bạn giải thích được#

1. Vì sao người duy trì dự án mã nguồn mở khó chịu với đóng góp do AI sinh, và chính sách của họ có thể khác nhau hoàn toàn.
2. Thứ tự bốn tuần: đọc luật, hỏi trước, sửa nhỏ có test và hiểu từng dòng, rồi mới mở PR và khai báo AI.
3. Cách dùng git cho luồng này: nhánh riêng, commit có test, rebase khi dự án đã đi tiếp, sửa lại sau phản hồi.

1. Hình dung trước: bạn là khách trong xưởng của người khác#

Hình dung một xưởng mộc nhỏ do một người chủ trông coi, mở cửa cho khách ghé thăm. Một vị khách bước vào và nói: "Tôi thấy chỗ này có thể làm đẹp hơn", rồi mang theo một xe đồ tự làm, tự đặt vào ba bốn góc xưởng. Có thể đồ tốt. Nhưng chủ xưởng phải xem từng món, dọn chỗ, và nếu hỏng thì ông phải chịu. Một vị khách khác đến, ngồi xem một tuần, hỏi: "Tôi giúp mài giùm cái ghế này được không?", rồi mài đúng một cái ghế và đưa ra xem. Chủ xưởng sẽ nhớ cái tên thứ hai.

Mã nguồn mở cũng vậy. Người duy trì thường là người làm việc ngoài giờ hoặc không lương. Mỗi pull request là một món đồ họ phải kiểm. AI làm cho việc gửi món đồ rẻ đi rất nhiều, nhưng việc kiểm thì vẫn tốn thời gian của người duy trì.

Điều rút ra: việc đóng góp tốt không đo bằng số dòng bạn gửi mà bằng mức độ bạn làm cho người duy trì dễ nói đồng ý.

2. Vì sao người duy trì đang quá tải#

2.1 Khảo sát của Linux Foundation Research (20/10/2026)#

Linux Foundation Research công bố báo cáo "Navigating Open Source Software Development in the Generative AI Era: Challenges and Opportunities for Project Communities" ngày 20/10/2026. Theo thông cáo của họ, người duy trì ước tính khoảng 25% pull request đến là rác do AI sinh, và 31% ở các dự án lớn. Cũng theo thông cáo: 59% người duy trì thấy lượng đóng góp tăng (69% ở dự án lớn), khoảng 35% dự án có chính sách chính thức cho phép dùng AI, 32% chưa có chính sách và chưa định có, và 61% người đóng góp nói họ xem xét kỹ và kiểm thử đầy đủ code do AI sinh trước khi gửi. Thông cáo cũng ghi người trả lời ước tính AI giảm trung bình khoảng 52% thời gian viết code.

Cần đọc cho đúng. Đây là ước tính của người trả lời khảo sát, không phải số đếm pull request. Số người trả lời không được nêu trong thông cáo tôi đọc. Tôi chỉ đọc thông cáo, chưa đọc cả báo cáo. Mẫu có thể thiên về những người chịu trả lời khảo sát.

Điều rút ra: vấn đề có thật và được đo, nhưng phần lớn dự án chưa có luật rõ. Bạn phải tự đi tìm luật.

2.2 Một dự án làm ví dụ: curl dừng chương trình thưởng lỗi#

Daniel Stenberg, người duy trì chính của curl, viết trong bài "The end of the curl bug-bounty" ngày 26/1/2026 rằng curl không còn chương trình thưởng lỗi, chương trình dừng từ 31/1/2026. Ông nêu rằng trước năm 2025, tỷ lệ báo cáo được xác nhận là lỗ hổng thật là "trên 15%", và từ 2025 là "dưới 5%", tức không tới một trên hai mươi báo cáo là thật. Ông cho rằng lý do gồm báo cáo rác do AI sinh, báo cáo kém chất lượng do người viết, và thái độ thiếu thiện chí của một số người, và ông ngờ rằng phần thưởng tiền mặt đã thu hút kiểu lạm dụng đó. Ông cũng nói người gửi báo cáo rác do AI tiếp tục bị cấm.

Điều này mô tả một dự án và là quan sát của người trong cuộc. Nó không chứng minh mọi dự án đều như vậy, và phần thưởng tiền có thể là yếu tố riêng của curl.

Điều rút ra: khi người nhận bị ngập, họ rút bớt cửa. Cửa đóng lại thì cả người đóng góp tốt cũng chịu.

2.3 GitHub cho người duy trì thêm công cụ#

Ngày 13/2/2026 GitHub thêm hai cài đặt cho kho mã: tắt hẳn pull request, hoặc chỉ cho người có quyền ghi mở pull request mới (mọi người vẫn đọc và bình luận được). Hai cài đặt nằm ở Settings, General, Features. Theo một bài blog Nhật mà tôi tìm thấy, có người thử và thấy cài đặt "chỉ người cộng tác" chưa hoạt động đúng như mô tả vào thời điểm đó, nên hãy coi đây là thông tin có thể đã thay đổi. GitHub cũng được tin là đã thêm giới hạn số pull request mở cùng lúc cho người không có quyền ghi (tháng 6/2026, tôi chỉ thấy qua bài tin).

Điều rút ra: một số kho sẽ không nhận pull request từ người lạ. Việc đầu tiên là biết kho đó có nhận không.

2.4 Một chính sách thật: Ghostty#

Để thấy chính sách cụ thể có thể nghiêm đến đâu, tôi đọc tệp CONTRIBUTING.md và tệp AI_POLICY.md của dự án Ghostty. Tôi chỉ nêu điều đọc được ở thời điểm đọc, và chính sách có thể đã đổi khi bạn đọc bài. Theo hai tệp đó: dự án cho phép dùng AI để viết code, nhưng yêu cầu khai báo mọi việc dùng AI (nêu công cụ và mức độ), yêu cầu người đóng góp hiểu toàn bộ code mình gửi và giải thích được nó mà không cần AI, và người lần đầu đóng góp phải được "vouch" (bảo lãnh) trước, nếu không pull request sẽ bị tự động đóng. Dự án cũng có danh sách công khai những người bị từ chối vì gửi đóng góp rác. Chính sách này chỉ áp cho người ngoài, không áp cho người duy trì.

Đây chỉ là một dự án. Dự án khác có thể cho tự do hơn, hoặc cấm hẳn đóng góp do AI sinh. Bài này không dựa vào dự án nào ngoài ví dụ đã đọc ở trên.

Điều rút ra: luật của dự án nằm ở chính dự án. Câu hỏi đầu tiên không phải "làm gì" mà là "ở đây họ quy định thế nào".

3. Kế hoạch bốn tuần#

Hình dung bốn lần ghé xưởng: lần một đi xem, lần hai hỏi, lần ba làm, lần bốn đưa ra. Thời gian dưới đây là gợi ý, khoảng vài giờ mỗi tuần.

Tuần 1. Đọc và dùng dự án#

Việc làm:

1. Chọn một dự án bạn đang dùng thật. Dự án bạn chưa dùng thì bạn khó biết thế nào là hữu ích.
2. Đọc README, CONTRIBUTING, CODE_OF_CONDUCT và, nếu có, chính sách về AI. Tìm xem dự án có nhận pull request từ người lạ không.
3. Đọc khoảng năm pull request đã được nhận và năm pull request bị đóng. Chú ý cách người ta viết mô tả và lý do bị đóng.
4. Cài và chạy dự án trên máy, chạy bộ test của dự án một lần.

Mang đi: năm dòng "luật chơi của dự án này" do bạn tự viết, kèm lệnh chạy test.

Tuần 2. Chọn một việc nhỏ đã được chấp nhận và hỏi trước#

Việc làm:

1. Tìm issue có nhãn gợi ý cho người mới (ví dụ good first issue) và chưa ai nhận.
2. Đọc kỹ issue và các bình luận. Một issue được người duy trì xác nhận mới đáng làm.
3. Bình luận xin nhận việc, nêu cách bạn dự định làm trong hai ba câu, và chờ phản hồi trước khi viết code.
4. Nếu chờ nhiều ngày mà chưa ai trả lời, đừng làm ngay một thay đổi lớn. Hỏi lại hoặc chọn việc khác.

Mang đi: một bình luận ngắn, lịch sự và rõ ràng, được người duy trì trả lời.

Tuần 3. Làm một thay đổi nhỏ có test và tự hiểu được#

Việc làm:

1. Tạo nhánh riêng. Viết một test thất bại để tái hiện vấn đề, rồi sửa cho test đạt.
2. Giữ một mục đích duy nhất. Không sửa thêm định dạng hay đổi tên hàng loạt trong cùng PR.
3. Chạy toàn bộ test của dự án và ghi số test đã chạy.
4. Dùng AI được nếu dự án cho phép, nhưng làm bài kiểm tra này: tắt AI và giải thích thành lời từng dòng bạn đổi, cho người khác hoặc cho chính bạn. Chỗ nào bạn không giải thích được thì bạn chưa hiểu, và chưa sẵn sàng gửi.

Mang đi: một nhánh với một commit sạch, có test chạy được.

Tuần 4. Mở PR rõ ràng, khai báo AI, nhận phản hồi bình tĩnh#

Việc làm:

1. Viết mô tả PR theo mẫu ở phần 5: vấn đề, cách sửa, cách kiểm, và dòng khai báo AI theo đúng yêu cầu của dự án.
2. Tự duyệt diff của chính mình trước khi gửi (xem Duyệt code do AI viết).
3. Khi nhận phản hồi, trả lời ngắn, sửa đúng điều được yêu cầu, và nếu dự án đã đi tiếp thì rebase.
4. Nếu bị từ chối, cảm ơn, hỏi lại nếu chưa rõ, và đừng tranh luận.

Mang đi: một PR mà người duy trì mở ra thấy ngay mục đích và cách kiểm.

4. Ví dụ chạy thật: luồng git của một đóng góp nhỏ (có thể bỏ qua nếu bạn chưa dùng git)#

Hình dung bạn tập trong một xưởng giả trước khi vào xưởng thật. Tôi dựng một "xưởng giả" ngay trên máy: một kho bare làm "kho gốc của dự án", và một bản sao làm "fork của bạn". Mọi lệnh dưới đây tôi đã chạy thật bằng Git 2.56.0 và Python 3.14.8. Hash commit sẽ khác trên máy bạn.

Lưu ý: đây không phải GitHub. Trên GitHub, bạn bấm Fork trên web, đẩy nhánh lên fork của mình rồi mở pull request trên web. Phần chung là các lệnh git: tạo nhánh, commit, rebase, sửa lại. Trong ví dụ, "dự án" là một thư viện nhỏ tên textkit có hàm slugify biến tiêu đề thành đoạn ngắn dùng trong địa chỉ web. "Vấn đề" là slugify("Hello World!") trả về hello-world- có dấu gạch thừa ở cuối.

4.1 Trước khi sửa: chạy test, tạo nhánh#

$ python3 -m unittest -q
Ran 1 test in 0.000s

OK

$ git switch -c fix-slug-trailing-dash

Một lần chạy đầu bị lỗi ngầm. Lần chạy đầu của tôi in ra "Ran 0 tests" và "NO TESTS RAN", vì thư mục tests thiếu tệp __init__.py nên bộ chạy test không tìm thấy gì. Không có dòng nào đỏ, chỉ không có test nào chạy. Đây đúng là lý do bài Làm cho kết quả của AI tự chứng minh khuyên luôn ghi số test đã chạy: "không có lỗi" chưa chắc là "đã kiểm".

4.2 Viết test thất bại trước#

Tôi thêm test cho ca có dấu chấm than và khoảng trắng ở hai đầu, rồi chạy khi chưa sửa:

$ python3 -m unittest -q
FAIL: test_no_trailing_dash (tests.test_slug.SlugTests.test_no_trailing_dash)
Traceback (most recent call last):
  File "tests/test_slug.py", line 10, in test_no_trailing_dash
    self.assertEqual(slugify("Hello World!"), "hello-world")
AssertionError: 'hello-world-' != 'hello-world'

Ran 2 tests in 0.000s

FAILED (failures=1)

Test thất bại đúng vì lý do mong đợi. Nếu test đạt ngay khi chưa sửa, hoặc thất bại vì lý do khác, test đang kiểm cái gì đó không phải vấn đề của bạn.

4.3 Sửa và chạy lại#

$ python3 -m unittest -q
Ran 2 tests in 0.000s

OK

$ git diff --stat
 tests/test_slug.py | 4 ++++
 textkit/slug.py    | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

Hai tệp, năm dòng thêm và một dòng đổi: đủ nhỏ để người duy trì xem trong vài phút.

4.4 Commit có mô tả rõ và dòng khai báo#

fix(slug): strip leading and trailing dashes

slugify("Hello World!") returned "hello-world-". Strip dashes at both
ends and add a test for punctuation and surrounding spaces.

AI assistance: used an AI tool to draft the test; I read and ran it.

Dòng cuối là cách một dự án có thể yêu cầu khai báo. Hãy dùng đúng cách của dự án bạn đóng góp, không phải mẫu này.

4.5 Dự án đã đi tiếp: fetch và rebase#

Trong lúc bạn làm, người duy trì đẩy thêm một commit lên nhánh chính. Bạn lấy về và dời thay đổi của mình lên trên bản mới nhất:

$ git fetch origin
$ git log --oneline --graph --all
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

$ git rebase origin/main
Successfully rebased and updated refs/heads/fix-slug-trailing-dash.

$ git log --oneline --graph --all
* ea41359 fix(slug): strip leading and trailing dashes
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

Cùng một thay đổi nhưng hash đổi (từ 0606d8e sang ea41359) vì nó nay nằm trên một nền mới. Commit cũ 0606d8e còn nằm ở nhánh đã đẩy lên trước đó.

4.6 Phản hồi từ người duyệt: sửa lại và đẩy bản mới#

Giả sử người duyệt xin thêm một test cho chuỗi rỗng. Tôi thêm test, chạy, rồi sửa lại commit cũ thay vì thêm commit chữa cháy:

$ python3 -m unittest -q
Ran 3 tests in 0.000s

OK

$ git commit --amend --no-edit
$ git push --force-with-lease origin fix-slug-trailing-dash
 + 0606d8e (cũ), d109624 (mới): nhánh fix-slug-trailing-dash (forced update)

$ git diff origin/main --stat
 tests/test_slug.py | 7 +++++++
 textkit/slug.py    | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

Git thật in một dòng nối hai hash cũ và mới bằng ký hiệu riêng; tôi viết lại cho dễ đọc, kết quả là hash 0606d8e được thay bằng d109624 trên máy chủ. --force-with-lease chỉ ghi đè khi nhánh trên máy chủ đúng như bạn nghĩ. Chỉ dùng nó trên nhánh của chính bạn (nhánh PR), tuyệt đối không dùng trên nhánh chính của dự án. Một số dự án muốn bạn thêm commit mới thay vì sửa lại, nên hãy xem hướng dẫn của dự án.

4.7 Một cách khác: tạo tệp vá#

Một số cộng đồng nhận thay đổi dưới dạng tệp vá gửi qua thư:

$ git format-patch -1 -o ../patches
../patches/0001-fix-slug-strip-leading-and-trailing-dashes.patch

Cách này ít gặp hơn trên GitHub nhưng vẫn dùng ở nhiều dự án lớn. Dự án nào dùng cách nào sẽ ghi trong CONTRIBUTING.

Ghi chú về ví dụ: đây là kho thử một người, không có người duyệt thật và không có giao diện web. Nó chứng minh các lệnh chạy được và cho ra kết quả như đã dán, không chứng minh một cuộc trao đổi thật diễn ra thế nào.

5. Mẫu mô tả PR và danh sách tự kiểm#

5.1 Mẫu mô tả pull request#

## Vấn đề
Một hai câu: cái gì sai, khi nào gặp. Dẫn tới issue (Closes #123).

## Cách sửa
Một hai câu: bạn đổi cái gì và vì sao chọn cách này.

## Cách kiểm
- Lệnh chạy test: python3 -m unittest
- Số test đã chạy: 3, tất cả đạt
- Test mới thất bại trước khi sửa: có

## Khai báo AI
Theo yêu cầu của dự án: có dùng AI không, công cụ nào, ở phần nào.
Tôi đã đọc, chạy và hiểu toàn bộ thay đổi.

5.2 Danh sách tự kiểm sáu câu trước khi bấm gửi#

1. Tôi có giải thích được từng dòng thay đổi mà không cần AI không?
2. Tôi đã chạy toàn bộ test của dự án và biết số test đã chạy chưa?
3. PR này có một mục đích duy nhất không?
4. Tôi đã đọc CONTRIBUTING và chính sách AI của dự án chưa, và làm đúng chưa?
5. Việc này đã được người duy trì chấp nhận trong issue chưa?
6. Mô tả có nói rõ cách kiểm để người duyệt làm theo được không?

Nếu có câu trả lời "không", hãy dừng và làm nốt trước khi gửi.

6. Lỗi hay gặp#

Hình dung vị khách trong xưởng: có những việc khách làm khiến chủ xưởng thở dài.

7. Minh họa: hai buổi sáng với cùng một issue#

Đây là tình huống minh họa, không nhắc đến người hay dự án thật. Hai người đóng góp cùng thấy một issue nhỏ.

Người thứ nhất không đọc luật:

• 09:00. Mở issue, thấy "việc dễ", nhờ AI sinh code.
• 09:40. AI sinh thay đổi 600 dòng, trong đó có định dạng lại ba tệp và một đoạn tối ưu thêm. Người đóng góp chưa đọc hết, mở PR, không có dòng khai báo AI.
• 14:00. Người duy trì đóng PR kèm lời nhắc đọc CONTRIBUTING: việc này chưa được chấp nhận và quá lớn. Người đóng góp mất một buổi sáng và không biết sai ở đâu.

Người thứ hai theo kế hoạch bốn tuần:

• 09:00. Đọc CONTRIBUTING, thấy dự án yêu cầu khai báo AI và hỏi trước khi làm.
• 09:20. Bình luận xin nhận việc, nêu cách sửa trong hai câu.
• Hôm sau, 10:00. Người duy trì trả lời "Ổn, cứ làm".
• Hôm sau, 15:00. Viết test thất bại trước, sửa, chạy toàn bộ test, đọc lại từng dòng không cần AI, rồi mở PR chỉ thêm khoảng 8 dòng, có dòng khai báo.
• Ngày thứ ba, 09:00. Người duyệt xin thêm một test, người đóng góp sửa lại trong 15 phút.

Việc nên làm: chặn mình ở bước hỏi trước và bước tự giải thích. Hai bước này tốn khoảng nửa giờ, nhưng thường tiết kiệm cho cả hai phía cả buổi sáng.

Minh họa này không thay cho bằng chứng. Bằng chứng nằm ở khảo sát của Linux Foundation và trường hợp curl ở phần 2: người duy trì thật đang chịu tải lớn và đang đóng cửa, nên một đóng góp dễ duyệt là món quà thật. Hai nguồn này là ước tính và kể lại của người trong cuộc, không phải thí nghiệm đối chứng.

8. Bài tập có đáp án#

Bài tập A. Tìm lỗi trong mô tả PR#

Mô tả sau là của một PR: "Fix stuff. Đã sửa lỗi, dùng AI cho nhanh. Đổi luôn định dạng toàn bộ thư mục. Đã test."

Tìm ít nhất năm điểm yếu.

Đáp án: (1) không nói vấn đề cụ thể và không dẫn tới issue; (2) "dùng AI cho nhanh" chưa nêu công cụ, phần nào, cũng chưa nói đã đọc và hiểu; (3) đổi định dạng toàn thư mục là một mục đích thứ hai, tách riêng; (4) "đã test" không nêu lệnh, số test, hay test mới có thất bại trước khi sửa không; (5) không có cách để người duyệt tự kiểm; (6) tiêu đề "Fix stuff" không nói gì.

Bài tập B. Hỏi trước hay làm ngay?#

Trong kho thử, slugify("Xin chào") trả về xin-ch-o (tôi đã chạy thật). Bạn thấy chữ có dấu bị mất. Bạn nên mở PR sửa ngay hay bình luận hỏi trước?

Đáp án: nên hỏi trước. Cách xử lý chữ có dấu là một quyết định thiết kế: bỏ dấu (xin-chao), giữ nguyên, hay chuyển ký tự. Người duy trì có thể có lý do giữ hành vi hiện tại hoặc muốn một cách khác. Mở PR ngay có thể bị đóng dù code của bạn chạy đúng. Bình luận hai ba câu nêu hiện tượng, vài lựa chọn và hỏi họ muốn hướng nào là đủ.

Bài tập C. Test đạt ngay khi chưa sửa#

Bạn thêm test slugify("Hello---World") == "hello-world". Chạy ngay thì đạt trước khi sửa gì (tôi đã chạy thật). Bạn nên làm gì?

Đáp án: đây không phải lỗi. Hàm đã gom các dấu gạch liên tiếp thành một. Một test đạt sẵn có thể vẫn đáng thêm như bảo vệ hành vi hiện có, nhưng không phải là bằng chứng bạn đã sửa lỗi, và không nên đóng gói như một "bản sửa". Hãy xem lại vấn đề thật là gì.

9. Nhìn cân bằng: biết gì, chưa biết gì#

Khá chắc: người duy trì báo cáo lượng đóng góp tăng và một phần đáng kể chất lượng thấp; ít nhất một dự án lớn (curl) đã đóng một cửa vì lý do này; một số dự án (như Ghostty) có chính sách rõ về AI.

Chưa rõ hoặc đáng thận trọng:

• Con số 25% và 31% là ước tính của người trả lời khảo sát, không phải số đếm. Tôi chưa đọc toàn bộ báo cáo.
• Trường hợp curl là một dự án, một người trong cuộc, và phần thưởng tiền có thể làm nó khác các dự án không có thưởng.
• Chính sách đổi nhanh. Bài này chỉ nêu những gì tôi đọc được ở thời điểm đọc.
• Tôi chưa thấy nghiên cứu đo trực tiếp việc làm theo kế hoạch bốn tuần có tăng tỷ lệ được merge không. Kế hoạch là tổng hợp thực hành, không phải kết quả thí nghiệm.

Đừng thổi phồng. Không có cách nào đảm bảo PR của bạn được nhận. Dự án có thể từ chối vì lý do chẳng liên quan đến bạn: đang đóng băng phát hành, đổi hướng, hoặc đơn giản là hết sức.

Đừng coi nhẹ. Có dự án cấm hẳn đóng góp do AI sinh. Khi gặp, hãy làm theo, không thử lách.

10. Kết luận#

Đóng góp mã nguồn mở thời AI là một việc của sự tôn trọng: đọc luật trước, hỏi trước, gửi ít và dễ duyệt, và tự hiểu thứ mình gửi. AI giúp bạn viết nhanh hơn, nhưng cũng giúp bạn gửi thứ chưa hiểu nhanh hơn. Bốn tuần ở trên là cách đặt các điểm dừng vào đúng chỗ.

Nếu bạn muốn thực hành luồng git này, hãy làm trong một kho thử trước. Xem thêm Git cho người dùng agent cho các lệnh cứu hộ, Gỡ lỗi như thám tử để tái hiện lỗi trước khi sửa, và Học một thư viện lạ cùng AI mà không mất tay nghề cho cách học một dự án mới mà vẫn giữ tay nghề.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Chính sách của từng dự án có thể đã thay đổi, nên hãy mở nguồn gốc để kiểm tra trước khi làm theo.

• Linux Foundation, thông cáo về khảo sát "Navigating Open Source Software Development in the Generative AI Era" (20/10/2026) và bản tin tóm tắt
• Daniel Stenberg, The end of the curl bug-bounty (26/1/2026)
• GitHub Changelog, New repository settings for configuring pull request access (13/2/2026)
• Ghostty, CONTRIBUTING.md và AI_POLICY.md (đọc tháng 10/2026, chính sách có thể đã đổi)
• Git, tài liệu git-rebase, git-push (--force-with-lease) và git-format-patch

Dành cho bất kỳ ai giao việc cho AI agent, kể cả người mới. Không cần biết gì về quan sát hệ thống hay bảo mật. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần code được đánh dấu để bỏ qua nếu bạn chưa cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Phần ví dụ chạy thật là một mô phỏng do tôi viết bằng Python, không phải nhật ký của một công cụ thương mại. Cách AI quyết định hành động bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ.

Tóm tắt nhanh#

• Khi bạn giao việc cho agent rồi đi họp, bạn không nhìn thấy từng bước nó làm. Nếu không có dấu vết, lúc có chuyện chỉ còn cách đọc lại cả cuộc trò chuyện dài để đoán.
• Nhật ký hành động là một dòng ghi cho mỗi việc agent làm: lúc nào, công cụ hay lệnh gì, kết quả ra sao, tệp nào bị đổi. Mỗi dòng một bản ghi JSON (định dạng JSON Lines) thì tìm kiếm được bằng vài dòng code hoặc lệnh jq.
• Ghi vừa đủ. Không ghi khóa bí mật, dữ liệu cá nhân hay toàn bộ nội dung tệp. Phải che trước khi ghi, vì nhật ký lộ khóa cũng nguy hiểm như code lộ khóa.
• Lớp ghi nên nằm ngoài agent và chỉ cho thêm dòng. Nhật ký mà chính agent sửa được thì không còn là bằng chứng.
• Trong ví dụ chạy thật của bài, 25 hành động tạo ra tệp 7.170 byte. Ba câu hỏi điều tra (dòng thời gian, lỗi đầu tiên, tệp đã đổi) có đáp án ngay khi chạy script, và một dòng bị sửa bị phát hiện.
• Nhật ký cho biết điều gì đã xảy ra, không cho biết điều đó có đúng không. Nó bổ sung chứ không thay cho việc đòi bằng chứng và kiểm thử.

Sau bài này bạn giải thích được#

1. Vì sao một phiên agent không ai xem vẫn cần để lại dấu vết, và dấu vết khác gì cuộc trò chuyện đã lưu.
2. Mỗi dòng nhật ký nên có những trường nào, và những gì tuyệt đối không được ghi.
3. Cách dùng nhật ký sau sự cố: dựng dòng thời gian, tìm lỗi đầu tiên, liệt kê tệp bị đổi, và phát hiện dòng bị sửa.

Từ khó, nói dễ#

1. Hình dung trước: camera cửa hàng và sổ biên nhận#

Hình dung bạn mở cửa hàng và thuê một nhân viên rất nhanh tay. Hôm nay bạn đi vắng. Chiều về, két tiền lệch 200 nghìn. Nếu cửa hàng không có gì ghi lại, bạn chỉ còn cách hỏi nhân viên, và nhân viên có thể trả lời rất thật thà mà vẫn nhớ sai.

Giờ hình dung cửa hàng có hai thứ. Một camera quay lại những gì diễn ra ở quầy. Một cuốn sổ biên nhận ghi từng giao dịch: mấy giờ, bán gì, thu bao nhiêu. Bạn không cần xem cả ngày quay phim. Bạn mở sổ, tìm giao dịch lúc 3 giờ chiều, thấy ngay chỗ lệch. Máy bay cũng vậy: hộp đen ghi lại thao tác để sau tai nạn người ta dựng lại chuyện gì đã xảy ra, dù phi công không còn để hỏi.

Agent làm việc giống nhân viên nhanh tay đó: nó chạy hàng chục lệnh trong vài phút. Cuộc trò chuyện là lời nó kể. Nhật ký hành động là cuốn sổ biên nhận: nó ghi cái đã làm chứ không phải cái đã nói.

Điều rút ra: nhật ký không để bắt lỗi nhân viên. Nó để khi có chuyện, bạn tìm ra nguyên nhân trong vài phút thay vì vài giờ đoán mò.

2. Vì sao phiên không ai xem lại cần dấu vết#

Càng giao việc cho agent, bạn càng ít xem từng bước. Trang giới thiệu báo cáo xu hướng lập trình agent 2026 của Anthropic nói các lãnh đạo kỹ thuật đang cân bằng giữa năng suất với giám sát, chất lượng và bảo mật, và liệt kê chủ đề điều phối nhiều agent. Tôi chỉ đọc được trang giới thiệu, còn bản đầy đủ nằm sau một biểu mẫu đăng ký nên tôi chưa đọc phần thân báo cáo và không trích thêm điều gì từ đó.

Một số liệu khác: khảo sát Stack Overflow 2026 ghi 69,9% người trả lời hỏi một AI agent khi gặp việc lạ (con số tôi đọc qua bản tóm tắt, chưa đối chiếu từng bảng). Nghĩa là agent đã thành một phần việc hằng ngày, và phần việc đó thường diễn ra khi bạn không nhìn.

Khi đó có hai kiểu mất mát. Kiểu một: có sự cố mà không ai biết agent đã chạy lệnh nào, nên điều tra chậm. Kiểu hai: không có sự cố nhưng đồng nghiệp hỏi "sao tệp test bị đổi?" và bạn phải đọc lại cả hội thoại dài để trả lời. Bài Làm cho kết quả của AI tự chứng minh xin bằng chứng nằm trong câu trả lời của agent. Nhật ký bổ sung phần còn lại: bằng chứng nằm ngoài câu trả lời, do một lớp khác ghi lại và agent không viết được.

Điều rút ra: giao việc nhiều thì cần dấu vết nhiều. Dấu vết rẻ hơn việc đọc lại.

3. Ghi gì và không ghi gì#

3.1 Bảy nhóm thông tin nên ghi#

Hình dung tờ biên nhận: ai bán, bán gì, lúc nào, thu bao nhiêu, theo đơn nào.

Thêm một trường prev (dấu vân tay dòng trước) nếu bạn muốn phát hiện dòng bị sửa, như phần 5 sẽ làm.

3.2 Ba thứ không được ghi#

1. Khóa bí mật và mật khẩu. Che trước khi ghi. Nhật ký thường được nhiều người đọc hơn tệp cấu hình, nên một khóa nằm trong nhật ký lan xa hơn một khóa nằm trong .env.
2. Dữ liệu cá nhân của người dùng. Chỉ ghi định danh đã che hoặc mã nội bộ.
3. Toàn bộ nội dung tệp hay kết quả lệnh dài. Ghi tóm tắt (số dòng, số test đạt) và vị trí để mở lại, không ghi cả nội dung. Nhật ký vừa nhỏ gọn vừa ít rủi ro.

Nếu nhóm bạn đã có chính sách dùng AI một trang, hãy để ba điều trên nằm trong cột "cấm" và gắn ngày xem lại cho thời gian lưu nhật ký.

3.3 Một dòng trông như thế nào#

{"seq": 12, "ts": "2026-10-31T09:01:27+07:00", "session": "s-001",
 "actor": "agent", "request": "R2: make the tests pass",
 "tool": "run_command", "args": {"cmd": "python -m pytest -q"},
 "exit_code": 1, "summary": "ran 20 tests, 18 passed, 2 failed",
 "files_changed": [], "prev": "5d5c9ffa0389"}

(Trong tệp thật, mỗi bản ghi nằm trên một dòng duy nhất. Ở đây xuống dòng để dễ đọc.)

Điều rút ra: bảy nhóm thông tin trả lời năm câu hỏi điều tra: ai, cái gì, lúc nào, vì sao, ảnh hưởng đến đâu. Ba thứ cấm giữ cho cuốn sổ không trở thành một chỗ rò rỉ mới.

4. Cơ chế: bốn mắt xích#

Hình dung dây chuyền: hành động, lớp ghi, nơi lưu, truy vấn.

1. Agent hành động. Chạy lệnh, sửa tệp, gọi công cụ.
2. Lớp ghi bắt lại hành động. Lớp này nằm trong công cụ hoặc khung chạy agent, không nằm trong lời nhắc cho agent. Nếu bạn chỉ dặn agent "nhớ tự ghi nhật ký", nó có thể quên hoặc ghi sai.
3. Che bí mật rồi ghi vào nơi chỉ thêm được. Ghi thêm dòng, không mở lại sửa dòng cũ.
4. Truy vấn khi cần. Đọc bằng script hoặc jq.

4.1 Công cụ của bạn có sẵn chỗ để gắn không#

Theo tài liệu hiện hành về hook của Claude Code (tôi đã mở trang này), công cụ cho gắn lệnh chạy trước hoặc sau mỗi lần gọi công cụ. Lệnh nhận một đối tượng JSON qua đầu vào chuẩn (stdin). Các trường tài liệu liệt kê gồm session_id, transcript_path, cwd, hook_event_name, và với sự kiện sau khi gọi công cụ có thêm tool_name, tool_input, tool_response, tool_use_id và duration_ms (không bắt buộc). Có một sự kiện riêng cho trường hợp công cụ thất bại, kèm trường error. Tài liệu cũng nói một hook kết thúc bằng mã 0 và không in quyết định nào thì không làm đổi việc gọi công cụ, còn mã 2 sẽ chặn, nên đừng dùng mã 2 cho việc ghi nhật ký.

Về bản ghi phiên: các đường dẫn ví dụ trong tài liệu kết thúc bằng .jsonl, nên bản ghi phiên được lưu dạng JSON Lines. Tài liệu không nói định dạng bằng lời, nên đây là suy ra từ ví dụ. Tài liệu cũng cho biết tệp bản ghi có thể được ghi với độ trễ.

Đây là một đoạn script ghi nhật ký tôi viết, dùng jq để lấy các trường rồi che khóa:

#!/bin/sh
# Ghi một dòng JSON đã che khóa cho mỗi lần gọi công cụ. Luôn thoát mã 0.
jq -c '{
  ts: (now | todate),
  session: .session_id,
  event: .hook_event_name,
  tool: .tool_name,
  input: (.tool_input | tostring | gsub("sk-[A-Za-z0-9]{8,}"; "[REDACTED]")),
  ms: .duration_ms
}' >> "${TRAIL_FILE:-hook-trail.jsonl}"
exit 0

Tôi chạy script này với một đối tượng JSON giả có cấu trúc giống tài liệu và thấy nó ghi ra một dòng, khóa giả sk-test1234567890abcd bị thay bằng [REDACTED]. Tôi chưa chạy nó bên trong một phiên Claude Code thật. Cú pháp khai báo hook (khóa matcher, nơi đặt trong tệp cấu hình) khác nhau giữa các phiên bản, nên hãy đọc tài liệu bản bạn dùng trước khi gắn.

4.2 Tiêu chuẩn chung: OpenTelemetry#

Nếu bạn thích dùng tiêu chuẩn thay vì tự đặt tên trường, dự án OpenTelemetry có bộ quy ước đặt tên cho tác vụ AI sinh nội dung (gồm hành động của agent và lần gọi công cụ). Theo các bài tổng hợp tôi đọc, bộ này vẫn ở trạng thái "Development" (chưa ổn định), nên tên thuộc tính có thể đổi giữa các phiên bản. Trang chính thức tôi mở chỉ cho biết các quy ước đã được chuyển sang một kho riêng, nên trạng thái "Development" là từ nguồn thứ cấp, hãy kiểm tra ở kho chính thức. Với người mới, bắt đầu bằng JSON Lines tự đặt tên rồi chuyển sau cũng được.

Điều rút ra: lớp ghi nằm ngoài agent, ghi sau mỗi hành động, che bí mật trước khi lưu.

5. Ví dụ chạy thật: 25 hành động, một lỗi, một khóa giả#

Đây là mô phỏng một phiên agent (Python 3.14.8, jq 1.7.1) do tôi viết. Các hành động là dữ liệu dựng sẵn, nhưng lớp ghi, che bí mật, chuỗi băm và truy vấn là code chạy thật, và các kết quả dưới đây là đầu ra thật. Hai script đầy đủ nằm ở phụ lục cuối bài.

Kịch bản (minh họa): agent nhận hai yêu cầu liên tiếp. R1 là thêm giảm giá 10 phần trăm cho phần thanh toán. R2 là làm cho các bài kiểm thử đạt. Trong phiên, agent đọc một tệp .env có khóa giả (API_KEY=sk-test1234567890abcd), chạy kiểm thử thất bại một lần (hành động 12), sửa, chạy lại đạt, rồi commit hai lần.

5.1 Khóa giả đã được che#

Hành động 7 là đọc .env. Dòng ghi lại:

{"actor": "agent", "args": {"path": ".env"}, "exit_code": 0, "files_changed": [], "prev": "2efa822af966", "request": "R1: add a 10 percent discount to checkout", "seq": 7, "session": "s-001", "summary": "loaded [REDACTED] (3 variables)", "tool": "read_file", "ts": "2026-10-31T09:00:13+07:00"}

Tìm chuỗi sk-test trong cả tệp cho kết quả 0 dòng khớp. Phần che là một biểu thức chính quy đơn giản, nên nó chỉ bắt được kiểu khóa bạn đã dự đoán. Hãy coi nó là lớp phòng thủ đầu tiên chứ không phải lớp duy nhất.

Một lỗi tôi gặp khi viết bài này: bản đầu tiên của tôi đổi tham số thành chuỗi JSON rồi mới che. Khi thử thêm một lệnh có password=abc123, mẫu \S+ nuốt luôn dấu ngoặc đóng và dấu nháy, làm dòng ghi bị cụt và script truy vấn báo lỗi khi đọc. Cách sửa là che từng giá trị chuỗi trước khi đổi sang JSON, như hàm redact trong script bên dưới.

5.2 Dòng thời gian#

== timeline ==
 1 09:00:03 read_file    exit=0 src/checkout.py
 2 09:00:05 read_file    exit=0 src/pricing.py
 3 09:00:07 search       exit=0 discount
 4 09:00:09 read_file    exit=0 tests/test_discount.py
 5 09:00:10 run_command  exit=0 git status --short
 6 09:00:11 run_command  exit=0 git switch -c agent/discount
 7 09:00:13 read_file    exit=0 .env
 8 09:00:33 edit_file    exit=0 src/pricing.py
 9 09:00:45 edit_file    exit=0 src/checkout.py
10 09:00:54 run_command  exit=0 python -m pytest -q
11 09:01:19 edit_file    exit=0 tests/test_discount.py
12 09:01:27 run_command  exit=1 python -m pytest -q
13 09:01:29 read_file    exit=0 tests/test_discount.py
14 09:01:44 edit_file    exit=0 src/pricing.py
15 09:01:52 run_command  exit=0 python -m pytest -q
16 09:01:53 run_command  exit=0 git diff --stat
17 09:01:54 run_command  exit=0 git add -A
18 09:01:56 run_command  exit=0 git commit -m 'feat: add 10 percent discount'
19 09:01:58 read_file    exit=0 README.md
20 09:02:08 edit_file    exit=0 README.md
21 09:02:09 run_command  exit=0 git add README.md
22 09:02:11 run_command  exit=0 git commit -m 'docs: mention discount'
23 09:02:19 run_command  exit=0 python -m pytest -q
24 09:02:20 run_command  exit=0 git log --oneline -3
25 09:02:24 final_answer exit=0 -

5.3 Ba câu hỏi điều tra#

== first failure ==
12 2026-10-31T09:01:27+07:00 run_command ran 20 tests, 18 passed, 2 failed
== files changed ==
README.md: 1 edit(s)
src/checkout.py: 1 edit(s)
src/pricing.py: 2 edit(s)
tests/test_discount.py: 1 edit(s)
== edits to test files ==
11 R2: make the tests pass ['tests/test_discount.py']

Đọc kết quả: thất bại đầu tiên là hành động 12 lúc 09:01:27. Ngay trước đó (hành động 11) agent đã thêm 22 dòng vào tệp test, rồi sau thất bại nó sửa src/pricing.py (hành động 14) chứ không sửa tệp test lần nữa. Nói cách khác, nhật ký cho thấy agent sửa code để test đạt, không sửa test cho khớp code. Nếu hành động 14 là một lần sửa tệp test, đó là chỗ bạn cần xem kỹ.

Cùng câu hỏi bằng jq (không cần Python):

jq -r 'select(.exit_code != 0) | "\(.seq) \(.ts) \(.summary)"' trail.jsonl
# 12 2026-10-31T09:01:27+07:00 ran 20 tests, 18 passed, 2 failed

jq -r '.files_changed[]' trail.jsonl | sort | uniq -c
#    1 README.md
#    1 src/checkout.py
#    2 src/pricing.py
#    1 tests/test_discount.py

5.4 Phát hiện một dòng bị sửa#

Tôi sao chép tệp nhật ký, rồi đổi mã kết thúc của dòng 12 từ 1 thành 0 để "xóa" thất bại. Chạy lại phần kiểm tra chuỗi băm:

== chain check ==
line 13: chain broken, an earlier line was changed
chain NOT ok
== first failure ==
none found

Dòng 13 chứa dấu vân tay của dòng 12 gốc, nên khi dòng 12 bị đổi, dấu vân tay không còn khớp. Kết quả "none found" ở phần lỗi đầu tiên cho thấy nếu không kiểm chuỗi băm trước thì bạn sẽ kết luận là phiên chạy sạch.

Giới hạn cần nói rõ: chuỗi băm chỉ phát hiện chứ không ngăn được. Kẻ sửa nhật ký có thể sửa lại toàn bộ chuỗi từ dòng bị sửa trở đi. Để chuỗi có giá trị, bạn phải cất dấu vân tay của dòng cuối ở một nơi mà người sửa không với tới (một dịch vụ khác, một hệ thống chỉ cho thêm, hoặc gửi cho người thứ hai).

6. Phép tính lưu trữ (minh họa, có thể bỏ qua)#

Tệp 25 dòng nặng 7.170 byte, tức khoảng 286,8 byte mỗi dòng. Giả sử một nhóm có 200 phiên mỗi ngày, mỗi phiên 100 hành động (số giả định để tính):

per_line = 7170 / 25               # 286.8 byte
per_day = 200 * 100 * per_line     # 5,736,000 byte
print(round(per_day / 1e6, 2), round(per_day * 30 / 1e6, 1))
# 5.74 172.1   (MB mỗi ngày, MB mỗi 30 ngày)

Khoảng 5,74 MB mỗi ngày và 172,1 MB cho 30 ngày. Dung lượng không phải vấn đề lớn với nhật ký tóm tắt. Vấn đề lớn hơn là ai được đọc và giữ bao lâu. Hai con số 200 và 100 là giả định của tôi, còn 286,8 byte đo trên mô phỏng này. Nhật ký thật có đầu ra dài hơn sẽ nặng hơn nhiều, đó là lý do không ghi toàn bộ nội dung.

7. Đọc lại dấu vết sau khi có chuyện#

Hình dung bạn là người điều tra mở cuốn sổ biên nhận. Năm câu hỏi theo thứ tự:

1. Sổ còn nguyên không? Kiểm chuỗi băm hoặc so với bản sao ở nơi khác.
2. Chuyện bắt đầu lúc nào? Tìm lỗi đầu tiên và nhìn các hành động ngay trước đó.
3. Ai hay cái gì ra lệnh? Xem trường request và actor.
4. Ảnh hưởng đến đâu? Liệt kê tệp bị đổi và lệnh có tác dụng ra ngoài (commit, đẩy mã, xóa).
5. Điều gì giữ cho chuyện không lặp lại? Việc này nằm ngoài nhật ký: viết một bản tổng kết sự cố. Bài kể chuyện xóa nhầm dữ liệu ở GitLab năm 2017 là một ví dụ về cách một nhóm kể lại sự việc sau khi nó xảy ra.

Nhật ký chỉ giúp câu 1 đến 4. Câu 5 là việc của con người.

8. Chỗ nào nhật ký hỏng#

Hình dung cuốn sổ có thể thiếu trang, ghi nhầm hoặc bị tẩy.

9. Minh họa: một buổi sáng hai kịch bản#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.

Không có nhật ký hành động:

• 09:00. Dev giao cho agent hai việc rồi vào họp đến 11:30.
• 11:35. Dev thấy nhánh có hai commit. Đồng nghiệp hỏi: "Sao tệp test bị đổi?"
• 11:40. Dev mở cuộc trò chuyện dài, cuộn tìm. Agent đã nói "đã sửa" nhưng không nói đã sửa tệp nào theo thứ tự nào.
• 12:20. Dev đoán và trả lời, nhưng không chắc.

Có nhật ký hành động:

• 09:00. Cùng hai việc, lớp ghi chạy ngoài agent.
• 11:35. Đồng nghiệp hỏi cùng câu.
• 11:37. Dev chạy truy vấn "tệp test bị sửa": hành động 11 lúc 09:01:19 thêm bài test mới, hành động 14 sửa code chứ không sửa test.
• 11:40. Trả lời kèm số thứ tự hành động.

Việc nên làm ở cả hai: gắn câu trả lời với một hành động có số thứ tự, không với trí nhớ. Đây là minh họa nên không chứng minh điều gì về tần suất. Bằng chứng nằm ở các nguồn cuối bài.

10. Bài tập làm tay (có đáp án)#

Chạy hai script ở phụ lục, rồi làm bốn việc sau.

1. Có bao nhiêu hành động run_command thất bại, và ở hành động số mấy?
2. Tệp nào bị sửa nhiều hơn một lần?
3. Thêm hai hành động vào cuối danh sách steps: một lệnh echo password=abc123 và một lệnh echo pwd=abc123. Chạy lại và đếm số dòng trong tệp có chứa abc123.
4. Sửa tay một dòng ở giữa tệp rồi chạy kiểm chuỗi. Dòng nào được báo hỏng?

Đáp án:

1. Một lệnh thất bại, ở hành động 12.
2. src/pricing.py, bị sửa hai lần (hành động 8 và 14).
3. Đúng một dòng chứa abc123. Lệnh password=abc123 bị che thành echo [REDACTED], còn pwd=abc123 lọt qua vì mẫu không có từ pwd (tôi đã chạy thử, kết quả là 1 dòng). Đó là bài học về giới hạn của che bằng mẫu cố định.
4. Dòng liền sau dòng bạn sửa, vì dòng đó chứa dấu vân tay của dòng gốc.

11. Số liệu và tài liệu đã dùng#

Đọc cho đúng: tôi không tìm thấy nghiên cứu đo việc có nhật ký hành động làm giảm thời gian điều tra bao nhiêu. Các lập luận trong bài là thực hành tốt dựa trên cách hoạt động của dấu vết, không phải kết quả thử nghiệm.

12. Danh sách kiểm: nhật ký cho agent#

1. Có lớp ghi nằm ngoài agent không, hay chỉ dặn agent tự ghi?
2. Mỗi dòng có thời gian, phiên, người thực hiện, yêu cầu gốc, công cụ, kết quả, tệp đổi?
3. Khóa bí mật có bị che trước khi ghi chưa, và đã thử bằng khóa giả chưa?
4. Có ghi dữ liệu cá nhân hay toàn bộ nội dung tệp không?
5. Nhật ký chỉ cho thêm dòng, hay agent sửa được?
6. Có cất dấu vân tay cuối hoặc bản sao ở nơi khác chưa?
7. Có truy vấn mẫu cho ba câu: dòng thời gian, lỗi đầu tiên, tệp đã đổi?
8. Ai được đọc, giữ bao lâu, và ngày xem lại là khi nào?

13. Nhìn cân bằng: nhật ký làm được gì và chưa làm được gì#

Làm được: rút ngắn việc dựng lại sự việc, trả lời "agent đã làm gì lúc mấy giờ", cho đồng nghiệp một căn cứ có số thứ tự, và làm lộ dòng bị sửa nếu bạn kiểm chuỗi.

Chưa làm được:

• Nhật ký không nói kết quả có đúng không. Một lệnh thành công vẫn có thể làm điều sai. Để biết đúng sai vẫn cần bằng chứng nộp kèm như trong bài Làm cho kết quả của AI tự chứng minh, kiểm thử và người đọc.
• Nó không ngăn thiệt hại. Nó chỉ giúp bạn biết sau đó. Với việc rủi ro thì cần thêm quyền hạn chế và điểm quay lại, như điểm lưu trong bài Git cho người dùng agent.
• Che bí mật bằng mẫu cố định sẽ bỏ sót kiểu khóa bạn chưa nghĩ tới.
• Nhật ký tốn dung lượng và cần chăm sóc về riêng tư: ai đọc, giữ bao lâu.
• Ví dụ chạy thật chỉ là mô phỏng một phiên. Nhật ký của công cụ thật sẽ có nhiều trường và nhiều ngoại lệ hơn.

Đừng thổi phồng: có nhật ký không có nghĩa là an toàn. Đừng coi nhẹ: khi cần nhất, tức là lúc có chuyện, đó thường là thứ duy nhất còn lại để dựa vào.

14. Kết luận#

Giao việc cho agent rồi đi họp là bình thường. Điều không bình thường là khi quay lại không biết nó đã làm gì. Hãy cho nó một cuốn sổ biên nhận do lớp khác ghi, ghi vừa đủ, che bí mật, chỉ cho thêm dòng, và biết cách đọc lại. Nhật ký không thay bằng chứng và kiểm thử, nhưng nó rút một buổi chiều điều tra xuống vài phút.

Phụ lục: hai script đầy đủ (có thể bỏ qua)#

agent_trail_demo.py, mô phỏng phiên và ghi nhật ký:

import hashlib
import json
import re
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path

LOG = Path(sys.argv[1] if len(sys.argv) > 1 else "trail.jsonl")
SECRET = re.compile(r"sk-[A-Za-z0-9]{8,}|(password|token|api_key)\s*[=:]\s*\S+", re.I)


def redact(value):
    """Hide secrets in every string inside a value, before it is turned into JSON."""
    if isinstance(value, str):
        return SECRET.sub("[REDACTED]", value)
    if isinstance(value, dict):
        return {k: redact(v) for k, v in value.items()}
    return value


class Trail:
    """Append-only JSON Lines trail. Each line carries the hash of the previous line."""

    def __init__(self, path, session):
        self.path, self.session, self.prev, self.seq = path, session, "start", 0
        self.clock = datetime(2026, 10, 31, 9, 0, 0, tzinfo=timezone(timedelta(hours=7)))
        path.write_text("")

    def record(self, request, tool, args, exit_code, summary, files=(), seconds=2):
        self.clock += timedelta(seconds=seconds)
        self.seq += 1
        line = {
            "seq": self.seq,
            "ts": self.clock.isoformat(),
            "session": self.session,
            "actor": "agent",
            "request": request,
            "tool": tool,
            "args": redact(args),
            "exit_code": exit_code,
            "summary": redact(summary),
            "files_changed": list(files),
            "prev": self.prev,
        }
        text = json.dumps(line, ensure_ascii=False, sort_keys=True)
        self.prev = hashlib.sha256(text.encode()).hexdigest()[:12]
        with self.path.open("a") as f:
            f.write(text + "\n")


trail = Trail(LOG, "s-001")
R1 = "R1: add a 10 percent discount to checkout"
R2 = "R2: make the tests pass"
steps = [
    (R1, "read_file", {"path": "src/checkout.py"}, 0, "120 lines", (), 3),
    (R1, "read_file", {"path": "src/pricing.py"}, 0, "80 lines", (), 2),
    (R1, "search", {"pattern": "discount"}, 0, "4 matches in 2 files", (), 2),
    (R1, "read_file", {"path": "tests/test_discount.py"}, 0, "45 lines", (), 2),
    (R1, "run_command", {"cmd": "git status --short"}, 0, "clean", (), 1),
    (R1, "run_command", {"cmd": "git switch -c agent/discount"}, 0, "switched to new branch", (), 1),
    (R1, "read_file", {"path": ".env"}, 0, "loaded API_KEY=sk-test1234567890abcd (3 variables)", (), 2),
    (R1, "edit_file", {"path": "src/pricing.py"}, 0, "+14 -2 lines", ("src/pricing.py",), 20),
    (R1, "edit_file", {"path": "src/checkout.py"}, 0, "+6 -1 lines", ("src/checkout.py",), 12),
    (R1, "run_command", {"cmd": "python -m pytest -q"}, 0, "ran 18 tests, 18 passed", (), 9),
    (R2, "edit_file", {"path": "tests/test_discount.py"}, 0, "+22 -0 lines", ("tests/test_discount.py",), 25),
    (R2, "run_command", {"cmd": "python -m pytest -q"}, 1, "ran 20 tests, 18 passed, 2 failed", (), 8),
    (R2, "read_file", {"path": "tests/test_discount.py"}, 0, "67 lines", (), 2),
    (R2, "edit_file", {"path": "src/pricing.py"}, 0, "+3 -1 lines", ("src/pricing.py",), 15),
    (R2, "run_command", {"cmd": "python -m pytest -q"}, 0, "ran 20 tests, 20 passed", (), 8),
    (R2, "run_command", {"cmd": "git diff --stat"}, 0, "3 files changed, 45 insertions, 4 deletions", (), 1),
    (R2, "run_command", {"cmd": "git add -A"}, 0, "staged 3 files", (), 1),
    (R2, "run_command", {"cmd": "git commit -m 'feat: add 10 percent discount'"}, 0, "1 commit created", (), 2),
    (R2, "read_file", {"path": "README.md"}, 0, "30 lines", (), 2),
    (R2, "edit_file", {"path": "README.md"}, 0, "+5 -0 lines", ("README.md",), 10),
    (R2, "run_command", {"cmd": "git add README.md"}, 0, "staged 1 file", (), 1),
    (R2, "run_command", {"cmd": "git commit -m 'docs: mention discount'"}, 0, "1 commit created", (), 2),
    (R2, "run_command", {"cmd": "python -m pytest -q"}, 0, "ran 20 tests, 20 passed", (), 8),
    (R2, "run_command", {"cmd": "git log --oneline -3"}, 0, "3 commits listed", (), 1),
    (R2, "final_answer", {}, 0, "reported done, branch agent/discount", (), 4),
]
for step in steps:
    trail.record(*step)
print(f"wrote {trail.seq} lines to {LOG}")

query_trail.py, kiểm chuỗi và truy vấn:

import hashlib
import json
import sys
from collections import Counter

path = sys.argv[1] if len(sys.argv) > 1 else "trail.jsonl"

print("== chain check ==")
prev, ok = "start", True
for i, line in enumerate(open(path), 1):
    if not line.strip():
        continue
    if json.loads(line)["prev"] != prev:
        print(f"line {i}: chain broken, an earlier line was changed")
        ok = False
        break
    prev = hashlib.sha256(line.rstrip("\n").encode()).hexdigest()[:12]
print("chain ok" if ok else "chain NOT ok")

rows = [json.loads(line) for line in open(path) if line.strip()]

print("== timeline ==")
for r in rows:
    args = r["args"]
    arg = args.get("cmd") or args.get("path") or args.get("pattern") or "-"
    print(f'{r["seq"]:>2} {r["ts"][11:19]} {r["tool"]:<12} exit={r["exit_code"]} {arg}')

print("== first failure ==")
first = next((r for r in rows if r["exit_code"] != 0), None)
print(f'{first["seq"]} {first["ts"]} {first["tool"]} {first["summary"]}' if first else "none found")

print("== files changed ==")
counts = Counter(f for r in rows for f in r["files_changed"])
for name, n in sorted(counts.items()):
    print(f"{name}: {n} edit(s)")

print("== edits to test files ==")
for r in rows:
    if any(f.startswith("tests/") for f in r["files_changed"]):
        print(r["seq"], r["request"], r["files_changed"])

Chạy: python3 agent_trail_demo.py trail.jsonl rồi python3 query_trail.py trail.jsonl. Đồng hồ trong mô phỏng là cố định, nên dấu vân tay (trường prev) trong tệp của bạn sẽ giống của tôi nếu bạn dùng đúng script này.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số nguồn là thứ cấp, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Anthropic, 2026 Agentic Coding Trends Report (trang giới thiệu, bản đầy đủ sau biểu mẫu)
• Stack Overflow, 2026 Developer Survey (đọc qua bản tóm tắt, chưa đối chiếu từng bảng)
• Anthropic, Claude Code: Hooks reference (trường JSON, sự kiện, mã thoát, đường dẫn bản ghi)
• OpenTelemetry, GenAI semantic conventions (trang đã chuyển kho) và các bài tổng hợp thứ cấp về trạng thái Development, ví dụ Dash0
• jq, jq Manual (lệnh lọc và gsub)
• Bài liên quan trong site: Làm cho kết quả của AI tự chứng minh, Git cho người dùng agent, Chính sách dùng AI một trang

Dành cho bất kỳ ai viết code hoặc nhờ AI viết code, kể cả người mới. Không cần biết bảo mật. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần chạy lệnh được đánh dấu để bạn bỏ qua nếu chưa cần.

Mọi khóa trong bài đều là khóa giả, gồm cặp khóa ví dụ có sẵn trong tài liệu của AWS. Số liệu lấy từ nguồn công khai có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Bài này là hướng dẫn thực hành, không phải tư vấn bảo mật cho hệ thống của bạn.

Tóm tắt nhanh#

• Khóa API, mật khẩu và mã truy cập là bí mật: ai cầm được là dùng được, như chìa khóa nhà.
• Xóa khóa khỏi tệp chưa phải là xong. Git nhớ mọi phiên bản cũ. Trong thí nghiệm của bài, sau khi xóa khóa ở commit thứ hai, git log -S vẫn tìm ra cả hai commit và git show in lại nguyên khóa.
• Thứ tự đúng khi lộ khóa: xoay hoặc thu hồi khóa trước, dọn lịch sử sau, rồi đọc nhật ký sử dụng. Tài liệu của GitHub cũng nói như vậy.
• Viết lại lịch sử không thu hồi các bản sao. Trong thí nghiệm, bản sao chép trước khi viết lại vẫn còn khóa.
• Có thể chặn từ đầu bằng biến môi trường, .gitignore, một pre-commit hook 30 dòng và tính năng quét của nền tảng. Mỗi lớp đều có chỗ sót, nên cần nhiều lớp.
• Khi làm việc với AI agent, thêm ba thói quen: không dán khóa thật vào cuộc trò chuyện, giữ tệp .env ngoài tầm với của agent, và đọc lại phần thay đổi trước khi commit.

Từ khó, nói dễ#

Sau bài này bạn giải thích được#

1. Vì sao xóa khóa khỏi tệp không làm nó biến mất, và cách tự kiểm bằng ba lệnh git.
2. Thứ tự đúng khi lộ khóa (xoay trước, dọn sau) và vì sao viết lại lịch sử không đủ.
3. Ba lớp phòng thủ (giữ ngoài code, chặn lúc commit, quét sau khi đẩy), và mỗi lớp sót ở đâu.

1. Hình dung trước: chìa khóa dưới thảm chùi chân#

Hình dung bạn để chìa khóa nhà dưới thảm chùi chân, rồi hôm sau nhận ra như thế không ổn nên chuyển chìa vào ngăn kéo. Nhưng trong một ngày đó, hàng xóm đi ngang đã kịp đúc một bản sao. Cất chìa khóa đi không làm bản sao biến mất. Cách duy nhất chắc chắn là đổi ổ khóa.

Khóa API trong code hoạt động như vậy. Khi bạn commit nó, git đã lưu một bản. Người khác có thể đã sao chép kho. Một công cụ tự động quét kho công khai có thể đã đọc nó. Xóa dòng đó ở commit sau giống như cất chìa vào ngăn kéo: tốt, nhưng chưa giải quyết bản sao.

Điều rút ra: khi một bí mật đã đi ra khỏi chỗ cất, hãy coi nó đã bị lộ và đổi khóa, chứ đừng chỉ cất lại.

2. Bí mật là gì, và lộ ở đâu#

Những chỗ lộ thường gặp:

• Commit thẳng vào git, rồi xóa ở commit sau (phần 3 chạy thật).
• Tệp .env bị commit vì quên ghi vào .gitignore, hoặc đã commit từ trước khi ghi.
• Nhật ký và ảnh chụp màn hình có chứa khóa, rồi gửi cho đồng nghiệp hoặc đăng lên diễn đàn.
• Dán vào cuộc trò chuyện với AI để "cho nó thấy lỗi". Nội dung đó có thể được lưu và hiển thị lại trong lịch sử cuộc trò chuyện.
• Mã chạy ở phía trình duyệt (client-side bundle): mọi thứ gửi xuống trình duyệt người dùng đều đọc được, nên không để khóa bí mật ở đó.

Điều rút ra: bí mật rò ra không chỉ qua một cửa. Cách phòng phải nhiều lớp.

3. Thí nghiệm thật: xóa rồi vẫn còn#

Tất cả lệnh và đầu ra trong phần này chạy thật trong một kho thử, với Git 2.56.0 và Python 3.14.8, chỉ dùng khóa giả. Mã hash khác nhau mỗi lần chạy. Thời gian ghi ở dưới là của máy tôi, cho kho 2 commit, nên chỉ để bạn hình dung cỡ.

3.1 Commit khóa giả, rồi xóa ở commit sau#

git init -q -b main repo
cd repo

# config.py chứa cặp khóa ví dụ trong tài liệu AWS (khóa giả)
#   AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
#   AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
git add .
git commit -m "add config"             # khoảng 0,03 giây

# commit sau đổi sang đọc từ biến môi trường
git add .
git commit -m "remove secret from config"

git log --oneline

2bfea15 remove secret from config
a0d01a2 add config

3.2 Nhìn thì sạch#

grep -n AKIA config.py          # không có kết quả
git grep AKIA                   # không có kết quả, chỉ tìm trong các tệp hiện tại

Cả hai lệnh không in ra gì. Đúng là tệp hiện tại đã sạch.

3.3 Nhưng lịch sử vẫn còn#

git log --oneline -S AKIAIOSFODNN7EXAMPLE

2bfea15 remove secret from config
a0d01a2 add config

Lệnh -S tìm các commit làm thay đổi số lần xuất hiện của chuỗi đó, nên nó chỉ ra cả commit thêm và commit xóa. Tiếp theo, tìm trong mọi commit và in lại tệp cũ:

git grep -n AKIA $(git rev-list --all)      # khoảng 0,02 giây
git show a0d01a2:config.py

a0d01a2473ddcb923dbfd69164c1df8a11de379b:config.py:3:AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"

import os

AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
REGION = "ap-southeast-1"

Chỉ cần ba lệnh và chưa đến một giây, ai có kho này cũng đọc lại được cả hai khóa.

Điều rút ra: tệp sạch không có nghĩa kho sạch. Phải tìm trong lịch sử.

4. Thứ tự đúng khi lộ khóa#

Hình dung có người báo "chìa khóa nhà bạn bị đúc bản sao". Bạn sẽ đổi ổ khóa trước, rồi mới đi tìm ai đã vào nhà.

1. Thu hồi hoặc xoay khóa ngay. Tài liệu secret scanning của GitHub khuyên xoay "ngay lập tức" và nói rằng xóa bí mật khỏi lịch sử git thì chậm và thường không cần thiết khi khóa đã bị thu hồi.
2. Đọc nhật ký sử dụng của khóa trên dịch vụ: ai dùng, từ đâu, lúc nào, trong khoảng thời gian lộ.
3. Dọn lịch sử (phần 6), nếu cần, để bản mới đẩy lên không còn khóa.
4. Ghi lại điều đã xảy ra và đặt rào chắn để lần sau không lặp lại (phần 5).

4.1 Xoay khóa AWS: quy trình tài liệu mô tả#

Tài liệu AWS về cập nhật access key mô tả quy trình xoay không làm gián đoạn ứng dụng:

1. Khi khóa thứ nhất còn hoạt động, tạo khóa thứ hai (lúc này có hai khóa cùng hoạt động).
2. Cập nhật mọi ứng dụng và công cụ sang khóa mới.
3. Xem thông tin "last used" của khóa cũ để biết còn ai dùng không. Tài liệu gợi ý có thể đợi vài ngày.
4. Không xóa ngay khóa cũ. Đổi nó sang trạng thái vô hiệu (Inactive) trước.
5. Dùng riêng khóa mới để kiểm ứng dụng còn chạy. Nơi nào vẫn dùng khóa cũ sẽ hỏng, và bạn có thể bật lại khóa cũ tạm thời.
6. Sau một thời gian đợi, mới xóa khóa cũ.

Quy trình trên viết cho việc xoay bình thường, có thời gian chờ. Với khóa đã lộ, việc vô hiệu hóa khóa cũ ngay là suy luận của tôi theo nguyên tắc "thu hồi trước" của GitHub, không phải lời của tài liệu AWS. Cái giá là ứng dụng nào còn dùng khóa cũ sẽ hỏng ngay, nên hãy chuẩn bị sẵn khóa mới.

4.2 Trong 15 phút làm được gì, chưa làm được gì#

Đây là mốc mục tiêu tôi đề xuất, không phải số đo. Thời gian thật phụ thuộc bạn có sẵn quyền và có biết khóa đang dùng ở đâu không.

Điều rút ra: 15 phút đủ để đóng cửa. Việc kiểm tra thiệt hại là việc của vài giờ sau.

5. Chặn từ đầu: nhiều lớp, mỗi lớp có chỗ sót#

Hình dung nhà có ba lớp: không mang chìa ra khỏi nhà, có người nhắc ở cửa, và có camera ngoài đường.

5.1 Lớp một: giữ bí mật ngoài code#

Đặt bí mật vào biến môi trường hoặc một nơi cất bí mật của dịch vụ, và để tệp cấu hình chỉ nói "đọc từ biến tên này". Trong thí nghiệm, commit thứ hai đã làm đúng như vậy:

AWS_ACCESS_KEY_ID = os.environ["AWS_ACCESS_KEY_ID"]

Nếu dùng tệp .env cho máy cục bộ, hãy ghi nó vào .gitignore trước khi tạo tệp. Thử thật (tôi dùng tên dev.env thay cho .env, vì môi trường chạy của tôi không cho tạo tệp tên .env; cách hoạt động giống nhau):

git status --short

?? dev.env
?? tools/

echo "dev.env" > .gitignore
git status --short
git check-ignore -v dev.env

?? .gitignore
?? tools/
.gitignore:1:dev.env    dev.env

Tệp dev.env biến mất khỏi danh sách, và check-ignore cho biết dòng nào của .gitignore đang chặn nó. Nhưng .gitignore chỉ có tác dụng với tệp chưa được theo dõi. Tôi thử với một tệp đã commit từ trước:

git add -f old.env
git commit -m "oops: commit old.env"
echo "old.env" >> .gitignore
git ls-files old.env

old.env

Dù đã ghi vào .gitignore, git vẫn theo dõi tệp này. Muốn ngừng theo dõi phải dùng git rm --cached old.env, và khóa trong lịch sử vẫn còn như phần 3.

5.2 Lớp hai: chặn lúc commit bằng pre-commit hook#

Dưới đây là một bộ quét rất nhỏ (khoảng 30 dòng Python) đọc các dòng sắp được thêm và dò ba dạng: khóa kiểu AWS, đầu khóa riêng, và dòng gán chuỗi cho tên như api_key, secret, token, password:

PATTERNS = {
    "aws access key id": re.compile(r"AKIA[0-9A-Z]{16}"),
    "private key header": re.compile(r"-----BEGIN [A-Z ]*PRIVATE KEY-----"),
    "key or password assigned to a string": re.compile(
        r"""(?i)(api[_-]?key|secret|token|passwd|password)\w*\s*[=:]\s*['"][^'"\s]{8,}['"]"""
    ),
}
# đọc: git diff --cached -U0, xét các dòng bắt đầu bằng "+", thấy khớp thì thoát với mã 1

Gắn vào .git/hooks/pre-commit:

#!/bin/sh
exec python3 tools/scan_secrets.py

Thử commit một tệp có khóa giả:

Blocked: this commit adds something that looks like a secret.
  deploy.py: key or password assigned to a string
Use an environment variable, then rotate the key if it was ever real.
exit code: 1

Commit bị từ chối (cả lần thử mất khoảng 0,14 giây). Nhưng bộ quét này có hai chỗ yếu, và tôi thử luôn:

• Bỏ sót: nếu khóa bị tách làm hai chuỗi (part1 = "AKIA", part2 = "IOSFODNN7EXAMPLE", rồi nối lại), commit được cho qua với mã 0.
• Báo nhầm: một dòng password = "change-me-please" trong tài liệu mẫu bị chặn, dù đó chỉ là chữ giữ chỗ.

Điều rút ra: công cụ quét dựa trên mẫu chữ bắt được lỗi hay gặp, không bắt được lỗi cố ý hay khéo léo, và đôi khi la nhầm. Đừng coi nó là bảo chứng.

Hook nằm trong thư mục .git/hooks, không đi theo kho. Muốn cả nhóm dùng chung phải có cách chia sẻ (ví dụ một công cụ quản lý hook trong dự án), và mỗi người vẫn có thể bỏ qua nó bằng --no-verify.

5.3 Lớp ba: quét sau khi đẩy, và chặn lúc đẩy#

Các nền tảng có tính năng cho việc này. Theo trang tài liệu GitHub tôi đọc (qua công cụ tóm tắt trang):

• Secret scanning tự dò thông tin xác thực bị lộ như khóa API và mật khẩu, và quét "toàn bộ lịch sử git trên mọi nhánh", cùng với nội dung issue, pull request, thảo luận và wiki.
• Push protection chặn lệnh đẩy có chứa bí mật, trước khi nó vào kho. Nó nhận mẫu của nhà cung cấp, mẫu chung (như khóa riêng, chuỗi kết nối cơ sở dữ liệu) và mẫu tự định nghĩa. Với kho, tính năng này mặc định tắt; ai có quyền ghi có thể bỏ qua bằng cách nêu lý do. Ở cấp người dùng, tài liệu ghi là bật sẵn để chặn việc đẩy bí mật lên kho công khai trên GitHub.com.

Tôi đọc tài liệu này qua công cụ tóm tắt trang, chưa kiểm từng chữ, nên hãy mở trang gốc (có ở phần nguồn) và xem cài đặt của chính tài khoản bạn. Các công cụ độc lập như gitleaks, trufflehog hay git-filter-repo cũng có, nhưng chưa chạy ở đây: tôi không cài chúng trong môi trường chạy thử.

6. Dọn lịch sử: làm được gì và không làm được gì#

Sau khi đã xoay khóa, bạn có thể muốn kho không còn khóa nữa. Công cụ khuyên dùng hiện nay là git filter-repo, nhưng tôi chưa chạy được vì máy thử không có nó. Vì vậy tôi demo bằng git filter-branch có sẵn trong Git (trang tài liệu của Git ghi rằng việc dùng lệnh này "không được khuyến nghị" và gợi ý dùng git filter-repo, nhưng nó chạy được và đủ để minh họa):

git clone -q repo clone-before       # chụp một bản sao TRƯỚC khi viết lại
cd repo
git filter-branch -f --tree-filter "python3 redact.py" -- --all   # khoảng 0,8 giây, 5 commit

Trong đó redact.py thay hai chuỗi khóa giả bằng REDACTED ở mọi commit. Kiểm tra:

git log --oneline -S AKIAIOSFODNN7EXAMPLE main

Không in ra gì: nhánh main đã sạch. Nhưng ba chỗ khác vẫn còn khóa:

git for-each-ref --format='%(refname)'

refs/heads/main
refs/original/refs/heads/main

Công cụ để lại nhánh sao lưu refs/original/refs/heads/main, và git log -S AKIAIOSFODNN7EXAMPLE --all vẫn thấy hai commit cũ. Muốn dọn phải xóa nhánh sao lưu, xóa reflog và dọn các đối tượng không còn ai trỏ tới:

git for-each-ref --format='%(refname)' refs/original | xargs -n1 git update-ref -d
git reflog expire --expire=now --all
git gc -q --prune=now                          # khoảng 0,1 giây
git log --oneline -S AKIAIOSFODNN7EXAMPLE --all --reflog   # không in gì
git cat-file -t a0d01a2        # fatal: Not a valid object name

Kho đã sạch hẳn. Còn bản sao chụp trước khi viết lại thì sao?

cd ../clone-before
git log --oneline -S AKIAIOSFODNN7EXAMPLE
git cat-file -t a0d01a2

2bfea15 remove secret from config
a0d01a2 add config
commit

Bản sao đó vẫn còn khóa. Đó là lý do dọn lịch sử không thay được việc xoay khóa: mọi người đã kéo (pull) hay fork kho trước đó vẫn giữ bản cũ, và một kho công khai có thể đã được người khác sao chép hay lưu lại.

Một cảnh báo thêm: viết lại lịch sử làm đổi mã hash của các commit, nên đồng đội phải kéo lại và có thể gặp xung đột. Phải báo trước. Bài Git cho người dùng agent giải thích vì sao đẩy ép (force push) là thao tác cần thận trọng.

7. Khi làm việc với AI agent: thêm sáu thói quen#

Hình dung bạn thuê thợ vào nhà: bạn đưa chìa khóa có hạn dùng, chỉ mở một phòng, chứ không đưa chìa chủ.

1. Đừng dán khóa thật vào cuộc trò chuyện. Nếu cần cho AI xem lỗi, thay khóa bằng chữ giữ chỗ như <KHOA_API>.
2. Giữ tệp .env ngoài đường dẫn agent đọc được hoặc dùng cơ chế chặn đọc của công cụ. Một agent có quyền đọc cả thư mục dự án có thể đọc luôn bí mật trong đó.
3. Dùng khóa quyền hẹp, hạn ngắn cho mọi việc agent làm: chỉ đủ phục vụ tác vụ, hết hạn sớm.
4. Đọc diff trước khi commit. Agent có thể ghi chuỗi kết nối cố định vào code cho "chạy được ngay". Một lệnh git add là đủ để đưa nó vào lịch sử. Xem bài Duyệt code do AI viết.
5. Không cho agent tự đẩy lên nhánh chính và không để nó tự chạy lệnh cài hoặc lệnh có quyền cao khi chưa ai xem. Xem thêm bài OWASP Top 10 cho ứng dụng dùng AI.
6. Đưa quy tắc vào chính sách nhóm. Bài Chính sách dùng AI một trang có cột "cấm" cho loại dữ liệu này.

7.1 Minh họa: một buổi sáng nhờ agent kết nối cơ sở dữ liệu#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật. Tên và giá trị là bịa.

Không có thói quen trên:

• 10:00. Dev nhờ agent: "Kết nối cơ sở dữ liệu giúp tôi, chuỗi kết nối đây" và dán chuỗi thật vào cuộc trò chuyện.
• 10:10. Agent viết config.py, gán thẳng chuỗi kết nối vào code cho "chạy được ngay", rồi commit.
• 10:20. Dev xem lướt, thấy chạy ổn, đẩy lên.
• 10:45. Nền tảng gửi cảnh báo phát hiện bí mật trong kho. Dev xóa dòng đó, đẩy lại. Nghĩ là xong.

Có thói quen:

• 10:00. Dev đặt chuỗi kết nối vào biến môi trường trên máy, nhờ agent: "đọc từ biến DATABASE_URL, đừng ghi giá trị vào code".
• 10:10. Agent viết config.py đọc biến môi trường. Hook pre-commit kiểm không thấy gì lạ.
• 10:20. Dev đọc diff, chỉ thấy tên biến, đẩy lên.

Nếu rơi vào phiên bản đầu, việc nên làm lúc 10:45 là: xoay mật khẩu cơ sở dữ liệu ngay, rồi đọc nhật ký truy cập, rồi mới tính chuyện dọn lịch sử. Xóa dòng ở commit sau không giải quyết gì vì lịch sử đã giữ chuỗi cũ và cuộc trò chuyện với AI cũng đã chứa nó.

8. Hay sai ở đâu#

9. Số liệu và tài liệu đã dùng#

Về một con số tôi không dùng: tôi đã thử kiểm một số liệu "41% trong 100 ứng dụng có lộ bí mật hoặc khóa API" gắn với một nghiên cứu của VibeWrench (tháng 3/2026). Tôi không tìm được nguồn xác nhận. Trang sản phẩm VibeWrench chỉ nói họ quét 100 ứng dụng và tìm ra 318 lỗ hổng, không nêu tỷ lệ lộ khóa. Vì vậy bài này không dùng con số đó.

Đọc cho đúng: có bằng chứng tốt cho cơ chế (git nhớ lịch sử, bản sao còn) vì bạn tự chạy lại được. Chưa có số liệu đáng tin cho tần suất lộ khóa nói chung, và tôi không tìm thấy nghiên cứu đo hiệu quả riêng của pre-commit hook.

10. Bài tập có đáp án (30 phút)#

Đề. Tạo một kho thử, dùng khóa giả (như cặp khóa ví dụ của AWS ở trên, tuyệt đối không dùng khóa thật), rồi:

1. Commit một tệp có khóa giả, rồi xóa khóa ở commit sau.
2. Dùng git log -S và git show để chứng minh khóa vẫn còn.
3. Viết một thứ tự năm bước nếu đó là khóa thật.
4. Gắn một pre-commit hook quét, rồi thử một commit có khóa gán trực tiếp và một commit có khóa tách làm hai chuỗi.
5. Chụp một bản sao kho, viết lại lịch sử bằng git filter-branch, rồi kiểm cả hai kho.

Đáp án.

1. Sau hai commit, git log --oneline hiện hai dòng.
2. git log --oneline -S <khóa> in ra cả hai commit. git show <commit thứ nhất>:<tệp> in lại khóa.
3. Một thứ tự hợp lý: (1) vô hiệu hóa khóa cũ trên dịch vụ, (2) tạo khóa mới và cập nhật nơi dùng, (3) kiểm ứng dụng, (4) đọc nhật ký sử dụng, (5) dọn lịch sử nếu cần và báo đồng đội. Điểm chấm: xoay khóa đứng trước dọn lịch sử.
4. Commit khóa gán trực tiếp bị chặn (mã thoát 1). Commit khóa tách chuỗi không bị chặn, vì bộ quét chỉ tìm mẫu nguyên.
5. Kho đã viết lại sạch sau khi xóa nhánh sao lưu, reflog và chạy gc; bản sao chụp trước vẫn còn khóa. Gợi ý cải thiện bộ quét: quét cả tệp thay vì chỉ dòng thêm, dò theo độ ngẫu nhiên của chuỗi, hoặc dùng công cụ chuyên dụng.

11. Danh sách kiểm trước khi đẩy code#

1. Có bí mật thật nào trong phần thay đổi không (khóa, mật khẩu, chuỗi kết nối, khóa riêng)?
2. Bí mật nằm ở biến môi trường hoặc nơi cất bí mật, không nằm trong code?
3. Tệp .env và tệp tương tự đã ghi vào .gitignore trước khi tạo?
4. Tôi đã đọc diff và tìm các chuỗi dài lạ trước khi commit?
5. Có hook hoặc công cụ quét chạy cục bộ, và có quét phía nền tảng?
6. Khóa tôi dùng có quyền hẹp và hạn ngắn không?
7. Tôi đã dán khóa thật vào cuộc trò chuyện với AI chưa? Nếu có, xoay khóa đó.
8. Nếu khóa lộ lúc này, tôi biết xoay ở đâu, trong bao lâu, và ai cần được báo?

12. Nhìn cân bằng: biết gì, chưa biết gì#

Khá chắc: git giữ lịch sử và có thể đọc lại khóa đã xóa; viết lại lịch sử không thu hồi các bản sao có sẵn; công cụ quét mẫu chữ có thể bỏ sót và báo nhầm; xoay khóa là bước gốc. Cả bốn điều đều đã chạy thật trong bài.

Chưa rõ hoặc có giới hạn:

• Tần suất khóa bị lộ ngoài đời và mức thiệt hại. Số liệu hiện có chủ yếu từ hãng bảo mật tự quét, và một con số tôi không xác nhận được nên đã bỏ.
• Hiệu quả thực tế của từng lớp phòng thủ. Tôi không tìm thấy nghiên cứu đo riêng pre-commit hook hay push protection.
• Các công cụ chuyên dụng (git-filter-repo, gitleaks, trufflehog) tôi chưa chạy. Hãy đọc tài liệu của chúng trước khi dùng.
• Nền tảng khác nhau về tính năng và cài đặt mặc định. Trang tài liệu GitHub tôi đọc qua công cụ tóm tắt và có thể đã đổi.

Đừng thổi phồng: không có lớp nào đủ một mình. Đừng coi nhẹ: chi phí phòng ngừa là vài phút mỗi lần thiết lập, còn một khóa lộ có thể khiến người khác chạm vào dữ liệu hay tài nguyên của bạn.

13. Kết luận#

Một khóa API đã vào git thì coi như đã ra khỏi tay bạn. Xóa dòng ở commit sau là cất chìa vào ngăn kéo, còn bản sao thì vẫn ở ngoài. Hãy xoay khóa trước, đọc nhật ký, rồi mới dọn lịch sử. Để lần sau không lặp lại, giữ bí mật ngoài code, chặn lúc commit, quét sau khi đẩy, và với AI agent thì đưa chìa khóa hạn ngắn, quyền hẹp, và luôn đọc diff trước khi commit.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Các trang GitHub và AWS tôi đọc qua công cụ tóm tắt trang, nên hãy mở bản gốc để kiểm tra trước khi trích dẫn.

• GitHub Docs, About secret scanning
• GitHub Docs, About push protection
• AWS Documentation, Update access keys (IAM User Guide)
• Escape, The State of Security of Vibe Coded Apps (không ghi ngày, do hãng bảo mật tự thực hiện)
• Git, git-filter-branch và git-log (tùy chọn -S)

Dành cho bất kỳ ai dùng AI để viết code hoặc giao việc cho AI agent, kể cả người mới. Không cần biết gì về cách mô hình hoạt động. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Mọi mức giá trong bài là giả định để tính cho dễ, không phải bảng giá hiện hành, vì giá thay đổi theo nhà cung cấp và theo thời gian. Cách mô hình bên trong làm việc chưa ai hiểu hết, nên các hình dung chỉ là cách tưởng tượng để dễ nhớ. Riêng cách tính tiền thì có tài liệu, và bài bám theo đó.

Tóm tắt nhanh#

• AI tính tiền theo token, tức các mảnh chữ mà mô hình đọc vào và viết ra. Hóa đơn là số token đầu vào nhân giá đầu vào, cộng số token đầu ra nhân giá đầu ra.
• Với một cuộc trò chuyện nhiều lượt, toàn bộ lịch sử được gửi lại ở mỗi lượt. Vì vậy chi phí tăng nhanh hơn số lượt. Trong ví dụ tính được của bài, 15 lượt gửi 322.500 token đầu vào nhưng chỉ có 7.500 token đầu ra, và gấp đôi số lượt làm đầu vào tăng khoảng 3,4 lần.
• Bộ nhớ đệm có thể giảm mạnh phần đọc lại. Trong ví dụ, chi phí còn khoảng 31%. Nhưng quy tắc và giá khác nhau giữa các nhà cung cấp, và bộ nhớ đệm hết hạn nếu bạn dừng lâu.
• Ba cách giữ trong ngân sách: phiên ngắn rồi mở phiên mới kèm bản tóm tắt, mô hình rẻ cho việc thường, giới hạn chi tiêu và theo dõi.
• Xu hướng đang đi theo hướng tính theo mức dùng. Gartner (24/6/2026) dự báo chi phí AI viết code có thể vượt lương trung bình của một dev vào năm 2028, và GitHub chuyển Copilot sang tín dụng tính theo token từ 1/6/2026.
• Rẻ nhất mỗi token không có nghĩa rẻ nhất mỗi việc xong. Hãy đo cả chi phí lẫn công sửa lại.

Từ khó, nói dễ#

Sau bài này bạn giải thích được#

1. Token là gì và vì sao cùng một nội dung có thể tốn số token khác nhau (tùy ngôn ngữ và cách chia mảnh).
2. Vì sao một cuộc trò chuyện dài đắt dần hơn tỷ lệ với số lượt, và bộ nhớ đệm làm gì để giảm bớt.
3. Ba cách giữ chi phí trong ngân sách và vì sao rẻ nhất mỗi token chưa chắc rẻ nhất mỗi việc xong.

1. Hình dung trước: đồng hồ taxi và cuốn sổ phải đọc lại#

Hình dung bạn thuê một người trả lời rất giỏi, nhưng người này không nhớ gì giữa các câu hỏi. Mỗi lần bạn hỏi, họ phải đọc lại cả cuốn sổ ghi mọi điều đã nói từ đầu, rồi mới viết câu trả lời. Và họ tính tiền theo số trang đọc cộng số trang viết, như đồng hồ taxi nhảy theo từng cây số.

Câu hỏi thứ nhất: cuốn sổ mỏng, đọc nhanh, rẻ. Câu hỏi thứ mười lăm: cuốn sổ đã dày lên, mỗi lần đọc lại tốn nhiều hơn. Phần bạn thực sự mới nói thêm ở mỗi lượt có thể chỉ vài dòng, nhưng phần phải đọc lại thì ngày càng nhiều.

Cách hình dung này chỉ để dễ nhớ. Điều có tài liệu rõ ràng là chuyện tính tiền: các dịch vụ AI tính theo token đưa vào và token sinh ra, và ở các cuộc trò chuyện nhiều lượt, lịch sử trước đó là một phần của đầu vào ở mỗi lượt (xem thêm bài Cửa sổ ngữ cảnh).

Điều rút ra: hóa đơn không tăng theo số câu bạn gõ. Nó tăng theo số lần cuốn sổ phải được đọc lại nhân với độ dày của cuốn sổ.

2. Token là gì#

2.1 Mảnh chữ, không phải chữ#

Mô hình không đọc từng chữ cái hay từng từ trọn vẹn, mà đọc các mảnh. Một từ phổ biến có thể là một mảnh, một từ hiếm có thể bị cắt thành vài mảnh, và dấu câu cũng là mảnh. Cách cắt cụ thể khác nhau giữa các mô hình, nên tôi không đưa ví dụ cắt cụ thể ở đây, vì sẽ dễ sai.

Quy tắc kinh nghiệm hay được nhắc cho tiếng Anh là khoảng 4 ký tự mỗi token. Tôi chưa kiểm chứng con số này với trang gốc (trang bộ đếm token của OpenAI trả lỗi 403 khi tôi mở) và coi nó là một giả định để ước lượng thô.

2.2 Cùng nội dung, số token khác nhau#

Nhóm Petrov, La Malfa, Torr và Bibi (2023) so sánh độ dài tokenization của cùng một văn bản dịch sang nhiều ngôn ngữ và thấy chênh lệch có thể lên đến khoảng 15 lần ở một số trường hợp, kể cả với các bộ tách chữ được huấn luyện cho nhiều ngôn ngữ. Họ lập luận rằng điều này có thể kéo theo chi phí cao hơn cho một số cộng đồng ngôn ngữ.

Hệ quả cho người đọc bài này: nếu bạn nhờ AI bằng tiếng Việt hoặc tiếng Nhật, số token trên mỗi ký tự có thể nhiều hơn tiếng Anh. Tôi không chạy được bộ đếm token trong môi trường viết bài (không có thư viện đếm token cài sẵn), nên không đưa ra con số riêng cho tiếng Việt hay tiếng Nhật. Cách đúng là dùng bộ đếm token của chính công cụ bạn dùng và đo trên văn bản thật của bạn. Nghiên cứu trên đo các mô hình thời 2023, mô hình mới có thể khác.

Điều rút ra: đừng đoán số token bằng số chữ. Hãy đo bằng công cụ đếm của nhà cung cấp, trên chính nội dung của bạn.

3. Giá đầu vào và đầu ra#

Hầu hết nhà cung cấp tính giá khác nhau cho token đầu vào và đầu ra, và đầu ra thường đắt hơn mỗi token. Ví dụ từ bảng giá trong tài liệu của Anthropic mà tôi đọc ngày 30/10/2026 (giá trên một triệu token):

Trong ba dòng này, đầu ra đều gấp 5 lần đầu vào, và mô hình nhỏ rẻ hơn mô hình lớn nhiều lần. Hãy xem đây là ví dụ của một nhà cung cấp tại một thời điểm. Giá đổi, tên mô hình đổi, và các nhà cung cấp khác có cách tính khác.

Dù vậy, đừng vội kết luận rằng "đầu ra đắt nên ít để ý đầu vào". Phần tính ở phần 4 sẽ cho thấy trong một cuộc trò chuyện dài, đầu vào mới là phần chiếm nhiều tiền nhất, vì nó bị lặp lại.

4. Vì sao hóa đơn phình: tính thử bằng một script chạy thật#

Hình dung: mỗi lượt, cuốn sổ dày thêm một chút và bị đọc lại.

4.1 Các giả định (minh họa, có thể bỏ qua phần tính)#

Đây là ví dụ minh họa với số dựng sẵn, không phải số đo từ một công cụ cụ thể:

• Lúc bắt đầu, bạn gửi 6.000 token hướng dẫn và tệp.
• Mỗi lượt có thêm 1.500 token nội dung mới (câu bạn gõ, kết quả của công cụ).
• Mỗi lượt mô hình viết 500 token, và phần đó nhập vào lịch sử.
• Giá giả định: 2 USD một triệu token đầu vào, 10 USD một triệu token đầu ra.
• Với bộ nhớ đệm: đọc lại phần đã lưu tính 0,1 lần giá đầu vào, ghi phần mới tính 1,25 lần. Hai hệ số này lấy theo mặc định trong tài liệu của Anthropic (một số mô hình có hệ số đọc thấp hơn).

4.2 Script chạy lại được#

# Illustrative numbers only. Change them to match your own tool and price list.
BASE = 6000           # tokens of instructions and files sent at the start
NEW_IN = 1500         # new tokens added each turn (your message, tool output)
OUT = 500             # tokens the model writes each turn
PRICE_IN = 2.00       # dollars per million input tokens (assumption)
PRICE_OUT = 10.00     # dollars per million output tokens (assumption)
READ = 0.10           # cache read costs 0.1 x input price (assumption)
WRITE = 1.25          # cache write costs 1.25 x input price (assumption)

def run(turns, base=BASE, new_in=NEW_IN, out=OUT):
    sent = 0                      # input tokens sent in total
    cost_plain = 0.0              # no caching: everything at full input price
    cost_cache = 0.0              # with caching: read old part cheaply, write new part
    context = base                # tokens already in the conversation
    prev_in = 0                   # what the previous call sent (it is in the cache)
    for t in range(1, turns + 1):
        this_in = context + new_in            # whole history is sent again
        sent += this_in
        cost_plain += this_in * PRICE_IN / 1e6
        if t == 1:
            cost_cache += this_in * PRICE_IN * WRITE / 1e6
        else:
            cost_cache += prev_in * PRICE_IN * READ / 1e6            # read what was cached
            fresh = this_in - prev_in                                # last output + new content
            cost_cache += fresh * PRICE_IN * WRITE / 1e6             # write the new part
        cost_out = out * PRICE_OUT / 1e6
        cost_plain += cost_out
        cost_cache += cost_out
        prev_in = this_in
        context = this_in + out               # output joins the history
    return sent, turns * out, cost_plain, cost_cache

for turns in (15, 30):
    sent, out_total, plain, cache = run(turns)
    print(f"{turns} turns: input sent {sent:,} tokens, output {out_total:,} tokens, "
          f"no cache ${plain:.4f}, with cache ${cache:.4f}")

# restart halfway: a fresh session instead of one long history (no caching in this line)
first = run(8)
fresh_short = run(7, base=1000)   # starts from a 1,000-token summary
fresh_full = run(7)               # starts again from the full 6,000-token base
one_long = run(15)
print(f"one session of 15 turns:               ${one_long[2]:.4f}")
print(f"8 turns + fresh 7 (1,000 summary):     ${first[2] + fresh_short[2]:.4f}")
print(f"8 turns + fresh 7 (full 6,000 again):  ${first[2] + fresh_full[2]:.4f}")

Kết quả thật khi tôi chạy bằng Python 3.14.8 (tôi cũng tính lại riêng bằng một đoạn khác, hai bên khớp nhau):

15 turns: input sent 322,500 tokens, output 7,500 tokens, no cache $0.7200, with cache $0.2212
30 turns: input sent 1,095,000 tokens, output 15,000 tokens, no cache $2.3400, with cache $0.5197
one session of 15 turns:               $0.7200
8 turns + fresh 7 (1,000 summary):     $0.4260
8 turns + fresh 7 (full 6,000 again):  $0.4960

4.3 Đọc kết quả#

• Đầu vào áp đảo. Với 15 lượt, tổng đầu vào gửi đi là 322.500 token, còn đầu ra chỉ 7.500 token, tức đầu vào gấp 43 lần. Khi tính tiền không dùng bộ nhớ đệm, phần đầu vào là 0,645 USD trong tổng 0,72 USD (khoảng 90%), phần đầu ra 0,075 USD.
• Chi phí tăng nhanh hơn số lượt. Gấp đôi số lượt (15 lên 30) làm đầu vào tăng từ 322.500 lên 1.095.000 token, khoảng 3,4 lần, và chi phí không dùng bộ nhớ đệm từ 0,72 lên 2,34 USD, khoảng 3,25 lần.
• Bộ nhớ đệm giảm mạnh phần đọc lại. Với 15 lượt, chi phí còn 0,2212 USD, khoảng 31% so với 0,72 USD. Với 30 lượt còn 0,5197 USD, khoảng 22% so với 2,34 USD. Vẫn tăng theo số lượt, chỉ chậm hơn.
• Mở phiên mới đúng lúc giúp được. Chia 15 lượt thành 8 lượt rồi 7 lượt ở phiên mới bắt đầu từ bản tóm tắt 1.000 token: 0,426 USD, thấp hơn khoảng 41% so với 0,72 USD (so cùng cách tính không dùng bộ nhớ đệm). Nếu phiên mới phải gửi lại toàn bộ 6.000 token ban đầu thì còn 0,496 USD, thấp hơn khoảng 31%.

4.4 Giới hạn của phép tính#

Đây là mô hình đơn giản hóa. Nó bỏ qua nhiều thứ có thật: bộ nhớ đệm hết hạn nếu bạn dừng lâu (tài liệu của Anthropic ghi thời hạn mặc định là 5 phút, được làm mới mỗi lần dùng), độ dài tối thiểu để được lưu đệm (từ 512 đến 4.096 token tùy mô hình), các khoản phí khác (công cụ, tìm kiếm), và việc công cụ của bạn có tự dùng bộ nhớ đệm hay không. Tôi chưa kiểm chứng việc này cho từng công cụ cụ thể. Số tuyệt đối của bạn sẽ khác. Điều có giá trị là hình dạng của đường cong: nhiều lượt trong cùng một lịch sử làm chi phí lên nhanh hơn số lượt.

Điều rút ra: nút điều chỉnh chính không phải là gõ ít hơn, mà là cho cuốn sổ ngắn hơn và đọc lại ít lần hơn.

5. Ba cách giữ trong ngân sách#

Hình dung quản lý quỹ ăn trưa của nhóm: chọn quán phù hợp từng bữa, không gọi lại cả thực đơn mỗi lần, và có sổ theo dõi.

Cách 1. Phiên ngắn và mới, kèm bản tóm tắt#

Khi một việc xong, đừng kéo tiếp cùng cuộc trò chuyện sang việc không liên quan. Nhờ agent tóm tắt những gì cần mang theo (quyết định đã chốt, tệp liên quan, việc còn lại), rồi mở phiên mới. Trong ví dụ, việc này giảm khoảng 31% đến 41% chi phí không dùng bộ nhớ đệm. Mẫu tóm tắt chuyển giao có trong bài Cửa sổ ngữ cảnh. Gartner cũng khuyên đào tạo dev chỉ gửi ngữ cảnh liên quan và tóm tắt hoặc cắt bớt đầu vào.

Cách 2. Mô hình rẻ cho việc thường#

Việc đơn giản và lặp lại (đổi tên, sinh dữ liệu mẫu, định dạng) thường không cần mô hình mạnh nhất. Với giá giả định chia cho 4 (0,50 USD đầu vào và 2,50 USD đầu ra một triệu token), cùng 15 lượt tốn 0,18 USD thay vì 0,72 USD. Gartner khuyên chuyển việc đơn giản, số lượng lớn sang mô hình nhỏ hơn và dành mô hình mạnh cho việc phức tạp. Nhưng hãy nhớ phần cân bằng ở dưới: nếu mô hình rẻ cần nhiều lượt hơn hoặc để lại lỗi, tổng chi phí có thể không giảm.

Cách 3. Giới hạn và theo dõi#

• Đặt giới hạn chi tiêu theo người hoặc theo nhóm. Theo bài đăng của GitHub ngày 27/4/2026, tổ chức có thể gộp tín dụng dùng chung và quản trị viên có thể đặt ngân sách ở cấp doanh nghiệp, trung tâm chi phí và từng người dùng, khi hết thì cho phép dùng thêm theo giá công bố hoặc chặn chi tiêu.
• Xem trang theo dõi mức dùng của công cụ mỗi tuần, không chờ hóa đơn cuối tháng. GitHub cho biết có bản xem trước hóa đơn từ đầu tháng 5/2026.
• Gartner khuyên đặt ngưỡng token, quy tắc leo thang và theo dõi tự động, và xem lại các luồng việc tốn nhiều token trong buổi nhìn lại sprint.

Điều rút ra: ba cách này bổ trợ nhau. Phiên ngắn giảm lượng token, mô hình rẻ giảm giá mỗi token, và giới hạn cùng theo dõi để bạn không bị bất ngờ.

6. Vì sao chủ đề này đang nóng: chuyển sang tính theo mức dùng#

6.1 Dự báo của Gartner (24/6/2026)#

Theo một bản đăng lại thông cáo của Gartner trên DevOps Digest (trang gốc của Gartner trả lỗi 403 khi tôi mở), Gartner dự báo đến năm 2028 chi phí AI viết code sẽ vượt mức lương trung bình của một lập trình viên. Lý do được nêu gồm lượng token tiêu thụ tăng, việc chuyển từ giấy phép theo ghế sang tính theo mức dùng, thiếu quản trị mức dùng (agent tự chạy, ngữ cảnh phình to) và việc các nhà cung cấp chưa có công cụ tối ưu chi phí hoàn chỉnh. Bản đăng lại không nêu con số phần trăm hay đô la cho phép so sánh đó, nên hãy coi đây là dự báo hướng đi, không phải con số đo được.

6.2 GitHub Copilot sang tín dụng tính theo token (1/6/2026)#

Theo bài đăng của GitHub ngày 27/4/2026 mà tôi đọc qua công cụ tóm tắt trang, từ 1/6/2026 việc dùng Copilot tiêu thụ GitHub AI Credits, được tính dựa trên token tiêu thụ (đầu vào, đầu ra và token đã lưu đệm) theo giá API công bố của từng mô hình. Gói hằng tháng đi kèm mức tín dụng tương đương giá gói (ví dụ Pro 10 USD, Business 19 USD một người dùng mỗi tháng). Gợi ý hoàn thành code và gợi ý chỉnh sửa tiếp theo không tiêu tín dụng. Cơ chế lùi về mô hình rẻ hơn khi hết hạn mức bị bỏ. Trang không nêu rõ một tín dụng bằng bao nhiêu đô la (các nguồn thứ cấp nêu con số khác nhau), nên tôi không dùng con số đó.

6.3 Con số đô la mỗi dev: chỉ để tham khảo thô#

Các blog như CloudZero, Eden AI hay Exceeds AI nêu khoảng chi phí từ vài trăm đô la mỗi dev mỗi tháng đến mức cao hơn nhiều với người dùng agent nặng. Đây là các hãng bán công cụ quản lý chi phí, nên có lợi ích thương mại, và phương pháp không rõ. Tôi không dùng các con số đó để đưa ra kết luận. Hãy xem hóa đơn thật của nhóm bạn.

Điều rút ra: xu hướng rõ là từ giá cố định sang trả theo mức dùng. Cách duy nhất chắc chắn là tự đo mức dùng của mình.

7. Chỗ nào dễ phình ngân sách#

Hình dung vòi nước chảy khi không ai nhìn.

7.1 Minh họa: một buổi sáng hai cách#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật. Số liệu theo mô hình ở phần 4.

Cách một, kéo dài một cuộc trò chuyện:

• 09:00. Dev nhờ agent sửa một lỗi hiển thị và làm tiếp theo cùng cuộc trò chuyện.
• 09:45. Xong việc thứ nhất sau khoảng 15 lượt. Dev nhờ thêm một việc không liên quan trong cùng cuộc trò chuyện, vì cho rằng agent "đã hiểu dự án rồi".
• 11:30. Tổng đã khoảng 30 lượt. Với số giả định của bài, chi phí không dùng bộ nhớ đệm đã là khoảng 2,34 USD thay vì 0,72 USD cho 15 lượt.

Cách hai, đóng việc rồi mở phiên mới:

• 09:45. Xong việc thứ nhất. Dev nhờ agent tóm tắt quyết định đã chốt và tệp liên quan trong khoảng 1.000 token, rồi mở phiên mới cho việc thứ hai.
• 11:30. Hai việc xong, mỗi việc nằm trong một lịch sử ngắn. Với số giả định, hai phiên 15 lượt tốn khoảng 1,44 USD (hai lần 0,72 USD) thay vì 2,34 USD, thấp hơn khoảng 38%. Đây là phép nhân từ kết quả của script, không phải số đo thật.

Việc nên làm: đặt thói quen mở phiên mới ở ranh giới giữa hai việc, và xem trang theo dõi mức dùng cuối buổi. Minh họa này không chứng minh điều gì. Bằng chứng nằm ở cách tính tiền được ghi trong tài liệu của nhà cung cấp và khuyến nghị của Gartner ở trên.

8. Bài tập có đáp án#

Việc cần làm: chạy script ở phần 4.2 và đối chiếu.

1. Trước khi chạy, hãy đoán: chi phí 15 lượt không dùng bộ nhớ đệm gần 0,5 USD, 1 USD hay 2 USD?
2. Chạy và ghi lại bốn con số: đầu vào gửi đi, đầu ra, chi phí không dùng bộ nhớ đệm, chi phí có dùng.
3. Đổi đúng một giả định, chạy lại và so sánh. Ba gợi ý: đổi NEW_IN từ 1500 lên 3000 (một công cụ in ra nhật ký dài), đổi số lượt từ 15 lên 30, hoặc chia giá đầu vào và đầu ra cho 4.

Đáp án để đối chiếu (cùng giả định, Python 3.14.8):

Cách đọc: gấp đôi nội dung mới mỗi lượt làm chi phí tăng khoảng 50%, gấp đôi số lượt làm tăng khoảng 3,25 lần, còn đổi mô hình rẻ hơn 4 lần thì giảm đúng 4 lần (vì giá là hệ số nhân). Hãy so lời đoán ở bước 1 với kết quả thật: khoảng cách giữa hai con số cho bạn biết mình đã ước chừng thấp hay cao, và mức nào bạn dễ bỏ sót khi quên rằng lịch sử bị gửi lại.

Bài tập thật (30 phút): mở trang theo dõi mức dùng của công cụ bạn đang dùng. Chọn một việc vừa làm xong và ghi số lượt, số token đầu vào, số token đầu ra và chi phí. Nếu trang không hiển thị, hãy ghi rõ như vậy. Đó cũng là một phát hiện.

9. Danh sách kiểm: tám câu hỏi#

1. Công cụ của tôi tính tiền theo token hay theo gói cố định, và gói đó có hạn mức dùng không?
2. Tôi biết mức dùng tuần này, hay chỉ chờ hóa đơn?
3. Cuộc trò chuyện hiện tại đã bao nhiêu lượt, và việc đang làm có còn liên quan đến những lượt đầu không?
4. Tôi có đang gửi cả tệp hay nhật ký dài mà chỉ cần một phần?
5. Việc này có cần mô hình mạnh nhất, hay mô hình rẻ hơn là đủ?
6. Công cụ có đặt số bước tối đa hay giới hạn chi tiêu cho agent không?
7. Bộ nhớ đệm có bật không, và thời hạn của nó là bao lâu?
8. Chi phí của việc này so với công sửa lại và rủi ro khi sai thì thế nào?

10. Nhìn cân bằng: biết gì, chưa biết gì#

Khá chắc: các dịch vụ AI tính tiền theo token vào và ra, đầu ra thường đắt hơn mỗi token, lịch sử trò chuyện được gửi lại ở các lượt sau, và bộ nhớ đệm có thể giảm giá phần đọc lại (theo tài liệu của Anthropic và của GitHub về cách tính tiền).

Chưa rõ:

• Chi phí thực của nhóm bạn. Mô hình ở phần 4 là đơn giản hóa với giá giả định.
• Công cụ của bạn tự dùng bộ nhớ đệm đến mức nào. Tôi không kiểm chứng từng công cụ.
• Mức chênh token giữa tiếng Việt, tiếng Nhật và tiếng Anh trên các mô hình hiện nay. Nghiên cứu tôi dẫn là thời 2023 và tôi không có bộ đếm để tự đo.
• Dự báo năm 2028 của Gartner là dự báo, không phải số đo.

Đừng thổi phồng. Rẻ nhất mỗi token chưa chắc rẻ nhất mỗi việc xong. Mô hình yếu hơn có thể cần nhiều lượt hơn hoặc để lại lỗi, và công sửa lại đắt hơn tiền token. Đừng chọn mô hình theo giá mà không đo chất lượng. Bài Đo một tính năng AI nói về cách đo chất lượng, chi phí và niềm tin cùng lúc.

Đừng coi nhẹ. Chi phí là một trục thật của việc dùng agent mỗi ngày, và việc tính theo mức dùng đang lan rộng. Hãy đưa chi phí vào chính sách dùng AI một trang của nhóm, cùng với việc đòi bằng chứng ở bài Kết quả AI tự chứng minh, để tiết kiệm không làm giảm chất lượng.

Đừng dùng để so sánh đồng nghiệp. Mức dùng token phụ thuộc loại việc, không đo năng suất của một người.

11. Kết luận#

Hóa đơn AI không tăng theo số câu bạn gõ, mà theo số lần lịch sử bị đọc lại nhân với độ dày của nó. Ba việc giữ được chi phí trong tầm tay: mở phiên mới ở ranh giới giữa hai việc, dùng mô hình đúng cỡ cho từng việc, và đặt giới hạn rồi xem mức dùng mỗi tuần. Hãy chạy script một lần với số của bạn, rồi so với trang theo dõi thật.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến ngày 30/10/2026. Giá và quy tắc tính tiền thay đổi, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Anthropic, Prompt caching (hệ số ghi và đọc bộ nhớ đệm, độ dài tối thiểu, thời hạn mặc định, bảng giá ví dụ; đọc qua công cụ tóm tắt trang)
• Gartner, Gartner Predicts AI Coding Costs Will Surpass Average Developer's Salary by 2028 as Token Consumption Surges (24/6/2026, trang gốc trả lỗi 403 khi tôi mở) và bản đăng lại trên DevOps Digest (nguồn tôi thực sự đọc)
• GitHub, GitHub Copilot is moving to usage-based billing (27/4/2026, đọc qua công cụ tóm tắt trang; các nguồn thứ cấp nêu giá trị một tín dụng khác nhau nên không dùng)
• Petrov, La Malfa, Torr, Bibi, Language Model Tokenizers Introduce Unfairness Between Languages (2023)
• Khoảng chi phí mỗi dev từ blog hãng bán công cụ quản lý chi phí chỉ để tham khảo thô: CloudZero, Eden AI

Dành cho bất kỳ ai dùng AI để viết code hoặc làm việc hằng ngày, kể cả người mới. Không cần biết thống kê. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài, và tôi đã mở nguồn gốc của các số METR dùng trong bài. Ví dụ ghi là "minh họa" là số tôi dựng sẵn, không phải số đo thật của ai. Cách AI làm việc bên trong chưa ai hiểu hết, và bài này cũng không nói gì về chuyện đó: nó chỉ dạy cách đo kết quả bên ngoài. Hai nghiên cứu được dẫn là của người khác, trên công cụ và thời điểm cụ thể, không phải kết luận về bạn.

Tóm tắt nhanh#

• Cảm giác "AI giúp tôi nhanh hơn" và việc nhanh hơn thật có thể khác nhau. Trong thử nghiệm ngẫu nhiên của METR năm 2025, 16 dev kỳ cựu làm 246 việc thật. Việc được dùng AI mất lâu hơn khoảng 19%, dù các dev dự đoán trước là nhanh hơn 24% và sau đó vẫn tin là nhanh hơn khoảng 20%.
• Bản theo dõi đầu năm 2026 của METR (57 dev, hơn 800 việc) nghiêng về hướng AI giúp nhanh hơn, nhưng chính METR gọi dữ liệu là "bằng chứng rất yếu" về mức tăng, vì nhiều dev từ chối làm việc không có AI.
• Bạn có thể tự đo chính mình trong hai tuần: khoảng mười việc cùng cỡ, chia ngẫu nhiên có AI hoặc không, bấm giờ cả phần sửa lại, rồi so trung vị.
• Ba thứ dễ làm hỏng phép đo: tự chọn việc nào dùng AI, quên thời gian sửa lại, và nhìn kết quả giữa chừng rồi đổi cách làm.
• Mười việc không chứng minh được gì. Nó chỉ cho bạn một gợi ý đo được, thay vì chỉ cảm giác.
• Bài có mẫu CSV, một script Python chạy được, một ví dụ minh họa có đáp án và danh sách kiểm. Đừng dùng kết quả để đánh giá đồng nghiệp.

Từ khó, nói dễ#

Sau bài này bạn giải thích được#

1. Vì sao cảm giác nhanh hơn có thể khác số đo, và vì sao cần đồng hồ.
2. Vì sao phải chia việc ngẫu nhiên và cộng cả thời gian sửa lại thì phép đo mới tương đối công bằng.
3. Vì sao mười việc chỉ là gợi ý, và cách đọc kết quả mà không tự lừa mình.

1. Hình dung trước: đôi giày chạy bộ mới#

Hình dung bạn mua một đôi giày chạy mới. Chạy xong, bạn thấy nhẹ chân và nghĩ mình nhanh hơn. Nhưng đồng hồ nói bạn chạy chậm hơn mọi hôm hai phút, vì hôm nay trời nóng hơn và đường dốc hơn. Cảm giác là thật, đồng hồ cũng là thật, nhưng chúng đo hai thứ khác nhau.

Để biết giày có giúp không, một người cẩn thận sẽ chạy nhiều buổi, chọn ngẫu nhiên buổi nào đi đôi mới, bấm giờ mọi buổi và so với nhau. Họ cũng không chỉ tính "thời gian chạy" mà còn tính cả "thời gian bị đau chân sau đó".

Dùng AI cũng vậy. Cảm giác "đỡ phải gõ, đỡ phải nghĩ" là có thật. Nhưng thời gian từ lúc nhận việc đến lúc thật sự xong và không bị trả lại là một thứ khác. Bài này dạy cách bấm cái đồng hồ thứ hai.

Điều rút ra: để biết thứ gì đó có giúp mình hay không, đừng hỏi cảm giác. Hãy chạy một phép so sánh nhỏ và công bằng.

2. Người khác đã đo ra sao#

2.1 Thử nghiệm của METR năm 2025#

METR là một tổ chức nghiên cứu độc lập. Họ chạy một thử nghiệm ngẫu nhiên: 16 dev mã nguồn mở kỳ cựu (trung bình khoảng 5 năm kinh nghiệm với chính dự án họ làm), làm 246 việc thật như sửa lỗi, thêm tính năng, tái cấu trúc, trên các kho mã lớn (trung bình hơn 22.000 sao và hơn một triệu dòng code). Mỗi việc được chia ngẫu nhiên thành "được dùng AI" hoặc "không được dùng AI". Công cụ AI chủ yếu là Cursor Pro với Claude 3.5 và 3.7 Sonnet. Thời gian từ tháng 2 đến tháng 6/2025, mỗi việc trung bình khoảng hai giờ, dev được trả 150 USD một giờ.

Kết quả: việc được dùng AI mất lâu hơn 19%. Trước khi làm, các dev dự đoán AI sẽ giúp họ nhanh hơn 24%. Sau khi xong, họ vẫn tin AI đã giúp nhanh hơn khoảng 20%. Các chuyên gia kinh tế và học máy được hỏi dự đoán nhanh hơn khoảng 39% và 38%.

METR tự nêu các giới hạn: chỉ 16 người nên khó khái quát, có thể có thiên lệch chọn mẫu (người tin AI giúp nhiều có thể đã không đăng ký), không loại trừ hiệu ứng học dần khi dùng công cụ quá khoảng 50 giờ, thời gian một phần do dev tự báo, và chỉ áp dụng cho việc trên kho mã quen thuộc. Ngoài ra trang METR hiện gắn nhãn kết quả này đã cũ.

Điều rút ra: con số 19% không phải là "AI làm chậm bạn". Nó là một thí nghiệm trên một nhóm, công cụ và thời điểm cụ thể. Điều đáng học là khoảng cách giữa cảm giác và số đo.

2.2 Bản theo dõi đầu năm 2026#

Ngày 24/2/2026 METR đăng bài "We are Changing our Developer Productivity Experiment Design". Họ chạy lại với 57 dev (10 người cũ và 47 người mới), 143 kho mã, hơn 800 việc. Theo bài, nhóm dev cũ làm nhanh hơn khoảng 18% (khoảng tin cậy từ nhanh hơn 38% đến chậm hơn 9%), nhóm dev mới nhanh hơn khoảng 4% (từ nhanh hơn 15% đến chậm hơn 9%). Cả hai khoảng đều đi qua số 0.

Điều quan trọng hơn: METR nói dữ liệu này là "bằng chứng rất yếu" về mức tăng, vì ngày càng nhiều dev từ chối tham gia do không muốn làm việc mà không có AI (điều này nhiều khả năng làm lệch kết quả theo hướng giảm mức tăng), mức trả giảm từ 150 xuống 50 USD một giờ có thể làm thêm lệch chọn mẫu, và việc đo thời gian trở nên kém tin cậy khi dev chạy nhiều agent cùng lúc. METR vẫn cho rằng nhiều khả năng dev nhanh hơn nhờ AI so với đầu năm 2025, và đang thiết kế lại thí nghiệm.

Điều rút ra: ngay cả nhóm chuyên đo cũng phải đổi cách đo khi công cụ và thói quen thay đổi. Một con số của người khác không thay được con số của bạn.

3. Thiết kế thí nghiệm hai tuần#

Hình dung đây là một thí nghiệm nhỏ ở bếp nhà: cùng một món, nấu hai cách, nếm thử mù.

3.1 Tám bước#

1. Chọn khoảng mười việc có cỡ gần nhau. Ví dụ mỗi việc dự kiến 30 đến 90 phút. Mười việc cho hai tuần làm việc, khoảng một việc mỗi ngày.
2. Viết trước dự đoán. Ghi lại: "tôi nghĩ AI sẽ giúp tôi nhanh hơn bao nhiêu phần trăm". Đây là bước METR dùng và là bước dễ bỏ nhất.
3. Định nghĩa "xong" trước khi bắt đầu. Ví dụ: test đạt, code đã tự đọc lại, đã chạy thử. Cùng một định nghĩa cho cả hai nhóm.
4. Chia ngẫu nhiên. Tung đồng xu hoặc dùng script bên dưới. Khoảng một nửa việc làm có AI, một nửa không. Không đổi nhóm sau khi đã thấy việc.
5. Bấm giờ từ lúc bắt đầu đến lúc xong theo định nghĩa ở bước 3. Ghi giờ bắt đầu và kết thúc thật, không ước lượng.
6. Ghi cả phần sửa lại. Nếu sau đó bị trả lại, hoặc bạn nhận ra thiếu, cộng thời gian sửa vào đúng việc đó.
7. Đừng nhìn kết quả giữa chừng. Nhìn sớm sẽ khiến bạn muốn đổi cách làm hoặc chọn việc.
8. Phân tích khi đủ mười việc. So trung vị hai nhóm, rồi đối chiếu với dự đoán ở bước 2.

3.2 Mẫu CSV#

Một việc một dòng. minutes là thời gian làm đến khi xong theo định nghĩa của bạn, rework_minutes là thời gian sửa lại sau đó:

task_id,arm,minutes,rework_minutes,done_checks
T1,no_ai,70,5,pass
T2,ai,35,20,pass

Nên ghi thêm ở một nơi riêng: mô tả việc, dự đoán trước, cảm nhận sau (tăng hay giảm bao nhiêu phần trăm) và ghi chú lạ. Cảm nhận ghi trước khi mở bảng số.

3.3 Script chia việc và phân tích (chạy bằng Python 3, không cần cài gì thêm)#

Lệnh plan chia ngẫu nhiên các việc. Lệnh analyze tính trung vị, chênh lệch, một phép thử hoán vị chính xác và khoảng bootstrap 95%:

#!/usr/bin/env python3
"""Self-experiment helper: randomize which tasks use AI, then compare the times.

  python3 ai_experiment.py plan 10 [seed]    : prints a CSV with the arm of each task
  python3 ai_experiment.py analyze data.csv [--no-rework] : medians, difference, exact permutation test, bootstrap interval

Needs only the Python standard library.
"""
import csv, itertools, random, statistics, sys


def plan(n, seed=None):
    rng = random.Random(seed)
    arms = ["ai"] * (n // 2) + ["no_ai"] * (n - n // 2)
    rng.shuffle(arms)
    print("task_id,arm")
    for i, a in enumerate(arms, 1):
        print(f"T{i},{a}")


def load(path, rework=True):
    rows = list(csv.DictReader(open(path)))
    cost = lambda r: float(r["minutes"]) + (float(r["rework_minutes"]) if rework else 0)
    ai = [cost(r) for r in rows if r["arm"] == "ai"]
    no = [cost(r) for r in rows if r["arm"] == "no_ai"]
    return ai, no


def diff(a, b):
    return statistics.median(a) - statistics.median(b)


def analyze(path, rework=True, seed=1, boots=10000):
    ai, no = load(path, rework)
    obs = diff(ai, no)
    # exact permutation test: every way of choosing which tasks would have been "ai"
    pooled = ai + no
    n, k = len(pooled), len(ai)
    count = total = 0
    for idx in itertools.combinations(range(n), k):
        s = set(idx)
        a = [pooled[i] for i in s]
        b = [pooled[i] for i in range(n) if i not in s]
        total += 1
        if abs(diff(a, b)) >= abs(obs):
            count += 1
    # bootstrap interval for the difference of medians
    rng = random.Random(seed)
    ds = sorted(
        diff([rng.choice(ai) for _ in ai], [rng.choice(no) for _ in no]) for _ in range(boots)
    )
    lo, hi = ds[int(0.025 * boots)], ds[int(0.975 * boots) - 1]
    print(f"tasks with ai: {len(ai)}, without ai: {len(no)}")
    print(f"median minutes with ai:    {statistics.median(ai):.1f}")
    print(f"median minutes without ai: {statistics.median(no):.1f}")
    print(f"difference (ai - no_ai):   {obs:+.1f} min ({obs / statistics.median(no) * 100:+.0f}%)")
    print(f"exact permutation p-value: {count}/{total} = {count / total:.3f}")
    print(f"bootstrap 95% interval:    {lo:+.1f} to {hi:+.1f} min")


if __name__ == "__main__":
    cmd = sys.argv[1]
    if cmd == "plan":
        plan(int(sys.argv[2]), int(sys.argv[3]) if len(sys.argv) > 3 else None)
    elif cmd == "analyze":
        analyze(sys.argv[2], rework="--no-rework" not in sys.argv)

Khi làm thật, đừng truyền hạt giống (seed) cho lệnh plan, để bạn cũng không đoán trước được. Lưu kết quả chia ra một tệp ngay lúc chạy và không sửa lại.

4. Ví dụ tính được (minh họa, có thể bỏ qua)#

Đây là ví dụ minh họa với số tôi dựng sẵn, không phải số đo thật của ai. Tôi chạy lệnh chia việc với hạt giống 7 (chỉ để ví dụ lặp lại được), rồi bịa thời gian cho từng việc:

$ python3 ai_experiment.py plan 10 7
task_id,arm
T1,no_ai
T2,ai
T3,ai
T4,ai
T5,no_ai
T6,ai
T7,no_ai
T8,no_ai
T9,ai
T10,no_ai

Sau hai tuần, bảng sample.csv (số phút bịa) như sau:

4.1 Chạy phân tích, hai cách#

Đầu ra thật khi chạy script trên bảng trên, có tính cả phần sửa lại:

$ python3 ai_experiment.py analyze sample.csv
tasks with ai: 5, without ai: 5
median minutes with ai:    55.0
median minutes without ai: 60.0
difference (ai - no_ai):   -5.0 min (-8%)
exact permutation p-value: 252/252 = 1.000
bootstrap 95% interval:    -45.0 to +25.0 min

Và quên phần sửa lại (cờ --no-rework):

$ python3 ai_experiment.py analyze sample.csv --no-rework
tasks with ai: 5, without ai: 5
median minutes with ai:    40.0
median minutes without ai: 60.0
difference (ai - no_ai):   -20.0 min (-33%)
exact permutation p-value: 48/252 = 0.190
bootstrap 95% interval:    -50.0 to +10.0 min

4.2 Đáp án và cách đọc#

Cách đọc trung thực: trong ví dụ này, AI có vẻ nhỉnh hơn một chút, nhưng mười việc không đủ để khẳng định, và cảm giác ban đầu lớn hơn số đo. Quan trọng hơn: nếu bạn quên cộng thời gian sửa lại, bạn sẽ tin vào con số 33% đẹp hơn thực tế.

Lưu ý: đây là số bịa. Công việc thật có thể cho kết quả hoàn toàn khác, kể cả chiều ngược lại.

5. Chỗ nào phép đo hỏng#

Hình dung bạn bấm giờ chạy bộ nhưng quên bấm lúc dừng ở đèn đỏ.

5.1 Minh họa: một tuần của một dev#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.

• Thứ hai, 09:00. Dev chạy plan. Việc đầu tiên rơi vào nhóm AI. Dev ghi dự đoán: nhanh hơn 30%.
• 09:05. Bắt đầu bấm giờ, nhờ AI viết hàm làm sạch dữ liệu.
• 10:20. AI báo xong, test đạt. Dev đóng đồng hồ: 75 phút.
• 10:45. Dev đọc lại, phát hiện thiếu ca ngày trống. Mất thêm 25 phút sửa. Dev ghi vào cột sửa lại, không bỏ qua.
• Thứ sáu, 17:30. Dev hứa với mình không nhìn bảng tổng cho đến hết tuần sau, dù đã thấy vài con số đẹp.
• Thứ sáu tuần sau, 16:00. Đủ mười việc. Dev chạy phân tích, đối chiếu dự đoán, ghi kết luận: AI nhỉnh hơn ở việc có mẫu rõ, không nhỉnh ở việc cần hiểu nghiệp vụ.

Việc nên làm: cộng phần sửa lại vào đúng việc, đừng bỏ qua dù đã "gần như xong". Đây là minh họa nên không chứng minh điều gì. Bằng chứng nằm ở nghiên cứu: thử nghiệm METR ở trên là một ví dụ rằng cảm giác và số đo có thể khác nhau.

6. Số liệu và tài liệu đã dùng#

Đọc cho đúng: các nguồn trên cho thấy cảm giác và số đo có thể lệch nhau và việc đo năng suất AI rất khó. Chúng không nói AI chậm hay nhanh với bạn.

7. Danh sách kiểm: tám câu hỏi trước khi tin con số của mình#

1. Tôi đã viết dự đoán trước khi bắt đầu chưa?
2. Việc nào dùng AI do đồng xu hay script quyết định, và tôi đã lưu lại chưa?
3. Các việc có cỡ gần nhau không?
4. "Xong" được định nghĩa giống nhau cho cả hai nhóm chưa?
5. Tôi đã cộng mọi thời gian sửa lại vào đúng việc chưa?
6. Tôi có nhìn kết quả giữa chừng và đổi cách làm không?
7. Khoảng tin cậy rộng đến đâu, và tôi có kết luận vượt quá nó không?
8. Tôi chỉ dùng kết quả này để điều chỉnh cách làm của mình, không để đánh giá ai chứ?

8. Nhìn cân bằng: đo được gì, chưa đo được gì#

Đo được: một gợi ý về việc nào AI có vẻ giúp, việc nào có vẻ không, và khoảng cách giữa cảm giác của bạn với số đo.

Chưa đo được:

• Mười việc không chứng minh được gì. Khoảng tin cậy rộng, và độ khó từng việc có thể làm lệch.
• Thời gian không phải tất cả. AI có thể giúp bạn học, làm việc ít mệt hơn hoặc chịu nhận việc khó hơn, những thứ này không nằm trong đồng hồ. Ngược lại, nhanh hơn không có nghĩa là hiểu code mình giao. Xem bài Học một thư viện lạ cùng AI mà không mất tay nghề.
• Kết quả của hôm nay có thể không đúng với công cụ ba tháng sau.
• Đừng dùng kết quả để đánh giá đồng nghiệp. Mẫu nhỏ, mỗi người một loại việc, và một con số dễ bị lạm dụng. Hãy đọc Đừng đo năng suất bằng số dòng code trước khi đưa bất kỳ chỉ số nào vào nhóm.
• Nếu muốn đọc các con số về người mới vào nghề một cách cẩn thận, xem Người mới vào nghề: các con số mâu thuẫn nhau.

Đừng thổi phồng: một thí nghiệm cá nhân không phải khoa học chặt chẽ. Đừng coi nhẹ: nó vẫn tốt hơn việc chỉ tin cảm giác, và chi phí chỉ là một bảng ghi thời gian trong hai tuần. Nếu muốn kiểm tra chất lượng kết quả AI trao cho bạn, hãy đọc thêm Làm cho kết quả của AI tự chứng minh.

9. Kết luận#

Cảm giác nhanh hơn là một cảm giác. Thời gian từ lúc nhận việc đến lúc thật sự xong và không bị trả lại là một số đo. Hai thứ này có thể lệch nhau, như thử nghiệm của METR đã cho thấy ở một nhóm cụ thể. Hãy chạy một thí nghiệm nhỏ: mười việc, chia ngẫu nhiên, bấm giờ cả phần sửa lại, so trung vị, và đọc kết quả bằng đúng độ chắc của nó.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Các số của METR tôi đã mở và đối chiếu từ trang của METR và bài báo arXiv. Hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv 2507.09089) và bài blog của METR, 10/7/2025
• METR, We are Changing our Developer Productivity Experiment Design (24/2/2026)
• Python Software Foundation, tài liệu mô-đun statistics và itertools (cho trung vị và tổ hợp)

Dành cho người mới học lập trình, người làm sản phẩm, và bất kỳ ai nhờ AI sửa một trang web chậm mà chưa biết lỗi nằm ở đâu. Không cần biết mạng máy tính. Từ nào khó cũng có một hình ảnh đời thường đi kèm, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Số liệu và định nghĩa lấy từ tài liệu công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" hoặc "mô phỏng" được dựng lại, không nhắc đến người hay công ty cụ thể. Cách các hệ thống thật vận hành có nhiều chi tiết hơn bài này, nên các hình ảnh dưới đây chỉ là cách hình dung để dễ nhớ.

Nói trước điều tôi không làm được: môi trường tôi viết bài chặn việc mở cổng mạng cục bộ và chặn truy cập https ra ngoài. Vì vậy tôi không chạy được curl thật vào một máy chủ nào. Phần "ví dụ chạy thật" là một mô phỏng tôi viết và chạy thật, nhưng các độ trễ do tôi đặt sẵn, không phải đo từ mạng. Các lệnh curl trong bài được ghi rõ là "chưa chạy ở đây". Bạn chạy trên máy mình để có số thật.

Tóm tắt nhanh#

• Khi bạn mở một trang, yêu cầu đi qua nhiều chặng: tra địa chỉ, mở kết nối, bắt tay bảo mật, gửi yêu cầu, ứng dụng xử lý, cơ sở dữ liệu trả lời, phản hồi quay về. Mỗi chặng có thể chậm hoặc hỏng riêng.
• Muốn biết chặng nào chậm thì đo, đừng đoán. Lệnh curl với tùy chọn -w in ra các mốc thời gian.
• Các mốc của curl là cộng dồn từ lúc bắt đầu. Thời gian một chặng bằng mốc sau trừ mốc liền trước.
• Trong mô phỏng của bài, hai trường hợp có tổng thời gian gần nhau (0,973 giây và 1,383 giây) nhưng thủ phạm khác hẳn: một bên là chờ cơ sở dữ liệu (chiếm khoảng 83%), một bên là tra DNS (chiếm khoảng 87%).
• Mã 200 chỉ nói yêu cầu thành công về mặt giao thức. Nó không nói nội dung đúng.
• Khi nhờ AI sửa trang chậm, hãy đo trước và đưa số đo cho AI. Code do AI viết có thể ẩn nhiều truy vấn nhỏ mà mắt thường khó thấy, nhưng tôi chưa tìm thấy nghiên cứu đo tần suất này.

Sau bài này bạn giải thích được#

1. Một yêu cầu web gồm những chặng nào, và vì sao mỗi chặng có thể chậm hoặc hỏng riêng.
2. Vì sao các mốc thời gian của curl phải trừ cho nhau, và cách tính từng chặng.
3. Cách khoanh vùng lỗi nằm ở mạng, ở ứng dụng hay ở cơ sở dữ liệu trước khi nhờ AI sửa.

Từ khó, nói dễ#

1. Hình dung trước: gửi một bưu kiện#

Hình dung bạn đặt hàng từ một cửa hàng ở thành phố khác. Trước khi nhận được hàng, có bảy việc xảy ra:

1. Bạn tra danh bạ để biết địa chỉ cửa hàng (DNS).
2. Bạn gọi điện báo có đơn và chờ họ nghe máy (kết nối TCP).
3. Hai bên thống nhất dùng thùng có khóa (TLS).
4. Bạn gửi phiếu đặt hàng ghi rõ muốn gì (yêu cầu HTTP).
5. Lễ tân nhận phiếu và xử lý (ứng dụng trên máy chủ).
6. Lễ tân xuống kho tìm hàng (cơ sở dữ liệu).
7. Hàng và phiếu giao quay về tay bạn (phản hồi).

Nếu hàng đến chậm, bạn không biết ngay lỗi nằm ở đâu: ở danh bạ cũ, ở đường dây bận, ở lễ tân, hay ở kho. Người đáng tin nhất là người bấm giờ từng việc. Máy tính cũng vậy.

Tài liệu của MDN mô tả ngắn hơn, theo ví dụ con đường: thiết bị của bạn là ngôi nhà, máy chủ là cửa hàng, DNS là cuốn sổ địa chỉ, HTTP là ngôn ngữ để đặt hàng. MDN liệt kê bốn bước: tra DNS, gửi yêu cầu, nhận phản hồi, ghép thành trang. Bài này tách chi tiết hơn để bạn thấy chỗ nào đo được.

Điều rút ra: "trang chậm" không phải một lỗi. Nó là tổng của bảy chặng, và thường chỉ một chặng chiếm phần lớn thời gian.

2. Bảy chặng, từng chặng một#

Bảng dưới là bản đồ đơn giản hóa. Cột cuối cho biết chặng đó hay hỏng thế nào, để bạn nhận ra khi thấy thông báo lỗi.

2.1 Chặng 1: DNS, tra danh bạ#

Hình dung: hỏi tổng đài số điện thoại của cửa hàng. Bạn biết tên, chưa biết số.

Máy tính chỉ nói chuyện với nhau bằng địa chỉ số. Trình duyệt hỏi một máy chủ DNS để đổi tên "example.com" thành địa chỉ số. Kết quả thường được nhớ tạm (cache) một thời gian, nên lần sau nhanh hơn. Vì thế lần đo đầu tiên thường chậm hơn các lần sau.

2.2 Chặng 2 và 3: kết nối và bắt tay bảo mật#

Hình dung: gọi điện báo rồi hai bên mua chung một chiếc thùng có khóa.

Theo tài liệu MDN, HTTP chạy trên TCP và thường được mã hóa bằng TLS. HTTP cần một đường truyền đáng tin cậy, nên nó mở kết nối trước. Với địa chỉ https, có thêm bước bắt tay TLS để hai bên thỏa thuận khóa. HTTP/1.0 cũ mở một kết nối mới cho mỗi cặp yêu cầu và phản hồi, còn các phiên bản sau dùng lại kết nối, nên yêu cầu thứ hai đến cùng máy chủ thường bỏ qua chặng 1 đến 3.

2.3 Chặng 4: gửi yêu cầu HTTP#

Hình dung: tờ phiếu đặt hàng. Có tên món (đường dẫn), cách đặt (phương thức) và vài dòng ghi chú (header).

MDN mô tả một yêu cầu gồm phương thức (như GET để lấy, POST để gửi), đường dẫn tài nguyên, phiên bản HTTP, các header tùy chọn và có thể có phần thân. Ví dụ theo mẫu của MDN:

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

Phản hồi gồm phiên bản, mã trạng thái kèm vài chữ giải thích, header và có thể có thân (nội dung trang):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 29769

Năm nhóm mã trạng thái theo MDN: 1xx thông tin, 2xx thành công, 3xx chuyển hướng, 4xx lỗi từ phía bên gửi yêu cầu, 5xx lỗi từ phía máy chủ. Vài mã hay gặp: 200 thành công, 301 đã chuyển vĩnh viễn sang địa chỉ khác, 304 nội dung chưa đổi nên dùng bản đã lưu, 404 không tìm thấy, 500 lỗi chung của máy chủ, 503 tạm thời không phục vụ được.

2.4 Chặng 5 và 6: ứng dụng và cơ sở dữ liệu#

Hình dung: lễ tân đọc phiếu rồi xuống kho. Mỗi lần xuống kho mất thời gian đi và về.

Với một trang động, thời gian thường dồn nhiều vào hai chặng này. Ứng dụng chạy code của bạn, và nếu cần dữ liệu thì hỏi cơ sở dữ liệu. Mỗi lần hỏi là một chuyến đi và về, nhất là khi cơ sở dữ liệu nằm ở máy khác. Hỏi 100 lần nhỏ thường chậm hơn hỏi một lần lớn, vì phải trả tiền chuyến đi 100 lần. Phần 6 có ví dụ tính được.

2.5 Chặng 7: phản hồi quay về#

Nội dung trả về càng lớn thì càng lâu, nhất là khi chưa được nén. Đây thường là chặng ngắn nhất với trang chữ, nhưng có thể dài với ảnh lớn hoặc tệp tải xuống.

Điều rút ra: mỗi chặng có "dấu hiệu lỗi" riêng. Thông báo lỗi là manh mối nên đọc kỹ trước khi nhờ AI đoán.

3. Đo từng chặng bằng curl#

Hình dung: đặt một đồng hồ bấm giờ ở mỗi cửa trên đường đi của bưu kiện.

curl là công cụ dòng lệnh để gửi yêu cầu HTTP. Hai tùy chọn quan trọng với bài này:

• -v (verbose, nói nhiều): in toàn bộ quá trình. Theo tài liệu của curl, dòng bắt đầu bằng * là thông tin của chính curl (tra tên, kết nối), dòng bắt đầu bằng > là phần curl gửi đi, dòng bắt đầu bằng < là phần curl nhận về.
• -w (write-out, in thông số sau khi xong): in các mốc thời gian theo mẫu bạn đặt.

Năm mốc cần biết. Tất cả đều tính bằng giây và đều đếm từ lúc bắt đầu, theo tài liệu libcurl:

Lệnh mẫu (chưa chạy ở đây, vì môi trường của tôi chặn truy cập https ra ngoài; bạn chạy trên máy mình):

curl -s -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' https://example.com/

Tôi có chạy lệnh dạng này với curl 8.7.1 và curl nhận đúng các tên biến, nhưng kết nối bị chặn nên mã trả về là 000 và các số không có ý nghĩa, tôi không dùng chúng.

3.1 Công thức trừ#

Vì các mốc cộng dồn, thời gian từng chặng là:

DNS             = time_namelookup
Kết nối TCP     = time_connect       - time_namelookup
Bắt tay TLS     = time_appconnect    - time_connect
Chờ máy chủ     = time_starttransfer - time_appconnect
Tải về          = time_total         - time_starttransfer

Khi địa chỉ là http (không có TLS), bỏ dòng TLS và dùng time_connect thay cho time_appconnect ở dòng "Chờ máy chủ" (cách tính xấp xỉ).

Giới hạn quan trọng: khoảng "chờ máy chủ" gồm cả ứng dụng (chặng 5) và cơ sở dữ liệu (chặng 6). curl không tách được hai phần này. Muốn tách cần log truy vấn hoặc công cụ theo dõi chuyên dụng.

4. Ví dụ chạy thật: mô phỏng bảy chặng (có thể bỏ qua phần tính)#

Đây là mô phỏng tôi viết bằng Python 3.14.8 và chạy thật trong môi trường của mình. Mỗi chặng là một lệnh chờ do tôi đặt sẵn. Chương trình in các mốc cộng dồn giống như curl, rồi tính từng chặng bằng phép trừ. Các độ trễ là số tôi chọn, không phải đo từ mạng. Điều đo được là phép trừ có cho kết quả đúng như đã đặt hay không.

Ca A: cơ sở dữ liệu chậm (DNS 0,040 giây, kết nối 0,030, TLS 0,060, chờ máy chủ 0,800, tải về 0,020). Ca B: DNS chậm (DNS 1,200, kết nối 0,030, TLS 0,060, chờ máy chủ 0,050, tải về 0,020).

Đầu ra thật của lần chạy:

A: slow database
  time_namelookup      0.045   leg =  0.045
  time_connect         0.080   leg =  0.035
  time_appconnect      0.144   leg =  0.064
  time_starttransfer   0.949   leg =  0.805
  time_total           0.973   leg =  0.024
  longest leg: time_starttransfer (0.805 s)
B: slow DNS, fast database
  time_namelookup      1.205   leg =  1.205
  time_connect         1.240   leg =  0.035
  time_appconnect      1.305   leg =  0.065
  time_starttransfer   1.360   leg =  0.055
  time_total           1.383   leg =  0.023
  longest leg: time_namelookup (1.205 s)

Đọc kết quả:

• Ca A: chặng chờ máy chủ là 0,805 giây trên tổng 0,973, tức khoảng 83%. Con số 0,805 hơi lớn hơn 0,800 đã đặt vì lệnh chờ thật luôn dôi ra vài mili giây.
• Ca B: chặng DNS là 1,205 giây trên tổng 1,383, tức khoảng 87%. Tổng thời gian của hai ca tương đương nhau (dưới 1,4 giây), nhưng chỗ cần sửa hoàn toàn khác.
• Nếu chỉ nhìn time_total, bạn không phân biệt được hai ca. Sửa cơ sở dữ liệu ở ca B sẽ không giúp gì.

Lưu ý rõ: đây là mô phỏng với độ trễ do tôi đặt, nó chứng minh cách tính, không chứng minh mạng thật trông thế nào. Số thật trên máy bạn sẽ khác.

4.1 Truy vấn thừa: đếm thật, thời gian giả định#

Ví dụ thứ hai cũng chạy thật, bằng Python và SQLite 3.53.4 trong bộ nhớ. Có 50 khách hàng và 200 đơn. Cách một: hỏi danh sách khách rồi hỏi từng khách một truy vấn riêng. Cách hai: một truy vấn có phép nối (join) và gom nhóm.

same answer: True
queries, one per row: 51
queries, one join   : 1
waiting for the database at 5 ms per query: 255 ms vs 5 ms

Hai cách ra cùng kết quả, nhưng một cách tốn 51 truy vấn và cách kia tốn 1. Con số đếm là thật. Con số 5 mili giây mỗi lượt đi về là giả định của tôi cho một cơ sở dữ liệu ở máy khác (SQLite trong bộ nhớ gần như không có độ trễ mạng). Với giả định đó, 51 truy vấn chờ 255 mili giây còn 1 truy vấn chờ 5 mili giây. Kiểu này gọi là N+1 (một truy vấn lấy danh sách, rồi N truy vấn cho từng dòng).

Điều rút ra: khi chặng "chờ máy chủ" dài, câu hỏi đầu tiên không phải "truy vấn nào chậm" mà là "trang này gửi bao nhiêu truy vấn".

5. Bài tập có đáp án#

Bài tập này dùng một máy chủ giả chạy trên máy bạn. Tôi chưa chạy được máy chủ này vì môi trường của tôi chặn việc mở cổng mạng (lệnh mở cổng báo "Operation not permitted"). Tôi chỉ kiểm tra được code biên dịch được. Đáp án bên dưới suy ra từ cách tôi viết code, nên bạn hãy chạy thật và so với đáp án.

5.1 Máy chủ giả#

Lưu thành slow_app.py:

import time
from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/slow":
            time.sleep(0.8)          # giả lập truy vấn chậm
            body = b"orders: 3\n"
        elif self.path == "/missing":
            self.send_response(404)
            self.send_header("Content-Length", "0")
            self.end_headers()
            return
        else:
            body = b"hello\n"
        self.send_response(200)
        self.send_header("Content-Type", "text/plain")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)
    def log_message(self, *a):
        pass

HTTPServer(("127.0.0.1", 8765), Handler).serve_forever()

Chạy python3 slow_app.py ở một cửa sổ terminal, và dùng cửa sổ khác cho các lệnh dưới đây.

5.2 Bài 1: tìm chặng chậm#

curl -s -o /dev/null -w 'tcp=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' http://127.0.0.1:8765/slow
curl -s -o /dev/null -w 'tcp=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' http://127.0.0.1:8765/

Câu hỏi: ở mỗi lệnh, chặng nào chiếm gần hết thời gian? Tính bằng phép trừ.

Đáp án (suy ra từ code, hãy so với số của bạn): lệnh đầu có first_byte trừ tcp xấp xỉ 0,8 giây (cộng sai số vài mili giây), vì code chờ 0,8 giây trước khi trả lời. Phần còn lại gần như bằng 0 vì cả hai đầu cùng một máy. Lệnh thứ hai không có chờ, nên mọi số đều rất nhỏ. Vì địa chỉ là http, không có TLS, bạn dùng time_connect thay cho time_appconnect.

5.3 Bài 2: mã 404 và thời gian#

curl -s -o /dev/null -w 'code=%{http_code} total=%{time_total}\n' http://127.0.0.1:8765/missing

Đáp án: code=404 và thời gian rất nhỏ. Bài học: một phản hồi lỗi vẫn có thể nhanh. Thời gian ngắn không có nghĩa là đúng.

5.4 Bài 3: một lần đo là chưa đủ#

Chạy lệnh của bài 1 (đường /slow) năm lần rồi ghi các giá trị first_byte. Lấy số ở giữa khi xếp từ nhỏ đến lớn (trung vị).

Đáp án: các số nên gần 0,8 giây nhưng lệch nhau vài mili giây. Trên mạng thật, độ lệch lớn hơn nhiều, nên đừng kết luận từ một lần đo.

5.5 Thử thêm với https (chưa chạy ở đây)#

curl -v https://example.com/ -o /dev/null
curl -s -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Trong lệnh -v, tìm các dòng * (kết nối và bắt tay), dòng > (phiếu đặt hàng curl gửi) và dòng < (phiếu trả hàng). Với lệnh -w, áp dụng công thức ở phần 3.1. Lần chạy đầu thường có DNS chậm hơn, lần hai thường nhanh hơn do bộ nhớ tạm.

6. Chỗ dễ nhầm#

Hình dung kiểm tra bưu kiện: biết hàng đến chậm chưa đủ, phải biết chậm ở cửa nào.

7. Minh họa: một buổi sáng với trang báo cáo chậm#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật. Tên, số lượng và thời gian là dựng lại.

• 09:30. Người dùng báo trang báo cáo mất khoảng 3 giây để hiện.
• 09:40. Dev nhờ agent: "Làm cho truy vấn nhanh hơn." Agent thêm một chỉ mục và báo "đã tối ưu".
• 10:05. Trang vẫn chậm. Dev chạy curl với -w và thấy tcp=0,02, first_byte=3,05, total=3,08. Chờ máy chủ chiếm gần 3 giây. DNS, kết nối và tải về đều không đáng kể.
• 10:15. Dev bật log truy vấn: một lần tải trang gửi 601 truy vấn (1 truy vấn lấy danh sách và 600 truy vấn cho từng dòng). Mỗi truy vấn chờ khoảng 5 mili giây vì cơ sở dữ liệu ở máy khác. Phép tính: 601 nhân 5 mili giây bằng 3.005 mili giây, khớp với khoảng 3 giây.
• 10:50. Dev nhờ agent gộp thành một truy vấn có phép nối, kèm yêu cầu in số truy vấn trước và sau. first_byte giảm xuống còn khoảng 0,1 giây (số giả định của ví dụ).

Việc nên làm: đo trước, rồi đưa số đo cho AI. Nếu chỉ nói "làm nhanh hơn", AI có thể sửa sai chỗ, như thêm chỉ mục cho một truy vấn vốn không phải thủ phạm, và vẫn báo xong. Hãy đòi bằng chứng như trong bài Làm cho kết quả của AI tự chứng minh: số truy vấn và số first_byte trước và sau.

Minh họa này không chứng minh điều gì về tần suất. Bằng chứng nằm ở chỗ khác: phần 4.1 đếm thật 51 truy vấn so với 1 cho cùng một kết quả. Còn việc code do AI viết có hay gây N+1 hay không thì tôi chưa tìm thấy nghiên cứu đo trực tiếp. Một nghiên cứu năm 2025 (Unveiling Inefficiencies in LLM-Generated Code) phân tích 492 đoạn code nhỏ do ba mô hình mã nguồn mở sinh ra trên bộ HumanEval+ và thấy lỗi logic và hiệu năng là hai nhóm kém hiệu quả thường gặp, nhưng đó là bài toán thuật toán nhỏ, không phải ứng dụng web có cơ sở dữ liệu. Hãy coi nguy cơ N+1 là có thể xảy ra và tự đo, đừng coi là chắc chắn. Về bảo mật của code do AI viết, xem thêm bài OWASP Top 10 cho ứng dụng dùng AI.

8. Số liệu và tài liệu đã dùng#

Đọc cho đúng: các tài liệu ủng hộ cách chia chặng và cách tính. Tôi chưa đo trên mạng thật và chưa tìm thấy nghiên cứu đo N+1 trong code do AI viết.

9. Danh sách kiểm: tám câu hỏi khi trang chậm#

1. Tôi đã đo bằng số, hay đang đoán?
2. Tôi đã lấy các mốc và trừ cho nhau chưa, hay đang dùng time_total?
3. Chặng nào lớn nhất: DNS, kết nối, TLS, chờ máy chủ hay tải về?
4. Tôi đo lần đầu hay lần sau (có bộ nhớ tạm)? Đã đo nhiều lần chưa?
5. Mã trạng thái là gì, và nội dung trả về có đúng không?
6. Nếu chặng "chờ máy chủ" dài, trang này gửi bao nhiêu truy vấn?
7. Khi nhờ AI sửa, tôi đã đưa số đo cho nó và đòi số đo sau khi sửa chưa?
8. Tôi đo từ đâu, và người dùng có ở nơi tương tự không?

10. Nhìn cân bằng: bản đồ này đơn giản hóa điều gì#

Làm được: cho bạn một cách chia vấn đề, một bộ công thức đo và một thói quen kiểm trước khi nhờ AI.

Chưa làm được:

• Đây là bản đồ đơn giản hóa của HTTP/1.1 chạy trên TCP có TLS. Trong thực tế có thêm CDN (mạng phân phối nội dung), proxy, bộ cân tải. Mỗi cái thêm một chặng hoặc cắt bớt một chặng.
• HTTP/3 theo RFC 9114 chạy trên QUIC, một giao thức dùng UDP, và gộp phần kết nối với phần bắt tay bảo mật. Theo các nguồn thứ cấp tôi đọc, điều này giảm số vòng đi về lúc mở kết nối. Khi đó các mốc time_connect và time_appconnect có thể không còn tách bạch như bảng ở phần 3. Hãy đọc bản gốc RFC nếu cần chính xác.
• curl đo từ một nơi, một lần. Một lần đo là nhiễu. Công cụ theo dõi chuyên dụng (APM) thấy nhiều hơn, như tách ứng dụng với cơ sở dữ liệu.
• Mô phỏng ở phần 4 chỉ minh họa phép tính, và bài tập ở phần 5 chưa được tôi chạy thật.

Đừng thổi phồng: biết bảy chặng không biến bạn thành chuyên gia hạ tầng, nhưng đủ để hỏi đúng câu. Đừng coi nhẹ: sửa sai chỗ vẫn tốn thời gian và vẫn có người báo "đã xong".

11. Kết luận#

"Trang chậm" là tổng của nhiều chặng, và thường một chặng chiếm gần hết. Hãy đo bằng curl -w, lấy mốc sau trừ mốc trước, rồi nhìn chặng lớn nhất. Nếu đó là chờ máy chủ, đếm số truy vấn trước khi đoán. Và khi nhờ AI sửa, hãy đưa số đo cho nó, đòi số đo sau khi sửa, rồi tự mở số đó ra xem.

Nguồn tham khảo#

Định nghĩa lấy từ tài liệu công khai tính đến tháng 10/2026. Phần về HTTP/3 dựa trên nguồn thứ cấp, hãy mở bản gốc để kiểm tra trước khi trích dẫn.

• MDN, How the web works
• MDN, Tổng quan HTTP và mã trạng thái phản hồi HTTP
• curl, CURLINFO_STARTTRANSFER_TIME và CURLINFO_APPCONNECT_TIME
• Everything curl, Verbose và trang man của curl (tôi chưa đọc được phần -w của trang này, tên biến được xác nhận bằng việc chạy curl 8.7.1)
• IETF, RFC 9114 (HTTP/3) và RFC 9000 (QUIC)
• Unveiling Inefficiencies in LLM-Generated Code: Toward a Comprehensive Taxonomy, arXiv 2503.06327 (2025)

Dành cho bất kỳ ai viết hoặc đọc code, kể cả người mới. Không cần biết trước về Git nâng cao hay gỡ lỗi. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần nào cần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Mọi lệnh và kết quả trong bài đều lấy từ một lần chạy thật trên kho thử (Git 2.56.0, Python 3.14.8), có script để bạn tự tạo lại. Các hash commit sẽ khác trên máy bạn vì chúng phụ thuộc thời gian. Cách người ta gỡ lỗi giỏi thế nào chưa có một lý thuyết thống nhất, nên năm bước dưới đây là tổng hợp thực hành, không phải quy trình đã được thử nghiệm đối chứng. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể.

Tóm tắt nhanh#

• Gỡ lỗi là một kỹ năng riêng, và nó không mất đi khi có AI. Nếu chưa biết lỗi nằm đâu mà hỏi AI ngay, bạn sẽ không đủ cơ sở để phán xét câu trả lời.
• Năm bước: tái hiện lỗi chắc chắn, thu nhỏ ca lỗi, đặt một giả thuyết có thể sai, chia đôi để thu hẹp vùng nghi ngờ, rồi sửa và thêm phép thử để lỗi không quay lại.
• Bước chia đôi có công cụ sẵn trong Git là git bisect. Trong ví dụ chạy thật của bài, 19 commit nghi ngờ cần 4 lần kiểm để tìm ra thủ phạm, so với tối đa 19 lần nếu đi tuần tự.
• Thủ phạm trong ví dụ là một commit tên "refactor: simplify discount check", tức là một thay đổi trông vô hại. Lỗi chỉ là một ký tự: >= thành >.
• Sau khi làm xong năm bước, bạn đưa cho AI một báo lỗi gọn (mẫu ở cuối bài). Lúc đó AI giúp nhanh hơn và bạn kiểm được lời giải thích của nó.
• Giới hạn: cách này cần phép thử cho kết quả giống nhau mỗi lần. Lỗi phụ thuộc thời gian, dữ liệu hay môi trường khó hơn nhiều.

Từ khó, nói dễ#

Sau bài này bạn giải thích được#

1. Vì sao một lỗi cần được tái hiện và thu nhỏ trước khi sửa, và thế nào là một giả thuyết "có thể sai".
2. git bisect tìm ra commit gây lỗi nhờ chia đôi, và vì sao 19 commit chỉ cần khoảng 5 lần thử.
3. Một báo lỗi tốt cho AI gồm những gì, và vì sao nên đưa nó sau khi tự thu hẹp vùng nghi ngờ.

1. Hình dung trước: thám tử ở hiện trường#

Hình dung một thám tử đến hiện trường. Họ không lao vào bắt người đầu tiên thấy khả nghi. Họ giữ nguyên hiện trường, ghi lại điều đã xảy ra, bỏ bớt chi tiết thừa để thấy cái cốt lõi, rồi đặt một giả thuyết cụ thể: "nếu thủ phạm vào bằng cửa sau thì sẽ có dấu bùn ở sàn bếp". Họ đi kiểm đúng điều đó. Nếu sai, họ bỏ giả thuyết và thử cái khác. Cuối cùng họ có chứng cứ để người khác kiểm lại.

Gỡ lỗi cũng vậy. Mỗi bước trong năm bước dưới đây tương ứng một việc thám tử làm:

Điều rút ra: thám tử giỏi không phải người đoán đúng ngay, mà là người có cách loại dần các khả năng sai.

2. Vì sao vẫn phải học điều này khi đã có AI#

2.1 Một khảo sát cho thấy kỹ năng này vẫn được coi trọng#

Dev Barometer Q2 2026 của BairesDev (khảo sát 1.569 lập trình viên ở 77 quốc gia, gồm 1.059 dev trẻ và 510 dev cao cấp, công bố tháng 6/2026) ghi nhận 48% dev trẻ xếp giải quyết vấn đề và tư duy phân tích là kỹ năng quan trọng nhất để được tuyển, gần gấp ba mức 18% chọn thành thạo công cụ AI. Cũng trong khảo sát này, chỉ 16% dev cao cấp nói dev trẻ hiểu đầy đủ code do AI sinh ra mà họ nộp.

Cần thận trọng ba điểm. Thứ nhất, BairesDev là công ty thuê ngoài phần mềm có lợi ích thương mại trong chủ đề này. Thứ hai, trang gốc từ chối truy cập khi tôi mở, nên tôi đọc các con số qua kết quả tìm kiếm trích từ thông cáo báo chí và bộ slide của họ, chưa tự đọc bảng gốc. Thứ ba, 16% là đánh giá của dev cao cấp về dev trẻ, không phải số đo mức hiểu thật. Hãy đọc đây là một tín hiệu, không phải bằng chứng cứng.

2.2 Vì sao hỏi AI ngay có thể khiến bạn mất khả năng phán xét#

Giả sử bạn dán cả tệp lỗi cho AI và nhận về một chỗ sửa. Nếu bạn chưa biết lỗi nằm đâu, bạn chỉ còn hai lựa chọn: tin hoặc không tin. Nghiên cứu của Perry và cộng sự (Stanford, 2022) với 47 người tham gia thấy nhóm dùng trợ lý AI viết code kém an toàn hơn ở bốn trên năm bài nhưng lại tin hơn rằng code của mình an toàn. Đó là mô hình đời cũ và nhóm nhỏ, nhưng nó gợi ý một rủi ro đáng để ý: cảm giác chắc chắn không đi cùng việc đúng.

Điều rút ra: dùng AI vẫn tốt. Nhưng bạn cần tự thu hẹp vùng nghi ngờ trước, để câu trả lời của AI có thứ để đối chiếu.

3. Năm bước, kèm một ví dụ chạy thật#

Ví dụ: một chương trình tính giỏ hàng nhỏ. Quy tắc: đơn từ 100 trở lên được giảm 10%. Phép thử báo lỗi: đơn có tổng đúng 100 không được giảm. Kho có 20 commit và đúng một commit làm hỏng quy tắc. Script tạo kho ở phần 5.

Bước 1. Tái hiện: một lệnh, cùng một kết quả#

Hình dung: giữ nguyên hiện trường, không để ai dọn.

Việc đầu tiên không phải sửa, mà là có một lệnh làm lỗi xảy ra mỗi lần:

python3 test_cart.py
echo "exit=$?"

FAIL total([(50, 2)]) = 100.0, want 90.0
exit=1

Hai dòng này là hiện trường: đơn gồm 2 món giá 50 (tổng 100) phải tính ra 90.0 nhưng chương trình ra 100.0. Mã kết thúc là 1, tức "không đạt". Nếu chạy hai lần mà ra hai kết quả khác nhau thì chưa tái hiện được, và đó là việc phải giải quyết trước (xem phần giới hạn).

Bước 2. Thu nhỏ: bỏ chi tiết thừa#

Hình dung: bỏ bớt người trong phòng cho đến khi chỉ còn những người liên quan.

Thử bỏ dần từng phần của ca lỗi và hỏi: lỗi còn không? Đây là kết quả của lần chạy thật, từ một giỏ hàng lớn thu về ca nhỏ nhất:

Số dòng hàng, số món, giá từng món đều không quan trọng. Thứ còn lại là tổng trước giảm đúng bằng 100. Ca lỗi tối thiểu bây giờ là một dòng: total([(100, 1)]).

Bước 3. Đặt một giả thuyết có thể sai, và đoán kết quả trước#

Hình dung: "nếu thủ phạm vào bằng cửa sau thì sẽ có bùn ở sàn bếp".

Từ bước 2, giả thuyết: hàm giảm giá xử lý sai đúng tại biên 100. Giả thuyết tốt cho phép đoán trước. Nếu đúng thì: dưới 100 không giảm, đúng 100 lẽ ra giảm mà không giảm, trên 100 có giảm. Rồi mới chạy:

discount(99.99)   # 0.0
discount(100)     # 0.0 (lẽ ra phải là 10.0)
discount(100.01)  # 10.0

Đúng như dự đoán: giảm giá chỉ bắt đầu sau 100 chứ không phải từ 100. Giả thuyết đứng vững, và bạn biết mình đang tìm một so sánh "lớn hơn" lẽ ra là "lớn hơn hoặc bằng". Một giả thuyết mà kết quả nào cũng "khớp" thì không có ích. Nếu kết quả ở đây là discount(100) = 10.0, bạn phải bỏ giả thuyết này.

Đến đây có thể đã thấy ngay chỗ sửa. Nhưng trong dự án thật, hàm đó có thể bị đụng đến bởi nhiều người, và câu hỏi "thay đổi nào làm nó hỏng" quan trọng không kém câu hỏi "hỏng ở đâu". Đó là bước 4.

Bước 4. Chia đôi: loại một nửa vùng nghi ngờ mỗi lần#

Hình dung: đoán số từ 1 đến 100. Bạn không hỏi "có phải 1 không, có phải 2 không", mà hỏi "lớn hơn 50 không". Mỗi câu hỏi loại một nửa.

Lịch sử có 20 commit. Commit đầu chạy đúng, commit mới nhất sai. Có 19 commit nghi ngờ. git bisect chọn commit ở giữa để bạn thử, rồi loại một nửa. Đây là phiên chạy thật:

git bisect start HEAD $(git rev-list --max-parents=0 HEAD)

status: waiting for both 'good' and 'bad' commits
status: waiting for 'good' commit(s), 'bad' commit known
Bisecting: 9 revisions left to test after this (roughly 3 steps)
[5f01574] feat: add free shipping limit

Git đã chọn commit ở giữa và chuyển bạn đến đó. Bạn chạy phép thử rồi đánh dấu git bisect good hoặc git bisect bad. Với git bisect run, Git tự chạy phép thử ở mỗi bước và dựa vào mã kết thúc (0 là tốt, 1 đến 127 trừ 125 là xấu, theo tài liệu Git):

git bisect run python3 test_cart.py

running 'python3' 'test_cart.py'
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[f1da7cd] feat: add min order note
running 'python3' 'test_cart.py'
FAIL total([(50, 2)]) = 100.0, want 90.0
Bisecting: 2 revisions left to test after this (roughly 1 step)
[2004cf0] feat: add coupon placeholder
running 'python3' 'test_cart.py'
FAIL total([(50, 2)]) = 100.0, want 90.0
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[6b693ef] refactor: simplify discount check
running 'python3' 'test_cart.py'
FAIL total([(50, 2)]) = 100.0, want 90.0
6b693ef is the first 'bad' commit
commit 6b693ef

    refactor: simplify discount check

 cart.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
bisect found first 'bad' commit

Phiên này kiểm 4 lần: commit giữa (đạt), rồi ba commit đều không đạt, đến khi chỉ còn một commit. Thủ phạm là refactor: simplify discount check. Xem thay đổi của nó:

git diff 6b693ef~1 6b693ef

-    if total >= 100:
+    if total > 100:

Một ký tự. Tên commit nói là "làm gọn", nhưng nó đổi hành vi. Đây là chỗ mà tên commit và nội dung thật có thể lệch nhau, và vì sao bạn nên tìm commit bằng phép thử chứ không bằng đọc tên.

Đừng quên kết thúc phiên bằng git bisect reset để Git đưa bạn về nhánh cũ.

Chia đôi cũng dùng được ngoài Git#

Ý tưởng "loại một nửa" dùng ở mọi nơi: tạm tắt nửa số dòng của một hàm dài xem lỗi còn không, in giá trị ở giữa luồng xử lý để biết hỏng trước hay sau điểm đó, hoặc tắt một nửa số tính năng bật cờ. Mỗi lần loại một nửa đưa bạn gần hơn nhiều so với nhìn từng dòng.

Bước 5. Sửa, kiểm lại, và chặn lỗi quay lại#

Hình dung: lập hồ sơ để vụ án không mở lại.

Sửa một ký tự (> thành >=), rồi chạy phép thử:

python3 test_cart.py
echo "exit=$?"

exit=0

Đạt. Bạn cũng kiểm các biên liền kề, và kết quả thật là:

total([(99.99, 1)])   # 99.99  (không giảm)
total([(100, 1)])     # 90.0   (giảm 10%)
total([(100.01, 1)])  # 90.01  (giảm 10%)

Phép thử đã có sẵn trong kho (kiểm đơn đúng 100), nên lỗi này sẽ bị bắt nếu ai đó làm hỏng lần nữa. Nếu chưa có thì việc thêm phép thử chính là bước này: lỗi nào cũng nên để lại một phép thử cho chính nó. Cách viết phép thử tốt hơn có trong bài Kiểm thử code do AI viết.

Điều rút ra: năm bước đưa bạn từ "chương trình sai" đến "một ký tự trong một commit cụ thể", với bằng chứng ở mỗi bước. Phần còn lại là thao tác sửa.

4. Phép tính để bạn tự kiểm lại: chia đôi nhanh đến đâu (có thể bỏ qua)#

Với N commit nghi ngờ, chia đôi cần tối đa khoảng log2(N) lần kiểm, làm tròn lên. Đây là kết quả tính thật:

import math
for n in (19, 99, 999, 9999):
    print(n, math.ceil(math.log2(n)), round(math.log2(n), 2))

Trong lần chạy thật, Git cần 4 lần, không phải 5. Con số 5 là mức tối đa, số lần thật phụ thuộc vị trí của lỗi. Nếu đi tuần tự từ commit cũ nhất, bạn cần 10 lần để chạm commit 11 (thủ phạm là commit thứ 11), và tối đa 19. Lưu ý: những con số này giả định mỗi lần kiểm cho kết quả đáng tin và mỗi commit đều chạy được. Nếu một số commit không build được, Git cho phép bỏ qua chúng bằng mã 125 nhưng sẽ cần thêm lần kiểm.

5. Bài tập: tự làm lại, kèm đáp án#

Lưu script này thành make_repo.sh, chạy bash make_repo.sh. Nó tạo thư mục cart-demo với 20 commit, trong đó đúng một commit làm hỏng phép giảm giá.

#!/usr/bin/env bash
# Tạo kho thử có 20 commit, trong đó đúng một commit làm hỏng phép giảm giá.
set -e
rm -rf cart-demo
mkdir cart-demo
cd cart-demo
git init -q -b main
git config user.name "debug-demo"
git config user.email "demo@example.com"

c() { cat >> "$2"; git add -A; git commit -q -m "$1"; }   # c "thông điệp" tệp < nội dung

cat > test_cart.py <<'EOF'
import sys
from cart import total

checks = [
    ([(10, 3)], 30.0),     # dưới 100: không giảm
    ([(50, 2)], 90.0),     # đúng 100: giảm 10%
    ([(60, 2)], 108.0),    # trên 100: giảm 10%
]
bad = [(i, want, total(i)) for i, want in checks if total(i) != want]
for i, want, got in bad:
    print(f"FAIL total({i}) = {got}, want {want}")
sys.exit(1 if bad else 0)
EOF
c "feat: add subtotal, discount, total and a check" cart.py <<'EOF'
def subtotal(items):
    return sum(price * qty for price, qty in items)

def discount(total):
    if total >= 100:
        return round(total * 0.10, 2)
    return 0.0

def total(items):
    s = subtotal(items)
    return round(s - discount(s), 2)
EOF
c "feat: add shipping fee" cart.py <<'EOF'

SHIPPING = 5.0
EOF
c "docs: explain discount rule" cart.py <<'EOF'

# Giảm 10% cho đơn từ 100 trở lên.
EOF
c "feat: add currency format" cart.py <<'EOF'

def money(x):
    return f"{x:,.2f}"
EOF
c "feat: add empty cart helper" cart.py <<'EOF'

def is_empty(items):
    return len(items) == 0
EOF
c "feat: add item count" cart.py <<'EOF'

def count(items):
    return sum(qty for _, qty in items)
EOF
c "feat: add max quantity" cart.py <<'EOF'

MAX_QTY = 99
EOF
c "feat: add tax rate constant" cart.py <<'EOF'

TAX_RATE = 0.08
EOF
c "feat: add receipt title" cart.py <<'EOF'

def title(name):
    return f"Receipt for {name}"
EOF
c "feat: add free shipping limit" cart.py <<'EOF'

FREE_SHIPPING_FROM = 200
EOF
perl -pi -e 's/total >= 100/total > 100/' cart.py
git add -A; git commit -q -m "refactor: simplify discount check"
c "feat: add coupon placeholder" cart.py <<'EOF'

COUPONS = {}
EOF
c "feat: add rounding helper" cart.py <<'EOF'

def r2(x):
    return round(x, 2)
EOF
c "feat: add item label" cart.py <<'EOF'

def label(price, qty):
    return f"{qty} x {price}"
EOF
c "feat: add min order note" cart.py <<'EOF'

MIN_ORDER = 1
EOF
c "feat: add currency code" cart.py <<'EOF'

CURRENCY = "USD"
EOF
c "feat: add store name" cart.py <<'EOF'

STORE = "Demo Shop"
EOF
c "feat: add version string" cart.py <<'EOF'

VERSION = "1.0"
EOF
c "feat: add free item note" cart.py <<'EOF'

FREE_ITEM_NOTE = "none"
EOF
c "chore: add end marker" cart.py <<'EOF'

# end of file
EOF

Hãy thử trước khi đọc đáp án:

1. Vào cart-demo, chạy python3 test_cart.py và ghi lại kết quả (bước 1).
2. Thu nhỏ ca lỗi bằng tay, thử vài giá trị khác (bước 2).
3. Viết giả thuyết của bạn thành một câu, kèm kết quả bạn đoán cho ba giá trị 99.99, 100 và 100.01 (bước 3).
4. Chạy git bisect bằng tay (đánh dấu từng commit) một lần, rồi chạy lại bằng git bisect run python3 test_cart.py. Đếm số lần kiểm (bước 4).
5. Sửa, chạy lại phép thử (bước 5).

Đáp án:

• Commit gây lỗi có tên refactor: simplify discount check, là commit thứ 11 trong 20 commit.
• Thay đổi của nó: >= thành > trong hàm discount của cart.py.
• Số lần kiểm: tối đa 5, trong lần chạy của tôi là 4. Của bạn có thể là 4 hoặc 5 và hash khác, đó là bình thường.
• Một cái bẫy: phép thử phải có mặt ở mọi commit bạn kiểm. Ở đây test_cart.py có từ commit đầu nên an toàn. Nếu phép thử chỉ được thêm ở commit giữa, các commit cũ hơn sẽ báo "xấu" vì thiếu tệp, và Git kết luận sai. Cách tránh: để phép thử ngoài kho (tài liệu Git cũng khuyên giữ script kiểm ở ngoài kho) hoặc chọn commit tốt ở sau khi phép thử đã có.

6. Báo lỗi gọn cho AI: làm sau năm bước#

Sau năm bước, bạn có đủ thứ để viết một báo lỗi mà AI dùng được và bạn kiểm được. Mẫu để dán:

Lỗi: <một câu>
Tái hiện (nhỏ nhất): <lệnh hoặc dữ liệu>
Mong đợi: <kết quả đúng>
Thực tế: <đầu ra nguyên văn>
Đã loại trừ: <các giả thuyết đã thử và kết quả>
Nghi ngờ: <giả thuyết hiện tại, kèm bằng chứng>
Phạm vi: <tệp, commit nghi ngờ>
Yêu cầu: giải thích nguyên nhân trước khi sửa,
đề xuất thay đổi nhỏ nhất, và nói rõ điều gì chưa kiểm.

Với ví dụ của bài, báo lỗi điền như sau:

Lỗi: đơn có tổng đúng 100 không được giảm 10%.
Tái hiện (nhỏ nhất): total([(100, 1)])
Mong đợi: 90.0
Thực tế: 100.0
Đã loại trừ: số dòng hàng và giá từng món không ảnh hưởng.
discount(99.99) = 0.0, discount(100) = 0.0, discount(100.01) = 10.0.
Nghi ngờ: so sánh tại biên 100 trong discount().
Phạm vi: git bisect cho thấy commit "refactor: simplify discount check".
Yêu cầu: giải thích nguyên nhân trước khi sửa và đề xuất thay đổi nhỏ nhất.

Với báo lỗi này, câu trả lời đúng gần như quá rõ: AI sẽ chỉ vào so sánh ở biên. Điều quan trọng hơn: bạn kiểm được câu trả lời bằng chính phép thử và các giá trị biên đã có. Nếu AI đề xuất sửa chỗ khác, bạn biết ngay là lệch. Về cách đòi AI nộp bằng chứng cho phần sửa, xem bài Làm cho kết quả của AI tự chứng minh.

7. Chỗ người mới hay vấp#

7.1 Minh họa: một buổi sáng hai cách làm#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.

Cách một: hỏi AI ngay.

• 09:30. Một người dùng báo: "Đơn 100 đồng của tôi không được giảm." Dev dán cả tệp cart.py cho AI và hỏi cách sửa.
• 09:40. AI đề xuất thêm một điều kiện đặc biệt cho tổng bằng 100 trong hàm total. Phép thử qua, dev gộp nhánh.
• 11:15. Hàm discount vẫn dùng >, nên một chỗ khác gọi discount trực tiếp (báo cáo cuối ngày) vẫn không giảm đúng. Dev lại mất thời gian đi tìm.

Cách hai: năm bước rồi mới hỏi.

• 09:30. Cùng báo cáo. Dev chạy phép thử, thấy lỗi tái hiện được bằng một lệnh.
• 09:40. Thu nhỏ về total([(100, 1)]), đoán và thử ba giá trị biên, giả thuyết đứng vững.
• 09:50. git bisect run chỉ ra commit "refactor: simplify discount check", thay đổi một ký tự.
• 10:00. Dev đưa báo lỗi gọn cho AI để chắc không còn chỗ nào dùng cùng điều kiện, rồi sửa tại gốc, gộp nhánh.

Việc nên làm: tập thói quen thu nhỏ và đặt giả thuyết trước khi nhờ AI, để bạn kiểm được điều nó nói. Đây là minh họa nên không chứng minh điều gì. Bằng chứng nằm ở các nghiên cứu đã dẫn: Perry và cộng sự (2022) cho thấy dễ chủ quan khi dùng trợ lý AI, và khảo sát BairesDev cho thấy giải quyết vấn đề vẫn được coi trọng. Xem thêm bài Git cho người dùng agent về cách để lại các điểm lưu giúp bisect có việc để làm.

8. Tám câu hỏi trước khi đưa lỗi cho AI#

1. Tôi có một lệnh làm lỗi xảy ra mỗi lần chưa?
2. Ca lỗi đã nhỏ nhất chưa: bỏ thêm gì nữa thì lỗi biến mất?
3. Giả thuyết của tôi là gì, và tôi đã đoán trước kết quả chưa?
4. Kết quả có khớp dự đoán không, hay tôi đang gượng ép cho khớp?
5. Lỗi này có phải lỗi quay lại (từng chạy đúng) không, và có commit tốt để làm mốc chưa?
6. Tôi đã loại trừ những khả năng nào, và ghi lại chưa?
7. Báo lỗi của tôi có đủ mong đợi, thực tế nguyên văn, đã loại trừ?
8. Khi AI trả lời, tôi dùng cái gì để kiểm nó: phép thử, giá trị biên, hay chỉ cảm giác?

9. Nhìn cân bằng: cách này làm được gì, chưa làm được gì#

Làm được: biến "chương trình sai" thành một chỗ cụ thể kèm bằng chứng, thu hẹp vùng nghi ngờ rất nhanh nhờ chia đôi, giúp báo lỗi gọn và kiểm được, và để lại phép thử chặn lỗi quay lại.

Chưa làm được:

• git bisect cần phép thử cho kết quả giống nhau mỗi lần và lịch sử có các commit chạy được. Lỗi phụ thuộc thời gian, dữ liệu thật, thứ tự chạy hay môi trường khó tái hiện hơn nhiều.
• Nếu lỗi có từ commit đầu tiên thì không có commit tốt để làm mốc. Nếu lịch sử bị gộp thành vài commit lớn thì chia đôi chỉ cho bạn một khối lớn.
• Một số lỗi cần đọc code kỹ hoặc hiểu nghiệp vụ, không phải lỗi hồi quy.
• AI đôi khi tìm ra nguyên nhân nhanh hơn người, kể cả khi bạn chưa làm đủ các bước. Bài không nói là đừng hỏi AI, mà là hỏi sau để kiểm được.
• Tôi chưa tìm thấy nghiên cứu đối chứng đo xem năm bước này giúp tìm lỗi nhanh hơn bao nhiêu. Nó là tổng hợp thực hành, kèm một ví dụ chạy thật trên một kho nhỏ do tôi dựng.
• Ví dụ chạy thật chỉ có một lỗi trong một kho 20 commit nhỏ. Kho thật phức tạp hơn nhiều.

Đừng thổi phồng: năm bước không đảm bảo tìm ra mọi lỗi. Đừng coi nhẹ: chi phí của việc sửa mà không hiểu thường nằm ở lần sau, khi lỗi quay lại ở chỗ khác.

10. Kết luận#

Gỡ lỗi giống việc của thám tử: giữ hiện trường, thu nhỏ, đặt giả thuyết có thể sai, loại dần bằng cách chia đôi, rồi lập hồ sơ để lỗi không quay lại. Khi bạn đã làm những bước đó, báo lỗi cho AI trở nên ngắn, và bạn có thứ để kiểm câu trả lời của nó. Hãy thử bài tập với kho 20 commit: nó mất khoảng nửa giờ và để lại cho bạn một thói quen dùng được suốt nghề.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Mọi lệnh và kết quả trong bài chạy thật trên Git 2.56.0 và Python 3.14.8, hash commit khác nhau giữa các lần chạy.

• Git, git-bisect documentation (cách dùng, git bisect run, mã kết thúc 0, 1 đến 127 trừ 125, 125 để bỏ qua)
• BairesDev, Dev Barometer Q2 2026 và thông cáo "16 percent of juniors fully understand AI code" (khảo sát của một công ty thuê ngoài, các con số tôi đọc qua kết quả tìm kiếm vì trang gốc chặn truy cập, hãy mở bản gốc trước khi trích)
• Perry và cộng sự, Do Users Write More Insecure Code with AI Assistants? (Stanford, 2022)

Dành cho bất kỳ ai viết hoặc nhờ AI viết truy vấn SQL, kể cả người mới. Bạn chưa cần biết cơ sở dữ liệu hoạt động bên trong ra sao. Thuật ngữ nào cũng đi kèm một hình ảnh đời thường, phần script và code đánh dấu là tùy chọn nếu bạn chỉ muốn đọc kết quả.

Mọi con số trong bài đến từ một thí nghiệm tôi đã chạy thật trên SQLite 3.53.4 (bản đi kèm Python 3.14.8, macOS, chip arm64) và dán nguyên văn kết quả. Thí nghiệm nhỏ, một máy, dữ liệu sinh ngẫu nhiên, nên hãy coi nó là cách học chứ không phải bảng so sánh hiệu năng. Cách cơ sở dữ liệu chọn kế hoạch bên trong khá phức tạp, các hình dung trong bài chỉ là công cụ để nhớ, thực tế tinh tế hơn.

Tóm tắt nhanh#

• Khi truy vấn không có chỉ mục, cơ sở dữ liệu thường phải đọc từng hàng của cả bảng để tìm kết quả. Trong thí nghiệm với 100.000 sách, tìm theo một tác giả mất khoảng 2,2 ms.
• Sau khi thêm chỉ mục cho cột tác giả, cùng truy vấn mất khoảng 0,03 ms, nhanh khoảng 79 lần (các lần chạy khác cho 75 đến 82 lần).
• Chỉ mục không phải lúc nào cũng giúp. Với cột chỉ có hai giá trị (còn hàng hoặc không), truy vấn dùng chỉ mục mà vẫn mất 43,6 ms so với 39,9 ms khi quét toàn bảng.
• Với chỉ mục nhiều cột, thứ tự cột quyết định truy vấn nào dùng được chỉ mục. Chỉ mục (genre, year) không giúp truy vấn chỉ lọc theo year, còn chỉ mục (year, genre) thì giúp.
• Chỉ mục có giá: thêm 20.000 dòng chậm hơn khoảng 2,2 lần với một chỉ mục và khoảng 5 lần với ba chỉ mục, và tệp lớn thêm khoảng 2,5 MB cho chỉ mục đầu tiên.
• Cách kiểm tra rất rẻ: đọc kế hoạch truy vấn (SCAN là quét cả bảng, SEARCH là đi qua một phần). Đây cũng là bằng chứng nên đòi khi AI viết truy vấn cho bạn.

Từ khó, nói dễ#

Sau bài này bạn giải thích được#

1. Vì sao truy vấn chậm dần khi bảng lớn lên: không có chỉ mục thì thời gian tăng theo số hàng, có chỉ mục thì tăng rất chậm.
2. Một chỉ mục tốt cần ba thứ: cột đứng đầu đúng, điều kiện loại bỏ được nhiều hàng, và truy vấn không "che" cột bằng hàm hay dấu % ở đầu.
3. Mỗi chỉ mục có giá: làm ghi chậm hơn và chiếm chỗ, nên thêm khi đo được lợi ích và bỏ khi không ai dùng.

1. Hình dung trước: hộp phiếu của thư viện#

Hình dung một thư viện có 100.000 cuốn sách. Bạn cần tìm mọi cuốn của tác giả "Author 1234". Cách thứ nhất là đi dọc mọi kệ, mở từng cuốn xem tác giả là ai. Cách thứ hai là mở hộp phiếu tra cứu, nơi các phiếu đã xếp sẵn theo tên tác giả, tìm đến chữ "Author 1234" và đọc các phiếu ở đó, mỗi phiếu ghi cuốn sách nằm ở kệ nào.

Cách thứ hai nhanh hơn rất nhiều, nhưng nó có điều kiện. Hộp phiếu phải được làm, và phải được giữ đúng mỗi khi thư viện nhập sách mới. Nếu bạn hỏi theo cách hộp phiếu không xếp sẵn (ví dụ "tác giả có số 1234 ở cuối tên"), thủ thư vẫn phải đi dọc mọi kệ.

Chỉ mục trong cơ sở dữ liệu là hộp phiếu đó. Phần còn lại của bài là xem nó nhanh hơn bao nhiêu, khi nào nó không giúp, và cái giá của nó, bằng số đo thật.

Điều rút ra: chỉ mục không làm bảng nhanh lên, nó cho cơ sở dữ liệu một lối tắt khi câu hỏi khớp với cách lối tắt được xếp.

2. Thí nghiệm thật: 100.000 cuốn sách#

2.1 Chuẩn bị#

Bảng books có 100.000 hàng sinh ngẫu nhiên với seed cố định để bạn dựng lại được đúng dữ liệu: tên sách, tác giả (2.000 tác giả khác nhau, nên mỗi tác giả khoảng 50 cuốn), năm xuất bản từ 1950 đến 2024, thể loại (8 loại) và cột còn hàng (khoảng 90% bằng 1). Mỗi truy vấn chạy 200 lần và tôi lấy trung vị. Cơ sở dữ liệu chạy trong bộ nhớ (:memory:), nên con số không phản ánh ổ đĩa thật, xem phần giới hạn bên dưới.

Script đầy đủ nằm ở phần 7 để bạn chạy lại. Dưới đây là kết quả của lần chạy tôi dùng làm số liệu chính của bài.

2.2 Tìm theo một tác giả: quét toàn bảng so với chỉ mục#

SELECT * FROM books WHERE author = 'Author 1234'    (59 hàng kết quả)

Không có chỉ mục:
    plan : SCAN books
    median: 2.204 ms

Sau CREATE INDEX idx_author ON books(author):
    plan : SEARCH books USING INDEX idx_author (author=?)
    median: 0.028 ms

Kế hoạch đổi từ SCAN (quét cả bảng) sang SEARCH books USING INDEX (tra chỉ mục), và thời gian giảm từ 2,204 ms xuống 0,028 ms, tức nhanh khoảng 79 lần. Tôi chạy toàn bộ script bốn lần và tỷ lệ nằm trong khoảng 75 đến 82 lần. Tôi chỉ đo ở một cỡ bảng (100.000 hàng), nên không chứng minh được cách thời gian thay đổi khi bảng lớn hơn. Về nguyên tắc, quét phải đi qua mọi hàng nên mất nhiều thời gian hơn khi bảng lớn lên, còn tài liệu PostgreSQL mô tả việc tra chỉ mục là đi qua vài tầng của một cây tìm kiếm.

Điều rút ra: với một điều kiện loại bỏ gần hết hàng, chỉ mục cho cải thiện rất lớn.

2.3 Cột chỉ có hai giá trị: chỉ mục dùng rồi mà không nhanh hơn#

SELECT * FROM books WHERE in_stock = 1              (89.966 hàng kết quả)

Không có chỉ mục:
    plan : SCAN books
    median: 39.896 ms

Sau CREATE INDEX idx_stock ON books(in_stock):
    plan : SEARCH books USING INDEX idx_stock (in_stock=?)
    median: 43.571 ms

Ở đây kế hoạch có dùng chỉ mục (SEARCH books USING INDEX) nhưng thời gian không giảm, thậm chí chậm hơn một chút (43,571 so với 39,896 ms). Lý do hợp lý nhất: truy vấn vẫn phải lấy gần 90% số hàng, nên phần việc chính là đọc và chuyển 89.966 hàng, mà tra chỉ mục không giảm được phần đó. Đây là cách giải thích của tôi, tôi chưa tách riêng chi phí từng bước để chứng minh.

Tôi thử thêm vế còn lại: in_stock = 0 chỉ trả về 10.034 hàng (khoảng 10%). Trên cơ sở dữ liệu mới, quét mất 5,551 ms và dùng chỉ mục mất 5,029 ms, chỉ nhanh hơn khoảng 9%. Ngay cả khi truy vấn loại bỏ 90% số hàng, lợi ích còn rất nhỏ so với 79 lần ở tác giả, vì mỗi tác giả chỉ khớp 59 hàng trên 100.000.

Điều rút ra: độ chọn lọc quyết định giá trị của chỉ mục. Câu hỏi nên đặt là "điều kiện này loại bỏ bao nhiêu hàng?", không phải "cột này có hay được lọc không?". Thấy chữ USING INDEX trong kế hoạch chưa có nghĩa là nhanh.

2.4 Chỉ mục nhiều cột: thứ tự cột quyết định#

Tôi thử hai chỉ mục trên hai cột thể loại (genre) và năm (year), với hai truy vấn.

Truy vấn A: WHERE genre = 'tech' AND year >= 2020    (827 hàng)
Truy vấn B: WHERE year = 2015                        (1.321 hàng)

Không có chỉ mục nhiều cột:
    A: SCAN books                                         3.124 ms

Chỉ mục (genre, year):
    A: SEARCH books USING INDEX idx_genre_year (genre=? AND year>?)   0.437 ms
    B: SCAN books                                         2.067 ms

Chỉ mục (year, genre):
    A: SEARCH books USING INDEX idx_year_genre (year>?)     0.561 ms
    B: SEARCH books USING INDEX idx_year_genre (year=?)     0.694 ms

Đọc kết quả:

• Truy vấn A dùng được cả hai chỉ mục, nhưng chỉ mục (genre, year) dùng cả hai điều kiện (genre=? AND year>?) còn chỉ mục (year, genre) chỉ dùng được điều kiện đầu year>?. Thời gian 0,437 so với 0,561 ms: khác nhau, nhưng không nhiều.
• Chênh lệch lớn nằm ở truy vấn B. Chỉ mục (genre, year) không dùng được cho truy vấn chỉ lọc theo year (kế hoạch vẫn là SCAN, 2,067 ms), còn chỉ mục (year, genre) thì dùng được (0,694 ms).

Hình dung hộp phiếu xếp theo hai tầng: trước theo thể loại, rồi trong mỗi thể loại theo năm. Hỏi "thể loại tech, năm từ 2020" thì đi thẳng tới ngăn tech rồi đọc tiếp. Hỏi "mọi sách năm 2015" thì năm 2015 nằm rải rác ở mỗi ngăn thể loại, hộp phiếu không giúp được. Tài liệu SQLite mô tả đúng quy tắc này: các cột của chỉ mục được dùng từ trái sang phải, không được bỏ cách. Use The Index Luke (Markus Winand) so sánh nó với danh bạ xếp theo họ, nơi bạn không tra được theo tên riêng.

Một lưu ý để khỏi hiểu quá: với truy vấn lọc bằng dấu bằng trên cả hai cột (ví dụ year = 2015 AND genre = 'tech'), tôi chạy thử cả hai thứ tự và cả hai đều dùng cả hai cột, mỗi cái khoảng 0,07 ms so với 1,6 ms khi quét. Thứ tự cột quan trọng nhất khi có truy vấn chỉ lọc theo một cột, hoặc khi có điều kiện khoảng (>=, BETWEEN) trên cột đứng đầu. Tài liệu PostgreSQL còn khuyên chỉ mục nhiều cột nên dùng dè dặt và chỉ mục quá ba cột hiếm khi hữu ích, trừ khi cách dùng bảng rất đều. PostgreSQL 18 có thêm khả năng "bỏ qua cột đầu" trong một số trường hợp, nên đúng thứ tự cột ở đây là quy tắc chung chứ không phải luật cho mọi hệ thống và mọi phiên bản.

Điều rút ra: viết ra các truy vấn thật của bạn trước, rồi chọn thứ tự cột sao cho cột đứng đầu có mặt trong nhiều truy vấn nhất.

2.5 Khi một chỉ mục có sẵn mà truy vấn vẫn quét#

Tôi giữ chỉ mục idx_author và thử bốn cách hỏi tìm cùng một tác giả:

WHERE lower(author) = 'author 1234'     plan: SCAN books                  5.539 ms
WHERE author LIKE '%1234'               plan: SCAN books                  3.798 ms
WHERE author LIKE 'Author 1234%'        plan: SCAN books                  2.852 ms
WHERE author GLOB 'Author 1234*'        plan: SEARCH books USING INDEX idx_author (author>? AND author<?)   0.029 ms

• Bọc cột trong hàm (lower(author)): chỉ mục xếp theo author, không theo lower(author), nên bị bỏ qua. Như hộp phiếu xếp theo tên viết hoa nhưng bạn hỏi bằng phiên bản viết thường của tên.
• Dấu % ở đầu (LIKE '%1234'): hộp phiếu xếp theo chữ cái đầu, nên hỏi theo phần cuối không dùng được.
• LIKE với phần đầu cố định (LIKE 'Author 1234%'): theo lý thuyết có thể dùng chỉ mục, nhưng ở đây vẫn là SCAN. Theo tài liệu SQLite, mặc định LIKE không phân biệt hoa thường nên chỉ tận dụng được chỉ mục khi cột dùng kiểu so sánh NOCASE. Chỉ mục mặc định của tôi so sánh theo từng byte (BINARY) nên không dùng được. Tôi thử tạo thêm chỉ mục author COLLATE NOCASE thì kế hoạch chuyển sang SEARCH.
• GLOB phân biệt hoa thường nên khớp với chỉ mục mặc định và cho 0,029 ms.

Chi tiết này là đặc thù của SQLite. PostgreSQL có quy tắc riêng về LIKE và chỉ mục (nó phụ thuộc vào kiểu so sánh và loại chỉ mục), và tôi chưa kiểm tra trong lượt này. Bài học chung vẫn đúng: đừng đoán, hãy đọc kế hoạch.

2.6 Cái giá: ghi chậm hơn và tốn chỗ#

Thêm 20.000 hàng vào bảng 100.000 hàng (trung vị 7 lần chạy, trong bộ nhớ):

0 chỉ mục                                  6.4 ms   (x1.00)   tệp 4.98 MB
1 chỉ mục (author)                        13.9 ms   (x2.18)   tệp 7.48 MB
3 chỉ mục (author, genre+year, title)     31.8 ms   (x5.00)   tệp 12.23 MB

Mỗi lần thêm một hàng, cơ sở dữ liệu phải cập nhật bảng và từng chỉ mục. Ba chỉ mục làm việc thêm dữ liệu chậm khoảng 5 lần và tệp lớn hơn gần 2,5 lần (từ 4,98 MB lên 12,23 MB). Tài liệu PostgreSQL cũng nói chỉ mục tạo thêm chi phí cho các thao tác thay đổi dữ liệu và khuyên bỏ chỉ mục hiếm khi hoặc không bao giờ được dùng.

Lưu ý: ví dụ chạy trong bộ nhớ, chỉ có phép thêm hàng hàng loạt trong một giao dịch, không có truy cập đồng thời và không có ổ đĩa. Hệ thống thật có thể khác khá nhiều, theo cả hai hướng. Hãy dùng con số này để thấy hướng (ghi tốn hơn khi thêm chỉ mục), không để dự báo.

Điều rút ra: hãy thêm chỉ mục cho các truy vấn bạn thật sự chạy nhiều, và đo lại. Chỉ mục "cho chắc" trên mọi cột là cách trả nhiều tiền cho thứ không dùng.

3. Cách đọc kế hoạch truy vấn#

Hình dung thủ thư nói trước cách họ sẽ tìm. Trong SQLite, bạn gõ EXPLAIN QUERY PLAN trước câu truy vấn:

EXPLAIN QUERY PLAN SELECT * FROM books WHERE author = 'Author 1234';

Theo tài liệu SQLite, có hai chữ cần biết:

Ba điểm dễ nhầm:

1. SEARCH không bảo đảm nhanh (ví dụ ở 2.3, truy vấn dùng chỉ mục mà vẫn mất tương đương quét).
2. Dấu ngoặc cho biết điều kiện nào được chỉ mục dùng. Ở 2.4, (year>?) cho thấy chỉ có một nửa điều kiện được dùng.
3. Tài liệu SQLite ghi rõ định dạng đầu ra này dành cho người đọc và có thể đổi giữa các bản, nên đừng viết code phụ thuộc vào nó.

Các hệ thống khác có công cụ tương tự nhưng cách ghi khác. PostgreSQL dùng EXPLAIN (và EXPLAIN ANALYZE để chạy thật và đo), nên đừng dán nguyên cách đọc của SQLite sang đó.

4. Chỗ hay sai khi dùng chỉ mục#

Hình dung thư viện chỉ có một thủ thư: càng nhiều hộp phiếu, họ càng bận mỗi khi nhập sách.

4.1 AI viết truy vấn thì sao#

Một trợ lý AI viết truy vấn thường không biết bảng của bạn sẽ có 100 hay 100 triệu hàng, trừ khi bạn nói. Truy vấn nó viết thường đúng về kết quả và chạy nhanh trên dữ liệu thử, nên người duyệt dễ bỏ qua. Tôi chưa tìm thấy số đo độc lập về việc truy vấn do AI sinh ra thiếu chỉ mục thường xuyên đến mức nào, nên đây là cảnh báo từ cơ chế, không phải từ số liệu. Cách xử lý rẻ nhất là đòi bằng chứng, như cách 2 trong bài Làm cho kết quả của AI tự chứng minh: yêu cầu AI dán kế hoạch truy vấn thật và số hàng giả định.

5. Minh họa: một truy vấn ổn lúc đầu, chậm sau vài tháng#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật, và các con số mở rộng là phép nhân tôi đặt ra, không phải số đo.

• 10:00. Dev nhờ agent: "Thêm màn tìm sách theo tác giả."
• 10:20. Agent viết truy vấn WHERE author = ?, thử trên 1.000 sách và chạy dưới 1 ms. Dev duyệt vì kết quả đúng và test xanh.
• Ba tháng sau, 09:30. Kho đã có 5 triệu sách. Nếu thời gian quét tăng đều theo số hàng (một giả định để minh họa), 2,2 ms ở 100.000 hàng thành khoảng 110 ms ở 5 triệu hàng (2,2 nhân 50). Mỗi lượt tìm giờ chiếm cả máy một khoảng đáng kể, và khi nhiều người cùng tìm, màn hình thấy chậm.
• Cách xử lý: chạy kế hoạch truy vấn, thấy SCAN books, thêm chỉ mục cho author, đo lại. Với giả định tra chỉ mục tăng rất chậm theo số hàng, thời gian sẽ vẫn ở mức rất nhỏ.

Việc nên làm ngay từ 10:20: khi duyệt truy vấn mới, hỏi kế hoạch truy vấn và số hàng dự kiến. Tình huống minh họa không chứng minh điều gì. Bằng chứng nằm ở thí nghiệm của phần 2 và ở tài liệu PostgreSQL: chỉ mục có chi phí khi ghi, nên cần chọn có chủ đích và đo, không thêm ồ ạt. Về nhu cầu học, ITviec (qua kết quả tìm kiếm, số của chính nền tảng tuyển dụng của họ) ghi tin tuyển có yêu cầu SQL tăng khoảng 38,7% so với cùng kỳ quý 3/2025, nên đây không phải kỹ năng bị lỗi thời vì có AI.

6. Bài tập có đáp án#

Chạy script ở phần 7 một lần để có dữ liệu, rồi làm ba bài. Cố đoán kết quả trước khi chạy.

Bài 1. Thêm chỉ mục cho truy vấn WHERE year = 2015 AND genre = 'tech'. Thử cả (year, genre) và (genre, year). Chỉ mục nào dùng được cả hai điều kiện, và thời gian khác nhau ra sao?

Bài 2. Tạo chỉ mục in_stock rồi chạy WHERE in_stock = 0 và WHERE in_stock = 1. Vì sao lợi ích rất khác so với tìm theo tác giả?

Bài 3. Chạy WHERE author LIKE 'Author 1234%' khi chỉ có chỉ mục mặc định trên author. Vì sao vẫn là SCAN? Có hai cách sửa, bạn tìm được không?

Đáp án (từ lần chạy của tôi)#

Bài 1. Cả hai thứ tự đều dùng cả hai điều kiện, vì cả hai là dấu bằng:

không chỉ mục: SCAN books                                   1.602 ms (149 hàng)
(year, genre): SEARCH books USING INDEX a (year=? AND genre=?) 0.071 ms
(genre, year): SEARCH books USING INDEX b (genre=? AND year=?) 0.074 ms

Khác biệt gần như không có. Điểm cần nhớ: với truy vấn chỉ dùng dấu bằng trên mọi cột, thứ tự ít quan trọng. Thứ tự quan trọng khi có truy vấn chỉ lọc một cột (như 2.4) hoặc có khoảng.

Bài 2. Trên cơ sở dữ liệu mới cho mỗi lần đo:

in_stock = 0  (10.034 hàng): quét 5.551 ms, chỉ mục 5.029 ms
in_stock = 1  (89.966 hàng): quét 39.209 ms, chỉ mục 41.749 ms

Lợi ích rất nhỏ ở = 0 (khoảng 9%) và không có ở = 1. Việc lấy và chuyển nhiều hàng chiếm phần lớn thời gian. Bài học: độ chọn lọc, và số hàng trả về, quyết định giá trị chỉ mục. Có những truy vấn khác trên cột này vẫn hưởng lợi (ví dụ đếm số sách còn hàng có thể dùng chỉ mục bao phủ), tôi chưa đo riêng trường hợp đó trong bài.

Bài 3. Theo tài liệu SQLite, mặc định LIKE không phân biệt hoa thường, nên tối ưu LIKE chỉ dùng chỉ mục có kiểu so sánh NOCASE. Chỉ mục mặc định là BINARY nên không dùng. Hai cách sửa: viết GLOB 'Author 1234*' (GLOB phân biệt hoa thường và dùng được chỉ mục BINARY, 0,029 ms), hoặc tạo chỉ mục CREATE INDEX nc ON books(author COLLATE NOCASE) thì LIKE 'Author 1234%' chuyển sang SEARCH (tôi chạy thử: 0,029 ms).

7. Script để chạy lại (tùy chọn)#

Chỉ cần Python 3 (có sẵn thư viện sqlite3). Lưu thành index_demo.py rồi chạy python3 index_demo.py. Mất khoảng nửa phút. Con số sẽ khác tùy máy, nhưng hình dạng kết quả (SCAN so với SEARCH, thứ tự lớn nhỏ của các thời gian) nên giống.

import itertools
import random
import sqlite3
import statistics
import time

N = 100_000
REPS = 200
GENRES = ["novel", "science", "history", "children", "cooking", "tech", "poetry", "comic"]


def make_rows(n, seed):
    rnd = random.Random(seed)
    rows = []
    for i in range(n):
        rows.append((
            f"Book {rnd.randrange(10**6):06d}",
            f"Author {rnd.randrange(2000):04d}",
            rnd.randrange(1950, 2025),
            rnd.choice(GENRES),
            1 if rnd.random() < 0.9 else 0,
        ))
    return rows


def new_db(rows):
    db = sqlite3.connect(":memory:")
    db.execute("CREATE TABLE books (id INTEGER PRIMARY KEY, title TEXT, author TEXT, "
               "year INTEGER, genre TEXT, in_stock INTEGER)")
    db.executemany("INSERT INTO books (title, author, year, genre, in_stock) VALUES (?,?,?,?,?)", rows)
    db.commit()
    return db


_n = itertools.count()


def plan(db, sql):
    # the counter comment makes each EXPLAIN text unique, so Python never reuses a stale cached plan
    return [r[3] for r in db.execute(f"EXPLAIN QUERY PLAN /*{next(_n)}*/ " + sql)]


def timed(db, sql):
    samples = []
    count = 0
    for _ in range(REPS):
        t = time.perf_counter()
        count = len(db.execute(sql).fetchall())
        samples.append((time.perf_counter() - t) * 1000)
    return statistics.median(samples), count


def show(db, label, sql):
    p = plan(db, sql)
    ms, count = timed(db, sql)
    print(f"[{label}] {sql}")
    print(f"    plan : {' | '.join(p)}")
    print(f"    rows : {count}   median: {ms:.3f} ms over {REPS} runs")


rows = make_rows(N, seed=42)
db = new_db(rows)
print("SQLite", sqlite3.sqlite_version, "rows", N)
print()

print("=== 1. One author: scan then index ===")
q1 = "SELECT * FROM books WHERE author = 'Author 1234'"
show(db, "no index", q1)
db.execute("CREATE INDEX idx_author ON books(author)")
show(db, "index on author", q1)
print()

print("=== 2. A column with two values (in_stock: 90% are 1) ===")
q2 = "SELECT * FROM books WHERE in_stock = 1"
show(db, "no index", q2)
db.execute("CREATE INDEX idx_stock ON books(in_stock)")
show(db, "index on in_stock", q2)
db.execute("DROP INDEX idx_stock")
print()

print("=== 3. Two columns: order matters ===")
q3 = "SELECT * FROM books WHERE genre = 'tech' AND year >= 2020"
q4 = "SELECT * FROM books WHERE year = 2015"
show(db, "no composite index, q3", q3)
db.execute("CREATE INDEX idx_genre_year ON books(genre, year)")
show(db, "index (genre, year), q3", q3)
show(db, "index (genre, year), q4 uses year only", q4)
db.execute("DROP INDEX idx_genre_year")
db.execute("CREATE INDEX idx_year_genre ON books(year, genre)")
show(db, "index (year, genre), q3", q3)
show(db, "index (year, genre), q4 uses year only", q4)
db.execute("DROP INDEX idx_year_genre")
print()

print("=== 4. Queries an index on author cannot help ===")
q5 = "SELECT * FROM books WHERE lower(author) = 'author 1234'"
q6 = "SELECT * FROM books WHERE author LIKE '%1234'"
q7 = "SELECT * FROM books WHERE author LIKE 'Author 1234%'"
show(db, "index on author, lower()", q5)
show(db, "index on author, LIKE '%1234'", q6)
show(db, "index on author, LIKE 'Author 1234%'", q7)
q8 = "SELECT * FROM books WHERE author GLOB 'Author 1234*'"
show(db, "index on author, GLOB 'Author 1234*'", q8)
print()

print("=== 5. The price: size and inserts (20,000 new rows, 7 runs each) ===")
extra = make_rows(20_000, seed=7)


def insert_time(index_sqls):
    samples = []
    pages = 0
    for _ in range(7):
        d = new_db(rows)
        for s in index_sqls:
            d.execute(s)
        t = time.perf_counter()
        d.executemany("INSERT INTO books (title, author, year, genre, in_stock) VALUES (?,?,?,?,?)", extra)
        d.commit()
        samples.append((time.perf_counter() - t) * 1000)
        pages = d.execute("PRAGMA page_count").fetchone()[0] * d.execute("PRAGMA page_size").fetchone()[0]
        d.close()
    return statistics.median(samples), pages / (1024 * 1024)


setups = [
    ("0 indexes", []),
    ("1 index (author)", ["CREATE INDEX i1 ON books(author)"]),
    ("3 indexes (author, genre+year, title)", [
        "CREATE INDEX i1 ON books(author)",
        "CREATE INDEX i2 ON books(genre, year)",
        "CREATE INDEX i3 ON books(title)",
    ]),
]
base = None
for name, sqls in setups:
    ms, mb = insert_time(sqls)
    base = base or ms
    print(f"{name:40s} insert 20,000 rows: {ms:8.1f} ms  (x{ms / base:.2f})   size after: {mb:6.2f} MB")

8. Danh sách kiểm trước khi thêm hoặc duyệt một truy vấn#

1. Bảng này dự kiến có bao nhiêu hàng sau một năm, và tôi đã thử với cỡ đó chưa?
2. Tôi đã đọc kế hoạch truy vấn chưa? Dòng đầu là SCAN hay SEARCH?
3. Điều kiện lọc loại bỏ khoảng bao nhiêu phần trăm hàng?
4. Truy vấn có bọc cột trong hàm, hoặc dùng % ở đầu LIKE không?
5. Với chỉ mục nhiều cột, cột đứng đầu có mặt trong các truy vấn thật chưa?
6. Dấu ngoặc trong kế hoạch cho thấy chỉ mục dùng được những điều kiện nào?
7. Chi phí ghi của chỉ mục mới có chấp nhận được với bảng hay thay đổi này không?
8. Có chỉ mục cũ nào không còn xuất hiện trong kế hoạch của truy vấn thật để bỏ đi không?
9. Nếu AI viết truy vấn, nó đã dán kế hoạch và số hàng giả định cho tôi chưa?

9. Nhìn cân bằng#

Khá chắc (đã đo hoặc có tài liệu): chỉ mục có thể làm truy vấn chọn lọc nhanh hơn hàng chục lần ở cỡ 100.000 hàng; độ chọn lọc, thứ tự cột và cách viết điều kiện quyết định chỉ mục có giúp không; chỉ mục làm ghi chậm hơn và tốn chỗ.

Cần thận trọng:

• Thí nghiệm chạy trên một máy, trong bộ nhớ, với dữ liệu sinh ngẫu nhiên và phân bố đều. Dữ liệu thật thường lệch (vài tác giả có rất nhiều sách) và ổ đĩa, bộ nhớ đệm, truy cập đồng thời làm kết quả khác.
• SQLite không phải PostgreSQL hay MySQL. Mỗi hệ có bộ lập kế hoạch riêng, quy tắc LIKE riêng, các loại chỉ mục riêng và các tối ưu riêng (ví dụ PostgreSQL 18 có bỏ qua cột đầu trong một số trường hợp). Tôi không kiểm tra trực tiếp PostgreSQL trong lượt này, các điểm về nó đến từ tài liệu.
• Bài không bàn tới thống kê của bộ lập kế hoạch (ANALYZE), chỉ mục một phần, chỉ mục bao phủ sâu, cache, hay cách bảng được lưu trên đĩa. Đó là những chủ đề đáng học tiếp.
• Số 79 lần là của thí nghiệm này. Đừng dùng nó như lời hứa cho hệ thống của bạn.

Đừng thổi phồng: chỉ mục không phải thuốc chữa mọi truy vấn chậm. Đôi khi chậm vì lấy quá nhiều hàng hay cột, vì thiếu LIMIT, hoặc vì thiết kế bảng. Đừng coi nhẹ: với bảng lớn, việc không xem kế hoạch truy vấn thường là nguyên nhân rẻ nhất để sửa.

10. Kết luận#

Chỉ mục là hộp phiếu của cơ sở dữ liệu: rất nhanh khi câu hỏi khớp cách nó được xếp, vô dụng khi không khớp, và luôn tốn công giữ. Muốn dùng đúng, bạn cần ba thói quen: đọc kế hoạch truy vấn, hỏi điều kiện loại bỏ bao nhiêu hàng, và đo lại sau khi thêm. Với truy vấn do AI viết, hãy đòi chính kế hoạch đó làm bằng chứng. Những điều này có giá trị lâu hơn mọi công cụ.

Muốn đi tiếp: bài Duyệt code do AI viết có danh sách kiểm cho phần thay đổi, và bài Kiểm thử code do AI viết giúp bạn có test bảo vệ khi sửa truy vấn.

Nguồn tham khảo#

Số đo trong bài do tôi chạy trên SQLite 3.53.4 (Python 3.14.8, macOS arm64) và có thể khác trên máy của bạn. Các tài liệu bên dưới tôi đã mở để kiểm tra những điều được nêu. Con số ITviec chỉ thấy qua kết quả tìm kiếm, chưa mở báo cáo gốc.

• SQLite, The SQLite Query Optimizer Overview (quy tắc dùng chỉ mục nhiều cột từ trái sang phải, điều kiện của tối ưu LIKE và GLOB)
• SQLite, EXPLAIN QUERY PLAN (ý nghĩa của SCAN, SEARCH và USING INDEX, lưu ý định dạng có thể đổi)
• PostgreSQL, Multicolumn Indexes và Introduction to indexes (tài liệu bản 18)
• Markus Winand, Use The Index, Luke: Concatenated Indexes
• ITviec, báo cáo thị trường tuyển dụng IT Q3/2025 (chỉ thấy qua kết quả tìm kiếm, chỉ đo tin tuyển dụng trên nền tảng của họ)

Dành cho bất kỳ ai giao việc viết code cho AI agent, kể cả người mới chưa từng dùng Git. Không cần biết trước gì. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần có lệnh được đánh dấu để bạn chép theo hoặc bỏ qua.

Mọi lệnh và kết quả trong phần ví dụ đều được chạy thật trong một kho thử (Git phiên bản 2.56.0, ngày 30/10/2026). Tình huống ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Cách agent mắc lỗi bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ.

Tóm tắt nhanh#

• Agent sửa nhiều tệp trong vài phút. Nếu bạn không có điểm quay lại, một lần sửa sai có thể nuốt cả buổi làm việc. Git là điểm lưu: nó chỉ nhớ những gì bạn đã commit.
• Thói quen cốt lõi: mỗi việc giao cho agent một nhánh riêng, bắt agent commit nhỏ, và đọc git status rồi git diff trước khi nhận kết quả.
• Có bốn đường lui, mỗi đường dùng cho một hoàn cảnh: git restore (chưa commit), git revert (đã commit, an toàn nhất), git reflog (cứu sau khi lỡ tay), git worktree (để agent làm ở thư mục riêng ngay từ đầu).
• Điểm mù lớn nhất: thay đổi chưa commit mà bị git restore thì không lấy lại được. Trong kho thử của bài này, nhật ký reflog không có dòng nào cho phần đó.
• Điểm lưu chỉ bao được tệp trong kho. Một cơ sở dữ liệu bị xóa hay một email đã gửi nằm ngoài Git.
• Các lệnh hủy nguy hiểm (push --force, reset --hard, clean) nên được ghi vào hướng dẫn cho agent là không tự chạy khi chưa hỏi.

Từ khó, nói dễ#

1. Hình dung trước: trò chơi có điểm lưu#

Hình dung bạn chơi một trò chơi dài. Bạn không bấm lưu thì lỡ chết một lần là mất một giờ chơi. Còn nếu cứ vài phút bạn bấm lưu một lần, chết thì chỉ mất vài phút.

Giao việc cho agent cũng vậy. Agent là người chơi rất nhanh và hơi vội: nó có thể sửa mười tệp trước khi bạn kịp đọc tệp đầu tiên. Nó giỏi nhưng không phải lúc nào cũng đúng, và tài liệu của chính các công cụ agent nói thẳng về điều đó (xem phần 6). Điểm lưu không làm agent bớt sai. Nó làm cái sai bớt đắt.

Git đóng vai trò đó, với một quy tắc quan trọng: Git chỉ nhớ những gì đã được commit. Thay đổi nằm trong thư mục mà chưa commit giống như đang chơi giữa chặng mà chưa lưu.

Điều rút ra: trước khi giao việc, hãy có một điểm lưu sạch. Trong khi agent làm, hãy bắt nó lưu thường xuyên.

2. Quy trình năm bước: mỗi việc một nhánh#

Hình dung bàn ăn có nhiều khay: bạn không thử món mới ngay trên đĩa chính, mà bày ra một đĩa riêng. Nếu hỏng thì bỏ đĩa đó, đĩa chính vẫn nguyên.

Phần dưới đây chạy thật trong một kho thử gồm một tệp prices.py tính tổng đơn hàng. Có một điểm lưu đầu tiên trên nhánh main.

Bước 1. Tạo nhánh riêng cho việc này#

git switch -c agent/add-discount

Switched to a new branch 'agent/add-discount'

Quy ước đặt tên agent/ten-viec giúp bạn nhìn danh sách nhánh là biết nhánh nào của agent. Đây là thói quen của tôi, không phải quy định của Git.

Bước 2. Giao việc và để agent làm#

Bạn nhờ agent: "thêm tham số giảm giá tùy chọn cho hàm total". Agent sửa tệp.

Bước 3. Đọc git status rồi git diff trước khi nhận#

git status -sb
git diff

## agent/add-discount
 M prices.py
diff --git a/prices.py b/prices.py
index de87eb8..d7bc76f 100644
--- a/prices.py
+++ b/prices.py
@@ -1,2 +1,3 @@
-def total(items):
-    return sum(item["price"] * item["qty"] for item in items)
+def total(items, discount=0):
+    subtotal = sum(item["price"] * item["qty"] for item in items)
+    return subtotal * (1 - discount)

M nghĩa là một tệp đã bị sửa. Dòng bắt đầu bằng - là dòng bị xóa, dòng bắt đầu bằng + là dòng mới. Việc đọc này chính là bước "mở bằng chứng ra" ở bài Làm cho kết quả của AI tự chứng minh, và là phần đầu của việc duyệt code do AI viết.

Bước 4. Commit nhỏ, như một điểm lưu#

git add prices.py
git commit -q -m "feat: add optional discount to total"
git log --oneline

c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function

Cờ -q chỉ để lệnh im lặng. Mỗi commit một việc có thể mô tả bằng một câu, như mẫu feat: tên việc của Conventional Commits (một quy ước viết ghi chú phổ biến, không bắt buộc).

Bước 5. Gộp khi đã hài lòng#

Khi đã đọc diff và chạy kiểm tra, bạn là người gộp nhánh vào main:

git switch main
git merge --no-ff -q agent/add-discount -m "merge: add discount"
git log --oneline --graph

*   04cbf8d merge: add discount
|\  
| * 5aee66b feat: add extra script
| * c5b6fbf Revert "refactor: simplify total"
| * 6f88dd0 refactor: simplify total
| * c9c7cf3 feat: add optional discount to total
|/  
* 6dd4973 feat: add total function

Nhánh main chỉ nhận thứ bạn đã xem. Các điểm lưu giữa (refactor, Revert, extra script) đến từ các thí nghiệm ở phần 3.

2.1 Phép tính để bạn tự kiểm lại (minh họa, có thể bỏ qua)#

Đây là ví dụ với số dựng sẵn. Giả sử agent làm liên tục 3 giờ (180 phút) và có sự cố ở phút cuối.

session = 180
no_commit_loss = session            # chưa lưu lần nào: mất tối đa 180 phút
every = 20
saves = session // every            # 9 điểm lưu
worst_loss = every                  # mất tối đa 20 phút
print(saves, worst_loss, session - worst_loss)
# 9 20 160

Đọc kết quả: commit mỗi 20 phút cho 9 điểm lưu, lần sự cố tệ nhất chỉ mất tối đa 20 phút thay vì 180, tức là giữ lại 160 phút. Con số 20 phút là giả định của tôi để minh họa. Đời thật không có công thức, nhưng quy tắc là đủ nhỏ để bạn nhìn lại được và dám bỏ.

3. Quay lại: chọn đúng lệnh cho đúng hoàn cảnh#

Hình dung bạn lỡ xóa một đoạn văn. Cách lấy lại phụ thuộc vào việc bạn đã lưu tài liệu hay chưa.

3.1 git restore: hủy thay đổi chưa commit#

Agent sửa tệp thành một hàm vô dụng:

git status -sb
git diff --stat
git restore prices.py
git status -sb

## agent/add-discount
 M prices.py
 prices.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
## agent/add-discount

Sau restore, git status không còn dòng M, tức là tệp đã về đúng bản đã commit. Cảnh báo: nếu thay đổi bị hủy là thứ bạn muốn giữ, không có đường về. Tôi thử: sửa tệp, git restore, rồi xem reflog và danh sách stash.

git reflog | head -2
git stash list | wc -l

5aee66b HEAD@{0}: reset: moving to HEAD
5aee66b HEAD@{1}: reset: moving to HEAD@{1}
       0

Hai dòng reflog là của các thao tác trước đó, không có bản ghi nào cho dòng bị hủy, và danh sách stash trống (0 mục). Trang hướng dẫn git restore mô tả lệnh là khôi phục nội dung theo một nguồn nên nội dung hiện tại bị thay thế. Muốn giữ thì git stash trước, hoặc commit trước.

3.2 git revert: đảo lại một commit đã có#

Agent commit một lần "đơn giản hóa" làm hỏng hàm:

git commit -qam "refactor: simplify total"
git revert --no-edit HEAD
git log --oneline

[agent/add-discount c5b6fbf] Revert "refactor: simplify total"
 Date: Fri Oct 30 17:31:17 2026 +0700
 1 file changed, 2 insertions(+), 1 deletion(-)
c5b6fbf Revert "refactor: simplify total"
6f88dd0 refactor: simplify total
c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function

Commit hỏng vẫn nằm trong lịch sử, và một commit mới đảo lại nó. Theo tài liệu Git, git revert tạo commit mới hoàn tác các commit trước thay vì xóa chúng. Vì không viết lại lịch sử nên đây là cách an toàn với nhánh dùng chung.

3.3 git reset --hard rồi git reflog: lỡ tay vẫn cứu được commit#

Đây là phần đáng sợ nhất, nên tôi cho chạy thật. Thêm một commit rồi lùi hai bước:

git reset --hard HEAD~2
git log --oneline
ls

HEAD is now at 6f88dd0 refactor: simplify total
6f88dd0 refactor: simplify total
c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function
prices.py

Tệp extra.py biến mất khỏi thư mục, và hàm trong prices.py quay về bản hỏng. Nhưng reflog còn nhớ:

git reflog | head -8

6f88dd0 HEAD@{0}: reset: moving to HEAD~2
5aee66b HEAD@{1}: commit: feat: add extra script
c5b6fbf HEAD@{2}: revert: Revert "refactor: simplify total"
6f88dd0 HEAD@{3}: commit: refactor: simplify total
c9c7cf3 HEAD@{4}: commit: feat: add optional discount to total
6dd4973 HEAD@{5}: checkout: moving from main to agent/add-discount
6dd4973 HEAD@{6}: commit (initial): feat: add total function

Điểm lưu 5aee66b vẫn ở đó. Đặt lại về nó:

git reset --hard HEAD@{1}
git log --oneline
ls

HEAD is now at 5aee66b feat: add extra script
5aee66b feat: add extra script
c5b6fbf Revert "refactor: simplify total"
6f88dd0 refactor: simplify total
c9c7cf3 feat: add optional discount to total
6dd4973 feat: add total function
extra.py
prices.py

Mọi thứ về lại. Theo tài liệu Git, mặc định các mục reflog được giữ 90 ngày và 30 ngày với mục không còn nằm trên nhánh nào, nên hãy cứu sớm. Reflog là sổ của máy bạn, không được đẩy lên máy chủ.

3.4 git stash: cất tạm phần đang dở#

git stash push -m "half done idea"
git stash list
git stash pop

Saved working directory and index state On agent/add-discount: half done idea
stash@{0}: On agent/add-discount: half done idea
Dropped refs/stash@{0} (377cf291f166fc06e84e9ac41e27da37fa79d8d9)

Giữa hai lệnh, git status sạch. Sau pop, thay đổi quay lại. Dùng khi bạn muốn tay trống để agent làm việc khác, mà chưa muốn commit nửa vời.

Điều rút ra: nhớ một câu: đã commit thì gần như luôn cứu được, chưa commit thì không. Vì vậy mới cần commit nhỏ.

4. Worktree: cho agent một bàn làm việc riêng#

Hình dung phòng bếp có hai quầy: bạn nấu ở quầy này, đầu bếp phụ nấu ở quầy kia. Cùng một bếp, cùng một kho nguyên liệu, nhưng không đụng tay nhau.

Worktree là thư mục làm việc thứ hai của cùng một kho. Theo tài liệu Git, nó dùng chung kho với thư mục chính nhưng có HEAD và vùng chuẩn bị (index) riêng, và mặc định Git không cho hai worktree cùng đứng một nhánh.

git worktree add ../demo-git-wt -b agent/refactor-names
git worktree list

Preparing worktree (new branch 'agent/refactor-names')
HEAD is now at 5aee66b feat: add extra script
/path/to/demo-git    5aee66b [agent/add-discount]
/path/to/demo-git-wt 5aee66b [agent/refactor-names]

(Tôi rút gọn đường dẫn thành /path/to/ cho dễ đọc.) Giờ agent làm trong demo-git-wt còn bạn vẫn sửa ở thư mục chính. Xong việc thì dọn:

git worktree remove ../demo-git-wt
git branch -d agent/refactor-names

Deleted branch agent/refactor-names (was 5aee66b).

git worktree remove chỉ xóa được thư mục sạch nếu không dùng --force. Claude Code có sẵn lối tắt claude --worktree tên-việc để mở phiên làm việc trong worktree mới, theo trang Common workflows của họ. Công cụ khác có thể có cách riêng, hãy xem tài liệu của công cụ bạn dùng.

5. Luật chơi cho agent#

Hình dung đưa chìa khóa cho người giúp việc: bạn nói rõ phòng nào được vào, phòng nào không.

5.1 Các thói quen nên ghi thành luật#

• Không commit thẳng vào main. Mỗi việc một nhánh.
• Không push --force và không tự push khi chưa hỏi. Đẩy lên máy chủ là hành động mà người khác thấy.
• Không reset --hard, không clean, không xóa nhánh khi chưa hỏi. git clean xóa các tệp chưa được Git theo dõi, nên tôi coi chúng như không có bản sao để cứu.
• Không đụng tệp chứa khóa như .env. Hãy để .gitignore chặn: kiểm tra bằng git check-ignore -v .env.

git check-ignore -v .env

.gitignore:1:.env	.env

Dòng trên nói quy tắc ở dòng 1 của .gitignore đang chặn tệp .env. (Trong kho thử, môi trường của tôi không cho tạo tệp .env thật, nên tôi chỉ kiểm quy tắc chứ không thử git status với tệp có thật.)

5.2 Năm dòng dán vào hướng dẫn cho agent#

Đặt khối này trong AGENTS.md hoặc tệp hướng dẫn của công cụ:

## Git
- Làm trên nhánh agent/<tên-việc>, không commit thẳng vào main.
- Commit nhỏ, mỗi commit một việc, chạy kiểm tra trước khi commit.
- Không dùng push --force, reset --hard, clean hay xóa nhánh khi chưa hỏi.
- Không push. Không sửa .env hay tệp chứa khóa.
- Cuối việc: dán kết quả git status và git diff --stat.

Đây là hướng dẫn viết bằng lời, agent có thể bỏ qua nó. Nó là lớp chắn thứ nhất, không phải duy nhất: hãy dùng thêm quyền hạn của công cụ và tính năng bảo vệ nhánh chính của dịch vụ lưu mã nếu có.

5.3 Ghi chú commit của agent nên trông thế nào#

feat: add optional discount to total

- discount defaults to 0, so existing callers keep working
- checked with: python -m pytest tests/test_prices.py (3 passed)

Dòng đầu nói việc gì, thân bài nói vì sao và đã kiểm bằng gì. Ghi chú này tự nó là bằng chứng nhỏ, hợp với cách 2 trong bài Làm cho kết quả của AI tự chứng minh.

6. Số liệu và tài liệu đã dùng#

Đọc cho đúng: tài liệu Git và Claude Code ủng hộ việc dùng điểm lưu và nhánh riêng. Tôi chưa tìm thấy nghiên cứu đo việc dùng nhánh riêng giảm bao nhiêu sự cố khi dùng agent, nên các thói quen ở trên là thực hành tốt, chưa phải kết quả đo.

7. Chỗ nào có điểm lưu vẫn hỏng#

Hình dung bạn lưu game ở máy này nhưng nhân vật đã làm gì đó ở thế giới thật bên ngoài.

7.1 Minh họa: một sáng với agent#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.

• 09:00. Dev tạo nhánh agent/add-discount, giao việc "thêm giảm giá cho hàm tính tổng".
• 09:20. Agent báo xong. Dev chạy git diff --stat thấy một tệp đổi nhiều hơn dự kiến. Đọc kỹ thì agent đã viết lại cả hàm cũ.
• 09:25. Chưa commit, nên dev có hai lựa chọn: git restore (mất hết, kể cả phần tốt) hoặc git stash rồi chọn phần cần. Dev chọn stash, giữ lại phần tốt, rồi nhờ agent làm lại gọn hơn.
• 10:10. Agent commit lần hai. Dev nhận ra commit này làm hỏng một test và chạy git revert HEAD. Lịch sử giữ nguyên, hàm về lại như trước.
• 10:30. Dev gộp vào main sau khi đọc diff.

Việc nên làm: commit sớm, đọc diff trước khi nhận, và quen với stash và revert hơn restore và reset. Minh họa này không chứng minh điều gì. Bằng chứng nằm ở các tài liệu trên, và ở một vụ có thật đáng nhớ: các bản tin năm 2025 kể rằng trong một thử nghiệm của một nhà sáng lập, một agent bị cho là đã xóa cơ sở dữ liệu sản xuất dù đang có lệnh đóng băng mã. Các nguồn không thống nhất về chi tiết, như khả năng phục hồi, và phần lớn thông tin đến từ chính người trong cuộc. Nếu đúng như kể thì đây là chuyện của một cơ sở dữ liệu chứ không phải tệp, tức là nằm ngoài những gì điểm lưu Git bao được.

8. Thói quen áp dụng từ ngày mai#

8.1 Tám câu hỏi trước khi giao việc và trước khi nhận#

1. Mình đang ở nhánh riêng của việc này chưa, hay đang ở main?
2. Trước khi giao, git status có sạch không, có việc dở nào chưa lưu?
3. Agent biết luật Git chưa (nhánh riêng, commit nhỏ, không push)?
4. Sau khi agent làm, mình đã đọc git status và git diff chưa?
5. Có tệp nào bị sửa mà mình không nhờ không?
6. Có thứ gì giống khóa hay mật khẩu trong diff không?
7. Nếu bỏ lần sửa này, mình dùng stash, restore hay revert, và mình có đang mất thứ chưa commit không?
8. Việc này có chạm vào thứ ngoài kho (cơ sở dữ liệu, thư, API) không?

8.2 Ba việc làm ngay#

1. Dán khối năm dòng ở 5.2 vào tệp hướng dẫn của công cụ bạn đang dùng.
2. Thử một lần trong kho nháp: reset --hard rồi reflog rồi đặt lại, để lúc cần không hoảng.
3. Bật bảo vệ nhánh main trên dịch vụ lưu mã bạn dùng, nếu có.

9. Nhìn cân bằng: Git làm được gì, chưa làm được gì#

Làm được: cho bạn điểm lưu, để thử không sợ hỏng, cho phép nhiều việc chạy song song nhờ worktree, và làm mọi thay đổi của agent hiện ra dưới dạng diff đọc được.

Chưa làm được:

• Không bao được thứ ngoài kho: cơ sở dữ liệu, thư đã gửi, tiền đã chuyển.
• Không cứu được thay đổi chưa commit.
• Không ngăn agent làm điều xấu, chỉ giúp bạn quay lại sau khi chuyện xảy ra. Ngăn chặn cần quyền hạn và luật.
• Học Git có chi phí. Với người mới, vài lệnh ở bài này đã đủ để bắt đầu. Các tình huống phức tạp như xung đột khi gộp cần thêm thời gian học.
• Tôi chưa thấy thử nghiệm đối chứng đo hiệu quả của từng thói quen. Hãy thử trong nhóm bạn và điều chỉnh.

Đừng thổi phồng: Git không phải công tắc an toàn. Đừng coi nhẹ: phần lớn tai nạn khi dùng agent trên tệp đều có thể giảm xuống thành chuyện "mất 20 phút" nếu có điểm lưu gần đó.

10. Kết luận#

Agent nhanh, và nhanh cả khi sai. Hãy cho mỗi việc một nhánh riêng, bắt nó lưu thường xuyên, đọc diff trước khi nhận, và nhớ bốn đường lui: restore cho phần chưa commit (và hiểu nó là mất thật), revert cho commit đã có, reflog để cứu sau khi lỡ tay, worktree để mỗi agent có một bàn làm việc riêng. Điểm lưu không làm agent bớt sai, nhưng làm bạn bớt sợ.

Nguồn tham khảo#

Số liệu và lệnh dựa trên tài liệu công khai và một kho thử chạy ngày 30/10/2026 (Git 2.56.0). Các bản tin về vụ Replit chủ yếu thuật lại bài đăng của người trong cuộc, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Git, git-restore, git-revert, git-reflog, git-worktree
• Anthropic, Checkpointing và Common workflows, mục Run parallel sessions with worktrees
• Tom's Hardware, AI coding platform goes rogue during code freeze and deletes entire company database và heise (7/2025)
• Conventional Commits, Specification 1.0.0

Dành cho trưởng nhóm, người làm tự do, chủ doanh nghiệp nhỏ và bất kỳ ai trong nhóm vài người dùng AI để làm việc, kể cả người mới. Không cần biết pháp lý hay bảo mật. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Đây không phải tư vấn pháp lý. Số liệu lấy từ nguồn công khai, có liệt kê cuối bài, và có chỗ tôi chỉ đọc qua bản tin. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty thật. Cách AI làm việc bên trong chưa ai hiểu hết, nên các hình dung chỉ là cách tưởng tượng để dễ nhớ. Mẫu chính sách là gợi ý thực hành của tôi, không phải chuẩn bắt buộc.

Tóm tắt nhanh#

• Nhóm nhỏ thường không có luật chơi về AI. Một bản tin về khảo sát Stack Overflow 2026 ghi rằng khoảng 29,7% người trả lời để cá nhân tự quyết và khoảng 24% nói nơi làm việc có công cụ được duyệt hoặc chính sách chính thức. Đây là số đọc qua bản tin.
• Rủi ro lớn nhất thường không nằm ở chỗ AI sai, mà ở chỗ ai đó dán dữ liệu không nên dán. Năm 2023, theo tin của Bloomberg và các báo thuật lại, nhân viên Samsung bị tường thuật là đã đưa mã nguồn nội bộ lên ChatGPT, và công ty sau đó hạn chế công cụ AI tạo sinh.
• Một trang là đủ để bắt đầu: ba cột (được làm, hỏi trước, cấm), bốn mức dữ liệu nói bằng lời thường, danh sách công cụ đã duyệt, một người chịu trách nhiệm cho mỗi thay đổi AI viết, các bước khi có sự cố và ngày xem lại.
• Cách thử chính sách: lấy 20 việc thật của tuần trước và xếp vào ba cột. Nếu quá nhiều việc rơi vào "hỏi trước", chính sách đang quá chặt hoặc quá mơ hồ.
• Chính sách quá chặt khiến người ta đi vòng, quá mơ hồ khiến không ai biết làm gì, và không ai đọc thì như không có. Bài liệt kê cách nhận ra từng loại.
• Chính sách không phải bảo chứng an toàn. Nó chỉ làm cho điều cần làm trở nên rõ ràng và có người chịu trách nhiệm.

Từ khó, nói dễ#

1. Hình dung trước: nội quy bếp ăn chung#

Hình dung một căn bếp chung của sáu người. Không ai muốn đọc một cuốn quy định dày. Nhưng nếu không có gì, người này dùng chung dao thớt sống và chín, người kia để đồ ăn hết hạn trong tủ lạnh. Một tờ giấy dán cửa tủ là đủ: cái này cứ dùng, cái này hỏi trước (ví dụ nồi áp suất của bác chủ nhà), cái này không bao giờ (để bình gas mở khi ra ngoài). Tờ giấy ngắn thì người ta đọc. Có ngày xem lại thì nó không lỗi thời. Có tên người chịu trách nhiệm thì có ai để hỏi.

Chính sách dùng AI cho nhóm nhỏ cũng vậy. Mục tiêu không phải bao quát mọi tình huống, mà là cho mọi người cùng một câu trả lời cho những câu hỏi lặp lại nhiều nhất: tôi có dán cái này vào đây được không, ai đọc lại cái AI viết, nếu lỡ tay thì làm gì.

Điều rút ra: một chính sách tốt cho nhóm nhỏ là tờ giấy dán cửa tủ, không phải cuốn sổ trong ngăn kéo.

2. Vì sao cần: hai điều có dữ liệu#

2.1 Phần lớn nhóm chưa có luật chơi (khảo sát Stack Overflow 2026, qua bản tin)#

Một bản tin về khảo sát Stack Overflow Developer Survey 2026 (IT Brief) ghi rằng khoảng 29,7% người trả lời nói việc dùng AI ở nơi làm việc là tùy chọn và để cá nhân tự quyết, và chỉ khoảng 24% nói người sử dụng lao động có công cụ được duyệt hoặc chính sách hay hướng dẫn chính thức. Tôi chỉ đọc con số này qua bản tin, chưa đối chiếu bảng trong trang khảo sát, và mẫu là người chịu trả lời khảo sát, không đại diện cho mọi nhóm nhỏ. Hãy đọc là "khá nhiều nơi chưa có", không phải con số chính xác.

Điều rút ra: nếu nhóm bạn chưa có chính sách thì bạn không lạ, và khoảng trống này là chuyện thường gặp chứ không phải riêng bạn.

2.2 Một ca được tường thuật: mã nguồn lên chatbot (Samsung, 2023)#

Theo tin đầu tiên của Bloomberg vào đầu tháng 5/2023 và các báo thuật lại (Forbes, TechRadar), kỹ sư của Samsung dùng ChatGPT để xử lý lỗi trong mã nguồn và bị tường thuật là đã đưa mã nguồn nội bộ lên đó vào khoảng tháng 4/2023. Công ty sau đó gửi thông báo hạn chế dùng công cụ AI tạo sinh trên máy tính, điện thoại và mạng của công ty, cho phép dùng trên thiết bị cá nhân miễn là không đụng đến tài sản trí tuệ của công ty, và nói vi phạm có thể bị kỷ luật. Thông báo theo các tin này không nêu nội dung đoạn mã bị lộ. Các nguồn cũng không thống nhất về việc lệnh hạn chế là tạm thời hay lâu dài, và tôi chưa mở được tin gốc của Bloomberg, nên hãy giữ ở mức "theo các tin thuật lại".

Điều đáng chú ý ở đây không phải tên một công ty lớn. Chuyện này xảy ra ở một chỗ có kỹ sư giỏi: một việc rất bình thường (nhờ chatbot xem giúp lỗi) kết hợp với một thói quen rất bình thường (dán đoạn code vào) là đủ.

Điều rút ra: rủi ro ở đây nằm ở hành vi dán dữ liệu, và nó cần một quy tắc nói rõ dữ liệu nào không được dán.

3. Tờ giấy một trang: ba cột và bảy mục#

Hình dung tờ giấy dán cửa tủ, chia ba cột màu xanh, vàng, đỏ. Mỗi cột chỉ vài dòng.

3.1 Ba cột#

• Được làm (không cần hỏi): dùng công cụ đã duyệt với dữ liệu công khai và nội bộ cho các việc như giải thích, viết nháp, viết test, đổi tên, soạn tài liệu.
• Hỏi trước: dùng công cụ chưa có trong danh sách, đưa dữ liệu khách hàng vào bất kỳ công cụ nào, cho agent chạy lệnh cài, xóa hoặc triển khai, dùng AI trong phần việc khách đã nói không dùng.
• Cấm: dán khóa, mật khẩu, token và dữ liệu cá nhân thật, dùng tài khoản miễn phí cá nhân cho dữ liệu của khách, gộp code do AI viết khi chưa có người thứ hai đọc và chưa chạy kiểm.

3.2 Bốn mức dữ liệu, nói bằng lời thường#

Hình dung nhà có bốn chỗ cất đồ.

3.3 Bảy mục còn lại#

1. Công cụ đã duyệt: tên, loại tài khoản, ai duyệt, ngày duyệt, và điều khoản về dữ liệu đã đọc chưa.
2. Ai duyệt kết quả: mọi thay đổi do AI viết có một người thứ hai đọc. Cách đòi bằng chứng ở bài Làm cho kết quả của AI tự chứng minh giúp người đọc nhanh hơn.
3. Ai chịu trách nhiệm: người bấm gộp hoặc gửi cho khách là người trả lời. Xem thêm bài Ai chịu trách nhiệm khi AI sai.
4. Nói với khách: khi nào nói, nói gì, theo hợp đồng.
5. Ghi lại: việc mới dùng AI thì ghi một dòng: công cụ, mục đích, mức dữ liệu.
6. Khi có sự cố: các bước ngắn ở phần 6.
7. Ngày xem lại: thường khoảng 90 ngày sau, có tên người giữ.

3.4 Mẫu để dán và sửa#

CHÍNH SÁCH DÙNG AI CỦA NHÓM [tên nhóm]
Người giữ: [tên]    Có hiệu lực: [ngày]    Xem lại vào: [ngày + 90 ngày]

ĐƯỢC LÀM (không cần hỏi)
- Dùng công cụ trong danh sách bên dưới với dữ liệu Công khai và Nội bộ.
- Nhờ AI giải thích, viết nháp, viết test, đổi tên, soạn tài liệu.

HỎI TRƯỚC
- Dùng công cụ chưa có trong danh sách.
- Đưa dữ liệu Khách hàng vào bất kỳ công cụ AI nào.
- Cho agent chạy lệnh cài, xóa hoặc triển khai.
- Dùng AI ở phần việc mà khách đã yêu cầu không dùng.

CẤM
- Dán khóa, mật khẩu, token, dữ liệu cá nhân thật.
- Dùng tài khoản AI cá nhân miễn phí cho dữ liệu của khách.
- Gộp code AI viết khi chưa có người thứ hai đọc và chưa chạy kiểm.

DỮ LIỆU: Công khai / Nội bộ / Khách hàng / Bí mật (ví dụ ở mục 3.2)
CÔNG CỤ ĐÃ DUYỆT: [tên, loại tài khoản, người duyệt, ngày]
NGƯỜI CHỊU TRÁCH NHIỆM: người bấm gộp hoặc gửi cho khách
NÓI VỚI KHÁCH: [khi nào, thế nào]
GHI LẠI: việc mới dùng AI, một dòng (công cụ, mục đích, mức dữ liệu)
SỰ CỐ: dừng, báo trong 1 giờ, ghi lại việc đã làm, đổi khóa nếu lộ, báo khách nếu cần

4. Một ví dụ minh họa cho nhóm sáu người#

Đây là ví dụ dựng lại, không nhắc đến công ty thật. Hình dung một nhóm sáu người làm phần mềm theo hợp đồng cho vài khách. Họ điền mẫu:

• Công cụ đã duyệt: một dịch vụ trả phí của nhóm, tài khoản do trưởng nhóm tạo, người duyệt đã đọc điều khoản về việc có dùng dữ liệu của nhóm để huấn luyện hay không (cần đọc điều khoản thật của dịch vụ họ chọn). Tài khoản miễn phí cá nhân không nằm trong danh sách.
• Hỏi trước: mọi việc chạm vào dữ liệu khách, và mọi lần cho agent chạy lệnh cài hoặc deploy.
• Nói với khách: ghi trong báo giá rằng nhóm dùng AI hỗ trợ viết code, mọi thay đổi có người đọc, và dữ liệu của khách không được đưa vào công cụ nếu chưa có đồng ý.
• Xem lại: mỗi 90 ngày, trưởng nhóm giữ.

4.1 Phép thử: xếp 20 việc thật vào ba cột (minh họa, có thể bỏ qua)#

Cách thử chính sách: mỗi người liệt kê việc thật đã dùng AI tuần trước, nhóm xếp vào ba cột. Số bên dưới là số dựng sẵn để dễ tính, không phải số đo.

tasks, people, minutes_per_ask = 20, 6, 3
allowed, ask, banned = 12, 6, 2
print(allowed / tasks, ask / tasks, banned / tasks)
# 0.6 0.3 0.1
weekly = tasks * people            # 120 việc mỗi tuần cả nhóm
asks = weekly * ask / tasks        # 36 lần hỏi trước
minutes = asks * minutes_per_ask   # 108 phút
print(weekly, asks, minutes, minutes / 60)
# 120 36.0 108.0 1.8

Đọc kết quả: trong 20 việc, 12 việc (60%) được làm ngay, 6 việc (30%) cần hỏi, 2 việc (10%) bị cấm. Với 6 người, mỗi người 20 việc một tuần, có khoảng 36 lần hỏi, mất cỡ 108 phút, tức khoảng 1,8 giờ một tuần cho cả nhóm. Nếu 12 trên 20 việc (60%) rơi vào "hỏi trước" thì cùng phép tính cho 72 lần hỏi và 3,6 giờ một tuần, và người ta sẽ ngừng hỏi.

Lưu ý rõ: ba phút mỗi lần hỏi và tỷ lệ 12, 6, 2 là số giả định. Mốc "hỏi trước không nên quá khoảng một phần ba số việc" là quy tắc kinh nghiệm của tôi, không phải số đo từ nghiên cứu nào. Hãy thử với việc thật của nhóm bạn rồi chỉnh.

5. Chỗ nào chính sách cũng hỏng#

Hình dung tờ nội quy: nếu quá dài thì không ai đọc, nếu quá chặt thì người ta nấu lén, nếu quá chung chung thì ai muốn hiểu sao cũng được.

5.1 Minh họa: một buổi sáng có và không có chính sách#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.

• 10:00. Một dev cần tìm lỗi trong báo cáo xuất cho khách. Nhật ký lỗi có email và tên của người dùng cuối của khách.
• 10:05. Dev dán nguyên nhật ký vào một chatbot công cộng bằng tài khoản miễn phí cá nhân, vì chưa có ai nói không được.
• 10:30. Dev thấy trong đoạn đã dán có email thật. Không có quy trình, nên dev im lặng.
• Tuần sau. Khách hỏi về việc dữ liệu của họ đi đâu. Không ai có câu trả lời.

Phiên bản có chính sách: ở 10:05, mục "dữ liệu khách hàng thì hỏi trước" khiến dev nhắn trưởng nhóm. Họ cùng xóa email khỏi nhật ký, dùng công cụ đã duyệt và ghi một dòng. Nếu vẫn lỡ dán, bước "báo trong một giờ" cho phép nhóm xử lý sớm: ghi lại đã dán gì, đổi khóa nếu có, báo khách nếu cần.

Việc nên làm: viết mục sự cố trước khi có sự cố, vì lúc hoảng người ta ít khi nghĩ ra các bước.

Minh họa này không thay cho bằng chứng. Ca Samsung được tường thuật ở trên là một ví dụ có thật về cùng kiểu hành vi, và khảo sát Stack Overflow 2026 (qua bản tin) cho thấy khoảng trống về chính sách là phổ biến. Xem thêm bài OWASP Top 10 cho ứng dụng dùng AI cho các rủi ro kỹ thuật.

6. Khi có sự cố: năm bước ngắn#

1. Dừng: ngừng việc đang làm với công cụ đó.
2. Báo trong một giờ: cho người chịu trách nhiệm, kể cả khi chưa chắc là sự cố.
3. Ghi lại: đã đưa gì, vào công cụ nào, lúc nào.
4. Xử lý: đổi khóa nếu lộ khóa, xóa cuộc trò chuyện nếu công cụ cho phép, hỏi nhà cung cấp về việc lưu dữ liệu.
5. Nói với khách nếu hợp đồng hoặc luật yêu cầu, và rút bài học vào chính sách.

Cho phép báo cả khi "suýt lỡ". Nếu báo bị phạt thì người ta sẽ im lặng.

7. Số liệu, tiêu chuẩn và luật: đọc thế nào#

Về pháp lý: theo các nguồn tôi tìm thấy, luật được Quốc hội thông qua ngày 10/12/2025 và có hiệu lực từ 1/3/2026. Luật định nghĩa bên triển khai là tổ chức hoặc cá nhân dùng hệ thống AI trong hoạt động nghề nghiệp, thương mại hoặc cung cấp dịch vụ, và việc dùng cho mục đích cá nhân, phi thương mại không thuộc phạm vi này. Nghĩa vụ cụ thể của từng bên, quy định hướng dẫn và thời hạn chuyển tiếp tôi chưa xác minh. Nếu nhóm bạn cung cấp sản phẩm hoặc dịch vụ dùng AI cho khách, hãy đọc toàn văn luật và hỏi người làm pháp chế. Bài này chỉ giúp bạn biết cần hỏi gì.

Đọc cho đúng: các nguồn trên ủng hộ việc có luật chơi rõ và có người chịu trách nhiệm. Tôi chưa tìm thấy nghiên cứu đo riêng một chính sách một trang giúp giảm bao nhiêu sự cố. Mẫu trong bài là tổng hợp thực hành.

8. Thói quen áp dụng từ ngày mai#

8.1 Tám câu hỏi trước khi dán chính sách lên cửa#

1. Chính sách có vừa một trang không?
2. Ba cột có ví dụ cụ thể, chứ không chỉ khái niệm?
3. Bốn mức dữ liệu có ví dụ quen thuộc với nhóm mình?
4. Có danh sách công cụ đã duyệt, kèm ngày và người duyệt không?
5. Mọi thay đổi do AI viết đã có người thứ hai đọc chưa?
6. Có tên một người chịu trách nhiệm và một người giữ chính sách không?
7. Các bước sự cố đã viết ra, và báo suýt lỡ có được phép không?
8. Đã có ngày xem lại chưa?

8.2 Ba việc làm ngay#

1. Dành 30 phút điền mẫu ở mục 3.4, bỏ bớt những gì nhóm bạn không cần.
2. Chạy phép thử 20 việc ở mục 4.1 với việc thật của tuần trước.
3. Đặt ngày xem lại khoảng 90 ngày sau và ghi tên người giữ.

9. Nhìn cân bằng: chính sách làm được gì, chưa làm được gì#

Làm được: cho mọi người cùng một câu trả lời cho các câu hỏi lặp lại, giúp người mới biết làm gì, tạo chỗ để báo khi lỡ tay và để lại dấu vết khi khách hỏi.

Chưa làm được:

• Chính sách không phải bảo chứng an toàn. Người ta vẫn có thể lỡ dán, và công cụ có thể thay đổi điều khoản.
• Tôi chưa thấy nghiên cứu đo hiệu quả của chính sách một trang. Hãy tự theo dõi số lần hỏi và số sự cố suýt xảy ra.
• Một tờ giấy không thay cho đào tạo, công cụ kiểm tra và văn hóa dám báo lỗi.
• Với nhóm cung cấp dịch vụ cho khách hoặc xử lý dữ liệu cá nhân, một trang là điểm bắt đầu, không phải toàn bộ nghĩa vụ pháp lý.

Đừng thổi phồng: không có mẫu nào đúng cho mọi nhóm. Đừng coi nhẹ: khoảng trống chính sách thường lộ ra vào lúc khách hỏi, và lúc đó đã muộn để viết.

10. Kết luận#

Nhóm nhỏ không cần cuốn quy định dày, cần một tờ giấy dán cửa tủ: được, hỏi trước, cấm, bốn mức dữ liệu, một người chịu trách nhiệm, năm bước khi có sự cố và một ngày xem lại. Hãy viết ra nháp trong 30 phút, thử với 20 việc thật, và sửa sau 90 ngày.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số nguồn tôi chỉ đọc qua bản tin hoặc tóm tắt thứ cấp, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn. Đây không phải tư vấn pháp lý.

• Stack Overflow, 2026 Developer Survey và bản tin IT Brief về khảo sát (nguồn của hai con số 29,7% và 24%)
• Tin về lệnh hạn chế AI tạo sinh của Samsung (5/2023): Forbes Australia và TechRadar (thuật lại tin của Bloomberg)
• NIST, AI Risk Management Framework (AI RMF 1.0, 1/2023)
• ISO, ISO/IEC 42001:2023
• Luật Trí tuệ nhân tạo số 134/2025/QH15 trên Thư viện Pháp luật và tóm tắt của Baker McKenzie (đọc toàn văn trước khi dựa vào)

Dành cho bất kỳ ai làm việc trong một nhóm có code, kể cả người mới và người đang giao việc cho AI agent. Không cần biết thiết kế phần mềm. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Cách AI agent đọc và dùng tài liệu bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ. Các lời khuyên về AI trong bài là tổng hợp thực hành, không phải kết quả của một thử nghiệm đối chứng.

Tóm tắt nhanh#

• Phần khó nhất của một dự án thường không phải là code mà là lý do đằng sau code. Lý do hay nằm trong đầu một vài người, rồi đi mất cùng họ.
• ADR (architecture decision record, bản ghi quyết định) là một trang ngắn ghi một quyết định: bối cảnh, quyết định, hệ quả và trạng thái. Khuôn này do Michael Nygard đề xuất năm 2011, độ dài khuyến nghị là một đến hai trang.
• Người mới thiếu lý do thì chỉ còn hai đường, cả hai đều xấu: chấp nhận mà không hiểu, hoặc đảo ngược mà không biết hệ quả. Nygard mô tả đúng hai đường đó.
• AI agent cũng có thể gặp tình huống tương tự: thấy một đoạn code "rườm rà" và dọn gọn, không biết rằng sự rườm rà là có chủ ý. Một ADR được trỏ tới từ tệp hướng dẫn cho agent là chỗ để nó kiểm tra trước khi sửa.
• Một ADR tốt chỉ cần một trang: viết cho một người đọc trong tương lai, nêu cả phương án đã loại và điều ta chấp nhận đánh đổi. Bài có sẵn mẫu để dán.
• ADR không phải thủ tục cho mọi thay đổi. Quyết định nhỏ và dễ đảo thì không cần. Và ADR chỉ có ích nếu có người cập nhật trạng thái và có người đọc.

Từ khó, nói dễ#

1. Hình dung trước: dòng chú thích trong công thức#

Hình dung một quán ăn có cuốn sổ công thức. Món canh ghi: "Không cho muối, nêm bằng nước mắm cuối cùng." Một bạn mới vào bếp thấy canh nhạt, tiện tay cho thêm muối. Hôm đó một khách dị ứng muối gọi canh. Không ai sai ý định. Cuốn sổ chỉ thiếu một dòng: "vì sao không cho muối".

Giờ hình dung cuốn sổ có dòng đó: "Không cho muối, vì món này phục vụ cả khách ăn kiêng. Muối do khách tự thêm ở bàn." Bạn mới đọc là hiểu, và nếu quán đổi chính sách thì có chỗ để sửa dòng ấy.

ADR là dòng chú thích đó, nhưng cho code. Đồng thời, đối với một AI agent bước vào kho mã, nó là dòng chú thích mà agent đọc được, trước khi tiện tay "cho thêm muối".

Điều rút ra: thứ cần lưu không phải là cuốn sổ lớn mà là lý do của từng quyết định đáng nhớ, đủ ngắn để có người đọc.

2. ADR là gì, theo nguồn gốc#

2.1 Bản gốc của Michael Nygard (2011)#

Trong bài "Documenting Architecture Decisions" đăng ngày 15/11/2011 trên blog Cognitect, Michael Nygard viết rằng các quyết định kiến trúc thường không có ghi chép về lý do. Người mới vào dự án chỉ có hai đường: chấp nhận quyết định mà không hiểu, hoặc đảo ngược nó mà không biết hệ quả. Ông nói cả hai đều có thể làm hại dự án, và quá nhiều quyết định không giải thích khiến cả nhóm sợ đổi bất cứ thứ gì.

Ông đề xuất mỗi bản ghi gồm năm phần:

• Tiêu đề: cụm danh từ ngắn.
• Bối cảnh: các lực tác động lên quyết định (kỹ thuật, chính trị, xã hội, đặc thù dự án), nêu sự việc không phán xét.
• Quyết định: câu đầy đủ, thể chủ động, bắt đầu bằng "Chúng tôi sẽ".
• Trạng thái: "đề xuất" cho đến khi các bên đồng ý, rồi "đã chấp nhận". Về sau có thể là "không dùng nữa" hoặc "bị thay thế", kèm liên kết tới bản mới.
• Hệ quả: bối cảnh sau quyết định, gồm cả điều tích cực, tiêu cực và trung tính.

Về độ dài: một đến hai trang. Về giọng văn: viết như đang trò chuyện với một lập trình viên trong tương lai, dùng câu đầy đủ, chỉ dùng gạch đầu dòng để trình bày chứ không để thay câu bằng mảnh vụn. Về lưu trữ: trong kho mã của dự án, ví dụ doc/arch/adr-NNN.md, đánh số tuần tự và không dùng lại số. Quyết định bị đảo không bị xóa: bản cũ giữ nguyên và đánh dấu bị thay thế.

Nygard cũng kể một trải nghiệm: sau khoảng ba tháng dùng trên vài dự án, sáu đến mười lập trình viên luân phiên qua các dự án nói phần bối cảnh trong bản ghi có giá trị. Đây là lời kể của chính tác giả, mẫu nhỏ, không phải nghiên cứu đối chứng.

2.2 MADR: một mẫu Markdown phổ biến#

MADR (Markdown Architectural Decision Records) là một mẫu gọn viết bằng Markdown. Theo trang chính thức, các phần gồm: tiêu đề, phần đầu tùy chọn (trạng thái, ngày, người quyết định, người được hỏi, người được báo), bối cảnh và vấn đề, các yếu tố quyết định (tùy chọn), các phương án đã xét, kết quả quyết định (kèm hệ quả tốt xấu), cách xác nhận việc tuân thủ (tùy chọn), ưu nhược của từng phương án, và thông tin thêm (có thể ghi điều kiện để xem lại). Quy ước lưu trữ: thư mục docs/decisions, tên tệp NNNN-tieu-de-viet-lien.md với số thứ tự. Phiên bản mới nhất trang mô tả là 4.0.0, ngày 17/9/2024, cấp phép kép MIT hoặc CC0.

2.3 Y-statement: ADR trong một câu#

Y-statement là dạng rút gọn do Olaf Zimmermann và các tác giả gắn với nó phổ biến, một câu theo mẫu: "Trong bối cảnh (tình huống), đối mặt với (mối lo), chúng tôi chọn (phương án) và không chọn (các phương án khác), để đạt (mục tiêu chất lượng), chấp nhận (cái mất)." Các nguồn tôi đọc ghi từ nối khác nhau một chút ("and against" hoặc "and neglected"), nên hãy coi đây là mẫu, không phải chuẩn cứng. Y-statement hợp với quyết định đơn giản. Với quyết định phức tạp, các nguồn khuyên dùng mẫu đầy đủ như MADR hoặc bản của Nygard.

Điều rút ra: ADR không phải công cụ phức tạp. Cốt lõi là bốn câu hỏi: ta đang ở hoàn cảnh nào, ta chọn gì, ta bỏ gì, và ta chấp nhận mất gì.

3. Vì sao nhóm mất quyết định, và vì sao AI làm vấn đề rõ hơn#

3.1 Dữ liệu từ khảo sát Stack Overflow 2026#

Trang kết quả khảo sát Stack Overflow Developer Survey 2026 có phần về những khó khăn liên quan đến ngữ cảnh. Theo bản tóm tắt tôi đọc, khoảng 60,9% người trả lời nói ngữ cảnh quan trọng nằm trong đầu một số người, 56,5% nói thông tin đã cũ, 53,4% nói thông tin rải trong quá nhiều công cụ và 63,2% nói thông tin chưa đầy đủ. Tôi đọc qua bản tóm tắt chứ chưa đối chiếu từng bảng, câu hỏi gốc có thể rộng hơn chuyện quyết định kỹ thuật, và người trả lời là những người chịu làm khảo sát. Vì vậy hãy hiểu đây là tín hiệu chung rằng tri thức nhóm thường rời rạc, không phải bằng chứng về ADR.

3.2 Với AI agent: nhìn thấy code, không thấy lý do#

Hình dung agent như một đồng nghiệp rất nhanh nhưng mới vào hôm nay: đọc toàn bộ code trong vài giây, nhưng không nhớ cuộc họp tuần trước. Khi nó thấy một đoạn code vòng vèo, phản xạ hợp lý là đơn giản hóa. Nếu sự vòng vèo là kết quả của một quyết định có lý do, thứ duy nhất ngăn nó lại là lý do được viết ở chỗ nó tìm thấy.

Cần nói rõ về giới hạn: tôi chưa tìm thấy nghiên cứu nào đo việc đưa ADR vào ngữ cảnh làm giảm bao nhiêu lần agent đảo quyết định. Cách nhìn ở đây là một lập luận thực hành, nối với bài Sổ tay cho AI: AGENTS.md, nơi ta đặt những điều agent cần biết ở chỗ nó đọc.

3.3 Phép tính để bạn tự kiểm lại (minh họa, có thể bỏ qua)#

Đây là ví dụ minh họa với số dựng sẵn, không phải số đo. Giả sử một nhóm sáu người ghi hai quyết định mỗi tháng, mỗi ADR dài 300 từ, và tốc độ đọc tài liệu kỹ thuật là 150 từ mỗi phút (giả định). Một năm nhóm có 24 ADR.

adr, words, wpm = 24, 300, 150
read_all = adr * words / wpm          # 7200 từ, tức 48 phút
index = adr * 12 / wpm                # 24 tiêu đề, 12 từ mỗi dòng, tức 288 từ, gần 2 phút

asked, explain = 5, 15                # người mới hỏi lại 5 quyết định, senior giải thích 15 phút mỗi lần
without = asked * explain             # 75 phút của senior
with_adr = asked * words / wpm        # 5 ADR x 2 phút = 10 phút của người mới
print(read_all, round(index, 2), without, with_adr)
# 48.0 1.92 75 10.0

newcomers = 4
print(newcomers * without, newcomers * with_adr)
# 300 40.0  (phút mỗi năm)

Đọc kết quả: đọc hết 24 ADR mất khoảng 48 phút, đọc riêng danh sách tiêu đề mất gần 2 phút, nên không ai phải nạp hết mọi thứ. Nếu mỗi người mới hỏi lại 5 quyết định và senior giải thích 15 phút mỗi lần, đó là 75 phút của senior cho một người, tức 300 phút một năm với 4 người mới. Với ADR, người mới tự đọc 5 bản trong khoảng 10 phút mỗi người, tức 40 phút một năm.

Lưu ý rõ: 300 từ, 150 từ mỗi phút, 5 câu hỏi và 15 phút là số tôi giả định. ADR cũng tốn thời gian viết và cập nhật, và chưa tính ở đây. Hãy thay bằng số của nhóm bạn.

4. Mẫu một trang#

Hình dung phiếu nộp bài: ít ô, ô nào cũng bắt buộc điền, và đủ nhỏ để điền trong mười phút. Mẫu dưới đây dựa trên bản của Nygard, thêm hai ô lấy ý từ MADR (điều kiện xem lại và cách xác nhận) để quyết định có lối thoát và có cách kiểm.

# ADR 0007: Gửi nhắc lịch qua hàng đợi

Trạng thái: đã chấp nhận (đề xuất / đã chấp nhận / bị thay thế bởi ADR 00NN)
Ngày: 2026-03-12
Người quyết định: tên hoặc vai trò

## Bối cảnh
Hoàn cảnh và ràng buộc, nêu sự việc, không phán xét. Ai đang chờ gì?

## Quyết định
Chúng tôi sẽ (một hoặc hai câu đầy đủ, thể chủ động)

## Phương án đã loại
- Phương án A: vì sao không chọn.
- Phương án B: vì sao không chọn.

## Hệ quả
- Được: điều tốt.
- Mất: điều ta chấp nhận đánh đổi.
- Trung tính: điều chỉ thay đổi, không tốt không xấu.

## Khi nào xem lại
Điều kiện cụ thể khiến ta mở lại quyết định.

## Cách kiểm
Một kiểm tra tự động hoặc dấu hiệu quan sát được cho thấy quyết định vẫn được tuân thủ.

Ba quy tắc giữ trong một trang:

1. Một ADR, một quyết định. Nếu cần chữ "và" ở tiêu đề, có lẽ đó là hai quyết định.
2. Câu đầy đủ trong phần bối cảnh và quyết định. Gạch đầu dòng chỉ dành cho danh sách ngắn như phương án và hệ quả.
3. Chi tiết dài để ở nơi khác. Bảng so sánh, biểu đồ, kết quả thử nghiệm: đặt liên kết, không dán vào.

5. Ví dụ minh họa: một ADR đã điền#

Đây là ví dụ minh họa, dựng lại cho bài này, không nhắc đến công ty hay sản phẩm thật. Tình huống: một ứng dụng nhỏ giúp tiệm dịch vụ đặt lịch hẹn và gửi nhắc lịch qua email. Mọi con số trong ví dụ đều là bịa.

# ADR 0007: Gửi nhắc lịch qua hàng đợi, không gửi trong lúc xử lý yêu cầu

Trạng thái: đã chấp nhận
Ngày: 2026-03-12

## Bối cảnh
Khi khách đặt lịch, ứng dụng gửi email xác nhận ngay trong lúc xử lý yêu cầu.
Dịch vụ gửi email thỉnh thoảng phản hồi mất vài giây và từng lỗi cả giờ.
Trong thời gian đó trang đặt lịch treo, và có khách bấm đặt hai lần.

## Quyết định
Chúng tôi sẽ đưa việc gửi email vào một hàng đợi công việc. Yêu cầu đặt lịch
chỉ ghi lịch vào cơ sở dữ liệu rồi trả lời ngay. Một bộ xử lý riêng gửi email
và thử lại tối đa ba lần.

## Phương án đã loại
- Gửi trực tiếp trong yêu cầu: đơn giản nhất, nhưng trang treo khi dịch vụ chậm.
- Quét bảng mỗi phút bằng lịch chạy định kỳ: không cần hàng đợi, nhưng email trễ
  tới một phút và phải quét cả bảng lớn.

## Hệ quả
- Được: trang đặt lịch phản hồi nhanh, lỗi email không làm hỏng việc đặt lịch.
- Mất: thêm một thành phần phải theo dõi, email có thể đến trễ vài giây.
- Trung tính: nhật ký có thêm một nguồn cần đọc khi gỡ lỗi.

## Khi nào xem lại
Nếu trong sáu tháng số email gửi dưới 50 mỗi ngày, hoặc nhà cung cấp email
có sẵn hàng đợi tích hợp.

## Cách kiểm
Một test đảm bảo yêu cầu đặt lịch không gọi trực tiếp dịch vụ email.

Phiên bản Y-statement của cùng quyết định: "Trong bối cảnh đặt lịch hẹn, đối mặt với dịch vụ email chậm và hay lỗi, chúng tôi chọn đưa việc gửi vào hàng đợi và không chọn gửi trực tiếp hay quét bảng định kỳ, để trang đặt lịch luôn nhanh, chấp nhận thêm một thành phần phải theo dõi."

Bản đầy đủ dài khoảng 260 chữ trong tiếng Việt, nằm trong mục tiêu một trang (khoảng 300 từ). Điểm đáng chú ý: phần "Phương án đã loại" chính là thứ ngăn người và AI quay lại phương án đơn giản nhất, vì phương án đơn giản nhất là thứ ai cũng nghĩ tới trước.

6. Viết ADR sao cho AI agent đọc được và dùng được#

Hình dung bạn để lại một tờ ghi chú cho người trực ca sau: tờ ghi chú chỉ có ích nếu được dán đúng chỗ người đó nhìn thấy.

1. Đặt ADR trong kho mã, ví dụ thư mục docs/adr, đi cùng code và cùng lịch sử thay đổi.
2. Có một tệp danh mục liệt kê tiêu đề, trạng thái và đường dẫn của từng ADR, mỗi bản một dòng. Agent đọc danh mục rồi mở bản liên quan, nên không phải nạp hết.
3. Trỏ tới từ tệp hướng dẫn cho agent. Trong AGENTS.md hoặc tệp hướng dẫn của công cụ, thêm vài dòng như khối dưới đây.
4. Ghi trạng thái ở dòng đầu, bằng từ cố định (đề xuất, đã chấp nhận, bị thay thế), để cả người và máy lọc được.
5. Để người viết hai phần đầu. Bối cảnh và quyết định do người điền. AI có thể gợi ý phương án đã loại hoặc soạn nháp, nhưng một lý do nghe hợp lý chưa chắc là lý do thật. Người xác nhận lý do, đúng tinh thần của bài Làm cho kết quả của AI tự chứng minh.

## Quyết định đã có
- Trước khi đổi cách làm đã có trong docs/adr, đọc danh mục docs/adr/README.md
  và mở ADR liên quan.
- Nếu thay đổi của bạn trái với một ADR đã chấp nhận, dừng lại và hỏi,
  đừng tự sửa.
- Khi báo xong, ghi rõ bạn đã đọc ADR nào.

Ba dòng, đủ ngắn để người và agent đọc hết. Dòng cuối dùng ý của cách thứ tư trong bài về bằng chứng: tách điều đã đọc khỏi điều giả định.

7. Vòng đời của một ADR#

Điểm quan trọng nhất: không xóa bản cũ. Người đọc cần thấy cả điều ta từng quyết và vì sao ta đổi.

8. Khi nào không nên viết ADR#

Đây là quy tắc kinh nghiệm của tôi, không phải chuẩn của Nygard hay MADR. Hình dung thùng rác của nhà bếp: không phải thứ gì cũng cần cuốn sổ riêng.

• Không viết khi quyết định đảo lại được trong khoảng một giờ làm việc (đổi tên biến, chọn tên tệp).
• Không viết khi lý do đã có trong tài liệu chuẩn của công cụ và ai cũng tra được.
• Không viết chỉ để cho đủ thủ tục. Một ADR không ai đọc tốn công mà không ích gì.
• Nên viết khi người mới có khả năng hỏi "vì sao lại thế này?", khi đảo quyết định tốn hơn nửa ngày, hoặc khi ta vừa loại một phương án mà ai cũng sẽ nghĩ tới trước.

9. Chỗ nào ADR cũng hỏng#

Hình dung cuốn sổ công thức: có cuốn rất dày mà không ai mở, có cuốn ghi sai từ lâu.

9.1 Minh họa: một buổi sáng có và không có ADR#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật, dùng lại ví dụ ở mục 5.

Không có ADR:

• 09:00. Dev nhờ agent: "Dọn gọn phần đặt lịch, bớt các thành phần thừa."
• 09:20. Agent thấy hàng đợi gửi email như một lớp thừa và chuyển thành gọi trực tiếp. Mọi test hiện có đều đạt.
• 11:00. Dev đọc diff thấy hợp lý, gộp vào nhánh chính.
• 15:30. Dịch vụ email chậm. Trang đặt lịch treo, khách bấm đặt hai lần.

Có ADR và AGENTS.md trỏ tới:

• 09:00. Cùng yêu cầu.
• 09:10. Agent đọc danh mục ADR, mở ADR 0007 rồi báo: "Hàng đợi này là quyết định đã chấp nhận. Tôi không đổi. Bạn có muốn mở ADR mới để thay không?"
• 09:20. Dev trả lời: "Giữ nguyên. Chỉ dọn phần khác."
• 09:50. Agent nộp thay đổi, ghi "đã đọc ADR 0007, không đụng hàng đợi".

Việc nên làm ở cả hai: dừng lại ở bước agent muốn bỏ một thứ trông thừa và hỏi thứ đó có lý do không. Đây là minh họa nên không chứng minh điều gì. Tín hiệu từ khảo sát Stack Overflow (đã nêu ở mục 3) và lời kể của Nygard chỉ cho thấy việc thiếu ngữ cảnh là có thật, và bản ghi ngắn có thể giúp.

10. Số liệu và tài liệu đã dùng#

Đọc cho đúng: các nguồn trên ủng hộ việc ghi lại lý do ngắn gọn. Tôi chưa tìm thấy nghiên cứu đối chứng đo trực tiếp ADR làm giảm lỗi hay giúp AI agent tránh đảo quyết định. Phần về AI trong bài là tổng hợp thực hành.

11. Thói quen áp dụng từ ngày mai#

11.1 Tám câu hỏi trước khi chốt một ADR#

1. Đây là một quyết định, hay hai quyết định đang ghép?
2. Người đọc sau một năm có hiểu bối cảnh mà không cần hỏi ai không?
3. Phần quyết định bắt đầu bằng "Chúng tôi sẽ" và là câu đầy đủ chưa?
4. Đã ghi phương án đã loại và lý do loại chưa?
5. Hệ quả có cả cái mất và cái trung tính, không chỉ cái được?
6. Có điều kiện xem lại và cách kiểm cụ thể chưa?
7. Trạng thái và ngày ở dòng đầu, và danh mục đã cập nhật chưa?
8. AGENTS.md hoặc README có trỏ tới ADR này chưa?

11.2 Ba việc làm ngay#

1. Tạo thư mục docs/adr và một danh mục trống.
2. Chọn một quyết định gần đây mà người mới hay hỏi, rồi viết ADR đầu tiên trong khoảng 15 phút.
3. Thêm ba dòng ở mục 6 vào tệp hướng dẫn cho AI agent.

12. Nhìn cân bằng: ADR làm được gì, chưa làm được gì#

Làm được: giữ lại lý do, giúp người mới tự tìm câu trả lời, cho agent chỗ để kiểm tra trước khi sửa, và buộc nhóm nói rõ cái mất của mỗi quyết định.

Chưa làm được:

• ADR không bảo đảm quyết định đúng. Nó chỉ ghi lại việc ta đã nghĩ gì lúc đó.
• Một ADR không được cập nhật có thể gây hại hơn không có ADR, vì nó nói sai điều đang có hiệu lực.
• Agent không bắt buộc phải đọc ADR, và tôi chưa thấy thử nghiệm đo mức độ nó tuân theo. Hãy kiểm bằng cách yêu cầu agent báo đã đọc ADR nào.
• ADR tốn công viết và duy trì. Với nhóm rất nhỏ hoặc dự án ngắn hạn, một câu trong README có thể đủ.
• Lý do AI soạn thay có thể nghe trôi chảy mà không đúng. Cần người xác nhận.

Đừng thổi phồng: ADR không thay cho giao tiếp trong nhóm. Đừng coi nhẹ: chi phí của một quyết định mất lý do thường nằm ở cuối, khi ai đó đảo ngược nó vì không biết nó từng có lý do.

13. Kết luận#

Code cho thấy ta đã làm gì, ADR cho thấy vì sao. Một trang ngắn, viết ngay lúc quyết định, kể cả phương án đã bỏ và cái mất, có đường dẫn từ nơi người và AI sẽ đọc, đủ để nhiều quyết định khỏi bị đảo ngược chỉ vì không ai biết chúng từng có lý do. Hãy bắt đầu từ một quyết định mà người mới hay hỏi.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số con số được đọc qua bản tóm tắt, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Michael Nygard, Documenting Architecture Decisions (Cognitect, 15/11/2011)
• Architectural Decision Records, adr.github.io và MADR (phiên bản 4.0.0)
• Olaf Zimmermann, Y-Statements (mẫu ADR một câu)
• Stack Overflow, 2026 Developer Survey (đọc qua bản tóm tắt, chưa đối chiếu từng bảng)

Dành cho bất kỳ ai dùng AI agent để viết code hoặc làm việc nhiều bước, kể cả người mới. Không cần biết gì về cách mô hình hoạt động. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Cách mô hình dùng thông tin dài bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ. Tên lệnh lấy từ tài liệu của Claude Code tại thời điểm đọc, các công cụ khác và các bản sau có thể khác.

Tóm tắt nhanh#

• Agent chỉ "nhớ" những gì đang nằm trong cửa sổ ngữ cảnh: yêu cầu của bạn, các tệp đã đọc, đầu ra của lệnh, hướng dẫn dự án. Cửa sổ có giới hạn, và mọi thứ mở ra đều chiếm chỗ.
• Nhiều nghiên cứu thấy mô hình dùng thông tin dài kém ổn định hơn thông tin ngắn. Liu và cộng sự (2023) thấy kết quả thường tốt nhất khi thông tin cần thiết ở đầu hoặc cuối và kém đi khi nó nằm giữa. Báo cáo của Chroma (7/2025) thử 18 mô hình và thấy độ tin cậy giảm khi đầu vào dài hơn. Các tác giả tự nói tác vụ của họ đơn giản hơn công việc thật.
• Khi cuộc trò chuyện gần đầy, công cụ có thể nén nó thành bản tóm tắt. Tài liệu của Claude Code nói bản tóm tắt giữ yêu cầu và đoạn code chính, nhưng chi tiết hướng dẫn từ đầu có thể mất.
• Trong ví dụ tính được của bài, một phiên làm việc dài chiếm khoảng 91,5% cửa sổ, trong đó khoảng 43% là việc cũ đã xong. Bắt đầu lại với một bản bàn giao ngắn đưa mức dùng về khoảng 8%. Đây là số minh họa để bạn tự tính lại.
• Quy tắc lâu dài đặt trong tệp hướng dẫn của dự án, không đặt trong cuộc trò chuyện. Chuyển sang việc không liên quan thì dọn cuộc trò chuyện. Cùng một việc nhưng đã dài thì nén có hướng dẫn.
• Bắt đầu lại cũng có giá: agent phải đọc lại, và bản bàn giao có thể thiếu hoặc sai. Phần "khi nào" của bài là quy tắc kinh nghiệm, không phải kết quả đo.

Từ khó, nói dễ#

1. Hình dung trước: cái bàn có diện tích cố định#

Hình dung bạn làm việc ở một cái bàn không to lắm. Bạn trải lên đó yêu cầu của sếp, vài tệp hồ sơ, kết quả của mấy lần tra cứu, ghi chú. Lúc đầu bàn trống, bạn thấy mọi thứ ngay. Sau hai tiếng, bàn đầy giấy, và tờ bạn cần nằm dưới ba tờ khác. Bạn vẫn làm được, nhưng chậm hơn và dễ bỏ sót hơn. Nếu đến lúc đầy hẳn, bạn chép lại những điều quan trọng sang một tờ mới, dọn sạch bàn, rồi làm tiếp. Bản chép chắc chắn thiếu vài chi tiết.

Agent làm việc gần giống vậy. Tài liệu của Claude Code mô tả cửa sổ ngữ cảnh gồm lịch sử cuộc trò chuyện, nội dung tệp, đầu ra của lệnh, tệp hướng dẫn, bộ nhớ tự động, các skill đã nạp và hướng dẫn hệ thống. Khi làm việc, cửa sổ đầy dần. Đây chỉ là hình dung để dễ nhớ: bên trong mô hình chắc chắn phức tạp hơn một cái bàn.

Điều rút ra: "agent quên" thường không phải vì nó lười hay ngu, mà vì chỗ có hạn và thứ đang chiếm chỗ không phải lúc nào cũng là thứ cần thiết. Việc của bạn là quản lý cái bàn.

2. Cái gì chiếm chỗ, và gì còn lại sau khi nén#

2.1 Những thứ chiếm chỗ#

Theo tài liệu của Claude Code, trước khi bạn gõ gì, một số thứ đã nằm sẵn trên bàn: tệp hướng dẫn, bộ nhớ tự động, tên các công cụ MCP và mô tả skill. Sau đó mỗi tệp đọc, mỗi đầu ra của lệnh, mỗi lượt qua lại đều thêm vào. Lệnh /context cho xem mức dùng theo từng loại và gợi ý cách giảm.

2.2 Gì còn lại sau khi nén#

Khi gần đầy, công cụ nén cuộc trò chuyện thành bản tóm tắt. Bảng dưới là tóm lược mục "What survives compaction" trong tài liệu, ở phiên bản tôi đọc. Chi tiết có thể thay đổi theo bản.

Hai điều rút ra từ bảng: nếu một quy tắc phải sống sót, hãy đặt nó ở tệp hướng dẫn gốc dự án, không phải trong lời nói. Và nếu bạn muốn kiểm soát cái gì được giữ, hãy nén chủ động kèm chỉ dẫn, ví dụ /compact focus on the auth bug fix, thay vì để công cụ tự đoán điều quan trọng.

Điều rút ra: quy tắc lâu dài thuộc về tờ nội quy dán tường, không thuộc về chồng giấy trên bàn. Xem thêm bài Sổ tay cho AI: AGENTS.md về cách viết tờ nội quy đó.

3. Vì sao cuộc trò chuyện dài làm agent kém đi#

Hình dung bạn đọc một tập hồ sơ 300 trang rồi bị hỏi một chi tiết ở trang 150. Có thể bạn trả lời được, nhưng khó hơn nhiều so với khi bạn chỉ nhận một trang. Nghiên cứu về mô hình ngôn ngữ cho thấy điều tương tự, dù vì sao thì chưa ai giải thích trọn vẹn.

3.1 Liu và cộng sự (2023): thông tin ở giữa dễ bị bỏ sót#

Nhóm tác giả (trong đó có Percy Liang) thử trả lời câu hỏi dựa trên nhiều tài liệu và tìm giá trị trong danh sách khóa và giá trị. Theo tóm tắt trên arXiv, hiệu năng thường cao nhất khi thông tin liên quan nằm ở đầu hoặc cuối đầu vào, và giảm đáng kể khi mô hình phải dùng thông tin ở giữa một đầu vào dài, kể cả với các mô hình được quảng bá là hỗ trợ ngữ cảnh dài. Đây là thí nghiệm với mô hình thời 2023. Trang tóm tắt tôi đọc không nêu tên từng mô hình, nên mô hình mới có thể cho kết quả khác.

3.2 Chroma (7/2025): 18 mô hình, độ tin cậy giảm khi dài hơn#

Báo cáo kỹ thuật của Chroma (Hong, Troynikov, Huber) thử 18 mô hình, trong đó có các dòng GPT-4.1, Claude 4, Gemini 2.5 và Qwen3, trên ba loại tác vụ: tìm "cây kim trong đống rơm" mở rộng, hỏi đáp trên hội thoại dài (LongMemEval, 306 câu, trung bình khoảng 113.000 token) và lặp lại một chuỗi từ. Các tác giả viết rằng hiệu năng ngày càng kém tin cậy khi đầu vào dài hơn. Họ cũng thấy thông tin gây nhiễu làm kết quả tệ hơn, kể cả khi chỉ có một đoạn gây nhiễu, và các mô hình phản ứng khác nhau: theo họ, các mô hình Claude có xu hướng từ chối trả lời khi mơ hồ, còn mô hình GPT có xu hướng trả lời sai nhiều hơn khi có nhiễu.

Cần đọc kèm lời của chính các tác giả: tác vụ của họ đơn giản hơn công việc thật, nên họ cho rằng ngoài đời hiệu ứng có thể tệ hơn, nhưng cũng khó tách ảnh hưởng của độ dài khỏi độ khó của tác vụ, và báo cáo không giải thích cơ chế. Đây là báo cáo kỹ thuật của một công ty, tôi chưa thấy đánh giá độc lập.

3.3 Anthropic (9/2025): "ngân sách chú ý" có hạn#

Bài về kỹ thuật ngữ cảnh của Anthropic (29/9/2025) dùng thuật ngữ context rot và mô tả ngữ cảnh như một tài nguyên hữu hạn, mỗi token thêm vào tiêu hao một phần "ngân sách chú ý" của mô hình. Bài đề xuất vài hướng: nén khi gần đầy, ghi chú ra bên ngoài cửa sổ để đọc lại sau, và dùng agent phụ với bàn riêng. Đây là quan điểm kỹ thuật của một hãng bán công cụ, không phải thí nghiệm đối chứng.

Điều rút ra: ba nguồn cùng hướng: dài hơn thường không có nghĩa là tốt hơn. Mức độ và nguyên nhân thì chưa chắc, và mỗi mô hình khác nhau.

4. Phép tính để bạn tự kiểm lại (minh họa, có thể bỏ qua)#

Đây là ví dụ minh họa với số dựng sẵn, không phải số đo. Giả sử cửa sổ 200.000 token. Một phiên làm việc gồm: phần nạp sẵn lúc bắt đầu 12.000 token, 25 lần đọc tệp mỗi lần 3.000 token, 40 đầu ra lệnh mỗi lần 1.500 token, và 60 lượt trao đổi mỗi lượt 600 token.

window = 200_000
startup = 12_000
files, file_size = 25, 3_000
cmds, cmd_size = 40, 1_500
turns, turn_size = 60, 600

used = startup + files * file_size + cmds * cmd_size + turns * turn_size
print(used, round(used / window * 100, 1))
# 183000 91.5

# giả sử nửa phần việc là một việc cũ đã xong
old = 0.5 * (used - startup)
print(old, round(old / window * 100, 1))
# 85500.0 42.8

# bắt đầu lại với bản bàn giao 4.000 token
fresh = startup + 4_000
print(fresh, round(fresh / window * 100, 1), (window - fresh) // file_size)
# 16000 8.0 61   (số tệp 3.000 token còn nhét thêm được)

Đọc kết quả: phiên dài dùng khoảng 91,5% cửa sổ, và trong đó khoảng 43% là việc cũ. Chỉ còn chỗ cho khoảng 5 tệp nữa (17.000 chia 3.000). Sau khi bắt đầu lại với bản bàn giao 4.000 token, mức dùng còn khoảng 8% và nhét thêm được khoảng 61 tệp.

Lưu ý rõ: tất cả kích thước token ở trên là giả định, kể cả giả định nửa phiên là việc cũ. Kích thước cửa sổ, ngưỡng tự động nén và cách tính token phụ thuộc mô hình và công cụ. Phép tính không nói rằng 8% sẽ cho kết quả tốt hơn 91,5%, chỉ cho thấy việc cũ chiếm chỗ bao nhiêu. Hãy chạy /context trong phiên thật của bạn để xem số thật.

5. Khi nào nên làm gì: dọn, nén, tách hay bắt đầu lại#

Hình dung bạn ở bàn làm việc: có lúc chỉ cần gạt bớt giấy, có lúc cần chép ghi chú sang tờ mới, có lúc nên sang hẳn bàn khác.

Cột "căn cứ" cho thấy phần nào có trong tài liệu và phần nào là kinh nghiệm cá nhân. Mốc cụ thể như "hai lần sửa" hay "quá một nửa cửa sổ" tôi chưa thấy nghiên cứu nào đo, nên hãy xem là điểm xuất phát để bạn tự chỉnh.

5.1 Dấu hiệu nên cân nhắc bắt đầu lại#

1. Bạn chuyển sang một việc không liên quan đến phần lớn nội dung trên bàn.
2. Agent làm trái một quy tắc bạn đã nói và bạn phải nhắc lần thứ hai.
3. Agent sửa đi sửa lại cùng một chỗ hoặc đề xuất lại điều đã bị loại.
4. Bạn không còn nhớ cuộc trò chuyện đã chốt gì (agent cũng khó nhớ hơn).
5. Sau một lần tự động nén, chất lượng thay đổi rõ.
6. Lệnh /context cho thấy phần lớn chỗ là đầu ra lệnh và tệp đã xong việc.

6. Mẫu bản bàn giao (có thể sao chép)#

Hình dung ghi chú ca trực: người vào ca sau đọc một phút là làm tiếp được. Dán khối này vào đầu phiên mới, hoặc lưu thành một tệp trong dự án để lần sau đọc lại.

## Bản bàn giao
Mục tiêu: <một câu>
Đã xong và đã kiểm: <việc, kèm lệnh đã chạy và kết quả>
Đang làm dở: <tệp, hàm, bước tiếp theo>
Đã chốt và lý do: <quyết định, một dòng mỗi cái>
Đã thử nhưng không được: <cách, lý do bỏ>
Không được làm: <ranh giới, tệp không đụng>
Chưa kiểm hoặc giả định: <điều agent đoán chứ chưa chạy>
Lệnh để chạy lại kiểm: <một lệnh>

Phần "chưa kiểm hoặc giả định" lấy ý từ bài Làm cho kết quả của AI tự chứng minh: tách điều đã chạy khỏi điều chỉ đoán, để phiên mới không coi điều đoán là sự thật. Bạn có thể nhờ agent viết bản nháp rồi tự đọc và sửa, vì bản tóm tắt do AI viết cũng có thể sót hoặc sai.

Câu lệnh nén có hướng dẫn, dùng khi vẫn làm cùng một việc:

/compact focus on: mục tiêu hiện tại, quyết định đã chốt, tệp đang sửa,
lệnh kiểm, và những gì không được đụng vào

7. Minh họa: một buổi sáng hai cách làm#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.

Không dọn cuộc trò chuyện:

• 09:00. Dev nhờ agent sửa lỗi làm tròn trong hóa đơn và dặn: "Tên hàm mới phải bắt đầu bằng calc."
• 09:40. Agent đã đọc 25 tệp và chạy nhiều lệnh. Lỗi sửa xong, test đạt.
• 10:30. Cùng phiên, dev nhờ đổi màu một nút ở trang khác.
• 10:45. Agent thêm hàm tên computeColor, trái quy tắc đã dặn lúc 09:00. Dev nhắc, agent sửa, nhưng sau đó lại đề xuất lại một cách đã bị loại ở 09:20.

Có dọn và có bản bàn giao:

• 09:40. Sửa xong, dev commit và lưu bản bàn giao ngắn vào tệp ghi chú của dự án. Quy tắc calc đã nằm sẵn trong tệp hướng dẫn gốc.
• 10:30. Dev chạy /clear và mở việc mới với yêu cầu rõ ràng.
• 10:45. Agent đọc tệp hướng dẫn, đặt tên đúng quy tắc ngay lần đầu.

Việc nên làm ở cả hai: quy tắc lâu dài vào tệp hướng dẫn, việc đã xong thì commit rồi dọn bàn. Đây là minh họa nên không chứng minh điều gì. Bằng chứng nằm ở các nghiên cứu ở phần 3, và chúng cũng có giới hạn: mô hình cũ hơn, tác vụ đơn giản hơn công việc thật. Xem thêm bài Bảy sai lầm khi viết yêu cầu cho agent.

8. Chỗ nào làm theo vẫn hỏng#

9. Số liệu và tài liệu đã dùng#

Đọc cho đúng: cả ba nguồn nghiên cứu đều gợi ý hướng "dài hơn thường kém tin cậy hơn". Tôi chưa tìm thấy nghiên cứu đối chứng đo trực tiếp việc "dọn cuộc trò chuyện" hay "viết bản bàn giao" cải thiện kết quả bao nhiêu trong công việc thật. Các mốc ở mục 5 là quy tắc kinh nghiệm.

10. Thói quen áp dụng từ ngày mai#

10.1 Tám câu hỏi giữa phiên làm việc#

1. Việc đang làm còn liên quan đến phần lớn nội dung trên bàn không?
2. Quy tắc bắt buộc đã nằm trong tệp hướng dẫn gốc chưa, hay mới chỉ nói miệng?
3. /context cho thấy cái gì đang chiếm chỗ nhiều nhất?
4. Việc đã xong đã được commit và kiểm chưa?
5. Tôi có cần agent đọc nhiều tệp chỉ để tra cứu, và có nên giao cho agent phụ?
6. Nếu nén, tôi muốn giữ lại những gì (đã viết thành chỉ dẫn chưa)?
7. Nếu bắt đầu lại, bản bàn giao của tôi có phần "chưa kiểm hoặc giả định" chưa?
8. Tôi đang bắt đầu lại vì có dấu hiệu rõ, hay chỉ vì thói quen?

10.2 Ba việc làm ngay#

1. Chạy /context trong phiên hiện tại và ghi lại ba thứ chiếm chỗ nhiều nhất.
2. Chuyển ba quy tắc bạn hay nhắc lại thành một khối ngắn trong tệp hướng dẫn gốc.
3. Lưu mẫu bản bàn giao ở mục 6 thành một tệp và thử dùng cho một việc trong tuần này.

11. Nhìn cân bằng: bắt đầu lại làm được gì, chưa làm được gì#

Làm được: giảm lượng việc cũ chiếm chỗ, tránh lặp lại điều đã bị loại, buộc bạn viết ra điều đã chốt (có lợi cho cả người đọc sau này), và giúp quy tắc quan trọng có chỗ đứng bền ở tệp hướng dẫn.

Chưa làm được:

• Không bảo đảm kết quả tốt hơn. Phiên mới mất các chi tiết bản bàn giao không ghi, và agent phải đọc lại tệp, tốn công và token.
• Tôi không có số đo trong công việc thật cho các mốc "khi nào". Hãy tự thử và so.
• Cách các công cụ khác nhau nén, nạp lại và đặt ngưỡng khác nhau, và thay đổi theo bản. Tài liệu bạn đọc hôm nay có thể không còn đúng sau vài tháng.
• Một bản tóm tắt do AI viết cũng có thể sai.

Đừng thổi phồng: đây không phải thuốc chữa mọi trường hợp agent làm sai, nhiều lỗi đến từ yêu cầu mơ hồ chứ không phải từ cửa sổ đầy. Đừng coi nhẹ: cuộc trò chuyện kéo dài mà không ai nhìn mặt bàn là nơi lỗi nhỏ tích tụ, và việc dọn rất rẻ so với việc đoán xem agent đã quên gì.

12. Kết luận#

Agent không nhớ vô hạn: nó làm việc trên một cái bàn có diện tích cố định, và nghiên cứu cho thấy bàn bừa thì kết quả thường kém ổn định hơn. Hãy đặt quy tắc bền vào tệp hướng dẫn, nén có chỉ dẫn khi vẫn làm cùng việc, dọn khi đổi việc, và khi bắt đầu lại hãy mang theo một bản bàn giao ngắn do chính bạn đã đọc lại.

Nguồn tham khảo#

Số liệu và mô tả lấy từ nguồn công khai tính đến tháng 10/2026. Tên lệnh và hành vi của công cụ thay đổi theo bản, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Liu và cộng sự, Lost in the Middle: How Language Models Use Long Contexts (arXiv, 7/2023, bản 3 ngày 20/11/2023)
• Hong, Troynikov, Huber (Chroma), Context Rot: How Increasing Input Tokens Impacts LLM Performance (14/7/2025)
• Anthropic, Effective context engineering for AI agents (29/9/2025)
• Anthropic, tài liệu Claude Code: How Claude Code works và Explore the context window

Dành cho bất kỳ ai dùng AI để viết code, tìm thông tin hay giao việc cho AI agent, kể cả người mới. Không cần biết gì thêm. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể. Cách AI làm việc bên trong chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ. Năm cách trong bài là tổng hợp thực hành từ tài liệu và nghiên cứu đã dẫn, không phải năm kỹ thuật đã được thử nghiệm đối chứng từng cái một.

Tóm tắt nhanh#

• Phần lớn người dùng AI đã quen với việc phải kiểm lại. Khảo sát Stack Overflow 2026 ghi nhận 48% người trả lời chỉ tin AI khi họ dễ kiểm chứng được kết quả, và chỉ 6,6% tin AI cho các quyết định quan trọng.
• Kiểm bằng cách "đọc kỹ rồi tự nghĩ lại" là cách tốn công nhất. Nếu AI nộp kèm bằng chứng có thể mở ra, việc kiểm chuyển từ "dựng lại cả lập luận" sang "nhìn một thứ cụ thể".
• Năm cách đòi bằng chứng: nguồn mở được, phép thử chạy được kèm đầu ra nguyên văn, thay đổi nhỏ và tách phần, phân loại đã chạy, chỉ đọc hay giả định, và cách để người khác chạy lại.
• Mỗi cách có chỗ hỏng riêng: nguồn có thể bịa, test có thể do chính AI viết cho qua, đầu ra có thể bị cắt. Bài nêu cách bắt từng loại.
• Trong ví dụ tính được của bài, kiểm một bản tóm tắt có 8 khẳng định mất khoảng 48 phút nếu không có bằng chứng và khoảng 18 phút nếu có. Đây là số minh họa để bạn tự tính lại với nhóm của mình.
• Bằng chứng không phải bảo chứng. Nó làm việc kiểm rẻ hơn, nhưng vẫn cần một người đủ hiểu để nhìn vào nó.

Từ khó, nói dễ#

1. Hình dung trước: phiếu sửa xe#

Hình dung bạn mang xe đến tiệm. Thợ nói: "Xong rồi anh ạ, chạy ngon." Bạn không có cách nào kiểm ngoài việc lái thử rồi hy vọng. Giờ hình dung thợ đưa một phiếu: đã thay má phanh trước, đã đạp thử phanh ở tốc độ 30 km/h trên đoạn dốc sau tiệm, quãng phanh bình thường, chưa kiểm hệ thống dầu. Cùng một người thợ, nhưng bạn biết được họ đã làm gì, thử gì và còn chưa động tới gì.

AI cũng vậy. Câu "đã xong, tất cả test đều pass" gần như không cho bạn gì để kiểm. Nó chỉ cho bạn thứ để tin. Tài liệu hướng dẫn của Claude Code mô tả đúng điểm này: agent dừng khi việc trông có vẻ xong, và nếu nó không có gì để chạy thử thì "trông có vẻ xong" là thứ duy nhất nó có, nên chính bạn trở thành bộ kiểm thử. Tài liệu cũng khuyên đòi kèm bằng chứng cụ thể như lệnh đã chạy và đầu ra của nó.

Điều rút ra: nói "xong" không tốn gì. Bằng chứng mới là thứ làm cho việc kiểm rẻ đi. Việc của bạn không phải là tin hay không tin, mà là thiết kế yêu cầu sao cho kết quả mang theo cách kiểm của nó.

2. Vì sao cần: người dùng đang phải kiểm#

2.1 Hai con số từ khảo sát Stack Overflow 2026#

Theo trang kết quả khảo sát Stack Overflow Developer Survey 2026 (hơn 30.000 phản hồi theo một bản tin), khoảng 48% người trả lời nói họ tin AI khi dễ kiểm chứng kết quả, còn 6,6% tin AI cho nhiều việc, kể cả quyết định quan trọng. Khảo sát cũng ghi 69,9% hỏi một AI agent khi gặp việc lạ. Tức là dùng nhiều, nhưng tin có điều kiện.

Cần thận trọng với hai điểm. Thứ nhất, tôi đọc qua bản tóm tắt chứ chưa đối chiếu từng bảng, và có một con số trên trang ("hơn 87% có mức tin nào đó, tăng từ 31%") nghe lệch với con số 6,6%, nên tôi không dùng nó. Thứ hai, về việc dẫn nguồn, các nguồn tôi đọc ghi 78,7% (một bản tin) và 93% (bản tóm tắt trang khảo sát) cho tỷ lệ coi trọng việc dẫn nguồn khi đánh giá câu trả lời của AI. Hai số khác nhau có thể do cách đếm hoặc câu hỏi, nên hãy hiểu là "đa số, khoảng 80% đến 93%".

Điều rút ra: người dùng đã tự nói điều họ cần là kết quả dễ kiểm. Phần còn thiếu là cách làm cho nó dễ kiểm.

2.2 Một vụ có thật: án lệ không tồn tại (Mata v. Avianca, 2023)#

Trong một vụ kiện tại tòa liên bang New York, luật sư của nguyên đơn dùng ChatGPT để soạn văn bản pháp lý. Văn bản trích các án lệ có tên hãng bay, lời trích và số hiệu rất đầy đủ, nhưng sáu vụ trong đó không tồn tại. Ngày 22/6/2023 tòa phạt hai luật sư và công ty luật tổng cộng 5.000 USD. Chi tiết hơn có trong bài Vì sao không nên tin AI tuyệt đối.

Ở đây điều đáng chú ý là: văn bản có "nguồn", nhưng nguồn không ai mở. Bằng chứng chỉ có ích khi có người mở nó ra.

Điều rút ra: đòi nguồn là bước một, mở nguồn ra là bước hai. Thiếu bước hai thì bước một chỉ là trang trí.

2.3 Vì sao AI hay trả lời chắc chắn: một lập luận đáng biết#

Nhóm Kalai, Nachum, Vempala và Zhang (OpenAI và Georgia Tech, 4/9/2025) lập luận rằng cách huấn luyện và cách chấm điểm mô hình thường thưởng cho việc đoán hơn là cho việc nói "tôi không chắc". Ví dụ họ đưa ra: hỏi sinh nhật của một người, đoán một ngày có xác suất đúng khoảng 1 trên 365, còn trả lời "không biết" luôn bị 0 điểm, nên đoán có lợi hơn. Trong bài đăng kèm, OpenAI báo cáo một phép so sánh trên bài kiểm tra SimpleQA: một mô hình từ chối trả lời 52% số câu và sai 26%, mô hình cũ hơn từ chối 1% và sai 75%.

Hãy đọc đây là lập luận của chính các tác giả và số đo của chính hãng, chưa thấy kiểm chứng độc lập trong lượt tìm của tôi. Nó cho một gợi ý thực dụng: nếu hệ thống có xu hướng trả lời dù không chắc, thì ta nên yêu cầu nói rõ chỗ không chắc, thay vì chờ AI tự nhận.

Điều rút ra: "tôi không chắc" thường không tự xuất hiện. Hãy xin nó trong yêu cầu.

3. Năm cách đòi bằng chứng#

Để dễ hình dung, hãy nghĩ mỗi cách là một ô trong phiếu sửa xe: đã đọc ở đâu, đã thử gì, đã đổi gì, chưa làm gì, cách để tôi tự thử lại.

Cách 1. Đòi nguồn mở được#

Hình dung: như sách có chú thích cuối trang. Chú thích chỉ có giá trị khi bạn lật được tới trang đó.

Câu mẫu đưa vào yêu cầu:

Mỗi khẳng định về code hoặc tài liệu hãy kèm vị trí kiểm được:
đường dẫn tệp và số dòng, hoặc đường dẫn tài liệu chính thức.
Khẳng định nào không có nguồn, ghi rõ "không có nguồn".

Cách đọc kết quả: chọn một hoặc hai khẳng định quan trọng nhất, mở nguồn, và xem nguồn có nói đúng điều đó không. Đường dẫn mở được chưa đủ, nội dung phải khớp.

Chỗ dễ hỏng: nguồn bịa (như án lệ ở trên), nguồn có thật nhưng nói điều khác, nguồn cũ. Cách bắt: mở ra, và nhìn ngày.

Cách 2. Đòi một phép thử chạy được, kèm đầu ra nguyên văn#

Hình dung: như đạp thử phanh. Kết quả hiện ra "dừng" hoặc "không dừng", không cần ai bình luận.

Câu mẫu:

Trước khi báo xong, chạy lệnh kiểm sau và dán nguyên văn
lệnh cùng đầu ra (không tóm tắt): npm test
Nếu có test fail, sửa rồi chạy lại.
Ghi rõ số test đã chạy.

Tài liệu của Claude Code liệt kê những thứ có thể làm phép thử: một tệp test, mã kết thúc của lệnh build, một trình kiểm lỗi (linter), một script so đầu ra với kết quả mẫu, hay ảnh chụp màn hình đặt cạnh bản thiết kế. Điều quan trọng là phép thử trả về đạt hoặc không đạt và AI đọc được kết quả.

Chỗ dễ hỏng: test do chính AI viết để vừa với code của nó (cùng một sai lầm nằm ở cả hai chỗ), AI sửa test cho khớp code, chỉ chạy một phần số test. Cách bắt: xem diff của thư mục test, so số test đã chạy với số test có, và phá thử: tự sửa sai một dòng rồi xem test có chuyển đỏ không. Cách viết test tốt hơn có trong bài Kiểm thử code do AI viết.

Cách 3. Đòi thay đổi nhỏ, tách từng phần#

Hình dung: như nộp bài từng câu thay vì nộp cả tập. Người chấm có thể chấm xong trong giờ nghỉ.

Câu mẫu:

Làm từng việc một. Mỗi lần chỉ một thay đổi có thể mô tả bằng một câu,
tối đa khoảng 100 dòng thay đổi. Sau mỗi phần nói rõ phần đó để làm gì
và tôi xem ở đâu để thấy nó hoạt động.

Hướng dẫn duyệt code công khai của Google nói thay đổi nhỏ được duyệt nhanh hơn và kỹ hơn, vì người duyệt có thể tìm vài phút nhiều lần thay vì chặn một khối 30 phút, và thay đổi lớn dễ làm sót ý quan trọng. Họ đưa ra mốc tham khảo: khoảng 100 dòng thường hợp lý, 1.000 dòng thường quá lớn. Đây là quy tắc kinh nghiệm cho duyệt bằng người, không phải số cứng, và có thể thay đổi theo số tệp.

Chỗ dễ hỏng: tách nhỏ nhưng các phần phụ thuộc nhau làm người đọc khó theo. Cách bắt: bắt AI ghi thứ tự và lý do tách. Khi một thay đổi thật sự cần lớn (đổi tên hàng loạt), hãy yêu cầu AI chỉ rõ phần máy móc và phần có logic.

Cách 4. Đòi phân loại: đã chạy, chỉ đọc, hay giả định#

Hình dung: như bác sĩ ghi trong hồ sơ: "đã khám", "đã xem phim chụp", "suy đoán dựa vào triệu chứng". Ba loại này không được trộn.

Câu mẫu:

Cuối câu trả lời, chia kết quả thành ba nhóm:
(a) đã chạy và thấy kết quả, kèm lệnh;
(b) đã đọc code nhưng chưa chạy;
(c) giả định hoặc đoán.
Nếu không chắc một điều, đưa nó vào (c), đừng bỏ qua.

Lý do: như phần 2.3, xu hướng của hệ thống có thể là trả lời cho trọn, còn "tôi chưa chạy cái này" thì không tự đến. Một bảng ba nhóm biến cái không chắc thành thứ có chỗ đứng.

Chỗ dễ hỏng: AI xếp nhầm vào nhóm (a) điều nó chỉ đọc. Cách bắt: với mỗi mục (a), phải có lệnh và đầu ra nguyên văn ngay cạnh. Mục (a) không có lệnh coi như thuộc nhóm (b).

Cách 5. Đòi cách để người khác chạy lại, hoặc nhờ một người đọc độc lập#

Hình dung: như công thức nấu ăn. Nếu bạn làm lại đúng các bước mà ra cùng món, món đó đáng tin hơn lời khen của người nấu.

Câu mẫu:

Cho tôi một lệnh (hoặc vài bước) để tôi tự thấy lại kết quả
trên máy sạch. Nêu rõ phiên bản và biến môi trường cần có.

Và nếu việc quan trọng, nhờ một phiên mới, chưa thấy lập luận cũ, đọc lại phần thay đổi so với yêu cầu gốc. Tài liệu của Claude Code mô tả việc này bằng lệnh review chạy trong một agent con mới, chưa từng thấy cuộc trò chuyện, nên không bị cuốn theo lập luận đã dẫn đến đoạn code. Hãy coi đó là một cách làm có lý chứ không phải đảm bảo, vì một AI khác cũng có thể mắc cùng kiểu lỗi.

Chỗ dễ hỏng: lệnh chạy được trên máy của AI mà không chạy được trên máy bạn (thiếu biến môi trường, phiên bản khác). Cách bắt: thật sự chạy một lần trên máy sạch hoặc trong CI. Và với việc quan trọng thì có người đọc, không chỉ máy.

Gộp thành một khối ngắn#

Nếu muốn dùng lâu dài, dán khối sau vào AGENTS.md hoặc tệp hướng dẫn của công cụ để mọi phiên đều đọc:

## Khi báo xong một việc
- Dán lệnh kiểm đã chạy và đầu ra nguyên văn, kèm số test đã chạy.
- Mỗi khẳng định về code có tệp và số dòng.
- Một thay đổi một mục đích, khoảng 100 dòng trở xuống.
- Chia kết quả: đã chạy / chỉ đọc / giả định.
- Cho một lệnh để tôi chạy lại trên máy sạch.

Năm dòng, đủ để người và AI cùng đọc hết. Giữ ngắn là chủ ý: một danh sách dài có thể bị bỏ qua.

4. Phép tính để bạn tự kiểm lại (minh họa, có thể bỏ qua)#

Đây là ví dụ minh họa với số dựng sẵn, không phải số đo. Giả sử AI nộp một bản tóm tắt thay đổi có 8 khẳng định (ví dụ "đã sửa lỗi định dạng ngày", "không đụng đến hàm thanh toán"). Bạn cần xác nhận từng khẳng định trước khi duyệt.

• Không có bằng chứng: mỗi khẳng định bạn phải tự dựng lại, giả sử 6 phút.
• Có bằng chứng: mỗi khẳng định bạn chỉ mở thứ được chỉ, giả sử 1 phút. Với 2 khẳng định rủi ro nhất, bạn kiểm sâu thêm 5 phút mỗi cái.

claims, rebuild, glance, deep, risky = 8, 6, 1, 5, 2
without = claims * rebuild              # 48 phút
with_proof = claims * glance + risky * deep   # 8 + 10 = 18 phút
print(without, with_proof, without - with_proof)
# 48 18 30

per_month = 2 * 20                      # 2 bản tóm tắt mỗi ngày, 20 ngày
print(without * per_month / 60, with_proof * per_month / 60)
# 32.0 12.0   (giờ mỗi tháng)

Đọc kết quả: 48 phút giảm còn 18 phút cho mỗi bản tóm tắt, tức còn khoảng 38%. Với hai bản mỗi ngày trong 20 ngày làm việc, đó là khoảng 32 giờ so với 12 giờ một tháng cho một người duyệt.

Lưu ý rõ: 6 phút, 1 phút và 5 phút là số tôi giả định, không phải số đo. Công việc thật có thể khác nhiều, và đòi bằng chứng cũng làm AI tốn thêm thời gian chạy và viết. Hãy tự bấm giờ vài lần với nhóm của bạn rồi thay số.

5. Chỗ nào đòi bằng chứng cũng hỏng#

Hình dung phiếu sửa xe: thợ vẫn có thể ghi "đã thử phanh" mà chưa thử.

5.1 Minh họa: một buổi chiều có và không có bằng chứng#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật.

Phiên bản không đòi bằng chứng:

• 14:00. Dev nhờ agent: "Sửa lỗi ngày 31/12 hiển thị sang năm sau trong báo cáo."
• 14:20. Agent trả lời: "Đã sửa, test pass." Dev đọc lướt đoạn thay đổi, thấy hợp lý, gộp vào nhánh chính.
• 16:30. Khách báo báo cáo cuối năm vẫn sai với một kiểu định dạng ngày khác. Agent chỉ sửa một trong hai chỗ.

Phiên bản có đòi bằng chứng:

• 14:00. Cùng yêu cầu, kèm khối năm dòng ở trên.
• 14:20. Agent nộp: đã chạy npm test, 12 test pass, chỉ có một test mới cho ngày 31/12 ở định dạng dd/MM. Nhóm (b): đã đọc hàm định dạng thứ hai nhưng chưa chạy. Nhóm (c): giả định mọi báo cáo dùng định dạng dd/MM.
• 14:25. Dev nhìn nhóm (b) và (c), thêm một ca 31/12 cho định dạng thứ hai. Test chuyển đỏ. Agent sửa chỗ còn lại.
• 14:40. Gộp nhánh với hai test mới.

Việc nên làm ở cả hai: chặn "đã xong" ở nhóm (b) và (c). Chính chỗ AI nói thật là "chưa chạy" cho dev biết nên nhìn vào đâu. Đây là minh họa nên không chứng minh điều gì. Bằng chứng nằm ở các nghiên cứu: Perry và cộng sự (Stanford, 2022) thấy người dùng trợ lý AI viết code kém an toàn hơn trong phần lớn bài thử nhưng lại tin hơn rằng code mình an toàn, nên việc lướt rồi duyệt là có cơ sở để lo. Xem thêm bài Duyệt code do AI viết.

6. Số liệu và tài liệu đã dùng#

Đọc cho đúng: các nguồn trên ủng hộ việc làm kết quả dễ kiểm. Tôi chưa tìm thấy nghiên cứu đối chứng đo trực tiếp việc đòi bằng chứng giảm bao nhiêu lỗi. Năm cách ở trên là tổng hợp thực hành.

7. Mức bằng chứng theo rủi ro#

Không cần đòi đủ năm thứ cho mọi việc. Hình dung đi chợ: mua rau thì nhìn, mua đồng hồ thì cần phiếu bảo hành.

8. Thói quen áp dụng từ ngày mai#

8.1 Tám câu hỏi trước khi nhận một kết quả#

1. Kết quả này mang theo cách kiểm nào: nguồn, phép thử, hay chỉ lời nói?
2. Tôi đã mở ít nhất một nguồn quan trọng chưa, và nó có nói đúng điều đó không?
3. Lệnh kiểm và đầu ra có nguyên văn không, hay chỉ là lời tóm tắt?
4. Bao nhiêu test đã chạy trên tổng số test có?
5. Test mới do ai viết, và nó có chuyển đỏ khi tôi phá thử một dòng không?
6. Thay đổi này có nhỏ đủ để tôi đọc hết không?
7. Phần nào AI ghi là "chỉ đọc" hoặc "giả định", và tôi xử lý chúng thế nào?
8. Tôi chạy lại được trên máy sạch chưa, hay mới tin lời AI?

8.2 Ba việc làm ngay#

1. Dán khối năm dòng vào tệp hướng dẫn của công cụ bạn đang dùng.
2. Chọn một việc nhỏ hôm nay, bấm giờ việc kiểm trước và sau khi đòi bằng chứng.
3. Nhờ đồng nghiệp đọc một bản "đã chạy, chỉ đọc, giả định" và nói xem có dùng được không.

9. Nhìn cân bằng: bằng chứng làm được gì, chưa làm được gì#

Làm được: làm việc kiểm rẻ và nhanh hơn, buộc AI nói rõ chỗ chưa chạy, để lại dấu vết cho người khác kiểm lại, và giúp phát hiện chỗ lệch giữa yêu cầu và thay đổi.

Chưa làm được:

• Bằng chứng không phải bảo chứng đúng. Test có thể sai, nguồn có thể bịa, và một bảng đẹp có thể tạo cảm giác an toàn quá mức. Nghiên cứu của Perry và cộng sự gợi ý người dùng dễ chủ quan hơn khi có trợ lý AI.
• Đòi bằng chứng tốn thêm thời gian chạy và viết, nên với việc rủi ro thấp là quá mức.
• Tôi chưa thấy thử nghiệm đối chứng đo riêng hiệu quả của từng cách. Hãy tự đo trong nhóm bạn.
• Một AI khác đọc lại có thể mắc cùng kiểu lỗi. Với việc quan trọng, cần một người đọc.

Đừng thổi phồng: đây không phải công thức làm AI hết sai. Đừng coi nhẹ: chi phí của việc nhận "đã xong" mà không có gì để kiểm thường nằm ở cuối, khi lỗi đã tới tay khách.

10. Kết luận#

Câu "đã xong" của AI nghe như câu trả lời, nhưng thực ra là lời hứa. Bằng chứng biến lời hứa thành thứ bạn kiểm được: nguồn mở được, phép thử chạy được, thay đổi nhỏ, ba nhóm đã chạy, chỉ đọc, giả định, và một lệnh để chạy lại. Hãy đặt các yêu cầu này vào chính câu lệnh đưa cho AI, và luôn là người mở bằng chứng ra.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số con số được thuật lại khác nhau, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Stack Overflow, 2026 Developer Survey (đọc qua bản tóm tắt, chưa đối chiếu từng bảng)
• Anthropic, Best practices for Claude Code (mục Give Claude a check to run)
• Kalai, Nachum, Vempala, Zhang, Why Language Models Hallucinate (9/2025) và bài đăng của OpenAI
• Google Engineering Practices, Small CLs
• Mata v. Avianca, Inc.: Wikipedia và LawNext về lệnh phạt
• Pearce và cộng sự, Asleep at the Keyboard? (2021) và Perry và cộng sự, Do Users Write More Insecure Code with AI Assistants? (Stanford, 2022)

Dành cho sinh viên, người mới đi làm và người đang tìm việc đầu tiên trong nghề phần mềm. Không cần biết thống kê. Từ nào khó đều có giải thích ngắn.

Đây là một bài suy ngẫm: mình cân nhắc bằng chứng và nói rõ chỗ chưa biết, không phải báo cáo nghiên cứu. Mình đọc trực tiếp bản PDF của hai bài nghiên cứu (Stanford, Harvard) và các trang gốc của SignalFire, Ramp, Yale, Indeed (qua FRED). Phần còn lại mình đọc qua bản tóm tắt hoặc báo chí và đã ghi rõ. Hãy mở bản gốc trước khi trích lại bất kỳ con số nào.

Tóm tắt nhanh#

• Nhiều bài báo nói AI đang thu hẹp cửa vào nghề, nhiều bài khác nói chưa thấy gì hoặc thấy ngược lại. Phần lớn các bài đều đúng với thứ nó đo. Vấn đề là chúng đo những thứ khác nhau.
• Điểm chung của các nghiên cứu lớn: không thấy mất việc trên cả nền kinh tế, nhưng việc làm của người 22 đến 25 tuổi ở những nghề chịu ảnh hưởng nhiều từ AI đang yếu đi (Stanford, Harvard). Bản cập nhật của Stanford (dữ liệu đến 6/2026) đưa con số 19%, và chính các tác giả gọi đó là chỉ báo mô tả sớm, chưa phải bằng chứng nhân quả.
• Cùng một nhóm, cùng một nguồn vẫn ra nhiều con số: 6%, 13%, 19%, 20%. Khác nhau ở mốc so sánh và cách tính, không phải ở người nói dối.
• Có những lời giải thích không liên quan đến AI: lãi suất tăng từ 2022, quy định thuế nghiên cứu và phát triển của Mỹ (Section 174), tuyển quá tay năm 2021 đến 2022. Các nhà nghiên cứu đã thử loại chúng ra, nhưng chưa ai loại sạch được.
• Trước khi tin một con số, hãy hỏi sáu câu: đếm ai, đếm gì, so với mốc nào, dữ liệu từ đâu, còn gì thay đổi cùng lúc, chắc đến đâu.
• Dù bên nào đúng, người mới vẫn làm được một số việc: tự đo thị trường của mình, mở rộng cửa, có bằng chứng thật về kỹ năng, và xem lại số liệu mỗi quý.

Từ khó, nói dễ#

1. Hình dung: năm người cân cùng một đám đông#

Hình dung rằng có thể giải thích chuyện này bằng một ví dụ đời thường. Đây là ví dụ minh họa của mình, không phải dữ liệu thật.

Năm người đứng trước cùng một đám đông ở cổng một nhà ga và cùng cố trả lời câu hỏi: "Đám đông này có đang nhỏ đi không?"

• Người thứ nhất chỉ đếm trẻ em. Anh thấy ít đi.
• Người thứ hai đếm tất cả. Cô thấy gần như không đổi.
• Người thứ ba đứng ở cửa vào và đếm người mới vào. Chị thấy giảm mạnh.
• Người thứ tư đọc bảng thông báo "cần thêm người". Bác thấy bảng đang vơi.
• Người thứ năm hỏi từng người: "Bạn có thấy khó vào không?" Em thấy nhiều người nói có.

Cả năm đều trung thực và cả năm đều đúng với thứ mình đo. Nếu chỉ nghe "đám đông đang nhỏ đi" thì bạn không biết ai đang nói gì. Câu chuyện về việc làm của người mới trong nghề phần mềm giống hệt vậy, chỉ khác là người ta còn chọn năm bắt đầu và nơi đứng khác nhau.

2. Bên nói "cửa vào đang hẹp lại"#

Mình xếp các nghiên cứu theo đúng thứ chúng đo. Cột cuối là mức mình tin vào việc mình đã đọc đúng, không phải mức tin vào kết luận.

Hai điều rút ra từ bảng:

1. Các nghiên cứu lớn không nói AI xóa việc cả nền kinh tế. Chính bài Stanford ghi là không thấy việc làm bị thay thế rộng khắp trên toàn nền kinh tế. Họ nói về một nhóm hẹp: người trẻ, ở các nghề dễ bị AI thay một phần.
2. Cùng nhóm, cùng nguồn vẫn ra nhiều con số. Với người 22 đến 25 tuổi ở nghề chịu ảnh hưởng nhiều, trang ADP Research nêu mức giảm khoảng 6% (từ cuối 2022 đến 7/2025, so với chính họ), bài Stanford nêu 13% và sau đó 19% (so với nhóm khác), còn riêng lập trình viên là khoảng 20% (so với đỉnh). Mục 4 sẽ tính lại các phép này để bạn thấy vì sao chúng khác nhau.

3. Bên nói "chưa thấy" hoặc "thấy ngược lại"#

Vài lưu ý để không đọc nhầm:

• Ramp nói "việc làm ở cấp mới vào tăng 12%", và con số này không bị tóm tắt sai: đó là mức tăng số người ở cấp mới vào tại công ty chi nhiều cho AI trong hai năm. Nhưng chính Ramp ghi rằng các công ty này vốn đã lớn hơn, nhiều kỹ sư hơn, nhiều vốn đầu tư mạo hiểm hơn và tăng nhanh hơn từ trước. Kết quả là một tương quan trong nhóm công ty đó, chưa nói gì về cả nền kinh tế, và bài chưa phải bản cuối.
• Harvard và Ramp thật sự ngược nhau về người mới, dù cùng nhìn công ty dùng AI. Theo ghi chú trong bài Harvard, hai bên đều dùng dữ liệu hồ sơ của Revelio. Điểm khác là cách định nghĩa "công ty dùng AI": một bên là đăng tin tuyển vị trí tích hợp AI, một bên là chi tiền cho công cụ AI. Cùng nhà cung cấp dữ liệu, định nghĩa khác, kết quả khác.
• Con số thất nghiệp theo ngành của Fed New York rất nhiễu vì mẫu nhỏ. Dữ liệu năm 2023 còn nằm trước phần lớn giai đoạn các bài trên bàn đến. Các bản cập nhật sau đó theo báo chí là khoảng 7,0% và 7,8%, nhưng mình chưa mở được bảng gốc để xác nhận, nên chưa dùng làm con số chính.

4. Vì sao cùng một thị trường lại cho ra con số khác nhau#

Hình dung rằng ta có một thị trấn đồ chơi. Con số dưới đây là minh họa do mình dựng, tính thật bằng tay, không đo thị trường thật.

Thị trấn đồ chơi có 100 vị trí cho người mới. Năm 2022: 40 vị trí thuộc nhóm nghề dễ bị AI thay một phần (nhóm A), 60 vị trí thuộc nhóm khác (nhóm B). Năm 2025: nhóm A còn 32, nhóm B lên 66.

Cùng bộ số, ba câu trả lời: "giảm 20%", "thấp hơn 27%", "gần như không đổi". Không ai sai. Đó cũng chính là cách bài Stanford ra con số 19%: việc làm ở hai nhóm nghề chịu ảnh hưởng nhiều nhất giảm khoảng 11% từ 11/2022 đến 6/2026, trong khi ba nhóm ít chịu ảnh hưởng nhất tăng khoảng 10%, và 0,89 / 1,10 - 1 cho ra khoảng 19% thấp hơn mức lẽ ra có. Nếu chỉ nhìn "giảm 11%" thì bạn có một con số khác từ cùng dữ liệu.

Ngoài cách tính, còn bốn thứ làm con số lệch nhau:

Đổi mốc, đổi câu chuyện: số liệu thật về tin đăng tuyển#

Chuỗi số của Indeed Hiring Lab về tin đăng tuyển phát triển phần mềm ở Mỹ (chỉ số, 2/2020 bằng 100, điều chỉnh theo mùa) được đăng trên FRED. Mình tính lại các mốc từ ba điểm trong chuỗi.

Cùng một chuỗi, ba câu: "tin đăng sụt hai phần ba", "vẫn thấp hơn trước đại dịch khoảng một phần năm", "đã hồi 32% từ đáy". Và chú ý: năm 2022 tin đăng gấp khoảng 2,3 lần trước đại dịch. Một phần của "mức giảm" là trở về từ một đỉnh bất thường, không phải mọi thứ đều là chuyện mới.

5. Những lời giải thích không liên quan đến AI#

Có thể coi như thị trường vừa trải qua nhiều thay đổi cùng lúc, và AI chỉ là một trong số đó.

Bài Stanford cũng ghi thẳng những điểm yếu của chính nó: khoảng cách giảm đi khi kiểm soát trình độ học vấn, có một số xu hướng lệch đã xuất hiện trước khi AI tạo sinh ra đời, và rõ hơn trong dữ liệu ADP so với các khảo sát quốc gia. Họ nhấn mạnh đây là chỉ báo mô tả sớm, chưa phải ước lượng nhân quả. Phần tổng quan trong bài Harvard cho biết một số nghiên cứu khác không thấy khác biệt có hệ thống giữa nghề ít và nhiều chịu ảnh hưởng, ví dụ nghiên cứu của Chandar (2025) và của Financial Times (2025) trên dữ liệu CPS, và nghiên cứu ở Thụy Điển thấy mức giảm nhỏ hơn, khoảng 5,5%. Mình đọc các điểm này qua phần tổng quan của Harvard, không phải qua từng bài gốc.

6. Sáu câu hỏi trước khi tin một con số#

Hình dung rằng sáu câu này là sáu cái đèn pin. Bạn rọi lần lượt vào con số, nếu chỗ nào tối thì đừng vội tin.

Thử áp dụng. Minh họa, tiêu đề tự đặt, không phải bài báo thật: "Việc làm cho dev mới giảm 20%". Sáu câu hỏi: dev mới ở nước nào? Số người đang làm hay số lần tuyển? Giảm từ năm nào, đỉnh hay trước đại dịch? Dữ liệu bảng lương hay tin đăng? Có lãi suất, thuế, tuyển quá tay không? Có nhóm so sánh không? Nếu bài không trả lời được từ ba câu trở lên, hãy xem con số đó như một lời đồn có số, chưa phải số liệu.

7. Việt Nam và Nhật Bản: mình tìm được gì#

• Việt Nam. Mình không tìm được số liệu của cơ quan nhà nước riêng về lập trình viên mới ra trường, cũng không mở được báo cáo công khai nào của các nền tảng việc làm lớn. Thứ gần nhất là khảo sát của ManpowerGroup cho quý 4/2026, theo bài của Tuổi Trẻ (9/9/2026): trong 285 nhà tuyển dụng được hỏi, 57% nói đã tăng tuyển người mới vào nghề so với 2025, và 77% ở nhóm thông tin. Hãy đọc thận trọng: đó là khảo sát nhà tuyển dụng tự khai bởi một công ty nhân sự, bài báo không nói 285 đơn vị này chỉ ở Việt Nam hay không, không định nghĩa "người mới vào nghề", và không tách riêng lập trình viên. Mức chắc: thấp đến trung bình.
• Nhật Bản. Mình không tìm được dữ liệu gốc về lập trình viên mới ở Nhật gắn với AI. Các bài báo hay dẫn dự báo của Bộ Kinh tế, Thương mại và Công nghiệp (METI) rằng đến 2030 Nhật có thể thiếu từ khoảng 160.000 đến 790.000 nhân lực IT tùy kịch bản. Mình chỉ đọc được qua các bản tóm tắt vì trang gốc từ chối truy cập, và đó là dự báo tổng số làm trước khi AI tạo sinh phổ biến, nên không trả lời được câu hỏi về người mới và AI. Mức chắc: thấp. Hãy mở bản gốc trước khi trích.

Nói thẳng: các con số ở bài này chủ yếu là của Mỹ. Việt Nam và Nhật có thể khác, và mình chưa có bằng chứng để nói khác thế nào.

8. Người mới làm gì được dù bên nào đúng#

Hình dung bạn không biết ngày mai mưa hay nắng. Mang theo cả ô lẫn kính râm thì không cần đoán đúng. Các gợi ý dưới đây là suy luận của mình, chưa được kiểm chứng trên nhiều người.

Một điều nữa: con số trung bình của cả nước không phải bản án cho một người. Một lần bị từ chối thường có nhiều lý do cụ thể, như ngân sách hay người khác phù hợp hơn, chứ không phải vì một con số thống kê. Nếu bạn muốn nhìn dài hơi, bài Nghề Dev qua các thời kỳ đặt chuyện này vào lịch sử của nghề, và bài Khi AI viết code nhanh hơn, dev còn làm nghề sáng tạo không? nói về phần việc khó thay thế.

9. Điều chưa biết#

• Nguyên nhân. Chưa ai tách được phần AI khỏi lãi suất, thuế, tuyển quá tay và điều chỉnh sau đại dịch. Các tác giả Stanford và Harvard đều nói điều này theo cách của họ.
• Việc chậm tuyển hay không tuyển nữa. Nếu chỉ là tuyển muộn hơn, người mới vẫn vào được sau vài năm. Nếu là mất hẳn một nấc thang, câu chuyện khác. Dữ liệu hiện nay chưa phân biệt được.
• Nghề phần mềm riêng. Số liệu về lập trình viên 22 đến 25 tuổi nhiều nhất là con số 20% của ADP và các khảo sát nhỏ. Khảo sát CPS có rất ít người ở nhóm này mỗi tháng.
• Ngoài nước Mỹ. Mình không có bằng chứng đáng tin cho Việt Nam và Nhật Bản.
• Số liệu đổi theo phiên bản. Con số của Stanford đã đổi từ 13% sang 16% rồi 19% khi có thêm dữ liệu và đổi cách tính. Bài này sẽ lỗi thời, vì vậy hãy xem ngày đăng.
• Giới hạn của mình. Mình đọc trực tiếp hai bài PDF và các trang gốc đã nêu, còn lại qua tóm tắt. Mình không có dữ liệu thô để tự kiểm lại, nên phần tính toán chỉ làm lại từ các con số công bố.

10. Nhìn cân bằng#

• Bài này không bảo bạn lo hay đừng lo. Số liệu cho thấy một vùng hẹp (người trẻ ở nghề dễ bị AI thay một phần) đang yếu đi, và chưa cho thấy chuyện toàn nền kinh tế.
• "Chưa thấy" khác "không có". Yale Budget Lab nói chưa thấy xáo trộn, không nói sẽ không có. Theo bản tóm tắt mình đọc, họ cho rằng AI nhiều khả năng sẽ để lại dấu ấn về sau.
• "Có thấy" khác "do AI". Mọi con số về người mới ở trên đều là tương quan.
• Cái gì đo được thì dễ bị kể thành chuyện. Chuyện "AI đã lấy việc của bạn" gọn hơn "nhiều thứ cùng đổi, chưa tách được". Gọn hơn không có nghĩa đúng hơn.

11. Kết luận#

Khi hai bài báo cho hai con số trái nhau, thường là chúng đang cân hai thứ khác nhau bằng hai cái cân khác nhau. Hãy hỏi sáu câu: đếm ai, đếm gì, mốc nào, nguồn nào, còn gì thay đổi, chắc đến đâu. Với người mới, việc làm những điều có ích trong mọi kịch bản quan trọng hơn việc đoán đúng bên: tự đo thị trường của mình, mở rộng cửa, có bằng chứng thật về kỹ năng, và xem lại mỗi quý.

Bắt đầu tuần này: mở một bảng tính, ghi 20 tin tuyển ở nơi bạn muốn nộp hồ sơ, và đừng đổi kế hoạch vì một tiêu đề.

Nguồn tham khảo#

Hãy mở bản gốc trước khi trích lại bất kỳ con số nào. Nguồn nào mình chỉ đọc qua tóm tắt hoặc báo chí đều được ghi rõ ở trên.

• Brynjolfsson, Chandar, Chen: Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of AI (Stanford Digital Economy Lab; phiên bản mình đọc ghi tháng 8/2026, dữ liệu đến 6/2026)
• ADP Research: Yes, AI is affecting employment, here's the data (số 6% và 20% cho lập trình viên trẻ nhất, 7/2025)
• Hosseini, Lichtinger: Generative AI as Seniority-Biased Technological Change (SSRN 5425555; bản 6/5/2026)
• SignalFire: State of Tech Talent Report 2025
• Ramp Economics Lab: Companies hire more after AI adoption (30/6/2026)
• Federal Reserve Bank of New York: The Labor Market for Recent College Graduates
• Economic Innovation Group: A viral chart on recent graduate unemployment is misleading (đọc lại số 6,1% và 7,5% theo ngành, ACS 2023)
• Yale Budget Lab: Evaluating the Impact of AI on the Labor Market: Current State of Affairs và Fortune: bài về cập nhật 2/2026 và "AI washing"
• FRED: Software Development Job Postings on Indeed in the United States (Indeed Hiring Lab)
• Baker Tilly: Domestic research expenditures, Section 174 under the 2025 tax act (tổng hợp của công ty kiểm toán, không phải văn bản luật)
• Tuổi Trẻ News: Vietnam among region's strongest hiring markets, yet employers struggle to find skilled workers (9/9/2026, khảo sát ManpowerGroup)
• Bài liên quan trong blog: Fresher thời AI: kế hoạch 12 tháng, Phỏng vấn thời AI: kế hoạch hai tuần, Ai chịu trách nhiệm khi AI sai?, Nghề Dev qua các thời kỳ

Dành cho người đang học một thư viện hoặc ngôn ngữ mới, nhất là sinh viên và fresher. Không cần biết trước về nghiên cứu hay thống kê, từ kỹ thuật nào cũng có giải thích ngắn.

Bằng chứng về chuyện này còn ít và còn mới, phần lớn là nghiên cứu nhỏ, ngắn. Kế hoạch bốn tuần là gợi ý của mình, chưa ai kiểm chứng. Hãy xem nó như một thí nghiệm bạn tự chạy trên chính mình.

Tóm tắt nhanh#

• Cách dùng AI có thể quan trọng hơn việc có dùng hay không. Trong một thí nghiệm nhỏ của Anthropic, nhóm giao hết việc cho AI hiểu bài kém hơn, còn nhóm dùng AI để hỏi và hiểu thì giữ được điểm.
• Nhanh hơn chưa chắc là học nhiều hơn. Nhóm dùng AI chỉ nhanh hơn vài phút, và khác biệt đó chưa đủ để kết luận.
• Cảm giác không phải số đo. Trong một nghiên cứu khác (METR), người dùng AI mất lâu hơn 19% nhưng vẫn tin mình nhanh hơn.
• Kế hoạch bốn tuần: có buổi AI bật, buổi AI tắt, và một bài tự kiểm tra 10 điểm vào mỗi thứ Sáu.
• Bốn quy tắc: đoán trước khi hỏi, xin giải thích chứ không chỉ xin code, viết lại từ trí nhớ, giữ buổi AI tắt.
• Có những lúc để AI làm trước là ổn. Bài nói rõ lúc nào.

Từ khó, nói dễ#

1. Hình dung: xem người khác nấu và chỉ đường bằng GPS#

Hãy hình dung hai cách học nấu ăn. Cách thứ nhất, bạn đứng xem một đầu bếp nấu xong cả món. Bạn được ăn, nhưng hôm sau chưa chắc nấu lại được. Cách thứ hai, bạn tự nấu, có một người phụ bếp đứng cạnh chỉ chỗ sai và giải thích vì sao. Món có thể ra chậm hơn, nhưng tay bạn nhớ.

Chỉ đường cũng vậy. Theo GPS, bạn đến nơi rất nhanh, nhưng tắt máy là lạc. Học bản đồ thì lúc đầu chậm, rồi bạn tự tìm được đường kể cả khi mất sóng.

Để dễ hình dung, có thể coi AI là cả đầu bếp lẫn GPS: nó làm được hộ bạn, và đó vừa là sức mạnh vừa là rủi ro. Câu hỏi của bài này là: khi nào nên để nó làm hộ, khi nào nên tắt nó đi để tay mình nhớ?

Một lưu ý chung: chưa ai hiểu hết bên trong AI, và nghiên cứu về chuyện học cùng AI mới có vài năm. Các hình ảnh trong bài chỉ để dễ hình dung.

2. Bằng chứng nói gì#

Số liệu lấy từ trang nghiên cứu của Anthropic và bài arXiv. Hai nguồn này làm tròn khác nhau một chút (một bên nêu 50% và 67%, một bên nêu chênh 4,15 điểm trên 27), nên mình viết "khoảng". Thời gian hoàn thành của nhóm AI nhanh hơn vài phút, nhưng các bản tóm tắt nêu con số hơi khác nhau và đều không có ý nghĩa thống kê.

Sáu cách dùng AI trong thí nghiệm của Anthropic#

Nhóm nghiên cứu xem lại video quay màn hình và chia người dùng AI thành sáu kiểu:

Ba kiểu đầu học kém, ba kiểu sau giữ được việc học. Điểm chung của ba kiểu sau là bạn vẫn tự nghĩ: hỏi để hiểu, hoặc tự xử lý lỗi. Nhưng mỗi nhóm chỉ có 2 đến 7 người, và đây là phân tích mô tả, nên chỉ nên coi là gợi ý cho cách dùng, không phải quy luật.

Vì sao "đoán trước" và "viết lại từ trí nhớ" có lý#

Hướng dẫn giảng dạy của MIT (Teaching and Learning Lab) nói rằng tự nhớ lại thông tin giúp nhớ lâu hơn việc xem lại, và dẫn nghiên cứu Roediger và Karpicke (2006). Cùng trang đó nói đoán sai rồi được xem đáp án có giải thích thì học tốt hơn, và gợi ý giải thích cho người học rằng sự vất vả đó là "khó khăn có ích" (desirable difficulties, Bjork 1994). Hướng dẫn của Đại học Arizona thêm rằng câu hỏi bắt người học dự đoán hoặc so sánh có ích hơn câu chỉ yêu cầu nhắc lại định nghĩa.

Đây là bằng chứng từ lớp học nói chung. Chưa có nghiên cứu nào thử đúng kế hoạch này với AI. Mình dùng nó như lý do hợp lý để thiết kế quy tắc, không phải bằng chứng rằng kế hoạch hiệu quả.

3. Minh họa: cùng một việc, hai cách học#

Đây là ví dụ minh họa, số liệu giả định, không phải người thật.

Một người học đang viết đoạn tải dữ liệu bằng thư viện mới.

Cách A, giao hết:

Cách B, đoán trước rồi hỏi vì sao:

Cách B chậm hơn 25 trừ 10 bằng 15 phút. Đổi lại, ở 11:30 người học tự sửa được. Các mốc giờ ở đây là giả định để minh họa, không phải số đo.

Điều đi kèm với ví dụ này là bằng chứng ở mục 2, không phải bản thân ví dụ: nhóm giao hết trong thí nghiệm của Anthropic điểm thấp hơn.

4. Bốn quy tắc#

1. Đoán trước khi hỏi. Ghi một dòng: "mình nghĩ kết quả sẽ là X". Chạy hoặc hỏi xong thì so sánh. Đoán sai không sao, chỗ lệch chính là chỗ bạn sắp học.
2. Xin giải thích, không chỉ xin code. Hỏi vì sao đoạn này viết thế, trường hợp nào nó sẽ sai, và có cách khác không. Trong nghiên cứu của Anthropic, đây gần với nhóm "xin code kèm giải thích".
3. Viết lại từ trí nhớ. Sau khi hiểu, đóng tab AI và tài liệu, tự gõ lại. Chỗ nào bí thì đánh dấu, mở lại, rồi gõ lại lần nữa.
4. Giữ buổi AI tắt. Mỗi tuần có buổi chỉ dùng tài liệu chính thức và thông báo lỗi của máy. Đây là lúc bạn kiểm tra tay mình còn nhớ hay không.

Hai quy tắc phụ: khi nhận code từ AI, duyệt nó như code người lạ; và nhớ rằng AI có thể sai bằng giọng rất chắc chắn.

5. Kế hoạch bốn tuần#

Giả định mỗi tuần 4 buổi 60 phút (thứ Hai đến thứ Năm) và bài tự kiểm tra 30 phút vào thứ Sáu (15 phút làm bài, 15 phút xem lại). Chọn một thư viện hoặc ngôn ngữ để đo được.

Tính thời gian#

• Mỗi tuần 4 buổi, mỗi buổi 60 phút, tổng giờ học 4 nhân 4 nhân 60 bằng 960 phút.
• Thứ Sáu: 4 nhân 30 bằng 120 phút. Tổng cả kế hoạch: 960 cộng 120 bằng 1.080 phút, tức 18 giờ.
• Phút AI tắt: tuần 1 và tuần 4 mỗi tuần 180 phút, tuần 2 và 3 mỗi tuần 120 phút, tổng 600 phút. Cộng 120 phút thứ Sáu (không AI) được 720 phút.
• Tỷ lệ AI tắt: 720 chia 1.080 bằng 66,7%. Phút AI bật là 360.

Tỷ lệ này là lựa chọn của mình, không có nghiên cứu nào nói con số đúng. Nếu bạn đang chạy deadline, hãy giữ ít nhất các buổi tuần 1 và bài thứ Sáu.

6. Bài tự kiểm tra mỗi thứ Sáu#

Không AI, không tài liệu, 15 phút, 10 điểm:

Sau đó mở tài liệu, chấm lại và ghi chỗ sai vào sổ. Chỗ sai là đề bài của tuần sau.

Ví dụ giả định về một người học: tuần 1 được 4 trên 10 (40%), tuần 2 được 5 (50%), tuần 3 được 7 (70%), tuần 4 được 8 (80%). Từ tuần 1 đến tuần 4 tăng 4 điểm, tức 40 điểm phần trăm. Đây là số giả định, và bài thi tự chấm nên có sai số. Hãy nhìn xu hướng của chính bạn, đừng so với người khác.

Một cách thử tự so sánh: trong mỗi tuần, chọn hai khái niệm học khi AI bật và hai khái niệm học khi AI tắt, rồi xem phần nào bạn nhớ tốt hơn vào thứ Sáu. Đây chỉ là bốn mẫu, nên chỉ để bạn tự rút kinh nghiệm.

7. Khi nào cho AI làm trước cũng ổn#

Anthropic lưu ý rằng một nghiên cứu trước đó của họ ghi nhận AI tăng năng suất ở những việc người làm đã thành thạo, nên hai kết quả có thể không mâu thuẫn nhau.

8. Nhìn cân bằng#

• Thí nghiệm chỉ kéo dài khoảng một giờ. Chưa biết sau vài tháng khoảng cách thu hẹp hay giữ nguyên.
• Mẫu nhỏ, một thư viện, một lần kiểm tra. Tác giả cũng nêu các hạn chế này, và một thí nghiệm khác có thể ra kết quả khác.
• Do một hãng AI thực hiện. Kết quả có phần bất lợi cho việc dùng AI, nhưng bạn vẫn nên đọc bản gốc và đối chiếu với nguồn độc lập.
• Công cụ trong thí nghiệm là chat. Công cụ tự động viết cả dự án có thể cho kết quả khác, và các tác giả cũng nói điều đó.
• Chưa so với học cùng người thật. Không rõ AI hay một người hướng dẫn giỏi hơn.
• Nghiên cứu toán PNAS là học sinh phổ thông. Không chắc kết quả áp dụng nguyên cho người lớn học lập trình.
• Khảo sát Microsoft và CMU là tự khai, chỉ có tương quan.
• Kế hoạch này chưa được thử trên nhiều người. Nếu bạn thấy nó quá chậm hoặc quá nghiêm, hãy chỉnh tỷ lệ AI tắt, miễn là vẫn có bài thi thứ Sáu để đo.

9. Kết luận#

Câu hỏi không phải "có nên dùng AI để học không", mà là dùng thế nào để tay mình vẫn nhớ. Bằng chứng hiện có, dù còn mỏng, cùng chỉ về một hướng: người vẫn tự nghĩ, tự hỏi vì sao và tự gõ lại thì giữ được việc học. Hãy đoán trước, xin giải thích, viết lại từ trí nhớ, giữ buổi AI tắt, và đo bằng bài thi thứ Sáu.

Bắt đầu ngay hôm nay: chọn một thư viện, ghi sổ dự đoán đầu tiên, và xếp lịch bài thi thứ Sáu đầu tiên.

Nếu bạn chưa có nền tảng, hãy xem kế hoạch 12 tháng cho fresher. Nếu sắp đi phỏng vấn, xem kế hoạch hai tuần. Để nghe hai người nói chuyện về chuyện này, xem đối thoại giữa một fresher và một senior.

Nguồn tham khảo#

Hãy mở bản gốc trước khi trích dẫn, vì số liệu có thể được cập nhật.

• Shen và Tamkin, "How AI Impacts Skill Formation", arXiv 2601.20245 (1/2026)
• Anthropic, trang giới thiệu nghiên cứu "How AI assistance impacts the formation of coding skills"
• Bastani và cộng sự, "Generative AI without guardrails can harm learning", PNAS 2025
• Wharton, bài tóm tắt nghiên cứu của Bastani và cộng sự
• METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (7/2025)
• Lee và cộng sự, "The Impact of Generative AI on Critical Thinking", CHI 2025 (bản PDF của tác giả)
• MIT Teaching + Learning Lab, "Help Students Retain, Organize and Integrate Knowledge"
• Roediger và Karpicke, "Test-enhanced learning", Psychological Science (2006)
• Đại học Arizona, "L2L Strategy: Retrieval Practice"
• Bài liên quan trong blog: Fresher thời AI: kế hoạch 12 tháng, Phỏng vấn thời AI: kế hoạch hai tuần, Đối thoại fresher và senior, Duyệt code do AI viết, Vì sao không nên tin AI tuyệt đối

Dành cho bất kỳ ai dùng AI để viết code hoặc giao việc cho AI agent, kể cả người mới. Không cần biết bảo mật. Thuật ngữ nào cũng đi kèm một ví dụ đời thường, và phần tính toán được đánh dấu rõ để bỏ qua nếu bạn không cần.

Số liệu lấy từ nguồn công khai, có liệt kê cuối bài. Ví dụ ghi là "minh họa" được dựng lại, không nhắc đến người hay công ty cụ thể nào. Nguyên nhân sâu xa khiến AI bịa tên thư viện chưa ai hiểu hết, nên các hình dung dưới đây chỉ là cách tưởng tượng để dễ nhớ.

Tóm tắt nhanh#

• Khi viết code, AI đôi khi gợi ý một thư viện nghe rất hợp lý nhưng không tồn tại. Một nghiên cứu lớn tại USENIX Security 2025 đo được tỷ lệ này trung bình ít nhất 5,2% với mô hình thương mại và 21,7% với mô hình mã nguồn mở, trên các thí nghiệm năm 2024.
• Nếu cùng một tên giả được gợi ý lặp lại, kẻ xấu có thể đăng ký trước tên đó trên kho thư viện công cộng như npm hay PyPI và để mã độc vào trong. Cách tấn công này được gọi là slopsquatting.
• Trong nghiên cứu trên, khi chạy lại 500 câu hỏi từng ra tên giả, khoảng 43% tên giả xuất hiện đủ cả 10 lần. Tức là tên bịa không hoàn toàn ngẫu nhiên, đủ để kẻ xấu đoán trước.
• Đã có thí nghiệm thật: gói rỗng huggingface-cli nhận hơn 30.000 lượt tải, và tên react-codeshift lan sang hơn 200 repo. Cả hai do nhà nghiên cứu đăng ký, không chứa mã độc.
• Rủi ro có thật nhưng chưa rõ lớn đến đâu: tôi chưa tìm thấy ghi nhận chắc chắn về một vụ slopsquatting gây thiệt hại lớn. Điều đáng lo hơn là agent có thể tự chạy lệnh cài mà không ai xem.
• Cách phòng không cần công cụ đắt tiền: khóa phiên bản bằng lockfile, nhìn qua gói mới trước khi cài, tắt script cài đặt, bắt agent xin duyệt và chạy trong môi trường cô lập.

Từ khó, nói dễ#

1. Hình dung trước: cô nhân viên và cửa hàng mạo danh#

Hình dung bạn hỏi một nhân viên bán hàng rất nhiệt tình: "Có ốp lưng nào hợp máy này không?" Cô ấy trả lời ngay: "Có món Zorbo Pro, bên em có bán." Thực ra không có món nào tên đó. Cô ấy không nói dối, chỉ là cô ấy giỏi nói những cái tên nghe hợp lý.

Giờ hình dung có một kẻ lừa đảo nhận ra cô ấy hay nhắc đúng cái tên ấy với rất nhiều khách. Hắn mở một cửa hàng ngay trước cửa, treo bảng "Zorbo Pro" và bán một món hàng độc hại. Lần sau cô ấy gợi ý, khách đi theo và vào đúng cửa hàng của hắn.

Đó là slopsquatting. Cô nhân viên là AI, "món hàng" là tên thư viện, cửa hàng là kho gói như npm, và lệnh npm install là bước chân vào cửa. Khác với việc gõ nhầm tên, ở đây người dùng không sai gì cả. Họ chỉ làm theo lời gợi ý.

Thuật ngữ này được cho là do Seth Larson, nhà phát triển bảo mật của Python Software Foundation, đặt vào tháng 4/2025, theo cách thuật lại của Wikipedia và của Andrew Nesbitt, người giúp nó lan rộng. Tôi chưa tìm được bài viết gốc của ông Larson để đối chiếu, nên coi đây là thông tin thuật lại, không phải trích nguyên văn.

Điều rút ra: nguy cơ không nằm ở chỗ AI sai, mà ở chỗ cái sai của AI có thể đoán trước được và có người sẵn sàng chiếm chỗ.

2. Hai thí nghiệm có thật và một sự cố dễ nhầm#

2.1 Gói rỗng huggingface-cli (Lasso Security, 2023 đến 2024)#

Bar Lanyado, nhà nghiên cứu của Lasso Security, thấy các mô hình AI cứ gợi ý lệnh cài một gói tên huggingface-cli trên PyPI. Gói đó không có thật, cách cài đúng là huggingface_hub[cli]. Ông đăng ký một gói rỗng dưới tên đó để xem có ai cài không.

Theo các báo thuật lại, gói nhận hơn 30.000 lượt tải trong khoảng ba tháng. Các nguồn ghi con số khác nhau, từ khoảng 15.000 đến 35.000, nên hãy coi đây là cỡ vài chục nghìn. The Register còn ghi rằng tên giả này xuất hiện trong hướng dẫn cài đặt của một kho mã nghiên cứu của Alibaba, và đã được sửa sau khi ông báo.

Cần thận trọng: lượt tải không chứng minh ai bị hại. Chưa rõ bao nhiêu lượt đến từ code do AI sinh ra, bao nhiêu từ người chép theo hướng dẫn, bao nhiêu từ máy quét tự động.

Điều rút ra: một cái tên bịa lặp lại đủ nhiều thì có người cài thật, và nó còn có thể chui vào tài liệu của người khác.

2.2 react-codeshift lan sang hơn 200 repo (Aikido Security, 2025 đến 2026)#

Theo bài của Aikido Security, một commit ngày 17/10/2025 vào một repo công khai thêm 47 "skill" (tệp hướng dẫn cho agent) do mô hình ngôn ngữ sinh ra. Ít nhất hai tệp trong đó chứa lệnh npx react-codeshift. Tên này có vẻ là sự pha trộn của hai gói thật là jscodeshift và react-codemod. Gói react-codeshift chưa từng tồn tại.

Các tệp đó bị chép và fork ra nhiều nơi. Theo Aikido, tháng 12/2025 có hơn 200 repo nhắc đến lệnh này, và đến ngày 14/1/2026, khi nhà nghiên cứu Charlie Eriksen đăng ký tên gói, con số là 237 trở lên. Một tìm kiếm mã trên GitHub khi đó cho khoảng 215 tệp khớp. Con số nên hiểu là "hơn 200", vì cách đếm khác nhau cho kết quả khác nhau. Ngay sau khi đăng ký, gói nhận khoảng 74 lượt tải trong ngày đầu, rồi mỗi ngày chỉ một đến bốn lượt. Tác giả cho rằng lượt tải rỉ rả này gợi ý có agent thật đang thử chạy lệnh. Đây là suy đoán của họ, không phải kết quả đã kiểm chứng. Gói được giữ làm chỗ trống an toàn, không chứa mã độc.

Điều rút ra: lỗi do AI bịa ra không đứng yên. Nó được chép, fork, dịch rồi trở thành "chuẩn" mà chính các agent khác lại đọc theo.

2.3 Sâu npm tháng 5/2026: nguy hiểm thật, nhưng không phải slopsquatting#

Nhóm nghiên cứu của Cloud Security Alliance (CSA) trong ghi chú ngày 17/5/2026 mô tả một đợt sâu npm gắn với nhóm TeamPCP: 373 phiên bản gói độc hại trên 169 gói npm và hai gói PyPI. Ghi chú nói rằng sâu này còn ghi cấu hình vào các tệp của công cụ lập trình AI và có phiên bản mang cả dấu provenance hợp lệ. Đây là ghi chú thứ cấp, thuật lại nguồn của người khác, nên hãy mở bản gốc trước khi trích dẫn. CSA cũng tự nói một số khẳng định "đầu tiên" thuộc về các nhà nghiên cứu mà họ dẫn.

Điểm cần nhớ: đây là chuyện gói thật bị chiếm quyền, không phải gói do AI bịa. Nó nằm ở đây vì hai lý do. Thứ nhất, nó cho thấy kho gói là mục tiêu thật và agent chạy lệnh cài là mắt xích dễ bị lợi dụng. Thứ hai, nó cho thấy provenance không phải bảo chứng tuyệt đối. Thói quen phòng thủ ở phần 6 hợp cho cả hai loại sự cố.

Điều rút ra: đừng chỉ nhìn tên "slopsquatting". Việc cần làm là kiểm soát cái gì được cài vào máy bạn, dù tên gói do AI bịa hay gói thật bị đầu độc.

3. Cơ chế từng bước#

Hình dung một dây chuyền bốn mắt xích. Cần nói trước: vì sao mô hình bịa tên gói thì chưa ai hiểu hết. Một cách nghĩ phổ biến là mô hình luôn cố viết ra tên trông giống tên thư viện thật, và tên thật thường ghép từ những từ quen như react, codemod, cli. Đây là cách hình dung, không phải kết luận đã chứng minh.

1. Bạn hỏi. Bạn (hoặc agent) cần thêm một chức năng, ví dụ đọc tệp CSV, và nhờ AI viết code kèm lệnh cài.
2. AI gợi ý một tên. Đôi khi tên đó không có trên kho gói. Theo nghiên cứu, chỉ khoảng 13,4% tên giả chỉ cách một tên thật một hai chữ cái, nên đây không chủ yếu là lỗi gõ sai.
3. Kẻ xấu đăng ký tên đó. Kho gói công cộng cho phép đăng ký tên còn trống rất nhanh. Nếu tên giả lặp lại, kẻ xấu có thể hỏi các mô hình phổ biến nhiều lần để xem tên nào hay xuất hiện và chiếm tên đó.
4. Lệnh cài chạy thành công. Lúc đầu lệnh cài báo lỗi "không tìm thấy", vô hại. Sau khi tên bị chiếm, cùng lệnh đó chạy được, và các script cài đặt có thể chạy ngay trên máy của người cài hoặc máy CI.

3.1 Phép tính để bạn tự kiểm lại (minh họa, có thể bỏ qua)#

Đây là ví dụ minh họa với số bịa cho dễ tính, dựa trên hai con số thật của nghiên cứu làm mốc: 5,2% (mô hình thương mại) và 43% (tên giả lặp đủ 10 lần). Giả sử một nhóm 10 dev, mỗi người nhờ AI gợi ý lệnh cài 5 lần mỗi ngày làm việc, trong 20 ngày làm việc.

devs, per_day, days = 10, 5, 20
suggestions = devs * per_day * days          # 1000
fake_rate = 0.052                            # mốc thấp của mô hình thương mại
repeat_rate = 0.43                           # tên giả lặp đủ 10 lần trong thử nghiệm
fake = suggestions * fake_rate               # 52
predictable = fake * repeat_rate             # 22.36
check_minutes = fake * 2                     # kiểm tra mỗi gói 2 phút
print(suggestions, round(fake), round(predictable), check_minutes, check_minutes / devs)
# 1000 52 22 104.0 10.4

Đọc kết quả: trong 1.000 lời gợi ý có khoảng 52 tên giả, trong đó cỡ 22 tên thuộc loại lặp lại, tức là loại kẻ xấu có thể đoán trước. Nếu một trong số đó bị chiếm và không ai kiểm, một lệnh npm install là đủ. Ngược lại, kiểm mỗi gói mới trong 2 phút tốn tổng cộng khoảng 104 phút một tháng cho cả nhóm, cỡ 10 phút mỗi người. Chi phí kiểm thấp hơn rất nhiều so với một lần cài nhầm.

Lưu ý: 43% đo trên 500 câu hỏi đã từng ra tên giả, không phải trên mọi câu hỏi, và 5,2% là trung bình theo từng tên gói gợi ý, không theo từng người dùng. Con số của nhóm bạn có thể khác nhiều, hãy xem đây là cách tính, không phải dự báo.

4. Chỗ nào trong công việc hằng ngày dễ hở#

Hình dung công trường: người thợ giỏi vẫn có thể lấy nhầm vật tư nếu không ai kiểm kho.

4.1 Minh họa: một buổi sáng với agent#

Đây là tình huống minh họa, không nhắc đến người hay sản phẩm thật. Tên gói trong ví dụ là bịa.

• 10:00. Một dev nhờ agent: "Gộp các tệp CSV trong thư mục này rồi làm sạch cột ngày."
• 10:03. Agent viết code dùng gói csv-tidy-helper-x và chạy lệnh cài. Agent đang ở chế độ tự duyệt nên lệnh chạy luôn.
• 10:04. Tên này chưa từng có trên kho, nhưng tuần trước ai đó đã đăng ký nó. Lệnh cài thành công, script cài đặt chạy.
• 11:30. Dev thấy code chạy ổn, mở PR. Lockfile thêm 14 dòng, không ai đọc.

Việc nên làm: bắt agent dừng ở lệnh cài và hỏi. Dev tra tên gói: ngày tạo là tuần trước, 3 lượt tải, không có kho mã nguồn. Dấu hiệu quá rõ để từ chối. Nếu lệnh cài đã chạy từ trong sandbox, thiệt hại cũng bị giới hạn. Phần 6 liệt kê các lớp bảo vệ này.

Minh họa này không thay cho bằng chứng. Bằng chứng là các nghiên cứu ở phần sau. Ngoài ra, nghiên cứu của Stanford (Perry và cộng sự, 2022) thấy người dùng trợ lý AI viết code kém an toàn hơn nhưng lại tin hơn rằng code của mình an toàn, nên việc không ai nhìn lại lệnh cài là có cơ sở để lo. Xem thêm bài Duyệt code do AI viết và bài Vì sao không nên tin AI tuyệt đối.

5. Số liệu từ nghiên cứu và vụ việc#

Đọc cho đúng: cả bảng cho thấy hai điều khác nhau. Có bằng chứng tốt rằng AI bịa tên gói, và rằng tên bịa có thể được đăng ký và có người cài. Chưa có bằng chứng tốt về việc điều này gây thiệt hại thật ở quy mô nào.

6. Thói quen áp dụng từ ngày mai#

Hình dung nhà bếp có quy trình nhập hàng: món mới phải có hóa đơn và người ký nhận, không phải ai muốn thì nhét vào kho.

6.1 Tám bước#

1. Khóa phiên bản bằng lockfile và dùng npm ci thay vì npm install trên CI và máy sạch. Theo tài liệu npm, npm ci cài đúng theo lockfile và báo lỗi nếu lockfile lệch với package.json.
2. Kiểm tra gói mới trước khi cài: ngày tạo, số lượt tải, kho mã nguồn có thật và khớp, người duy trì, lịch sử phiên bản. Gói tạo tuần trước mà có tên rất "đúng ý" là dấu hiệu cần dừng.
3. Tắt script cài đặt mặc định bằng --ignore-scripts hoặc ignore-scripts=true trong .npmrc. Chỉ bật cho gói bạn đã tin.
4. Dùng danh sách cho phép hoặc kho gương nội bộ (private registry mirror): chỉ những gói đã được duyệt mới cài được, tên lạ sẽ không tìm thấy.
5. Xem provenance bằng npm audit signatures khi gói có. Nhớ rằng nó cho biết nguồn gốc, không bảo đảm sạch.
6. Bắt người duyệt mọi lệnh cài của agent. Đừng bật chế độ tự duyệt cho lệnh cài hoặc lệnh chạy code lạ.
7. Chạy agent trong sandbox hoặc devcontainer, không đưa khóa thật, token deploy hay quyền ghi lên production vào đó.
8. Đọc khác biệt của lockfile trong mỗi PR: có gói mới nào không, tên gì, từ kho nào. Việc này nằm trong danh sách ở bài Duyệt code do AI viết.

6.2 Bốn lệnh nên nhớ#

# 1. Cài đúng theo lockfile, không chạy script cài đặt
npm ci --ignore-scripts

# 2. Nhìn gói trước khi cài: ngày tạo, người duy trì, kho mã nguồn
npm view some-package time.created time.modified maintainers repository.url
curl -s https://api.npmjs.org/downloads/point/last-week/some-package

# 3. Kiểm tra chữ ký và provenance của những gì đã cài
npm audit signatures

# 4. Sau thay đổi của agent: có dòng resolved mới nào trong lockfile không
git diff package-lock.json | grep '^+.*"resolved"'

Với Python, lệnh tương tự là pip install --require-hashes -r requirements.txt, nhưng cần lockfile có băm (hash) từng gói. Cú pháp các công cụ khác nhau, hãy xem tài liệu công cụ bạn dùng.

6.3 Mười câu hỏi trước khi cài#

1. Tên gói này có trên kho thật không, và tôi tra bằng trang kho hay bằng trí nhớ?
2. Gói tạo từ khi nào? Dưới vài tuần thì nghi ngờ.
3. Lượt tải mỗi tuần là bao nhiêu so với mức gói này đáng có?
4. Có kho mã nguồn công khai khớp với tên gói không?
5. Người duy trì là ai, có lịch sử không?
6. Gói có chạy script lúc cài không?
7. Có gói phổ biến hơn làm cùng việc không?
8. Lệnh cài này là của tôi, hay của agent chưa ai duyệt?
9. Nếu gói độc hại, máy này chứa gì nó có thể lấy?
10. Sau khi cài, lockfile thêm bao nhiêu dòng, và tôi đã đọc chưa?

7. Nhìn cân bằng: biết gì, chưa biết gì#

Khá chắc: các mô hình có bịa tên gói, tỷ lệ đo được ở mức vài phần trăm đến hơn hai mươi phần trăm trong thí nghiệm, tên giả có thể lặp lại, tên bịa có thể được đăng ký, và có người thật cài.

Chưa rõ:

• Tỷ lệ bịa của các mô hình và công cụ mới hơn. Nhiều công cụ giờ biết tra cứu trên mạng hoặc kiểm tra tên gói, có thể giảm tỷ lệ. Tôi chưa thấy số đo độc lập cho từng công cụ.
• Mức thiệt hại thực tế. Tôi chưa tìm thấy ghi nhận chắc chắn về một vụ slopsquatting gây thiệt hại lớn, nhưng việc chưa thấy không có nghĩa là chưa từng xảy ra.
• Các thí nghiệm của nhà nghiên cứu đăng ký gói vô hại. Người xấu thật sẽ không báo.

Đừng thổi phồng. Các sự cố lớn hơn trong chuỗi cung ứng, như sâu npm tháng 5/2026, đến từ gói thật bị chiếm. Nếu chỉ phòng slopsquatting thì bạn bỏ sót phần lớn rủi ro. Thói quen ở phần 6 hợp cho cả hai.

Đừng coi nhẹ. Chi phí phòng ngừa thấp (khoảng 10 phút mỗi người mỗi tháng trong ví dụ trên), còn một agent tự cài gói chưa ai xem có thể chạm vào khóa truy cập và mã nguồn. Bài OWASP Top 10 cho ứng dụng dùng AI đặt rủi ro chuỗi cung ứng vào bản đồ rộng hơn. Nếu agent của bạn gọi công cụ qua MCP, hãy đọc thêm MCP là gì, vì mỗi công cụ cũng là một thứ bạn đang cài vào.

8. Kết luận#

Một cái tên AI bịa ra tự nó vô hại, cho đến khi có người đăng ký nó và có máy nào đó tự cài. Phần lớn rủi ro nằm ở chỗ "không ai nhìn". Hãy cho lệnh cài một chốt kiểm: khóa phiên bản, tra gói mới, tắt script, bắt agent xin duyệt, và đọc lockfile.

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Một số con số được thuật lại khác nhau, và các ghi chú thứ cấp chỉ để tham khảo, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Spracklen và cộng sự, We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025)
• Lasso Security, AI Package Hallucinations và The Register (thí nghiệm huggingface-cli)
• Aikido Security, bài về react-codeshift và các lệnh npx bịa trong tệp skill (2026)
• Nguồn gốc thuật ngữ (thuật lại, chưa tìm thấy bài gốc): Wikipedia, Slopsquatting và Andrew Nesbitt, Slopsquatting meets dependency confusion
• Cloud Security Alliance, Mini Shai-Hulud: npm Worm Targets AI Developer Supply Chain (ghi chú thứ cấp, 17/5/2026)
• npm Docs, Generating provenance statements và lệnh npm ci
• Pearce và cộng sự, Asleep at the Keyboard? (2021) và Perry và cộng sự, Do Users Write More Insecure Code with AI Assistants? (Stanford, 2022)

Dành cho lập trình viên, người làm sản phẩm và trưởng nhóm đang đưa AI vào công việc. Thuật ngữ nào khó đều có giải thích ngắn.

Tác giả không phải luật sư, bài này không phải tư vấn pháp lý. Hai vụ việc được kể lại từ các nguồn công khai (bài tổng hợp của hãng luật, báo, bách khoa mở), không phải từ bản án gốc. Phần "bản đồ trách nhiệm" và năm việc cuối bài là ý kiến của tôi, không phải quy định.

Tóm tắt nhanh#

• Hai vụ việc có thật cho thấy câu "AI làm chứ không phải tôi" không giúp được ai.
• Người dùng kết quả của AI và người đưa AI ra cho khách đều có phần việc phải kiểm tra.
• Trách nhiệm không tự có người nhận. Phải gán tên, trước khi sự cố xảy ra.
• Năm việc một đội có thể làm ngay: một người chịu trách nhiệm, điểm kiểm tra ở chỗ rủi ro cao, nhật ký, đường chuyển cho người, viết lại sự cố không đổ lỗi.

Từ khó, nghĩa dễ#

1. Vụ thứ nhất: chatbot của hãng bay nói sai#

Theo bài tổng hợp của hãng luật Manatt, một hành khách tên Moffatt hỏi chatbot trên trang của Air Canada về vé giá đặc biệt khi có tang. Chatbot trả lời rằng anh có thể mua vé bình thường rồi xin hoàn phần chênh lệch trong vòng 90 ngày. Nhưng chính sách thật của hãng không cho hoàn sau khi bay. Khi anh xin hoàn, hãng từ chối.

Hãng lập luận, theo bài tổng hợp đó, rằng chatbot là một thực thể pháp lý riêng và hãng không phải chịu trách nhiệm về lời nó nói. Tòa trọng tài dân sự ở British Columbia (vụ Moffatt kiện Air Canada, 2024 BCCRT 149) bác lập luận này, cho rằng hãng có nghĩa vụ chăm sóc khách và đã khai báo sai một cách cẩu thả. Hãng phải bồi hoàn khoản chênh lệch, con số được nêu là 650,88 đô la Canada.

Điều đáng nghĩ là số tiền nhỏ, nhưng nguyên tắc thì không: khách không có lý do gì để biết trang nào của website là "đúng" và trang nào là "chatbot nói bậy".

2. Vụ thứ hai: luật sư nộp án lệ do AI bịa#

Trong vụ Mata kiện Avianca (tòa liên bang ở New York, 2023), các luật sư của nguyên đơn nộp văn bản có dẫn nhiều án lệ. Khi phía bên kia không tìm thấy các án lệ ấy, hóa ra chúng do ChatGPT bịa ra, và các luật sư đã không kiểm tra lại. Ngày 22 tháng 6 năm 2023, thẩm phán phạt tổng cộng 5.000 đô la, và nhận xét rằng các luật sư đã "bỏ rơi trách nhiệm" của mình (theo Wikipedia, Bloomberg Law và Above the Law).

Điểm tôi lấy từ vụ này: công cụ không ký tên, người dùng ký. Việc kiểm chứng không biến mất chỉ vì bản nháp được viết bằng máy.

3. Hai vụ, một mẫu chung#

Cả hai đều thiếu một người có tên cầm trách nhiệm kiểm chứng ở khâu cuối.

4. Một bản đồ trách nhiệm (ý kiến của tôi)#

Khi AI sai, thường có bốn bên, mỗi bên có một phần:

Tôi không biết phần việc "đúng" trước pháp luật ở từng nơi. Bảng này chỉ là cách chia việc để một đội khỏi mỗi người nghĩ phần kia lo.

5. Năm việc một đội có thể làm ngay#

1. Gán một người chịu trách nhiệm cho mỗi tính năng AI. Có tên, không phải "cả nhóm". Người đó biết tính năng làm gì, đo thế nào, tắt ra sao.
2. Đặt điểm kiểm tra của con người ở chỗ rủi ro cao. Tiền, sức khỏe, pháp lý, dữ liệu cá nhân, việc không hoàn tác được. Chỗ rủi ro thấp (gợi ý tiêu đề) có thể thoáng hơn. Xem bài Duyệt code do AI viết và OWASP Top 10 cho ứng dụng AI về việc kiểm tra và giới hạn quyền.
3. Ghi nhật ký để truy lại. Khi có khiếu nại, bạn cần biết AI đã nói gì, với ai, lúc nào, dựa trên nguồn nào.
4. Có đường chuyển cho người, và cho khách biết. Khi AI không chắc, hoặc khách nói "tôi muốn gặp người", phải có lối đi. Nói rõ khi nào khách đang nói chuyện với máy, và đừng để lời của máy nghe như cam kết khi nó không phải.
5. Viết lại sự cố theo kiểu không đổ lỗi cá nhân. Hỏi "hệ thống đã cho phép điều này xảy ra thế nào", không hỏi "ai làm". Hai câu chuyện GitLab 2017 và Amazon S3 2017 là ví dụ về cách kể sự cố mà tập trung vào cơ chế. Bài Không nên tin AI tuyệt đối bàn về lý do cần kiểm chứng.

6. Những cái bẫy#

• "AI làm chứ không phải tôi." Hai vụ trên cho thấy lập luận này yếu.
• Duyệt cho có. Người kiểm tra bấm đồng ý hàng trăm lần mỗi ngày mà không đọc. Có tên trên giấy chưa phải là có kiểm tra thật.
• Đổ cho cá nhân cuối chuỗi. Người bấm nút cuối thường chỉ là mắt xích cuối của một hệ thống thiếu kiểm soát.
• Đẩy hết sang nhà cung cấp. Hợp đồng có thể giới hạn trách nhiệm của họ. Đừng giả định, hãy đọc.
• Ghi nhật ký mà không bảo vệ. Nhật ký chứa lời khách nói, cần được giữ cẩn thận như mọi dữ liệu cá nhân.
• Gán trách nhiệm cho một người nhưng không cho họ quyền tắt tính năng.

7. Góc nhìn cân bằng#

• Chỉ hai vụ, qua nguồn thứ cấp. Tôi đọc về chúng qua bài tổng hợp, báo và bách khoa mở, không đọc bản án gốc. Chi tiết có thể thiếu.
• Luật khác nhau theo nơi. Một quyết định của tòa trọng tài ở British Columbia không tự động áp dụng ở nơi khác.
• Kiểm tra mọi thứ là không thực tế. Vì vậy bài mới nói đến rủi ro cao. Chỗ rủi ro thấp, kiểm tra ít cũng được.
• Bản đồ trách nhiệm là một cách chia việc, không phải cách chia lỗi trước pháp luật.
• Có thể tôi đang nhìn lệch vì hai vụ được chọn đều là vụ bị báo chí chú ý. Rất nhiều lần AI sai mà không ai kiện.

8. Kết luận#

Công cụ AI có thể soạn nhanh, nhưng nó không ký tên và không bị phạt. Trách nhiệm vẫn rơi về người và tổ chức đưa kết quả ra. Việc nên làm là gán tên cho trách nhiệm trước khi sự cố xảy ra, đặt kiểm tra ở nơi sai sót đắt giá, và học từ sự cố mà không săn người có lỗi.

Một bước nhỏ hôm nay: chọn một tính năng AI bạn đang chạy và hỏi "nếu nó nói sai với một khách hàng sáng mai, ai là người biết đầu tiên, và ai quyết định tắt nó?" Nếu chưa trả lời được, đó là việc đầu tiên.

Nguồn tham khảo#

• Manatt: AI Gone Wild, Airline Has to Honor a Refund Policy (nguồn thứ cấp, bài tổng hợp của hãng luật)
• Wikipedia: Mata v. Avianca, Inc. (nguồn thứ cấp)
• Bài liên quan trong blog: Duyệt code do AI viết, OWASP Top 10 cho ứng dụng AI, Không nên tin AI tuyệt đối, Ngày kỹ sư xóa nhầm dữ liệu: GitLab 2017, Một lệnh nhầm, bốn tiếng: Amazon S3 2017

Dành cho người làm sản phẩm, trưởng nhóm và lập trình viên đang đưa AI vào sản phẩm. Từ kỹ thuật nào cũng có giải thích ngắn.

Cách chia ba lớp và các chỉ số lấy từ các bài hướng dẫn của người làm nghề (blog, tài liệu của công cụ theo dõi), là nguồn thứ cấp. Các ngưỡng và con số trong bài đều là minh họa, không phải chuẩn. Ví dụ cửa hàng "Hồng" là dựng lại.

Tóm tắt nhanh#

• Số lượt dùng không phải thành công. Hãy đo kết quả của công việc.
• Đo ba lớp cùng lúc: chất lượng, chi phí, niềm tin. Một lớp đơn lẻ tạo điểm mù.
• Chi phí đúng là chi phí cho mỗi kết quả thành công, gồm cả công người duyệt.
• Tỷ lệ chấp nhận cao có thể là tin quá mức. Đặt nó cạnh tỷ lệ đạt từ evals.
• Dùng một bảng một trang và quyết định trước điều gì xảy ra khi chỉ số xấu đi.

Từ khó, nói dễ#

1. Vì sao không đo một con số#

Rất dễ bắt đầu bằng thứ dễ đếm: số lượt gọi, số người dùng. Nhưng một tính năng AI có thể được dùng rất nhiều mà vẫn tệ: trả lời sai, tốn nhiều tiền, hoặc bị người dùng âm thầm bỏ qua.

Các hướng dẫn thực hành (mình đọc qua tóm tắt) đều đồng ý ở hai điểm: đếm lượt gọi là nông, thứ cần đo là công việc được hoàn thành; và nên xếp chỉ số theo lớp vì tập trung vào một lớp tạo điểm mù. Một ví dụ hay gặp: một mô hình đúng 95% vẫn vô ích nếu người dùng không tin nó.

Vì vậy mình chia ba lớp:

Bài này nối với Viết bài kiểm tra cho tính năng AI (lớp chất lượng) và Đừng đo năng suất bằng số dòng code (vì sao chỉ số hoạt động dễ đánh lừa).

2. Lớp chất lượng#

Chất lượng không phải một con số "độ chính xác". Hãy lấy từ phân tích lỗi: gom lỗi thành nhóm và đếm, như trong bài về evals.

Các chỉ số gợi ý:

• Tỷ lệ đạt theo từng nhóm lỗi. Ví dụ "hiểu nhầm ý", "bịa thông tin", "giọng quá cứng". Mỗi nhóm một con số.
• Số lỗi nghiêm trọng. Một lỗi bịa giá khác hẳn một lỗi giọng văn. Đếm riêng lỗi có hậu quả thật.
• Tỷ lệ đạt tổng, nhưng không dùng làm con số duy nhất.

Chỉ số tổng "đạt tất cả" rồi khoan xuống từng nhóm. Hướng dẫn về evals cũng khuyên chấm đạt hoặc không đạt thay vì thang điểm.

Cách theo dõi: chạy lại bộ evals mỗi khi đổi mô hình, đổi lời nhắc hoặc đổi dữ liệu. Nếu bạn đổi mô hình mà không chạy lại, bạn không biết chất lượng thay đổi thế nào.

3. Lớp chi phí#

3.1. Chi phí cho mỗi lượt gọi và cho mỗi kết quả thành công#

Chi phí mỗi lượt gọi là con số dễ lấy. Nhưng một tính năng có thể gọi mô hình rẻ mà cần người sửa lại nhiều, hoặc cần gọi nhiều lần mới ra một kết quả dùng được. Vì vậy chi phí đáng so sánh là:

Chi phí cho mỗi kết quả thành công = (chi phí mô hình + hạ tầng + công người duyệt hoặc sửa) ÷ số kết quả thành công

Ví dụ minh họa (số dựng lại): trợ lý trả lời khách của cửa hàng "Hồng", một tháng.

Nếu chỉ nhìn chi phí mô hình, 20 triệu chia 10.000 lượt, ra 2.000 đồng mỗi lượt, bạn sẽ bỏ sót công người sửa và 1.000 ca thất bại. Đó là lý do "chi phí cho mỗi kết quả thành công" lộ ra nhiều hơn.

3.2. Độ trễ#

Hãy đo độ trễ ở mức p95 (và p99), không chỉ trung bình. Trung bình che mất những lần chậm nhất, mà đó là lúc người dùng bỏ đi. Với tính năng trò chuyện, thời gian đến chữ đầu tiên ảnh hưởng nhiều tới cảm giác nhanh.

4. Lớp niềm tin#

Đây là lớp hay bị bỏ qua. Nhìn từ hành vi người dùng:

Xem xu hướng chứ không chỉ mức tuyệt đối. Một số hướng dẫn nêu rằng một cú nhảy đột ngột của tỷ lệ chỉnh sửa là dấu hiệu chất lượng tụt, không phải do cá nhân hóa.

Bối cảnh: khảo sát Stack Overflow 2025 (hơn 49.000 người trả lời) ghi nhận 46% người dùng không tin độ chính xác của AI và chỉ 3% rất tin. Người dùng sản phẩm của bạn cũng có thể có thái độ tương tự. Niềm tin cần được kiếm, và cần được đo.

5. Cạm bẫy: tỷ lệ chấp nhận cao có thể là tin quá mức#

Đây là điểm mình thấy quan trọng nhất của bài. Nếu người dùng chấp nhận 90% đầu ra nhưng evals cho thấy chỉ 75% thực sự đúng, thì khoảng cách 15 điểm là người dùng đang tin quá mức, không phải tính năng tốt.

Cách đọc: đặt tỷ lệ chấp nhận cạnh tỷ lệ đạt từ evals.

Mình không có dữ liệu để nói tỷ lệ này thường là bao nhiêu. Đây là cách đọc các chỉ số, không phải kết quả đo.

6. Bảng một trang#

Một bảng chín chỉ số, ba lớp, ghi theo tuần.

Ghép đôi: mỗi chỉ số tốc độ hoặc chi phí đi cùng một chỉ số chất lượng. Chi phí giảm mà tỷ lệ đạt tụt không phải tiến bộ.

7. Quyết định trước khi chỉ số xấu đi#

Một bảng không có quy tắc hành động chỉ là trang trí. Ví dụ minh họa, ngưỡng là dựng lại:

Ngưỡng cụ thể tùy rủi ro của tính năng. Tính năng trả lời về tiền cần ngưỡng nghiêm hơn tính năng gợi ý tiêu đề.

8. Những bẫy hay gặp#

• Chỉ đo lượt dùng. Dùng nhiều không có nghĩa là tốt.
• Chỉ có thích hoặc không thích. Phản hồi này ít người bấm và lệch về hai cực. Hãy kết hợp với hành vi (chỉnh sửa, ghi đè).
• Quên công người duyệt trong chi phí. Chi phí mô hình có thể rẻ mà tổng chi phí không rẻ.
• Trung bình che mất đuôi. Hãy xem p95 và các ca tệ nhất.
• Đổi mô hình mà không chạy lại evals.
• Biến chỉ số thành mục tiêu (luật Goodhart): nếu thưởng cho tỷ lệ chấp nhận, người ta sẽ làm nó đẹp lên mà không cải thiện chất lượng.

9. Nhìn cân bằng#

• Nguồn thứ cấp. Cách chia ba lớp đến từ các hướng dẫn của người làm nghề (blog, tài liệu của công cụ theo dõi), không phải nghiên cứu độc lập.
• Không có chuẩn về ngưỡng. Mọi con số trong bài là minh họa. Mình không biết mức tỷ lệ chấp nhận hay chỉnh sửa "bình thường" cho từng loại tính năng.
• Đo lường tốn công. Với một thử nghiệm nhỏ, bảng một trang rút gọn (chất lượng, chi phí, một chỉ số niềm tin) là đủ.
• Chỉ số không thay được việc nghe người dùng. Hãy đọc vài cuộc trao đổi thật mỗi tuần.
• Ví dụ cửa hàng "Hồng" là dựng lại, các con số do mình tạo ra để minh họa công thức.

10. Kết luận#

Một tính năng AI tốt không phải tính năng được gọi nhiều nhất, mà là tính năng cho kết quả đúng, với chi phí hợp lý và được tin đúng mức. Hãy đo ba lớp cùng lúc, tính chi phí cho mỗi kết quả thành công, và đọc tỷ lệ chấp nhận cạnh tỷ lệ đạt.

Việc nhỏ làm ngay: chọn một tính năng AI bạn đang chạy, tính chi phí cho mỗi kết quả thành công (nhớ cộng công người sửa), và so với số bạn vẫn dùng.

Nguồn tham khảo#

• Antoine Buteau: AI product metrics, economics and support burden (thứ cấp, hướng dẫn của người làm nghề)
• PostHog: Product metrics to track for LLM apps (thứ cấp)
• Hamel Husain và Shreya Shankar: LLM Evals, Everything You Need to Know
• Stack Overflow Developer Survey 2025, phần AI
• Bài liên quan trong blog: Viết bài kiểm tra cho tính năng AI, Đừng đo năng suất bằng số dòng code, Vibe coding làm prototype trong một ngày

Đây là câu chuyện có thật, không phải chuyện của mình. Mình kể lại theo báo cáo sau sự cố do chính AWS công bố (link ở cuối bài, mình đọc trực tiếp). Báo cáo không nêu tên người thực hiện lệnh, nên mình cũng không đặt tên và không đoán điều họ nghĩ.

Bài này khác bài GitLab 2017 ở một điểm: đây không phải câu chuyện về sao lưu hỏng, mà về một công cụ cho phép gỡ quá nhiều chỉ bằng một giá trị nhập sai. Giờ trong bài là giờ Thái Bình Dương (PST) như trong báo cáo.

Tóm tắt nhanh#

• Ngày 28/2/2017, lúc 9:37 sáng, một thành viên được ủy quyền của nhóm S3 chạy một lệnh để gỡ một số ít máy chủ khỏi một hệ thống con liên quan đến tính cước. Một giá trị nhập sai khiến nhiều máy chủ hơn dự định bị gỡ.
• Số máy chủ bị gỡ phục vụ hai hệ thống lõi của S3: chỉ mục và phân bổ. Cả hai phải khởi động lại hoàn toàn.
• S3 ở vùng US-EAST-1 chỉ hoạt động bình thường lại lúc 1:54 chiều, khoảng bốn tiếng mười bảy phút sau.
• Điểm đáng nói: lệnh làm đúng điều nó được dạy, chỉ là không có gì ngăn nó gỡ quá nhiều. Cả bảng theo dõi sức khỏe dịch vụ của AWS cũng phụ thuộc vào S3.
• AWS sửa công cụ để gỡ chậm hơn và không bao giờ gỡ xuống dưới mức tối thiểu.

Từ khó, nói dễ#

1. Một việc vận hành bình thường#

Buổi sáng hôm đó, nhóm S3 đang gỡ lỗi một quy trình tính cước chạy chậm ở vùng US-EAST-1. Một thành viên được ủy quyền làm theo một sổ tay thao tác đã có: gỡ một số ít máy chủ khỏi một hệ thống con liên quan đến tính cước, để xem có giúp ích không.

Không có gì lạ ở đây. Gỡ máy chủ khỏi một hệ thống con là việc thường ngày của người vận hành, và có sổ tay cho nó. Đó là một điểm quan trọng: đây là thao tác được cho phép, theo quy trình, bởi người có quyền.

2. 9:37 sáng: một giá trị nhập sai#

Theo báo cáo, lệnh được chạy lúc 9:37, và một trong các giá trị đầu vào bị nhập sai. Kết quả: nhiều máy chủ hơn dự định bị gỡ.

Báo cáo không nói giá trị nào, sai ra sao hay vì sao. Mình không đoán. Điều có thể nói chắc là công cụ nhận giá trị đó và thực hiện, không có chốt nào kiểm tra "lệnh này sắp gỡ bao nhiêu và có an toàn không".

Số máy chủ bị gỡ lại không thuộc hệ thống tính cước mà thuộc hai hệ thống lõi:

• Chỉ mục (index): giữ siêu dữ liệu và thông tin vị trí của mọi đối tượng trong vùng. Cần cho các yêu cầu lấy, liệt kê, ghi và xóa.
• Phân bổ (placement): cấp chỗ lưu cho đối tượng mới khi có yêu cầu ghi. Phụ thuộc vào chỉ mục hoạt động đúng.

Lấy đi từng đó năng lực thì cả hai phải khởi động lại hoàn toàn.

3. Khởi động lại: việc đã nhiều năm chưa làm#

Đây là chi tiết mình thấy đáng suy ngẫm nhất trong báo cáo. AWS viết rằng họ đã nhiều năm chưa khởi động lại hoàn toàn các hệ thống này ở các vùng lớn. Trong thời gian đó S3 lớn lên rất nhiều, và các bước kiểm tra tính toàn vẹn của siêu dữ liệu cần để khởi động lại an toàn khiến việc này lâu hơn dự kiến.

Nói cách khác: khả năng khôi phục chưa từng được thử ở quy mô hiện tại. Nó giống với bài học của GitLab: một bản sao lưu chưa thử khôi phục thì chưa biết có dùng được, và một quy trình khởi động lại chưa từng chạy ở quy mô thật thì chưa biết mất bao lâu.

4. Dòng thời gian#

Tất cả theo giờ Thái Bình Dương, ngày 28/2/2017, vùng US-EAST-1.

Từ 9:37 đến 1:54 chiều là khoảng 4 giờ 17 phút. Báo cáo không nêu thời lượng của riêng từng lần khởi động lại.

5. Ai bị ảnh hưởng, và chi tiết trớ trêu về bảng theo dõi#

Theo báo cáo, các dịch vụ bị ảnh hưởng gồm bảng điều khiển S3, việc khởi chạy máy ảo mới (EC2), các ổ đĩa EBS cần dữ liệu từ ảnh chụp lưu trong S3, và AWS Lambda. Một số dịch vụ còn tồn việc trong lúc gián đoạn và cần thêm thời gian để hồi phục.

Chi tiết trớ trêu: bảng điều khiển của trang theo dõi sức khỏe dịch vụ của AWS cũng phụ thuộc vào S3. Đến 11:37 chưa cập nhật được trạng thái từng dịch vụ, nên AWS phải dùng tài khoản Twitter và dòng chữ trên đầu trang để thông báo.

Bài học chung (suy luận của mình): công cụ báo cáo sự cố không nên sống trên chính thứ đang hỏng.

6. Điều gì khiến một lệnh nhầm thành sự cố lớn#

Dựa trên báo cáo, mình thấy năm lớp cùng làm một giá trị nhập sai thành bốn tiếng gián đoạn. Phần diễn giải này là của mình.

Điểm chung: mỗi lớp đều hợp lý khi đứng riêng, và chỉ khi gặp nhau thì thành sự cố.

7. AWS đã sửa những gì#

Theo báo cáo:

• Gỡ chậm hơn. Công cụ gỡ năng lực được đổi để gỡ với tốc độ thấp hơn.
• Mức tối thiểu. Thêm cơ chế chặn mọi lần gỡ làm hệ thống con xuống dưới mức năng lực tối thiểu cần thiết.
• Rà soát công cụ khác. AWS kiểm tra các công cụ vận hành khác để tìm kiểm tra an toàn tương tự.
• Giảm bán kính ảnh hưởng và rút ngắn khôi phục. Chia nhỏ các hệ thống con thành các ô độc lập. Việc chia nhỏ hệ thống chỉ mục, vốn dự định làm vào cuối năm, được đưa lên làm ngay.
• Bảng theo dõi chạy trên nhiều vùng.

Nhìn chung, AWS không tập trung vào việc cấm một người nhập sai, mà vào việc làm cho nhập sai không gây hại lớn.

8. So với câu chuyện GitLab#

Hai vụ cùng có mô-típ "một lệnh nhầm", nhưng bài học nằm ở các chỗ khác nhau:

Ghép lại: hãy làm cho lệnh nhầm khó hơn, và làm cho hậu quả của nó nhỏ hơn.

9. Mình rút ra gì: câu hỏi cho công cụ có quyền gỡ#

Phần này là gợi ý của mình, không phải kết luận của AWS. Nếu bạn viết hoặc dùng một công cụ có thể gỡ, xóa, tắt, hãy hỏi:

1. Có mức tối thiểu không? Công cụ có chặn mọi thao tác đưa hệ thống xuống dưới mức an toàn không?
2. Có giới hạn tốc độ không? Gỡ chậm cho người vận hành thời gian nhận ra sai.
3. Có cho xem trước không? Chế độ chỉ liệt kê: "lệnh này sẽ gỡ N máy" trước khi gỡ.
4. Bán kính ảnh hưởng là bao nhiêu? Một lệnh nhầm làm hỏng tối đa bao nhiêu?
5. Có khôi phục thử ở quy mô thật chưa? Lần cuối bạn khởi động lại cả hệ thống là khi nào?
6. Công cụ báo cáo sự cố có sống độc lập không?
7. Người thứ hai có nhìn thấy thao tác nguy hiểm không?

10. Khi AI có quyền chạy công cụ#

Câu chuyện này xảy ra năm 2017, nhưng mô-típ rất hiện đại: một công cụ có quyền gỡ, nhận một đầu vào sai, và không có gì chặn. Với AI agent, đầu vào sai có thể đến từ một câu lệnh bị dắt, và agent không "cảm thấy có gì sai".

Đó chính là mục quyền quá rộng (LLM06) trong OWASP Top 10 cho ứng dụng dùng AI: chức năng thừa, quyền thừa, tự chủ thừa. Và các biện pháp ở đó trùng với bài học của AWS: giới hạn chức năng, quyền tối thiểu, bắt người duyệt việc có tác động lớn. Bài MCP là gì nói về cầu chì, và mức tối thiểu của S3 chính là một cầu chì.

11. Nhìn cân bằng#

• Đây là một nguồn chính. Mình dựa vào báo cáo của chính AWS, và báo cáo viết theo góc nhìn của AWS.
• Báo cáo không nêu nhiều chi tiết. Không có tên người, giá trị nhập sai cụ thể hay thời lượng riêng từng lần khởi động lại, nên mình không đoán.
• Phần so sánh và bảng "năm lớp" là diễn giải của mình.
• Sự cố gần mười năm tuổi. Hệ thống đã đổi nhiều, nhưng các nguyên nhân (không có mức tối thiểu, bán kính lớn, khôi phục chưa thử, công cụ phụ thuộc vào thứ hỏng) vẫn rất quen.
• Mình không biết người thực hiện lệnh cảm thấy gì, nên bài không tả điều đó.

12. Kết luận#

Một giá trị nhập sai, bốn tiếng, và một phần internet chậm lại. Nhưng điều AWS chọn sửa không phải là "bảo người vận hành đừng nhập sai". Họ sửa công cụ để lệnh nhầm không gỡ quá nhiều và hệ thống để hậu quả nhỏ hơn. Đó là cách nghĩ đáng học nhất.

Việc nhỏ làm ngay: tìm một công cụ có quyền gỡ hoặc xóa mà bạn đang dùng, và hỏi nó có mức tối thiểu và chế độ xem trước không. Nếu chưa, thêm vào việc cần làm.

Nguồn tham khảo#

• AWS: Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region
• Bài liên quan trong blog: Ngày một kỹ sư xóa nhầm dữ liệu: câu chuyện GitLab 2017, OWASP Top 10 cho ứng dụng dùng AI, MCP là gì? Giải thích bằng ổ cắm điện

Dành cho người viết hoặc duyệt code có AI tham gia, kể cả người mới. Từ kỹ thuật nào cũng có giải thích ngắn.

Ví dụ mã và các con số trong ví dụ là dựng lại để dễ hình dung. Con số "100% độ phủ, 4% điểm đột biến" lấy từ phần tóm tắt của một bài báo (mình chưa đọc toàn văn). Các công cụ được nhắc tên chỉ để làm ví dụ, mình chưa chạy chúng. Các cách làm là gợi ý của mình.

Tóm tắt nhanh#

• Khi AI viết cả code lẫn test, test dễ chỉ xác nhận code, không xác nhận yêu cầu.
• Test xanh chưa đủ. Độ phủ cao cũng chưa đủ: có bộ test phủ 100% mà bắt được rất ít lỗi.
• Câu hỏi đúng không phải "test có xanh không" mà là "nếu code sai, test có đỏ không?"
• Bảy cách: viết từ đặc tả, thấy đỏ trước, tự làm hỏng code, kiểm thử đột biến, theo thuộc tính, bảng giá trị biên, chạy thật.
• Bắt đầu bằng thứ rẻ nhất: làm hỏng code bằng tay và xem test.

Từ khó, nói dễ#