# Prompt tham vọng hơn cho Claude Code: altitude, depth, range

[Ray Amjad](https://homus.dev/speakers/ray-amjad) · [Ray Amjad](https://homus.dev/orgs/ray-amjad)

> Ray Amjad đi qua bài của Felix Rieseberg: prompt theo goal beyond the goal, giao ownership cho agent, đòi cách làm của chuyên gia và mượn lời giải từ ngành khác.

Topics: Context Engineering, Coding Agents, Workflow

Canonical: https://homus.dev/talks/your-prompts-are-too-small-for-claude-code

## 1. Cùng model, cùng harness, mà có người được gấp 10 đến 100 lần

Ray Amjad mở đầu bằng một nhận xét của anh (video đăng ngày 18/10/2026): càng ngày càng rõ là có một số người lấy ra được nhiều hơn gấp 10 tới 100 lần so với những người còn lại, dù họ dùng cùng một model và cùng một harness. Theo Ray, một ví dụ tốt là Felix Rieseberg, người mà anh giới thiệu là một trong các engineering lead đang làm việc trên Claude (theo video đăng ngày 18/10/2026; trang cá nhân của Felix ghi anh làm việc trên Claude tại Anthropic, đọc ngày 22/10/2026). Ray gọi đó là một bài hay mà Felix vừa viết, tên là "How to be more ambitious: A tutorial for humans with models", đăng ngày 13/10/2026, tức vài ngày trước video.

Ray muốn đào sâu mọi thứ trong bài đó, kèm thật nhiều ví dụ. Lý do anh đưa ra: ngay cả Anthropic cũng nói rằng khi tuyển người, họ quan tâm xem ứng viên đã thể hiện được cách dùng AI tool một cách sáng tạo hay chưa. Trên màn hình, Ray mở bài "How employment is changing at Anthropic" của chính Anthropic (đăng ngày 16/10/2026). Đoạn được trích viết rằng thay đổi rõ nhất trong ghi chú phỏng vấn của các hiring manager là ngày càng nhấn mạnh việc ứng viên đã chứng minh được cách dùng AI tool sáng tạo hay chưa; năm 2024, thành tích dùng AI tooling được nhắc tới trong khoảng 5% đánh giá cho vai trò kỹ thuật và 7% cho vai trò phi kỹ thuật, và tới năm 2026 các tỉ lệ này đã tăng gấp ba với vai trò kỹ thuật, gấp bốn với vai trò phi kỹ thuật (theo bài của Anthropic đăng ngày 16/10/2026).

Từ đó Ray kết luận, theo cách nhìn của anh trong video đăng ngày 18/10/2026: chỉ nói với Claude "hey, build giúp tôi feature này" không còn tạo ra lợi thế gì. Điều mình muốn là nâng cái trần (ceiling) của những gì mình làm được, bằng cách tham vọng hơn (more ambitious) khi dùng model.

Ý mở đầu của Ray: khác biệt không nằm ở model hay harness, mà ở mức tham vọng của thứ mình yêu cầu.

## 2. Bốn kiểu ambition: speed, altitude, depth, range

Theo Felix, tham vọng (ambition) có bốn kiểu: speed, altitude, depth, và range. Ray nói anh sẽ đi qua từng kiểu một, với thật nhiều ví dụ trong Claude Code mà người xem có thể "lấy về dùng luôn".

![Bốn ô vẽ tay: Speed, Altitude, Depth, Range, ô Speed được khoanh](https://homus.dev/photos/RbfQayMNtJc-0102.jpg)

Bốn kiểu ambition trong bài của Felix: Speed (mũi tên tua nhanh), Altitude (mũi tên lên), Depth (mũi tên xuống) và Range (mũi tên hai chiều). Ô Speed đang được khoanh.

Speed là kiểu hiển nhiên: cùng một khối việc, giờ làm xong trong ít thời gian hơn. Khi bạn cần viết code, Claude sẽ viết nhanh hơn. Theo Ray (video đăng ngày 18/10/2026), đó là chỗ mà gần như ai cũng đã đứng rồi. Vì vậy, giống như chính Felix làm trong bài, Ray bỏ qua phần speed.

## 3. Altitude: từ task lên outcome, rồi lên goal beyond the goal

Với altitude, Felix nói về việc đi lên một tầng: thay vì giao cho model một task, bạn đưa cho nó cái outcome mà bạn thật sự muốn. Ray cho rằng điều này cũng chính là prompt theo goal thay vì theo task. Anh nói mình đã bàn về ý này gần tám tháng (tính tới video đăng ngày 18/10/2026); anh có một video từ tháng 2 nói về chuyện mọi thứ bạn gõ vào agent nên là goal-based chứ không phải task-based. Nhưng giờ Felix đặt thêm một câu hỏi: được rồi, rồi chuyện gì xảy ra tiếp theo? Đâu là cái goal nằm sau cái goal (the goal beyond the goal)?

Ray lấy một ví dụ về công việc liên quan tới performance. Nếu prompt theo task, bạn sẽ nói kiểu: thêm một index cho câu orders query. Claude sẽ làm đúng việc đó rồi dừng lại. Nếu prompt theo outcome và goal, bạn sẽ nói kiểu: mọi trang đều load dưới 200 millisecond cho người dùng thật. Khi đó Claude sẽ tự quyết xem orders query có đáng được thêm index hay không.

Nhưng nếu bạn dừng lại và tự hỏi goal beyond the goal của mình là gì, tức là vì sao mình làm chuyện này ngay từ đầu, thì câu trả lời trong trường hợp này sẽ là: người dùng làm xong việc của họ nhanh hơn; hãy tìm chỗ họ phải chờ hoặc phải click lòng vòng nhiều nhất, rồi cắt bỏ nó. Nói cách khác, toàn bộ lý do mình quan tâm tới performance, và lý do mình đưa ra các goal về performance, là vì mình muốn người dùng làm xong việc nhanh hơn.

![Bảng vẽ tay tiêu đề Performance với ba dòng Task, Outcome/goal, Goal beyond the goal](https://homus.dev/photos/RbfQayMNtJc-0223.jpg)

Ba tầng của cùng một việc về performance: task "Add an index to the orders query.", outcome/goal "Every page loads in under 200ms for real users." và goal beyond the goal "Users get through their work faster. Find where they wait or click around the most and cut it."

## 4. Từ "fix this crash" tới "keep my apps crash-free"

Ví dụ mà chính Felix đưa ra là về crash. Đầu năm ngoái (bài của Felix đăng ngày 13/10/2026, nên tức là đầu năm 2025; Ray tính là cách đây gần 20 tháng), Felix vẫn còn bảo Claude: "hey, sửa giúp tôi crash này", "sửa crash kia". Cuối cùng anh chỉ còn hỏi Claude: "hey, giữ cho các app của tôi không bị crash" (keep my apps crash-free).

![Ba ô fix this crash có mũi tên up a level dẫn tới tấm khiên keep apps crash-free, bên dưới là crash reports và máy Windows](https://homus.dev/photos/RbfQayMNtJc-0432.jpg)

Bên trái là ba yêu cầu "fix this crash" riêng lẻ; mũi tên "up a level" dẫn tới tấm khiên "keep apps crash-free". Phía dưới, hai thứ nuôi goal đó: crash reports và các máy thật (Windows, Mac, Linux).

Có một điều mình phải đảm bảo khi leo lên các nấc thang này: cho Claude access tới đúng tool để nó làm xong được việc. Trong trường hợp này, Claude cần access tới crash report, có thể đang nằm trên Sentry, và access tới các máy Windows, Mac và Linux thật để nó có thể tái hiện lỗi và thử các bản sửa trên đó. Bài của Felix cũng kể đúng như vậy: để Claude giữ app không crash, trước hết anh phải đảm bảo nó lấy được crash report dễ dàng, hiểu phiên bản app nào ứng với git commit nào, và có máy Windows, macOS, Linux để tự tái hiện và kiểm chứng bản sửa.

## 5. Hỏi agent trước: để đạt goal này, bạn cần tooling gì?

Khi định nghĩa một goal beyond the goal lớn kiểu "giữ app không crash", cách Ray thích làm là hỏi Claude từ trước: để làm được việc này, bạn cần access tới những gì?

Anh đưa ra một ví dụ thực tế với dịch vụ sandbox mà anh đang làm. Anh có thể giao cho Claude goal làm cho dịch vụ đó không còn crash, nhưng trước hết anh phải chắc rằng nó có access tới đúng tool từ trước. Vì vậy anh vào Slack, vì (theo Ray, video đăng ngày 18/10/2026) phần lớn các agent của anh được anh làm việc cùng qua Slack, tạo một channel mới và đặt tên theo kiểu "<tên dịch vụ> crash free". Sau đó anh tag agent Slack của mình, tên là Percy, và gõ:

```
Hey, so my goal is to basically make sure this application is crash-free. I know it's a pretty ambitious goal, but what kind of tooling would you need to set up or need from me to make this possible? I'd want you to run on a every like 12 hours, just basically working towards this goal.
```

Agent Slack sẽ trả lời kiểu: "đây là những tooling tôi khuyên bạn nên dựng". Lúc đó, Percy đang chạy và lục qua repository để xem hiện đã có gì. Ray đoán nó có thể sẽ nói với anh kiểu: "bạn tạo cho tôi một tài khoản AWS riêng để tôi thử nghiệm trên đó, rồi đặt trần ngân sách hay gì đó".

Điểm chính ở đây, theo Ray: khi leo lên các nấc altitude, bạn muốn đảm bảo agent có access tới đúng tooling và đúng môi trường để làm bất cứ thứ gì nó cần khi tiến tới goal đó. Cũng có thể agent không đoán trước được nó sẽ còn cần gì từ bạn. Khi đó bạn muốn cho phép nó tag bạn hoặc nhắn cho bạn mỗi khi cần dựng thêm tooling nào đó.

Cách Ray làm trước khi giao một goal lớn: hỏi agent nó cần tooling gì, dựng tool đó, để agent chạy định kỳ và cho phép nó tag mình khi cần thêm.

## 6. Ra khỏi vòng lặp: đừng làm meat proxy

Một cách nhìn khác cho altitude, theo Ray, là chuyển bản thân mình ra khỏi vòng lặp (out of the loop) và lên trên vòng lặp (on the loop).

Ví dụ từ chính các ứng dụng của anh: khi một người dùng liên hệ customer support để báo bug, một người trong team của anh thường chuyển bug đó cho Claude Code, kiểu "hey, sửa cái này đi". Claude sửa xong, rồi team báo lại cho người dùng. Đôi khi yêu cầu hoặc mô tả bug của người dùng hơi mơ hồ, thì team lại phải hỏi thêm chi tiết rồi chuyển lại cho Claude. Trong tình huống đó, team của anh đang đóng vai người trung gian, cái "meat proxy", và sẽ tốt hơn nhiều nếu thiết kế một hệ thống để Claude tự xử lý chuyện này.

![Sơ đồ user, support, middleman là you, rồi Claude Code fix this và fix](https://homus.dev/photos/RbfQayMNtJc-0443.jpg)

Chuỗi cũ: user, support, rồi "you" ở giữa được khoanh và gắn nhãn "middleman", trước khi tới Claude Code với lệnh "fix this" và kết quả "fix". Cột bên trái liệt kê các nấc factory, ownership, analytics, bugs; nấc đang được tô là "bugs".

Hệ thống mà Ray thiết kế, theo lời anh kể trong video đăng ngày 18/10/2026, như sau. Một agent chạy theo routine sẽ theo dõi cả hai nguồn: kênh support, qua MCP server của công cụ support anh dùng, và Sentry. Nó thường ghép được một support ticket với một crash đã xảy ra trên Sentry. Nhờ vậy, khi một bug được báo, nó có thể thử tái hiện bug đó trên một máy thật. Nếu không tái hiện được, nó quay lại hỏi người dùng thêm các câu làm rõ, kiểu "hey, bạn đang dùng browser nào?", cho tới khi tái hiện được. Khi đã tái hiện được, nó làm bản sửa, merge vào, rồi báo người dùng kiểu "hey, lỗi đã được sửa".

Câu Ray tự hỏi mình ở đây là: mình đang làm người trung gian ở chỗ nào? Một phiên bản tham vọng hơn của task này trông sẽ ra sao?

Ví dụ: có một support ticket gửi tới qua email bằng tiếng Nhật. Agent của anh nhận ticket, thử tái hiện lỗi bên trong ứng dụng. Khi không tái hiện được, nó trả lời người dùng, hỏi rằng chữ "key" họ dùng nghĩa là gì: họ đang nói tới một keyboard shortcut hay một API key?

## 7. Từ dashboard sang những câu hỏi đúng

Một cách khác mà altitude đã giúp Ray: hồi trước thời AI agent, anh thường xuyên kiểm các dashboard. Sau khi AI agent đủ tốt, anh nối chúng vào tất cả MCP server của các dịch vụ anh dùng, và để agent dựng dashboard theo yêu cầu, gộp dữ liệu từ nhiều nguồn khác nhau.

Rồi anh lùi lại một bước và tự hỏi: vì sao mình lại đi xin dashboard ngay từ đầu? Mục tiêu cuối cùng ở đây là gì? Anh nhận ra rằng về cơ bản nó là để giúp anh trả lời những câu hỏi vẫn lởn vởn trong đầu, kiểu: vì sao người ta mua? Ai quay lại? Cái gì dự báo được doanh thu? Anh đã hi vọng rằng nếu nhìn dashboard đủ lâu thì sẽ nảy ra câu trả lời cho mấy chuyện đó.

Nhưng cùng lúc ấy, anh có thêm một lần đổi cách nghĩ lớn: thay vì chỉ dùng AI để trả lời những câu hỏi mình đang có, nên dùng nó cả để giúp mình đặt ra đúng câu hỏi ngay từ đầu, rồi sau đó mới đi trả lời. Trong thực tế, anh vào Slack và nói đại ý: "hey, goal của tôi là tăng mức hài lòng của khách hàng và doanh thu mỗi tuần, dùng tất cả MCP server mà bạn có. Bạn có thể nghĩ ra 10 câu hỏi mà tôi nên hỏi để giúp tôi tiến tới các goal đó không? Rồi tìm luôn câu trả lời cho các câu hỏi đó và chuẩn bị cho tôi một báo cáo có biểu đồ, có nhận định riêng của bạn và mọi thứ kiểu như vậy."

Sau đó, mỗi tuần agent Slack của anh lại chạy, chuẩn bị báo cáo này và gửi cho anh đều đặn. Ray thấy nó thật sự hữu ích, vì Claude bắt đầu hỏi những câu kiểu: thời gian median từ lần ghé đầu tiên tới lúc mua là bao lâu?

![Dashboard bị gạch chéo, ô questioner với ba câu hỏi, biểu đồ median about 4 min từ visit tới purchase](https://homus.dev/photos/RbfQayMNtJc-0723.jpg)

Nấc "analytics": dashboard bị gạch chéo, thay bằng một "questioner" đặt ra các câu "why do they buy?", "who comes back?", "what predicts revenue?". Biểu đồ bên dưới là phân bố thời gian từ lần ghé tới lúc mua, với vạch "median about 4 min".

Với một trong các sản phẩm của Ray, kết luận là khoảng bốn phút (theo số đo của Ray Amjad, video đăng ngày 18/10/2026), và điều đó xếp sản phẩm này vào loại mua theo cảm hứng (impulse buy). Anh còn phát hiện, trong trường hợp riêng của anh, rằng video retention tương quan âm với doanh thu: người xem hết toàn bộ video lại ít có khả năng mua của anh hơn (theo số liệu của Ray, video đăng ngày 18/10/2026). Anh thấy cách này tốt hơn dashboard nhiều, vì nó giúp anh ra quyết định tốt hơn, có cơ sở hơn.

## 8. Giao ownership cho agent

Một cách khác để Ray leo lên altitude là trao ownership cho các agent của anh. Trước đây, agent Slack chỉ làm những task mà anh tag nó vào, nghĩa là chính anh là cái trigger cho từng mẩu việc. Giờ thì, giống ví dụ của Felix, chúng nhận ownership.

Cụ thể, anh có các agent khác nhau chịu trách nhiệm cho từng mảng khác nhau của business: revenue, sign-up, refund, churn, error. Theo Ray (video đăng ngày 18/10/2026), chúng chạy suốt ngày đêm, kiểu một lần mỗi ngày hoặc hai lần mỗi ngày, và chỉ tag anh, chỉ báo cho anh khi có gì đó trông không ổn. Toàn bộ có thể là một vòng lặp lớn, hoặc thay vào đó là nhiều vòng lặp nhỏ.

![Người you, các task @agent mờ dần, Slack agent chạy daily, nhắn something looks off, năm đồng hồ revenue signups refunds churn errors](https://homus.dev/photos/RbfQayMNtJc-0803.jpg)

Nấc "ownership": các mũi tên "@agent task" từ "you" mờ đi; một "Slack agent" chạy "daily", theo dõi năm đồng hồ revenue, signups, refunds, churn, errors, và chỉ lên tiếng "something looks off" khi đồng hồ refunds lệch đỏ.

## 9. Sửa system thay vì sửa application

Một việc nữa Ray hay làm khi nói tới altitude là làm việc trên chính cái system nhiều hơn là trên các application, vì đó là chỗ anh có nhiều đòn bẩy (leverage) hơn. Trước đây, anh trỏ Claude Code vào và nói "hey, build giúp tôi feature này". Giờ thì anh trỏ Claude Code vào chính cái system và nói "hey, thêm thứ này vào system". Đến lượt nó, system có thể build thêm nhiều feature hơn, sửa nhiều bug hơn và tự làm nhiều việc hơn, trong khi vẫn đảm bảo sự chú ý của anh chỉ đổ vào những thứ quan trọng nhất.

![Before: you points agent builds one feature. After: you points agent tới the system](https://homus.dev/photos/RbfQayMNtJc-0823.jpg)

Nấc "factory". Before: bạn trỏ agent, agent build ra một feature, và "you, on every feature". After: bạn trỏ agent vào "the system", và system mới là thứ làm ra các feature.

Tất nhiên, Ray nói anh không làm vậy mọi lúc: với những feature thật sự lớn, anh vẫn tự nhảy vào. Nhưng giờ phần lớn thời gian, theo Ray (video đăng ngày 18/10/2026), các agent của anh tự chạy suốt ngày đêm, tìm vấn đề trong ứng dụng, rồi tự mở PR, kiểm chứng các vấn đề đó, và đóng chúng lại.

Và theo Ray, đây là toàn bộ cú chuyển: khi bạn sửa một bug trong application, bạn sửa được đúng một bug. Nhưng khi bạn sửa một bug trong system, thì mọi app, mọi thứ mà system chạm tới, đều được sửa theo.

## 10. Tool và môi trường cho agent mới là phần tốn công

Phần quan trọng nhất ở đây, theo Ray, là anh muốn chắc rằng các agent của mình có access tới đúng tool để làm việc của chúng. Chúng cần access tới analytics, tới nhiều thứ khác nhau bên trong business, ví dụ read-only access vào Stripe. Chúng cũng cần nhiều cách để tự kiểm chứng công việc của chính mình: thiết bị để test, các login mà chúng dùng được, và khả năng tự tạo tài khoản mới tinh trên hệ thống.

Lý do, theo Ray (video đăng ngày 18/10/2026), là các agent này sẽ không tự động hỏi bạn kiểu "hey, tôi cần access tới tool này nữa, bạn cấp cho tôi được không?". Vì vậy Ray thấy bản thân anh giờ còn dành nhiều thời gian hơn trước cho việc đảm bảo các agent của mình có đúng tool và đúng môi trường.

Những thứ Ray kể là agent của anh cần: dữ liệu để nhìn (analytics, Stripe chỉ đọc) ở bên trái, và cách để tự kiểm chứng công việc (thiết bị test, login, tạo tài khoản mới) ở bên phải.

## 11. Depth: làm một task theo cách người giỏi nhất ngành làm

Kiểu thứ ba Felix nói tới là depth. Đôi khi bạn không muốn một outcome lớn hơn; bạn muốn đảm bảo một task cụ thể được làm thật, thật tốt. Về cơ bản, bạn muốn nó được làm theo cách mà người giỏi nhất trong ngành sẽ làm task đó.

Một điều Felix nói trong bài: khi bạn bảo model đóng vai một người chuyên nghiệp, nó thường đổi từ vựng nhưng không thật sự đổi phương pháp (theo bài của Felix đăng ngày 13/10/2026). Ví dụ, nó sẽ dùng một bảng markdown đơn giản, trong khi một data scientist thật sẽ dùng tới database và một kiểu statistical model nào đó.

Ray lấy ví dụ: app của bạn mất 10 giây để load. Bạn có thể bảo Claude "hey, làm cái này nhanh hơn đi", và bạn sẽ nhận được kiểu lazy loading rồi useMemo. Còn theo Ray (video đăng ngày 18/10/2026), nếu bạn prompt để Claude dùng đúng những tool mà một performance engineer thật sự dùng, nó sẽ bắt đầu profile ứng dụng, đọc các trace, tìm xem thời gian thật sự đi đâu, và xác định kiểu "hey, câu database query ở đây đang chiếm nhiều thời gian nhất".

![my app loading 10s, make this faster cho ra useMemo và lazy still slow, profiler trace cho thấy db queries chiếm phần lớn thời gian](https://homus.dev/photos/RbfQayMNtJc-1043.jpg)

Phía trên: "my app" load mất 10s, yêu cầu "make this faster" chỉ cho ra "+ useMemo()" và "+ lazy()", kết quả "still slow". Phía dưới: một profiler trace trên trục 0 đến 10 giây với router, auth, db queries, render, hydrate; thanh db queries được khoanh là "where time goes".

## 12. Đặt goal vô lý và bảo Claude rằng nó hợp lý

Một điều nữa Felix nhấn mạnh trong bài (đăng ngày 13/10/2026) là đưa cho Claude một goal vô lý, rồi bảo nó rằng goal đó hoàn toàn hợp lý. Ví dụ, bạn muốn thời gian load còn 5 giây; vậy thì hãy đòi 200 millisecond. Rồi khi Claude bảo bạn "hey, cái đó không thể", bạn đáp lại kiểu "có thể chứ, cứ tiếp tục đi".

![Đồng hồ đo từ 10s qua 5s, 1s tới 200ms, normal ask ở 5s, ask for this ở 200ms, agent nói not possible, bạn đáp it is, keep going](https://homus.dev/photos/RbfQayMNtJc-1114.jpg)

Đồng hồ thời gian load: "today: 10s", "normal ask" dừng ở 5s, còn "ask for this" kéo tới 200ms. Bên phải, agent trả lời "not possible" và bạn đáp "it is, keep going".

Theo Ray, mình đã thấy điều này vài tháng trước (tính từ video đăng ngày 18/10/2026), khi người tạo ra Bun (Jarred Sumner) bảo Claude làm việc với giả thuyết Riemann. Theo lời Ray kể, một nửa prompt của anh ấy về cơ bản là động viên Claude, kiểu: "bạn cần đặt một bước nhảy niềm tin lớn vào năng lực của mình, bạn là large language model có năng lực nhất thế giới cho tới nay, bạn làm được mà". Ray thấy chuyện đó khá buồn cười, vì một kỹ thuật mà, theo anh (video đăng ngày 18/10/2026), mình đang thấy ngày càng nhiều là đưa cho Claude một goal vô lý và động viên nó tiến dần tới goal đó.

Nhưng với các bài toán engineering, mình muốn đảm bảo nó dùng đúng những tool mà chuyên gia dùng. Và bạn không cần biết những tool đó là gì. Theo Ray (video đăng ngày 18/10/2026), Claude đã biết chuyên gia dùng tool nào; bạn chỉ cần khăng khăng đòi dùng đúng những tool đó.

## 13. Prompt của Felix để viết lại prompt cho sâu hơn

Trong bài, Felix còn đưa ra một meta prompt, tức một prompt dùng để viết lại các prompt sẵn có của bạn cho sâu hơn. Ray mở đúng đoạn đó trên trang của Felix, dưới dòng "A simple prompt that often helps me:":

```
I want a deeper version of this task, not a bigger one. Before rewriting it: (1) say what a top professional in this field would do here that I'm not asking for; (2) name the rawest material they would start from instead of what has already been digested for me; (3) name the specific methods and tools they would use; (4) say what, other than you or me, would show the result is right. Then rewrite my prompt to ask for exactly that.
```

Ray đọc lại từng phần: đây là bản sâu hơn của task, không phải bản lớn hơn. Trước khi viết lại, hãy nói một chuyên gia hàng đầu trong ngành sẽ làm gì ở đây mà tôi chưa yêu cầu; nêu ra nguyên liệu thô nhất mà họ sẽ bắt đầu, thay vì những thứ đã được tiêu hoá sẵn cho tôi; nêu các phương pháp và tool cụ thể họ sẽ dùng; nói xem thứ gì, ngoài bạn và tôi, sẽ chứng minh kết quả là đúng; rồi viết lại prompt của tôi để đòi đúng điều đó.

Theo Ray, phần số 4 về cơ bản là ý tưởng có một verifier thật tốt. Ngay trên đoạn prompt, bài của Felix cũng viết rằng đừng bảo model tự chấm chính nó, và "in October 2026" anh khuyên hãy khăng khăng đòi kiểm chứng từ bên ngoài, lý tưởng là một tool mà model chạy được để nhận feedback ngay.

## 14. Range: một ngành khác đã giải phần khó rồi

Ý cuối cùng Felix nói tới là range. Ray cho rằng range có thể là ý khó hình dung nhất, nên anh muốn giải thích cho cẩn thận. Về cơ bản, task nào cũng trông như thuộc về một lĩnh vực cụ thể. Range là nhận ra rằng một lĩnh vực hoàn toàn khác đã giải xong phần khó trong bài toán của bạn rồi.

Mẹo Felix chia sẻ để tìm ra điều đó là thay danh từ bằng động từ. Danh từ ở đây là "a deck", một bộ slide. Dạng động từ của nó sẽ là: khiến những người bận rộn tin vào một câu chuyện nhân quả và ra quyết định trong điều kiện bất định, trong khoảng 30 phút. Và đó là việc mà rất nhiều người ở nhiều ngành khác đã làm sẵn, như nhà báo, biên tập viên và analyst.

Mẹo "noun to verb" của Felix: lật "a deck" thành việc nó thật sự phải làm, rồi tìm những nghề đã làm việc đó hằng ngày.

Có thể bạn đang nghĩ: được rồi, nhưng làm sao mình viết nổi một prompt như vậy? Thường thì bạn không viết được, vì bạn chỉ thật sự biết về lĩnh vực của mình. Theo Ray (video đăng ngày 18/10/2026), Claude thì biết về gần như mọi nghề khác. Vì vậy bạn lật ngược lại và nói: "Claude, đây là bài toán của tôi. Phỏng vấn tôi, rồi cho tôi biết những nghề nào đã xử lý một bài toán có hình dạng kiểu này, và họ thật sự làm gì ở đây."

## 15. Ví dụ range: error message

Ví dụ: error message của bạn có thể trông kiểu "Error 500". Bạn bảo Claude "hey, tôi muốn cải thiện error message trong ứng dụng", và nó có thể biến mọi trang lỗi thành thứ gì đó thân thiện hơn, kiểu "đã có lỗi xảy ra, vui lòng thử lại sau". Nhưng vấn đề vẫn còn nguyên, vì người dùng vẫn bị kẹt.

Nếu dùng đúng mẹo của Felix, thì error message là danh từ, còn động từ sẽ là: giúp một người đang bối rối tự gỡ được chỗ kẹt, một mình, mà không phải liên hệ ai. Và đó chính là việc mà các nhân viên support làm để kiếm sống.

Theo Ray, ít nhất là ở thời điểm video đăng (18/10/2026), Claude không có sẵn ý tưởng range này theo mặc định, nên bạn phải gợi hành vi đó ra bằng một prompt kiểu: kéo về sáu tháng support ticket gần nhất, ghép từng ticket với error tương ứng, rồi xếp hạng theo số lượng. Trên màn hình, khung prompt ghi:

```
> pull 6 months of tickets
> match each to its error
> rank them by count
```

Ray đoán nhiều khả năng bạn sẽ thấy chỉ 4 error gây ra phần lớn support ticket, và bạn nên tập trung viết lại mấy cái đó. Như vậy, error gốc cho một lỗi kiểu "entity too big", thay vì nói "oops, thử lại sau", sẽ thành kiểu: video này 6GB, gói của bạn cho phép 5GB, chưa có gì được upload, bạn có thể nén nó lại hoặc nâng cấp gói.

![Ba cửa sổ upload: original ENOSPC 413, default fix Oops, range version Upload failed với Compress it và Upgrade](https://homus.dev/photos/RbfQayMNtJc-1403.jpg)

Ba phiên bản của cùng một lỗi upload: "original" là "ENOSPC 413 Request Entity Too Large"; "default fix" là "Oops! Something went wrong. Try again later." với nút "Try again" và ghi chú "fails again"; "range version" là "Upload failed. This video is 6 GB. Your plan allows 5 GB. Nothing was uploaded." với hai nút "Compress it" và "Upgrade".

Theo Ray, đó là phiên bản "có range" của cùng một task, và nó sẽ giảm số người phải tìm tới customer support.

## 16. Ví dụ range: feature request và ông bác sĩ

Một chỗ khác Ray thích áp dụng range là feature request. Giả sử bạn có một loạt người dùng xin tính năng export CSV. Bước đi bình thường của bạn sẽ là build một nút export CSV, rồi tự nhủ "ok, xong việc".

Nhưng thử nghĩ xem bác sĩ làm gì. Một bệnh nhân bước vào và nói "tôi cần kháng sinh". Một bác sĩ giỏi sẽ không chỉ kê đơn kháng sinh cho họ. Họ sẽ hỏi về triệu chứng, chẩn đoán vấn đề, và có thể xác định ra rằng thứ thật sự cần lại là một thứ khác. Người dùng cũng y như vậy.

Dù người dùng xin một tính năng cụ thể, bạn muốn tìm ra các triệu chứng theo cách một bác sĩ làm. Và bạn có thể bảo Claude làm đúng việc đó. Claude có thể nhận ra rằng trong số những người xin export CSV, thật ra phần lớn đang import nó vào Google Sheets mỗi thứ Hai; một số đang gửi nó cho kế toán của họ qua email; và chỉ một nhóm nhỏ thật sự muốn một nút CSV. Khi đó, bạn sẽ thêm các tính năng: một bản sync Google Sheets trực tiếp, một email sao kê hằng tháng để họ chuyển tiếp cho đúng người, và cuối cùng mới là nút CSV.

![Claude đọc 43 CSV requests, chia thành 29 Google Sheets Mondays, 8 to accountant, 6 wanted a CSV, dẫn tới live Sheets sync, monthly statement email, CSV button](https://homus.dev/photos/RbfQayMNtJc-1503.jpg)

Ví dụ trên màn hình: Claude đọc "43 CSV requests" và hỏi "what was the file for?". Kết quả: 29 cho "Google Sheets, Mondays" dẫn tới "live Sheets sync" (được ghi là "the real symptom"), 8 gửi "to accountant" dẫn tới "monthly statement email", và chỉ 6 "wanted a CSV" dẫn tới "CSV button".

Theo Ray (video đăng ngày 18/10/2026), rất có thể các model trong tương lai sẽ giỏi chuyện này theo mặc định. Nhưng ngay lúc này, với range, khi đưa cho Claude một bài toán, mình muốn nó nghĩ: được rồi, người ở các lĩnh vực khác đang làm gì mà có thể đã giải bài toán này giúp mình rồi?

## 17. Self-efficacy: thấy người khác làm được thì trần của mình nâng lên

Ray khá thích phần cuối bài của Felix, nơi Felix nói về self-efficacy: về cơ bản là mức độ bạn tin rằng mình làm được một việc. Theo bài của Felix (đăng ngày 13/10/2026), nhìn chung người tin rằng mình làm được nhiều hơn thì rốt cuộc tự họ đạt được nhiều hơn.

Một trong những điều quan trọng nhất ở đây là khi bạn thấy người khác làm được một việc, việc đó thôi không còn cảm giác bất khả thi nữa. Felix dùng ví dụ dặm bốn phút (four-minute mile): rất nhiều người từng nghĩ chạy một dặm dưới bốn phút là không thể, nhưng khi kỷ lục đó bị phá vào tháng 5 năm 1954, người tiếp theo phá nó chỉ 46 ngày sau. Về cơ bản, thấy một người khác chạy một dặm trong bốn phút khiến bạn tin chắc hơn rằng chính mình cũng làm được. Theo Ray, chuyện tương tự cũng xảy ra với lần đầu tiên có người chạy marathon dưới 2 giờ (bài của Felix, đăng ngày 13/10/2026, kể đó là cuộc đua ở London vào tháng 4 năm 2026, và người về nhì cũng phá mốc hai giờ).

Hình Ray vẽ khi nói về self-efficacy: thanh "your ceiling" nằm trên đầu "you", và một người khác đã vượt qua nó ("someone did it"). Thấy người khác làm được thì trần của mình dịch lên.

Ray nói đó là một phần lý do anh thích làm video về Claude Code và các agent khác: khi bạn thấy những gì làm được bên trong Claude Code, trần của chính bạn dịch lên và bạn đạt được nhiều hơn.

Và theo anh, lý do điều này quan trọng hơn bao giờ hết là các model đang nhảy vọt mỗi vài tuần, trong khi kỳ vọng của mình thì không dịch chuyển nhanh được như vậy (theo Ray, video đăng ngày 18/10/2026). Đó là một khoảng cách mà bạn có thể tận dụng, nếu bạn thường xuyên lấy cảm hứng và lấy ý tưởng từ những người đang làm việc sát hơn với những gì model làm được.

![Biểu đồ capability: model capability đi lên theo bậc thang mỗi 2 weeks, đường kỳ vọng của mình đi lên chậm, khoảng giữa là the gap](https://homus.dev/photos/RbfQayMNtJc-1623.jpg)

Trục "capability": đường "model capability" đi lên theo từng bậc, mỗi bậc khoảng "2 weeks", còn đường kỳ vọng của mình ("our ex...") chỉ nhích lên chậm. Phần tô giữa hai đường là "the gap".

## Nguồn và liên kết

- Tên gốc: Your Prompts Are Too SMALL for Claude Code
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=RbfQayMNtJc](https://www.youtube.com/watch?v=RbfQayMNtJc)

- Kênh YouTube Ray Amjad (Ray Amjad): [youtube.com/channel/UCLA7cJBnqr0nLF2bQBD9uUg](https://www.youtube.com/channel/UCLA7cJBnqr0nLF2bQBD9uUg)

- Trang cá nhân của Felix Rieseberg (đọc ngày 22/10/2026): [felixrieseberg.com](https://felixrieseberg.com/)

- Felix Rieseberg, "How to be more ambitious: A tutorial for humans with models" (đăng ngày 13/10/2026; bốn kiểu ambition, ví dụ crash-free, prompt "deeper version", mẹo noun to verb, self-efficacy): [felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models](https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/)

- Anthropic, "How employment is changing at Anthropic" (đăng ngày 16/10/2026; đoạn về tiêu chí tuyển dụng và cách dùng AI tool sáng tạo): [anthropic.com/research/employment-at-anthropic](https://www.anthropic.com/research/employment-at-anthropic)

Nguồn: https://homus.dev/talks/your-prompts-are-too-small-for-claude-code · cập nhật 2026-10-22