The Ceiling Is the Ask

Claude drafted this from one of my work sessions, my prompts and my notes, and I edited it until it sounded like me. The opinions, and the decisions in the story, are mine. Posts like this one lean on AI more than my thought pieces do.

For a long time I treated agents like junior engineers, and my AGENTS.md and skills were written that way: small tasks, tight scope, check in before anything big. The models outgrew that. They work at a senior level now, and my own guidelines had become the ceiling on what I got out of them. I knew agents could help us build much better software than we were building. I just didn’t know how to start.

Most of us use agents for speed. Same task we would have done anyway, just faster. That’s useful, and it’s also the smallest thing these tools can do for us.

Felix Rieseberg, an engineering manager at Anthropic who works on Claude, wrote How to be more ambitious: A tutorial for humans with models. His argument is that we underuse these models because we don’t expect enough of them, and that when something impressive happens, the right move is to ask for more. One line from it stuck with me: “I want a deeper version of this task, not a bigger one.”

The Ceiling

You have a task in your head sized to what you could finish today, and you hand that exact task to the agent. Fix this crash. Write tests for this class. Summarize this article. The agent does it, the result is fine, and the ceiling never moves.

Felix’s point is that the ceiling is usually us, not the model. He leans on research into self-efficacy: specific, hard goals beat “do your best”, and people who believe they can do a thing attempt more of it. One of his examples is George Dantzig, who solved two open problems in statistics because he showed up late to class and thought they were homework.

The other half is that “model capabilities don’t grow uniformly.” You don’t find out what an agent can do on your codebase unless you ask past what you expect, because the jump from last quarter’s model might be in exactly the place you stopped asking.

Every codebase I’ve worked in has a list of work everyone agrees matters and nobody gets to, because it’s too big for one person to fit in a sprint. Ours has long-running workflows with no tests at the level that matters, and test files that sit fully commented out. Nobody was going to pick that up on a Tuesday afternoon, and that’s exactly the kind of work where asking for more pays off.

I do this too. When we moved our API docs to Scalar and the .NET OpenAPI generator, one endpoint broke on a bool. We fixed the bool. Then it broke on an enum, and my ask was to “investigate that rq”. Then I was typing “UGH I need you to investigate these changes we made against V1 and V2 to identify regressions”. That pass found the same enum bug waiting on a second set of routes that serialize through their own JSON options. Every one of those asks was sized to the bug in front of me. The outcome I wanted was “the migration doesn’t change what goes over the wire”, and the judge for that is a diff of every endpoint’s request and response shapes before and after. One ask like that up front would have caught all three.

The Ladder

Felix splits ambition into four kinds. Speed is the one everyone already gets, so he skips it, and so will I.

Altitude is asking what the goal is behind the goal. His example is going from “fix this crash” to “keep the apps crash-free”, which meant wiring Claude up to pull crash reports, map app versions to commits, and reproduce bugs on all three desktop platforms. The task is the bottom rung. The outcome is the state of the world you actually want. The system is whatever keeps that outcome true without anyone asking again.

Depth is working the way the best person in that field would. Start from the rawest source (logs, traces, the actual ticket thread), use the instruments they use (profilers, benchmarks, queries, statistics), and give it a number that feels unreasonable. 200ms, not “faster”. Then let something other than the agent judge the result.

Range is borrowing from fields you wouldn’t think of. The trick is replacing the noun with a verb: “README” becomes “get a skeptical dev to trust this tool in 30 seconds”. Once it’s a verb, you can ask who does that for a living and have the agent do their work. Not write in their voice. Do their work.

I turned the article into two things. The first is an Ambition section that lives in my user-level AGENTS.md, so every session gets it. It adds two rules of my own on top of Felix’s: when I give a number, it’s reachable, and when a lookup is slow or a check is manual, build the tool that does it.

## Ambition

Agents are my engineering team and I am the lead. Ambition lives in the goal and the verification. The diff stays scoped.

- Altitude: before non-trivial work, state in one line the outcome behind the task. "Fix this crash" serves "the app stays crash-free". Do the task, then end with the outcome-level next step as a proposal
- Depth: ask what a top practitioner would do here that I didn't ask for. Start from the rawest source (logs, data, traces, the actual ticket thread) and use the instruments they use (profilers, benchmarks, queries, statistics), then do it
- Hard targets: when I give a number, it is reachable; work toward it. When quality is measurable (latency, size, error rate), propose a number before starting
- Range: name the job as a verb, not a noun. "README" becomes "get a skeptical dev to trust this tool in 30 seconds". Ask which fields do that verb and do the work those practitioners do, not an imitation of their voice
- Tools over toil: when a lookup is slow, a step repeats, or a check is manual, build the script, CLI, or skill that does it and tell me

The second is an /ambition skill that points the same ideas at a single prompt. You hand it something rough and it grounds itself in the repo first (what logs, tests and CLIs already exist), climbs the ladder, turns the deliverable into a verb, and writes one paste-ready prompt with a checkable goal, a number, and a judge that isn’t the agent.

/ambition refactor the database copy orchestrator

That one-liner comes back as something like this, with the real file names and sizes filled in from the repo:

Make the copy workflow safe to change. CopyOrchestrator.cs (783 lines on top of a
2,160-line service) has no working orchestrator tests, and its test file is
entirely commented out.

1. Characterize first. Build a scripted orchestration context that records every
   activity call the current orchestrator makes, per scenario, to golden files.
   Nothing changes until the old behavior is pinned.
2. Fail every call. Rerun each scenario once per activity call with that call
   failing, and check after each run: resource locks restored, temp databases
   deleted, firewall rules and identity access removed, job in a terminal state.
   Report how many runs break one of those today.
3. Rebuild behind a flag using the declarative step pattern we already trialed,
   with a new API version in front of it.
4. Judge it with something other than yourself: a parity check that fails on any
   call-sequence difference not on a named list of intended changes, mutation
   testing on the new steps, and reviewer subagents that haven't seen your reasoning.

Target: zero broken runs for the new orchestrator across the full single-failure
sweep. Fan the work out to subagents in parallel worktrees, and package the harness
and playbook as a skill so the next orchestrator starts from it.

The one thing it refuses to do is make a prompt bigger and vaguer. The ambition goes in the goal and in how the work gets checked, and the diff stays scoped.

The Day

It started small. I pasted Anthropic’s formal verification write-up into a session and asked for a summary, and whether it was something we could use at work. That’s a speed ask. A fine one, but the answer would have been a paragraph and a shrug.

Six minutes later I pointed it at one of our worst workflows, a long-running orchestration that copies databases between environments. It needed a massive refactor anyway, and it was a good fit for a declarative step pattern we’d already trialed on a different set of workflows. Then, about an hour in, I stopped asking for the next step and asked for the outcome:

Build me an excalidraw diagram covering the proposed architecture. Then begin. Use sub-agents and orchestrate the refactor. Watch for potential skills & reusable prompts, guides. The work we do here is how we will propose refactoring all orchestrators. That being said, we need to vertical slice this & redo/new API version for [the copy] endpoints while we’re at it.

Looking back, that prompt hits all three rungs without me thinking about it. The task was “refactor the copy”. The outcome was “the copy can change safely”. The system was “this is how we refactor every orchestrator”, which is why it asked for skills and guides as part of the work rather than after it.

By late afternoon the session had run 14 subagents. Four mapped the ground first: the copy flow, the API surface, the patterns already in the repo, and an inventory of every orchestrator we have. Five built in parallel worktrees: a shared test harness, a new API version, the rebuilt orchestrator, the UI and CLI moving onto the new API, and a set of shared steps. Two were reviewers that hadn’t seen any of our reasoning. Two wrote skills, and one extended the harness.

The depth came from the judges, which I wrote up in more detail in Fail Every Call. Nothing got to call itself done because an agent said so:

• We made each cloud call fail, one at a time, and checked whether the copy still cleaned up after itself. In 105 of those runs the old orchestrator didn’t. It left resource locks off, leaked a temp database, or turned a successful copy into a failed job. The new one cleaned up every time.
• A parity check ran both orchestrators on the same scenarios and failed the build on any difference we hadn’t agreed to up front.
• Mutation checks broke the code on purpose to see whether our tests noticed. At first they mostly didn’t, which told us exactly which tests to fix.
• Reviewer agents that hadn’t seen any of our reasoning found a serious bug in code that was already in production.

The outputs that matter most aren’t the orchestrator. They’re what the next person starts from: a test harness that works for any orchestrator, a skill that turns the refactor playbook into something anyone can run, and a skill for scaffolding the next endpoint.

My part was the decisions. One whole area was out of scope. The old endpoints were so tied to a platform version we’re retiring that they had to be scrapped, not patched. The new cleanup order (resource locks go back last) needed a human to agree it was right. I read every review list and decided what got fixed now and what waited until after parity.

This started as a side quest for me, but I was quickly blown away by not only the efficiency but the thoroughness of what was happening. I’ve tried these types of refactors before, but I almost always ended up breaking things up into smaller chunks, very human level of me.

The Night

The harness proves a lot, but it runs against a scripted cloud. Proving the new orchestrator does the same real work against real resources means running copies old and new side by side, watching locks, diffing logs and cleaning up after. That’s grind, and it’s exactly the kind of work that gets pushed to a later sprint because nobody has time to sit with it.

Instead of sitting with it, I gave an agent the outcome and the limits before I logged off: plain copies only, no deletes, one retry per run, a time cap, and write down everything you create. By morning it had run old and new side by side on real copies, run the pair again across environments, and found three bugs no unit test was going to catch. It built its own tools along the way too, like log flatteners, a lock poller and a sequence differ. My part was reading the report and saying yes to cleanup.

The agents took the running, watching and diffing, and I kept the parts that need a person: what to test, where the limits were, and what to do about the bugs. The next time you catch yourself planning a day of babysitting something, write down the outcome and the limits instead, hand it off, and spend that day on the work only you can do.

This way I could start my day in a good spot knowing a bulk of the work was done, and it was time for executing more work on a concrete test surface. I had baselines, I could see that we had a fully functioning, regression free refactor of one of our largest pain points. This was amazing to see, because I could now see a potential path to scoping out this work for the rest of our platform.

The Rules

The skill is a starting point. Most of the payoff comes from how you run the session after it, and these are the rules I hold myself to:

1. Say the outcome before the task. One line. “Fix the flaky test” serves “the pipeline stays green”, and the agent should know which one it’s working for.
2. Give it a number. Latency, error rate, test count, mutants killed. If you can’t name one, you don’t have a judge yet.
3. Never let the agent grade its own work. Tests that go red first, mutation checks, the running app, a reviewer agent that hasn’t seen your reasoning. Your own reading of the code isn’t evidence either.
4. Map before you build. Fan the reading out to subagents and keep their conclusions, not the file dumps.
5. Build the tool the second time. A slow lookup, a manual check or a step the agent keeps walking through by hand becomes a script, a CLI command or a skill, and it goes in the repo where the next person finds it.
6. Keep the diff scoped. Ambition lives in the goal and the verification. Improvements you notice along the way go in a follow-up, not the same PR.
7. Own the decisions. The agents do the typing. Scope, tradeoffs, what ships and what waits are still yours.
8. Let it run while you’re gone. Before you log off, write down the outcome, the hard limits and where the report goes. Read the report and the cleanup list first thing in the morning.

The Cost

This isn’t free. Close to 20 subagents in a day burns a LOT of tokens compared to a normal session, and most tasks don’t need it. A one-line fix doesn’t need a system rung. Save the big asks for work that’s been too big to start.

The review load moves to you. The two reviewers came back with 12 items on one side and 14 on the other, and somebody has to read all of them and decide. If you run five builders in parallel and don’t have time to review five branches, you’ve just made a pile of unreviewed code faster. I’ve been running these reviews through my own tool, nittle. Shameless plug ;)

Ambitious sessions produce a lot of code that hasn’t touched production yet. The overnight runs hit real cloud resources, but through a worker on my machine with the new path forced on. Done means a deployed environment has run it for a while.

Unattended runs need their limits written down before you leave. My brief said no deletes, one retry per run and a 3-hour cap, and the agent kept to all of it. It still left a change request open from an attempt it aborted, and the cleanup the next morning left two more that only a human could close. Read the cleanup list every morning, and keep anything the agent can’t undo out of the brief.

“Refactor it and also fix the six bugs” sounds more ambitious, and it would have been the wrong ask, because then nobody could tell a regression from a fix. The new orchestrator fixes three of the six, each one on the named list of intended changes, and leaves the other three alone until after parity, so every difference traces back to one decision.

Next time I’d have the agent write a deterministic benchmark script or CLI command first and run that, instead of having agents drive every copy step by step. The overnight runs worked, but they were slow and token heavy. A script gives the same answer every time and is still there for the next person. It’s rule 5 again, and I didn’t follow it.

The Ask

Pick one task this week that you’d normally size down, and climb the ladder before you start. Take the outcome rung, give it a number, and put a judge on it that isn’t the agent. If part of it is grind (running, watching, diffing), write the limits down and let an agent run it while you work on something else.

I think it’s time we really lean into what these latest models can do. Adapt to agentic engineering, become more ambitious, use the tools at your disposal, and find the fun in developing in a way you haven’t before. Own the big picture, own innovating new ways to find your flow again, and be optimistic about what we can do with these tools.