How to Be More Ambitious With AI (Without Going Bigger)

If you want to know how to be more ambitious with AI, the short answer is this: stop sizing your request to the task you typed. Ask for the outcome behind the task (Altitude). Ask for the task done the way the best person in that field would do it, from raw material, checked by something other than the model (Depth). And bring in fields the task doesn't obviously need, doing what their experts actually do (Range).

That framework isn't mine. It comes from Felix Rieseberg, who works on Claude at Anthropic, in his October 13, 2026 essay How to be more ambitious: A tutorial for humans with models. Read the original. It's short and it's good.

This post covers what happened when I held that framework up against my own work: agency client projects through Ramlit, design work at ColorPark, security audits at xCyberSecurity, and the content pipeline that produces the post you're reading. You'll get my copy-paste prompt templates for each type of ambition. You'll also see the place where my own system breaks Felix's most important rule. I didn't notice it until I read his essay.

The commit that should have taught me this months ago

On June 10, 2026, I pushed a commit to the repo that runs my content agent. The message was dull: add publish contract gates to aria and save new posts. What it fixed was not dull.

For months that pipeline had run on what Felix calls Speed: the same work in less time. I'd paste in a source, an agent would research and draft, and a post would land in the right folder. It was fast and the volume was real. Then Google Search Console's page indexing report started filling up with two labels I came to hate: "Crawled – currently not indexed" and "Alternate page with proper canonical tag."

Google was reading my pages and choosing not to keep them.

Writing faster wasn't going to fix that. The fix was to change the question I was asking. "Write a post about X" became "make a page that deserves a slot in Google's index when hundreds of similar pages already exist." The commit added six gates every draft has to pass. One checks for information the top results don't already have. One checks for real first-hand experience. One refuses to write a new page if an existing one already owns the query.

I didn't have a name for that move until October. Felix calls it Altitude. I'll come back to this commit near the end, because it also contains a mistake his essay names directly, and it's the most useful thing in this post.

What Felix Rieseberg's essay actually argues

The premise is that model capabilities don't grow evenly. Felix borrows a line from Terence Tao, and I checked the source: in the slides for his October 2026 Caltech lecture, Math 2.0, Tao writes that AI performance is "extremely jagged: astounding in some directions, while inadequate in others." Some people find the astounding directions and seem to fly. Most are still using the model to fix an email's tone.

Felix's evidence for the astounding side comes from his own month. One item: Claude "may have helped discover a new planet." That checks out, with a caveat. Gizmodo reported on October 9, 2026 that Pavel Rabtsevich, a product manager in Spain with no formal astronomy training, used Claude Code alongside other tools to scan public TESS telescope data. He found a dimming pattern around the star TIC 4206066 that suggests a planet about 1.4 times Earth's size. It's still an unconfirmed candidate, pending TESS observations scheduled for October 31 to November 26. Felix also mentions the first AI music video he genuinely likes and a "new era of math." Tao's Math 2.0 lecture is that conversation.

His answer to the gap is four types of ambition:

Felix skips Speed because it's well established and takes little creativity. I won't skip it, because Speed is where most of us are stuck, and I was stuck there for a long time.

Why Speed is the trap I was living in

Speed is seductive because it's measurable on day one. A Laravel CRUD module that took an afternoon now takes twenty minutes. A security audit report writes itself from scanner output. A blog post arrives while you're on a call.

The trouble is that Speed multiplies whatever you were already doing, including the parts that were wrong. My content pipeline didn't have a writing problem. It had a worthiness problem, and Speed scaled the worthiness problem into a pile of pages Google declined to index.

That's the first lesson I'd hand any agency owner: if you can only describe your AI wins in hours saved, you're optimizing the task and ignoring the outcome. The next three sections each tackle that from a different direction.

Altitude: how to be more ambitious with AI by aiming at the outcome

Felix's example is the best single illustration of Altitude I've seen. He used to ask Claude to fix individual crashes. Eventually he asked it to keep the apps crash-free.

That's one sentence of difference, and it changes everything downstream. "Fix this crash" ends when the crash is fixed. "Keep the apps crash-free" has no end. It's a standing responsibility, and that's why it takes the human out of the loop.

The QBR ladder, rung by rung

Felix builds the idea up with a deliberately boring example: a quarterly business review deck at an imaginary company, Acme Inc. Each rung is more ambitious than the last.

1. Understand, don't fill in. Don't update the numbers in the template. Give the model all the data you can get and ask: "Tell me what changed this quarter, why, and what we should do about it."
2. Get to the decisions. Good meetings end with decisions, so ask: "Work out which three decisions are most urgent in the face of everything you've learned, and start working on potential directions with for/against arguments."
3. Replace the ritual. The QBR exists for a reason. Ask: "The review exists so leadership catches problems early and moves money and people to the right places. Design a better way to do that than a quarterly deck, show from our own history that it would have caught things sooner, and run it beside the current one for a quarter."

Look at rung three. It doesn't ask for a better deck. It asks the model to prove a better process, using your own history as evidence, and to run it in parallel before anyone trusts it. That's a much bigger ask than a deck, and it's grounded in data you already have.

What Altitude looks like on agency work

Here's how I'd write that ladder for the most common recurring job in my agency world: monthly maintenance on a client's WordPress site.

• Rung 1, the task: "Update the plugins and the theme, then confirm nothing broke." Most maintenance retainers run at this level.
• Rung 2, the decisions: "From the update history, uptime logs, and plugin changelogs, work out which three things on this site are most likely to cause an outage or a breach in the next 90 days. Give me options for each, with for/against arguments I can take to the client."
• Rung 3, the outcome: "The retainer exists so this client never loses sales to downtime or a hacked site. Design a better way to guarantee that than a monthly update pass. Show from this site's own incident history what it would have caught, then run it on staging beside the current process for a month."

None of that is exotic. The difference is that rung 3 makes the model responsible for the reason the retainer exists, not for the chore.

The setup cost nobody puts in the demo

This is the part of Felix's essay I'd underline twice. Before Claude could keep his apps crash-free, he had to make sure it could fetch crash reports, map each app version to its git commit, and use Windows, macOS, and Linux machines to reproduce and verify fixes on its own.

Altitude is mostly plumbing. The ambitious prompt is the easy part. The work is giving the model the access that makes the prompt possible.

For the WordPress rung 3 above, that plumbing looks like this:

• Shell access to a staging copy, with WP-CLI installed
• Read access to the uptime monitor's API and the host's error logs
• A vulnerability database the agent can query against the installed plugin versions (WPScan's is the usual choice)
• A way to diff staging against production after every change
• A rule written in plain language about what it may do alone and what needs my approval

When Altitude is the wrong move

Felix gives a good tell: Altitude fits when you're going to hold meetings about the work. It fits less well for creative work, and "Claude, go make money" still doesn't work for most businesses on its own in 2026.

I'd add a second tell from client work: if the client will email you about it next month, it's an Altitude problem. If the deliverable lives or dies on its own, like a logo concept or a one-off landing page, climb a rung at most and spend your ambition on Depth.

Copy-paste template: Altitude

Here is the task I'd normally give you: [TASK].

Before doing it, climb the ladder:
1. What is this task FOR? Name the outcome it serves, in one sentence.
2. What decisions does that outcome depend on? List the three most urgent,
   with for/against arguments for each.
3. Design a standing process that owns the outcome instead of repeating
   the task. Use our own history ([DATA SOURCES]) to show what it would
   have caught earlier.

Then list the access you'd need to run rung 3 (data, tools, permissions)
and mark each as "have" or "missing". Start on the highest rung you can
actually verify with what you have now. Ask before anything that spends
money, touches production, or can't be undone.

Altitude changes what you ask for. Depth changes how well the answer gets made, and it's where most of the quality gains I've seen come from.

Depth: how to be more ambitious with AI by working like the field's best

Felix defines Depth as pushing the model to use the tools, techniques, media, and knowledge of the best professionals in the field. Then you keep pushing until those professionals might learn something from the result.

He gives five techniques. I'll run each against a real category of my work.

1. Insist on the expert's instruments

Felix's sharpest observation: when you tell a model to act like a professional, it often switches vocabulary without switching methods. You get the jargon and the same markdown table. A real data scientist reaches for a database and a statistical model. You don't need to know what experts use. The model usually does.

On a security audit, the vocabulary version is a markdown checklist titled "OWASP Top 10 Review." The instrument version is the model running the scanners and static analysis a pentester would run (nuclei templates, semgrep rules, a proxy capturing real requests). Then it confirms each finding with a reproduction instead of listing "potential" issues.

2. Pick an unreasonable goal and call it reasonable

Felix's example is that if you need your website to load in 5 seconds instead of 10, you should ask for 200 milliseconds. If the model says something is impossible, tell it again that it's solvable and it just needs to keep going.

On a slow Laravel admin panel, the reasonable ask is "make this page faster." The unreasonable ask is a target that forces a different design: a 200ms server response on the heaviest report page. A target like that rules out "add an index and call it done." It forces the model to profile the query plan, question the data model, and consider caching or precomputing the report. Sometimes it won't get there. A missed hard target with honest numbers is still a far better result than a met easy one.

3. Challenge what you know

Business beliefs are approximations. Felix's prompt: "We believe churn is an onboarding problem. Try to reproduce that from the raw data."

The agency version shows up constantly. A client is sure their conversions dropped because of the redesign. Maybe they did. Or maybe the drop started two weeks earlier, when a payment plugin update quietly broke checkout on one browser. Give the model the raw analytics export and the deploy log, and ask it to try to disprove the client's theory before anyone pays to redesign the redesign.

4. Produce new knowledge

Once the model is deep in the data, ask what nobody knows yet. Felix's version: "Build a simulation of our customers that reproduces the last year from our logs. Then find the earliest signal of churn we don't know about yet, and show it predicts on data it has not seen."

The phrase that matters is on data it has not seen. It's the difference between a pattern and a story the model told itself. It also leads straight into the last technique, which I think matters most.

5. Use an outside judge

Felix: "Do not ask the model to judge itself." He assumes that will eventually be solved by more capable models, but in October 2026 he insists on outside validation. Ideally it's a tool the model can run to get feedback immediately.

On a code project, outside judges are everywhere: the test suite, PHPStan at a strict level, a Lighthouse run, a load test, a reproduction script that fails before the fix and passes after. On a security audit, the judge is the exploit actually working on staging. On a content project, the judge is harder to find. Asking the model to cite sources and leave blanks instead of guessing (the approach in my three prompting rules that stopped AI from guessing) helps, but it's still not an outside judge. That's where my own system goes wrong. I'll get to that.

I wrote about defining success criteria a loop can actually check in my breakdown of loop engineering versus prompt engineering. An outside judge is the same idea pointed at quality instead of completion.

The "deeper, not bigger" prompt

Felix shares a prompt he uses often. Here it is verbatim, credited to him:

I want a deeper version of this task, not a bigger one. Before rewriting it: (1) say what a top professional in this field would do here that I'm not asking for; (2) name the rawest material they would start from instead of what has already been digested for me; (3) name the specific methods and tools they would use; (4) say what, other than you or me, would show the result is right. Then rewrite my prompt to ask for exactly that.

— Felix Rieseberg, How to be more ambitious

The opening clause, deeper, not bigger, is the guardrail. Without it, "be more ambitious" turns into feature creep: more sections, more deliverables, more side quests, and no better result. It's the same discipline I argued for in why restraint is the most important dev skill right now. Ambition should raise the standard. It shouldn't raise the scope.

Copy-paste template: Depth (my extension for client work)

I use Felix's prompt as the first half and add a client-safe second half:

I want a deeper version of this task, not a bigger one: [TASK].

Before rewriting it:
(1) What would a top professional in [FIELD] do here that I'm not asking for?
(2) What's the rawest material they'd start from? (Logs, exports, source
    code, raw requests, not summaries or dashboards.)
(3) Which specific methods and tools would they use? Use those tools, not
    their vocabulary.
(4) What, other than you or me, would show the result is right? Name a
    test, measurement, reproduction, or held-out dataset you can run.

Then:
- Set a target a top professional would call ambitious, and treat it as
  reachable.
- Report against the outside judge with real numbers, including misses.
- Do not expand the deliverable. Same scope, higher standard.

If you've followed along this far, you already have more than most "prompt better" advice offers: a way to raise the outcome and a way to raise the standard. Range is the third axis, and it's where Felix says he sees the most magic. It's also the easiest one to get wrong.

Range: what happens when you replace the nouns with verbs

Range means looking at the work through more fields than used to be affordable. Felix points out that every heist movie spends its first 30 minutes assembling a crew with different talents. With multi-agent setups (parallel threads, orchestrators, subagents), assembling a crew is now cheap.

He admits it takes creativity. His example: until he saw his colleague Alex Albert use Blender to render interior designs, he'd never thought of using Claude to build 3D environments for his own homepage, even though he'd made video games before. The tools from another field were sitting right there. He just hadn't connected them to his problem.

Technique 1: replace the nouns with verbs

Felix credits this trick to The Art of Innovation by Tom Kelley and Jonathan Littman, the IDEO book from 2001. His example: a quarterly review isn't "a deck." It's "getting busy people to believe a story about cause and effect, and to decide under uncertainty, in 30 minutes."

Once you have the verbs, the relevant fields show up on their own. Believe a story points to journalism and editing. Cause and effect points to statistics. Decide under uncertainty points to decision science and risk.

Here's the same move on work I actually do:

• A client's landing page isn't "a page." It's getting a skeptical stranger to trust an unfamiliar business enough to hand over an email address, before they scroll away. The verbs bring in conversion copywriting, trust and credibility research, accessibility (the stranger might use a screen reader), and performance engineering (a stranger on a slow phone gives up fast).
• A security audit report isn't "a PDF." It's convincing a non-technical owner to spend money now on a risk they can't see, and giving their developer exact steps to close it. That brings in risk communication, technical writing, and the attacker's view.
• A brand identity system isn't "a logo and a palette." It's making a company recognizable and trusted in a fraction of a second, everywhere it appears, by people who'll never think about it. That brings in perception psychology, typography for small screens, and the production constraints of print and packaging.

Technique 2: assemble the crew

Felix raises the stakes on purpose: the deck has to be amazing or aliens blow up Earth, so who does humanity send? For quality, an analyst, a journalist, and an editor. If the deck gets presented, a motion designer and an audio designer. As a red team, a short seller and a forensic accountant.

For the landing page above, my crew would be:

Technique 3: do what they do, don't play them

This is Felix's warning, and it's the most important line in the Range section. It's easy to slip into role play, which makes your transcript weirder without improving the result. Use the crew to find fields and techniques. Don't ask the model to write like a short seller. Ask it to do what a short seller does to research a position.

I've watched this fail in my own sessions, and it's the same literal-instruction trap I dug into in my notes on Claude Opus 5 prompting. Ask for "a security expert's review" and you get a confident voice and the same checklist. Ask the agent to run a proxy, replay the form submission with malformed input, and report what the server returns, and you get findings. A useful self-check: if a "persona" in your prompt doesn't come with a tool or a method, delete it.

Copy-paste template: Range

Task: [TASK].

1. Rewrite this task as verbs: what is it actually trying to make people
   believe, decide, or do, and under what constraints?
2. From those verbs, list 4–6 fields whose experts would approach this
   differently. Include one adversarial field (a red team) whose job is
   to find why this fails.
3. For each field, give: the job they'd actually do here, the method or
   tool they'd use, and what their output would be.
4. Run each field as a separate subagent using that field's method.
   No role play: a subagent without a concrete method gets cut.
5. Merge the findings. Where fields disagree, show the disagreement and
   the evidence on each side instead of averaging it away.

If you'd rather have someone build this kind of multi-agent setup for your own projects (crew definitions, subagent wiring, outside judges, and all), it's the kind of engagement I take on. You can see what I've built at fiverr.com/s/EgxYmWD.

The prerequisite Felix states once and everyone skips

Near the end of the practical section, Felix adds a line that's easy to miss: all of these forms of ambition require the model to have a computer where it can install software, and access to the relevant data, through MCP connectors or other means.

Without those two things, every template above falls back into role play. Without a staging server, a "keep the site healthy" Altitude prompt can't do anything. A Depth prompt that names semgrep is decoration if semgrep can't be installed. A Range crew with a performance engineer is just a persona if nobody can run Lighthouse.

So before you raise the ambition of a prompt, raise the access. My short checklist:

• Can the agent run code and install tools in a sandbox?
• Can it read the raw data (exports, logs, source), not just a summary?
• Is there an outside judge it can run without me (tests, a measurement, a reproduction)?
• Is there a written line between what it may do alone and what needs approval?

Three yeses and you can try rung 3. One yes and you're doing Speed with extra words.

Which brings me back to my own commit, and to the rule I broke.

Where my own pipeline breaks Felix's most important rule

When I added those six publish gates in June, I was proud of the scoring system. Every draft gets a 0–5 score on each gate, and three of them (intent, information gain, and experience) have a hard floor of 4. Anything below that gets labeled DRAFT — NOT PUBLISHABLE.

Now reread Felix's fifth Depth technique: do not ask the model to judge itself.

Who scores those gates? The same agent that wrote the draft. My quality system, the thing I built specifically to stop pumping out pages Google didn't want, is a model grading its own homework. It's better than no gate, because writing down the criteria forces the model to check against them. But it isn't an outside judge.

The real outside judge already exists, and it's the one that started all this: Search Console's indexing report. Google decides whether the page is worth keeping, not my agent. Here's the uncomfortable admission. The file in my repo that's meant to hold the verified-indexed URL list, so the agent can check its internal links against reality, still says "placeholder — needs GSC export." It was last touched in April. I built the self-grading part carefully and never connected the part that would let the real judge talk back.

What I'm changing, in order:

1. Export the indexed and not-indexed URL lists from Search Console monthly and commit them, so the agent's link checks run against Google's actual verdict.
2. Treat the self-score as a pre-check, not a verdict. The real pass/fail is whether the page gets indexed and holds a position after a few weeks.
3. Feed failures back into the gates. Every page Google declines is a labeled example of what "not worth indexing" looks like for my site.

That third step is Altitude again: from "score this draft" to "keep my site's pages indexed." It's the same move Felix made from fixing crashes to keeping apps crash-free.

Two more trade-offs worth saying out loud

Ambition and fixed-fee client work don't mix by default. If a client is paying for "update the plugins," quietly running rung 3 burns hours they didn't buy. The honest version is to run rung 2 (the three urgent decisions) and bring it to the client as a proposal. Ambition raises the standard. It doesn't give you permission to change the contract.

Depth costs tokens. Running real tools, reading raw logs, and spinning up a crew of subagents uses far more compute than filling in a template. For throwaway work, Speed really is the right call. The skill is knowing which tasks deserve the expense.

If you'd rather install this framework than retype it, RoboNuggets published an MIT-licensed Claude skill, be-ambitious, that turns Felix's essay into steps an agent follows: the Altitude ladder, the Depth questions, and the Range crew. It credits an earlier prompt-only version by DannyMac180. I have it installed. Its best rule is one Felix implies but never states this bluntly: "Ambition raises the standard, not the permissions."

Why does self-efficacy matter when the model does the work?

Felix ends his essay by explaining why any of this is necessary. His answer surprised me: the bottleneck isn't the model. It's us, and what we believe is possible.

He opens with Michelangelo, who famously didn't want to paint the Sistine Chapel ceiling. He was a sculptor, not a painter. The historical accounts back that up: he saw himself first as a sculptor, had little fresco experience, and accepted the commission reluctantly in 1508.

Psychology calls the underlying trait self-efficacy: people who believe more in their own abilities tend to accomplish more. And it can be hacked. Felix cites Edwin Locke and Gary Latham, whose 2002 American Psychologist paper, "Building a Practically Useful Theory of Goal Setting and Task Motivation," summarizes 35 years of research. Its central finding is that specific, hard goals produce better performance than being told to "do your best." He also points to Patrick Collison's Fast list, a sourced catalog of big projects done quickly: the Empire State Building in 410 days, Disneyland in 366, the P-80 Shooting Star jet in 143.

Felix lists three well-documented ways people get past their own beliefs. I checked each one.

Believe it's possible. In 1939, George Dantzig arrived late to Jerzy Neyman's statistics class at Berkeley, copied two problems from the board, and turned in solutions days later, apologizing that the homework seemed harder than usual. They were two famous unsolved problems in statistics. (Popular retellings exaggerate this. Dantzig's own 1986 interview is the reliable version.)

Watch someone else do it. Roger Bannister ran the first sub-four-minute mile, 3:59.4, at Oxford on May 6, 1954. John Landy beat it 46 days later in Turku, Finland. The same thing just happened in marathon running. On April 26, 2026, Sabastian Sawe won the London Marathon in 1:59:30, the first official sub-two-hour marathon. In the same race, Yomif Kejelcha finished 11 seconds behind him in 1:59:41, in his first-ever marathon.

Give yourself permission to fail. Felix mentions W. Timothy Gallwey's The Inner Game of Tennis (1974), whose core idea is that you don't play your best tennis when you're trying really, really hard. Engineers have their own example. In August 1991, Linus Torvalds announced his new operating system on comp.os.minix as "just a hobby, won't be big and professional like gnu."

What this means for prompts

All three ideas map directly onto working with models. That's the part I think gets missed.

• Dantzig is the unreasonable-goal technique. Tell the model the hard target is reasonable and it keeps going instead of stopping at the first wall.
• Bannister is Range. Seeing Alex Albert render rooms in Blender is what opened up 3D for Felix. Reading someone else's ambitious build log does the same for you. That's half the reason I write these posts.
• Gallwey is the outside judge. Permission to fail only works when something honest measures the result. A missed target with real numbers is a good outcome. A faked pass is not.

Felix's closing point is the one I keep returning to. Self-efficacy isn't a new problem, but it's a more powerful one now, because our abilities jump every few weeks. The ceiling isn't what the model can do. It's what we think to ask for.

Your move this week

Go back to the commit at the top of this post. I spent months making my pipeline faster before I asked what it was for. When I finally asked, I still let the model grade itself, and I didn't see that until a Claude engineer's essay named it.

So here's the challenge. Pick one task you'll hand a model in the next 24 hours, preferably a boring recurring one. Before you send it, write down three things: the goal beyond the goal, the rawest material an expert would start from, and the outside judge that will tell you whether the result is right. Then run Felix's "deeper, not bigger" prompt on it and compare.

If you can't name an outside judge, you've found the next piece of plumbing to build.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io