15 bài học sau hơn 1.000 giờ dùng Claude Code

1. Những gì hơn 1.000 giờ với Claude Code dạy Nick

Nick Saraev mở đầu bằng hai con số của chính anh, theo video đăng ngày 25/09/2026: anh đã tiêu hơn 30.000 đô cho Claude Code chỉ trong vài tháng gần nhất (tiêu đề video ghi con số chính xác là 31.141 đô), và đã dành hơn 1.000 giờ làm việc với các model như Opus 5.5. Anh cho người xem lướt qua danh sách hoá đơn thật của mình trên màn hình và mời mọi người cứ xem.

Mục tiêu của video, theo lời anh, là đưa cho người xem tất cả những gì anh ước mình đã biết khi mới bắt đầu. Anh nói trước rằng đây không phải những mẹo đơn giản nhất: muốn vắt thật kiệt "chiếc khăn ướt" Claude Code (anh dùng thành ngữ squeeze the proverbial wet towel) thì phải đi vào chi tiết vụn vặt. Dù vậy, anh đã sắp xếp chúng từ đơn giản nhất tới phức tạp nhất, để ai ở trình độ nào cũng lấy được thứ gì đó cho mình (video đăng ngày 25/09/2026).

Trên màn hình, anh mở một bảng vẽ lớn với tiêu đề "What 1,000 hours of Claude Code taught me", gồm mười lăm ô đánh số, mỗi ô là một mẹo. Phần còn lại của video đi lần lượt qua từng ô (video đăng ngày 25/09/2026).

2. Đừng tin output đầu tiên: chạy eval

Mẹo đầu tiên là đừng tin output đầu tiên. Nick kể, trong video đăng ngày 25/09/2026, rằng anh đang làm việc với một doanh nghiệp trị giá nhiều tỷ đô mà theo anh khá "có tội" ở đúng chuyện này: tin vào chất lượng của output đầu tiên. Điều đó đã gây ra những rắc rối lớn ở các bước phía sau, và anh nói sẽ kể thêm một chút về chuyện này sau.

Điều đáng tiếc mà phần lớn mọi người không nhận ra về Claude và các large language model khác, theo Nick (video đăng ngày 25/09/2026), là chúng không phải hệ thống tất định (deterministic). Nói cụ thể: nếu bạn đưa cùng một prompt nhiều lần, mỗi lần nó sẽ cho một kết quả khác nhau. Có khi các kết quả chỉ lệch nhau một chút, có khi chúng khác hẳn nhau, chẳng gần giống chút nào.

Anh lấy ví dụ: giả sử bạn nghĩ ra một prompt "xịn", chẳng hạn viết kịch bản cho một video YouTube. Lần đầu bạn chạy, nó làm rất tốt. Vậy đã đủ để lấy prompt đó cất vào bộ SOP (quy trình chuẩn) của doanh nghiệp và chuẩn hoá cả công ty theo nó chưa? Câu trả lời của anh là không, bạn không thể tin output đầu tiên.

Lý do: nếu chạy lại chính prompt đó, giả sử sáu lần, lần đầu bạn sẽ thốt lên "trời ơi, tuyệt quá". Nhưng lần thứ hai rất có thể bạn sẽ nói "cái này dở tệ". Lần thứ ba có khi tạm được, nhưng tới lần thứ tư và thứ năm bạn sẽ hỏi "chuyện gì đang xảy ra vậy Claude, bạn vừa ngã cầu thang à?". Rồi tới lần thứ sáu nó lại kéo bạn về chỗ ổn (video đăng ngày 25/09/2026).

Theo cách Nick giải thích trong video đăng ngày 25/09/2026, do bản chất thống kê của model có những sai lệch nhỏ, lần chạy đầu tiên bạn có thể rơi vào một điểm cực đại, tức là một tình huống chất lượng cao. Nhưng lần thứ hai, thứ ba hay thứ tư, bạn có thể rơi vào một điểm cực tiểu, tức một output chất lượng thấp, ít giá trị.

Vì thế, theo anh, việc của một prompt engineer, và thật ra là việc duy nhất của người xây hệ thống bằng Claude và các model khác cho chính mình hay cho công ty khác, là thu hẹp các đỉnh và đáy trong cách mình dùng model: chuẩn hoá nó để mỗi lần nhờ một việc, bạn biết mình sẽ nhận được gì (video đăng ngày 25/09/2026).

Cách làm là chạy đi chạy lại một bộ đánh giá prompt mỗi khi bạn định đưa thứ gì đó vào một workflow. Tên gọi chuyên môn của chúng là eval. Nếu chưa nghe thuật ngữ này bao giờ, anh nói bạn sẽ gặp nó rất nhiều trong mảng large language model engineering, và eval là thứ quan trọng cần hiểu khi muốn cải thiện hệ thống từng bước (video đăng ngày 25/09/2026).

Chạy một lần, thấy được rồi cất đi là không đủ. Điều bạn cần làm là chạy 10 lần, đếm xem bao nhiêu lần trong 10 lần nó thật sự đạt. Nếu là 7 trên 10 thì đó là 7 trên 10. Rồi khi chỉnh prompt, bạn lại đếm số lần đạt, so với lượt chạy trước. Nếu lượt mới tốt hơn, chẳng hạn được 8 trên 10 thay vì 7 trên 10, thì giữ bản mới. Về cốt lõi, Nick nói, đây là một quá trình nghiên cứu thống kê: mỗi lần làm vậy, bạn về cơ bản là một nhà khoa học.

3. Cho Claude một cách tự kiểm tra bài của nó

Điều thứ hai Nick nói tới là cho Claude và các model khác một cách để tự kiểm tra công việc của chính chúng. Giả sử bạn giao một task, kiểu "Claude ơi, viết cho tôi một bài luận về X, Y và Z". Phần lớn thời gian, theo Nick (video đăng ngày 25/09/2026), Claude sẽ làm được. Nhưng giả sử lần này bạn không gieo được con xúc xắc may mắn, vì bạn không có một bộ eval tốt và prompt của bạn thì lộn xộn. Khi đó chất lượng có thể khá tệ.

Anh nghĩ về chuyện này qua hình ảnh bản nháp. Ai từng viết luận đều đã đi qua quy trình mà trường học khuyên: viết bản nháp đầu, bản nháp thứ hai, có thể một bản gần cuối, và cuối cùng mới tới bài hoàn chỉnh đã sửa. Khi bạn chỉ để Claude đưa kết quả một lần, trong đúng một lần thử, thì chất lượng thấp cũng chẳng có gì lạ, vì nó giống như bạn chỉ có bản nháp đầu tiên của bài luận (video đăng ngày 25/09/2026).

Và bản nháp đầu, như Nick nói (kèm một câu xin lỗi vì lời lẽ hơi thô), thường thì dở tệ. Vậy việc cần làm là cho nó một cách để kiểm tra rồi sửa chính công việc của mình trước khi làm lại từ đầu. Càng làm vậy nhiều lần, theo anh (video đăng ngày 25/09/2026), chất lượng cuối cùng càng tăng.

Ngay cả khi bộ eval của bạn được đặc tả khá sơ sài, theo kinh nghiệm Nick kể trong video đăng ngày 25/09/2026, chỉ cần cho model một vòng sửa (revision loop) là thường đã cải thiện chất lượng đáng kể, vì giờ nó có thứ để so sánh. Vòng đó có thể là một ảnh chụp màn hình, một phép so sánh với ví dụ mẫu, hoặc một kiểu bài kiểm tra chuẩn. Nếu là một website, anh gợi ý cho nó chạy một bài kiểm tra Lighthouse hay PageSpeed Insights.

4. Để code làm context

Điều thứ ba là để code làm context (let the code be the context). Nick nói anh thấy lỗi này rất nhiều, và nó là một hệ quả phụ của skill. Theo cách anh mô tả trong video đăng ngày 25/09/2026, skill là cách làm khá ngây thơ để vận hành hoá và chuẩn hoá các task, do Anthropic tung ra cách đây vài năm (lời anh) rồi cả thế giới nhảy theo. Nhưng theo anh, skill thật sự không còn là cách làm tốt nhất nữa.

Lý do: giả sử bạn đang phát triển một skill hay một app nào đó. Thông thường, cách một model, ở đây là Claude Code, làm việc trên app là nó vừa sửa code, vừa sửa thêm một loạt thứ đi kèm. Chẳng hạn nó đang viết đoạn code tạo thumbnail. Khi số phiên bản tăng dần, từ V1 lên V2, V3 rồi V4, code đã được cập nhật. Nhưng các ghi chú đi kèm thì nhiều khi vẫn ở V1, file spec và file log cũng có thể vẫn ghi V1 (video đăng ngày 25/09/2026).

Kết quả là có một độ vênh giữa nguồn sự thật (source of truth) và phần context mà Claude cùng các model khác dùng để quản lý nguồn sự thật đó. Hai nguồn trôi dần ra xa nhau. Trên bảng vẽ, anh vẽ file "code v4" bên trái, và ba file NOTES.md, SPEC.md, LOG.md vẫn ở v1, nối với code bằng dấu khác, kèm dòng "two sources of truth drift apart" (video đăng ngày 25/09/2026).

Cách làm hiệu quả hơn nhiều bây giờ, theo Nick (video đăng ngày 25/09/2026), là đưa thẳng mọi thứ vào chính code (anh nói "inlining") của app. Anh còn gợi ý bạn có thể kéo xuống phần mô tả video, chép phần lời của video, nhất là đoạn anh đang nói, rồi đưa cho Claude. Anh tin rằng với mọi task liên quan tới lập trình hay tới skill, việc chôn thẳng mọi thứ vào script sẽ cải thiện eval đáng kể, mà rốt cuộc eval là thứ ta làm tất cả những chuyện này để đạt được.

Như vậy, khi bạn nói "thêm giúp tôi một nút logout lên navbar", thay vì phải đọc qua ghi chú, spec và log, Claude chỉ cần đi thẳng vào code, xem các comment inline, vân vân. Đó là thứ nó buộc phải đọc mỗi lần làm việc, và chất lượng sẽ tốt hơn rất nhiều. Nick nói anh đã thử cách này ở nhiều doanh nghiệp và nhiều nơi khác, và với anh đây là cách nên làm (video đăng ngày 25/09/2026).

Ngoại lệ chính, tất nhiên, là file CLAUDE.md của bạn, nơi bạn ghi cách bạn muốn Claude làm việc: sở thích (preferences), bài học (lessons), hay như anh đùa, cả nội dung các video YouTube của Nick Saraev. Những thứ đó không thay đổi về bản chất việc code làm gì (video đăng ngày 25/09/2026).

5. Để Claude viết prompt cho bạn

Việc lớn tiếp theo là để Claude viết prompt cho bạn. Nick biết nhiều người đã cầm sẵn chĩa ba (pitchfork) để phản đối mẹo này. Ngày xưa, anh nói, chúng ta từng là những prompt engineer giỏi nhất, và anh từng rất tự hào về kỹ năng viết prompt của mình (video đăng ngày 25/09/2026).

Sự thật không vui, theo Nick (video đăng ngày 25/09/2026), là bây giờ AI giỏi việc này hơn chúng ta. Lý do anh đưa ra: đó là một trong những thứ Anthropic đã "nướng" sẵn vào Claude, khả năng giao tiếp với các đồng đội khác, tức là viết prompt cho các đồng đội khác.

Vì vậy, thay vì nói với Claude "tôi muốn X cho đối tượng Y, làm theo cách này cách kia, cách này cách kia, bạn có đủ thông tin rồi, làm đi", hãy chỉ nói: "tôi muốn thứ X cho đối tượng Y, tôi muốn bạn giúp tôi viết một prompt". Sau đó Claude sẽ hỏi lại bạn vài câu: nó dành cho ai? Bạn trả lời: cho founder. Thế nào mới là thật sự tốt? Bạn đưa nó một ví dụ dài một trang. Bạn có ví dụ nào không? Và bạn đưa ví dụ (video đăng ngày 25/09/2026).

I want X for Y audience.
Help me write a prompt.

Khi viết prompt kiểu này, một dạng meta prompting, theo Nick (video đăng ngày 25/09/2026) bạn sẽ có kết quả tốt hơn đáng kể, vì Claude cực kỳ hiệu quả ở việc này: nó đã được huấn luyện, hay được nướng sẵn, theo cách Claude hiểu AI agent và các model khác thường học như thế nào. Bạn vẫn là người khởi động hành động, nhưng Claude giờ đứng cao hơn một tầng trừu tượng, ít nhất là so với vài năm trước. Bản thân các prompt thậm chí không còn quá quan trọng nữa; điều quan trọng là biết cách prompt Claude để nó tự prompt chính nó.

Với một yêu cầu cực nhanh và đơn giản, thứ bạn làm hằng ngày và hiểu rõ quy trình, thì tất nhiên có thể bỏ qua bước này, chỉ cần nói "Claude, vào website này theo cách này và lấy cho tôi thông tin này", vậy là được. Nhưng với bất cứ việc gì có phạm vi lớn hơn, nhiều project có thể ngốn ngân sách token lớn, Nick nói làm theo cách này sẽ cho kết quả tốt hơn mọi cách khác (video đăng ngày 25/09/2026).

6. Theo dõi thứ gì đang ăn context window

Điều thứ năm là theo dõi thật kỹ thứ gì đang ăn context window của bạn. Nếu bạn chưa biết, Nick giải thích rằng bạn có thể gõ /context vào bất kỳ chat nào với các model Claude để xem điều này (video đăng ngày 25/09/2026). Context window, tức tổng lượng context mà Claude có thể giữ trong đầu khi làm việc cho bạn, thường đã bị chiếm khá nhiều bởi những thứ mặc định do hệ thống cung cấp, ngay từ khi vừa mở ra, trước khi bạn kịp gõ một chữ.

Anh chỉ lên thanh màu trên bảng vẽ: màu xám ở đây là system prompt, có thể là CLAUDE.md của bạn; màu tím có thể là các built-in tool; màu cam có thể là các MCP connector; tiếp theo có thể là memory; và cuối cùng màu xanh lá có thể là các skill. Trên thực tế, anh nói mình chỉ ước lượng bằng mắt, khoảng 30% context đã bị chiếm trước khi anh nói gì (ước lượng của Nick trên ví dụ của anh, video đăng ngày 25/09/2026).

Khi bạn lấp đầy một chat bằng một loạt câu hỏi và yêu cầu ngẫu nhiên, thì hiển nhiên context window càng dài, mỗi request càng đắt. Nhưng, theo Nick (video đăng ngày 25/09/2026), chính model cũng trở nên kém thông minh hơn do context rot và một loạt yếu tố khó tránh khác khi làm việc với các agent mang tính xác suất như thế này.

Vậy điều bạn muốn làm là: nếu bạn không thật sự dùng tất cả các MCP, hãy tắt càng nhiều càng tốt. Nếu bạn không dùng các skill, hãy cắt bớt càng nhiều càng tốt (video đăng ngày 25/09/2026).

Khi đang prompt một model mà context gần đầy, hoặc thấy model không phản hồi như bạn muốn, hoặc vừa mất nhiều thời gian để model thiết kế một prompt cho bạn đưa ngược vào nó, thì đừng tiếp tục prompt trong cửa sổ đó. Hãy chép prompt đó ra và chuyển sang một phiên mới, một phiên có context gần như trống, rồi tiếp tục cuộc trò chuyện ở đó. Chỉ cần prompt chứa đủ context và những thông tin liên quan, Nick nói bạn sẽ ổn (video đăng ngày 25/09/2026).

Một cách khác là dùng /compact. Theo Nick, vào lúc quay video đăng ngày 25/09/2026, lệnh này khá tốt, dù có một số vấn đề với cách nó nén các tool definition và vài thứ khác, có thể đã được sửa khi bạn xem video. Anh thấy dùng /compact thường xuyên là khá hợp lý, và vì lý do đó anh hay chủ động compact sớm hơn nhiều so với lúc Claude tự động compact.

7. Nới dây cương: đối xử với Claude như một contractor

Điều tiếp theo là nới dây cương (loosening the leash). Nick tự trêu rằng mình nói như một ông già: hồi "ngày xưa tươi đẹp" của AI model, khoảng 2020, 2021, 2022, bạn cần giữ dây cương thật chặt với model. Nghĩa là bạn phải qua lại rất nhiều lần mới có được thứ mình muốn, phải liệt kê mọi cách không được làm để nó biết tránh hết những cách đó khi làm việc (video đăng ngày 25/09/2026).

Điều bạn có thể làm bây giờ, theo Nick (video đăng ngày 25/09/2026), là bỏ những hướng dẫn từng bước cực chi tiết và đối xử với Claude giống một contractor hơn là một nhân viên nội bộ.

Anh giải thích cho ai không làm kinh doanh: với một nhân viên nội bộ, bạn thường đưa đặc tả công việc rồi còn chỉ luôn cho họ cách làm. Như vậy họ sẽ tối ưu quy trình theo cách bạn vạch ra, và bạn nhận được một kết quả khá ổn. Còn contractor thì thường đã có sẵn một bộ quy trình riêng. Họ là contractor, là freelancer, làm việc cho chính mình, và họ biết làm việc đó rất giỏi. Thường bạn trả họ nhiều tiền hơn một chút, rồi họ dùng quy trình đã tối ưu cao, xây qua có khi hàng trăm nghìn project (lời anh), để làm nhanh hơn và tốt hơn nhiều so với quy trình của bạn. Sau đó có thể bạn trao đổi, đặt câu hỏi với họ.

Vì vậy, thay vì đưa cho Claude cách làm từng bước, hãy đối xử với nó như một contractor: chỉ cần đưa một định nghĩa tốt về thế nào là xong (definition of done). Kiểu như: "bạn xong khi điều này đúng, điều kia đúng, và điều kia nữa đúng. Nếu tất cả đều đúng thì bạn ổn rồi. Có câu hỏi gì cứ hỏi." Những điều như "nếu không biết thì hỏi" hay "đừng bao giờ bỏ qua test", anh nói bạn có thể ghi vào CLAUDE.md (video đăng ngày 25/09/2026).

Theo Nick (video đăng ngày 25/09/2026), bạn không còn cần đống "sẹo" kiểu những câu "không bao giờ, không, không bao giờ" viết cho các model đời cũ. Claude bây giờ khá thông minh và tự suy ra được phần lớn điều bạn muốn. Chỉ cần tập trung vào nguyên tắc ở mức cao, kiểu "nếu bạn không biết gì thì cứ hỏi tôi, vì việc này rất quan trọng", là bạn sẽ ổn.

8. Chẩn đoán trước khi bắt tay sửa

Việc lớn tiếp theo là chẩn đoán trước khi bắt đầu sửa. Giả sử có một bug nào đó. Thay vì nói "tôi muốn bạn sửa cả app, nó không chạy", hãy nói (video đăng ngày 25/09/2026):

List all of the problems with this app.
Don't rewrite or do anything yet.

Lý do, theo Nick (video đăng ngày 25/09/2026): nếu bạn để nó sửa luôn, mà những vấn đề nó tìm ra không phải thứ bạn lường trước hay không phải thứ bạn muốn giải quyết, thì câu "nó hỏng rồi, sửa đi" có thể chẳng dẫn tới đâu. Hãy nhớ rằng Claude có định nghĩa riêng về thế nào là một vấn đề và cái gì đáng sửa. Thay vào đó, bạn cần liệt kê các vấn đề ra, rồi chỉ đưa cho nó những vấn đề bạn muốn nó giải quyết.

Ví dụ trên bảng vẽ: nó liệt kê cho bạn bốn vấn đề, gồm mở đầu mơ hồ (vague opening), nói một ý hai lần (says it twice), quá suồng sã (too casual) và không có ví dụ (no example). Bạn bảo: không, sự suồng sã thì ổn, đó không phải thứ tôi muốn nó sửa. Bạn gạch dòng đó đi, rồi chỉ đưa cho nó ba điều bạn thật sự muốn sửa. Như vậy, theo Nick (video đăng ngày 25/09/2026), bạn tiết kiệm ngân sách token, và cũng rút ngắn đáng kể thời gian để tới được kết quả.

Hãy hình dung nếu bạn làm hỏng bước này: bạn sẽ nói "sửa hết cái này đi". Nó sẽ sửa cả phần suồng sã, và ở bước sau bạn lại phải làm lại phần đó. Theo Nick (video đăng ngày 25/09/2026), như vậy tốn gấp đôi số bước, gấp đôi thời gian và gấp đôi số token.

9. Thử bằng MCP, scale bằng skill

Việc lớn tiếp theo là MCP server, viết tắt của Model Context Protocol. Nick kể cách anh làm việc vào lúc quay video (đăng ngày 25/09/2026): gần như lúc nào anh cũng dựng thử (prototype) một hệ thống, cho chính mình hay cho nhiều khách hàng anh làm cùng, bằng một MCP connector. Khi nói MCP connector, anh nói rõ là anh muốn nói tới những thứ như plugin, connector trong cả Codex lẫn Claude Code, và các khái niệm tương đương ở các app khác. Nếu nó là một plugin, một connector, hay kiểu đăng nhập OAuth, thì phần lớn thời gian bên dưới nó thật ra là Model Context Protocol, và đó là thứ anh đang nói tới.

Lý do anh dùng nó để prototype: theo Nick (video đăng ngày 25/09/2026), chỉ mất một cú bấm để dựng MCP lên, bấm một nút, đăng nhập, xong. Bạn có thể đi tiếp và kiểm chứng là nó chạy. Nhưng khi đã kiểm chứng xong, dùng nó để scale lại không tối ưu.

Anh nói đã thấy rất nhiều quy trình ở các doanh nghiệp lớn mà anh làm cùng, những nơi đã lao vào bằng cả hai chân để đưa AI vào toàn bộ stack, mà các quy trình thường ngày vẫn chạy bằng MCP server. Ưu điểm của MCP là giúp bạn chạy được rất nhanh. Còn nhược điểm, theo Nick (video đăng ngày 25/09/2026), là nó thường rất nặng về context, và chứa một đống thứ vớ vẩn mà bạn vốn chẳng bao giờ muốn có trong một tool spec.

Vì thế, cách làm là: khi đã kiểm chứng việc đó làm được, hãy biến những gì bạn vừa làm thành một custom skill gọn nhẹ. Lúc đó bạn có một danh sách tool call definition và tool spec được lọc kỹ hơn, sát hơn nhiều. Theo Nick, nó sẽ nhẹ hơn đáng kể cho context và cũng có khả năng đúng cao hơn đáng kể (video đăng ngày 25/09/2026).

Turn what we just did into a lean custom skill.

Một điều nữa anh rất ghét: mỗi lần mở Claude Code với một đống MCP, theo Nick (video đăng ngày 25/09/2026), lại mất thêm vài giây khởi động, vì Claude phải kiểm tra các MCP có chạy không, gửi nhận vài tín hiệu, kiểu dọn dẹp để chắc mọi thứ ổn. Anh cực ghét phải chờ việc đó, nên anh cố tỉa bớt danh sách MCP, tức danh sách connector trong trường hợp Claude Code, càng nhiều càng tốt khi khởi động. Anh thấy việc này thường tiết kiệm cho anh khoảng ba tới năm giây mỗi lần.

10. Chạy song song các task có phạm vi rõ ràng

Điều tiếp theo là cách chạy song song các task có phạm vi rõ ràng (scoped task). Nick kể rằng, tính đến lúc quay video đăng ngày 25/09/2026, anh không còn chỉ nói "Claude, làm X cho tôi", rồi nhận "vâng Nick, tôi đã làm X", rồi "tuyệt, giờ chuyển sang Y" nữa. Thay vào đó, anh chia thật rõ phạm vi của từng task cụ thể, rồi để Claude quản lý tất cả song song bằng subagent, agent team hoặc các tính năng tương tự.

Giả sử bạn đang thiết kế một website hay ho nào đó. Bạn có thể để nhiều agent cùng làm nhiều phần khác nhau của website một lúc. Theo Nick (video đăng ngày 25/09/2026), Claude thường tự làm vậy, nhưng bạn cũng có thể khuyến khích nó bằng câu như sau, một câu anh rất thích và thường giúp tăng tốc phát triển đáng kể:

Do this in parallel by running mutually exclusive scoped tasks.

Lý do là: giả sử có một bug ở nút logout, có một cải tiến bạn muốn làm ở hero section, và có một thay đổi bạn muốn làm ở feedback form. Thay vì chờ Claude làm lần lượt từng việc, bạn có thể cho cả ba việc chạy cùng lúc, rồi chỉ cần một bước merge để gộp tất cả lại (video đăng ngày 25/09/2026).

Nick vẽ thêm ngay trên bảng (và xin người xem thông cảm cho nét vẽ của mình). Thay vì quy trình kiểu "Claude, làm cái này", "vâng Nick, tôi làm xong rồi, giờ làm gì tiếp?", "Claude, làm cái này", "vâng Nick, xong rồi, làm gì tiếp?", "Claude, làm cái này", tức ba bước nối tiếp, thì giờ nó giống thế này: bạn nói ngay từ đầu "Claude, tôi muốn bạn làm hết những việc này: sửa hero section, feedback form, nút logout, và một việc khác nữa". Rồi ở cuối, việc duy nhất là merge. Phía này là chỉ dẫn ban đầu, ở giữa là danh sách lớn các scoped task, và phía kia là một bước merge, rất đơn giản (video đăng ngày 25/09/2026).

Điểm mấu chốt, tất nhiên, là khi giao task, bạn phải đảm bảo không có nhiều agent cùng làm trên một thứ. Theo Nick (video đăng ngày 25/09/2026), Claude tự lo việc này và bạn thường không cần lo nhiều. Nhưng anh nói rõ cái giá: bạn tiết kiệm được một ít thời gian đổi lại tỷ lệ lỗi cao hơn một chút. Anh thích đánh đổi như vậy vì anh nghĩ bạn cần đi nhanh, và anh nói thêm "insert current year here" (hãy điền năm hiện tại vào đây).

11. Luôn bắt đầu lại bằng một handoff note

Điều tiếp theo: luôn bắt đầu lại từ đầu với một handoff note. Ý anh là trong một session rất dài, hiển nhiên bạn sẽ gặp context rot như đã nói ở trên. Càng qua lại nhiều, càng nhiều thứ ngớ ngẩn lọt vào đầu Claude, đơn giản là hệ quả phụ của chính kỹ năng prompt của con người (video đăng ngày 25/09/2026).

Nick tả một tình huống: bạn nói "đừng làm X". Nhưng ba bốn lượt chat sau, bạn lại nói "ừ, tôi muốn nó hơi giống X". Và nó sẽ nghĩ: "anh ấy nói đừng làm X, nhưng cũng nói hơi giống X, chắc mình làm ở khoảng giữa", rồi kết quả thì dở tệ.

Thay vì để chuyện đó xảy ra, mỗi khi Claude không cho kết quả anh muốn, Nick luôn dùng một prompt đơn giản: tóm tắt chúng ta đang ở đâu. Cho tôi biết những gì đã xong. Cho tôi tất cả các quyết định tôi cần đưa ra. Cho tôi những việc tiếp theo. Rồi cho tôi một danh sách các vấn đề còn mở (video đăng ngày 25/09/2026).

Summarize where we are.
Give me what is done.
Give me all the decisions I need to make.
Give me the things that are next.
Then give me a list of open problems.

Sau đó anh tự sửa bất cứ chỗ nào anh thấy sai trong bản tóm tắt đó, rồi đưa nó sang một tin nhắn mới, trong một phiên mới. Theo Nick (video đăng ngày 25/09/2026), thường thì Claude sẽ hiểu: "ok, đây rõ ràng là phần bàn giao từ một session trước, mình nên bắt đầu với ý đó trong đầu". Nó sẽ hỏi bạn những gì còn bỏ ngỏ trong bản tóm tắt đã nén. Và bạn có chất lượng context cao hơn đáng kể nhờ một prompt ngắn hơn rất nhiều. Như đã nói ở trên, anh cũng thấy cách này rẻ hơn.

12. Hỏi chuyện bên lề bằng /btw

Tiếp theo là hỏi những câu bên lề bằng /btw. Nick thấy buồn cười là gần như chẳng ai làm việc này, trong khi anh thì liên tục "/btw". Lý do, theo anh (video đăng ngày 25/09/2026): Claude và các model khác càng agentic, càng khó biết chuyện quái gì đang diễn ra.

Anh hỏi người xem đã bao nhiêu lần gặp cảnh này chỉ trong vài tuần hay vài tháng gần đây: bạn giao cho Claude một task lớn, kiểu "refactor checkout flow". Nó bắt đầu làm một loạt thứ, rồi 10 phút sau bạn quay lại và tự hỏi "ơ, nãy giờ tới đâu rồi nhỉ?". Bạn bắt đầu cuộn qua cả đống chat và nhận ra mình chẳng biết chuyện gì đang xảy ra (video đăng ngày 25/09/2026).

Thế là bạn ngây thơ ngồi chờ nó làm xong rồi báo cáo. Bạn đọc báo cáo mà không hiểu chuyện gì đang diễn ra, lại hỏi nó đúng câu đó lần nữa, và giờ lại phải chờ thêm một khoảng thời gian dài để nó làm xong.

Thay vào đó, hãy song song hoá việc này bằng cách hỏi câu bên lề với /btw. Theo Nick (video đăng ngày 25/09/2026), bất cứ khi nào Claude đang làm việc, bạn chỉ cần gõ /btw rồi hỏi, chẳng hạn "cái này nghĩa là gì?", và nó sẽ trả lời bạn ngay trong khi vẫn đang làm việc ở session kia.

Anh đưa hai lợi ích. Thứ nhất, nó không làm bẩn main context bằng những câu hỏi mang tính học hỏi hay hỏi thông tin về việc bạn đang cố làm. Thứ hai, nó nhanh hơn và dễ hơn rất nhiều. Vì thế Nick nói mọi người nên dùng /btw 100% ở mọi chỗ có thể (video đăng ngày 25/09/2026).

13. Fan out và fan in: model rẻ đi tìm, model đắt quyết định

Nick chuyển sang mẹo tiếp theo bằng một so sánh cho người chơi Yu-Gi-Oh: anh nói ai chơi Yu-Gi-Oh trong khung chat sẽ hiểu, đây là chuyện bàn tay của Exodia so với cái đầu hay thân của Exodia; còn bàn tay thì, nói thật, anh chẳng mấy bận tâm.

Ý chính là: nếu bạn có một task, gần như lúc nào bạn cũng có thể làm nó tốt hơn bằng cách tìm hiểu thêm về vấn đề. Nghĩa là bạn có thể tìm hiểu xem người khác đã thử những cách nào để giải bài toán đó, đọc hết các paper về chủ đề, lướt qua một loạt blog hay Reddit để xác định: rốt cuộc mọi người đã thử ném những gì vào bài toán này trước đây? Làm vậy thì chất lượng task tăng đáng kể (video đăng ngày 25/09/2026).

Vấn đề duy nhất là làm toàn bộ việc nghiên cứu đó thường tốn nhiều tiền. Theo Nick (video đăng ngày 25/09/2026), cách tối ưu là trả một ít tiền cho một model thật rẻ để quét không gian tìm kiếm rộng nhất có thể, cho nó fan out (toả ra), mang về cho bạn càng nhiều thông tin càng tốt, vì các model rẻ đó đều có context ngắn và rẻ. Rồi đưa hết cho model mạnh hơn để nó ra quyết định.

Trong trường hợp này, với một Opus 5.5, Opus 6, Fable, hay bất kỳ model nào bạn đang dùng vào lúc xem video (lời Nick, video đăng ngày 25/09/2026), hãy đưa task vào với một câu kiểu như câu anh đọc dưới đây:

Hey, I want a fan out and fan in strategy where you delegate to cheap subagents to find out as much information on XYZ topic as humanly possible, best approaches in (insert current year), things that maybe most other people don't currently do.

And then I also want you to ideate and hypothesize a bunch of approaches to doing this that maybe aren't normally supported in the literature and see if there's anything to support that.

Then I want you to combine that all into a mega prompt for a stronger model, like maybe your successor (Opus, Fable, Mythos, whatever), and then how to make the decision.

Khi làm vậy, theo Nick (video đăng ngày 25/09/2026), bạn có độ phủ rộng hơn, nhanh hơn nhiều, và cũng tốn ít tiền hơn so với để Opus làm hết. Anh nói không thể diễn tả hết mẹo này đã thay đổi căn bản chiến lược prompt của cá nhân anh tới mức nào, và rất khuyên mọi người dùng fan out, fan in ở mọi chỗ có thể.

14. Dọn lại CLAUDE.md

Mẹo "bắt buộc phải có" tiếp theo, theo cách Nick gọi, là thiết lập CLAUDE.md. Anh nói nó giống chuyện context rot: nếu bạn cứ đưa vào những thứ ngớ ngẩn không còn liên quan, như chính anh đã làm.

Anh kể chuyện của chính mình, trong video đăng ngày 25/09/2026: gần đây anh vẫn đưa cho nó các con số doanh thu đã lỗi thời từ vài tháng trước, và nó liên tục đưa ra quyết định cho anh dựa trên những con số cũ đó. Như anh kể, mức chấp nhận rủi ro của anh khi đó thấp hơn nhiều, số tiền anh sẵn sàng bỏ ra để giải quyết vấn đề cũng thấp hơn nhiều. Portfolio của anh lúc đó cũng chưa đầy đủ, nên nó không có những thứ chất lượng cao để gợi ý anh bán cho người khác, vân vân.

Vì thế, anh bảo hãy kiểm tra CLAUDE.md của bạn, kiểm tra ngay bây giờ, dừng video lại nếu cần, và xem lại xem mọi thứ trong đó có thật sự còn liên quan không. Theo anh, không có lý do gì để gửi, hay phí, dù chỉ một ký tự, vừa tốn ngân sách token vừa tốn trí thông minh của Claude. Thông tin duy nhất nên có trong đó là thứ bạn thật sự muốn có (video đăng ngày 25/09/2026).

Cách anh làm: luôn có một phần tóm tắt "cái gì ở đâu", thứ bạn tạo được rất dễ bằng lệnh /init (anh nói "backslash init"). Rồi đưa vào vài sở thích. Trong trường hợp của anh, anh ghi: "đưa tôi đường dẫn file đầy đủ" và "dùng Python". Nó được làm những gì? "Cứ thoải mái làm bất cứ gì trong phạm vi này. Nếu không chắc, hỏi tôi trước, nhưng nói chung tôi tin bạn." Rồi đây là vài thông tin về tôi, đây là vài bài học tôi đã rút ra, vân vân. Như vậy là ổn, theo Nick (video đăng ngày 25/09/2026).

Chỉ cần đảm bảo bạn không đưa vào đúng những thứ bạn từng đưa cho các model đời trước. Theo Nick (video đăng ngày 25/09/2026), mỗi lần model được cập nhật, kể cả cập nhật rất nhỏ, bạn nên làm lại quy trình này để chắc rằng CLAUDE.md và các system prompt nói chung có chất lượng thật cao.

15. Luôn có sẵn một công cụ dự phòng

Tiếp theo: luôn có sẵn một công cụ dự phòng. Theo Nick (video đăng ngày 25/09/2026), đáng tiếc là Claude Code không phải lúc nào cũng tuyệt vời. Có lúc Claude gặp sự cố ngừng hoạt động (outage), có lúc chất lượng dao động, một hệ quả đáng tiếc của kinh tế học model, "tokenomics" và những thứ tương tự.

Anh kể điều anh hay thấy khắp internet: khi Claude Code sập, ai ai cũng lên Twitter hay YouTube kêu "Claude Code sập rồi". Lý do, theo anh, là họ chẳng làm được việc gì cả vì không có phương án dự phòng (video đăng ngày 25/09/2026).

Cách anh làm: anh chạy Claude Code làm công cụ chính, nhưng luôn có một model dự phòng như Codex hoặc một model khác trong cùng thư mục, thường đi kèm một file AGENTS.md hoặc thứ tương tự. Theo cách Nick giải thích (video đăng ngày 25/09/2026), AGENTS.md giống như phiên bản CLAUDE.md của các model khác.

Anh tạo symlink, tức là nối file CLAUDE.md trong thư mục của anh với file AGENTS.md, để nội dung hai file soi gương nhau. Như vậy, mỗi khi Claude cập nhật CLAUDE.md, AGENTS.md cũng được cập nhật theo. Và nếu Claude có lúc sập, anh chỉ việc kéo Codex vào và nói: "Codex, tiếp tục từ chỗ người anh em Claude của bạn bỏ dở". Anh đùa rằng Codex sẽ đáp "Claude à, gã đó dở lắm", nhưng vẫn làm. Nhờ vậy anh chẳng bao giờ thật sự phải chịu cảnh outage (video đăng ngày 25/09/2026).

Dòng ghi chú màu vàng nằm dưới hai file trên bảng vẽ:

When you update this file, update AGENTS.md too.

Nick nói bạn sẽ bất ngờ về số đội lớn mà anh từng làm cùng, những đội ở các công ty tỷ đô, hoàn toàn không có phương án dự phòng hay bất kỳ sự đa dạng model nào (lời anh, video đăng ngày 25/09/2026). Khi Claude Code sập, họ bị trói tay thật sự, và năng suất kinh tế trong công ty dừng hẳn. Anh nhắn: đừng để mình rơi vào cảnh đó.

Anh cũng nói thêm, trong video đăng ngày 25/09/2026, rằng Claude gần đây đã được cập nhật để hiểu cả AGENTS.md. Nên dù anh vẫn khuyên giữ một file CLAUDE.md trong workspace, bạn cũng có thể chỉ cần một file AGENTS.md rồi đổi nóng model bất cứ khi nào Claude cần.

16. Để CLAUDE.md học từ lỗi sai

Mẹo cuối: để Claude học từ lỗi sai và đưa bài học vào CLAUDE.md. Giả sử có một lỗi, chẳng hạn bạn đang thử một API cũ, và mỗi lần Claude thử API cũ đó, nó thất bại. Bạn bảo: "ok, cập nhật CLAUDE.md để lần sau không làm vậy nữa". Nó có thể ghi kiểu "đừng thử lại API cũ" (video đăng ngày 25/09/2026).

Nhưng theo Nick (video đăng ngày 25/09/2026), như vậy là dở. Một lần nữa, bạn đang bảo nó điều không được làm. Thay vì lấp đầy cả file bằng một danh sách những điều nó không được làm, những điều phủ định, hãy đưa cho nó điều khẳng định. Ghi những câu như "gộp các lần đọc file lại" (batch the file reads), giả sử đó là cách giải quyết thật sự cho vấn đề. Đừng chỉ đưa cho nó một đống vấn đề, vì làm vậy trông như học, nhưng không phải. Hãy đưa cả lời giải.

Một cách đơn giản và dễ dàng anh luôn dùng để Claude tự làm việc này là hỏi (video đăng ngày 25/09/2026):

How could you have done that faster, with fewer tokens?

Anh nói mình thường hỏi câu này mỗi lần đưa một skill vào một vòng eval, như đã nói ở phần đầu về những lần gieo xúc xắc may rủi của prompt. Khi làm vậy và đưa tất cả những thứ đó vào CLAUDE.md, cùng với một công cụ như /insights và những thứ tương tự, CLAUDE.md của bạn thường trở thành một cỗ máy thật sự mạnh (video đăng ngày 25/09/2026).

Theo ước tính của Nick (video đăng ngày 25/09/2026), CLAUDE.md của anh chắc tiết kiệm cho anh khoảng ba tới bốn giờ mỗi tuần, chỉ riêng nhờ tất cả những lỗi Claude hay mắc với một nhóm task nhất định mà giờ nó không còn mắc nữa. Ngay cả những chỉ dẫn ở mức cao, kiểu "làm xong thì mở file này lên cho tôi", cũng tiết kiệm cho anh rất nhiều thời gian. Anh nói nếu bạn dùng các terminal tool như Ghostty hay những công cụ tương tự, chỉ dẫn này còn có ích hơn nữa, vì việc điều hướng trong các app đó vốn khá khó.

Nick khép video bằng lời cảm ơn người xem, và hẹn gặp lại ở video sau.