---
title: "Felix Rieseberg on AI ambition: altitude, depth and range"
description: "Felix Rieseberg, who leads Claude.ai work at Anthropic, splits AI ambition into speed, altitude, depth and range, and explains the last three with a QBR example and cautions."
url: https://udon-dev.com/en/notes/claude-ambition-tutorial/
lang: en
published: 2026-10-15
topic: [ai]
tags: ["claude", "anthropic", "prompting", "ai-agent", "goal-setting"]
---

# Felix Rieseberg on AI ambition: altitude, depth and range

- Felix Rieseberg splits ambition in using AI into four directions: speed, altitude, depth and range. He treats speed (doing the same work in less time) as already settled and illustrates the other three with examples
- Altitude means asking for the outcome beyond the task. Depth means having the model work with the tools and raw materials that top experts in the field use. Range means gathering perspectives from several fields
- His cautions: don't let the model grade its own results; use external judgment instead. Have it use methods, not play roles. Give it a computer where it can install software, plus access to the data
- As reasons ambition matters, he cites self-efficacy and goal-setting research showing that specific, difficult goals produce higher performance than "do your best"

People who use AI keep hearing that they should use it more ambitiously. What you should actually do to be more ambitious is rarely spelled out. Felix Rieseberg published a tutorial on exactly that question on [his blog](https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/) on October 13. He is an engineering manager at Anthropic who has led development of Claude.ai, Cowork and Claude Code Desktop. He acknowledges that among people working on AI, writing "we're not ambitious enough" has become a rallying cry, and says the advice is hard to act on. So he writes down concrete methods.

He mainly uses Claude, but says the advice is not specific to any one model.

## Four directions of ambition

Rieseberg splits ambition in using AI into four directions.

| Direction | Meaning |
|---|---|
| Speed | Finish the same work in less time |
| Altitude | Raise the level of abstraction and think about the outcome beyond the individual task |
| Depth | Like a leading expert in the field, work with the data, tools and problems one layer below the task |
| Range | Use knowledge and tools from fields you don't normally use, not only the ones the task obviously requires |

Speed is at the center of AI's economic value, is already established and needs little technique, so he skips it. He explains the other three with the same example: preparing materials for a quarterly business review (QBR) at a fictional company, "Acme Inc." Give Claude the data and it will make slides; give it a template and it will fill it in. From there, he changes the request one step at a time.

## Altitude: ask for the outcome beyond the task

Altitude starts from the view that a task you hand to a model is only your best guess at how to get the outcome you want. So you ask yourself what you want to happen next, and what the goal behind the goal is. At the beginning of last year he was asking Claude to fix individual crashes. Eventually he asked it to keep the apps crash-free.

In the QBR example, he raises the request in three steps.

1. Instead of having it update the numbers in the template, give it as much data as you can and ask, "Tell me what changed this quarter, why, and what we should do about it."
2. A good meeting ideally ends with a decision, so ask, "Work out which three decisions are most urgent in the face of everything you've learned, and start working on potential directions with for/against arguments."
3. Treating the QBR as a mechanism from an era when people had no choice but to read the data carefully themselves, ask, "The review exists so leadership catches problems early and moves money and people to the right places. Design a better way to do that than a quarterly deck, show from our own history that it would have caught things sooner, and run it beside the current one for a quarter."

Altitude works well when the final outcome you want is clear, and less well for creative work. If you're about to call a meeting about the work you're doing, that is a good signal to raise the altitude. There are limits. "Claude, go make money" doesn't seem to work for most businesses by itself in 2026, but he sees models able to operate at higher levels of abstraction as their capabilities improve. Running the new method in parallel with the current one for a quarter in the third step reads as a way to compare the two on actual results.

Raising the altitude also lets you build systems that keep running without a person handing over the next task each time. Making that work often requires changing how the work flows. Before handing crash elimination to Claude, he made it easy for Claude to fetch crash reports and to map app versions to Git commits. He also gave it access to Windows, macOS and Linux computers so it could reproduce and verify fixes on its own.

## Depth: give it the tools and raw materials of top experts

Depth is the direction for when you want the work itself done to a high standard. You have the model use the tools, methods, media and knowledge that the best experts in the field use, and push until even an expert could learn something. In the QBR example, assuming Acme Inc is struggling with customer churn, he lists five methods.

- **Use the same tools as the best**: Ask a model to act like an expert and it often changes only its vocabulary, not its methods. If Claude tries to get by with a Markdown table, ask it to use a database and statistical models. Even if you don't know what experts use, Claude usually does
- **State an outrageous goal as if it were obvious**: If you want to cut a website's load time from 10 seconds to 5, ask for 200 milliseconds. If the model says it seems impossible, keep repeating that the problem is solvable and it just needs to keep going
- **Have it challenge your assumptions**: Give it the raw information and data, and have it check your premises with the aim of disproving them. His example: "We believe churn is an onboarding problem. Try to reproduce that from the raw data."
- **Have it create new knowledge**: Once it is deep in the data, have it look for blind spots. His example: "Build a simulation of our customers that reproduces the last year from our logs. Then find the earliest signal of churn we don't know about yet, and show it predicts on data it has not seen."
- **Use external judgment**: Don't let the model grade itself. He expects rising model intelligence to solve this eventually, but as of October 2026 strongly recommends requiring external verification. The ideal is a tool the model can run itself and get results from right away

He also shares a prompt he often uses:

```text
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.
```

The fourth question settles the "external judgment" from the list above at the request stage. I covered the burden of reviewing what AI produces in [AI increased code, but not necessarily finished work: understanding debt (Japanese)](/notes/ai-code-volume-understanding-debt/).

## Range: gather perspectives from other fields

Range means looking at the work through the eyes of several fields. What AI changed, in his view, is that you can now bring in more fields than used to be worth the effort. Because multi-agent setups (multiple threads, orchestrators, subagents) have become easy to use, asking Claude to bring in another field has produced interesting results.

Putting it into practice takes imagination. He writes that despite having made games, it didn't occur to him to build a 3D space for his homepage with Claude until he watched a colleague render an interior design in Blender. He uses two methods.

- **Replace nouns with verbs**: This is a technique from Tom Kelley and Jonathan Littman's *The Art of Innovation*. A quarterly review isn't "a deck." It's "getting busy people to believe a story about cause and effect, and to decide under uncertainty, in 30 minutes." Turning it into a verb makes it easier for both people and Claude to see which fields could bring a useful perspective
- **Assemble a team**: Imagine that the deck has to be amazing, or aliens will blow up Earth. What team would humanity put together? For the quality of the result, bring in an analyst, a journalist and an editor; if it will be presented, add motion and sound designers too. To attack it from the opposite side, add a short seller and a forensic accountant who investigates accounting fraud

He warns that this technique easily slides into role-play by accident. Having the model play a role only makes the conversation odd and doesn't improve the result. The point of the technique is to find the fields and methods that help. Instead of having it play a short seller, have it carry out the research a short seller does before taking a position.

## The shared premise: give it an environment to work in

He says every one of these directions assumes the model has a computer where it can install software, and access to the relevant data through MCP connectors or similar. Many tools can set up that kind of environment, and he recommends using one of them. In the crash example, preparing report access and computers on three operating systems before handing the job to Claude is this premise in practice.

## Why ambition matters: self-efficacy and goal-setting research

In the second half of the post, he explains why this tutorial is needed. In his view, people have always been limited by what they believe is possible, and they believe in themselves only in very narrow areas. As an example, he mentions Michelangelo, a sculptor, who did not want to paint the ceiling of the Sistine Chapel.

He notes that psychology calls this [self-efficacy](https://en.wikipedia.org/wiki/Self-efficacy). Self-efficacy is the belief that you can take the actions needed to reach a goal, a concept the psychologist Albert Bandura proposed in 1977.

As evidence that self-efficacy can be raised, he points to research by Edwin Locke and Gary Latham. In their [2002 paper](https://med.stanford.edu/content/dam/sm/s-spire/documents/PD.locke-and-latham-retrospective_Paper.pdf) summarizing 35 years of goal-setting research, specific, difficult goals consistently led to higher performance than urging people to "do your best." The paper explains that a do-your-best goal has no external referent, so each person interprets it differently. The harder the goal, the higher the performance; performance leveled off or dropped only when people reached the limits of their ability or when their commitment to a difficult goal lapsed. The depth section's "state an outrageous goal as if it were obvious" reads as the same idea applied to how you ask a model.

He also points to Stripe founder Patrick Collison's ["Fast" list](https://patrickcollison.com/fast), which collects what people achieved under ambitious goals and short deadlines. It includes launching BankAmericard (later Visa) in 90 days and designing and delivering the P-80 jet fighter in 143 days. He lists three things that help people achieve hard things.

- **Believe it's possible**: In 1939, George Dantzig arrived late to a statistics class, took the two problems on the blackboard for homework, solved them and handed them in. They were unsolved problems in statistics
- **See someone else do it**: Running a mile in under four minutes had long been a target, but after Roger Bannister did it in May 1954, another runner followed 46 days later
- **Allow yourself to fail**: He cites *The Inner Game of Tennis* and its argument that you can't play your best tennis when you try too hard, and Linux, which was announced as "just a hobby, won't be big and professional like GNU"

Self-efficacy is not a new problem, he writes, but its impact is larger now that capabilities leap forward every few weeks. That is why we need ways to reach for things we didn't think were possible, which is the conclusion of the post.