# Playbook AI-native SDLC của Anthropic với Claude Code

[Eric Tech](https://homus.dev/speakers/eric-tech) · [Eric Tech](https://homus.dev/orgs/eric-tech)

> Đi qua playbook AI-native SDLC của Anthropic: intent.md, spec.md, plan.md, TDD và feedback loop, eval trong CI, review PR, hook, deploy và metrics.

Topics: Coding Agents, Workflow, Skills, Evals

Canonical: https://homus.dev/talks/claude-code-the-complete-ai-native-sdlc-guide

## 1. Playbook AI-native SDLC của Anthropic

Eric mở đầu bằng một tin mới: Boris Cherny, người đứng đầu Claude Code, cùng team Anthropic vừa phát hành **AI-native SDLC playbook**. SDLC là viết tắt của software development lifecycle, tức vòng đời phát triển phần mềm. Theo cách anh giải thích, vòng đời này thường đi qua một chu trình cố định: bắt đầu bằng planning (lập kế hoạch), rồi designing (thiết kế), building (xây dựng), sau đó testing, deployment, và cuối cùng là maintaining (bảo trì). Sau khi xong phần maintain, chu trình vòng lại về planning và cứ thế đi tiếp với feature kế tiếp hoặc bug kế tiếp.

![Sơ đồ sáu giai đoạn Plan, Design, Build, Test, Deploy, Maintain xếp thành vòng tròn quanh logo Claude](https://homus.dev/photos/6CaQ9ZFuuKI-0012.jpg)

Bên trái là SDLC truyền thống như một chuỗi thẳng từ Plan tới Maintain; bên phải là cùng sáu giai đoạn đó xếp thành một vòng lặp với Claude ở giữa.

Toàn bộ bài viết này, đúng ra là cả một khoá học gồm 14 bài (lesson) trên Claude Academy, chứa mọi thứ mà team Anthropic thực sự đang dùng trong vòng đời này để build ứng dụng bằng Claude Code. Vì thế, trong video, Eric muốn cho thấy chính xác playbook này vận hành thế nào, và cách mỗi người có thể áp dụng nó vào vòng đời phát triển dùng AI của riêng mình, để build ứng dụng theo best practice.

Nói xong phần giới thiệu, anh đi thẳng vào nội dung chính.

## 2. Build co lại, ba khâu còn lại phải siết

Ý tưởng nền của playbook là thế này. Trước khi có AI agent, mọi giai đoạn đều chạy ở tốc độ con người (human speed). Trong SDLC truyền thống, phần tốn thời gian nhất là quá trình build, tức viết code. Giờ có AI, quá trình build đó co lại nhỏ hơn rất nhiều, nên cả chu trình ngắn đi đáng kể.

![Hai hàng khối: Before agents với khối Build rất dài, After agents với khối Build chỉ còn một vạch mỏng](https://homus.dev/photos/6CaQ9ZFuuKI-0123.jpg)

Hình minh hoạ trong playbook: hàng trên "Before agents: every stage runs at human speed" có khối Build chiếm gần nửa chiều dài; hàng dưới "After agents: build runs at agent speed" chỉ còn một vạch Build mỏng, phần dư ra là "cycle time reclaimed". Dưới hàng dưới có ba nhãn: requirements, review, release.

Chính vì vậy, Anthropic gợi ý chúng ta tập trung tinh chỉnh ba khâu: cách thu thập requirement (requirement gathering), quy trình review, tức làm sao review tốt hơn những đoạn code mà AI viết ra, và cách release sản phẩm đã build. Đó là ba chỗ cần đầu tư nhiều hơn trong quy trình mới. Phần còn lại của video đi qua từng giai đoạn để xem Anthropic đề xuất tinh chỉnh chúng ra sao, để cả vòng đời SDLC dùng AI trở nên tốt hơn.

Trên trang giới thiệu của playbook (Lesson 1 of 14, Introduction) còn có một bảng so sánh từng giai đoạn giữa Traditional SDLC và AI-native SDLC. Ở giai đoạn Plan, cách truyền thống là requirement được thu thập bởi một uỷ ban, chắt lọc qua workshop và sign-off, rồi viết tay; còn cách AI-native là Claude tổng hợp các pain point thẳng từ nguồn và ghi lại trong `intent.md`, một file người đọc được và máy hành động được. Ở Design, spec do analyst viết rồi designer đọc, so với requirement và design được nén lại trong một phiên làm việc với agent, được dẫn dắt bởi tiêu chuẩn mã hoá thành skill và version trong Git. Ở Build, test và code viết tay, tài liệu viết sau khi phát triển xong, so với test và code do AI sinh ra, kiến thức được duy trì trong các file `CLAUDE.md` và skill có version.

## 3. Plan: để agent phỏng vấn bạn bằng skill grill-me

Phần đầu tiên là planning stage, xem Anthropic gợi ý làm planning thế nào. Trong SDLC truyền thống, giai đoạn planning thường đòi bạn đi nói chuyện với các stakeholder hoặc khách hàng, project manager, hoặc các team, cố gắng viết ra requirement và gom mọi thứ lại với nhau.

Nhưng trong thế giới mới, với AI SDLC, chính AI có thể đặt câu hỏi và thu thập toàn bộ requirement. Điều này có được nhờ các skill như skill **grill-me** trong bộ skill của Matt Pocock: skill này phỏng vấn bạn, đào sâu bằng câu hỏi qua mọi khía cạnh của kế hoạch, và đi qua từng nhánh của cây quyết định (decision tree), cho tới khi AI đạt được sự hiểu chung (shared understanding) giữa bạn và AI agent.

![Trang mô tả skill grill-me: Relentless interviewing skill that stress-tests plans and designs through systematic questioning](https://homus.dev/photos/6CaQ9ZFuuKI-0223.jpg)

Trang mô tả skill grill-me: "một skill phỏng vấn không ngừng, stress-test kế hoạch và thiết kế bằng cách hỏi có hệ thống". Nó hỏi sâu mọi khía cạnh của kế hoạch theo từng nhánh của cây quyết định cho tới khi hai bên hiểu như nhau, và tự khám phá codebase để trả lời những câu hỏi mà code đã có sẵn câu trả lời.

## 4. intent.md: ghi lại cái "why", mỗi thay đổi một file

Khi AI agent đã thu thập đầy đủ context, bước tiếp theo Anthropic gợi ý là ghi lại cuộc trò chuyện đó, các quyết định và context, vào một file duy nhất là `intent.md`. File này con người đọc được, và máy cũng hành động được dựa trên nó.

Eric muốn làm rõ nhanh hai điểm. Thứ nhất, `intent.md` không giới hạn ở một file cho mỗi project. Bạn có thể có nhiều file `intent.md` khác nhau, mỗi thay đổi (change) một file, cùng nằm trong một thư mục tên là `intent/`.

Thứ hai, file `intent.md` không bắt buộc phải nằm trong repo. Giả sử bạn dùng Jira, hay một hệ thống ticket như Linear, và muốn đặt toàn bộ source of truth ngay trong ticket, bạn cũng làm vậy được. Bạn không cần lưu một file tĩnh trong repo; bạn có thể lưu intent ngay trong hệ thống ticket.

![Hình vẽ tay: intent.md trong thư mục repo bên trái, bảng tracker To Do, In Progress, Done bên phải, chữ Pick one. Not both.](https://homus.dev/photos/6CaQ9ZFuuKI-0256.jpg)

Hai nơi có thể làm source of truth: file `intent.md` trong repo, hoặc ticket trên tracker (cột To Do, In Progress, Done), nối với nhau bằng một link. Dòng chữ dưới cùng: "Pick one. Not both.", chọn một nơi, đừng chọn cả hai.

Anthropic cũng đưa sẵn một template cho `intent.md` để thấy nó trông thế nào. File bắt đầu bằng tiêu đề intent (tên của thay đổi), rồi tới các mục: problem (vấn đề), proposed outcome (kết quả đề xuất), affected users and systems (người dùng và hệ thống bị ảnh hưởng), constraints (ràng buộc) và open questions (câu hỏi còn mở).

![Lesson 2 of 14 Capture as intent.md trên Claude Academy, ví dụ intent claims status self-service](https://homus.dev/photos/6CaQ9ZFuuKI-0319.jpg)

Lesson 2 "Capture as intent.md": ví dụ "Intent: claims status self-service". Problem: khách hàng gọi tổng đài để hỏi hồ sơ bồi thường của họ đang ở đâu, nhân viên mất khoảng một phần ba thời gian cuộc gọi cho những câu hỏi chỉ về trạng thái. Proposed outcome: khách tự xem trạng thái, bước kế và ngày dự kiến trên portal. Affected users and systems: nhân viên xử lý hồ sơ, team portal, claims-core API. Constraints: không thêm PII vào phiên portal, chỉ dùng cơ chế xác thực hiện có.

Eric đã lấy chính template đó và tạo thành một prompt để mọi người chụp màn hình lại và làm theo. Thứ duy nhất cần đổi là nơi bạn muốn lưu file `intent.md`: có thể ở local, có thể trên Jira, hoặc bất kỳ công cụ nào nối qua MCP. Prompt trên màn hình có tiêu đề "Step 3 · paste this to write the file":

```
That is clear enough. Now write the file at
intent/2026-09-13-claims-status-self-service/intent.md.

Line 1 is "# Intent: name of the change".
Line 2 is "Author: my name (my team). Status: draft."

Then five level-two headings, in this order, which cannot change:
Problem, Proposed outcome, Affected users and systems,
Constraints, Open questions.

Write only what I said. Put anything I did not say into
Open questions. Do not invent it.
```

Sau khi kết thúc phiên grill (phỏng vấn), bạn có thể dán thẳng prompt này. Hoặc một cách khác: tạo một skill, hay một slash command dựa trên prompt này, rồi gọi nó ở cuối mỗi phiên grill. Như vậy bạn luôn có một file `intent.md`, hoặc một mục intent nằm ở đâu đó trong project của mình.

## 5. Design: từ intent.md sang spec.md

Có file `intent.md` rồi thì về cơ bản ta đã có một artifact chain (chuỗi artifact). File `intent.md` được chuyển sang giai đoạn design, và giai đoạn design sẽ chuyển mọi thứ có trong intent thành một spec đúng nghĩa.

Có thể bạn đang thắc mắc: `intent.md` và `spec.md` khác nhau ở đâu? Khác biệt rõ ràng là `intent.md` làm rõ cái **why**, tại sao chúng ta làm việc này, còn `spec.md` định nghĩa chính xác cái **what**: các yêu cầu kỹ thuật và hành vi mong đợi. Trên màn hình, Eric còn mở phần AI Overview của một công cụ tìm kiếm để minh hoạ: `intent.md` định nghĩa "why" và mục tiêu kinh doanh của một feature hay project bằng ngôn ngữ thường, còn `spec.md` định nghĩa chính xác "what", tức yêu cầu kỹ thuật và hành vi mong đợi; trong workflow AI-native như Claude Code, chúng là những bước nối tiếp nhau để biến một ý tưởng thành code.

Theo bài viết, Anthropic đưa sẵn một prompt rõ ràng để làm theo, chuyển file intent thành một spec đúng nghĩa. Trên trang, mục "What it looks like" ghi "The prompt:" và bên dưới là:

```
Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.
```

Tuy vậy, bạn không bắt buộc phải theo đúng prompt này để chuyển intent thành spec. Bạn có thể dùng các bộ skill như skill của Matt Pocock hay Superpowers mà kênh đã nói tới, hoặc bất kỳ skill nào tổ chức của bạn có hay bạn thích. Bạn hoàn toàn có thể dùng template hay format riêng của mình để biến bất kỳ intent nào thành một spec đúng nghĩa.

Artifact chain mà Eric mô tả: intent.md trả lời "why", spec.md trả lời "what", và plan.md biến cả hai thành các task mà agent làm theo.

Video có một đoạn ngắn Eric giới thiệu cộng đồng học trên Skool của anh.

## 6. plan.md: biến intent và spec thành task cho agent

Tóm lại tới đây: ta đã nói cách tạo plan, tức brainstorm và tạo file `intent.md`; rồi cách tạo design, tức system spec sẽ ra sao, và đó là `spec.md`. Việc tiếp theo là tạo `plan.md`. File `plan.md` lấy mọi thứ đã bàn trước đó, cả intent lẫn spec, rồi chuyển chúng thành các task hành động được (actionable task) mà AI agent có thể làm theo, hoặc song song, hoặc từng bước một.

Với `plan.md`, không có công thức nào vừa cho mọi người (no one size fits all). Đây là template Anthropic đưa ra cho `plan.md`: có tiêu đề plan; có danh sách các file sẽ thay đổi và nằm ở đâu; có thứ tự công việc (order of work), tức làm gì trước, làm gì sau; rồi tới các rủi ro (risks) cần cân nhắc; và cách chứng minh công việc thực sự xong (proof). Proof có thể là một file test kiểm tra một vùng nhất định của code để cho thấy nó thật sự chạy.

![Lesson 4 of 14 Claude Code plan mode as the default starting point: Order of work, Risks, Proof](https://homus.dev/photos/6CaQ9ZFuuKI-0643.jpg)

Lesson 4 "Claude Code plan mode as the default starting point": ví dụ "Plan: claims status self-service (from intent.md 2026-06-02)". Order of work gồm ba bước: thêm status endpoint sau lớp auth hiện có, dựng panel gọi endpoint đó, nối vào thanh điều hướng của portal. Risks: claims-core API giới hạn 50 request mỗi giây nên panel phải cache. Proof: `test_status.py` phủ bốn trạng thái của hồ sơ, và ảnh chụp màn hình khớp với bản đã duyệt.

Đó là danh sách các mục Anthropic gợi ý cho file `plan.md`. Kèm theo là một prompt Anthropic viết sẵn, để lấy file `intent.md` cùng spec đã thiết kế ở hai giai đoạn trước, áp dụng các skill hiện có, và chuyển tất cả thành một file `plan.md` đúng nghĩa.

Dĩ nhiên, như Eric đã nói, không có công thức chung. Nếu bạn dùng skill to-tickets trong bộ skill của Matt Pocock, hay skill writing-plans của Superpowers, thì thật lòng cả hai về cơ bản đều lấy spec và chuyển mọi thứ thành một plan đúng nghĩa. Eric mở file SKILL.md của writing-plans trên GitHub: skill này có cách viết implementation plan riêng. Nó có goal, architecture, tech stack, chỗ để spec, các global constraint, rồi tới cấu trúc task. Mỗi task ghi rõ file nào thay đổi, có interface, có dạng checkbox cho việc làm trước và làm sau. Phần "Bite-Sized Task Granularity" ghi rằng mỗi bước là một hành động dài 2 tới 5 phút, ví dụ "Write the failing test", "Run it to make sure it fails", "Implement the minimal code to make the test pass", "Run the tests and make sure they pass", "Commit".

Vậy nên nếu bạn đã đang dùng những framework spec-driven development kiểu này để chuyển spec thành plan cho AI agent làm theo, thì cứ tiếp tục dùng. Luôn cố dùng thứ bạn đã có và đang chạy tốt, rồi lấy playbook này làm tài liệu tham chiếu để xem có gì có thể bổ sung vào SDLC của mình cho tốt hơn. Đừng lấy nguyên mọi thứ trong video; hãy dùng thứ đang chạy, rồi xem những chỗ nào có thể tinh chỉnh trong chu trình phát triển hiện tại của bạn.

Đó là phần build: về cơ bản là chuyển mọi thứ thành một plan đầy đủ trước khi thật sự implement.

## 7. Viết test trước và cho Claude một feedback loop

Một điều cần lưu ý: trước khi thật sự implement, ta cũng cần tập trung viết test trước, tức test-driven development (TDD). Đó cũng là điều Anthropic khuyến nghị. Về testing, Anthropic muốn bạn dùng TDD: trước khi viết code, ta tạo test trước, tạo phần kiểm tra trước rồi mới tạo thứ cần kiểm tra.

Mục tiêu là tạo ra một feedback loop: khi test còn fail, ta để AI sửa đoạn code nó viết cho tới khi test pass. Bài viết ghi chính xác thế này, trong Lesson 8 "Give Claude a feedback loop": luôn cho Claude một cách để tự kiểm tra công việc của mình, dù là test hay một lần build, có thể là lint hoặc một ảnh chụp màn hình để so sánh khác biệt. Phiên làm việc tự kiểm tra công việc của nó và tự sửa lỗi của chính nó trước khi chúng ta phải nhìn thấy.

![Sơ đồ It checks its own work: Write code, Run the checks gồm tests lint build, Pass?, Fix it, Commit + push](https://homus.dev/photos/6CaQ9ZFuuKI-0854.jpg)

Agent viết code, chạy các bước kiểm (tests, lint, build), hỏi "Pass?"; nếu NO thì quay về "Fix it" rồi viết lại, nếu YES thì "Commit + push".

Nói cách khác, ta muốn giao nhiều hơn cho automated testing trước khi một người phải bước vào để kiểm tra thay đổi. Về TDD, kênh đã review nhiều skill. Ví dụ skill tdd của Matt Pocock, nơi bạn chuyển sang tập trung viết test trước rồi mới implement. Rồi skill test-driven-development của Superpowers cũng làm việc rất, rất tương tự. Còn đây là phiên bản TDD của Anthropic.

Trong phiên bản của Anthropic có ba thứ: test, lint và build. Build ở đây không phải là viết code, mà là thật sự chạy build để xem nó có compile được không. Đó là ba thứ được kiểm: phần mềm có chạy được không, có output nào vô nghĩa không, và function hay chương trình có hành xử đúng không. Mục `CLAUDE.md` trên màn hình, tiêu đề "teach it what 'green' means":

```
## Verifying your work

- make test   (finishes with "0 failed")
- make lint   (finishes with no output)
- make build  (finishes with "Build succeeded")

Do not report done until all three are green.
```

Câu cuối nói rõ: không báo done cho tới khi cả ba đều xanh. Nghĩa là đừng cố báo xong khi ba bước đó chưa pass. Bên dưới, hình còn ghi chú rằng phần trong ngoặc mới là nửa quan trọng: một lệnh không có output mong đợi sẽ để agent tự quyết định thế nào là "pass".

## 8. Ba lớp testing framework

Video có một đoạn quảng cáo cho Certificate Program in Agentic AI của Johns Hopkins University, tổ chức cùng Great Learning.

Đã thấy test quan trọng, việc tiếp theo là chọn đúng công cụ cho testing. Eric chia nó thành ba lớp.

Lớp đầu tiên là functional test, tức viết unit test. Framework dùng ở đây là **Jest** hoặc **Vitest**, và thứ được test là từng function. Giả sử có một function làm một phép tính, gọi một endpoint, hay lấy một ít thông tin; ta có test function đó được không? Được, bằng Jest hoặc Vitest.

Khi test cho function đã phủ đủ, lớp tiếp theo là component testing. Nếu ứng dụng có UI, có thể là mobile app hoặc web app, ta dùng **React Testing Library** để test các UI component. UI component có thể là button, form, hay bất cứ thứ gì người dùng nhìn thấy và tương tác được. Quan hệ ở đây là: một component có thể gọi nhiều function, nhưng function không gọi UI component. Đó là quan hệ phụ thuộc giữa chúng. Vì vậy ta muốn tạo test cho function trước, tức những lớp dưới cùng, rồi mới viết test cho UI component.

![Danh sách Testing Frameworks: Jest/Vitest Functional, React Testing Library UI Component, Cypress/Playwright Entire Pages](https://homus.dev/photos/6CaQ9ZFuuKI-1343.jpg)

Ba lớp test Eric viết lên bảng: Jest/Vitest cho functional test, React Testing Library cho UI component, Cypress/Playwright cho toàn bộ các trang.

Khi UI component đã được phủ, phần cuối là end-to-end testing, mô phỏng toàn bộ luồng của người dùng. Giả sử có nhiều trang và ta muốn người dùng đi qua chúng; ta dùng công cụ như **Cypress** hoặc **Playwright**, cả hai đều là framework end-to-end đúng nghĩa để mô phỏng và test toàn bộ các trang. Đó là ba lớp testing framework cho ứng dụng.

## 9. Continuous evals trong CI

Khi đã dựng xong testing, thứ tiếp theo là continuous evals trong continuous integration (Lesson 9, "Continuous evals in CI"). Cách làm là để AI dựng các evaluation (eval) dựa trên những skill ta chạy, ví dụ skill TDD vừa chạy. Ta muốn chắc chắn có eval cho skill đó.

Tại sao? Vì khi bạn đổi sang model khác, có thể xảy ra chuyện model mới bỏ sót những thứ vốn đang chạy tốt. Ta muốn biết chính xác cái gì đang chạy. Vì vậy Anthropic khuyến nghị lấy 20 tới 50 task thật mà Claude đã hoàn thành, và dùng chúng làm eval cho model mới. Task đó có thể là một pull request, hoặc một GitHub issue bạn đang theo dõi. Để AI đọc qua chúng, dùng skill như skill-creator để dựng eval, rồi chạy test để xem model mới mà ta chuyển sang có làm được việc đó không.

![Hình An eval is a task you already solved: ngăn kéo 20 to 50 real tasks, chạy lại sau khi đổi model hoặc rules, kết quả 18 of 20 passed](https://homus.dev/photos/6CaQ9ZFuuKI-1405.jpg)

"An eval is a task you already solved": một ngăn kéo chứa 20 tới 50 task thật (add a status endpoint, fix the tenant cache key, rename a config flag), chạy lại chúng sau khi đổi model hoặc đổi rules, rồi hỏi "Same tasks. Did anything get worse?"; ví dụ trên hình ra 18 trên 20 task pass, tức 90%.

Anthropic viết rằng chỉ cần viết một task thành một eval: prompt cộng với output mong đợi. Bài cũng gợi ý chạy nó trong continuous integration, tức chạy trong CI/CD pipeline của bạn. Bên dưới là một GitHub workflow tên là agent eval, để đánh giá xem skill còn chạy được không. Phần job trên màn hình:

```
jobs:
evals:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install -g @anthropic-ai/claude-code
- name: Run eval suite
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
for eval in evals/*.json; do
claude -p "$(jq -r '.prompt' $eval)" \
--allowedTools "Read,Edit,Bash(make test)" \
--output-format json > result.json
./evals/check.sh "$eval" result.json
done
```

Một CI/CD pipeline chạy kiểm tra skill như vậy giúp chắc chắn mọi thứ vẫn chạy và được đánh giá. Giả sử bạn đổi model, hoặc đổi rules: skill còn chạy với thay đổi đó không? Một workflow như thế này có sẵn những bước kiểm tra đó. Với mỗi eval, nó chạy Claude ở chế độ headless với các tool được phép (allowed tools), rồi xem model mới hay thay đổi rules có còn thoả mãn các eval đã đặt hay không. Trên màn hình, workflow này còn được hẹn chạy theo lịch bằng cron.

## 10. AI review pull request theo REVIEW.md

Có eval rồi, việc tiếp theo Anthropic khuyến nghị là để AI review pull request (Lesson 10, "AI in the PR review loop"). Điều Eric rút ra là bạn có thể để Claude review theo một file `REVIEW.md` duy nhất, ghi chính xác những gì cần lọc ra. File đó có review instructions: chạy ba lượt (pass) và gắn mỗi phát hiện với lượt của nó, gồm bug, security và compliance; định nghĩa thế nào là "Important"; giới hạn số nit (cap the nits); và mục "Do not report", ví dụ đừng báo các file sinh tự động nằm dưới `src/gen/`, hay những file tạm cũng có thể bỏ qua.

![Lesson 10 of 14 AI in the PR review loop, nội dung REVIEW.md](https://homus.dev/photos/6CaQ9ZFuuKI-1603.jpg)

Ví dụ `REVIEW.md` trong Lesson 10 "AI in the PR review loop" trên Claude Academy.

```
# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.
```

Bài viết còn nói rằng có thể để một người, ví dụ tech lead của team, viết file `REVIEW.md`, ghi chính xác SOP (quy trình chuẩn) để review, tức review pull request thế nào. Rồi để AI theo file đó mà review những gì nó viết ra; đó có thể coi là best practice.

Khuyến nghị riêng của Eric: để AI lấy các pull request trong quá khứ, những cái mà thường có người để lại comment. Cho nó đọc những comment đó, xem có những pattern chung nào lặp lại, rồi thêm chúng vào `REVIEW.md`. Như vậy mỗi lần nó xem một pull request mới, đó chính là những thứ nó sẽ nhìn vào trước khi gắn tag hay viết comment.

## 11. Hooks: guardrail trước khi tới production

Dĩ nhiên chỉ có quy trình review là chưa đủ. Ta còn có thể thêm hook để duyệt mọi thứ trước khi AI merge pull request vào production thật. Về cơ bản, hook cho phép thế này: mỗi khi AI định làm một việc, ví dụ chạm vào database production, hoặc merge một pull request, ta có thể thêm hook để chặn những hành động nhất định mà AI đang định làm.

![Hình vẽ hooks: update plan, block file edit, run linter, block credentials; robot bị bức tường blocked exit 2 chặn trước production](https://homus.dev/photos/6CaQ9ZFuuKI-1715.jpg)

Bốn việc hook có thể làm: update plan, block file edit, run linter, block credentials. Robot agent bị một bức tường chặn trước "production", trên tường ghi "blocked: exit 2" kèm hướng dẫn "here is how to get approved".

Ví dụ khi nó đang sửa: reviewer agent gửi một số comment cho builder agent, và builder agent sẽ sửa vài chỗ trong pull request. Lúc đó ta có thể dùng hook để chạy linter, đảm bảo mọi thứ được format gọn gàng và test đều pass. Hoặc nếu nó định ghi credential nào đó vào codebase, hook sẽ chặn lại. Hoặc có những file mà ta không muốn AI sửa, ta cũng chặn được bằng hook. Ta dùng hook để thêm guardrail, đảm bảo không có bug hay dữ liệu nhạy cảm nào bị đẩy lên production. Đó là điều Anthropic khuyến nghị.

## 12. CI/CD: trước và sau khi deploy

Giả sử AI đã review xong pull request và cuối cùng merge nó. Thứ tiếp theo là CI/CD integration và deployment (Lesson 12): thay đổi mà nó viết sẽ được deploy lên production ra sao. Về cơ bản có hai phần: trước deployment và sau deployment.

Trước deployment: khi build fail, workflow gọi Claude ở chế độ headless (`claude -p`). Claude đọc toàn bộ build log, tìm nguyên nhân fail, rồi tạo một pull request và gửi đi review. Pull request đó đi qua đúng quy trình vừa nói ở trên để chắc chắn bản sửa build là đúng, rồi feature được release lên production. Trên màn hình, phần tóm tắt còn ghi rằng khi deploy, Claude gọi một deployment tool qua MCP, một hook chặn việc deploy lên production cho tới khi có người cho phép, và Claude chạy với quyền hạn chế trong một môi trường tách biệt.

Sau deployment: ta để Claude gọi một status tool. Status tool có thể là Datadog, Sentry, hay bất kỳ công cụ theo dõi hiệu năng hệ thống nào bạn dùng. Claude nhìn vào đó xem có gì hỏng nghiêm trọng không. Nếu hệ thống hỏng sau khi release feature này, ta có thể cho Claude một tool để rollback feature, rồi để nó tìm root cause, tạo pull request, và đi lại quy trình deployment một lần nữa. Đó là điều Anthropic khuyến nghị cho quy trình deployment với Claude.

Hai nửa của giai đoạn deploy theo cách Eric kể: trước deploy Claude sửa build fail bằng một pull request đi qua review; sau deploy Claude theo dõi qua status tool và có thể rollback rồi mở PR sửa nguyên nhân gốc.

## 13. Maintain: đóng vòng lặp bằng metrics

Tới đây ta đã đi qua planning, designing, building, testing và cuối cùng là deployment. Bước cuối là phần maintain: làm sao để Claude bảo trì hệ thống sau khi feature đã release? Điều này dẫn tới bài học cuối cùng: closing the loop on metrics, đóng vòng lặp bằng metrics (Lesson 13).

Metrics ở đây, như đã nói, có thể là Sentry, Datadog, hay bất kỳ công cụ theo dõi hiệu năng hệ thống nào bạn có, và ta có thể làm định kỳ. Ví dụ, bài viết tạo một file YAML mẫu nhìn vào 30 ngày gần nhất. Bạn có thể để Claude đọc log, nhìn vào mọi thứ để xem có gì cải thiện được trong hệ thống. Có thể là một lỗi cứ lặp lại, một câu query dữ liệu cứ chậm dần, hoặc người dùng đang rời bỏ (churn) ứng dụng. Ví dụ trên trang là một file `bands.yaml` theo dõi tỉ lệ test fail trong CI:

![Lesson 13 of 14 Closing the loop on metrics, ví dụ bands.yaml](https://homus.dev/photos/6CaQ9ZFuuKI-2003.jpg)

Lesson 13 "Closing the loop on metrics": file `bands.yaml` theo dõi metric `ci_test_failure_rate` với baseline 30 ngày trượt, kèm ba mức phản ứng theo độ lệch.

```
metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
1sigma: { action: log }
2sigma: { action: diagnose,
tools: "Read,Grep,Bash(gh run view *)" }
3sigma: { action: propose,
routes: [pull_request, runbook:rollback-deploy] }
```

Dù vấn đề là gì, ta có thể để Claude vòng ngược lại bằng cách tạo một file `intent.md` mới, rồi để Claude đi lại toàn bộ quy trình, toàn bộ SDLC này một lần nữa để cải thiện ứng dụng. Vòng lặp khép lại đúng như hình ở đầu video: từ Maintain quay về Plan.

Đó là toàn bộ video về SDLC của Anthropic. Eric kết luận rằng ta có thể dùng AI để tự động hoá gần như mọi giai đoạn của vòng đời phát triển phần mềm. Anh mời mọi người like video và subscribe nếu muốn xem thêm nội dung như vậy, rồi hẹn gặp lại ở video sau.

## Nguồn và liên kết

- Tên gốc: Claude Code: The Complete AI-Native SDLC Guide
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=6CaQ9ZFuuKI](https://www.youtube.com/watch?v=6CaQ9ZFuuKI)

- Kênh YouTube Eric Tech (Eric Tech): [youtube.com/channel/UCOXRjenlq9PmlTqd_JhAbMQ](https://www.youtube.com/channel/UCOXRjenlq9PmlTqd_JhAbMQ)

- The AI-native SDLC playbook, khoá 14 bài trên Claude Academy (intent.md, plan mode, feedback loop, continuous evals, PR review, CI/CD, closing the loop on metrics): [academy.claude.com/courses/ai-native-sdlc-playbook](https://academy.claude.com/courses/ai-native-sdlc-playbook/introduction)

- Bộ skill của Matt Pocock (grill-me, to-tickets, tdd): [github.com/mattpocock/skills](https://github.com/mattpocock/skills)

- Superpowers, bộ skill có writing-plans và test-driven-development: [github.com/obra/superpowers](https://github.com/obra/superpowers)

- Tài liệu hooks của Claude Code: [code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks)

- Testing framework được nhắc tới: [Jest](https://jestjs.io), [Vitest](https://vitest.dev), [React Testing Library](https://testing-library.com/docs/react-testing-library/intro/), [Cypress](https://www.cypress.io), [Playwright](https://playwright.dev)

Nguồn: https://homus.dev/talks/claude-code-the-complete-ai-native-sdlc-guide · cập nhật 2026-10-15