The model is no longer the bottleneck. We are.

There are two ways to use the same model right now. On one side, people wondering whether Claude helped an amateur astronomer spot a new planet, or Terence Tao talking about a new era for mathematics. On the other, most of us, still asking the model to rephrase an email or summarize a meeting.

Same tool, same subscription, two uses that have nothing in common.

If the difference doesn’t come from the tool, it comes from what we dare to ask of it. That’s the thesis of a post I read last week, and I want to break it down here, testing it against other sources and against a personal project that served as my test bed.

Felix Rieseberg and the question of ambition

Felix Rieseberg is an engineering manager at Anthropic, where he leads engineering for Claude.ai, Cowork and Claude Code Desktop. He also co-maintains Electron, and has worked at Slack, Stripe, Notion and Microsoft.

On October 13, 2026, he published How to be more ambitious: a tutorial for humans with models.

His starting point is simple. He often tells people to be “more ambitious” with models, and he realized that the advice, on its own, is useless. Nobody knows what to do with “be more ambitious”. So his post tries to make it actionable.

Along the way he quotes Terence Tao, for whom models are astounding in some directions and inadequate in others. Keep that idea in mind, it will come back.

The four kinds of ambition

Felix splits ambition into four axes.

Speed. Doing the same thing, faster. It’s the gain everyone already knows, and it has an established economic value. Felix deliberately sets it aside, and rightly so: stop there and you’re still rephrasing emails.

Altitude. Asking for an outcome rather than a task. Asking what you want to happen next, and what lies beyond the immediate goal.

His own example: he went from “fix this bug” to “keep the app bug-free”.

He also walks through a quarterly business review in three steps:

1. hand the model all the raw data and ask it what changed and why;
2. have it isolate the three most urgent decisions, with the case for and against each;
3. ask it to design something better than the quarterly deck for catching problems earlier, and run it alongside the current process for a quarter.

A sign you’re on this ground: the work would normally have required meetings.

Depth. Working the way the best expert in the field would, on the real data and tools rather than the surface of the task.

Where the model would happily produce a markdown table, insist on a database and a statistical model. Set unreasonable goals and treat them as reasonable: aim for a 200 ms load time when the current target is 5 seconds.

And above all, a point I’ll come back to: have the work judged by something outside the model, rather than asking it whether it’s happy with what it did. The nuance matters: the model runs the judge, ideally a tool it can execute itself for immediate feedback, but it isn’t the one delivering the verdict. A failing test can’t be talked round.

Range. Drawing on several disciplines, more than would have been economical before.

Felix borrows a trick from The Art of Innovation by Tom Kelley and Jonathan Littman: replace nouns with verbs. A “quarterly review” becomes “getting busy people to believe a story about cause and effect and decide under uncertainty”. Put that way, you immediately see that a journalist, an editor or an analyst would have something to say.

Hence the idea of assembling a crew of specialists, red team included. With a nuance I find spot on: ask the model to do what a specialist does, not to write like one. Role-play makes the transcripts weirder without making the result better.

And he sets one condition for all of this: the model needs a computer it can use, to install software, and access to the relevant data.

For his crash example, Felix first had to rebuild his own workflow: giving Claude the crash reports, the mapping from app versions to git commits, and test machines on Windows, macOS and Linux to reproduce and verify the fixes.

An example: FinOps Terminal

Without planning it, I found myself testing this framework on a personal project. I set myself a deliberately outsized goal: take inspiration from the Bloomberg Terminal to build my own market terminal, free, for my personal use.

The Bloomberg Terminal is the reference tool of trading floors, priced at around $32,000 per seat per year according to public estimates.

Let me say it right away so it’s clear: FinOps Terminal doesn’t play in the same league and doesn’t claim to.

It’s missing whole parts of what makes Bloomberg:

• the chat between subscribers, which is a big part of what keeps users there;
• the API and the integration with trading-floor tools;
• data freshness, since I use free sources, some of them delayed and unofficial, where Bloomberg sells licensed real-time data;
• the speed and reliability of professional infrastructure.

It’s an example to illustrate Felix’s point, not a competitor.

What interests me is how the three axes played out.

Altitude. I didn’t ask for “a stock chart”. I asked for a terminal.

The result is a SwiftUI macOS app with 17 keyboard-driven functions (quotes, charts, fundamentals, SEC filings, yield curve, screener, portfolio, alerts…), an iPad app that can act as the terminal’s keyboard, Apple TV dashboards and a dedicated backend.

FinOps Terminal on a Mac. Functions are called by their mnemonic (CHART, DESC, FIN, DCF…) or with a click in the sidebar.

One detail sums up the mindset. The Bloomberg Terminal is famous for its physical keyboard and its colored keys: one key per asset class, a GO to run a command, a CANCEL to back out. I don’t have that keyboard. Rather than drop the idea, I had the iPad play that role. In Keypad mode, it drives the Mac’s active panel with market keys, function keys, a red CANCEL, a green GO, a number pad and shortcuts to watchlists. A piece of hardware was missing, so we replaced it with a device we already had.

No Bloomberg keyboard? The iPad stands in for it. Ticker, yellow key, function, GO.

Depth. The project didn’t start with code but with a “clean room” study of the Bloomberg Terminal, based only on public documentation: how professionals use it, the security → function → GO grammar, linked panels, the context that carries from one screen to the next.

That’s exactly Felix’s “what would the best expert in the field do?”.

Behind it, real data sources (SEC EDGAR, FRED, Yahoo Finance, Binance) and real methods: discounted cash flow valuation, event studies, news sentiment analysis by Claude.

Range. SwiftUI, Python and FastAPI, iPadOS, tvOS, Docker, TimescaleDB, Proxmox, Tailscale, real-time crypto streams. For a single person, covering that many fields would never have been economical before.

A dashboard built on the Mac and shown on the living-room Apple TV.

But the part that best illustrates the post is Felix’s condition. I gave the AI near-full power.

It had an API token for my Proxmox. It created the virtual machine itself from a Debian image with cloud-init, installed the SSH key, configured the firewall, Tailscale and the Docker Compose stack, then deployed the backend. The scripts are idempotent, so it could rerun any step after an error without breaking anything.

One caveat, so the takeaway isn’t just “give your AI a root key”: the token is injected from 1Password without ever appearing in plain text, and everything runs on my homelab, not in production.

And above all, it was allowed to test the whole software from A to Z. The VM responds, the API accepts the connection, the Mac app pulls the data, the pytest and swift test suites pass.

Careful, though: the AI didn’t judge its own work. It never had to tell me “it’s fine, it works”: at almost every step, a real machine answered for it. The VM boots or it doesn’t, the API responds or it doesn’t. The AI ran the judge, the judge delivered the verdict. That’s exactly Felix’s distinction.

With one limit I’d rather state: the tests were also written by the AI. A judge you write yourself is only half independent. So the final word belongs to the real infrastructure, and to me, using the app.

The result: 4 days, 31 commits, about 19,000 lines of Swift and Python.

The real subject: self-efficacy

The part of Felix’s post that struck me most isn’t the method. It’s his answer to the question: why is it so hard to be ambitious?

His answer: we’re limited by what we believe is possible. We only trust ourselves within a narrow scope.

He points out that Michelangelo saw himself as a sculptor and didn’t want to paint the Sistine Chapel.

The concept behind this has a name in psychology: self-efficacy, the belief in your own ability to succeed at a task. And that belief affects actual performance.

The concept comes from Albert Bandura, who formalized it in 1977 and identified four sources of it. What’s interesting is that Felix’s examples cover three of them.

Believing it’s possible. In 1939, George Dantzig, a student at Berkeley, arrives late to class, copies two problems from the blackboard thinking they’re homework, and solves them. They were two statistics problems considered unsolved. Nobody had told him it was impossible.

Watching others succeed. Roger Bannister ran the mile in under four minutes in May 1954. He was the only one to have done it for 46 days, until John Landy beat him.

More recently, in April 2026 at the London Marathon, Sabastian Sawe became the first person to run an official marathon in under two hours, in 1:59:30. And in the same race, Yomif Kejelcha broke two hours too.

Having permission to fail. The Inner Game of Tennis, by Timothy Gallwey, argues that trying too hard hurts performance.

And Linus Torvalds announced Linux in 1991 as “just a hobby”, one that wouldn’t be big and professional.

Felix doesn’t name Bandura’s fourth source, yet it’s the one considered the most powerful: mastery experience. Having already succeeded at something comparable yourself.

I draw a very practical conclusion from it: ambition with models can’t be declared, it has to be built. Every slightly-too-big goal that works out, and is verified, makes the next one easier to attempt.

Felix also draws on the review by Locke and Latham, which sums up 35 years of goal-setting research: people given specific, hard goals outperform those simply told to “do their best”.

And on Patrick Collison’s Fast list, which catalogs achievements reached with audacious goals and tight deadlines.

His conclusion: self-efficacy is an old problem, but it matters more than ever, because model capabilities improve every few weeks. What we thought impossible last month may not be anymore.

The counterpoints

I don’t want to stop at enthusiasm, because several studies seriously qualify the story.

The jagged frontier. In 2023, a Harvard and BCG team led by Fabrizio Dell’Acqua had 758 consultants work with and without GPT-4.

On tasks the AI handled well, the assisted consultants completed 12% more tasks, 25% faster, with work rated 40% better.

But on a task chosen to sit just beyond what the model could do, they were markedly less likely to reach the right answer than those working without AI.

Ethan Mollick, a co-author, calls this the jagged technological frontier: you don’t always know which side of it you’re on. That’s exactly Tao’s observation. Being ambitious without knowing it means stepping outside the frontier.

Perception is not a judge. In 2025, the research group METR ran a randomized trial with 16 experienced open-source developers, on 246 real tasks from their own repositories.

Before the study, they expected AI to make them 24% faster. Afterwards, they estimated they had gained 20%. Measured, they had been 19% slower.

The sample is small and the tools have improved a lot since, but the message stands: our sense of efficiency proves nothing.

The Bannister myth. The story of the psychological barrier falling all at once is partly a legend. John Landy had failed several times before succeeding, and he was already very close to the record. Belief matters, but it isn’t enough: the training mattered too.

What the model didn’t give me. My study of the Bloomberg Terminal said it from the start: its lasting value comes from the breadth of its data, the speed of navigation and its network.

The model gave me the speed of navigation, and a lot of software. It gave me neither the licensed data, nor the user network, nor the infrastructure.

That’s the jagged frontier on a concrete case: ambition pays off on what is software, and hits a wall on what is access and people.

It all converges on the same point. Felix’s outside judge isn’t a methodological detail, it’s what makes ambition safe.

Without it, an outsized goal mostly produces things that look like they work. With it, you know which side of the frontier you’re on.

Dare to ask for more

In March 2023, Simon Willison wrote that AI-assisted development made him more ambitious, because it lowered his bar for deciding a project was worth it. Ideas that would have taken days of work became doable in an hour.

Three years later, the bar is even lower.

The question is no longer really what the model can do. It’s whether we dare to ask, whether we give it a computer and data to do it with, and whether we’ve planned how to verify the result.

The rest, as Felix says, is a matter of self-belief. And that can be trained.

---

Sources

• Felix Rieseberg, How to be more ambitious: a tutorial for humans with models, felixrieseberg.com
• Terence Tao, Math 2.0, terrytao.wordpress.com
• Gizmodo, Did Claude help an amateur astronomer discover a new planet?, gizmodo.com
• Fabrizio Dell’Acqua et al., Navigating the Jagged Technological Frontier, Harvard Business School and BCG, d3.harvard.edu
• Ethan Mollick, Centaurs and Cyborgs on the Jagged Frontier, oneusefulthing.org
• METR, randomized trial on experienced developer productivity, summarized by Axios
• Albert Bandura, Self-Efficacy: Toward a Unifying Theory of Behavioral Change (1977), overview on simplypsychology.org
• Edwin Locke and Gary Latham, retrospective on 35 years of goal-setting research, stanford.edu
• Patrick Collison, Fast, patrickcollison.com
• Simon Willison, AI-enhanced development makes me more ambitious with my projects, simonwillison.net
• NPR, Kenya’s Sabastian Sawe is first person to run sub-2-hour marathon, kunc.org
• Brain Food, The four-minute mile, brainfood.substack.com
• CostBench, estimated Bloomberg Terminal pricing, costbench.com
• FinOps Terminal, GitHub repository, github.com/gh-prim/finops-terminal
• Header image: Debasish Biswas, Hillary Step near Everest top, Wikimedia Commons, licensed CC BY-SA 4.0, cropped