Agentic Engineering (Phần 2): Testing, QA và Playbook: biến Agentic Engineering thành năng lực thật của team

Nội dung của bài viết được tham khảo và truyền cảm hứng cực lớn từ series: Agentic Engineering Patterns của Simon Willison - người đồng sáng tạo ra Django, một trong những web framework bằng ngôn ngữ Python phổ biến nhất hiện nay. Cực kì recommend mọi người nên đọc chi tiết series này:

Giới thiệu: https://simonwillison.net/2026/Feb/23/agentic-engineering-patterns/ Guideline: https://simonwillison.net/guides/agentic-engineering-patterns/

Các bạn có thể đọc lại Agentic Engineering (Phần 1): Từ “vibe coding” đến cách làm phần mềm một cách bài bản để nắm các định nghĩa và principles cơ bản của Agentic Engineering. Phần 2 này sẽ tiếp tục đào sâu vào các phần thật sự cốt lõi, chuyển hóa một cách toàn vẹn năng lực của AI thành năng lực của team.

Nếu thấy bài viết hữu ích, đừng quên click 1 upvote, thêm 1 lượt share, 1 lượt comment ủng hộ tinh thần tác giả 👋

1. Không có feedback thật thì agent chỉ đang đoán

Ở phần 1, chúng ta đã nói về tư duy và workflow khi làm việc với coding agents. Về cơ bản, thứ làm agentic engineering khác với “vibe coding”, đó chính là feedback.

Coding agent mạnh vì nó có thể hành động và quan sát. Nhưng nếu chúng ta không cho nó tín hiệu quan sát tốt, nó lại quay về bản chất cũ: một mô hình sinh text rất tự tin. Mà “tự tin” trong phần mềm thì không có nhiều giá trị nếu không đi kèm bằng chứng.

Trong engineering, feedback thật thường đến từ:

• automated tests
• type checker
• linter
• compiler
• runtime error
• stack trace
• browser screenshot
• console log
• network request
• benchmark
• manual QA evidence
• code review

Một câu “đã sửa” không đủ. Một testcase, fail trước và pass sau có giá trị hơn nhiều. Một screenshot cho thấy UI đúng ở mobile viewport đáng tin hơn câu “giao diện ổn”. Một diff nhỏ dễ review đáng giá hơn một summary dài.

Câu hỏi của phần này vì thế rất cụ thể: làm sao thiết kế feedback loop để agent làm việc mà mình kiểm chứng được, chứ không phải chỉ nghe nó kể?

2. First run the tests

Pattern đầu tiên nghe đơn giản đến mức hơi chán: trước khi sửa, hãy chạy test.

Nhưng càng dùng agent nhiều, chúng ta sẽ càng thấy bước này quan trọng. Nếu agent bắt đầu sửa khi chưa biết baseline, rất dễ rơi vào mớ bòng bong:

• test đã fail từ trước, agent tưởng do nó gây ra.
• environment thiếu dependency, agent sửa code vô ích.
• test suite flaky, agent đuổi theo lỗi không ổn định.
• agent chạy nhầm test rồi báo pass.
• agent sửa quá rộng để làm một test không liên quan pass.

Prompt baseline:

Trước khi sửa code:
1. Chạy test liên quan nhất nếu biết.
2. Nếu chưa biết lệnh test, đọc README/package config/CI config để tìm.
3. Báo baseline: pass, fail, hoặc không chạy được.
4. Không sửa code trước khi báo baseline.

Baseline là ranh giới trách nhiệm. Test đã đỏ trước khi agent động vào code thì đừng bắt diff mới chịu hết tội. Test xanh trước đó và đỏ sau đó thì quay lại soi diff mới.

Trong team, nên lưu lệnh test phổ biến vào docs hoặc instruction file. Agent có thể tự tìm, nhưng nếu team đã biết lệnh chuẩn rồi thì đừng bắt nó đoán lại mỗi lần.

3. Red/green TDD

TDD: Test Driven Development - Một phong cách lập trình mà trong đó bạn đảm bảo mọi đoạn code bạn viết ra đều đi kèm với các bài test tự động để chứng minh đoạn code đó hoạt động đúng.

TDD có ba bước kinh điển: red, green, refactor. Với coding agents, vòng red/green đặc biệt phù hợp vì nó biến một yêu cầu mơ hồ thành một mục tiêu rõ ràng.

"red/green" means: the red phase watches the tests fail, then the green phase confirms that they now pass.

Thay vì prompt:

Fix bug in checkout shipping.

hãy prompt:

Hãy viết regression test fail cho bug phí ship không cập nhật khi đổi địa chỉ sau coupon.
Chạy test để chứng minh test fail đúng lý do.
Sau đó sửa code tối thiểu để test pass.

Điểm quan trọng nhất là fail đúng lý do. Một test "đỏ" vì syntax error, import sai, fixture hỏng hoặc setup thiếu không phải một test tốt trong trường hợp này. Test "đỏ" đúng nghĩa phải chứng minh behavior hiện tại chưa đáp ứng yêu cầu.

Prompt TDD đầy đủ hơn:

Bug: khi user nhập coupon rồi đổi địa chỉ sang vùng khác,
shipping fee không được tính lại.

Hãy làm TDD:
1. Tìm test hiện có liên quan checkout/shipping/coupon.
2. Viết regression test tái hiện bug.
3. Chạy test để chứng minh test fail vì behavior hiện tại sai.
4. Không sửa implementation cho đến khi test fail đúng lý do.
5. Sửa code tối thiểu để test pass.
6. Chạy test liên quan.
7. Báo cáo red/green evidence, file thay đổi và rủi ro còn lại.

TDD giúp agent bớt đoán bừa. Nó cũng giúp reviewer đỡ khổ khi nhìn thấy MR kiểu +1817 - 1512. Khi có test mới rõ ràng, reviewer có thể hỏi rất cụ thể: test này có thật sự bắt bug không? Implementation có làm đúng điều test mô tả không? Edge case nào chưa được cover?

4. Cẩn thận với test do agent viết

Agent viết test rất nhanh. Nhưng test nhanh không có nghĩa là test tốt.

Một số kiểu test do agent viết cần cảnh giác:

• test chỉ kiểm component render, không kiểm behavior.
• assertion quá yếu.
• mock mất phần logic cần kiểm.
• expected được đổi theo actual.
• snapshot quá rộng.
• skip hoặc xfail bị thêm vô lý.
• test trùng với test cũ.
• factory dữ liệu sai domain.

Với bug fix, test mới phải fail nếu bug còn tồn tại. Với feature mới, test phải kiểm tra behavior hoặc contract quan trọng, chứ không dừng ở implementation detail cho có.

Checklist review test do agent viết:

• Tên test có mô tả behavior không?
• Test có fail đúng lý do trước khi sửa không?
• Assertion có đủ cụ thể không?
• Dữ liệu test có dùng fixture/factory đúng không?
• Có mock quá mức không?
• Test có phụ thuộc timing/flaky không?
• Có edge case quan trọng nào thiếu không?
• Test có theo style repo không?

Prompt để agent tự kiểm test:

Trước khi báo test xong, hãy review test mới:
- Nó fail thế nào nếu bug còn tồn tại?
- Assertion chính là gì?
- Fixture có theo pattern repo không?
- Có mock nào che mất behavior thật không?
- Có test cũ nào trùng không?

Có thể để agent tự phê bình output của nó, nhưng đừng vì thế mà bỏ qua phần đọc test. Test yếu là một trong những cách dễ nhất để có cảm giác an toàn giả.

5. Khi test suite chậm hoặc khó chạy

Nhiều repo có test suite lớn, chậm hoặc phụ thuộc môi trường. Nếu cứ bắt agent chạy full suite sau mỗi lần sửa, vòng lặp sẽ rất chậm.

Nên phân lớp test:

Trong vòng lặp sửa, chạy:
pytest tests/checkout/test_shipping.py -k address_change

Sau khi pass, chạy thêm:
pytest tests/checkout

Với frontend:

Chạy test hẹp:
npm test -- shipping-fee.test.ts

Sau khi pass:
npm run lint
npm run typecheck

Nếu agent không chạy được test, nó phải nói rõ:

• lệnh đã thử.
• lỗi chính.
• nguyên nhân khả dĩ.
• kiểm chứng thay thế.
• bước cần con người làm.

Một rule nên đưa vào instruction file:

Nếu không chạy được test, không được nói "tests pass".
Hãy báo "not run" kèm lý do và output lỗi chính.

Một agent báo “not run” tốt hơn nhiều so với agent nói pass mà không có bằng chứng. Nghe kém hào nhoáng hơn, nhưng thật hơn.

6. Agentic manual testing

Không phải mọi thứ đều được automated test cover. UI, layout, loading state, responsive behavior, accessibility, permission flow và những thứ lặt vặt trong browser nhiều khi vẫn cần manual QA.

Agentic manual testing là cách để agent tự làm một phần việc đó bằng browser automation, screenshot, console log và ghi chú.

Ví dụ với web app, agent có thể:

• mở localhost.
• nhập form.
• click qua flow.
• đổi viewport mobile.
• kiểm text xuất hiện.
• kiểm button enabled/disabled.
• đọc console error.
• chụp screenshot.
• ghi lại bước tái hiện.

Prompt:

Sau khi sửa frontend, hãy kiểm tra bằng browser:
1. Mở http://localhost:3000.
2. Đi qua flow checkout.
3. Nhập coupon TEST10.
4. Đổi address sang vùng khác.
5. Xác nhận shipping fee cập nhật.
6. Kiểm console không có error.
7. Chụp screenshot hoặc mô tả bằng chứng.

Nhưng agent không được “nhìn” cho vui. Nó phải kiểm tra theo tiêu chí. Screenshot là bằng chứng, nhưng chỉ hữu ích nếu đi kèm nhận xét có cấu trúc.

7. Ma trận QA nhỏ cho feature có UI

Trước khi manual test, hãy yêu cầu agent tạo một ma trận QA nhỏ. Không cần quá chi tiết, chỉ cần đủ để tránh test mỗi happy path.

Nhóm case	Ví dụ	Kiểm tra bằng
Happy path	coupon hợp lệ, địa chỉ hợp lệ	browser + unit test
Error state	coupon hết hạn	browser/manual
Edge case	đổi địa chỉ sau coupon	regression test
Permission	user chưa login	integration/manual
Responsive	mobile viewport	screenshot
Accessibility	focus order, label	checklist

Prompt:

Trước khi manual QA, hãy tạo ma trận kiểm thử cho flow này.
Giới hạn 8-12 case đáng kiểm nhất.
Phân loại: automated test hiện có, cần test mới, manual/browser check.
Sau đó thực hiện các case browser có thể làm.

Agent rất giỏi làm theo checklist. Vấn đề là checklist phải tồn tại. Nếu không có, nó thường đi đúng một flow đẹp nhất rồi báo pass. Ngoài đời thì user không "ngoan" như vậy.

8. QA evidence

Khi agent làm manual QA, đừng để nó kết thúc bằng một câu “đã kiểm tra”. Hãy bắt nó ghi evidence theo format:

## Manual QA evidence

Environment:
- URL:
- Branch/commit:
- Browser/viewport:

Steps:
1. ...
2. ...

Observed:
- ...

Expected:
- ...

Result:
- Pass/Fail

Screenshots:
- ...

Console/network:
- ...

Ghi chú này giúp PR dễ review hơn. Nó cũng giúp việc debug nếu bug quay lại. Thay vì một câu “đã test thủ công”, reviewer thấy agent đã đi qua bước nào, quan sát gì, kết quả ra sao.

9. QA còn nhiều thứ ngoài test pass

Một thay đổi có thể pass test nhưng vẫn không đủ tốt. Ví dụ:

• error message khó hiểu;
• loading state nhấp nháy;
• mobile layout tràn ngang;
• button disabled sai thời điểm;
• log thiếu thông tin khi lỗi;
• performance giảm;
• accessibility label thiếu;
• empty state bị bỏ quên.

Với user-facing flow, có thể yêu cầu agent kiểm thêm các lớp này:

Ngoài test pass, hãy review thay đổi theo:
- UX edge cases
- loading/error/empty states
- accessibility cơ bản
- responsive layout
- observability/logging
- performance risk

Không phải task nào cũng cần tất cả. Nhưng với user-facing flow, agent có thể giúp nhắc team không bỏ sót những thứ hay bị coi là “để sau”.

10. Linear walkthrough: dùng agent để hiểu code

Agent không chỉ dùng để viết code. Một việc rất đáng làm là bắt nó tạo linear walkthrough: một bài giải thích đi theo luồng chạy thật của code, từ entrypoint đến side effects.

Thay vì ném cho người mới một danh sách file rồi bảo “em đọc đi”, walkthrough trả lời:

• request hoặc user action bắt đầu ở đâu?
• hàm/component nào được gọi tiếp?
• dữ liệu đi qua những lớp nào?
• state nào thay đổi?
• DB/cache/queue/network nào bị tác động?
• test nào bao phủ flow?
• điểm rủi ro nằm ở đâu?

Prompt:

Hãy tạo linear walkthrough cho flow <flow name>.

Yêu cầu:
- Không sửa file.
- Tìm entrypoint từ UI/API/CLI.
- Đi theo flow thực tế qua các file quan trọng.
- Với mỗi bước, ghi file/function liên quan.
- Nêu state/data nào thay đổi.
- Nêu side effect: DB, network, queue, log, cache.
- Nêu test hiện có bao phủ flow.
- Nêu điểm rủi ro hoặc chưa chắc.

Output bằng Markdown, theo thứ tự tuyến tính.

Walkthrough tốt giúp onboarding, review repo lạ và chuẩn bị trước khi sửa code. Nó cũng biến phần agent vừa đọc hiểu được thành tài liệu có thể giữ lại. Đọc code xong rồi để mọi thứ trôi mất trong chat thì hơi phí.

11. Interactive explanations

Một số thứ giải thích bằng chữ rất mệt:

• thuật toán ranking;
• parser;
• scoring formula;
• data transformation;
• state machine;
• layout calculation;
• pipeline xử lý media.

Coding agent có thể tạo artifact tương tác: HTML playground, notebook, chart, simulator, visualizer. Artifact này không nhất thiết là production code. Nhiều khi nó chỉ là công cụ học tập hoặc debug nội bộ. Nhưng nếu nó giúp team hiểu nhanh hơn, vậy là đủ.

Prompt:

Hãy tạo một artifact tương tác để giải thích <concept>.

Mục tiêu người đọc:
- hiểu input
- thấy từng bước xử lý
- thấy output thay đổi khi chỉnh tham số

Ràng buộc:
- chạy local, không cần backend nếu có thể
- code đơn giản, dễ đọc
- có dữ liệu mẫu nhỏ
- không dùng dependency nặng nếu không cần

Sau khi tạo:
- chạy thử
- mô tả cách mở artifact
- ghi các giới hạn của demo

Chỗ đáng giá không nằm ở việc “agent lại viết thêm code”. Chỗ đáng giá là cả team hiểu vấn đề nhanh hơn.

12. Prompt library

Một trong những phần thực tế nhất là lưu các prompt thường dùng. Nghe đơn giản, nhưng nhiều team không làm. Prompt hay nằm trong history của từng người, vài tuần sau không ai tìm lại được.

Với team, prompt library nên được xem như tài sản kỹ thuật. Nó giúp:

• người mới dùng agent đúng hơn;
• team bớt lặp lỗi prompt;
• convention được chuẩn hóa;
• review dễ hơn vì output format quen;
• bài học sau mỗi task được tích lũy.

Các prompt nên có trong library:

• explore feature;
• implement with TDD;
• review diff;
• manual QA browser;
• write linear walkthrough;
• create interactive explanation;
• update docs from diff;
• summarize production log;
• propose tests for bug report.

Cấu trúc gợi ý:

docs/agentic/
  README.md
  prompts/
    explore-feature.md
    implement-with-tdd.md
    review-diff.md
    manual-qa-browser.md
    write-linear-walkthrough.md
    create-interactive-explanation.md
  checklists/
    agent-pr-review.md
    qa-evidence.md
  examples/
    checkout-walkthrough.md

Về cơ bản, điều này gần giống với cách các agent-skills đang được đóng gói, chia sẻ hay thậm chí thương mại hóa hiện nay. Các skill hữu ích giúp tiết kiệm thời gian loay hoay xử lý với agent rất nhiều, chất lượng đầu ra cũng cải thiện đáng kể.

Tuy nhiên, prompt library không nên trở thành nghĩa địa tài liệu. Hãy review định kỳ. Prompt lỗi thời có thể làm agent tệ hơn. Một prompt sai lệnh test còn nguy hiểm hơn không có prompt.

13. Playbook ngắn cho team

Sau prompt library, team nên có một playbook ngắn. Ngắn thôi. Tài liệu 40 trang thường không có ai muốn đọc cả.

Playbook trả lời:

• Khi nào dùng agent?
• Khi nào không dùng?
• Workflow chuẩn là gì?
• Git rules là gì?
• Test baseline chạy thế nào?
• Manual QA evidence format ra sao?
• Khi nào dùng subagent?
• Agent không được làm gì?
• Review checklist là gì?

Mẫu:

# Agentic Engineering Playbook

## Nguyên tắc
- Con người sở hữu output.
- Không merge code chưa review.
- Test/bằng chứng quan trọng hơn lời agent nói.
- Diff nhỏ hơn thì review tốt hơn.

## Workflow chuẩn
1. Explore.
2. Plan.
3. Implement.
4. Verify.
5. Review.
6. Capture lessons.

## Git rules
- Luôn kiểm `git status` trước khi sửa.
- Dùng branch riêng cho task thật.
- Không chạy destructive Git commands nếu chưa xác nhận.

## QA rules
- First run the tests.
- Bug fix nên có regression test nếu khả thi.
- UI change cần manual QA evidence.

## Prompt library
- Link tới `docs/agentic/prompts/`.

Hãy bắt đầu với 2–3 trang và cải thiện sau mỗi task. Playbook hữu ích là playbook có người mở ra xem và sử dụng.

14. Những tình huống nên "đạp phanh"

Agentic engineering không có nghĩa agent làm mọi thứ. Có những chỗ nên stop ngay khi phát hiện bất thường:

• thay đổi quyền truy cập hoặc security-critical logic;
• migration dữ liệu không thể rollback;
• code liên quan thanh toán, pháp lý, y tế hoặc dữ liệu nhạy cảm;
• thao tác production;
• rewrite kiến trúc lớn;
• quyết định sản phẩm mơ hồ;
• tác vụ cần hiểu cam kết với khách hàng.

Trong các trường hợp này, agent vẫn có thể hỗ trợ:

• tạo checklist;
• đọc code và tóm tắt;
• đề xuất test;
• tạo dry-run script;
• viết docs;
• review diff.

Nhưng con người phải giữ quyền quyết định và kiểm chứng ở mức cao hơn. Agent hỗ trợ được nhiều, nhưng không nên là yếu tố quyết định cuối trong các vùng rủi ro cao.

Kết luận

Testing, QA, walkthroughs, artifacts và prompt library là những phần làm agentic engineering bớt giống một trò nghịch tool mới, và giống một năng lực thật của team hơn.

Nếu tóm lại:

• Agent cần feedback thật; không có feedback, nó chỉ đang đoán.
• First run the tests giúp biết baseline.
• Red/green TDD là một trong những pattern mạnh nhất cho coding agents.
• Test do agent viết vẫn cần review nghiêm túc.
• Manual QA bằng browser giúp kiểm user-facing flow.
• QA evidence làm PR đáng tin hơn.
• Linear walkthroughs giúp hiểu codebase và onboarding.
• Interactive explanations biến agent thành công cụ học tập.
• Prompt library và playbook biến kinh nghiệm cá nhân thành tài sản chung.
  

Với agentic engineering, AI không gánh trách nhiệm kỹ thuật thay chúng ta. Nó chỉ làm cho nhiều vòng lặp kỹ thuật tốt trở nên rẻ hơn: viết test, chạy QA, đọc code, tạo walkthrough, cập nhật docs, review diff. Trước đây ta hay bỏ qua vì thiếu thời gian. Bây giờ không có lý do gì để bỏ qua những điều này nữa.

Oke done, xong chỉ tiêu Mayfest năm nay. 2026 là năm của agent bùng nổ, chúng ta cần quan tâm nhiều hơn về cách làm việc với agent, với AI, để biến năng lực của LLM thành năng lực của bản thân chứ không phải lo lắng về 1 tương lai bị thay thế. Không biết năm sau sẽ có thêm những công nghệ nào mới, mình có thể chia sẻ tiếp về những kiến thức gì, hẹn mọi người lại vào Mayfest 2027. See ya 👋