Don't treat large language models as interns: Reconstruct human-machine collaboration through the three dimensions of "height, depth and breadth"

Shenyi Bureau is a translation and compilation team under 36Kr, focusing on technology, business, workplace, life and other fields, with a focus on introducing new technologies, new perspectives and new trends from abroad.

Editor's Note: Most people only use top large language models as a polishing tool. A core developer of Claude personally states that what widens the gap between people is not prompts, but the ambition of usage. This article comes from translation and compilation.

I participated in the development of Claude. It has been a really interesting experience: every day I hear about someone else who has accomplished a great feat with the help of Claude (or independently by Claude). Some directions I have never thought of, some I once thought impossible to achieve, and others I simply lacked the curiosity or time to try. Just this month, it may have assisted in the discovery of a new planet, I saw the first AI music video that truly impressed me, and people have started talking about a new era of mathematics.

The growth of model capabilities is not balanced. As Terence Tao put it, models are "amazing in some aspects, but powerless in others". Some people can harness those amazing capabilities as if they are riding the wind. It is truly fascinating to watch people reach incredible heights with the product I helped build. But many others are still figuring out how to move these new-born wings, not knowing what else it can do besides asking "What is the capital of France?" or "Can you rewrite this email to make it less aggressive?".

Me and other AI practitioners often call for that we should be more ambitious when applying AI, which has become a slogan. Whenever we see amazing results, we repost it with a comment that "our ambition is not enough". I understand that it is not easy to follow this advice, so I wrote this guide on how to be more ambitious.

I divide ambition into four types: Speed, Altitude, Depth and Range.

• Speed: Complete the same work in less time, which is the basic foundation for AI to create economic value. For example, when I need to write a piece of code, I can write it faster with Claude. This point is already quite mature, and it does not require much creativity in usage, so I will skip it.

• Altitude: Raise the level of abstraction, focus on the final result rather than a single task.

• Depth: Look at the task like a top expert in this field. Do not stay at the level of the task itself, but go one layer deeper to directly touch the underlying data, tools and problems.

• Range: Do not be limited to the single field that the task superficially belongs to, but call on knowledge, tools and skills from multiple fields, including those you would not normally use.

I usually mainly use Claude (needless to say), but my suggestions are not targeted at a specific model.

Altitude

We often casually call it "let the model work at a higher level of abstraction". When you assign a task to the model, what it actually executes is your best guess of "how to get the desired result". To be more ambitious in terms of "Altitude", you might as well ask yourself: What do you want to happen next? What is the goal behind the goal? At the beginning of last year, I was still letting Claude help me fix crash issues one by one; later, I directly asked Claude to take charge of ensuring that our application does not crash.

Let's look at a daily (even boring) office scenario. Suppose you work for a fictional company Acme Inc, and you need to prepare a presentation for the Quarterly Business Review (QBR). Given a bunch of data, Claude will be happy to generate several pages of slides for you. Maybe you even have a template, and it only needs to fill in the content. This is obviously not comparable to discovering a new planet, so let's look at several specific steps to make this task more ambitious. We start from the most basic practice, adding a little more ambition at each step:

• In terms of input, what most reviews want to know is: what changed this quarter, why it changed, and how we should respond. Resist the urge to only update a few numbers in the template, and give the model as much data as you can get to let it understand your business: "Tell me what changed this quarter, why it happened, and what we should do."

• Meetings (at least good meetings) ideally end with several decisions. You can say to Claude: "Based on everything you know, identify the three most urgent decisions, and start sorting out the arguments for and against each potential direction."

• QBR was born in an era when people needed to manually screen data carefully, interpret the meaning of data, and judge whether the business needed adjustment. You can say to Claude: "The purpose of the review is to let the management detect problems early, and allocate capital and manpower to the right places. Please design a better way to achieve this than quarterly presentations, use our own historical data to prove that it could have detected problems earlier, and run it in parallel with the existing process for a quarter."

The "Altitude" trick works best if the final result you are really pursuing is a certain outcome; it is less effective for creative work. A good signal to judge whether it is suitable to raise "Altitude" is: whether you are going to have a meeting next to discuss the thing you are working on. This approach still has limitations at present (in 2026, for most enterprises, just saying "Claude, go make money" does not work yet), but I generally observe that the stronger the model, the better it can work at a higher level of abstraction.

People will also find sustainable workflows at the "Altitude" level: it eliminates the need for you to intervene all the time, so you do not have to keep giving the model instructions task after task. To do this well, you often need to adjust your workflow. For example, in order to let Claude ensure that our application does not crash, I first have to make sure that it can easily access crash reports, figure out which git commit each application version corresponds to, and let it use Windows, macOS and Linux computers, so that it can truly reproduce the problem independently and verify the fix.

Depth

Sometimes, you just want to do a task to the extreme. To be more ambitious in terms of "Depth" means pushing the model to adopt the tools, technologies, media and knowledge used by the best professionals in this field, and keep pushing forward until even these people can learn something new from your results.

Let's continue to use the quarterly business review presentation of Acme Inc as an example. Suppose Acme Inc is troubled by user churn (that is, customers keep losing over time). I find that the comprehensive application of the following several skills is very helpful:

• Stick to using the same tools used by top people in the industry: When asked to "act like a professional", models often just change a set of wording, and the method does not really change. To handle our problem in depth, we have to use the same tools as top data scientists and statisticians. When Claude habitually uses Markdown tables, insist on asking it to use databases and statistical models instead. You do not necessarily have to know what tools experts use, and Claude usually knows.

• Set seemingly unreasonable goals and tell the model that it is very reasonable: You need to reduce the website loading time from 10 seconds to 5 seconds? Then ask for 200 milliseconds. The model thinks something is impossible? Emphasize to it over and over again that this is completely solvable, just keep moving forward.

• Challenge what you already know: Especially in the business field, many things we firmly believe in are actually just rough approximations of reality. Let the model access original information and data, and ask it to test various hypotheses in an adversarial way. "We think user churn is a problem in the new user onboarding link. Please try to reproduce this conclusion from the original data."

• Produce new knowledge: This can easily follow after "Challenge what you already know". Once Claude has dived deep into the data, let it find blind spots. "Build a customer simulation based on our logs to reproduce the situation of the past year. Then find the earliest churn signal we do not know yet, and prove that it also has predictive power on unseen data."

• Introduce an external referee: Do not let the model judge itself. I guess this problem will be solved eventually as model intelligence improves, but in October 2026, I urge you to insist on external verification. The ideal situation is to provide a tool that the model can run directly and get feedback immediately.

Share a simple prompt that often helps me:

What I want is a "deeper" version of this task, not a "larger" version. Before rewriting, please first: (1) Explain what top professionals in this field will do here that I have not asked for; (2) Point out what most original materials they will start with, instead of the materials that have been digested for me; (3) Point out the specific methods and tools they will use; (4) Explain what else besides you and me can prove that the result is correct. Then rewrite my prompt to exactly put forward these requirements.

Range

In short, to be more ambitious in terms of "Range" means to examine our work from the perspectives of different fields, and there are so many involved fields that it was not cost-effective in the past. This is not a unique insight: the first 30 minutes of every heist movie are spent gathering a group of people with different backgrounds and unique skills. As AI products make it easier and easier to run multi-agent systems (multi-threading, orchestrators, or simple sub-agents), I find that asking Claude to introduce more perspectives from different fields often leads to very interesting results.

Putting this into practice is not easy, and it requires you to exert your creativity. Before seeing my colleague Alex Albert use Blender to render interior designs, I never thought that I could use Claude to make 3D environments for my homepage, even though I used to make video games! But without a doubt, this is also where I have seen miracles happen most often.

So how to do it specifically? I use the following several skills:

• Try to replace nouns with verbs: This is an old method proposed by Tom Kelley and Jonathan Littman in "The Art of Innovation". A quarterly review is not "a presentation", but "convincing busy people of a story about cause and effect within 30 minutes, and making decisions in uncertainty". With verbs, it is easier for both me and Claude to see which fields can bring unique and useful perspectives.

• Assemble a team: This presentation must be amazing, otherwise aliens will blow up the earth. What kind of team will humans gather? To ensure production quality, I will invite an analyst, a journalist and an editor. If there is also a live demo, a motion and audio designer is probably needed. It may also be helpful to introduce an adversarial "red team", so invite a short seller and a forensic accountant.

• It is easy to unconsciously turn this into role-playing, which will only make the chat record weirder without actually improving the results. Please use this method to find fields and technologies: do not let the model "write like a short seller", but let it do what a short seller would do when researching their positions.

All kinds of ambition I described require the model to have a computer that can install software and access all kinds of relevant data (through MCP connectors or other methods). There are many tools to achieve this, and I suggest you make good use of them.

We have encountered this kind of thing before

The above are specific suggestions on how to be more ambitious. If you are willing to stay for one more minute, I want to talk about why I think this matter is necessary from the very beginning.

We humans have always been bound by what we think is "possible", and worse, we usually only trust ourselves within a very narrow professional scope. As we all know, Michelangelo did not want to paint the ceiling of the Sistine Chapel: you know, he was a sculptor, not a painter.

When researching the issue of "ambition", I learned that psychology has a special concept for this: self-efficacy. In short, people with high self-efficacy trust their abilities more, and then actually accomplish more. There is evidence that self-efficacy can be improved through tricks: Locke and Latham sorted out 35 years of research on goal setting, and confidently concluded that people who are given specific and difficult goals perform better than those who are only told to "do your best". Patrick Collison, the founder of Stripe, maintains a list called "Fast", which records many things that humans have accomplished when facing bold goals and tight deadlines at the same time. Here are several well-documented tricks:

• Only by believing that difficult things are possible can you accomplish difficult things: In 1939, George Dantzig was late for his statistics class at UC Berkeley, he copied down two problems on the blackboard, thought they were homework, and handed them in after finishing. They were actually two unsolved problems in statistics.

• After seeing others accomplish it, difficult things can also be accomplished: For decades, humans have been chasing running 1 mile in 4 minutes. Roger Bannister broke this record in May 1954, but he was the only one who achieved it for only 46 days. If you are a running enthusiast, you will find that a similar scene is happening for the sub-2-hour marathon: this April, Sabastian Sawe ran the first officially recognized sub-2-hour marathon in London. In the same race, the runner-up also finished within 2 hours.

• Only by allowing yourself to fail can you accomplish difficult things: Obviously, "The Inner Game of Tennis" is a business book loved by everyone, and I only discovered this last week. The core argument of this book is that if you try too hard, you will not play your best tennis. We engineers may still remember the announcement when Linux was released: "It's just a hobby, it won't be big and professional like GNU."

Self-efficacy is not a new problem, but now it carries more weight. In a world where our capabilities jump every few weeks, we need some skills to do things that we would not have seriously considered, or even did not believe were possible. If you find more skills that can make you more ambitious, please be sure to let me know!

Translator: boxi.