Author: QbitAI
Set some unreasonable goals, then tell the model: this is completely reasonable!
This is a little AI usage tip shared by Felix Rieseberg, the head of Claude Code desktop.
How exactly do you do it?
Suppose you want to cut a website's load time from 10 seconds to 5 seconds. He suggests:just set the goal at 0.2 seconds.
The model says it can't be done? Then keep telling it: this problem can absolutely be solved, try again, try again.
In Felix's view, we can be even bolder when assigning tasks to AI.
For example, the original task was "make a reporting PPT." It can be rephrased as:
Within 30 minutes, convince a group of busy people of your explanation of the causes and consequences of the matter, and make a decision while the situation is still unclear.
Besides deliberately setting aggressive goals, he also offers several specific approaches:
Don't just tell AI to "think like an expert." Then follow up by asking: what raw materials would a real expert look at, what tools would they use, what methods would they adopt, and then write these requirements into the task.
Don't treat your own judgment directly as the answer. Hand it over to AI for verification, and have AI go back to the original materials to look for evidence supporting it, as well as counterexamples that might overturn it.
Don't let AI grade itself. If it's code, actually run it; if it's a prediction, test it with new data, and ultimately let the real results speak.
Below is Felix's detailed tutorial on using (tuning) and (teaching) Claude, lightly edited.
Enjoy~
With AI, we can be even more ambitious
I work on the Claude team.
What makes this job fascinating is that almost every day I learn that yet another thing has been accomplished with the help of Claude—or even independently by Claude.
Some things I had never thought of, some I originally thought were impossible; and some were simply things I myself was neither curious enough nor had the time to try.
Just this month, Claude may have helped discover a new planet; I saw the first AI music video that I genuinely liked; we even started discussing whether a new era of mathematics is arriving.
A model's various capabilities do not advance in lockstep. As Terence Tao said, they are "amazing in some directions, yet still lacking in others."
Some people have learned to harness the model's astonishing capabilities, as if they had truly taken flight. Watching them reach such heights with a product I built with my own hands is truly fascinating.
More people are still figuring out how to make good use of these newly grown wings. They are still pondering: besides answering "What is the capital of France," or "Can you make the tone of this email gentler," what else can AI do?
Many of us in the AI industry often say one thing:with AI, you should be more ambitious.
This phrase has almost become our rallying cry. Whenever we see astonishing results, we repost them with a line: "We are still not ambitious enough."
I also know that saying this is easy, but actually doing it is hard. So here is a tutorial on "how to be more ambitious."
I divide ambition into four categories:speed, height, depth, and breadth.
Speed: completing the same work in less time. This is the most basic way AI creates economic value.
For example, when writing a piece of code, with Claude's help I can finish it faster. This usage is already quite mature, and there is not much need to explore more complex ways of using it, so I will skip it here.
Height: raising the level of abstraction of the task, focusing on the final outcome you want to achieve rather than on individual concrete tasks.
Depth: thinking about the task like a top expert, going further into the underlying data, tools, and problems.
Breadth: seeking approaches to solving problems from multiple fields, and also using knowledge, tools, and methods you would not normally come into contact with.
Although I mainly use Claude, these suggestions are not aimed at any particular model.
Height: Let the model work at a higher level of abstraction
We often casually call this approach "letting the model work at a higher level of abstraction." When you give the model a task, it is actually executing your best idea of how to achieve the desired outcome.
If you want to think from a higher dimension, you might ask yourself—what do you want to happen next? And what is the goal behind the goal?
At the beginning of last year, I was still asking Claude to help me fix individual program crashes. Later, I directly asked it to ensure our application always runs without crashing.
Let's look at an everyday office task (frankly, even a bit tedious).
Suppose you are at Acme Company and need to prepare a PPT for a quarterly business review (QBR). Give Claude a bunch of data, and it will gladly help you make it; maybe you already have a template, and it just needs to fill in the content.
This really cannot compare with discovering a new planet. But for the same quarterly report, what else can we get AI to do? We can start from the most basic requirements and raise our ambitions step by step:
Step one: have it understand what happened in the business.
Most reviews need to answer these questions: What changed this quarter? Why? What should be done next?
If you only want to update the numbers in the template, please restrain that impulse—give the model as much data as you can get your hands on, let it truly understand your business, and then ask it:
Tell me what changed this quarter, why it happened, and what actions we should take.
Step two: have it identify the decisions that need to be made.
A meeting—at least a good meeting—should ideally end with some decisions. You can ask Claude like this:
Based on everything you have learned, determine the three most urgent decisions right now, and analyze the possible directions for action, listing the arguments for and against each.
Step three: have it redesign this working mechanism.
In the past, to do a good quarterly business review, humans had to carefully filter the data, understand what the data meant, and then judge whether the business needed adjustment.
Now, you can try asking Claude:
The purpose of the review is to let management discover problems as early as possible and allocate capital and personnel to the right places.
Please design a better way to achieve this than a quarterly PPT, use our own historical data to prove which problems it could have discovered earlier, and then run it in parallel with the existing method for one quarter.
When you are truly pursuing a final outcome, the method of raising the level of the goal is most effective; but for creative tasks, its applicability is relatively limited.
A very good signal for judgment is: if what you are doing will still need a meeting to discuss afterward, then it is worth raising the goal one more level.
Of course, limitations still exist—at least in 2026, for most companies, simply saying "Claude, go make money" does not seem able to make things run automatically.
However, my overall observation is: as capabilities increase, models seem increasingly able to work at higher levels of abstraction.
Raising the level of the goal can also help people find workflows that run sustainably without continuous human intervention, so you do not have to assign new tasks to the model one after another.
To do this well, it often requires changing existing workflows.
For example, to have Claude ensure our application does not crash, I first had to let it easily access crash reports, understand which Git commit each application version corresponds to, and give it permission to access Windows, macOS, and Linux computers. Only then could it truly independently reproduce problems and verify whether fixes were effective.
Depth: use top experts' methods to thoroughly work through the problem
Sometimes, you just want a task to be completed especially well.
Being more ambitious in "depth" means pushing the model to use the tools, techniques, media, and knowledge used by the best professionals in this field, and continuously raising the bar—until even these experts might learn something new from your results.
Let's continue with Acme Company's quarterly business review. Suppose this company is facing a user churn problem, that is, customers continuously leaving over time.
I have found that combining the following methods is very helpful:
Insist on using the tools used by top people in the industry
When you ask a model to "work like a professional," it often just switches to a set of professional vocabulary, while the actual method remains unchanged.
To truly study a problem in depth, you have to use the tools used by top data scientists and statisticians. When Claude reaches for a Markdown table, insist that it switch to databases and statistical models.
You do not need to know in advance what experts would use—Claude usually knows.
Set "unreasonable" goals, then tell the model they are very reasonable
You want to shorten website loading time from 10 seconds to 5 seconds? Ask directly for 0.2 seconds.
Does the model think something is impossible? Emphasize to it again that this problem can definitely be solved and that it needs to keep trying.
Challenge conclusions you have already accepted
Especially in business, many things we believe to be facts are only rough approximations of reality.
Let the model access raw information and data, and examine those assumptions with a skeptical attitude.
For example:
We believe that user churn is a problem in the new user onboarding process. Please try to reproduce this conclusion from the raw data.
Discover new knowledge
This step easily follows "challenging existing cognition"—since Claude has already gone deep into the data, continue asking it to look for blind spots:
Build a customer simulation model based on our logs to reproduce the situation over the past year. Then, identify the earliest signals that foreshadow user churn and that we do not yet know about, and validate the predictive capability with data it has never seen.
Introduce external evaluation
Do not let the model evaluate itself.
I think that as model intelligence continues to improve, this problem will eventually be solved. But in October 2026, I strongly recommend that you stick with external validation.
Ideally, the validation method should be a tool that the model can run on its own and get immediate feedback from.
The following simple prompt often helps me:
I want to take this task deeper, not expand its scope. Before rewriting the task, please first complete four things:
Explain what top professionals in this field would do that I have not yet asked for.
List the most raw materials they would start from, rather than directly using content that has already been organized and digested for me.
List the specific methods and tools they would use.
Explain what, besides you and me, could prove that the result is correct.
Then, rewrite my prompt and write these requirements into it accurately.
Breadth: Also use methods from other fields
Being more ambitious in "breadth" means examining your work from the perspectives of different fields.
The fields involved can be more numerous than in the past, because doing so in the past was often not cost-effective.
This idea is not new. In almost every movie about experts teaming up, the first 30 minutes are spent assembling a group of people with different backgrounds and different strengths.
As AI products make multi-agent systems easier and easier to run—whether through multiple threads, an orchestrator, or directly using sub-agents—I find that having Claude bring in ideas from other fields often leads to some very interesting results.
Putting it into practice is not easy; it requires you to use your creativity.
Before I saw my colleague Alex Albert use Blender to render interior designs, I had never thought of using Claude to create a 3D environment for my homepage.
You should know, I used to make video games!
However, this is also exactly where I most often see surprises.
How to do it specifically? I use the following methods.
Try replacing nouns with verbs
This is an old method mentioned by Tom Kelley and Jonathan Littman in The Art of Innovation.
The purpose of a quarterly review is far more than producing "a PPT." What you need to do is:
In 30 minutes, convince a group of busy people of an explanation of the causes and consequences of a matter, and make a decision under uncertainty.
Describing the task with verbs makes it easier for me and Claude to see which fields can provide unique and useful perspectives.
Build a cross-disciplinary team
Suppose this PPT must be stunning, otherwise aliens will blow up the Earth. What kind of team would humans assemble?
To ensure the quality of the final product, I would bring in an analyst, a journalist, and an editor.
If an on-site presentation is also needed, I might also need a motion designer and an audio designer.
Bringing in a dedicated "red team" that looks for flaws might be very helpful, so I would also bring in a skeptic and a forensic accountant.
However, this approach can easily turn into role-playing by accident. The result is only that your conversation with the model becomes stranger, while the actual outcome does not improve.
You should use this method to find useful fields and techniques. Directly asking the model to conduct an investigation the way a skeptic studies an investment target is more meaningful than asking it to write such a character.
All the methods I introduced earlier require the model to have a computer it can operate, be able to install software, and access various relevant data, whether through MCP connectors or other means.
There are now quite a few tools that can provide these conditions, and I suggest you choose one and use it.
Self-efficacy: People also need to update their judgments of their own abilities
The above are my specific suggestions on "how to be more ambitious."
If you are willing to stay a little longer, I want to talk about why it is necessary for us to discuss this issue.
Humans have always been limited by their own judgments: what we think is possible and what we think is impossible. What is more troublesome is that we usually think we can only make a difference in a very narrow field.
Michelangelo's reluctance to paint the Sistine Chapel is a famous example. He considered himself a sculptor and lacked identification with the identity of a painter.
[Francisco Goya is one of the greatest painters in Spanish history, regarded as a pioneer of Romantic painting and a key figure connecting the classical masters with modern art]
While studying the question of "ambition," I learned that psychology has a related concept: self-efficacy.
Simply put, people with higher self-efficacy believe more in their own abilities, and therefore can accomplish more things.
There is evidence that self-efficacy can be improved through certain methods.
Locke and Latham reviewed 35 years of goal-setting research and reached a clear conclusion: people who are given clear and challenging goals perform better than those who are merely told to "do their best."
Stripe founder Patrick Collison maintains a list called "Fast," recording what humanity has accomplished under bold goals and urgent deadlines.
Below are several well-documented methods.
Believe that difficult things can be done
In 1939, George Dantzig arrived late to a statistics class at Berkeley.
He copied down the two problems on the blackboard, assuming they were homework, and later submitted his solutions.
In fact, those were two unsolved problems in statistics.
See others do it, then go complete difficult things
For decades, humanity had been trying to run a mile in under four minutes.
In May 1954, Roger Bannister broke through this barrier. But the situation of "only him in the world running under four minutes" lasted only 46 days.
If you follow running, you'll notice that something similar is happening with the two-hour barrier in the marathon.
This April, Sabastian Sawe ran the first sub-two-hour marathon in an official race in London. The runner-up in the same race also ran under two hours.
[The two-hour marathon barrier: The full marathon is 42.195 kilometers, and humanity's "breaking 2" (running under two hours) is considered a landmark physical threshold on par with the "four-minute mile"]
Allow yourself to fail, then challenge difficult things
"The Inner Game of Tennis" seems to be a business book that everyone loves, and I only discovered it last week.
The core idea of the book is: when you try desperately hard and overexert yourself, you actually cannot play your best tennis.
We engineers may still remember how Linus described Linux when it was first announced:
I'm doing this thing just for fun, it won't be as grand and professional as GNU~
(Who could have imagined that Linux would later become such a big deal, while the GNU kernel still hasn't been completed to this day...)
Self-efficacy is not a new problem, but it has become so, so important today!
In an era where capabilities leap forward every few weeks, we urgently need some methods to accomplish things we have never seriously considered, or even never believed we could do.
