Nửa tiếng làm xong việc, vậy sao cả dự án vẫn tắc nghẽn?

11 giờ đêm, bạn dán mắt vào terminal. Agent vừa viết xong code cho một tính năng, chạy luôn cả test, và khi thông báo hiện lên, bạn liếc nhìn dấu thời gian — nửa tiếng. Cùng một việc đó, tuần trước cả team bạn phải xếp lịch nguyên ba ngày.

Bạn vừa định tắt máy đi ngủ thì điện thoại rung lên một thông báo: danh sách yêu cầu chờ xử lý vẫn còn tám tấm phiếu chưa ai đụng tới, Pull Request từ hôm qua cũng chưa ai xem. Bạn chợt nhận ra một điều — thứ duy nhất trở nên nhanh hơn là công đoạn "viết code", còn mọi công đoạn khác vẫn y nguyên như cũ.

Đây chính xác là vấn đề mà Boris Cherny — người tạo ra Claude Code — và đội ngũ Anthropic muốn chỉ thẳng ra, khi gần đây họ công bố một tài liệu "playbook cho vòng đời phát triển phần mềm (SDLC) AI-native". YouTuber Rob Shocks đã mổ xẻ tài liệu này trên kênh của mình, và câu tóm gọn cốt lõi là: code không còn là nút thắt cổ chai nữa, quy trình của bạn mới là thứ đang cản đường.

Tốc độ "gấp đôi" là có thật — nhưng chỉ xảy ra ở một khâu duy nhất

Vòng đời phát triển phần mềm truyền thống trông như thế này: lập kế hoạch, thiết kế, xây dựng, kiểm thử, triển khai, vận hành — xong một vòng lại quay về điểm xuất phát để đón tính năng tiếp theo, con bug tiếp theo, lần phát hành tiếp theo.

Trước khi Agent xuất hiện, công đoạn "xây dựng" gần như luôn là phần tốn thời gian nhất và cũng tốn kém nhất. Sau khi có Agent, công đoạn này được rút ngắn đáng kể — theo cách nói của Rob Shocks, tương đương nhanh gấp đôi. Vấn đề là, lập kế hoạch, thiết kế, kiểm thử, review, vận hành — không có công đoạn nào nhanh lên theo. Đây chính là câu hỏi mà tài liệu của Anthropic muốn trả lời: Agent đã giúp chúng ta rút ngắn khâu "xây dựng", vậy từng công đoạn còn lại phải được thiết kế lại với Agent như thế nào?

Từ "họp hành thu thập yêu cầu" đến "tranh luận với Agent cho tới khi cả hai cùng đồng ý"

Trước tiên hãy nhìn vào giai đoạn lập kế hoạch. Cách làm truyền thống là ngồi họp, thu thập yêu cầu, viết PRD, tổ chức workshop, rồi đối chiếu hết vòng này đến vòng khác với các bên liên quan.

Trong quy trình mới mà Anthropic mô tả, bước đầu tiên bị đảo ngược: để Agent chủ động hỏi đi hỏi lại bạn trước, hỏi rõ tính năng bạn muốn làm, con bug bạn muốn sửa, hoặc hình hài của cả sản phẩm, để từ đó xây dựng nên bối cảnh (context) đầy đủ. Rob Shocks nhắc đến việc bản thân anh dùng một skill khám phá tên là "Switch Dimension Discovery"; anh cũng nhắc tới "Realm" do Matt Pocock làm ra, hay tính năng "Requirements Discovery" tích hợp sẵn trong Cursor — công cụ có thể khác nhau, nhưng mục đích thì giống nhau: để Agent hỏi liên tục cho tới khi nó thực sự hiểu bạn muốn gì. Việc bạn cần làm là dốc hết kinh nghiệm của mình, hiểu biết về lĩnh vực, và mọi bối cảnh liên quan vào cuộc trò chuyện đó.

Sau đó Agent sẽ chắt lọc những điểm đau (pain point) rút ra từ cuộc trò chuyện đó, tổng hợp lại thành một file — intent.md. Điểm đặc biệt của file này là: con người đọc hiểu được, mà máy móc cũng có thể trực tiếp hành động dựa trên nó (human-readable and machine-actionable).

Trong SDLC truyền thống, một ý tưởng trước tiên sẽ trở thành một user story trong backlog, được tính điểm story point, rồi trải qua vài lần bàn giao mới tới lượt con người bắt tay vào làm. Còn trong thế giới mà Anthropic mô tả, bất kỳ ai đưa ra vấn đề — dù là khách hàng báo lỗi, product manager có ý tưởng tính năng mới, hay kỹ sư muốn ghi lại ý tưởng cải tiến quy trình — đều có thể trực tiếp brainstorm cùng Claude và viết kết quả thành một file intent.md. Cách làm thực tế rất đơn giản: tạo một thư mục tên `intent` trong dự án, và mỗi file intent.md sẽ được lưu ở đó.

Viết xong file này, công việc vẫn chưa kết thúc. Người đưa ra ý định đó (Anthropic gọi là originator) cần quay lại kiểm tra nội dung mà Agent đã viết, xác nhận hai bên hiểu đúng ý nhau — originator không cần phải là chuyên gia trong team, bất kỳ ai cũng có thể đảm nhận vai trò này. Sau đó, những file intent.md rời rạc này sẽ được gom lại thành thứ giống như một backlog — có thể là từng file markdown riêng lẻ, cũng có thể được đưa vào Notion hoặc Linear, do người phụ trách sản phẩm sắp xếp thứ tự ưu tiên, thậm chí có thể giao cho Agent phân loại sơ bộ — gắn nhãn frontend/backend, độ lớn công việc, loại tính năng, mức độ ưu tiên.

intent.md chỉ là bước đầu tiên: một dây chuyền sản xuất mang tên "artifact chain"

Một khi intent.md được chốt, quy trình sẽ tiến sang trạm kế tiếp — spec (đặc tả). Anthropic khuyến nghị: ngay khi intent được xác nhận, dùng một hook hoặc quy trình cố định để tự động kích hoạt việc tạo spec, và đưa ra một prompt mẫu: đọc file intent.md đính kèm, tạo ra một bản đặc tả yêu cầu và thiết kế, áp dụng các skill hiện có để lập kế hoạch và tuân theo quy chuẩn thương hiệu, rồi viết đầy đủ vào spec.md. Ở khâu này không có đáp án chuẩn duy nhất — bạn có thể trực tiếp dùng plan mode tích hợp sẵn trong Cursor, Claude Code hay Codex, hoặc tự tay xây một skill tạo spec mang phong cách riêng của team.

Bước tiếp theo là plan: kỹ sư đưa cả intent lẫn spec vào Agent, cho nó chạy plan mode, và tạo ra một file plan.md. Anthropic khuyến nghị ở bước này nên quay ngược lại chất vấn chính bản kế hoạch đó — hỏi nó "những thay đổi nào có khả năng gây lỗi". Mục tiêu là làm cho plan.md hoàn chỉnh tới mức: dù có giao riêng nó cho một kỹ sư khác, người đó không cần quay lại xem intent hay spec vẫn có thể thực thi trực tiếp theo đó. Điều này đặc biệt quan trọng, vì Rob Shocks đặc biệt nhấn mạnh: toàn bộ quy trình này chưa bao giờ do cùng một Agent làm từ đầu đến cuối — từng giai đoạn sẽ do các Agent khác nhau, thậm chí các đoạn hội thoại (context window) khác nhau tiếp nhận. Vì vậy bạn phải coi intent, spec, plan — những "sản phẩm trung gian" này — như tài liệu bàn giao chính thức, để Agent tiếp theo có thể bắt đầu lại trực tiếp từ chính tài liệu đó, mà không cần mang theo ký ức của cuộc hội thoại trước.

Bản thân plan.md cũng có cách viết cố định: liệt kê những file cần thay đổi, thứ tự công việc hoặc checklist, rủi ro và giới hạn, cùng với "bằng chứng" — một tiêu chuẩn thành công có thể kiểm chứng được, có thể là kiểm tra lint, có thể là kết quả pass/fail của test. Anthropic cũng khuyến nghị lưu lại mọi phiên bản của intent, spec, plan, cùng với việc ai đã thay đổi chúng vào lúc nào — đây là phần mà rất nhiều doanh nghiệp thấy khó triển khai nhất, nhưng lại quan trọng nhất để theo dõi hiệu quả (ví dụ như các chỉ số DORA).

Sau khi bước vào giai đoạn build (xây dựng), Anthropic khuyến nghị dùng "auto mode" để tăng tốc — nhưng Rob Shocks nhắc rằng điều này phụ thuộc rất nhiều vào tổ chức của bạn: hãy chạy thử một thời gian trong môi trường quyền hạn bị siết chặt trước, rồi nới lỏng dần dần, đợi tới khi bạn nắm rõ công cụ nào, gói phụ thuộc bên ngoài nào, nguồn mạng nào nằm trong "phạm vi sử dụng hợp lý" được phép, rồi mới khoá bộ quyền đó vào cấu hình của Cursor hay Claude — lúc đó Agent mới có thể tăng tốc mà không cần bạn phải canh chừng liên tục, đồng thời vẫn kiểm soát được "bán kính nổ" (blast radius). Nhóm cũng khuyến nghị kết hợp với worktree, để nhiều Agent có thể xử lý song song nhiều tác vụ khác nhau; và thứ xâu chuỗi tất cả lại, giữ cho quy trình đi đúng quỹ đạo, chính là hook — ví dụ tự động cập nhật plan sau khi build xong, chặn Agent không cho đụng vào một số thư mục, hoặc ngăn nó cài một gói npm chưa được duyệt. Môi trường thực thi Agent tốt hơn còn có thể tách plan thành nhiều tác vụ độc lập, giao cho nhiều sub-agent xử lý song song.

Đến giai đoạn test (kiểm thử), nguyên tắc của Anthropic là: để Agent làm hết mức có thể trước khi kỹ sư con người hay QA ra tay — viết test, chạy lint, chạy build để xác nhận không có lỗi; nếu team có dùng công cụ như Playwright, thậm chí có thể để Agent thực sự chạy dịch vụ lên, chụp màn hình, ghi lại quá trình thao tác rồi giao lại. Anthropic cũng khuyến nghị mỗi khi skill thay đổi hoặc đổi model thì chạy một vòng evals: trước tiên thu thập khoảng hai mươi trường hợp thực tế từng xử lý cùng với kết quả kỳ vọng, mỗi khi có model mới, quy mô mới, hoặc cách làm việc thay đổi căn bản, thì dùng bộ case này để kiểm tra lại, xác nhận toàn bộ SDLC có bị thụt lùi hay không.

Bước vào giai đoạn deploy (triển khai), Agent sẽ dựa theo kết quả review mà con người đã hoàn tất để mở một Pull Request; Anthropic khuyến nghị để một Claude instance khác review PR này một cách bất đồng bộ (async) theo chính sách và quy chuẩn bảo mật của team — nếu nó không đồng ý, sẽ có thêm một Claude instance khác chuyên xử lý việc qua lại các ý kiến review đó. Về mặt quản trị, bạn có thể thiết kế hook để việc deploy bắt buộc phải qua sự phê duyệt của người cụ thể, hoặc đáp ứng một cổng phát hành (release gate) nào đó mới được thông qua; sau khi PR được duyệt, sẽ có một Agent khác chạy một vòng kiểm tra bảo mật và CI — có thể là các kiểm tra lint và ngưỡng mang tính quyết định, cũng có thể là các Agent kiểu Cursor Bugbot hay kiểm tra bảo mật của Claude giúp bạn bắt lỗi thêm một lần nữa.

Cuối cùng là maintenance (vận hành) — Rob Shocks thẳng thắn nói đây là đoạn "tham vọng nhất" trong toàn bộ tài liệu. Vận hành truyền thống mang tính bị động: bạn đang ăn trưa, bạn đang trực, hoặc có thể là 3 giờ sáng nhận được cảnh báo server sập, một ticket nằm im lìm trong đống backlog chất cao như núi và bị lãng quên hoàn toàn. Còn trong SDLC AI-native, một sự cố bảo mật, một ticket mới, một tin nhắn trên Slack, hay chính lịch trình (schedule) đều có thể đánh thức Claude mà hoàn toàn không cần con người tham gia, để nó chẩn đoán và xử lý một cách bất đồng bộ — và nó sẽ tự sinh ra một file intent.md dựa theo log phát hiện được hoặc tin nhắn nhận được. Trong vận hành thực tế, bạn có thể thiết lập sẵn một số chỉ số cần bảo vệ, một khi trang web sập hoặc lưu lượng API đột ngột tăng vọt, sẽ kích hoạt Agent đi chẩn đoán, viết ra intent, đề xuất phương án — tất cả xảy ra trước khi bạn kịp chạm vào máy tính.

Bước ngoặt: điều thực sự bị thử thách không phải Agent thông minh hay không, mà là bạn đã làm tốt việc quản trị hay chưa

Đọc đến đây, rất dễ hiểu playbook này theo kiểu "chỉ cần nhét Agent vào mọi công đoạn, quy trình sẽ tự động nhanh lên". Nhưng tổng hợp lại, thứ thực sự nâng đỡ cả dây chuyền artifact chain này lại là một loạt những thứ chẳng mấy "hào nhoáng": lưu lại mọi phiên bản của intent, spec, plan và ghi rõ ai đã sửa; chạy thử trong môi trường quyền hạn siết chặt trước rồi mới nới lỏng dần; dùng hook để chặn những thư mục và gói phụ thuộc không nên đụng vào; mỗi lần đổi model đều chạy một vòng đánh giá hồi quy (regression evals); PR phải có review độc lập và ngưỡng bảo mật riêng. Thiếu bất kỳ mảnh nào trong số này, "để Agent tiếp quản toàn bộ SDLC" rất dễ biến thành "để Agent dùng tốc độ nhanh hơn để nhân bản sự hỗn loạn ra nhiều công đoạn hơn".

Bản thân Rob Shocks cũng thừa nhận, quy trình làm việc mà anh dạy trên kênh của mình không hoàn toàn giống với tài liệu này của Anthropic; trên thị trường còn có những trường phái khác như Superpowers, BMAD. Không có đáp án chuẩn nào áp dụng được cho tất cả, điều quan trọng là team phải chọn ra một bộ quy trình và cố gắng không đổi xoành xoạch.

Kể từ hôm nay, thứ bạn cần viết trước không phải là code, mà là một file intent.md

Nếu chỉ được mang đi một thay đổi thói quen duy nhất từ cả quy trình này, có lẽ đó sẽ là: lần tới, trước khi làm một tính năng hay sửa một con bug, hãy để Agent hỏi đi hỏi lại bạn, đổ hết bối cảnh trong đầu bạn ra, viết thành một file intent.md, rồi mới đi tiếp.

Đây cũng chính là lý do vì sao quy trình này lại đặc biệt thú vị với một điều khác mà chúng tôi quan tâm: một khi một tính năng phải đi qua bảy cửa ải intent, spec, plan, build, test, deploy, maintain, mỗi cửa ải đều có thể do một Agent khác nhau, một model khác nhau chạy, và số lần gọi cũng nhiều hơn hẳn so với "một Agent viết từ đầu tới cuối". Sau khi quy trình được chuẩn hoá, mức sử dụng sẽ trở nên có thể dự đoán được, nhưng cũng phân tán hơn — và đây chính xác là điều mà AI Token King muốn giúp các team giải quyết: dù phía sau có nối bao nhiêu Agent, chuyển đổi bao nhiêu model, mỗi lần gọi dùng model nào, tốn bao nhiêu Token, thực tế bị trừ bao nhiêu tiền, đều có thể tra cứu rõ ràng chỉ trong một lần xem.

Câu hỏi thường gặp (FAQ)

Câu 1: intent.md thực chất là gì? Theo lời Rob Shocks thuật lại cách làm của đội ngũ Anthropic, intent.md là một file ý định được hình thành từ việc "originator (người đưa ra vấn đề)" brainstorm cùng Claude rồi tổng hợp lại, với đặc điểm là "con người đọc hiểu được, mà máy móc cũng có thể trực tiếp hành động dựa trên nó". Nó thay thế cho những user story rời rạc trong backlog truyền thống, trở thành điểm khởi đầu cho các sản phẩm tiếp theo như spec, plan.

Câu 2: Ai có thể viết intent.md? Bất kỳ ai. Có thể là khách hàng báo lỗi, product manager muốn thêm tính năng, hay kỹ sư muốn ghi lại ý tưởng cải tiến quy trình — không cần phải là chuyên gia trong team. Sau khi viết xong, Anthropic khuyến nghị chính người đưa ra vấn đề đó quay lại kiểm tra nội dung mà Agent đã tổng hợp, xác nhận hai bên hiểu đúng ý nhau.

Câu 3: intent.md có quan hệ gì với spec.md và plan.md? Ba file này hợp thành thứ mà Rob Shocks gọi là "artifact chain (chuỗi sản phẩm trung gian)": intent.md xác lập trước vấn đề cần giải quyết cùng bối cảnh; một khi intent được chốt, dùng hook hoặc quy trình cố định để kích hoạt tạo ra spec.md (đặc tả yêu cầu và thiết kế); rồi kỹ sư đưa cả intent lẫn spec vào Agent, cho chạy plan mode, tạo ra plan.md (các file cụ thể cần thay đổi, thứ tự, rủi ro và tiêu chuẩn kiểm chứng).

Câu 4: Điều này có nghĩa là toàn bộ quy trình có thể vận hành hoàn toàn không cần con người giám sát? Không phải. Bản ghi âm gốc nhiều lần nhấn mạnh con người vẫn phải giữ vai trò ở những điểm kiểm tra then chốt: originator phải xác nhận intent, kỹ sư phải xác nhận plan mới được thực thi, trước khi deploy cần con người phê duyệt hoặc đáp ứng cổng phát hành. Điều Anthropic nói tới là giảm bớt thời gian nhân lực tiêu tốn ở mỗi công đoạn, chứ không phải loại bỏ hoàn toàn sự phán đoán của con người.

Câu 5: Có nhất định phải sao chép y nguyên phiên bản của Anthropic không? Không cần. Chính Rob Shocks trong video cũng nói rằng quy trình anh thực sự dạy không hoàn toàn giống với tài liệu này của Anthropic, trên thị trường cũng có các trường phái khác như Superpowers, BMAD. Điều quan trọng là team phải chọn ra một bộ và cố gắng chuẩn hoá, chứ không phải mỗi dự án lại đổi một cách chơi khác.

Tuyên bố nguồn tư liệu

Nội dung bài viết này được tổng hợp từ video 《Claude Codes New INTENT.MD, What is It?》 do kênh YouTube Rob Shocks đăng tải vào tháng 9 năm 2026. Nội dung là phần mổ xẻ và thuật lại bằng lời nói của kênh này về "playbook cho vòng đời phát triển phần mềm AI-native" mà Anthropic (đội ngũ nơi Boris Cherny — người tạo ra Claude Code — làm việc) đã công bố, không phải do tác giả bài viết trực tiếp tra cứu tài liệu gốc chính thức của Anthropic rồi trích dẫn nguyên văn; các bước quy trình, tên công cụ trong bài (như Switch Dimension Discovery, Realm, Cursor Requirements Discovery) đều phản ánh trung thực nội dung video, không phải dịch nguyên văn, mà là tổng hợp sau khi tổ chức và diễn giải lại. Nếu team của bạn muốn chính thức áp dụng quy trình tương tự, khuyến nghị tự tra cứu tài liệu gốc chính thức do Anthropic công bố để đối chiếu chi tiết.

Đọc thêm

• AGENTS.md là gì? Một bản README dành cho AI đọc — vì sao Codex, Claude Code, Copilot đều đang dùng

• Agent Skills là gì? Claude dùng thư mục để dạy AI làm việc, giờ đã trở thành chuẩn mở được cả OpenAI, Google hưởng ứng

• Làm sao để AI Agent Skill đáng tin cậy? 5 trọng điểm thực chiến và lỗi thường gặp

• Claude Code tốn quá nhiều Token? 3 mẹo giúp bạn tiết kiệm hơn 50% chi phí

Hành động ngay

Khi một tính năng phải chạy qua bảy cửa ải intent, spec, plan, build, test, deploy, maintain, phía sau có thể là hàng loạt Agent, hàng loạt model thay nhau ra trận, và hoá đơn Token cũng theo đó mà rải rác trong từng lượt gọi. Dùng thử miễn phí AI Token King, trải hết Token tiêu tốn, model được dùng, chi phí thực tế bị trừ của mỗi lượt gọi ra trước mắt — dù SDLC AI-native của bạn có nối bao nhiêu Agent và model, bạn vẫn hiểu rõ tiền đã chảy đi đâu.