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

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.

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ể.

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.

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.

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ở).

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.

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.

Đó 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.

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.

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.

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.

# 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.

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.

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:

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.