Ask Claude Code for "a summary panel" and you get a summary panel with passing tests. Yet you may still look at that panel with no idea what to do next. The task was done correctly, but it wasn't what you really wanted.

On October 13, Anthropic's Felix Rieseberg published "How to be more ambitious" about this problem. With the same model, some people get remarkable results while others stop at softening the tone of an email. We tried his methods one by one on a real project.

This post covers:

1. Why you only get what you ask for, and the four types of ambition
2. Altitude: adding one line about the goal
3. Depth: having the model rewrite the request, then building it through
4. The outside judge: the "2,000 layouts" were really about 381
5. Range: turning nouns into verbs and looking through several fields
6. What Claude needs for any of this to work
7. Limits of this trial

How to read the numbers. [Official docs] means material written by the person concerned (here, Felix's post), [Paper] means a public paper, and [Our measurement] means results from our own runs in this trial. We used Claude Code (Opus 5.5), with the Codex CLI as the outside judge.

1. Why you only get what you ask for

Felix Rieseberg (Felix below) is an engineering manager at Anthropic who has led engineering for Claude.ai, Cowork, and Claude Code Desktop. He also co-maintains Electron [Official docs] (Felix's post).

We usually treat AI like a to-do list: build this, fix that. The prompt doesn't say what outcome we want, so the AI does the task and reports that it's done. Tell it the outcome instead, and it can compare what it built against that goal and fix what falls short.

Felix points out that people work similarly, citing goal-setting research. Locke and Latham reviewed 35 years of studies and found that people given specific, hard goals perform better than people told to do their best [Paper] (Locke & Latham 2002).

He splits ambition into four types [Official docs].

• Speed: the same work, faster. Everyone already does this, so his post skips it.
• Altitude: hand over the outcome rather than the task.
• Depth: work like a field-leading expert, one level down in the data and tools.
• Range: draw on other fields beyond the one the task seems to need.

We tried the other three on ComfySims, an open-source app that places furniture you plan to buy on your floor plan at real size. It checks before you buy whether a bed fits through the door and whether you can still walk around it. The exact prompts are in PROMPTS.md in the practice repo.

2. Altitude: adding one line about the goal

Felix says that at the start of last year he still asked Claude to fix individual crashes. Eventually he asked it to keep the apps crash-free [Official docs]. Claude decides what to fix.

So we built the same "layout summary panel" twice and compared. [Our measurement]

One moment stood out. The existing check reported no problems, but Claude, given the goal, worked through the coordinates itself and said the counter was blocking the doors. Below that it listed decisions with their reasons, such as "buy a counter 130 cm or shorter, or use another wall" and "move the TV unit 20 cm west." All 255 tests passed as well.

Felix notes that altitude doesn't fit everything. It works well when you really want a clear outcome, or for work you'd hold meetings about. It works less well for creative work, and "go make money" mostly doesn't work yet [Official docs].

3. Depth: having the model rewrite the request

Asking a model to act like a professional often changes its vocabulary, not its methods. So Felix says to insist on the tools the best people in the field actually use. When Claude reaches for a markdown table, insist on databases and statistical models. You don't have to know what experts use; Claude usually does [Official docs].

He also says to pick unreasonable goals on purpose: ask for 200 ms rather than 5 s when your site loads in 10 s.

He shares a prompt he often uses (see the original post and PROMPTS.md for the full text). You ask for a deeper version rather than a bigger one, and before rewriting the model answers four things:

1. What would a top professional do that you aren't asking for?
2. What's the rawest material, rather than something already digested?
3. Which specific methods and tools would they use?
4. What, other than you or the model, would show the result is right?

How a one-line request changed

We pasted this prompt under one line: "a feature that checks whether the walkways between furniture are wide enough." Claude looked through the repo first, then rewrote the request into a single file, deep-prompt.md. [Our measurement]

• Definition: walkway width is measured at the narrowest point on the path.
• Raw material: cite primary texts such as the ADA standards and the Korean accessibility law's appendix with section numbers, and mark any number it can't trace as unverified.
• Evidence: seven kinds, including examples with hand-known answers, a comparison of two independent calculations, and checks on the screen.

We opened a new session with none of that conversation and handed it only this file.

What the new session did

• It couldn't find the original source for body measurement data, so it left those numbers out and judged by furniture dimensions alone.
• Given two boxes 80 cm apart, one method returned 0 and the other 79. It found and fixed three problems.
• It wrote 26 acceptance tests (tests that check behavior against the requirements) and sorted the 7 initial failures into code problems and test problems before fixing them.
• It ran both methods on random layouts and reported "99.72% within ±1 cm across 3,939 paths in 2,000 layouts." [Our measurement]

The finished view marks the narrowest point on each path. The pink marker shows 80 cm between the sofa and the cabinet, and the green one shows 124 cm at the door. You can see where things get tight before you buy.

It looked finished at this point. But that number had a problem.

4. The outside judge: the "2,000 layouts" were really about 381

Felix says not to have a model judge its own work; ideally the judge is a tool it can run for immediate feedback [Official docs]. After all, that model made every decision in the work.

So we told Claude to get a review from the Codex CLI, check the evidence for each finding, and fix only the valid ones. Codex ran read-only and couldn't change code. [Our measurement]

• Codex raised 7 findings. Rather than fixing them right away, Claude reproduced 6 and confirmed 1 by reading the code.
• Fixing them exposed something bigger. Because of a numeric precision problem, the random layout generator repeated the same rooms in a cycle of about 381. The earlier "99.72% of 2,000" was really measured on about 381 layouts.
• It also found that all 273 tests passed while the exit code was still failing. It had missed this earlier because it hadn't checked the exit code. The cause was its own test blocking the event loop for 90 seconds.

[Our measurement] The percentage rose slightly, but the real change isn't its size. It's whether you can trust the number. The worst case actually got larger, and Claude openly reported loosening its own test limit to ±2 cm to match the measurement. On its own, the model that built this would have believed a check of 381 layouts was a check of 2,000.

5. Range: turning nouns into verbs

Felix's example is the heist movie, where the first 30 minutes go to assembling people with different talents. The trap is role play. Asking a model to talk like someone just makes the transcript weirder, so ask it to do what that person actually does [Official docs].

His trick for finding which fields to bring in is turning nouns into verbs. A quarterly review isn't a deck; it's getting busy people to believe a story about cause and effect and decide within 30 minutes.

We described ComfySims the same way. It isn't a 3D house editor; it's helping people decide with confidence, before they buy, whether furniture will fit and be livable in their home. Then we had a subagent (an agent handling a separate piece of work) for each field make fixes in turn.

Claude picked 7 fields and set a rule: don't talk like that person, produce what they actually produce, such as a return-reason table or a survey sheet. Because this took a long time, we only ran the first four. [Our measurement]

Tests grew to 329 by the fourth field, and the full check passed again each time. Each field's different eyes turned up problems the earlier ones hadn't seen.

6. What Claude needs

Felix says all of this requires giving the model a computer that can install software and access to relevant data, whether through MCP connectors or other means [Official docs]. Before handing over crash-free apps, he first did three things:

1. Made crash reports easy to fetch.
2. Made it possible to tell which app version maps to which commit.
3. Provided Windows, macOS, and Linux computers so it could reproduce issues and verify fixes itself.

This project had the same three things. [Our measurement]

Demanding better results is pointless if there's no way to check them. If you want to start small, try adding one line about the goal to your next prompt.

Limits of this trial

• We ran each method once on one project. The altitude comparison rests on a single panel. We didn't measure how much better any method is.
• Mutation testing, which deliberately breaks code to see whether tests catch it, didn't finish. Of 2,442 mutants, 15% (446) took 54 minutes and scored 75.3% at that point, but that run predates the fixes for Codex's findings, so it isn't final evidence.
• Among the evidence listed in deep-prompt.md, we didn't do the comparison against a real room measured with a tape measure.
• Range covered 4 of 7 fields. Four criteria with no source found (two height values, the 5% dimension tolerance, and 50 cm in front of windows) are marked unverified in the spec and only raise warnings.
• Felix's post is advice from experience, not an experiment measuring its effect.

Watch the video

We walked through the same process with real execution screens in a video. The video is in Korean.

• How Anthropic engineers use Claude Code

Sources

• Felix Rieseberg, How to be more ambitious: A tutorial for humans with models (2026-10-13)
• Locke & Latham, Building a practically useful theory of goal setting and task motivation: A 35-year odyssey, American Psychologist (2002)
• dante01yoon/claude-ambition-practice: the prompts used in the video (PROMPTS.md)
• dante01yoon/ComfySims: the demo project