Playbook về SDLC AI-native

Claude Code21/08/2026

Các tổ chức đã bắt đầu dùng AI để viết code với tốc độ mà một năm trước không ai nghĩ tới, nhưng các quy trình xoay quanh phần code đó lại không thay đổi kịp nhịp độ đó. Nhiều đội kỹ thuật vẫn giữ nguyên các cổng phê duyệt, các vòng review, các bước bàn giao và chính sách y hệt như trước, khiến năng suất mà các công cụ coding agent như Claude Code mang lại bị kìm hãm lại.

Vòng đời phát triển phần mềm (software development lifecycle - SDLC) là quy trình đưa phần mềm từ ý tưởng đến sản phẩm. Đa số tổ chức vận hành một biến thể nào đó của cùng sáu giai đoạn: lên kế hoạch, thiết kế, xây dựng, kiểm thử, triển khai và bảo trì. Theo cách truyền thống, mỗi giai đoạn là một pha riêng biệt do một vai trò khác nhau phụ trách. Product manager viết yêu cầu, technical architect biến chúng thành thiết kế, kỹ sư xây dựng theo thiết kế đó, đội QA ở các doanh nghiệp chịu quản lý (regulated enterprise) kiểm tra lại, đội release triển khai, và đội vận hành theo dõi những gì đang chạy. Công việc di chuyển giữa các pha thông qua tài liệu, ticket và các thỏa thuận hoàn thành công việc (sign-off).

SDLC truyền thống nặng về quy trình để đảm bảo trách nhiệm giải trình và kiểm soát ở từng bước. Nhưng SDLC truyền thống được thiết kế để tối ưu hiệu quả trong một thời kỳ mà giai đoạn tốn thời gian và chi phí nhất chính là viết và triển khai code - điều đó không còn đúng nữa. Các bản PRD, các nghi thức ước lượng (estimation ritual), và các vòng review bảo mật sản phẩm sinh ra để ép sự đồng thuận trong khoảng thời gian có thể kéo dài hàng tuần, hàng tháng, thậm chí hàng quý của công việc phát triển.

SDLC truyền thống cũng có các cơ chế kiểm soát giả định rằng mọi bước đều do con người thực hiện. Những tổ chức tạo ra giá trị lớn nhất là những tổ chức đã tái thiết kế lại quy trình của mình xoay quanh những gì AI agentic có thể làm ngày nay, đồng thời vẫn đảm bảo con người luôn ở trong vòng lặp giám sát. Trong bài viết này, đội Applied AI của Anthropic chia sẻ một số thực hành tốt nhất mà họ dùng để tích hợp Claude vào từng giai đoạn của SDLC, giúp quá trình phát triển tăng tốc và quy trình vận hành trơn tru hơn - được đúc kết từ việc làm việc trực tiếp với khách hàng.

Khi code không còn là điểm nghẽn nữa, và giai đoạn xây dựng chạy nhanh hơn nhiều so với những gì SDLC truyền thống cho phép, ba điều sau sẽ xảy ra:

• Điểm nghẽn dịch chuyển sang các bước nằm trước và sau giai đoạn xây dựng - chủ yếu là lập kế hoạch, review/kiểm thử, và triển khai - những bước vẫn chạy ở tốc độ con người.
• Các cơ chế kiểm soát không còn khớp với thực tế và trở nên bất khả thi. Review từng dòng code bằng tay là hợp lý khi một con người viết ra nó, nhưng cách đó không thể theo kịp khi agent viết ra phần lớn diff.
• Chi phí quản trị (governance) tăng lên vì các trường hợp ngoại lệ vẫn phải đi qua các cuộc họp và ủy ban chỉ nhóm họp hàng tuần hoặc hàng tháng.

Xây dựng không còn là ràng buộc nữa - các bước chạy ở tốc độ con người xung quanh nó mới là ràng buộc. Các giai đoạn tốc độ con người giữ nguyên độ dài trong khi xây dựng co lại còn vài giờ.

Lấy một điểm nghẽn về bảo mật làm ví dụ. Các đội bảo mật được biên chế theo năng suất con người, nên khi agent nhân số lượng code sinh ra lên nhiều lần, hàng chờ review sẽ phình to hoặc code sẽ được triển khai mà không được review đầy đủ. Một tổ chức chịu quản lý không thể chấp nhận cả hai kết cục đó, vì vậy các bước kiểm tra bảo mật và chính sách của họ buộc phải theo kịp tốc độ của agent.

Để thực sự tận dụng được lợi ích năng suất và đảm bảo an toàn cho AI agentic, vòng đời SDLC truyền thống cần được chuyển đổi ở cùng mức độ như giai đoạn triển khai (implementation) đã trải qua.

SDLC AI-native là gì?

SDLC AI-native là một quy trình được thiết kế lại, kết hợp các mục tiêu kiểm soát cũ với cơ chế thực thi mới. Thay vì một luồng tuyến tính, quy trình trở thành một vòng lặp, và AI được nhúng vào mọi điểm. SDLC AI-native thúc đẩy việc bàn giao và kích hoạt tự động các bước tiếp theo, giúp giải quyết bản chất thủ công và cồng kềnh của việc bàn giao giữa các pha trong SDLC truyền thống.

Những sự dịch chuyển

Bảng dưới đây nêu bật hai đầu của quang phổ giữa SDLC truyền thống và SDLC AI-native được Claude hỗ trợ. Đa số tổ chức nằm ở đâu đó giữa hai cột này.

Giai đoạn	SDLC truyền thống	SDLC AI-native
Plan	Yêu cầu được thu thập qua ủy ban, chắt lọc qua các buổi workshop và chữ ký phê duyệt, viết tay	Claude tổng hợp trực tiếp các điểm đau từ nguồn và ghi lại trong intent.md - vừa dễ đọc với người, vừa máy có thể xử lý được
Design	Spec được viết bởi các analyst, được các designer diễn giải lại	Yêu cầu và thiết kế gộp thành một phiên làm việc duy nhất với agent, được định hướng bởi các chuẩn mã hóa dưới dạng skill, quản lý phiên bản trong git
Build	Test và code được viết tay, tài liệu được viết sau khi phát triển xong	Test và code được AI sinh ra, kiến thức tổ chức được duy trì dưới dạng file CLAUDE.md và skill có thể đọc được bởi máy, có quản lý phiên bản
Test	Các cổng QA ở ranh giới giữa các giai đoạn	Các eval liên tục đan xen suốt quá trình triển khai
Deploy	Con người review từng dòng code, governance diễn ra theo chu kỳ review, thường không nhất quán	Nhiều lớp review agentic, review con người chỉ dành cho code thuộc diện quản lý và quan trọng. Governance được thực thi ngay khi AI hành động, với hook làm cổng phê duyệt
Maintain	Con người theo dõi lỗi trên production	Agent giám sát các bản triển khai đang chạy. Bất kỳ dải kiểm soát (control band) nào bị vi phạm đều được chẩn đoán và ghi lại vào vòng lặp dưới dạng intent.md mới

Sợi chỉ xuyên suốt cột bên phải chính là artifact được commit. Mỗi giai đoạn kết thúc bằng việc ghi một artifact vào hệ thống quản lý phiên bản (bao gồm intent.md, spec.md, plan.md, diff cùng test của nó, PR cùng các phát hiện review, và bản ghi sự cố), và giai đoạn tiếp theo bắt đầu bằng việc đọc artifact đó. Ở các giai đoạn đầu, file .md là artifact chủ đạo vì cả product owner và agent đều có thể đọc và thao tác trên cùng một file. Từ giai đoạn Build trở đi, artifact là code và các bản ghi của nó. Chuỗi commit cũng chính là dấu vết kiểm toán (audit trail): ai yêu cầu gì, agent tạo ra gì, và ai đã phê duyệt.

Con người vẫn chịu trách nhiệm cho mọi quyết định cần đến phán đoán. Trong thế giới SDLC agentic, sự chú ý của con người dịch chuyển theo cùng với các artifact cần được review.

Mẹo

Mỗi giai đoạn commit một artifact mà giai đoạn tiếp theo có thể đọc được. Gộp lại, intent, spec, plan, diff và các phát hiện review chính là dấu vết kiểm toán.

Các “play”

Các “play” (các thực hành cụ thể) là phần cốt lõi của playbook này, được nhóm thành sáu giai đoạn phi tuyến tính (Plan, Design, Build, Test, Deploy, Maintain), cùng nhau bao phủ toàn bộ vòng đời.

Mỗi play bao gồm:

• Điều gì thay đổi;
• Cách bắt đầu;
• Các bước cụ thể để triển khai;
• Các cân nhắc về governance; và
• Cách đo lường xem nó có hiệu quả hay không.

Các bước này mang tính module hóa, và tổ chức có thể chọn ưu tiên chuyển đổi các giai đoạn khác nhau vào những thời điểm khác nhau tùy theo nhu cầu riêng. Mỗi play liệt kê các phụ thuộc của nó dưới mục “Prerequisites” (điều kiện tiên quyết), và đồ thị phụ thuộc minh họa thêm cho điều này.

Một giai đoạn kết thúc bằng việc commit một artifact, và việc commit đó khởi động giai đoạn tiếp theo. Một intent.md được chấp nhận sẽ kích hoạt bước thu thập yêu cầu và thiết kế, một spec.md được phê duyệt sẽ kích hoạt plan mode, một PR được merge sẽ kích hoạt pipeline, và một dải kiểm soát bị vi phạm trên production sẽ viết ra intent.md tiếp theo - và vòng lặp cứ thế tiếp diễn.

Ban đầu, bạn tự tay prompt từng bước, với trạng thái cuối cùng là một vòng lặp trong đó mỗi artifact được chấp nhận sẽ kích hoạt cổng tiếp theo. Sự chú ý của con người tập trung ở các cổng này, review những gì agent đã gắn cờ thay vì phải bắt đầu lại từ đầu mỗi giai đoạn.

Các play được liệt kê theo giai đoạn; các mũi tên cho biết thứ tự nên áp dụng chúng. Hai thứ này không giống nhau. Bắt đầu với bất kỳ play nào không có mũi tên chỉ vào - nó không cần gì trước đó. Với mọi play khác, các mũi tên chỉ vào nó là những play nên áp dụng trước.

Giai đoạn 1 - Plan

Ý tưởng không còn phải chờ ai đó viết chúng ra. Intent được ghi lại một lần, bằng chính lời của người khởi xướng, dưới dạng một artifact có quản lý phiên bản mà giai đoạn sau có thể hành động dựa trên đó.

Ghi lại dưới dạng intent.md

intent.md, thứ khởi động quy trình phát triển phần mềm, có thể đến từ nhiều con đường khác nhau: một người có ý tưởng, một ticket được tạo, hoặc một sự cố được phát hiện qua cảnh báo (xem Giai đoạn 6: Maintenance).

Khi một người có ý tưởng, họ brainstorm cùng Claude và tạo ra một bản proto-spec dạng markdown. Trong SDLC truyền thống, chính người đó phải thuyết phục một thành viên đội sản phẩm viết lại ý tưởng cùng họ hoặc thay họ.

Bản proto-spec do Claude tạo ra dễ đọc với con người, có quản lý phiên bản, và có thể được giai đoạn tiếp theo sử dụng ngay lập tức. Bản proto-spec được lưu dưới dạng intent.md.

Dù intent xuất phát từ một sự kiện kích hoạt hay từ một agent, các bước áp dụng đều như nhau: product owner review và chỉnh sửa intent.md do agent viết trước khi commit nó.

Truyền thống: Một ý tưởng đi qua các mục backlog, user story, story point, và các buổi refinement trước khi ai đó có thể hành động dựa trên nó. Quyền sở hữu chuyển giao ở mỗi lần bàn giao, nên thứ đến tay đội kỹ thuật đã bị biến dạng nhiều bước so với ý định ban đầu của người khởi xướng.

AI-native: Người khởi xướng brainstorm cùng Claude và viết kết quả xuống thành intent.md, một bản proto-spec bằng chính ngôn từ của họ. Artifact này chứa những gì được mong muốn, tại sao, và trong điều kiện ràng buộc nào. Các quy trình lặp lại được mã hóa qua skill.

Điều kiện tiên quyết: Không có.

Hạ tầng cần thiết: Quyền truy cập Claude cho những người không phải kỹ sư (claude.ai hoặc Cowork); một mẫu intent.md đã thống nhất; một nơi lưu trữ chung, có quản lý phiên bản cho intent mà product owner theo dõi. Với một sản phẩm đơn lẻ, nơi đơn giản nhất là một thư mục intent/ trong repo sản phẩm - cách này giữ chuỗi artifact nằm ngay cạnh code được tạo ra từ nó. Một repo intent riêng chỉ đáng đầu tư khi intent trải rộng trên nhiều repo, và trong một monorepo thì đó chỉ là một thư mục.

Việc thiết lập này là công việc một lần cho đội nền tảng (platform) hoặc đội kỹ thuật. Một thành viên kỹ thuật cần dựng “nhà” cho intent và quyết định ai được phép ghi vào đó, vì nhiều người đóng góp sẽ đến từ khắp tổ chức.

Một khi repo tồn tại, những người đóng góp không có kinh nghiệm git không cần dùng git trực tiếp. Thay vào đó, một connector tới hệ thống quản lý phiên bản (ví dụ GitHub) cho phép Claude commit các file markdown thay họ từ claude.ai hoặc Cowork.

Cách thực hiện:

• Người khởi xướng mô tả vấn đề cho Claude bằng chính lời của họ - họ có thể mô tả điều họ không thể làm hôm nay, ai bị ảnh hưởng bởi ý tưởng này, “tốt hơn” trông như thế nào, hoặc điều gì nằm ngoài phạm vi. Không cần ngôn ngữ trang trọng.
• Brainstorm cho đến khi ý tưởng trở nên cụ thể. Claude đặt những câu hỏi mà một analyst sẽ đặt: phạm vi, người dùng, ràng buộc, và thành công trông như thế nào.
• Yêu cầu Claude viết kết quả thành intent.md theo mẫu của tổ chức, có thể được mã hóa thành một skill do một thành viên kỹ thuật thiết lập và một lead ký duyệt. Mẫu này có thể bao gồm vấn đề, kết quả đề xuất, người dùng và hệ thống bị ảnh hưởng, ràng buộc, và các câu hỏi còn bỏ ngỏ.
• Người khởi xướng sửa lại bất kỳ điều gì Claude hiểu sai.
• Commit intent.md vào nơi lưu trữ chung. Tác giả và dấu thời gian được ghi vào bản ghi, và product owner tiếp nhận ý tưởng từ đó.

# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.

## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome
Customers see claim status, next step and expected date in the portal.

## Affected users and systems
Claims handlers, portal team, claims-core API.

## Constraints
No new PII in the portal session. Existing authentication only.

## Open questions
Do third-party loss adjusters need access too?

Cân nhắc về governance: Bằng chứng chính là intent.md đã commit, liệt kê tác giả, dấu thời gian và toàn bộ lịch sử chỉnh sửa. Nó được ghi trong lịch sử git của nơi lưu intent. Product owner phê duyệt, và quyết định chấp nhận hay từ chối để đưa intent sang Giai đoạn 2: Design được ghi lại dưới dạng merge hoặc review đóng lại.

Cách đo lường:

• Chỉ số leading: Thời gian từ cuộc trò chuyện đầu tiên đến khi có một intent.md được commit, đọc từ lịch sử git của nơi lưu intent (ghi lại tác giả và dấu thời gian). Kỳ vọng là giảm từ một chu kỳ thu thập và tinh chỉnh kéo dài nhiều tuần xuống còn vài giờ.
• Chỉ số lagging: Tỷ lệ “sống sót” - tỷ lệ các file intent.md mà product owner chấp nhận đưa sang Giai đoạn 2: Design thay vì đóng lại. Ngoài ra còn có số lần chỉnh sửa intent.md sau khi commit spec.md đầu tiên cho cùng một thay đổi.

Giai đoạn 2 - Design

Yêu cầu và thiết kế gộp lại thành một phiên làm việc duy nhất. Chính sách được áp dụng ngay khi spec đang được viết, chứ không phải bị phát hiện trong một buổi review vài tuần sau đó.

Yêu cầu và thiết kế

Sau khi được product owner phê duyệt, Claude lấy intent.md đã được chấp nhận và tạo ra một bản spec yêu cầu và thiết kế. Việc này được định hướng bởi các skill của tổ chức về thương hiệu, bảo mật, tuân thủ (compliance), và UX.

Product owner review bản spec đó, nhưng không viết nó. Mục tiêu của quy trình này là tạo ra một spec mà đội kỹ thuật có thể lập kế hoạch dựa trên đó, kèm các điểm cần lưu ý đã được gắn cờ.

Công việc front-end là ví dụ rõ ràng nhất. Sau khi intent.md được chấp nhận, product owner phác thảo thiết kế trong Claude Design (beta) từ intent.md, lặp lại trên bản mock, rồi xuất sang Claude Code để xây dựng.

Truyền thống: Yêu cầu và thiết kế là hai pha tách biệt do hai đội khác nhau thực hiện. Analyst hình thức hóa ý tưởng thành yêu cầu, rồi designer diễn giải lại thành thiết kế. Sự tách biệt này tồn tại vì lý do trách nhiệm giải trình, nhưng nó chậm và mất mát thông tin.

AI-native: Cả hai pha diễn ra trong một phiên làm việc được prompt duy nhất. Claude lấy intent.md và tạo ra spec yêu cầu và thiết kế, bị ràng buộc bởi các skill của tổ chức, với các điểm cần lưu ý đã được gắn cờ.

Điều kiện tiên quyết: Một file intent.md, cùng các chính sách thương hiệu, bảo mật, tuân thủ, và UX được viết dưới dạng skill.

Hạ tầng cần thiết: Một product owner có quyền truy cập Claude. Không cần kỹ năng kỹ thuật.

Cách thực hiện:

• Product owner mở một phiên làm việc với các skill của tổ chức được nạp sẵn và đính kèm intent.md.
• Prompt của product owner trỏ vào intent.md, nêu rõ các ràng buộc, và yêu cầu gắn cờ các điểm cần lưu ý. Ban đầu chạy thủ công, sau đó mã hóa thành một slash command cấp tổ chức. Từ đó, biến việc chấp nhận intent.md ở nơi lưu intent thành trigger, với một job không tương tác kích hoạt khi merge, chạy pass với các skill của tổ chức đã nạp, và commit spec.md dưới dạng một pull request (play CI/CD ở Giai đoạn 5: Deploy sẽ nói về phần hạ tầng này). Từ đó trở đi, sự tham gia đầu tiên của product owner là ở bước review.
• Cùng product owner đó review spec so với ý tưởng ban đầu. Spec có giải quyết đúng vấn đề đã nêu không, và các câu hỏi bỏ ngỏ từ intent.md đã được trả lời hay chuyển tiếp chưa?
• Xử lý các điểm được gắn cờ trước tiên, vì đó là những điểm mà một analyst sẽ leo thang lên. Product owner giải quyết từng điểm với chủ chính sách liên quan trước khi đội kỹ thuật thấy spec.
• Commit spec.md cùng với intent.md. Cặp file này ghi lại điều gì đã được yêu cầu và điều gì đã được quyết định.
• Product owner quyết định spec và intent có được đưa sang build hay không, tham khảo ý kiến technical lead với những gì tổ chức xếp vào diện rủi ro cao hơn. Một thành viên con người luôn là người ra quyết định này, và việc chấp nhận spec chính là điều khởi động play plan mode ở Giai đoạn 3: Build.

Prompt mẫu:

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.

Cân nhắc về governance: Thay vì bị phát hiện trong một buổi review vài tuần sau, chính sách hiện hành được đọc và áp dụng ngay khi spec đang được viết. Các skill của tổ chức được áp dụng như ràng buộc lên spec. Spec, prompt tạo ra nó, và phiên bản các skill đang hiệu lực đều được ghi trong hệ thống quản lý phiên bản. Product owner ký duyệt spec, và chuyển các điểm được gắn cờ đến đúng chủ chính sách.

Cách đo lường:

• Chỉ số leading: Thời gian trôi qua giữa commit intent.md và commit spec.md cho cùng một thay đổi (hai dấu thời gian git), so với chu kỳ yêu cầu cộng thiết kế cũ.
• Chỉ số lagging: Việc làm lại yêu cầu sau khi build đã bắt đầu. Đếm các commit spec.md có ngày sau commit plan.md đầu tiên cho cùng một thay đổi - git log sẽ cho ra con số này trực tiếp.

Giai đoạn 3 - Build

Không gì được triển khai mà không có một kế hoạch được chấp nhận. Kiến thức tổ chức trở thành các file mà agent đọc, và các cơ chế bảo vệ chạy dưới dạng code thay vì thói quen.

Claude Code plan mode làm điểm khởi đầu mặc định

Kỹ sư bắt đầu phiên Claude Code ở plan mode, đưa cho Claude bản spec.md đã được phê duyệt từ Giai đoạn 2: Design, và để nó phỏng vấn họ, lặp lại kế hoạch cho đến khi kỹ sư hài lòng.

Truyền thống: Một kỹ sư đọc thiết kế và bắt đầu viết code. Cách thay đổi sẽ được thực hiện, xuống tới file nào và test nào, nằm trong đầu kỹ sư hoặc cùng lắm là một comment trên ticket. Không ai khác có thể review điều đó. Thứ đầu tiên một reviewer nhìn thấy là diff hoàn chỉnh, và lúc đó việc làm lại đã chậm.

AI-native: Công việc bắt đầu với một kế hoạch được viết ra mà Claude tạo trong plan mode, nơi nó có thể đọc codebase mà không thay đổi gì. Kỹ sư sửa lại kế hoạch trước khi code được viết, và phiên bản được phê duyệt được commit thành plan.md để các giai đoạn sau đối chiếu.

Điều kiện tiên quyết: Artifact intent (intent.md hoặc spec.md) nếu có, và file CLAUDE.md sẽ hữu ích.

Hạ tầng cần thiết: Claude Code với quyền truy cập repo.

Cách thực hiện:

• Kỹ sư bắt đầu phiên làm việc ở plan mode với Claude.
• Kỹ sư đưa cho Claude intent.md và spec.md, yêu cầu một kế hoạch triển khai nêu rõ các file sẽ thay đổi, thứ tự công việc, và các test chứng minh nó hoạt động.
• Chất vấn kế hoạch bằng cách hỏi thay đổi này có thể phá vỡ điều gì, bước nào rủi ro nhất, và những lựa chọn khác Claude đã không chọn.
• Lặp lại cho đến khi một kỹ sư chưa từng thấy cuộc trò chuyện này có thể triển khai thay đổi chỉ dựa vào kế hoạch.
• Commit kế hoạch đã phê duyệt thành plan.md. Kế hoạch gia nhập dấu vết kiểm toán, và play review PR (Giai đoạn 5: Deploy) sẽ đối chiếu diff cuối cùng với nó.
• Chấp nhận kế hoạch và để Claude triển khai. Với một kế hoạch chắc chắn, việc triển khai thường chỉ cần một lượt.
• Khi việc triển khai đi chệch khỏi kế hoạch, cập nhật plan.md trong cùng commit. Cân nhắc dùng một hook để đảm bảo đồng bộ giữa hai thứ này.

Ví dụ (plan.md):

# Plan: claims status self-service (from intent.md 2026-06-02)

## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py

## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.

## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.

## Proof
test_status.py covers the four claim states; screenshot matches the
approved mock.

Cân nhắc về governance: Việc review thiết kế diễn ra trước khi bất kỳ dòng code nào được sinh ra, khi việc đổi hướng vẫn chỉ là chỉnh sửa một tài liệu. Plan mode tự thực thi điều này, vì Claude không thể chỉnh sửa file cho đến khi kỹ sư chấp nhận kế hoạch. Kế hoạch và các bản chỉnh sửa của nó được ghi lại cùng với người đã chấp nhận. Các thay đổi thông thường được kỹ sư phê duyệt, và những gì tổ chức xếp vào rủi ro cao hơn sẽ chuyển đến tech lead hoặc kiến trúc sư.

Cách đo lường:

• Chỉ số leading: Tỷ lệ thay đổi được merge ngay từ lượt triển khai đầu tiên, và thời gian từ khi kế hoạch được phê duyệt đến khi PR được merge, lấy từ metadata của PR.
• Chỉ số lagging: Số chu kỳ làm lại trên mỗi thay đổi (cũng từ metadata PR), và tần suất diff đã merge còn khớp với plan.md đã commit.

Claude Code ở auto mode

Claude Code cũng có thể chạy ở auto mode, nơi kỹ sư phê duyệt kế hoạch và, một khi hài lòng và đã lặp lại đủ, Claude áp dụng từng thay đổi mà không cần hỏi ở mỗi chỉnh sửa. Khi các cơ chế bảo vệ từ các play sau trưởng thành hơn (một CLAUDE.md được tinh chỉnh, các skill mã hóa chính sách, các hook chặn hành động không an toàn, và một bộ test mà Claude có thể chạy), auto-accept trở thành mặc định cho công việc thường nhật: một spec.md chặt chẽ, phạm vi ảnh hưởng nhỏ, và code đã được test bao phủ.

Sự dịch chuyển ở đây là từ việc người dùng theo dõi agent thực hiện từng chỉnh sửa và review từng hành động, sang việc review các artifact sau những phiên làm việc tự động dài hơn. Auto-accept mode còn tạo điều kiện cho tính song song giữa các cá nhân và cả đội khi dùng cùng worktree, và là nền tảng để chạy SDLC tự động, khép kín vòng lặp như mô tả ở Giai đoạn 6: Maintenance.

Hệ thống legacy và nguồn sự thật (source of truth)

Các quy trình SDLC hiện có nhiều khả năng đã theo dõi artifact rồi, chỉ là không dưới dạng file markdown. Work item có thể nằm trong Jira, yêu cầu nằm trong một công cụ có khả năng truy vết tuân thủ quy định, thiết kế nằm trong Figma, và các phê duyệt thay đổi thuộc về một change board. Những hệ thống đó khó thay thế vì kiểm toán viên và cơ quan quản lý đã chấp nhận chúng, và các đội khác đang phụ thuộc vào chúng - vì vậy SDLC AI-native phải thích ứng với những gì đang tồn tại.

Khi chuyển sang SDLC AI-native, với mỗi artifact mà quy trình tạo ra, hãy chỉ định một hệ thống làm nguồn sự thật, với mọi nơi khác chỉ giữ bản sao hoặc liên kết đến bản gốc. Có thể cấu hình theo các cách sau, tùy vào từng artifact:

• Repo làm nguồn sự thật. Các artifact markdown là bản ghi chính thức, hệ thống legacy tham chiếu tới file bên trong các commit. Đây có thể là cấu hình sạch sẽ nhất cho các tổ chức do kỹ thuật dẫn dắt, vì mọi bản ghi nằm trong một công cụ với một cơ quan cấp dấu thời gian duy nhất.
• Hệ thống legacy làm nguồn sự thật. Jira, ServiceNow, hoặc công cụ yêu cầu giữ bản ghi chính thức, các artifact markdown chỉ là bản làm việc. Claude đọc bản ghi khi bắt đầu phiên làm việc và ghi kết quả trở lại thông qua một connector MCP trong cùng phiên tạo ra spec hoặc plan.
• Liên kết là mức tối thiểu. Mọi artifact ghi chú ID bản ghi, và mọi bản ghi legacy chứa commit SHA của file markdown. Liên kết là điểm khởi đầu tốt khi chuyển sang SDLC AI-native, chấp nhận việc có hai nguồn sự thật.

Cả hệ thống legacy và hệ thống markdown-first đều có thể cùng tồn tại, miễn là có liên kết giữa hai bên, hoặc một trong hai được tuyên bố là nguồn sự thật.

CLAUDE.md

CLAUDE.md cho Claude bối cảnh mà một người mới gia nhập cần, bao gồm quy ước, lệnh, kiến trúc, và những lỗi mà đội thường gặp nhất. Kiến thức từng nằm trong đầu người ta và trên wiki giờ trở thành một file mà agent đọc vào đầu mỗi phiên làm việc, được cả đội duy trì và cập nhật mỗi khi có lỗi xảy ra.

Điều kiện tiên quyết: Không có.

Hạ tầng cần thiết: Một repo, Claude Code đã cài đặt, và một kỹ sư nắm rõ codebase.

Cách thực hiện:

• Chạy /init trong repo. Claude sẽ tạo một CLAUDE.md khởi đầu dựa trên những gì nó tìm thấy.
• Cắt gọn file được sinh ra xuống còn những gì một người mới cần biết trong ngày đầu tiên. Giữ lại lệnh build, test, lint, các quy ước quan trọng, và những điều Claude thường làm sai.
• Đưa CLAUDE.md vào git ở gốc repo để cả đội dùng chung một phiên bản và mọi thay đổi được review như code.
• Áp dụng một quy tắc hữu ích: khi Claude mắc cùng một lỗi hai lần, chỉnh sửa đó nên được đưa vào CLAUDE.md.
• Giữ file dưới một trang, vì Claude đọc toàn bộ nó vào đầu mỗi phiên và bất cứ gì đã lỗi thời chỉ tốn context vô ích.

Ví dụ (CLAUDE.md):

# Payments service

## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)

## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.

## Architecture
- api/ holds REST controllers, core/ holds domain logic,
  adapters/ talks to external systems.
- Kafka events are defined in schemas/; never edit generated classes.

## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.

Cân nhắc về governance: CLAUDE.md được quản lý phiên bản, nên các chỉ dẫn mà agent làm theo có thể được review và kiểm toán. Quy ước của đội được áp dụng qua file này, các thay đổi lên nó được ghi trong lịch sử git, và code owner phê duyệt các thay đổi đó trong review PR.

Cách đo lường:

• Chỉ số leading: Tần suất Claude lặp lại một lỗi mà CLAUDE.md lẽ ra phải bắt được. Các chỉnh sửa lên CLAUDE.md nên được theo dõi qua lịch sử git.
• Chỉ số lagging: Thời gian đến PR đầu tiên được merge của một thành viên mới trong đội, lấy từ lịch sử PR.

Skill như kiến thức thể chế

Skill là cách một tổ chức biến kiến thức thể chế (institutional knowledge) thành thứ có thể vận hành được. Các chỉ dẫn rõ ràng, có quản lý phiên bản, được áp dụng rộng rãi, và được cập nhật tập trung khi chính sách thay đổi. Nguyên tắc chung: viết một skill cho kiến thức thể chế cần được áp dụng nhất quán; đừng viết skill cho những thành phần thuộc về CLAUDE.md hoặc một prompt.

Điều kiện tiên quyết: Không bắt buộc. Có CLAUDE.md sẽ hữu ích vì nó giữ kiến thức làm việc của agent trong repo, nhưng một skill không phụ thuộc vào đó.

Hạ tầng cần thiết: Một chính sách có chủ sở hữu rõ ràng và một nguồn sự thật được viết ra.

Cách thực hiện:

• Chọn một phần kiến thức đang được áp dụng không nhất quán hiện nay. Có thể là một chuẩn bảo mật, một quy ước thiết kế API, hoặc một quy tắc thương hiệu.
• Viết nó thành một skill - một thư mục chứa SKILL.md với frontmatter nêu rõ khi nào nó kích hoạt và phần nội dung nêu rõ phải làm gì. Một kỹ sư viết skill này từ nguồn sự thật của chủ chính sách, với sự trợ giúp của Claude.
• Đặt skill trong repo tại .claude/skills/<name>/ để nó đi kèm với code, hoặc phân phối trên toàn tổ chức qua một plugin.
• Kiểm tra xem skill có kích hoạt hay không. Yêu cầu Claude thực hiện tác vụ liên quan theo nhiều cách khác nhau và xác nhận skill nạp được mỗi lần.
• Khi chính sách thay đổi, thay đổi skill và để chủ chính sách ký duyệt thay đổi đó.
• Kỹ sư tự động nhận phiên bản mới trong phiên làm việc tiếp theo của họ.

Ví dụ (.claude/skills/secure-api-review/SKILL.md):

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
   no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
   schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
   actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
   appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

Cân nhắc về governance: Một skill là một cơ chế kiểm soát, dù chỉ mang tính khuyến nghị. Nó khiến Claude nhiều khả năng áp dụng chính sách khi code được viết, nhưng không gì ép buộc một phiên làm việc phải tuân thủ nó. Một chính sách bắt buộc phải luôn đúng cần một thứ tất định hơn đứng sau skill, như một hook chặn hành động hoặc một bước review kiểm tra lại chính sách ở PR. Skill khiến vi phạm hiếm gặp, còn hook khiến chúng gần như không thể xảy ra. Các lần skill được gọi được ghi trong session trace, và chủ chính sách review các thay đổi skill như review code.

Cách đo lường:

• Chỉ số leading: Thời gian từ khi chủ chính sách phê duyệt một thay đổi chính sách đến khi skill được cập nhật merge, lấy từ PR trên thư mục skill.
• Chỉ số lagging: Số phát hiện review PR có trích dẫn chính sách này, con số này nên giảm dần về 0 khi skill áp dụng chính sách ngay lúc code được viết. Nếu con số này không giảm, hoặc skill không kích hoạt, hoặc nội dung skill đã lệch khỏi chính sách chính thức.

Hook như cơ chế bảo vệ tại thời điểm build

Skill là một cơ chế kiểm soát mang tính khuyến nghị, còn hook là lớp tất định đứng sau nó. Đa số hành động của Claude là chỉnh sửa file và chạy lệnh shell trong lúc triển khai, nên giai đoạn build là nơi hook thường kích hoạt nhiều nhất.

Hook ở giai đoạn build có thể:

• Chặn chỉnh sửa lên các đường dẫn được bảo vệ như class được sinh tự động hoặc một package bị đóng băng;
• Chạy formatter và linter sau mỗi lần chỉnh sửa file để tránh tích tụ sai lệch;
• Giữ credential không lọt vào diff.

Hãy dùng hook để hỗ trợ bất kỳ skill nào có chính sách cần luôn đúng không ngoại lệ. Một hook chạy trên mỗi hành động khớp với nó, nên các hook ở giai đoạn build nên nhanh và giới hạn phạm vi vào file vừa thay đổi. Các kiểm tra nặng hơn như chạy toàn bộ bộ test nên đặt ở bước commit hoặc PR.

Một hook yêu cầu con người phê duyệt thuộc về các cổng ở Giai đoạn 5: Deploy, vì một lời nhắc phê duyệt trong lúc build sẽ đặt một con người trở lại đường găng (critical path) của mọi phiên làm việc đang chạy song song.

Phiên song song và subagent

Một kỹ sư có thể điều khiển nhiều luồng công việc cùng lúc.

Một phiên song song là một instance Claude Code đầy đủ khác, làm việc trên một tác vụ riêng biệt trong worktree git của riêng nó. Mỗi phiên độc lập không biết gì về các phiên khác, và kỹ sư điều khiển chúng là điểm chung duy nhất giữa chúng.

Một subagent chạy bên trong một phiên duy nhất như một trợ thủ có phạm vi giới hạn, với context window và giới hạn công cụ riêng, phù hợp cho những việc lặp lại trong nhiều tác vụ, ví dụ như xác minh ứng dụng chạy đúng như mong đợi.

Phiên song song làm tăng số tác vụ mà một kỹ sư có thể xử lý cùng lúc, trong khi subagent giữ mỗi phiên tập trung vào tác vụ của riêng nó. Công việc của kỹ sư là điều khiển và review tất cả chúng.

Truyền thống: Một kỹ sư làm một tác vụ tại một thời điểm, dành phần lớn ngày hoặc tuần của họ chờ build, test và reviewer. Chuyển đổi giữa các tác vụ trong lúc chờ là khả thi, nhưng việc chuyển ngữ cảnh (context switch) đủ mệt mỏi nên ít người chọn làm vậy.

AI-native: Một kỹ sư chạy nhiều phiên Claude cùng lúc, mỗi phiên trong worktree riêng cho tác vụ riêng. Các việc lặp lại trở thành subagent với context và giới hạn công cụ riêng. Công việc của kỹ sư chuyển sang điều phối, và cuối cùng là xây dựng và giám sát các vòng lặp.

Điều kiện tiên quyết: CLAUDE.md, vì mọi phiên đều đọc file này. Vòng lặp feedback (Giai đoạn 4: Test) cũng hữu ích ở đây, vì cần ít giám sát hơn từ kỹ sư khi một phiên có thể tự xác minh công việc của mình.

Hạ tầng cần thiết: Một repo git, vì tính cách ly đến từ worktree, và các cấu hình quyền được tinh chỉnh để phiên làm việc không phải chờ lời nhắc phê duyệt cho những lệnh mà tổ chức coi là an toàn.

Cách thực hiện:

• Kỹ sư chia công việc thành các tác vụ chạm vào các file khác nhau, dùng kế hoạch từ play plan mode (Giai đoạn 3: Build) để xác định đâu là công việc độc lập. Các tác vụ chia sẻ file chạy trong một phiên duy nhất, lần lượt.
• Mỗi tác vụ song song có worktree riêng, ví dụ claude --worktree feature-auth ở một terminal và claude --worktree fix-rate-limit ở terminal khác. Một worktree là một checkout riêng trên nhánh riêng, giúp các phiên không va chạm trên cùng file.
• Hai hoặc ba phiên là điểm khởi đầu hợp lý. Giới hạn thực tế là số luồng mà một người có thể review đúng cách, vì vậy chỉ thêm phiên khi việc review vẫn theo kịp.
• Biến các việc lặp lại thành subagent, định nghĩa trong các file markdown ở .claude/agents/, mỗi file có tên, mô tả khi nào dùng, và các công cụ nó được phép chạm vào. Ví dụ: một agent đơn giản hóa code sau khi agent chính hoàn tất, một verifier chạy ứng dụng và kiểm tra hành vi, một researcher khám phá codebase và báo cáo lại mà không làm ngập context chính. Đưa các định nghĩa này vào git để cả đội cùng dùng chung.

Ví dụ (.claude/agents/verifier.md):

---
name: verifier
description: Runs the app and checks the change works before the session
  reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

Cân nhắc về governance: Càng nhiều phiên làm việc đồng nghĩa càng nhiều output, nên các cơ chế kiểm soát phải đến từ cấu hình trong repo. Hook và cài đặt quyền ở đó áp dụng cho mọi phiên, và những gì một phiên làm được ghi lại và gán trách nhiệm cho kỹ sư đã chạy nó.

Cách đo lường:

• Chỉ số leading: Số phiên đồng thời trên mỗi kỹ sư trong khi chất lượng review vẫn được giữ vững, đếm từ dữ liệu xuất OpenTelemetry, và tỷ lệ thời gian trong ngày dành cho việc điều khiển thay vì chờ đợi.
• Chỉ số lagging: Số thay đổi được merge trên mỗi kỹ sư mỗi tuần, đọc cùng với tỷ lệ làm lại xác định qua lịch sử PR.

Cho Claude một vòng lặp feedback

Luôn cho Claude một cách để tự xác minh công việc của nó, dù là test, build, hay so sánh ảnh chụp màn hình. Một phiên làm việc kiểm tra công việc của chính nó và tự sửa lỗi trước khi kỹ sư nhìn thấy.

Vòng lặp feedback không nên bị nhầm với subagent verifier (Giai đoạn 3: Build). Vòng lặp feedback chạy xuyên suốt toàn bộ tác vụ, nhiều lần tùy theo lượng công việc. Còn subagent verifier là một cách để đóng gói bước kiểm tra cuối cùng, bằng cách chạy một context window mới sau khi phiên làm việc tin rằng công việc đã xong - nhờ vậy phán quyết không bị ảnh hưởng bởi các giả định đã tạo ra code đó.

Truyền thống: Tín hiệu cho biết code hoạt động đến muộn - CI vài phút sau, tester vài ngày sau, production vài tuần sau. Với một agent tạo ra code, tín hiệu đến muộn nghĩa là một con người phải kiểm tra toàn bộ output của nó, và người đó trở thành điểm nghẽn.

AI-native: Phiên làm việc được trao một cách để tự kiểm tra công việc của mình trước khi con người thấy nó. Chạy test, chạy build, chụp ảnh màn hình. Claude lặp lại cho đến khi kiểm tra vượt qua, nên thứ đến tay kỹ sư đã vượt qua kiểm tra rồi. Việc thiết lập vòng lặp này thuộc về kỹ sư chạy phiên làm việc.

Điều kiện tiên quyết: Không có.

Hạ tầng cần thiết: Một bộ test và một bản build có thể chạy cục bộ chỉ với một lệnh mỗi loại. Với công việc UI, cách để Claude “nhìn thấy” kết quả là thiết yếu - một công cụ trình duyệt hoặc công cụ chụp màn hình kết nối qua MCP.

Cách thực hiện:

• Nếu việc kiểm tra công việc hôm nay cần một chuỗi lệnh và kiến thức môi trường, gói nó vào một target duy nhất như make test hoặc npm test, thoát với mã khác 0 khi thất bại.
• Trong phần Commands của CLAUDE.md, liệt kê từng lệnh kèm ví dụ output khi mọi thứ ổn.
• Nêu rõ một mục tiêu và làm nó có thể định lượng để Claude tự kiểm tra công việc mà không cần hỏi bạn, ví dụ: “Tất cả test trong test_status.py phải pass”, “ảnh chụp màn hình khớp với bản mock đính kèm”, hoặc “endpoint trả về 200 kèm field mới”.
• Với việc sửa lỗi, hãy viết test thất bại trước. Yêu cầu Claude tái tạo lỗi dưới dạng một test, chạy nó, và xác nhận nó thất bại đúng vì lý do bạn kỳ vọng. Commit test đó. Chỉ sau đó mới yêu cầu Claude làm nó pass mà không sửa test, với hook chặn sửa file test ở bước cuối cùng đảm bảo ràng buộc này. Một test tồn tại trước khi sửa lỗi, mà agent không thể viết lại, chính là bằng chứng lỗi đã được khắc phục.
• Với công việc UI, khép vòng lặp bằng kiểm tra trực quan. Cho Claude một công cụ trình duyệt hoặc chụp màn hình, cho nó bản mock, và để nó lặp lại. Triển khai, chụp màn hình, so sánh, điều chỉnh. Hai hoặc ba vòng là bình thường, và kết quả nên tốt hơn sau mỗi vòng.
• Làm cho việc xác minh trở thành một phần của “hoàn thành”. Chỉ dẫn nằm trong CLAUDE.md. Chạy test trước khi báo cáo một tác vụ hoàn thành, và hiển thị output.
• Cuối cùng, bản thân vòng lặp cũng cần được bảo vệ, vì một agent đang sửa code không được phép làm suy yếu bước kiểm tra trên chính code đó. Một hook chặn chỉnh sửa file test trong lúc sửa lỗi làm được việc này. Cách khác là kiểm tra diff trong review và từ chối bất kỳ thay đổi nào chạm vào test.

Ví dụ (khối xác minh trong CLAUDE.md):

## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

Bốn điều cần lưu ý khi thiết lập cơ chế này: thứ được thực thi là việc xác minh trước khi báo cáo hoàn thành, và việc chặn agent sửa file test trong lúc sửa lỗi, cả hai đều có thể triển khai dưới dạng hook nơi tổ chức muốn đảm bảo chắc chắn; bằng chứng chính là output thực tế của make test, log build, hoặc ảnh so sánh mà Claude đã chạy và dán vào, nên bằng chứng đến từ chính toolchain; nơi ghi lại nằm trong session transcript (được xuất OpenTelemetry chuyển tới hệ thống quan sát của tổ chức) và trong check run của PR, nơi reviewer và người kiểm toán sau này đều thấy được; ai phê duyệt là code owner review PR, người có thể tập trung vào ý định và rủi ro vì bằng chứng máy móc đã sẵn có.

Cách đo lường:

• Chỉ số leading: Tỷ lệ CI pass ngay từ lượt đầu tiên cho các thay đổi do agent viết, hệ thống CI đã hỗ trợ sẵn số liệu này.
• Chỉ số lagging: Thời gian review trên mỗi PR (từ metadata PR), nên giảm khi test bắt được những gì reviewer từng phải bắt, và tỷ lệ thay đổi gây lỗi (change failure rate) từ hệ thống theo dõi sự cố.

Eval liên tục trong CI

Eval là phiên bản AI-native của QA theo cổng giai đoạn (stage-gate QA). Trong thực tế, đó là một bộ test chạy mỗi khi cấu hình của agent thay đổi. Khi một model mới được thay vào hoặc một prompt được viết lại, bộ eval sẽ cho biết agent còn làm việc đúng chuẩn như trước hay không.

Bộ eval nên được coi là một bộ sống. Khi model cải thiện, những case từng phân biệt được tốt/xấu sẽ không còn tác dụng nữa và cần bổ sung case mới nảy sinh từ việc giám sát liên tục.

Tùy vào use case, một số đội có thể muốn chạy eval offline theo lịch cố định thay vì trên mỗi thay đổi. Các bước dưới đây dành cho việc đánh giá liên tục.

Điều kiện tiên quyết: CLAUDE.md và vòng lặp feedback (Giai đoạn 4: Test).

Hạ tầng cần thiết: CI có thể chạy Claude Code không tương tác, và một API key có ngân sách cho các lượt chạy eval.

Cách thực hiện:

• Platform engineer thu thập 20 đến 50 tác vụ thực tế từ công việc gần đây, kèm kết quả kỳ vọng/đã được chấp nhận.
• Viết mỗi tác vụ thành một eval, tức là prompt cộng với các kiểm tra định nghĩa “đạt” (test pass, lint sạch, hành vi không đổi, tuân thủ chính sách).
• Bộ eval chạy không tương tác trong CI theo lịch và trên bất kỳ thay đổi nào lên CLAUDE.md, skill, hoặc hook, vì cấu hình đó định hướng agent và xứng đáng được kiểm thử hồi quy như code.
• Chặn (gate) các thay đổi cấu hình dựa trên kết quả. Một thay đổi skill làm giảm tỷ lệ pass sẽ được review trước khi merge.
• Mỗi sự cố production được thêm thành một eval, do đội sở hữu sự cố đó viết, và ở lại trong bộ eval như một test hồi quy.

Ví dụ (.github/workflows/agent-evals.yml):

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']
  schedule:
    - cron: '0 2 * * *'
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

Cân nhắc về governance: Eval cho QA một cổng theo kịp output của agent. Ngưỡng tỷ lệ pass được thực thi như một merge check, các lượt chạy được ghi lại để so sánh kết quả theo thời gian, và đội sở hữu thay đổi cấu hình phê duyệt nó.

Cách đo lường:

• Chỉ số leading: Tỷ lệ pass của eval theo thời gian, báo cáo bởi bộ eval trên mỗi lượt chạy, và thời gian một sự cố production trở thành một eval cố định.
• Chỉ số lagging: Số lỗi hồi quy bắt được trong CI so với số lỗi hồi quy phát hiện trên production, lấy từ hệ thống theo dõi sự cố.

Giai đoạn 5 - Deploy

Review chạy theo cả hai chiều, và governance được thực thi ngay khi agent hành động. Agent làm mọi thứ cho đến cổng production, và không được phép vượt qua nó.

AI trong vòng lặp review PR

Claude vừa đưa vừa nhận review. Nó review các PR đến theo chính sách của tổ chức, và xử lý các comment review trên chính PR của nó. Điều này cho phép kỹ sư tập trung vào hành vi trong lần review PR của họ, thứ cuối cùng quy về việc phán đoán ý định và rủi ro.

Truyền thống: Năng lực review được lên kế hoạch quanh output của con người. Một PR chờ reviewer đọc toàn bộ, chất lượng review dao động theo tải của reviewer, và tác giả phải thúc giục trong khi backlog phình to.

AI-native: Mọi PR nhận được cùng một bộ pass review giống nhau, với các phát hiện được xếp hạng theo mức độ nghiêm trọng. Sự chú ý của con người dịch chuyển lên một tầng cao hơn: liệu thay đổi có làm đúng những gì kế hoạch dự định, và rủi ro có chấp nhận được không.

Điều kiện tiên quyết: Một CLAUDE.md được cập nhật từ Giai đoạn 3: Build; các skill nếu các pass review thực thi các chính sách đã viết; các subagent đã định nghĩa.

Hạ tầng cần thiết: Một repo có tích hợp Claude, hoặc là dịch vụ Code Review được quản lý (research preview) được admin bật, hoặc claude-code-action chạy trong CI riêng của bạn, với model call qua AWS Bedrock, Google Vertex hoặc Microsoft Foundry khi cần (play CI/CD nói về các lựa chọn triển khai này). Chính sách branch protection yêu cầu phê duyệt từ code owner cũng rất đáng để có.

Cách thực hiện:

• Dịch vụ Code Review được quản lý là cách bắt đầu nhanh nhất. Một admin bật nó và chọn repo. Chạy review trong CI riêng của bạn với claude-code-action khi cần kiểm soát pipeline hoặc muốn các lệnh gọi API đi qua thỏa thuận cloud riêng của tổ chức (play CI/CD nói về phần hạ tầng này).
• Tech lead viết chính sách review thành REVIEW.md ở gốc repo, chia thành các pass mà tổ chức quan tâm: lỗi và sai sót logic; bảo mật và lỗ hổng; tuân thủ so với spec (spec.md từ play yêu cầu), kế hoạch triển khai (plan.md từ play plan mode) và nguyên tắc thiết kế. REVIEW.md cũng định nghĩa thế nào là Important (quan trọng) so với Nit (vặt vãnh), và những gì nên bỏ qua.
• Tech lead thiết lập ngưỡng con người. Các phát hiện không tự phê duyệt hoặc chặn một PR, và branch protection vẫn yêu cầu phê duyệt từ code owner. Một platform engineer muốn chặn merge dựa trên phát hiện có thể đọc số lượng theo mức độ nghiêm trọng mà check run công bố dưới dạng bảng tổng hợp máy đọc được.
• Khi một reviewer hoặc tác giả gắn thẻ @claude trên một comment review, Claude xử lý comment đó và đẩy bản sửa. Thread PR ghi lại cả yêu cầu lẫn thay đổi. Vòng lặp sửa này chạy qua claude-code-action. Trong dịch vụ được quản lý, comment @claude review sẽ yêu cầu một lượt review mới thay vì vậy. Với các PR do Claude mở, hãy đi xa hơn và để Claude “trông nom” PR đến khi merge. Một số đội gói vòng lặp này thành một slash command tùy chỉnh, quét các comment review chưa giải quyết và các check thất bại trên PR, xử lý và đẩy bản sửa, cho đến khi PR xanh và chỉ còn chờ phê duyệt từ code owner.
• Các phát hiện review được đưa trở lại CLAUDE.md. Khi một review gắn cờ một lỗi lần thứ hai, bản sửa được đưa vào CLAUDE.md như một phần của review đó, và vì review đọc CLAUDE.md nên lỗi đó được bắt ngay từ PR tiếp theo. Review cũng gắn cờ khi một thay đổi đã làm CLAUDE.md lỗi thời.
• Mỗi tháng một lần, tech lead tinh chỉnh thiết lập bằng cách đánh giá các phát hiện để cải thiện reviewer, và giới hạn số lượng Nit trong REVIEW.md. Các đường dẫn được sinh tự động và bất cứ gì CI đã thực thi sẵn đều được loại trừ.

Ví dụ (REVIEW.md):

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

Cân nhắc về governance: Nguyên tắc phân tách trách nhiệm được giữ vững, vì agent đã viết code không có cách nào tự phê duyệt nó. Chính sách review trong REVIEW.md được áp dụng cho mọi PR, và các phát hiện, bản sửa, đánh giá, phê duyệt đều được ghi trong lịch sử PR, nên PR chính là bản ghi kiểm toán. Phê duyệt đến từ con người qua branch protection, dựa trên các phát hiện.

Cách đo lường:

• Chỉ số leading: Thời gian đến lượt review đầu tiên, nên giảm xuống còn vài phút, và tỷ lệ comment review được giải quyết mà không cần con người chạm vào nhánh, dữ liệu lưu trực tiếp trên Git.
• Chỉ số lagging: Số lỗi và lỗ hổng bắt được trước khi merge, đối chiếu với những gì lọt ra production, từ lịch sử PR và hệ thống theo dõi sự cố.

Hook như cổng phê duyệt

Giai đoạn build dùng hook như cơ chế bảo vệ, cho phép hoặc chặn hành động mà không cần con người tham gia (Giai đoạn 3: Build). Một hook cũng có thể “hỏi”, tạm dừng hành động cho đến khi một người cụ thể phê duyệt - đây chính là điều mà việc chặn phát hành (release gating) cần.

Play này nằm ở Giai đoạn 5: Deploy vì cổng phát hành là trường hợp rõ ràng nhất, nhưng hook không chỉ dành riêng cho deploy: chúng chạy bất cứ đâu Claude hành động. Ví dụ, hook có thể chặn chỉnh sửa lên migration và hạ tầng khi không có change ticket ở Giai đoạn 3: Build, và ngăn agent sửa file test trong một tác vụ sửa lỗi ở Giai đoạn 4: Test.

Điều kiện tiên quyết: Không có.

Hạ tầng cần thiết: Một danh sách bằng văn bản các phê duyệt mà quy trình thay đổi yêu cầu.

Cách thực hiện:

• Lãnh đạo kỹ thuật, cùng với đội change management và tuân thủ, liệt kê các cổng phê duyệt con người phải giữ lại, như chữ ký change management, ủy quyền phát hành, và chỉnh sửa các đường dẫn được bảo vệ.
• Platform engineer diễn đạt mỗi cổng thành một hook - một script chạy trước khi Claude hành động, có thể cho phép, hỏi, hoặc chặn.
• Hook của đội đặt trong .claude/settings.json trong git, còn các hook không thể thương lượng đặt trong managed settings do platform hoặc IT admin sở hữu, nơi từng kỹ sư không thể tự tắt chúng.
• Một lần chặn nên tự giải thích - khi một hook chặn một hành động, lý do và con đường để được phê duyệt nên xuất hiện trong output của Claude.

Ví dụ (.claude/settings.json):

{
    "hooks": {
      "PreToolUse": [
        {
          "matcher": "Bash",
          "hooks": [
            { "type": "command",
              "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
          ]
        }
      ]
    }
}

Và bản thân cổng đó (.claude/hooks/production-gate.sh):

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2 # exit 2 blocks the action; the message goes to Claude
   fi
fi
exit 0

Cân nhắc về governance: Hook chính là các cổng phê duyệt. Điều kiện của cổng được thực thi mỗi lần, cho mọi người. Các quyết định cho phép và chặn được ghi lại kèm dấu thời gian. Cổng cũng định nghĩa thế nào là “được phê duyệt” - dù đó là một change ticket đã duyệt hay chữ ký của release manager.

Managed settings cho một doanh nghiệp chịu quản lý

Được triển khai bởi đội platform qua MDM hoặc admin console; kỹ sư không thể chỉnh sửa hoặc ghi đè bất kỳ phần nào.

{
  "permissions": {
     "deny": [
        "Read(.env*)", "Read(./secrets/**)",
        "WebFetch", "Bash(curl *)", "Bash(wget *)"
     ],
     "allow": [
        "Bash(git *)", "Bash(make build)",
        "Bash(make test)", "Bash(make lint)"
     ],
     "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
     "enabled": true,
     "failIfUnavailable": true,
     "allowUnsandboxedCommands": false,
     "network": { "allowedDomains": ["git.internal.example.com",
"registry.npmjs.org"] },
     "credentials": {
        "files": [
          { "path": "~/.ssh", "mode": "deny" },
          { "path": "~/.aws/credentials", "mode": "deny" }
        ],
        "envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ]
     }
  },
  "allowManagedHooksOnly": true,
  "disableSideloadFlags": true,
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
     { "source": "github", "repo": "example-corp/approved-plugins" }
  ],
  "requiredMinimumVersion": "2.1.193"
}

Ý nghĩa của từng dòng, xét theo góc độ kiểm soát:

• permissions.deny giữ bí mật (secret) không lọt vào context của agent và chặn truy cập mạng tùy tiện qua các công cụ; permissions.allow phê duyệt trước vòng lặp an toàn nội bộ để danh sách deny không biến thành sự mệt mỏi vì quá nhiều lời nhắc (prompt fatigue).
• disableBypassPermissionsMode cộng với allowManagedPermissionRulesOnly nghĩa là không kỹ sư, file dự án, hay flag dòng lệnh nào có thể nới lỏng các quy tắc.
• sandbox bịt lỗ hổng mà permission không bịt được. Một deny ở cấp công cụ trên WebFetch không ngăn được một lệnh shell truy cập mạng; danh sách domain cho phép ở cấp hệ điều hành chặn hẳn việc truy cập ra ngoài. failIfUnavailable và allowUnsandboxedCommands biến sandbox thành một cổng thực sự: Claude Code từ chối khởi động khi sandbox không khởi tạo được, và một lệnh thất bại trong sandbox không thể được thử lại bên ngoài nó.
• credentials bịt lỗ hổng mà các quy tắc deny còn để hở. permissions.deny quản lý các công cụ file của Claude, nhưng một lệnh shell trong sandbox vẫn có thể đọc ~/.ssh hoặc ~/.aws/credentials theo mặc định; khối này chặn các lượt đọc đó và loại bỏ các secret được nêu tên khỏi môi trường của mọi lệnh chạy trong sandbox.
• allowManagedHooksOnly nghĩa là các cổng phê duyệt từ play này là những hook duy nhất được chạy; không gì cục bộ có thể bổ sung hay thay thế chúng.
• disableSideloadFlags và strictKnownMarketplaces nghĩa là mọi skill, agent, hook và MCP server trên máy của một kỹ sư đều đến qua marketplace plugin đã được tổ chức phê duyệt, chứ không bao giờ từ thư mục home cá nhân.
• allowManagedMcpServersOnly biến bề mặt công cụ của agent thành một allowlist do đội platform sở hữu.
• requiredMinimumVersion từ chối khởi động trên một phiên bản thấp hơn ngưỡng đã duyệt, nên các cơ chế kiểm soát được thực thi bởi một bản build mà tổ chức đã thực sự đánh giá.

Hãy coi đây là điểm khởi đầu để tùy chỉnh, chứ không phải một khuyến nghị để sao chép nguyên xi. Mỗi lệnh deny đánh đổi với năng lực, và mức cân bằng phù hợp phụ thuộc vào phân loại dữ liệu của repo. Tài liệu tham chiếu settings ghi lại mọi key, kể cả các key chỉ dành cho managed settings.

Cách đo lường:

• Chỉ số leading: Thời gian chờ ở mỗi cổng phê duyệt. Mỗi quyết định của hook được ghi vào dữ liệu xuất OpenTelemetry kèm dấu thời gian và phán quyết cho phép/chặn, nên thời gian chờ hiển thị rõ theo từng cổng.
• Chỉ số lagging: Số vi phạm cổng lọt tới production trước và sau khi có hook, từ hệ thống theo dõi sự cố.

Tích hợp CI/CD và triển khai

Chạy Claude Code không tương tác bên trong pipeline CI/CD, sandbox việc thực thi để các agent chạy dài an toàn, đưa việc triển khai ra ngoài qua các tích hợp MCP, và tập dượt các đường rollback trước khi agent thực sự cần đến chúng.

Truyền thống: Pipeline chạy các script tất định, và bất cứ gì cần phán đoán đều phải chờ con người - ví dụ chẩn đoán một test không ổn định (flaky), viết changelog, hoặc tìm hiểu vì sao build hỏng. Triển khai và rollback là các runbook mà con người làm theo dưới áp lực.

AI-native: Claude chạy không tương tác bên trong pipeline cho các bước cần phán đoán, trong một sandbox với credential giới hạn phạm vi. Công cụ triển khai được đưa ra cho agent qua MCP, nên chính luồng làm việc đã viết và test thay đổi cũng có thể triển khai và rollback nó, bên trong các cổng mà tổ chức định nghĩa theo từng môi trường.

Điều kiện tiên quyết: Claude trong vòng lặp review PR và hook như cổng phê duyệt, vì các cổng này phải tồn tại trước khi tự động hóa tăng tốc bất cứ điều gì đi qua chúng.

Hạ tầng cần thiết: Một nền tảng CI đã cài claude-code-action, hoặc bất kỳ runner nào có thể gọi claude -p; quyền truy cập model qua API, hoặc Bedrock, Foundry, Vertex nếu traffic phải ở trong thỏa thuận cloud của tổ chức; các MCP server cho các đích triển khai; một profile sandbox cho các job của agent, không có credential production thường trực.

Cách thực hiện:

• Platform engineer bắt đầu với các bước phán đoán chỉ đọc. Dùng claude -p trong một job pipeline để chẩn đoán build thất bại, tóm tắt một test không ổn định, hoặc soạn changelog.
• Thêm các bước ghi phía sau các cổng đã có cho những việc như sửa lint, cập nhật tài liệu tự sinh, hoặc xử lý comment review qua nhắc @claude. Bất cứ gì agent viết ra đều đi qua một PR nhờ branch protection, và agent không có đường nào để push thẳng lên main.
• Việc thực thi được sandbox hóa. Job của agent chạy trong container theo network policy với token phạm vi ngắn hạn, và không giữ credential production theo mặc định.
• Đưa việc triển khai ra ngoài qua MCP. Deploy, status, và rollback trở thành các công cụ, giới hạn theo từng môi trường, nên quyền triển khai của agent là một allowlist thay vì một script shell kèm credential.
• Phân tầng mức độ tự chủ theo môi trường. Ở development, agent tự do triển khai. Ở production, agent chuẩn bị bản phát hành và release manager ủy quyền, với một hook thực thi cổng production. Staging nằm ở đâu đó giữa.
• Rollback nên là đường đi được tập dượt nhiều nhất trong pipeline - một lệnh duy nhất mà agent có thể chạy và được luyện tập thường xuyên ở staging. Play khép vòng lặp (Giai đoạn 6: Maintenance) sẽ gọi lệnh rollback này khi một dải kiểm soát bị vi phạm, nên nó cần được chứng minh từ trước.

Ví dụ (bước pipeline):

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

Cân nhắc về governance: Nguyên tắc điều hành là agent có thể hành động cho đến cổng production và không được phép vượt qua nó. Các cơ chế kiểm soát sau thực thi nguyên tắc này:

• Branch protection biến bất cứ gì agent viết ra thành một PR, không có đường thẳng nào tới main.
• Hook deploy production chặn bản phát hành cho đến khi một release manager được nêu tên ủy quyền. Mỗi lượt chạy không tương tác hoạt động dưới danh tính riêng của agent, nên log pipeline tách bạch được những gì agent làm với những gì kỹ sư kích hoạt nó đã làm.
• Các tầng quyền theo môi trường quy định agent được làm gì trên đường tới cổng.

Cách đo lường:

• Chỉ số leading: Tỷ lệ các lỗi pipeline được chẩn đoán mà không cần page một con người, lấy từ log pipeline CI/CD.
• Chỉ số lagging: Các chỉ số DORA (DevOps Research and Assessment), mà hệ thống CI và công cụ triển khai đã tự phát ra sẵn.

Giai đoạn 6 - Maintain

Vòng lặp khép lại. Một trigger gọi Claude mà không có con người nào trong đường dẫn kích hoạt, và những gì nó tìm thấy quay trở lại pipeline dưới dạng intent.md.

Bảo trì và khép vòng lặp

Từ đầu đến giờ, chúng ta đã bàn về cách thêm Claude vào từng giai đoạn của SDLC, với mỗi giai đoạn cần một con người khởi động các bước đầu tiên. Nhưng giai đoạn này chuyển trọng tâm sang việc chạy Claude tự động để khép vòng lặp.

Ví dụ, một agent giám sát chạy liên tục có thể, dựa trên một bug ticket được tạo ra, khởi tạo một intent.md, rồi đi qua các pha yêu cầu, kế hoạch, xây dựng, kiểm thử và review. Giai đoạn 6: Maintenance chạy “headless” (không cần giao diện tương tác), với một cổng tin cậy độc lập giữa các giai đoạn - một kiểm tra tất định hoặc một agent review đối nghịch (adversarial) - quyết định output của giai đoạn trước được tiếp tục hay leo thang lên con người.

Truyền thống: Bảo trì là một pha phản ứng (reactive). Mọi ticket hoặc sự cố đều chờ một người hành động và khởi động lại quy trình. Một cảnh báo bắn ra lúc 3 giờ sáng có thể bị bỏ lỡ, một ticket có thể nằm trong backlog cho đến khi ai đó nhặt lên, và các hành động sau hậu kiểm (post-mortem) có thể không bao giờ đến được codebase nếu một đám cháy khác bùng lên trước.

AI-native: Một trigger như một dải kiểm soát bị vi phạm, một ticket, một tin nhắn trên kênh chat, hoặc một lịch trình sẽ gọi Claude mà không có con người nào trong đường dẫn. Claude chẩn đoán, hành động chỉ qua các con đường đã được chặn (gated), và ghi lại những gì nó tìm thấy dưới dạng intent.md, rồi đi qua các giai đoạn đã mô tả ở trên. Con người triage và review công việc đó, không còn phải khởi động nó nữa.

Khép vòng lặp

Một script tất định theo dõi production và gọi Claude khi một dải kiểm soát bị vi phạm. Việc giám sát vi phạm này là một ví dụ hữu ích cho khuôn mẫu của vòng lặp chạy tự động, còn phần Claude Tag (public beta) ở cuối giai đoạn này nói về công việc đến từ các kênh khác.

Điều kiện tiên quyết: intent.md để cho vòng lặp một output có cấu trúc để khởi động lại. Việc review PR do Claude tăng tốc, hook như một ranh giới hành động, và một đường rollback cho CI/CD (được tầng tự chủ cao nhất gọi tới).

Hạ tầng cần thiết: Một kho metric mà script phát hiện có thể truy vấn (Prometheus, API của hệ thống CI, hoặc tương đương), quyền đọc repo, một cách chạy Claude Code không tương tác trong CI, hoặc Agent SDK cho một dịch vụ nhận webhook.

Cách thực hiện:

• Service owner hoặc platform engineer chọn một metric có baseline trung bình trượt ổn định, ví dụ tỷ lệ test CI thất bại, tỷ lệ lỗi 5xx sau khi deploy, hoặc thời gian chu kỳ PR.
• Họ viết script phát hiện, thường là trung bình và độ lệch chuẩn trên một cửa sổ trượt, kèm các quy tắc (Western Electric hoặc tương đương) để dải này bắt được cả trôi dạt chậm lẫn đột biến. Script được quản lý phiên bản và có unit test, việc phát hiện hoàn toàn tất định, không có model nào tham gia.
• Các tầng phản ứng được định nghĩa trong cấu hình có quản lý phiên bản (bands.yaml bên dưới). Ở 1σ script chỉ ghi log, ở 2σ nó gọi Claude ở chế độ chỉ đọc để chẩn đoán, và ở 3σ Claude có thể hành động, nhưng chỉ bằng cách mở một PR vào cổng review hoặc kích hoạt một runbook đã được phê duyệt trước.
• Tầng trigger có thể là một workflow theo lịch trên GitHub hoặc GitLab, một webhook từ hệ thống giám sát hiện có, hoặc một Cron Job trong nội bộ mạng. Claude chạy stateless, hoặc là một bước không tương tác trên CI runner, hoặc là một dịch vụ Agent SDK trong container sandbox (play CI/CD nói về các lựa chọn triển khai và truy cập model). Vì lượt chạy là stateless và không tương tác, một vòng lặp có thể bắt đầu và kết thúc mà không ai khởi động nó.
• Agent viết chẩn đoán của mình thành intent.md theo định dạng Giai đoạn 1: Plan, bao gồm điểm bất thường và bằng chứng của nó, một kết quả đề xuất, các hệ thống bị ảnh hưởng, và các câu hỏi bỏ ngỏ. Từ đó phát hiện này đi qua pipeline như bất cứ thứ gì khác.
• Service owner hoặc kỹ sư trực triage hàng chờ, chuyển các phát hiện liên quan đến sản phẩm cho product owner: sửa ngay, lên lịch, hoặc bỏ qua. Việc bỏ qua giúp tinh chỉnh các dải và giảm nhiễu.
• Khi một bản sửa được triển khai, thêm một eval cho sự cố đó (play eval liên tục) để đảm bảo các vấn đề tương tự được phòng ngừa về sau.

Ví dụ (bands.yaml giám sát tỷ lệ test CI thất bại):

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] }

Cân nhắc về governance: Ranh giới các tầng được thực thi từ cấu hình có quản lý phiên bản, với quyền và managed settings từ chối truy cập production. Các lần gọi, phát hiện, và quyết định triage đều được ghi lại kèm dấu thời gian. Một service owner triage và phê duyệt các phát hiện, các thay đổi kết quả đi qua cổng review PR thông thường, và các runbook mà agent có thể kích hoạt đã được phê duyệt từ trước.

Cách đo lường:

• Chỉ số leading: Thời gian từ khi dải bị vi phạm đến khi có một intent.md trong hàng chờ triage, so với thời gian cũ từ sự cố đến hành động hậu kiểm. Log của script phát hiện có dấu thời gian vi phạm và tầng sự cố.
• Chỉ số lagging: Tỷ lệ phát hiện trở thành bản sửa đã merge (hàng chờ triage so với lịch sử PR thực tế), và số sự cố lặp lại cùng loại, nên giảm dần khi các bản sửa bổ sung case vào bộ eval.

Ví dụ thực tế:

• Khi tỷ lệ test CI thất bại vượt 3σ, agent cách ly test không ổn định hoặc mở một PR revert, và cổng review sẽ quyết định.
• Khi tỷ lệ lỗi 5xx sau deploy vượt 3σ với một lần triển khai nằm trong cửa sổ thời gian, agent kích hoạt pipeline rollback hiện có.
• Khi thời gian chu kỳ PR vi phạm một quy tắc trôi dạt, agent viết một báo cáo cho lãnh đạo kỹ thuật, cho thấy hệ thống này hoạt động tốt cho cả chỉ số quy trình lẫn chỉ số production.

Mẹo

Việc phát hiện luôn tất định. Claude chỉ được gọi khi một dải bị vi phạm, và tầng vi phạm quy định nó được phép làm gì.

Claude trực với Claude Tag

Sự cố cũng có thể đến qua các ứng dụng giao tiếp công sở khác như Slack hoặc Teams. Một sự cố có thể trông như một tin nhắn Slack lúc 10 giờ tối yêu cầu sửa gấp trên kênh sự cố - và giờ đây có thể được xử lý ngay lập tức. Claude Tag (public beta, hiện có trên Slack) biến Claude thành một thành viên của những kênh đó dưới danh tính riêng của nó, nên mỗi sự cố mới đều có một người phản ứng đầu tiên, và bản thân phản ứng đó trở thành một phần của vòng lặp và bộ nhớ cho các sự cố tương lai.

Cuộc trò chuyện và kiến thức thể chế ở lại trong kênh, với bất kỳ ai trong kênh cũng có thể hướng dẫn và hành động cho phản ứng đó. Bất kỳ thành viên đội nào cũng có thể kiểm chứng giả thuyết, khám phá lựa chọn mới, và điều tra theo thời gian thực, với lịch sử kênh bổ sung vào khả năng kiểm toán. Qua quyền truy cập MCP, Claude xác minh metric đã về lại baseline, xác nhận điều đó trong thread, và viết bản hậu kiểm vào một file bài học kinh nghiệm có quản lý phiên bản mà các cuộc điều tra tương lai có thể đọc.

Sự cố không phải là công việc duy nhất mà Claude Tag đảm nhận. Khi được gắn thẻ trên một ticket qua MCP hoặc được hỏi trong kênh, Claude triage công việc theo cùng cách. Một bản sửa nhỏ, phạm vi rõ ràng, đến dưới dạng một PR qua cổng review, còn thứ gì lớn hơn được viết thành intent.md cho Giai đoạn 1: Plan - và từ đó vòng lặp bắt đầu tự nuôi chính nó.

Kênh chính là dấu vết kiểm toán: yêu cầu, chẩn đoán, ủy quyền của con người và bản sửa đều ở lại nơi sự cố được xử lý.

Lời kết

Model và harness đã trở nên tiên tiến hơn nhiều, cho phép các tổ chức không chỉ chuyển đổi cách họ tạo ra code, mà cả toàn bộ vòng đời phát triển phần mềm.

Sự chuyển đổi này vẫn giữ phán đoán của con người ở vị trí trung tâm, đồng thời cân nhắc các yêu cầu governance và quy định của các tổ chức doanh nghiệp lớn.

Bài viết này tổng hợp nhiều thực hành tốt nhất mà đội Applied AI của Anthropic thực sự áp dụng hàng ngày cho khách hàng của họ.

Vòng lặp cứ thế tiếp diễn

Phán đoán của con người luôn đứng trên vòng lặp.

Tài liệu tham khảo

Các tài liệu dưới đây là những gì một đội platform cần để thiết lập các cơ chế kiểm soát nói trên, theo thứ tự gần đúng nên triển khai:

• Thiết lập Claude Code cho tổ chức - bản đồ quyết định dành cho admin, nên bắt đầu từ đây
• Tài liệu tham chiếu Settings và thứ tự ưu tiên, gồm mọi key chỉ dành cho managed settings
• Server-managed settings từ Claude admin console
• Permissions (quyền)
• Sandboxing - cách ly ở cấp hệ điều hành cho filesystem và mạng
• Hooks
• Skills
• Plugin và private marketplace - cách skill và hook được phân phối trên toàn tổ chức
• Managed MCP - kiểm soát tập trung bề mặt công cụ của agent
• Tổng quan triển khai doanh nghiệp - Bedrock, Vertex, Foundry
• Cấu hình mạng doanh nghiệp
• Giám sát (OpenTelemetry)
• Bảng điều khiển analytics
• Compliance API - feed hoạt động doanh nghiệp, truy xuất và xóa chat
• Mô hình bảo mật

Nguồn

Bài viết được lược dịch và biên tập từ bài gốc “The AI-Native SDLC playbook” trên blog chính thức của Claude (Anthropic), đăng ngày 21/08/2026, với đóng góp từ Jim Blackhurst, Will Steuk và Jamal Arif. Các hình ảnh trong bài được lấy lại từ bài gốc.

← Xem tất cả bài viết