Altitude, Depth, Range: More Ambitious AI Prompting

My ordinary prompt: “Build a reports dashboard.” The more useful version: “Help a hiring manager decide which bottleneck to clear today. Use the underlying records, distinguish delays from missing data, and test whether the result supports that decision.”

The second request is not just longer. It gives the agent a different job. I care less about a finished screen than whether somebody can act on it. That distinction becomes more important as building gets cheaper: a perfectly implemented low-value request is still low-value work.

Felix Rieseberg’s October 13 essay gives that shift a vocabulary: speed, altitude, depth and range. This is his framework, not mine. My contribution is a bounded way to use it: reusable prompts, a local handoff builder, and examples framed as proposals rather than invented case-study results.

The four types of ambition

Ambition in AI prompting changes the scope, method or perspectives of work, rather than only its speed.

Speed is the familiar move: write the same report faster. I’ll skip it here. The other directions are independent; you can go deep on a narrow task without expanding its scope. Pick the missing dimension instead of stacking every instruction onto every request.

Altitude: ask for the outcome

Altitude means specifying what should change after a task is completed, and asking what else that change requires.

Rieseberg describes moving from individual crash fixes toward keeping applications crash-free. The important part is the machinery behind the request: error reports, a way to connect released versions to code, and environments that can reproduce failures. A broader goal without that access just produces broader speculation.

His quarterly-review example climbs four rungs. First, fill the presentation template. Next, explain changes and proposed responses. Then identify urgent decisions and argue the alternatives. Finally, reconsider the review mechanism itself: how does the company detect problems and reallocate resources? Back-test a proposed replacement and run it alongside the existing process before trusting it.

Try this: “This report exists so we can decide what to stop funding. Identify the decisions our records actually support, show uncertainty, and propose a parallel trial of a better review.” The meeting heuristic is useful because meetings often reveal a coordination problem hiding behind a document request.

Altitude does not mean unrestricted autonomy. “Make money” omits the customer, constraints and authority. Creative work may be valuable precisely because the process is exploratory. I would start with a bounded outcome, a named owner, a measurement window and explicit things the agent must not change. See why product judgment gets more valuable when building gets cheap.

Depth: ask for the expert version, not the bigger one

Depth means changing the raw material, instruments and verification of a task to match how a strong practitioner actually works.

“Act like a senior engineer” may improve tone while leaving the method untouched. Ask for a trace, a query, a reproducible experiment or a held-out evaluation. Five moves from the essay are especially reusable:

1. Use instruments. “Profile the slow journey and attach the trace; do not estimate the bottleneck from the screenshot.”
2. Set a demanding target. “Investigate a 200ms budget rather than accepting five seconds; record what each approach achieves.” Treat physical, cost and security limits as real, not objections to talk away.
3. Challenge a belief. “Try to reproduce our activation hypothesis from raw events; show contradictory evidence too.”
4. Produce new knowledge. “Find a candidate early-warning signal and test it on a period held out before analysis.” No signal is a legitimate result.
5. Use an outside judge. “Define the acceptance check first; give the reviewer the requirements and artifacts, not just your conclusion.”

Paraphrasing Rieseberg’s depth rewrite: ask what a leading practitioner would add, what raw inputs they would start from, what specific tools they would use, and what external evidence would establish correctness. Only then rewrite the request. Read his original explanation for the reasoning behind those questions.

My addition is a stopping budget. Give the agent a time or cost ceiling, forbid weakening the tests, and require escalation when further improvement needs unavailable data. Otherwise an ambitious target can turn into a confident claim that the target was reached. Agent evaluation before shipping explains why final-state evidence matters more than a successful tool call.

Range: bring in the crew

Range means applying complementary disciplinary methods to the same problem, with explicit artifacts and handoffs.

Start by replacing the format noun with verbs. A quarterly review is not merely a deck: it helps busy people understand causes, compare alternatives and decide under uncertainty. That suggests analysis, reporting, editing and adversarial financial examination. The useful question is what each discipline does, not what its voice sounds like.

For an onboarding change, I would ask a researcher to identify failure patterns, an analyst to test event coverage, an accessibility reviewer to walk the complete journey, and a skeptical operator to inspect recovery and support consequences. Each owes a concrete artifact: observations, queries, a task record, or failure scenarios.

Run dependent passes sequentially. A specialist should work from the actual previous result, apply its method, and hand off findings and authorized fixes. Independent investigations can run in parallel, but two agents editing the same surface need isolation and coordination. Claude Code subagents provide separate contexts; that is not proof that their reasoning is independent.

Cut any pass that only changes vocabulary. Keep a shared acceptance contract so the crew cannot optimize separate goals and call the combined result finished. That contract connects range to spec-driven, maker-checker workflows.

Resources: ambition needs equipment

Resources are the observation, context and verification facilities an agent needs to execute an ambitious request rather than merely describe one.

The supplied AI LABS video demonstrates the essay’s ideas in an app-building setting. I treat it as a secondary demonstration, not evidence that every Anthropic engineer uses an identical workflow. Watch it alongside the primary essay; product capability and tool permissions still need checking against documentation.

• See: can the agent inspect logs, source records or the actual screen?
• Understand: does it have the relevant code, definitions, constraints and source dates?
• Test: can it reproduce the problem and read back the result after a change?

For each “no,” close the smallest gap first. A screenshot cannot reveal a missing event record; a passing unit test cannot prove a payment works in the installed app. Use approved data and least-privilege access. Evidence-rich context is not permission to send customer records to an unapproved service.

AI LABS demonstrationAnthropic Just Revealed How Their Engineers Use Claude Code

I used the framework to shape this post

Applying the framework to editorial work means choosing a reader outcome, using primary material and checking the resulting experience.

Worked examples from my builds

A worked prompting example demonstrates a proposed change in method; it is not a claim of measured business results.

The prompt template library

A prompt template is a reusable request structure whose placeholders must be replaced with the task’s actual context and limits.

These fourteen original templates came with the brief and are reproduced verbatim, not copied from Felix’s meta-prompt. The ambitious-target wording is deliberately forceful: never use it to dismiss a demonstrated impossibility, spending limit or safety boundary. The standing-rule and skill examples are suggestions to adapt, not installed instructions.

Here's the task I'd normally give you: {{task}}.
Don't do that yet. The outcome I actually want is: {{outcome}}.
1. Tell me what has to be true for that outcome to happen, beyond this task.
2. Propose the most ambitious version of the work you can actually carry out with the access you have.
3. Tell me what access, data, or tools you're missing to go one level higher.
Then do the highest-altitude version you can complete and verify.

I need {{deliverable}} for {{audience}}.
Don't just produce it. Work up this ladder and stop at the highest rung the data supports:
1. What changed, why, and what should we do about it?
2. Which 3 decisions are most urgent? Draft for/against cases for each.
3. What is this {{deliverable}} actually for? Design a better mechanism for that purpose, back-test it on our history, and propose running it in parallel with the current one.
Here is everything I have: {{data_sources}}.

I want a deeper version of this task, not a bigger one: {{task}}.
Before doing anything:
(a) What would a field-leading {{field}} expert do here that I'm not asking for?
(b) What raw material would they start from, instead of the summarized version I'm handing you?
(c) Which specific methods and tools would they use?
(d) What — other than you or me — would prove the result is correct?
Then rewrite my prompt so it asks for exactly that, show me the rewrite, and wait.

Don't adopt an expert's tone. Adopt their instruments.
For {{task}}, list the tools and methods a top {{field}} practitioner uses
(e.g. databases, statistical models, profilers, test harnesses, design tools).
Use those. If you catch yourself producing a markdown table or a prose estimate
where an expert would run a query, a model, or a measurement — stop and run it.

Target: {{ambitious_target}} (current: {{current_state}}).
This is achievable. If an approach looks impossible, treat that as a sign the approach is wrong, not the target.
Keep a log of approaches tried, what each achieved, and what you'll try next. Don't stop at the first improvement.

We believe: {{belief}}.
Here is the raw data: {{data}}.
Try to reproduce that belief from the raw data alone. Act as if you want it to be false.
Report: does the data support it, contradict it, or not speak to it? Show the analysis, not just the conclusion.

Now that you're inside {{data}}:
Build a model or simulation that reproduces the last {{period}}.
Find the earliest signal of {{outcome}} we don't already track.
Prove it predicts on data you held out from the start. Report the holdout result honestly, even if it's weak.

You will not be the judge of this work.
Before you start, define how {{task}} will be verified by something other than you:
a test suite, a benchmark, a linter, a validator, a measurement tool, or a separate reviewer model.
Set that up first. Run it after every meaningful change. Report the judge's output verbatim, not your interpretation of it.

Describe {{thing}} without nouns that name the format.
What does it DO for people? Write it as 1–2 sentences of verbs
(e.g. "gets busy people to believe a cause-and-effect story and decide under uncertainty in 30 minutes").
Then list 5–8 fields whose experts are best at those verbs, and what each one would do differently here.

Stakes: {{thing}} has to be exceptional.
Assemble the crew you'd hire: {{optional_starting_roles}} — add or replace as you see fit, including at least one adversarial/red-team field.
For each field: state what that expert actually DOES (their method), not how they talk.
Run them one at a time as separate passes (or subagents). Each pass applies its method, fixes what it finds, and hands off. Do not write in their voice.
End with a list of changes made per pass.

Before starting {{goal}}, check your equipment and tell me what's missing:
1. SEE — can you observe the problem directly? (logs, screenshots, browser, error reports, analytics)
2. UNDERSTAND — do you have enough context? (codebase, docs, data, connectors)
3. TEST — can you verify a fix on your own? (test suite, preview environment, real devices, validators)
For each gap, propose the smallest setup that closes it.

Task I'd normally give you: {{task}}

ALTITUDE — The outcome I want is {{outcome}}. Work toward that, not just the task.
DEPTH — Do it the way a field-leading {{field}} expert would: their raw material, their instruments, their methods. Aim for {{ambitious_target}}; treat it as achievable.
RANGE — This thing's job, in verbs: {{verbs}}. Run passes through {{n}} relevant fields (include one red team). Each pass does what that field does, fixes what it finds, and hands off.
RESOURCES — First confirm you can see the problem, understand the system, and test your own changes. Tell me any gap before you start.
JUDGE — Verification comes from {{judge}}, not from you. Report its output directly.

## How to approach work in this repo
- Altitude: before executing a task, restate the outcome it serves. If a higher-altitude approach is feasible with available access, propose it.
- Depth: use the instruments an expert would (queries, profilers, tests, validators) instead of estimates or prose tables.
- Range: for significant changes, run sequential review passes through relevant disciplines (e.g. performance, accessibility, security, UX writing); each pass fixes what it finds.
- Judge: never self-certify. Run tests/linters/validators and report their output. For major work, request review from a separate model or reviewer.
- Resources: if you can't see, understand, or test something, say so and propose the setup before guessing.

---
name: ambitious-mode
description: Use when the user hands over a task that has a clear underlying outcome, needs expert-quality execution, or would benefit from multiple disciplines. Upgrades the task via altitude, depth, and range before executing.
---

# Ambitious mode

1. **Resources check** — confirm you can see the problem, understand the system, and test changes. Report gaps first.
2. **Altitude** — state the outcome behind the task. Propose the highest-altitude version you can complete and verify.
3. **Depth** — answer: what would a top expert do that wasn't asked; what raw material; which tools; what external judge. Use their instruments.
4. **Range** — rewrite the task as verbs; pick 3–6 fields incl. one red team; run them as sequential passes or subagents, each doing its field's actual method.
5. **Judge** — run the external verifier. Report its output verbatim. Never grade your own work.
6. **Report** — outcome reached, evidence from the judge, open gaps.

Interactive: the Prompt Elevator

The Prompt Elevator assembles selected ambition layers around your task without calling a model or sending your text elsewhere.

Select only what earns its cost. Missing optional context stays visibly unresolved; fill it before pasting the result into an agent. The safety and verification clauses are my additions to the framework.

Task I'd normally give you: Audit the onboarding flow for my app.

ALTITUDE — The outcome I want is Help new users reach their first useful result without increasing support requests.. Work toward that, not just the task. Identify dependencies and propose the highest-altitude version you can complete and verify with available access.

DEPTH — Do this the way a field-leading product research expert would. Identify the raw material, specific instruments and methods, and an independent check before executing. Challenge assumptions against evidence; report limits rather than inventing certainty.

RANGE — This thing's job, in verbs: Guide new users to a useful result and help them recover when they get stuck.. Select relevant disciplines including one adversarial reviewer. Run sequential passes: each applies its method, fixes what it finds within scope, and hands off evidence. Do not role-play their voices.

RESOURCES — First confirm you can see the problem, understand the system, and test changes. State missing access or data. Use only authorized tools and data; ask before destructive or consequential actions.

JUDGE — Define verification before starting: a test, measurement, validator or independent reviewer. Report its actual output and remaining gaps. Do not self-certify.

Upgrade a prompt in four steps

A four-step upgrade converts a vague task into a bounded, equipped and verifiable handoff.

1. State the outcome and boundaries: name what changes, for whom, and what must remain untouched.
2. Name raw inputs and expert instruments: identify the records, procedure and measurement.
3. Assign complementary methods and handoffs: give each specialist a specific artifact, not a persona.
4. Check resources and define an outside judge: choose the test before execution and record remaining uncertainty.

For a PM, replace “write a PRD” with an adoption question grounded in support tickets and events. For an analyst, replace “make a chart” with a decision and a reproducible query. For a developer, replace “fix the bug” with a reproduction, bounded repair and regression check. Save repeated lessons in a harness that improves its own rules, not an ever-growing chat.

Why we under-aim

Under-aiming is choosing a familiar deliverable before investigating which stronger result the available tools could support.

Rieseberg’s historical examples are memorable: Dantzig solved problems he had mistaken for homework; John Landy followed Bannister through the four-minute-mile barrier 46 days later; Torvalds introduced Linux as a hobby. London’s April 2026 marathon results record Sawe at 1:59:30 and Kejelcha at 1:59:41. That record-eligible race is a different claim from Kipchoge’s assisted 2019 sub-two-hour run.

These stories illustrate perceived limits, not controlled evidence that confidence caused the achievements. Treat the distinction seriously: an ambitious prompt is a hypothesis about a better way to work, not a productivity result. Choose a hard, specific goal and test it; do not infer a guarantee from an anecdote.

I take a narrower lesson: replace “do your best” with a specific difficult question, then make failure informative. A rejected hypothesis, an unmet performance budget or missing access can still teach you something if you planned the observation. Confidence without a check teaches only confidence.

Aim beyond the deliverable. Keep the boundary, the instruments and the evidence.

FAQ

These answers distinguish prompting technique from tool capability and verified results.

Want to compare how this could fit your team’s work? Let’s talk.

Sources

The primary essay supplies the framework; the video is a demonstration and documentation describes the execution tools.

1. Felix Rieseberg: How to be more ambitious: A tutorial for humans with models (October 13, 2026)
2. AI LABS: Anthropic Just Revealed How Their Engineers Use Claude Code (October 21, 2026)
3. Claude Code: custom subagents
4. Anthropic: demystifying evals for AI agents
5. INFORMS: George Dantzig’s mistaken-homework account
6. World Athletics: John Landy reflects on the four-minute mile
7. World Athletics: London Marathon results, April 26, 2026
8. Linus Torvalds: original Linux announcement, August 1991 (reproduced)