Articles
Your Ceiling With AI Is Your Ambition: Four Dimensions of Speed, Altitude, Depth, and Range
Anthropic engineering lead Felix Rieseberg breaks "being more ambitious with AI" into four dimensions: speed, altitude, depth, and range. This post summarizes his approach and examples, plus my own working notes on giving goal-oriented instructions and orchestrating a Multi-AI Agents team of experts for multi-perspective cross-review to raise the quality of the work.
· 6 min read
Anthropic engineering lead Felix Rieseberg writes in "How to be more ambitious: A tutorial for humans with models" that when he sees someone else get a striking result out of AI, he and the people around him often have the same reaction: "We're not being ambitious enough."
My reading: the ceiling on how people use AI is usually their own ambition and imagination, not the model.
He breaks "ambition" into four dimensions:
- Speed: do the same work in less time.
- Altitude: raise the level of abstraction and look at the end result, not a single task.
- Depth: work to the standards, tools, and methods of the best experts in the field.
- Range: step outside a single domain and look for solutions across fields.
The conclusion up front: give precise, goal-oriented instructions and orchestrate a Multi-AI Agents team of experts for multi-perspective collaboration and cross-review, and the overall quality of the work goes up.
1. Speed: The Most Basic Dimension, and the One Few People Get Stuck On#
Do the same work in less time. Felix considers this one familiar to everyone, and the article skips it.
My take: speed is the most obvious value of AI, but if speed is all you chase, the way you collaborate won't change much. What really separates people is the other three dimensions.
2. Altitude: Ask "What's the Goal Behind the Goal?"#
The core question: What is the next result I actually want? What is the goal behind the goal?
Felix's examples:
- From fixing a crash to making the app stop crashing. He had been asking Claude to fix a single crash, then switched to asking for an app that stays at zero crashes. To make that run continuously on its own, he first had to change his own process: make crash reports easy to get, map app versions to Git commits, and let Claude use Windows, macOS, and Linux machines to reproduce crashes and verify fixes.
- Three levels of upgrade for a quarterly business review (QBR):
- Work from raw data as much as possible, and explain what changed this quarter, why, and what to do next.
- Identify the 3 most urgent decisions and write out the arguments for and against each.
- Design a replacement mechanism that spots problems earlier than the quarterly deck, test it on historical data, then run it in parallel with the current process for a quarter.
He also notes the limits: in 2026, a vague goal like "Claude, go make me money" doesn't work yet, but he expects the level of abstraction models can handle to keep rising.
3. Depth: Hold It to the Specs of the Field's Top Experts#
Felix's approach:
- Use the tools the industry actually uses. Models often change only the wording, not the method, and hand back a Markdown table and call it done. Insist on real analysis tools such as databases and statistical models.
- Set a goal that sounds unreasonable, and tell the model it is solvable. His example: after getting a website's load time from 10 seconds down to 5, ask for 200 milliseconds. When the model backs off, insist the goal is achievable.
- Challenge the assumptions you hold. Give the model raw data and have it test them adversarially. For example: "We think churn comes from onboarding. Try to reproduce that conclusion from the raw data."
- Produce new knowledge. Build a simulation from the logs, find the earliest churn signal you don't know about yet, then validate it on data the model hasn't seen.
- Find an outside judge. Don't let the model grade its own work. Ideally, attach a tool the model can run directly that gives immediate feedback for verification.
His prompting principle: ask for a "deeper version," not a "bigger version." Ask the model to say what a top professional would do beyond the ordinary, where the rawest data is, which methods and tools to use, and what, other than the model or your own judgment, can prove the result is right.
4. Range: Verbs Over Nouns, and Build a Team of Experts#
- Verbs over nouns. Felix takes this idea from The Art of Innovation. Rather than "a deck," a QBR is "helping busy people understand cause and effect and make a decision under uncertainty in 30 minutes." Define the goal with a verb and you can see which fields of skill it needs.
- Build a team. To make a good deck, bring in an analyst, a journalist, and an editor; to present it, add a motion and sound designer. For adversarial review, bring in a short-seller researcher and a forensic accountant.
- Don't do pointless role-play. Don't tell the model to "write in the voice of a short seller"; tell it to actually carry out one part of how a short-seller researches. Changing only the voice won't make the result any better.
The prerequisite: the model needs a computer where it can install software, and a way to reach the relevant data, such as through an MCP connector.
5. My Working Notes: From "Passing Data" to "Achieving Intent"#
What follows is my own extension, combining software architecture and engineering practice. It is not from the original article.
1. Jobs to be Done and Intent-Based Design#
- Don't ask "what to do"; ask "what to achieve." Design shouldn't stop at a passive data-passing pipeline like
generate_deck_pdf(). It should move up to a state-transition intent like resolve_leadership_uncertainty_and_commit_budget().
- Define the real loss function. Ask only for a deliverable and the model produces polished-looking nonsense; ask it to resolve uncertainty in a decision and the model and its Sub-agent will proactively fill in logical gaps and risk boundaries.
2. Diverge When Exploring, Converge When Accepting#
- When exploring, diverge first to find possibilities, then converge.
- When accepting results, don't diverge again. Unbounded questions like "what other ways could this be done?" only get you generic answers.
- State the goal scope, the constraints, and the objective verification tools (specific test scripts, business-metric thresholds), so the Multi-Agent team can stress-test within a focused frame and deliver high-quality results.
Summary of Takeaways#
- Goal orientation: Verbs over nouns. Deliver the result that solves the problem, not just an output to hand in.
- Exploration and convergence: Diverge when exploring to find possibilities; converge strictly when accepting, and verify the boundaries.
- Abstraction focus: Start from the core question and rebuild the whole task flow.
- Expert depth: Don't just imitate an expert's voice; push the model to solve the problem with the top expert's tools and methods.
Original article: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)