Boris Cherny không còn prompt Claude nữa.
Đó không phải là một câu paraphrase lan truyền. Đó là phát biểu có ghi chép lại của chính anh ấy: "Tôi không còn prompt Claude nữa. Tôi có các loop đang chạy để prompt Claude và tự tìm ra việc cần làm. Việc của tôi là viết loop." Anh ấy đã nói điều này trong nhiều lần xuất hiện công khai, một buổi nói chuyện tại Sequoia, một buổi phỏng vấn với Acquired, Startup School của Y Combinator, và mô hình bên dưới câu nói đó mới chính là chủ đề thực sự của bài viết này. Không phải mẹo vặt. Không phải danh sách tính năng. Mà là cách cụ thể mà người đã xây dựng nên Claude Code thực sự sử dụng nó hàng ngày, được kiểm chứng qua chính những phát biểu công khai của anh ấy thay vì paraphrase gián tiếp.
Đây là phân tích đầy đủ, dựa trên những gì Cherny thực sự đã nói, cộng với các phương pháp thực hành tốt nhất do chính Anthropic ghi lại cho công cụ mà anh ấy đã xây dựng.
Claude Code Chưa Từng Được Thiết Kế Để Trở Thành Một Sản Phẩm
Hiểu cách Cherny sử dụng công cụ này bắt đầu từ việc hiểu nó đến từ đâu, bởi vì nguồn gốc giải thích triết lý, và đó là một câu chuyện thú vị hơn hầu hết những người đang dùng công cụ này hôm nay nhận ra.
Claude Code bắt đầu vào năm 2021 như một dự án nghiên cứu về an toàn AI (AI safety alignment), không phải một sản phẩm. Ban đầu là một extension VS Code thô sơ, sau đó là một công cụ CLI nội bộ tên là clide, được dùng bên trong Anthropic suốt nhiều năm trước khi bất kỳ ai bên ngoài công ty nghe đến nó. Cherny tham gia dự án vào tháng 9 năm 2024 và xây dựng lại phần lõi trong một sprint hai tuần vào tháng 12 năm đó. Bản phát hành công khai vào tháng 2 năm 2025 diễn ra lặng lẽ, không có nhiều phô trương, được đón nhận bằng sự hờ hững hơn là phấn khích. Sau đó Claude 4 ra mắt, và việc áp dụng bùng nổ gần như chỉ sau một đêm.
Đánh giá của riêng anh ấy về vị trí hiện tại của công cụ, được nói thẳng: "Chúng tôi mới hoàn thành được 1% thôi."
Cách nhìn đó quan trọng đối với cách bạn nên tiếp cận việc sử dụng nó. Cherny không mô tả một sản phẩm hoàn thiện với một mô hình sử dụng đúng đắn cố định. Anh ấy mô tả một thứ vẫn đang được xây dựng lại một cách tích cực, bởi một đội ngũ dùng chính công cụ này để xây dựng công cụ. Claude Code đã được viết lại nhiều lần bằng chính Claude Code, một vòng lặp tự cải thiện có trước cả khi thuật ngữ "loop engineering" trở thành một cụm từ được ai đó sử dụng công khai. Điều này đáng để dừng lại suy ngẫm một chút, vì nó giải thích một điều khiến nhiều người dùng mới bối rối: tại sao cách "đúng" để sử dụng công cụ này dường như liên tục thay đổi. Đó không phải sự mâu thuẫn. Đó là một công cụ mà chính những người tạo ra nó vẫn đang chủ động khám phá khả năng thực sự của nó, trong thời gian thực, dùng chính công cụ đó để tìm hiểu.
Nhiều năm được dùng như một công cụ nghiên cứu nội bộ trước khi trở thành sản phẩm cũng giải thích tại sao phần lớn triết lý dưới đây đọc có vẻ đầy chủ kiến khác thường đối với một phần mềm dành cho lập trình viên. Hầu hết các công cụ tích lũy tính năng để phục vụ một lượng người dùng bên ngoài rộng lớn với những nhu cầu cạnh tranh nhau ngay từ ngày đầu. Claude Code tích lũy triết lý trước tiên, bên trong một đội ngũ nhỏ đang giải quyết các vấn đề của chính họ, trước khi nó phải phục vụ quy trình làm việc của bất kỳ ai khác. Lịch sử đó chính là lý do tại sao việc hiểu các mô hình sử dụng cụ thể của Cherny, thay vì những lời khuyên "công cụ AI coding" chung chung, xứng đáng với thời gian cần bỏ ra để thực sự thấm nhuần.
Sự Chuyển Dịch Cốt Lõi: Từ Prompting Đến Thiết Kế Loop
Điều quan trọng nhất mà Cherny đã nói công khai về việc thực sự sử dụng Claude Code là câu nói về loop ở trên, và nó đáng để phân tích kỹ ý nghĩa thực tế của nó, không chỉ là một câu nói hay để trích dẫn.
Một prompt là một chỉ dẫn đơn lẻ, được gửi một lần, nhận câu trả lời một lần. Một loop là một hệ thống: nó prompt Claude, đánh giá những gì nhận được, quyết định bước tiếp theo, và lặp lại, không cần con người ngồi ở giữa mỗi chu kỳ. Mô tả công việc đã được xác nhận của Cherny, "việc của tôi là viết loop", nghĩa là anh ấy dành thời gian để thiết kế các hệ thống tạo ra và đánh giá prompt, chứ không phải tự gõ prompt từng lượt.
Quy trình làm việc hàng ngày đã được xác nhận của anh ấy phản ánh trực tiếp điều này. Điện thoại là giao diện chính, không phải bàn phím laptop. Năm đến mười phiên hoạt động chạy cùng lúc, mỗi phiên có khả năng tạo ra các sub-agent, đôi khi vài trăm agent cùng lúc, đôi khi vài nghìn agent qua đêm cho các công việc sâu hơn. Hàng chục loop chạy liên tục trong nền, trông chừng pull request, giữ cho quy trình tích hợp liên tục (CI) luôn khỏe mạnh, phân cụm phản hồi theo lịch định kỳ. Các quy trình này vẫn tiếp tục tồn tại phía máy chủ ngay cả khi laptop của anh ấy đóng lại.
Bài học thực tế cho bất kỳ ai dùng Claude Code hàng ngày: giới hạn trên của những gì công cụ có thể làm không bị đặt bởi một prompt duy nhất tốt đến đâu. Nó được đặt bởi cách bạn thiết kế hệ thống xung quanh các chu kỳ prompting, kiểm tra, và thử lại tự động lặp lại.
Điều Gì Thực Sự Đã Thay Đổi Trong System Prompt, Và Tại Sao Nó Quan Trọng
Cherny cũng đã nói trực tiếp về một quyết định kỹ thuật cụ thể, bộc lộ cách anh ấy nghĩ về việc chỉ dẫn Claude nói chung: "Chúng tôi đã loại bỏ ~80% system prompt của Claude Code cho các mô hình mới nhất, đây là những gì chúng tôi học được về việc viết system prompt."
Cú cắt đó xảy ra cụ thể với thế hệ Opus 4.8, giảm system prompt từ khoảng 15.000 ký tự xuống còn khoảng 4.500, không có sự sụt giảm nào đo lường được trên các bài đánh giá lập trình. Bài học đằng sau nó, theo hướng dẫn về context-engineering của chính Anthropic, là các danh sách quy tắc cứng nhắc, đầy đủ không còn cần thiết khi một mô hình đủ năng lực để thực sự vận dụng phán đoán. Các quy tắc trở thành các quyết định dựa trên phán đoán. Các ví dụ sử dụng công cụ được thay thế bằng các giao diện được thiết kế để tự giải thích. Context toàn diện cung cấp từ trước được thay thế bằng progressive disclosure, thông tin chỉ được hiển thị khi một tình huống cụ thể thực sự cần đến, thay vì được nạp vào mọi phiên làm việc theo mặc định.
Một sắc thái đáng nêu một cách trung thực, vì nó làm phức tạp phiên bản đơn giản của câu chuyện này: khi Opus 5 ra mắt, các bài kiểm tra độc lập từ cộng đồng phát triển phát hiện ra system prompt thực tế của nó dài hơn khoảng 72% so với Opus 4.8. Đó không phải là sự mâu thuẫn với bài học trên, mà là một phiên bản sâu hơn của nó. Prompt thu nhỏ lại về khối lượng chỉ dẫn cứng nhắc, rồi phình to hơn với các tham chiếu phong phú và cụ thể hơn, các ví dụ có lời giải, bộ test, thang đánh giá, loại context mà một mô hình thực sự có năng lực hơn có thể tận dụng tốt. Bài học không phải là "ngắn hơn luôn luôn tốt hơn." Mà là khối lượng chỉ dẫn nên bám theo điều mô hình cụ thể thực sự cần để vận dụng phán đoán tốt, không phải một mục tiêu cố định theo bất kỳ hướng nào.
Viết CLAUDE.md Theo Cách Mà Chính Các Đội Ngũ Của Anthropic Làm
Điều này kết nối trực tiếp với cách bạn nên cấu trúc các chỉ dẫn cấp dự án của mình, và tài liệu chính thức của Anthropic nói rõ mô hình tinh thần cần dùng: hãy nghĩ về Claude như một nhân viên mới cực kỳ thông minh nhưng bị mất trí nhớ, cần những chỉ dẫn tường minh.
Ý nghĩa thực tế của cách nhìn đó. Thông minh nghĩa là bạn không cần giải thích quá kỹ năng lực chung, nó đã có sẵn. Mới nghĩa là không có kiến thức tích lũy về lịch sử hay quy ước cụ thể của dự án bạn. Mất trí nhớ nghĩa là mỗi phiên làm việc bắt đầu từ con số không, CLAUDE.md là thứ duy nhất đáng tin cậy để mang context qua các phiên.
Hướng dẫn được ghi lại của Anthropic nhắm đến việc giữ file này dưới 200 dòng, với một số đội ngũ kỷ luật nhất chạy ở mức thấp đến 60. Bài kiểm tra để xác định điều gì nên nằm trong file: điều này có thực sự liên quan đến gần như mọi phiên làm việc, hay chỉ với một phần hẹp, tình huống cụ thể của công việc? Những thứ phổ quát, lệnh build, quy tắc về phong cách bất di bất dịch, kỳ vọng về test, các rào chắn thực sự, thuộc về file gốc. Bất cứ thứ gì hẹp hơn thuộc về một file được import, được kéo vào context chỉ khi công việc cụ thể của phiên thực sự cần, sử dụng cú pháp import @path/to/file mà công cụ hỗ trợ trực tiếp.
Đối với những chỉ dẫn thực sự không thể bỏ qua, cách thực hành nội bộ của Anthropic dùng các dấu nhấn mạnh tường minh, "IMPORTANT" hay "YOU MUST", được dành riêng cho một số ít quy tắc mà chi phí nếu Claude bỏ lỡ là thực sự cao. Đánh dấu mọi thứ theo cách này phá hỏng hoàn toàn mục đích, vì nó ngừng hoạt động như một tín hiệu ngay khi được áp dụng một cách bừa bãi.
Plan Mode: Hiểu Trước Khi Hành Động
Một mô hình hành vi cụ thể đáng để đưa vào cách bạn thực sự vận hành công cụ: cho Claude lập kế hoạch trước khi thực thi, thay vì nhảy thẳng vào thay đổi.
Đây không chỉ là một nút bật/tắt tính năng, nó phản ánh một sự thay đổi thực sự mà chính các tài liệu của Anthropic mô tả: các mô hình mới hơn lập kế hoạch đúng mà không cần sự dẫn dắt nặng nề từ trước như những thế hệ cũ, đến mức một số đội ngũ báo cáo rằng họ không còn cần ép một bước plan mode tường minh cho mọi tác vụ, vì khả năng suy luận mặc định của mô hình đã tạo ra một kế hoạch mạch lạc trước khi hành động. Dù vậy, đối với những thay đổi thực sự phức tạp, nhiều file, việc yêu cầu tường minh một kế hoạch trước tiên, và xem xét nó trước khi phê duyệt thực thi, vẫn là một điểm kiểm tra hữu ích có ý nghĩa, bắt được một yêu cầu bị hiểu sai trước khi nó lan truyền qua hàng chục lần sửa file thay vì sau đó.
Sub-Agent Và Công Việc Song Song
Quy trình đã được xác nhận của Cherny, chạy hàng trăm, đôi khi hàng nghìn sub-agent trong một phiên làm việc duy nhất, chỉ ra một năng lực cấu trúc đáng để hiểu và sử dụng một cách có chủ đích thay vì tình cờ.
Một agent chính có thể phân rã một tác vụ phức tạp thành các phần nhỏ hơn và triển khai các sub-agent để thực thi chúng một cách độc lập, mỗi agent làm việc trong context riêng của nó thay vì tất cả cạnh tranh không gian trong một cuộc hội thoại liên tục. Điều này phục vụ hai mục đích cùng lúc. Nó cho phép công việc tràn khỏi một context window duy nhất chạy trên nhiều context nhỏ hơn. Và nó thêm một lớp xác minh thực sự, vì một sub-agent xem xét đầu ra của một agent khác đang kiểm tra công việc mà nó không tự tạo ra, điều này về mặt cấu trúc đáng tin cậy hơn một agent tự chấm điểm bài của chính mình trong cùng hơi thở đã tạo ra nó.
Riêng cho công việc song song, git worktrees cho phép nhiều phiên làm việc trên các nhánh hoặc thư mục riêng biệt đồng thời mà không để các thay đổi đang dang dở của phiên này làm gián đoạn phiên khác. Đây là cơ sở hạ tầng cơ học bên dưới việc chạy nhiều loop đồng thời như cách Cherny mô tả anh ấy làm cá nhân, không phải một agent đơn lẻ làm việc nhanh hơn, mà là nhiều agent làm việc trên những phần công việc thực sự riêng biệt cùng một lúc.
Quyết Định grep: Một Nghiên Cứu Điển Hình Về Sự Đơn Giản Hơn Sự Tinh Vi
Một quyết định kỹ thuật cụ thể, được ghi chép rõ ràng từ đội ngũ của Cherny minh họa một triết lý rộng hơn đáng để thấm nhuần. Claude Code đã bỏ vector search và embeddings cho tìm kiếm codebase để chuyển sang grep và glob thuần túy. Lời của chính anh ấy về kết quả: "vượt trội mọi thứ. Vượt xa."
Bài học khái quát hóa qua quyết định cụ thể này. Một giải pháp nghe có vẻ tinh vi hơn, semantic vector search, không tự động tốt hơn một giải pháp đơn giản hơn, grep, nếu giải pháp đơn giản hơn thực sự khớp tốt với vấn đề. Codebase có cú pháp chính xác, tên hàm chính xác, đường dẫn import chính xác, loại khớp chính xác, theo nghĩa đen mà grep làm rất giỏi và một phép khớp ngữ nghĩa mờ có thể thực sự làm suy yếu bằng cách đưa ra các kết quả có vẻ hợp lý nhưng sai.
Bài học thực tế cho cách bạn cấu hình quy trình làm việc của riêng mình: đừng mặc định chọn công cụ hoặc kiến trúc nghe có vẻ phức tạp hơn chỉ vì giả định rằng sự phức tạp hàm ý năng lực. Hãy test lựa chọn đơn giản với trường hợp sử dụng thực tế của bạn trước. Thường thì nó thắng, và ngay cả khi không thắng, bạn đã xác nhận rằng cách tiếp cận phức tạp hơn xứng đáng có chỗ đứng chứ không phải được mặc định công nhận.
Không Bao Giờ Để Một Agent Tự Chấm Điểm Công Việc Của Chính Nó
Một nguyên tắc riêng biệt, đã được xác nhận từ hoạt động harness engineering của chính Anthropic, liên quan trực tiếp đến cách bạn nên cấu trúc bất kỳ bước xác minh nào trong quy trình Claude Code của mình: việc tạo ra và đánh giá nên diễn ra trong các vai trò thực sự tách biệt, vì một mô hình xem xét đầu ra của chính nó trong cùng hơi thở đã tạo ra nó có xu hướng nghiêng về tích cực, ngay cả khi một người xem xét là con người sẽ phát hiện ra lỗi ngay lập tức.
Thực tế, điều này nghĩa là agent viết code không nên là lượt kiểm tra quyết định liệu code đó có đủ tốt để phát hành hay không. Một bước đánh giá riêng biệt, lý tưởng nhất là có quyền truy cập vào thứ mà agent tạo ra không có, kết quả test suite thực tế, tài liệu yêu cầu gốc, sẽ bắt được những gì mà tự đánh giá bỏ sót. Đây cũng chính là nguyên tắc đằng sau mô hình xác minh sub-agent ở trên, được áp dụng như một kỷ luật chung chứ không phải một tính năng cụ thể.
Quản Lý Effort Và Context
Đối với bất kỳ ai chạy các phiên làm việc dài hơn, đòi hỏi nhiều hơn, việc hiểu cách truyền tín hiệu mức effort trực tiếp là quan trọng. Đưa "ultrathink" vào một prompt báo hiệu độ sâu suy luận tối đa cho phản hồi cụ thể đó mà không thay đổi các cài đặt phiên rộng hơn. Đối với việc điều phối quy trình tự động ở cấp phiên, đặt mức effort ở bậc cao nhất kết hợp suy luận sâu với việc tự động phân rã tác vụ trong suốt phiên, mặc dù điều này đòi hỏi một mô hình thực sự hỗ trợ bậc effort đó, không phải mọi mô hình trong danh sách đều làm được.
Quản lý context tự nó xứng đáng được chú ý một cách có chủ đích trong các phiên dài. Khi một phiên chạy lâu hơn, context tích lũy có thể bắt đầu pha loãng tín hiệu của những gì thực sự quan trọng ngay lúc này, cùng một vấn đề mà các file CLAUDE.md phình to tạo ra, chỉ là diễn ra động trong một cuộc hội thoại đơn thay vì tĩnh trong một file. Định kỳ bắt đầu một phiên mới cho một giai đoạn công việc thực sự mới, thay vì kéo dài một cuộc hội thoại vô thời hạn, là một kỷ luật thực tế, đáng áp dụng thay vì giả định rằng nhiều context hơn luôn luôn tốt hơn.
Một Ví Dụ Làm Việc Cụ Thể: Áp Dụng Điều Này Vào Một Tác Vụ Thực Tế
Để làm cho tất cả những điều trên trở nên cụ thể thay vì trừu tượng, đây là cách các nguyên tắc này thực sự kết hợp trên một tác vụ thực tế, phổ biến: thêm một tính năng mới vào một codebase hiện có với độ phức tạp hợp lý, vài file liên kết với nhau, một số test hiện có, một thay đổi không tầm thường nhưng cũng không kỳ lạ.
Bắt đầu với CLAUDE.md đã có sẵn, ngắn gọn, phổ quát, các lệnh build và test, các quy tắc phong cách bất di bất dịch, không có gì tình huống làm rối nó. Điều này nghĩa là phiên làm việc bắt đầu với context thực sự, liên quan được nạp tự động, mà bạn không cần giải thích lại các quy ước dự án từ con số không.
Thay vì viết một prompt dài, đơn lẻ, đầy hy vọng mô tả toàn bộ tính năng một cách chi tiết kiệt cùng, hãy mô tả mục tiêu và để khả năng lập kế hoạch của mô hình tự xử lý việc phân rã, tin tưởng vào triết lý giảm khung đỡ (reduced-scaffolding) từ phần thảo luận về system prompt ở trên. Đối với một tác vụ có quy mô này, việc yêu cầu tường minh một kế hoạch trước là đáng giá với bước thêm này, vì một yêu cầu bị hiểu sai bắt được ở đây chỉ tốn hai phút sửa chữa thay vì một giờ gỡ rối các thay đổi trên nhiều file sau đó.
Khi kế hoạch trông ổn, hãy để việc thực thi diễn ra. Nếu tác vụ tự nhiên tách thành các phần thực sự độc lập, ví dụ cập nhật một data model và riêng biệt cập nhật UI mà nó phục vụ, đó là ứng viên tự nhiên cho việc phân rã sub-agent, mỗi phần làm việc trong context riêng thay vì tất cả chen chúc trong một cuộc hội thoại liên tục duy nhất.
Trước khi coi kết quả là hoàn thành, hãy chạy một lượt xác minh riêng biệt thay vì tin vào báo cáo tự thân của agent thực thi rằng mọi thứ đều hoạt động. Điều này có thể đơn giản như một phiên mới, hoặc một sub-agent với quyền chỉ đọc, kiểm tra kết quả test thực tế và diff so với kế hoạch ban đầu, không chỉ chấp nhận một câu "xong rồi" đầy tự tin từ cùng context đã viết code.
Hãy chú ý điều gì vắng mặt trong phần minh họa này. Không có công cụ kỳ lạ
