Top 1% dùng Claude Code khác thế nào

1. Plan mode không còn là lời khuyên số một

Simon mở đầu bằng một nhận xét: suốt một năm qua, gần như mọi lời khuyên về Claude Code đều nói cùng một điều, đó là hãy bắt đầu trong plan mode. Ngay cả người tạo ra Claude Code cũng nói vậy. Hồi tháng Một, Boris Cherny kể rằng phần lớn session của anh đều bắt đầu ở plan mode. Nhưng hai tuần trước video này, trên Hacker News, chính Boris lại nói plan mode không còn hữu ích nữa.

Hai phát biểu đó cách nhau chín tháng, và theo Simon, trong chín tháng ấy cách Boris cùng nhóm 1% người dùng giỏi nhất làm việc với Claude đã thay đổi hoàn toàn. Vì vậy video đưa ra mười điều nhóm top 1% đang làm, để bạn có được setup tốt nhất và thôi tốn thời gian cho những lời khuyên đã cũ. Điều đầu tiên chính là thứ họ dùng thay cho plan mode.

Để hiểu vì sao, hãy nhìn lại plan mode thực sự đã làm gì. Nó chưa bao giờ thay đổi khả năng của Claude. Nó chỉ chèn thêm một reminder vào mỗi tin nhắn prompt, đại ý "bạn đang ở plan mode, xin đừng bắt đầu code vội". Trong bình luận trên Hacker News, Boris kể anh nghĩ ra ý tưởng này vào một tối Chủ nhật muộn, vì đã quá mệt với việc lần nào cũng phải nhờ Claude lên kế hoạch trước khi bắt tay vào build. Simon thấy khá buồn cười khi một ý tưởng nảy ra trong một tối Chủ nhật cuối cùng lại trở thành một phần gắn chặt với cách tất cả chúng ta làm việc với Claude Code mỗi ngày.

Ở thời điểm đó, plan mode thực sự rất có ích, vì các model cũ hơn, hãy nghĩ lại Sonnet 4.6 và những bản Opus đời đầu, đều có xu hướng lao thẳng vào làm việc ngay. Đó là một giới hạn của model. Nhưng với các model mới hơn, Boris đơn giản là thôi dùng nó, vì giờ đây việc lên kế hoạch diễn ra ngay trong lúc model làm việc.

2. Thay plan mode bằng một brief ba dòng: task, guardrails, done

Vậy Boris làm gì thay thế? Như anh giải thích ở YC Startup School, anh mô tả task, mô tả những guardrails bao quanh task đó, mô tả thế nào là xong, tức definition of done, rồi để model tự tìm cách làm.

Simon lấy ví dụ một bản báo cáo khách hàng hằng tuần (weekly client report). Brief cho việc đó có thể chỉ gồm ba dòng. Task: làm báo cáo tuần này từ file export của CRM. Guardrails: không sửa template đã đặt sẵn, và không email cho ai cả. Definition of done: mọi con số khớp với file export.

Thay vì đọc một bản kế hoạch trước khi task bắt đầu, giờ bạn kiểm tra những gì nó đã làm sau khi xong. Đó là lời khuyên hiện tại. Với những thay đổi lớn hơn, Boris nhờ Claude vẽ một diagram, hoặc thậm chí làm một demo tương tác về những gì nó đã thay đổi. Và ngay hôm trước video, Claude cũng công bố khả năng tích hợp sẵn để tạo live dashboard và animated explainer, nên lấy output tương tác kiểu này giờ còn dễ hơn.

Cách làm Simon đề xuất: khi task xong, bạn yêu cầu nó một trang hình ảnh (one-page visual) mô tả nó đã làm gì và nó đã giả định những gì trong lúc làm task đó.

Từ đây Simon bắt đầu dựng một bức tranh sẽ lớn dần qua cả video. Bên trái là bạn, và thứ duy nhất bạn viết là brief. Claude làm phần việc, và thứ quay về là output cùng trang explainer một trang kia. Nghĩa là giờ bạn chủ yếu kiểm tra kết quả, chứ không còn lên kế hoạch chi tiết từ trước nhiều như trước nữa.

3. Đừng chỉnh effort level, cũng đừng viết "think hard"

Brief đã nói rõ phải làm gì và guardrails là gì. Nhưng nhiều người vẫn cố điều khiển mức Claude suy nghĩ về task. Lời khuyên mới là bỏ qua chuyện đó hoàn toàn.

Có thể bạn còn nhớ năm ngoái người ta bảo phải viết những cụm như "think", "think hard", "think harder" hay "ultrathink", và mỗi cụm cho Claude một thinking budget lớn hơn. Nhưng giờ Claude Code đọc "think hard" đơn giản như một phần của prompt, như những chữ bình thường. Trên màn hình, Simon đặt cạnh nhau hai thời điểm: "Last year" với thinking budget, và "Now" với dòng "think hard about why the test fails" chỉ còn là chữ trong prompt.

Việc chỉnh mức suy nghĩ đã thành một setting riêng mà bạn có thể nhận ra là effort level. Mỗi model có một mức được khuyến nghị. Opus 5.5 được khuyến nghị ở medium, và Anthropic nói rằng ở mức medium, nó ngang hoặc vượt Opus 5 ở mức high cho công việc coding và knowledge work. Nói đơn giản, mặc định bây giờ đã làm thay điều bạn từng tự làm, với ít bước hơn và ít token hơn.

Vì vậy với đa số task, lời khuyên là cứ để nguyên, coi như bớt một thứ phải nghĩ, giữ ở effort level được khuyến nghị. Simon nói anh sẽ không ngạc nhiên nếu trong tương lai gần, Anthropic bỏ hẳn setting này và để nó tự chạy ở phía sau. Tóm lại, ý chính ở đây là: hãy tin vào setup của Claude.

4. Cho Claude một cách để tự kiểm chứng công việc

Hai điều tiếp theo nói về cách Claude chứng minh rằng nó đã thực sự làm xong task bạn giao. Có một ý từ bài đăng tháng Một của Boris vẫn còn cực kỳ đúng: cho Claude một cách để verify công việc của nó sẽ tăng chất lượng kết quả cuối lên 2 đến 3 lần. Và docs của Anthropic giờ đặt điều này làm mẹo đầu tiên.

Đúng như docs viết, một check mà Claude tự chạy được chính là khác biệt giữa một session bạn phải ngồi canh và một session bạn có thể rời đi. Nếu bạn muốn những setup tự động hơn, chỉ cần giám sát, thì điều này sẽ là then chốt.

Để làm được, bạn sẽ không bảo Claude "double check" công việc trong prompt. Hướng dẫn cho Opus 5 nói rằng model đã tự kiểm tra công việc của nó mà không cần được nhắc. Vì vậy dòng đó về cơ bản chỉ thêm chi phí mà không cải thiện kết quả. Việc bạn cần làm là luôn đưa cho nó những tiêu chí có thể trả về pass hoặc fail.

5. Biến definition of done thành một check chạy được

Ví dụ, Simon yêu cầu Claude viết một script nhỏ tên check-report, dùng để đối chiếu với tiêu chí done của ví dụ weekly client report ở trên. Script về cơ bản kiểm tra mọi con số so với file export, và kiểm tra mọi section trong template đều đã được điền. Đó là tất cả những gì script check-report xác nhận.

Các dòng đầu của script hiện trên màn hình như sau:

#!/usr/bin/env python3
# every figure matches the export
report = load("weekly-report")
export = load("crm-export.csv")
for name, value in report.figures():

Cách nó vận hành: giả sử ở lần chạy đầu, check fail ở một con số không khớp với export. Claude sẽ quay lại sửa chỗ đó, chạy lại check, và khi pass thì mới cho bạn xem output. Nghĩa là với tư cách người dùng, bạn chỉ đọc bằng chứng, chứ không phải tự mình chạy kiểm tra trên output.

Cách làm cụ thể là nhìn lại definition of done, chính cái dòng trong brief của bạn, và biến nó thành một check mà Claude chạy được. Simon lưu ý check không nhất thiết phải là một script code chạy được. Nó có thể là tài liệu brand voice mà Claude dùng để đối chiếu bản nháp. Nhưng check càng deterministic thì càng bắt được nhiều lỗi.

Như vậy, giờ Claude tự làm nhiều phần việc hơn và chỉ trao cho bạn bằng chứng rằng nó đã làm đúng. Nhưng điều này chỉ có ích khi Claude có cách tiếp tục làm cho tới khi pass các check. Nếu không, bạn sẽ ngồi đó gõ "continue" liên tục để nó sửa phần bằng chứng của chính nó.

6. /goal và cái bẫy của judge Haiku

Điều đó dẫn tới /goal. Về cơ bản, /goal gõ "continue" thay cho bạn. Simon hy vọng trong tương lai mình thậm chí không cần viết lệnh này nữa, mà chỉ cần đặt tiêu chí là muốn nó tiếp tục cho tới khi đã xác nhận được definition of done, đơn giản vậy thôi. Nhưng hiện tại, chúng ta dùng /goal.

Có một điểm cần biết về cách nó hoạt động hôm nay, và Simon nói điểm này rất quan trọng. Sau mỗi turn, một model nhỏ riêng biệt như Haiku đọc goal của bạn và quyết định xem điều kiện đã đạt chưa. Nếu chưa, Claude sẽ chạy thêm một turn nữa để cố đạt goal đó.

Cái bẫy là judge, tức agent Haiku kia, không tự chạy lệnh hay đọc file. Nó chỉ được đưa cuộc chat bạn đã gửi và output của Claude. Vì vậy nếu goal được định nghĩa kém, ví dụ definition of done chỉ là "báo cáo đã xong", thì về cơ bản nó sẽ kết thúc quá sớm. Nó sẽ nghĩ đã đạt tiêu chí done trong khi thực tế chưa.

7. Viết một goal tốt: một end state, cách chứng minh, giới hạn turn

Vì thế goal phải thật rõ ràng và tường minh, để nó chính là cái check bạn đã tạo ở phần trước. Anthropic nói một goal tốt có một end state duy nhất, nói cách chứng minh end state đó, và nói những gì không được thay đổi. Nó cũng nên có một giới hạn số turn để không chạy mãi.

Goal của Simon cho ví dụ này rất đơn giản. Anh đọc nó như sau: /goal, script check-report pass và bạn cho tôi xem output; template không bị thay đổi; hoặc dừng sau 15 turn. Bây giờ Claude có thể đi tiếp trên con đường kiểm chứng đó, lặp đi lặp lại cho tới khi đạt tiêu chí của bạn, và tiêu chí đó được viết sẵn trong script check-report.

Như vậy bạn giải phóng thêm thời gian vì không phải giám sát nó. Bạn không phải ngồi gõ "continue" mỗi lần, mà chỉ cần xác nhận output đúng như mong đợi. Giờ các agent đang chạy vòng lặp quanh bạn, và việc tiếp theo là bảo đảm những chỉ dẫn nền trong CLAUDE.md không đi ngược lời khuyên mới nhất của Anthropic.

Trước khi sang phần đó, video có một đoạn quảng cáo cho khoá học sắp ra của chính Simon về việc giao bớt công việc hằng ngày cho Claude, Codex và các công cụ AI khác.

8. CLAUDE.md là trang mục lục của workspace

Simon muốn chắc rằng nền móng của setup vững, vì mọi thứ nói tới từ đầu video đều dựa trên nó. Khi Opus 5 ra mắt gần đây, Anthropic đã làm một việc mà anh gọi là điên rồ: họ xoá hơn 80% chỉ dẫn của chính Claude Code, vì phần lớn chỉ dẫn đó tồn tại để sửa những thứ mà các model cũ hay làm sai.

Docs của Anthropic bảo giữ CLAUDE.md dưới 200 dòng, và đó không phải lời khuyên mới, vì file dài hơn tốn nhiều chi phí hơn và ít được làm theo hơn. Trên màn hình là đoạn docs "Keep your files short, organized, and consistent", với dòng được tô đậm: mục tiêu dưới 200 dòng cho mỗi file CLAUDE.md, file dài hơn tiêu nhiều context hơn và giảm mức tuân thủ.

Nhưng Simon chia sẻ cách anh bắt đầu nghĩ về CLAUDE.md, và cho rằng cách nghĩ này có thể hữu ích cho bạn. Với anh, CLAUDE.md giờ là trang mục lục (contents page) của workspace. Nó làm đúng việc mà SKILL.md làm bên trong một thư mục skill.

Có bốn thứ vẫn nên nằm trong CLAUDE.md:

1. Các tool và lệnh mà Claude không thể tự đoán ra.
2. Bất cứ việc gì bạn làm khác với cách Claude vẫn làm theo mặc định.
3. Có liên quan tới điều trên: những "gotcha" mà Claude đã làm sai hơn một lần.
4. Những ranh giới (boundaries) đã nói ở đầu video, ví dụ "chỉ viết bản nháp email".

Mọi thứ khác trong CLAUDE.md về cơ bản trở thành một pointer, một tham chiếu tới file khác, nơi Claude có thể vào lấy thêm thông tin khi cần.

9. Ba luật cho pointer và lệnh /doctor prompt-audit

Với chính các pointer, có ba luật cần theo.

Luật một: viết tham chiếu dưới dạng path, không phải import. Nếu bạn dùng ký hiệu @, toàn bộ file sẽ được nạp vào mọi session. Thay vào đó, hãy viết path trong dấu backtick kèm thời điểm nên mở nó, ví dụ "đọc client brief trước mọi việc liên quan tới khách hàng". Như vậy Claude biết chỉ mở file đó vào đúng lúc và nạp nó vào context.

Nội dung file CLAUDE.md trên màn hình, trước khi dòng import bị gạch:

# Weekly client report

Run `check-report` before you call a report done.
Draft only. Never email a client.
Never edit `docs/report-template.md`.

@docs/client-brief.md

Luật hai: trỏ tới mọi file ngay từ CLAUDE.md. Anthropic nói một file chỉ được với tới qua một file khác, tức là lồng nhau, sẽ chỉ được xem trước 100 dòng đầu. Khi đó có thể bạn bỏ lỡ chính chi tiết cần có trong các file tham chiếu.

Luật ba: file nào dài hơn 100 dòng thì có một mục lục ở đầu. Anthropic đặt luật này cho file skill, nhưng Simon áp nó cho mọi file mà mục lục trỏ tới, vì với file nào cũng vậy, bạn sẽ bị đọc dở chỉ 100 dòng đầu.

Simon thừa nhận đây là khá nhiều luật. Bạn có thể tự sửa, hoặc đơn giản là chạy /doctor prompt-audit. Lệnh này kiểm tra CLAUDE.md, skills và rules của bạn để tìm những chỉ dẫn viết cho model cũ, những path không còn tồn tại, và những file mâu thuẫn với nhau.

Nó sẽ không thay đổi gì cho tới khi bạn xác nhận và đồng ý. Sau đó nó cắt mọi thứ Claude vốn đã tự làm khỏi các chỉ dẫn, và biến phần còn lại thành một mục lục, một index với nhiều pointer và tham chiếu tới các file khác.

Quay lại bức tranh đang dựng: CLAUDE.md nằm bên dưới Claude, vì nó được đọc trước mọi thứ khác và là nền móng của mọi công việc bạn làm. Hãy nghĩ về nó như cái index, và mỗi mũi tên đi ra từ CLAUDE.md trỏ tới một file mà Claude chỉ mở khi cần. Đó là progressive disclosure: chỉ nạp context cần thiết vào đúng lúc cần. Bản thân CLAUDE.md chỉ chứa thông tin luôn luôn đúng.

10. Chỉ đưa vào skill những gì Claude làm sai

Quay lại weekly client report: cách bạn thực sự chạy báo cáo đó sẽ được đưa vào một skill, nếu và chỉ nếu Claude không làm đúng được ngay lần đầu khi chưa có gì hỗ trợ. Simon kể đây là điều đã làm anh vấp hết lần này tới lần khác khi build skill. Phần lớn chúng ta lên quy trình cho skill trong đầu, rồi prompt để build skill trước khi Claude kịp thử làm việc đó một lần mà không có skill nào.

Nhưng hướng dẫn về skill của Anthropic bảo làm ngược lại, nhất là bây giờ khi model đã giỏi hơn rất nhiều. Bước đầu tiên họ ghi là hoàn thành task mà không có skill.

Trên màn hình là đoạn "Creating a new Skill", bước 1 "Complete a task without a Skill": làm một vấn đề cùng Claude bằng prompt bình thường; trong lúc làm, bạn sẽ tự nhiên cung cấp context, giải thích sở thích và chia sẻ kiến thức về quy trình; hãy để ý những thông tin bạn phải đưa đi đưa lại.

Nghĩa là bạn làm việc đó với Claude như thường, rồi chạy nó trên các task thật mà không có skill, và ghi lại chỗ nó thực sự làm sai. Khi đó phần skill chỉ giải quyết những vấn đề có thật, thay vì ghi chép những vấn đề tưởng tượng. Bạn không build skill cho một quy trình nữa, mà gần như reverse engineer skill để xử lý những thứ Claude không tự lo được khi chưa có gì.

Simon nói chắc bạn đã thấy một chủ đề lặp lại trong video, về những gì thay đổi suốt sáu tháng qua: để Claude yên làm việc của nó cho tới khi nó mắc lỗi. Rồi mới thêm hạ tầng và các file như skill để hỗ trợ nó tới đích. Đội của Anthropic cũng nói phần lớn những skill tốt nhất của họ bắt đầu chỉ với vài dòng và một gotcha duy nhất, sửa một điều mà Claude làm khi chưa có gì. Cách nhìn này coi skill là danh sách những thứ Claude đã làm sai, chứ không còn là cẩm nang cho cả quy trình.

Còn một cách khác: bây giờ bạn có thể record một skill trong desktop app, nó làm cùng việc đó bằng cách xem bạn làm. Khi Simon tự chạy thử trên một automation DM cho Instagram, nó nhận ra những chỗ anh làm sai trong lúc demo và ghi lại chính những chỗ đó. Anh nhớ skill lúc ấy nhỏ tới bất ngờ, và giờ anh hiểu chính xác vì sao: nó chỉ ghi lại những phần Claude không tự hiểu được.

Tóm lại, bạn chọn quy trình muốn tự động hoá, chạy nó không có skill trên một model tốt, và chỉ ghi lại những lần bạn phải sửa, những lần sửa đưa nó tới definition of done của bạn. Sau đó hãy chắc rằng bạn chạy nó trên đúng model bạn định dùng cho mọi lần sau, vì các model khác nhau sẽ cho kết quả khác nhau và cần nhiều hay ít chỉ dẫn hơn.

Đó là phần còn lại của hạ tầng. Trên bức tranh, skills nằm cạnh CLAUDE.md. CLAUDE.md là những gì luôn đúng về setup, về workspace hay doanh nghiệp của bạn. Còn một skill là những gì đúng với một quy trình cụ thể, và phần lớn chỉ là những chỗ cần sửa.

11. Thư viện skill: 7 trên 9 không hơn một file giả

Tiếp tục với skill, Simon nói nhanh về các thư viện skill. Anh thấy những gói skill nổi tiếng được chia sẻ liên tục và nhận hàng nghìn sao. Nhưng một developer đã thử nghiệm chín gói như vậy vào cuối tháng Chín. Người đó chạy 450 lần trên Opus 5.5, và chỉ hai trong chín gói làm tốt hơn một file giả (dummy file) có cùng độ dài, điều mà Simon nói thẳng là rất đáng suy nghĩ.

Đây là một vài trong những skill cho coding agent được gắn sao nhiều nhất. Vậy mà context bên trong chúng không làm output tốt hơn trong bảy trên chín kịch bản.

12. Dọn thư mục skill bằng plugin eval và /skill-doctor

May là đội Claude Code đã nhận ra điều này và giờ có sẵn một cách để kiểm tra. Bạn có thể chạy claude plugin eval, lệnh này chạy cùng một task có skill và không có skill, rồi chấm điểm dựa trên khác biệt. Bạn thấy được skill so với không skill: Claude Code làm task bạn cần tốt tới đâu trong mỗi trường hợp.

Như tên gọi, công cụ này chủ yếu được thiết kế cho plugin, nhưng bạn có thể chỉnh để dùng cho từng skill riêng lẻ. Simon đã làm việc đó cho thành viên trong cộng đồng của anh.

Điều nó cho bạn biết là: nếu hai điểm số ra bằng nhau, skill đó chỉ đang tốn thêm token của bạn, tức nó chỉ là đồ trang trí. Chưa kể nó còn làm thư mục của bạn thêm bừa bộn.

Để dọn skill, Simon chạy /skill-doctor trước. Lệnh này cho thấy mỗi skill tốn bao nhiêu và được dùng thường xuyên tới đâu. Rồi anh bỏ những skill không bao giờ dùng. Tiếp đó anh chạy plugin eval trên các skill còn lại và cắt thêm được vài skill nữa trong thư mục skills.

Simon nói điều này hoàn toàn hợp lý khi nghĩ tới việc model giờ giỏi thế nào. Chỉ là phần lớn chúng ta chưa sửa lại thư viện cũ, với cả đống skill đã cài. Nếu chỉ mang về một điều từ video này, anh khuyên hãy xử lý việc đó ngay hôm nay.

13. Luật bắt buộc phải nằm trong hook, không phải chữ in hoa

Tới đây, bạn đã có gần như toàn bộ hạ tầng then chốt. Nhưng còn ba điều sẽ thực sự tăng tốc khối lượng công việc bạn làm được mà vẫn giữ chất lượng output cao.

Có lẽ bạn đã nhận ra rằng việc thêm những chữ như "IMPORTANT" hay "YOU MUST" viết hoa vào rules, vì Claude cứ làm sai, không còn hiệu quả nữa. Trên màn hình, Simon so một dòng CLAUDE.md theo kiểu hướng dẫn tháng Tư 2025: dòng "run tests before committing" được đổi thành "IMPORTANT: YOU MUST run tests before committing".

Nếu bạn thực sự muốn bảo đảm một điều sẽ xảy ra, bạn cần viết hook tốt. Với ai chưa dùng, hook chỉ là những script nhỏ chạy được, chạy vào một thời điểm bạn định sẵn. Thời điểm đó có thể là ngay trước khi Claude dùng một tool, hay mỗi lần nó dùng tool. Hook sẽ chạy vào lúc đó và hoàn toàn deterministic, không tốn token AI nào và chạy bất kể thế nào.

Trong ví dụ client report, nếu có rule "không bao giờ email khách hàng", bạn về cơ bản xoá dòng đó đi và biến nó thành một hook chặn mọi email gửi tới khách. Hook đó bảo đảm kết quả, vì nó chạy bất kể thế nào trên điều kiện bạn đặt.

Vậy hãy rà file CLAUDE.md, tìm mọi thứ viết hoa. Mỗi dòng như vậy hoặc là thứ Claude vốn đã làm, nên xoá đi, hoặc là thứ tuyệt đối không được xảy ra, nên trở thành hook. Quay về lời khuyên gốc của Boris, đây chỉ là những guardrails được gắn vào các hành động mà Claude có thể làm thay bạn.

14. Để Claude tự dựng agent team, bạn chỉ đặt giới hạn

Hai điều cuối nói về việc bạn có thể đứng xa công việc tới mức nào, để mọi thứ chạy mà không cần bạn. Ví dụ: bạn có nên dùng subagent và agent team không, hay giờ nên giao luôn quyết định đó cho Claude?

Đầu năm nay, người ta build agent team bằng tay, với orchestrator, file agent và routing. Có một lead agent, và bạn có thể tương tác với từng subagent, giao task cho nó. Nhưng hướng dẫn cho Opus 5 giờ nói model này giao việc cho subagent dễ dàng hơn mọi model trước đó. Với những việc nhỏ, Anthropic nói điều đó về cơ bản chỉ nhân chi phí và thời gian lên. Lời khuyên của họ là đặt giới hạn số subagent được thêm vào, để không liên tục thêm ngày càng nhiều subagent cho một task đơn giản.

Nói đơn giản, Claude sẽ tự phán đoán thay bạn về team cần dựng, team cần bao nhiêu thành viên, task nào cần giao cho thành viên nào. Claude làm việc đó. Còn việc của bạn bây giờ là đặt team được phép lớn tới đâu, các ranh giới, các guardrails. Điều đó giúp nó không tốn quá nhiều hoặc làm quá tay cho một task không cần tới.

Simon đã thử đưa cho Claude một brief nặng về research mà không có sẵn file agent nào. Trên task panel, bạn thấy mặc định nó tự dựng các helper của mình. Nó hiểu nên đi theo workflow nào, giao việc cho những subagent nào để hoàn thành task.

15. Ngoại lệ cho subagent, và Ultracode

Có thể bạn nhớ hồi người ta nói về Ultracode như một effort level. Ultracode thực ra tạo ra nhiều nhóm subagent, và có thể dựng thêm subagent mãi vào một team cho một task riêng lẻ.

Có một lưu ý với việc để Claude tự phân bổ subagent. Nếu bạn đang làm một skill vì Claude có giới hạn khi chưa có gì hỗ trợ, và trong đó có một bước như research lớn, hay một bước kết nối tới MCP hoặc connector, thì bạn nên bảo nó làm bước đó trong một subagent, để cuộc chat chính sạch sẽ cho phần việc thực sự quan trọng. Nhớ lại lý do ta tính tới subagent ngay từ đầu, một trong các lý do là giữ main context sạch. Vì vậy giao những task đó cho subagent có thể rất mạnh.

Tóm lại, Claude sẽ thêm bất kỳ helper nào nó cần cho một quy trình, nó tự dựng chúng, nhưng bạn có thể kiểm soát giới hạn trong config.

16. Chạy mà không cần bạn: projects, routines và MCP events

Điều cuối cùng là chạy mọi thứ mà bạn thậm chí không cần nghĩ tới. Giấc mơ ngồi trên bãi biển với ly piña colada trong khi agent điều hành cả doanh nghiệp thì chắc chắn chưa tới. Nhưng điều cuối này đưa ta tới gần hơn. Trên màn hình là một nhân vật hoạt hình nằm thư giãn trên ghế bãi biển với ly cocktail, rồi bật dậy hoảng hốt khi một thông báo hiện ra.

Một trong những cập nhật mới nhất của Claude Code, projects, là một bước đúng theo hướng đó. Project giờ là một cuộc hội thoại liên tục, tự mở các thread của nó, trong khi trước đây bạn phải tự mở từng session, và nó tiếp tục chạy cả khi máy bạn đã tắt. Nó chạy nhiều agent song song để hoàn thành một task cụ thể.

Lý do điều đó mạnh là khi bạn có context tách biệt cho từng project, kết hợp với task chạy theo hẹn giờ hoặc theo sự kiện, ví dụ một việc được thêm vào to-do list, hoặc một contact hay lead mới được thêm vào CRM, thì bạn có thể dựng routines trong Code, hoặc scheduled tasks trong chế độ Chat hay Cowork. Những thứ đó có thể xử lý công việc mà bạn không cần có mặt.

Simon nói đây chính là cách anh sản xuất toàn bộ carousel và shorts cho Instagram bây giờ. Tất cả những gì anh cần làm là bấm approve trong một giao diện anh tự build. Anh có nhắc rằng cách làm này được chia sẻ cho thành viên trong cộng đồng trả phí của anh.

Điều này càng quan trọng hơn khi Codex vừa công bố MCP events cho plugin, nghĩa là giờ các app đã kết nối có thể kích hoạt Codex chạy khi có chuyện gì đó xảy ra. Trên màn hình là trang recap DevDay 2026 của OpenAI, mục "MCP events for plugin automations": hỗ trợ cho đặc tả MCP Events đề xuất, để plugin có thể khởi động automation khi có sự kiện trong một app đã kết nối, ví dụ bảo ChatGPT theo dõi task mới trên một project board rồi đọc tài liệu liên quan và soạn kế hoạch ngay cả khi bạn vắng mặt.

Về cơ bản, ta đang đóng gói mọi thứ đã nói trong video thành một gói để chạy. Khi đó bạn tập trung vào quy trình tiếp theo muốn tự động hoá, vì tất cả những gì cần làm với quy trình đã chạy mà không có bạn là xác nhận output của nó. Simon nhắc lại một lần rằng cộng đồng của anh giúp mọi người giao quy trình đầu tiên cho AI theo cách này.

Anh kết thúc bằng lời hẹn: video tiếp theo sẽ đi qua mọi cập nhật trong năm qua dành riêng cho việc build skill. Anh cảm ơn mọi người đã xem.