In the Age of AGI, Our Ambitions Are Still Far Too Small | 5Y View

Every leap in technological paradigm redefines what is possible. But the people who truly seize the opportunity are rarely the first to master the tools — they are the first to realize they can aim for something far greater.

In the age of AI, what we need to recalibrate is not just our assessment of technical capabilities, but our imagination of future possibilities.

A great era demands not only more powerful technology, but more audacious ambition.

The author, Felix Rieseberg, is an engineering manager at Anthropic. He has led engineering for Claude.ai, Cowork, and Claude Code Desktop, and is a co-maintainer of open-source projects including Electron.

(There's a surprise at the end.)

By Felix Rieseberg

I've been involved in building Claude. There's always a fascinating experience that comes with it: every day, I hear about someone using Claude — or Claude itself — to accomplish something remarkable; things I never thought of, things I thought impossible, or things I simply lacked the curiosity and time to try. This month, it may have helped discover a new planet; I saw the first AI music video I actually liked; and we're discussing a new era for mathematics.

Model capabilities do not grow uniformly. As Terence Tao put it, models are "amazing at some things and subhuman at others." Some people have already learned to harness those amazing capabilities, as if taking flight. Watching people reach unimaginable heights with a product I helped build is utterly addictive. Many others are still figuring out how to make these new wings work, unsure what to do beyond asking "what is the capital of France" or "can you make this email sound less angry."

I often join other AI practitioners in calling for greater ambition in how we use AI. It has become something of a mantra. Whenever we see something astonishing, we reshare it with the note: "We are not being ambitious enough." I know it's not easy to actually act on this, so I wrote this tutorial on how to become more ambitious.

I divide "ambition" into four dimensions: speed, altitude, depth, and breadth.

Speed: Completing the same work in less time — the basic way AI creates economic value. For example, you need to write some code, and I can do it faster with Claude. This usage is already mature and doesn't require much creativity, so I'll skip it.

Altitude: Raising the level of abstraction in your thinking, focusing on end outcomes rather than individual tasks.

Depth: Approaching tasks like the top expert in a field. Not staying on the surface, but going one layer deeper to touch the underlying data, tools, and problems.

Breadth: Drawing on multiple domains, not limiting yourself to the one domain the task superficially seems to require, using knowledge, tools, and methods you wouldn't normally employ.

I primarily use Claude, but these recommendations are not limited to any single model.

Altitude

We casually call this "having the model work at a higher level of abstraction." When you give a model a task, it executes what you believe is the most likely way to achieve the desired outcome. To be more ambitious in altitude, ask yourself: what do you want to happen next? What is the goal behind this goal? Early last year, I was still asking Claude to fix individual crashes one by one. Later, I simply asked Claude to make sure our app stopped crashing altogether.

Let's look at an everyday office task — perhaps a mundane one. Suppose you work at a fictional company, Acme Inc, and need to prepare a presentation for a quarterly business review (QBR). Give Claude a batch of data, and it will gladly make you a few slides. You probably already have a template, and it just needs to fill in the content. This is hardly comparable to discovering a new planet, so let's see what concrete steps can make this more ambitious. We'll start from the basics and raise the goal with each step:

Most reviews need to answer: what changed this quarter, why, and how should we respond. Don't just think about updating numbers in a template. Give the model all the data you can get your hands on and let it understand your business: "Tell me what changed this quarter, why, and how we should respond."

Meetings should ideally end with some decisions. Ask Claude: "Based on everything you've learned, identify the three most urgent decisions we need to make, and start researching possible directions, listing pros and cons."

The quarterly business review was born in an era where people had to carefully sift through data to figure out what it meant and whether the business needed adjustment. Ask Claude: "The purpose of the review is to let management spot problems early and allocate capital and people appropriately. Design a better way to achieve this than quarterly presentations, prove with our own historical records that it can spot problems earlier, and have it run in parallel with the existing method for one quarter."

If you are indeed pursuing some final outcome, raising altitude works best; for creative work, it is less effective. One useful signal: if what you're doing will require a follow-up meeting, it's usually worth trying to be more ambitious in altitude. There are of course limits — in 2026, for most businesses, simply saying "Claude, go make money" probably won't work. But in general, I've found that the stronger the model, the more it can work at higher levels of abstraction.

Raising altitude can also help people find workflows that run continuously without human intervention, so you don't have to assign tasks to the model one by one. Doing this well often requires changing your workflow. To have Claude ensure our app stopped crashing, I first had to make sure it could easily access crash reports, know which Git commit corresponded to each app version, and give it access to Windows, macOS, and Linux machines so it could independently reproduce problems and verify fixes.

Depth

Sometimes, you just want to do a task exceptionally well. Being more ambitious in depth means pushing the model to use the tools, methods, media, and knowledge employed by the best professionals in a field, and going deeper until even those professionals might learn something new from your work.

Continuing with the Acme Inc quarterly business review example. Suppose the company is facing a user churn problem — customers leaving over time. I've found the following approaches helpful:

Insist on tools used by industry leaders: When you ask a model to work like a professional, it often just changes its vocabulary without actually changing its approach. To solve problems deeply, we need to use the tools of top data scientists and statisticians. When Claude is about to use a Markdown table, insist it use databases and statistical models. You don't necessarily need to know what experts use, but Claude usually does.

Set seemingly unreasonable goals and tell the model they are reasonable: Want to reduce your website load time from 10 seconds to 5? Demand 200 milliseconds. Does the model think something is impossible? Repeatedly tell it that this problem is entirely solvable, it just needs to keep trying.

Question what you think you know: Especially in business, much of what we believe to be true is just a rough approximation of reality. Have the model access raw information and data, and ask it to test assumptions with the intent to refute. "We believe churn is caused by onboarding issues. Try to reproduce this conclusion from raw data."

Produce new knowledge: This follows naturally from questioning existing conclusions. Once Claude has gone deep into the data, have it look for blind spots. "Based on our logs, build a customer simulation model that reproduces the past year. Then identify the earliest churn signal we haven't yet discovered, and prove it has predictive power on unseen data."

Bring in external judgment: Don't let the model judge itself. I imagine this problem will eventually be solved as models become more intelligent, but as of October 2026, I implore you to insist on external validation. Ideally have a tool the model can run itself to get immediate feedback.

This simple prompt often helps me:

I want to take this task deeper, not make it bigger. Before rewriting:

(1) Say what top professionals in this field would do that I haven't asked for;

(2) Point out what raw materials they would start from, rather than using content already processed for me;

(3) List the specific methods and tools they would use;

(4) Explain how, besides you and me, the results could be proven correct. Then rewrite my prompt to explicitly require these things.

Breadth

Simply put, being more ambitious in breadth means examining our work from the perspective of different fields — involving so many domains that in the past it wouldn't have been worth the cost. This isn't a particularly novel insight: every heist movie spends its first 30 minutes assembling a crew of people from wildly different backgrounds, each with their own specialty. As AI products make running multi-agent systems increasingly easy — whether through multiple threads, orchestration schedulers, or simply using sub-agents — I've found that asking Claude to bring in more domains produces fascinating results.

Putting this into practice isn't easy; it requires creativity. Before seeing my colleague Alex Albert use Blender to render interior design, I never thought to have Claude create 3D scenes for my personal homepage, even though I used to make video games! Yet this is also where I've seen the most magical results.

So, how to do it specifically? I use these methods:

Try replacing nouns with verbs: This is an old technique from Tom Kelley and Jonathan Littman's The Art of Innovation. A quarterly review is not "a presentation" but "in 30 minutes, convince busy people of a causal explanation and enable decision-making under uncertainty." Describing it with verbs makes it easier for both me and Claude to understand which domains might offer unique and useful perspectives.

Assemble a team: This presentation must be good enough or aliens will blow up Earth. What team would humans assemble? To ensure quality, I'd bring in an analyst, a journalist, and an editor. If it also needs to be presented live, maybe add a motion and audio designer. A dedicated "red team" to find flaws might help too — so bring in a short seller and a forensic accountant.

This process can easily devolve into roleplay that just makes the conversation weirder without improving actual results. Use this method to find relevant domains and approaches. Don't have the model imitate a short seller's writing voice; have it do research the way a short seller researches their own positions.

All these methods for increasing ambition that I've described require the model to have access to a computer, be able to install software, and access various relevant data, whether through MCP connectors or other means. Many tools already enable this, and I suggest you pick one to use.

We've Been Here Before

Those are my concrete suggestions for how to be more ambitious. If you're willing to read a bit more, I'd like to talk about why I think this is necessary.

We humans have always been constrained by our own judgments of "what is possible." Worse, we usually only believe in our capabilities within very narrow domains of expertise. As is well known, Michelangelo was reluctant to paint the Sistine Chapel — you see, he was a sculptor, not a painter.

In researching ambition, I learned that psychology has a specific concept for this: self-efficacy. Simply put, people with high self-efficacy believe more in their abilities and therefore achieve more. There is evidence that self-efficacy can be improved through certain methods: Locke and Latham carefully studied 35 years of goal-setting research and reached a clear conclusion — people assigned specific, difficult goals perform better than those simply asked to "do their best." Stripe founder Patrick Collison maintains a list called "Fast," documenting many things humans have accomplished with bold goals and tight deadlines. The following methods are well-documented:

• Believing difficult things can be done, and thus doing them: In 1939, George Dantzig arrived late to a statistics class at UC Berkeley. He copied two problems from the blackboard, thinking they were homework, solved them, and turned them in. They were actually two unsolved problems in statistics.
• Seeing others do difficult things, and then doing them yourself: For decades, humans pursued running a mile in under four minutes. Roger Bannister broke through in May 1954, but as the only person to do so, he held the record for just 46 days. If you follow running, you see something similar happening with the two-hour marathon barrier: this April, Sabastian Sawe ran the first officially recognized sub-two-hour marathon in London. In the same race, the runner-up also broke two hours.
• Allowing yourself to fail, and thus accomplishing difficult things: I only discovered last week that The Inner Game of Tennis seems to be everyone's favorite business book. Its core insight is that when you desperately try to play tennis well, you cannot perform at your best. We engineers may remember Linux's early release note: "Just a hobby, won't be big and professional like GNU."

Self-efficacy is not a new problem, but its impact is greater now. In a world where our capabilities leap forward every few weeks, we need methods to help ourselves do things we never seriously considered or didn't believe possible. If you discover more ways to make yourself more ambitious, please let me know!

The illustrations in this article are from Francisco Goya's Modo de volar (The Way of Flying).

From the editors: We have turned the methods described in this article into a Skill for your use ↓

https://github.com/whereisnoki-stack/skills/raw/refs/heads/main/ambition-upshift-v1.0%281%29.zip

Original article: https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/