Felix Rieseberg, an engineering manager at Anthropic who has so far led engineering for Claude.ai, Cowork and Claude Code Desktop, lists feats accomplished with or by Claude near the start of his 13 October 2026 post: this month, it may have helped discover a new planet. Meanwhile, many people still use AI to ask for the capital of France or to make an email sound less angry. He sums up the picture with this observation:

Model capabilities don't grow uniformly.

Some people, he writes, have learned to pilot the models' astounding capabilities and seem to be flying; many others are still struggling to get their new wings to work. He acknowledges that “we're not ambitious enough”, a line people working on AI (himself included) keep repeating, is hard advice to follow, so he wrote a tutorial. He mostly uses Claude and says the advice applies to other models too.

Rieseberg describes four types of ambition:

Speed: the same work in less time.
Altitude: going up in abstraction and looking at the outcome behind individual tasks.
Depth: approaching a task the way a field-leading expert would, and going one level down to the data, the tools and the underlying problem.
Range: bringing the perspective of several fields to a task, even one that looks like it belongs to a single field.

Speed is the bread and butter of AI's economic value. It is well established and needs little creativity, so Rieseberg passes over it quickly, and so do we. The examples come from his post and from a video in which Ray Amjad, a YouTube creator who covers AI agents, walks through it. The factory examples are ours.

Altitude: the goal beyond the goal

Rieseberg points out that a task you hand the model is your best guess at how to get the outcome you want. So the question to ask is “what do you want to happen next?” His own work moved this way. At the beginning of last year he was still asking Claude to fix individual crashes:

Eventually I asked Claude to simply keep our apps crash-free.

That goal changed the workflow. First he had to make sure Claude could easily fetch crash reports and understand which app version maps to which git commit. He also gave it access to Windows, macOS and Linux computers so that it could reproduce and verify fixes on its own.

The post's running example is a quarterly business review (QBR) deck at an imagined company. Claude will happily fill in the slides of a template. One level up, you give the model as much data as you can get your hands on, so it understands the business, and ask:

Tell me what changed this quarter, why, and what we should do about it.

The second step starts from the fact that good meetings end with decisions: ask the model to work out the three most urgent decisions and prepare possible directions with arguments for and against. The third step questions the meeting itself. The prompt he suggests reminds the model that the review exists so leadership catches problems early and moves money and people to the right places. It then asks the model to design a better way to do that, show from the company's own history that it would have caught problems sooner, and run it beside the current process for a quarter.

Altitude, he writes, works best when you really are after some ultimate outcome, and less well for creative work. A good tell-tale sign that it fits: there will be meetings to discuss the work. It has limits: in 2026, “Claude, go make money” does not seem to work for most businesses on its own. Still, Rieseberg generally sees that models seem able to operate at higher levels of abstraction the more capable they become.

Before handing an agent a goal like this, Ray Amjad asks it what access it needs. In his support process, he noticed a teammate was relaying messages between users and Claude, and he handed that relay to an agent. The agent matches support tickets to crash logs, tries to reproduce the bug on a real machine, asks the user clarifying questions when it has to, then fixes the issue and tells the user. The question Amjad asks himself: where am I being the middleman?

Altitude in the factory

Factories run on meetings: the morning production meeting, the weekly quality meeting, the monthly management review. By Rieseberg's sign, the work discussed in these meetings is a good candidate for altitude. The same ladder works for a monthly production report:

Ask the model to update the report's tables.
Ask what changed this month, why, and what should be done about it.
Remember why the report exists: to see problems early and send resources to the right line and the right machine. Then ask the model to propose a way to do that without waiting a month, and to show on past months how much sooner it would have caught problems.

Each step needs the model to reach more data. We explained why the setup around the model matters so much in our post on shop-floor data. Rieseberg says altitude is where people find durable workflows that take the human out of the loop; in a factory, which decisions stay with people is a decision of its own. We covered that in our post on trusting AI.

Depth: working with the expert's tools

Rieseberg defines depth as pushing the model to use the tools, techniques and knowledge of the best professionals in the field, until even those professionals might learn something from the result. The example is the same company, now looking at customer churn. He suggests five techniques.

Insist on the experts' instruments

His observation:

When prompted to act like a professional, models often switch vocabulary without actually switching methods.

When Claude reaches for a Markdown table, insist on the database and the statistical model a data scientist would use. According to Rieseberg, Claude usually knows what the experts use. Amjad's example comes from software: asked to “make this faster” for a page that takes 10 seconds to load, the model tends to suggest familiar fixes such as lazy loading. Insist on a performance engineer's tools, and it starts profiling and reading traces, which shows where the time actually goes, for example that database queries take most of it.

In a factory, it is easy to get a paragraph of commentary on “why did efficiency drop?” An industrial engineer looks at the same question with control charts, a Pareto analysis and a breakdown by shift, line and machine. Ask the model to look with those tools too.

Pick unreasonable goals and tell the model they are reasonable

Rieseberg's example: you need your website to load in 5 seconds where it now takes 10? Ask for 200 milliseconds. If the model thinks the goal is impossible, repeat that the problem is solvable and it just needs to keep going.

Challenge what you know

Rieseberg notes that many business beliefs are only rough approximations of reality. Give the model the raw data and have it check your assumptions adversarially:

We believe churn is an onboarding problem. Try to reproduce that from the raw data.

Every factory has beliefs like this: “scrap goes up on the night shift”, “most downtime is waiting for material”. Asking the model to reproduce them from the raw records moves the meeting's argument onto the data. The more complete the raw data, the more the test can be trusted.

Produce new knowledge

Once Claude is deep in the data, you can ask it to find blind spots. Rieseberg's example prompt asks the model to build a simulation of the customers that reproduces the last year from the logs, then find the earliest churn signal nobody knows about yet, and show that it predicts on data the model has not seen.

Use an outside judge

Do not ask the model to judge itself.

Rieseberg assumes this will eventually be solved as models get more intelligent; as of October 2026, he implores readers to insist on outside validation. Ideally it is a tool the model can run itself to get feedback immediately. In a factory, the outside judge often already exists: the stock count, the quality lab's measurement, the shipment record. If the model says scrap fell this month, compare that with a record kept independently of the model's own calculation.

Four questions that deepen a task

Rieseberg shares a short prompt he often uses. It opens with this sentence:

I want a deeper version of this task, not a bigger one.

It then asks the model to answer four questions before rewriting the task:

What would a top professional in this field do here that you are not asking for?
Going back past the material that has already been summarised for you, what is the rawest material they would start from?
Which methods and tools would they use?
Apart from you and the model, what would show that the result is right?

Finally, the model rewrites your prompt to ask for exactly that. In his video, Amjad singles out the fourth question: finding a really good verifier. The full prompt is in Rieseberg's post.

Range: looking at the work through other fields

For Rieseberg, range means looking at your work from the perspective of more fields than would have been economical in the past. He says the idea is hardly new: every heist movie spends its first 30 minutes assembling a diverse crew. As running several agents together gets easier, he has seen interesting results from asking Claude to bring in additional fields.

He admits this takes creativity. Even though he has made video games, he never considered using Claude to build 3D environments for his homepage until he saw his colleague Alex Albert render interior designs with Blender. His verdict on range:

…this is easily where I see the most magic happen.

Replace the nouns with verbs

Rieseberg takes this trick from The Art of Innovation by Tom Kelley and Jonathan Littman. He describes the quarterly review with a verb: “getting busy people to believe a story about cause and effect”, and getting them to decide under uncertainty in 30 minutes. The verbs make it easier for both him and Claude to see which fields could bring a useful perspective. As Amjad points out, journalists, editors and analysts already do this for a living.

Most of us know our own field well and little else. So Amjad suggests handing the search to Claude: describe the problem, ask Claude to interview you first, and then to name the jobs that deal with a problem of the same shape and what they do about it.

His own example is error messages. Asked to “improve the error messages”, the model may turn a 500 error into a friendlier “Something went wrong, please try again later”, and the user is still stuck. As a verb, an error message helps a confused person get unstuck without contacting anyone, which is what support staff do every day. Amjad suggests matching the last six months of support tickets to errors, ranking them by count and rewriting the few errors behind most tickets. He applies the same thinking to feature requests: a good doctor asks about the symptoms before writing the prescription the patient asked for.

In a factory, most work goes by a noun too: the shift handover form, the quality report, the maintenance plan. Put the handover form as a verb, and it becomes starting the next shift's first hour without losses. Shift handover in hospitals is a long-studied example of the same job. You can ask the model to study how that field handles handovers and adapt it to your form.

Assemble the crew

Rieseberg imagines that aliens will blow up Earth unless the deck is amazing, and assembles a crew: an analyst, a journalist and an editor for production quality; a motion and audio designer if it has to be presented; and, as an adversarial “red team”, a short seller and a forensic accountant. He adds a warning straight away:

It is easy to accidentally engage in role play…

Role play makes the transcript weirder without improving the outcome. The crew is a way to find fields and techniques. Rieseberg's advice is to ask the model to do what a short seller does to research their position.

First, a computer and data

All of these types of ambition, Rieseberg writes, need the model to have a computer where it can install software, and access to all kinds of relevant data (through MCP connectors or other means). Plenty of tools make this possible. In a factory, that means the model reaching production, quality and maintenance records. On whose authority, and within which limits, that access is granted is part of the work to settle at the very start.

We have been here before

Rieseberg ties the post to self-efficacy, the psychology term for how much you believe in your own abilities: people who believe in them more actually accomplish more. He argues that self-efficacy can be hacked, citing Edwin Locke and Gary Latham, who reviewed 35 years of goal-setting research and found that people given specific, hard goals perform better than people told to do their best. Rieseberg lists three ways in:

Believe it is possible: in 1939, George Dantzig arrived late to a statistics class at Berkeley, copied two problems off the blackboard and solved them as homework. They were two unsolved problems in statistics.
Watch somebody else do it: Roger Bannister ran a mile in under four minutes in May 1954 and stayed the only person to have done so for just 46 days. The marathon is seeing the same: on 26 April 2026, Sabastian Sawe won the London Marathon in 1:59:30, the first person to run one under two hours in an official race. Yomif Kejelcha, second in the same race, also finished under two hours.
Give yourself permission to fail: The Inner Game of Tennis argues that you do not play your best tennis when you are trying really, really hard. Linux, too, was announced as “just a hobby”.

Self-efficacy isn't a new problem, but it is a more powerful one now.

In a world where our abilities leap every couple of weeks, Rieseberg writes, we need techniques that let us do things we did not believe possible. Amjad makes a similar point: models jump every couple of weeks while expectations lag behind. His way to take advantage of that gap is to take ideas regularly from the people working closest to what the models can do.

Where to start

Before writing your next prompt, these questions help:

What outcome do I want from this task, and what do I want to happen after that?
Is this work preparing for a meeting? If so, what decision should the meeting end with?
What raw data would the best expert in this field start from, and which tools would they use?
Apart from the model itself, what will show the result is right?
If I describe this work with a verb, which jobs do that verb every day?
What access does the model need to own this work? (I can ask the model too.)

Sources

Felix Rieseberg: How to be more ambitious: A tutorial for humans with models (13 October 2026).
Ray Amjad: Your Prompts Are Too SMALL for Claude Code (YouTube, 18 October 2026).
Edwin A. Locke and Gary P. Latham: Building a Practically Useful Theory of Goal Setting and Task Motivation: A 35-Year Odyssey.
The Associated Press (WLRN): Kenya's Sabastian Sawe is first person to run sub-2-hour marathon to win in London (26 April 2026).

Four ways to be more ambitious with AI