Thay prompt engineering bằng role engineering

1. Từ AI là tool sang AI là một staff member thường trực

Nick Saraev mở video bằng một chi tiết về Boris Cherny, người tạo ra Claude Code. Theo Nick (video đăng ngày 23/10/2026), Boris giờ dùng Claude Code chủ yếu qua giao diện Slack, chứ không qua một chat tool riêng hay qua terminal.

Nick nói người dùng phổ thông cũng đã thấy cú đẩy này qua các app như GrokBot, Muse, Dots và những cái tương tự (theo video đăng ngày 23/10/2026). Với anh, thay đổi trong sáu tháng qua về cơ bản là chuyển từ AI như một tool sang AI như một staff member thường trực (persistent staff member).

Anh nói thẳng: chỉ khoảng một năm rưỡi trước, có rất nhiều chuyện nhảm (anh dùng chữ "bullshit") về kiểu "AI employees đang điều hành business của tôi". Nhưng theo Nick, tính đến video đăng ngày 23/10/2026, chúng ta thật sự đã tới điểm đó rồi. Vì vậy anh thấy đáng để nói một chút về cách chuyển từ việc chủ yếu là prompt AI sang việc quản lý (managing) nó.

2. Role engineering, và những session chạy hàng tuần

Nick kể anh đã dành bảy năm qua làm việc với và xây các hệ thống AI, và nói anh đã kiếm được "nhiều triệu đô" từ đó (lời anh tự nói trong video đăng ngày 23/10/2026). Hôm nay anh muốn nói về cú chuyển đổi kia, và về một thứ anh gọi là role engineering.

Đi từ tool sang staff member thường trực nghĩa là gì? Nick dẫn lại: Boris Cherny, cùng khá nhiều nhân viên khác ở Anthropic, đã nói công khai nhiều lần rằng họ làm những việc như đưa Claude một prompt rồi để nó chạy theo đúng nghĩa đen hàng tuần ở background. Trong lúc đó họ tự ghé vào xem tiến độ, quản lý nó, rồi chỉnh dần (anh dùng chữ "massaging") cho tới khi ra kết quả cuối (theo Nick, video đăng ngày 23/10/2026).

Theo cách Nick mô tả (video đăng ngày 23/10/2026), họ không ngồi cạnh Claude suốt thời gian đó, cũng không chờ từng chữ nó nói ra. Họ chỉ đơn giản là ở trong tổ chức, kiểu như làm cùng văn phòng với Claude. Thỉnh thoảng Claude đi tới chỗ họ và nói "good", họ đáp "good", rồi ai làm việc nấy.

3. Code được merge ở Anthropic, và chuyện cách diễn đạt prompt

Nick nói chính vì cách làm này mà bên trong Anthropic, "chỉ vài ngày trước", AI đã viết hơn 80% toàn bộ code họ merge, qua những context session cực dài như anh vừa tả (lời Nick, video đăng ngày 23/10/2026). Trên màn hình, con số được ghi kèm mốc khác: "More than 80% authored by Claude, as of May 2026".

Trước thay đổi này, kỹ năng chính là cách diễn đạt yêu cầu. Đó chính là prompt engineering. Nick kể (video đăng ngày 23/10/2026) người ta từng dùng rất nhiều từ ngữ cầu kỳ và một loạt hệ thống "rất ngầu" để sinh ra những prompt hay, giúp mọi người khiến AI làm đúng điều họ muốn.

Còn bây giờ, theo Nick (video đăng ngày 23/10/2026), vì AI đã là một generalist và có năng lực tới vậy, ý tưởng là không phải làm những thứ đó nữa. Cũng như bạn không phải chọn từng chữ khi giao việc cho một nhân viên, bạn chỉ đưa họ một bản phác thảo sơ bộ rồi tin rằng họ sẽ làm đúng. Anh nói điều đó giống một cách đáng ngạc nhiên với cách bạn dùng Claude ở thời điểm video.

4. Đối xử với Claude như một nhân viên mới rất giỏi

Vậy làm thế nào trong thực tế? Bước đầu tiên Nick đưa ra: đọc bộ hướng dẫn và khuyến nghị mới của Anthropic. Anh trích, họ viết đúng là phải đối xử với Claude như một nhân viên mới rất giỏi nhưng chưa có context về các norm và workflow của bạn. Trang "Prompting best practices" trong docs của Claude ghi nguyên câu "Think of Claude as a brilliant but new employee who lacks context on your norms and workflows" (đọc ngày 23/10/2026).

Nick nói thêm, với ai chưa từng tuyển người: anh đã làm việc đó vài lần. Theo anh, các khuyến nghị kia về cơ bản có nghĩa là: đưa Claude một goal; đưa nó toàn bộ background cần thiết để hiểu goal đó là gì, nó ra đời thế nào và vì sao bạn muốn nó; rồi đưa một ví dụ về một sản phẩm thật sự chất lượng cao. Cộng thêm, tất nhiên, những lỗi bạn muốn tránh, và vân vân (theo Nick, video đăng ngày 23/10/2026).

5. SMART goals: chữ "measurable" là quan trọng nhất

Làm phần goal thế nào? Nick trả lời: dùng thứ gọi là SMART goals. Theo anh (video đăng ngày 23/10/2026), đó chính là framework mà các manager đã dùng để giao việc cho nhân viên trong tổ chức suốt khoảng nửa thế kỷ. SMART là viết tắt của specific, measurable, attainable, relevant và time-bound. Task phải có đủ cả năm thuộc tính đó thì mới có nghĩa.

Nick nói, nhìn chung với một agent, chữ "measurable" là phần quan trọng nhất (theo Nick, video đăng ngày 23/10/2026). Nếu task không đo được, hay còn gọi là verifiable, thì agent không thể tự kiểm tra công việc của mình. Nó không thật sự biết được thứ nó vừa làm có đúng là thứ được kỳ vọng hay không.

Ví dụ của anh (video đăng ngày 23/10/2026): nếu bạn giao cho agent một task kiểu "bạn làm website của tôi tốt hơn được không?", đó không phải một goal đo được, vì agent không có cách nào thật sự để đặt nó vào một khung cụ thể. Nhưng nếu bạn nói "này, bạn làm cho homepage load dưới hai giây trên màn hình iPhone được không?", thì giờ bạn có một goal rất rõ ràng và đo được. Đó là phần goal.

6. Background context: một knowledge base 50.000 record

Đưa background context thế nào? Nick nói bạn dùng một thứ như knowledge base. Anh vừa làm một video về chủ đề này vài ngày trước. Về cơ bản, anh có một knowledge base chất lượng rất cao, lưu hơn 50.000 record của chính anh (theo Nick, video đăng ngày 23/10/2026).

Trong đó có toàn bộ email, toàn bộ lời thoại của các video (như video bạn đang xem), toàn bộ các session AI anh từng làm, tức mọi cuộc trò chuyện anh từng có với Claude, ChatGPT và các model khác. Ngoài ra còn một loạt thứ khác như GitHub commit log, toàn bộ repo của anh, "bất cứ thứ gì bạn muốn": knowledge base đó đều có (theo Nick, video đăng ngày 23/10/2026).

Ý tưởng là anh không phải dựng lại context đó mỗi lần, như cách bạn từng phải làm với context engineering, thứ Nick gọi là người kế nhiệm của prompt engineering. Theo anh (video đăng ngày 23/10/2026), nó lúc nào cũng có sẵn mọi thứ cần để hiểu động cơ và mục tiêu của anh.

7. Ví dụ về việc làm tốt: tự làm ít nhất một lần

Cuối cùng, bạn chỉ cần đưa cho nó vài ví dụ về những sản phẩm bạn thật sự thích. Điều người ta không nhận ra, theo Nick (video đăng ngày 23/10/2026), là bạn không thể chỉ bảo AI "làm thật tốt vào", vì nó, một lần nữa, không hiểu "tốt" là gì.

Bạn cần đưa nó một thứ để so sánh, hay một thứ để đo theo. Điều đó có nghĩa, tiếc là, bạn gần như phải tự làm việc đó ít nhất một lần. Ít nhất thì Nick rất khuyên bạn tự làm nó ít nhất một lần (video đăng ngày 23/10/2026).

Anh nói (video đăng ngày 23/10/2026) khoảng thời gian đó có lẽ là thời gian giá trị nhất bạn từng bỏ ra cho bất cứ việc gì. Và nếu làm tốt, nhiều khả năng đó là lần cuối cùng bạn phải tự làm task ấy. Làm xong, bạn chỉ việc đưa ví dụ cho AI và nói: "này, tôi muốn bạn build nó y như thế này".

Nick nói nếu bạn làm việc này một cách thông minh, nó sẽ làm rất tốt (theo Nick, video đăng ngày 23/10/2026). Anh khẳng định đây đúng là mũi nhọn (cutting edge) của việc dùng AI cho knowledge work. Anh nói anh ước gì mình đang phóng đại, ước gì mình đang bịa ra chuyện này.

Chỉ một hai năm trước, anh từng chế giễu những ai gợi ý kiểu này: "cái quái gì vậy, bạn thật sự điều hành cả một công ty toàn 'AI agents' à?". Mấy thứ đó lúc ấy, theo lời anh, còn không trả lời nổi một email mà không chèn vào 4.000 cái em dash. Vậy mà theo Nick, tính đến video đăng ngày 23/10/2026, chúng ta thật sự đã tới đó.

8. Không có công thức bí mật: connector và auth

Nick nói không có "secret sauce" nào cả (video đăng ngày 23/10/2026). Bạn chỉ việc đối xử với nó như với một nhân viên trong công ty, rồi đảm bảo nó có quyền truy cập mọi thứ, một lần nữa qua một thứ như knowledge base, chưa kể toàn bộ connector nó cần tới các dịch vụ phần mềm khác nhau.

Theo Nick (video đăng ngày 23/10/2026), đó chính là những gì các tool như GrokBot, Dots, Muse và các tool tương tự làm cho bạn: chúng lo toàn bộ phần auth và những thứ kiểu đó ở background.

9. Prompt thật của người ở Anthropic

"Nếu bạn không tin tôi", Nick đưa ra một danh sách ví dụ về nhân viên Anthropic và những người khác thật sự dùng cách này để prompt Claude làm những việc rất hay cho họ (các ví dụ dưới đây do Nick thuật lại trong video đăng ngày 23/10/2026).

Ví dụ thứ nhất, theo Nick kể trong video đăng ngày 23/10/2026: Boris Cherny muốn viết lại app Claude desktop bằng Swift, một ngôn ngữ lập trình khác. Theo Nick, prompt của anh ấy đúng nghĩa đen chỉ là: viết lại Electron app bằng Swift, chạy Electron app trong máy ảo Mac, chụp màn hình rồi so từng pixel với bản Swift, và đừng dừng cho tới khi xong. Nick nói việc đó chạy hơn hai tuần. Trang phỏng vấn trên màn hình ghi prompt như sau, và Boris kể lúc đó nó vẫn đang chạy, "a little over two weeks", khoảng 14, 15 ngày:

I want you to rewrite the Electron app in Swift. I want you to run the Electron app in the Mac virtual machine, screenshot it, and then look pixel by pixel. Compare it to the Swift version. Don't stop until you're done.

Ví dụ thứ hai, cũng theo Nick (video đăng ngày 23/10/2026): một lần Claude tự nhảy vào một thread Slack, rồi kéo dữ liệu từ một loạt tool khác nhau gộp lại thành một câu trả lời. Boris thì đúng nghĩa đen chỉ nói: "can you make some designs? Just mock it up." Nick hỏi lại người xem: hãy nói đó không phải câu bạn sẽ nói với một nhân viên đi.

Ví dụ thứ ba, theo Nick (video đăng ngày 23/10/2026): Nicholas Carlini, một researcher ở Anthropic, cho 16 Claude agent làm cùng anh để build một C compiler. Theo Nick, anh ấy đúng nghĩa đen chỉ nói "keep going until it's perfect", và một lần nữa nó chạy khoảng hai tuần.

Theo Nick (video đăng ngày 23/10/2026), chuyện này không quá khó hình dung. Rốt cuộc, Claude là một staff member khác trong tổ chức của bạn. Chừng nào bạn đối xử với nó như thế, và tất nhiên tôn trọng Claude như tôn trọng bất kỳ nhân viên nào khác, các bạn sẽ làm được rất nhiều việc.

10. Train nó: chạy năm đến mười lần rồi góp ý

Khi Claude đã tới mức làm được những việc như vậy cho bạn, theo Nick (video đăng ngày 23/10/2026) việc bạn cần làm là train nó. Đừng chỉ cho Claude làm một việc một lần. Hãy cho Claude làm việc đó năm hoặc mười lần. Cũng như bạn đánh giá output của một nhân viên, bạn sẽ phải đánh giá output của Claude.

Anh nói thẳng việc này sẽ tốn rất nhiều token, và có lẽ cũng tốn thời gian hơn bạn muốn một chút, nhưng nó thật sự quan trọng, ít nhất là ở thời điểm video (23/10/2026). Từ đó, việc của bạn đúng nghĩa đen chỉ là xem lại tất cả output nó đưa ra, lấy mức trung bình, rồi đưa cho nó một loạt cách để cải thiện.

Đừng dừng ở đó, Nick nói tiếp trong video đăng ngày 23/10/2026. Hãy nói: "Tôi thấy ở task A bạn làm thế này, tôi không thích lắm. Tôi thấy ở task B bạn thiếu X, Y, Z, lần chạy sau mình nên sửa. Này, ở task C bạn đang làm blah blah blah." Gom thành một danh sách lớn các thay đổi có thể hành động được, đưa cho Claude, rồi cho nó chạy trong một vòng lặp cho tới khi sửa hết.

11. SOP, một nửa ngày làm việc, và những bản nâng cấp

"Xin chúc mừng", Nick nói: giờ bạn đã có những SOP được thể chế hoá, về cơ bản là cùng loại thứ vẫn được coi là "con ngỗng đẻ trứng vàng" trong quản lý và đào tạo. Có điều giờ chúng đã được viết ra ở một định dạng mà bạn có thể đưa cho bất kỳ agent nào trong năm hay mười năm tới, để nó lặp lại đúng những gì bạn vừa làm (theo Nick, video đăng ngày 23/10/2026).

Nick nói việc này hiện chiếm khoảng 50% cả ngày của anh, tính đến video đăng ngày 23/10/2026, và anh "không nói xạo". Anh dành cả ngày để nghĩ ra các format khác nhau cho content, các implementation, các hệ thống anh muốn build và vân vân. Anh giao những việc đó cho một loạt Claude agent và sub-agent, rồi chỉ ngồi đó góp ý xem anh sẽ cải thiện X, Y, Z ra sao. Theo một nghĩa nào đó, anh nói, anh đang train nó nhiều ngang với việc nó đang train anh.

Làm xong, theo Nick (video đăng ngày 23/10/2026), bạn đúng nghĩa đen được nâng cấp miễn phí cho "nhân viên" của mình gần như suốt đời. Bạn biết nhân viên thường giỏi hơn, có năng lực hơn một chút theo thời gian khi họ học cách tổ chức vận hành chứ? Hãy tưởng tượng điều đó nhân một nghìn lần.

Nick dự đoán (video đăng ngày 23/10/2026): khi Opus 5.5 lên thành Opus 6, Opus sẽ không chỉ giỏi hơn 10%, mà sẽ giỏi hơn 100% ở rất nhiều task. Tỷ lệ lỗi sẽ rơi xuyên qua cả tầng hầm của Trái Đất, theo cách nói của anh.

12. Benchmark mỗi model mới bằng chính danh sách task của bạn

Cách đơn giản nhất để đo và đánh giá chuyện này theo thời gian, theo Nick (video đăng ngày 23/10/2026), là lấy danh sách các task bạn cho nó làm đều đặn, lưu nó ở đâu đó. Lần sau có model mới ra, bạn chỉ việc bench hai model với nhau.

Khi đó, theo Nick (video đăng ngày 23/10/2026), bạn sẽ nói được model của mình làm tốt hơn bao nhiêu, và cũng sẽ làm được những việc như so sánh chi phí.

13. Mặt trái: chi phí token

Nói tới chi phí, Nick chuyển sang mặt trái. Theo số anh tự nêu trong video đăng ngày 23/10/2026, mới hôm trước anh đã tiêu khoảng 2.500 đô tiền token cho một loạt session Claude. Nếu ngoại suy với 20 ngày làm việc mỗi tháng, đó là khoảng 50.000 đô một tháng, hay hơn nửa triệu đô một năm.

Anh nói mình có lẽ là một trong những trường hợp cực đoan, vì anh tự coi mình là người cực kỳ AI-native và thật sự không muốn tuyển bất kỳ ai mà anh không bắt buộc phải tuyển. Nhưng theo Nick (video đăng ngày 23/10/2026), chi phí có thể đội lên khá lớn, nhất là khi bạn muốn việc xong nhanh và dùng giá API.

14. Quản lý chi phí: đúng model, prompt cache, batch và hoá đơn

Vì thế lớp tiếp theo, giống như với nhân viên, là bạn phải định kỳ audit hiệu suất của chúng rồi làm cost management. Nick nói có nhiều cách, và đây là vài cách được khuyến nghị ở thời điểm video (23/10/2026).

Cách thứ nhất: chọn model khớp với việc. Cũng như bạn không giao việc của junior cho một senior, hay việc của senior cho một junior, bạn có lẽ nên giao Haiku cho các task cấp thấp, đơn giản; Sonnet cho knowledge work thông thường; còn Opus hoặc Fable cho knowledge work chất lượng cao, những việc thật sự tạo khác biệt cho tổ chức (cách chia của Nick, video đăng ngày 23/10/2026).

Cách thứ hai: đảm bảo bạn không đánh mất lợi ích của prompt cache. Nick giải thích: nếu bạn prompt Claude hai lần trong một khoảng thời gian nhất định, prompt thứ hai chỉ tốn khoảng 5% đến 10% mức giá bình thường. Đó gọi là prompt caching, và theo anh, nó tồn tại để khuyến khích những ai chạy các session nặng knowledge work cố gắng dồn các session đó lại gần nhau, để Claude có mức sử dụng khá dễ đoán theo thời gian (theo Nick, video đăng ngày 23/10/2026). Trên màn hình, Nick đưa một câu trích từ docs prompt caching của Anthropic: "By default, the cache has a 5-minute lifetime." Trang docs đó ghi cache read tốn 10% giá input token gốc, và 5% với Claude Opus 5.5 và Claude Sonnet 5.5 (đọc ngày 23/10/2026).

Nếu bạn để nhiều khoảng nghỉ, nhiều quãng trống giữa session này và session kế tiếp, chi phí của bạn sẽ đội lên (theo Nick, video đăng ngày 23/10/2026).

Cách thứ ba: nếu không cần việc xong ngay, ví dụ một task có thời gian hoàn thành trên 24 giờ và bạn có thể lùi lại một chút, bạn có thể batch nó. Theo Nick (video đăng ngày 23/10/2026), Anthropic và nhiều nhà cung cấp AI khác giờ có batch API, cho phép gửi một batch request lớn, chẳng hạn chạy qua đêm, rồi sáng dậy là việc đã xong. Anh giải thích về cơ bản họ tìm những khoảng thời gian GPU không được dùng nhiều lắm rồi đẩy request vào đúng lúc đó. Trang docs Batch processing của Claude ghi Message Batches API giảm chi phí 50%, phần lớn batch xong trong chưa tới một giờ, và batch hết hạn nếu không xong trong 24 giờ (đọc ngày 23/10/2026).

Cách cuối: theo dõi hoá đơn của bạn. Cũng như bạn sẽ không tuyển 50 người mà không thỉnh thoảng hỏi ý bộ phận tài chính, bạn cũng không nên tuyển hay đưa vào 50 "staff member" Claude như thế. Theo Nick (video đăng ngày 23/10/2026), thực tế là ở thời điểm đó một cái có lẽ đã đủ cho 80% task của bạn. Bạn cũng có thể nhúng Claude hoặc một agent khác thẳng vào kênh giao tiếp của team, rồi để mọi người cùng prompt một agent đó.

Nick khép video bằng lời mong mọi người thích video này, và mời người xem để lại bình luận về chủ đề họ muốn anh nói tiếp, vì anh lấy phần lớn ý tưởng từ khán giả.