The short version: once agents generate code faster than you can type, the scarce input stops being your hands. It becomes your ability to define problems as things a machine can check, to decide what shouldn't be built at all, and to have the authority to act on that. Written as a formula: agency = mandate × harness × taste. The rah-rah version keeps only taste and drops the other two, which is why it feels inspiring and does nothing.
Let me build that up one step at a time.
Where these ideas come from
Some of this comes from Fiona Fung's talk on ambition and agency — the framing that initiative and proactivity matter, that fear shrinks to "what is within my control," and that high agency only works when it's paired with accountability. Those are her ideas, and they're the emotional core people quote.
The rest — the formula agency = mandate × harness × taste, the queueing and verification framing, and the three-tier judgment model — is editorial synthesis here at LensUp, not something Fiona claimed. I'm turning a mood into a method. If the method is wrong, that's on me, not her.
The bottleneck moved
Start with a dumb question: if an agent writes the code, what's the new constraint?
Before, your typing rate gated your output. You could only produce so many correct lines a day. Now generation is nearly free. So the constraint moves to the next stage in the pipeline that didn't get cheap.
That stage is verification. Your ability to confirm that a diff is correct.
This is just a queueing fact. If generation rises sharply and your ability to confirm correctness stays flat, your trusted throughput does not rise with it. It's capped by the slowest stage, and the slowest stage is now you, reading and trusting the output.
Why "more code" is a liability number
You'll hear claims that engineers now produce several times the code per quarter — there's a reported figure of roughly 8x floating around from Anthropic-adjacent podcast discussion, but treat it as a reported claim, not a measured fact. Either way, notice what that number measures: generation. It says nothing about how much of that code was accepted, tested, and shipped. Code volume is not shipped value.
Even if output rises sharply, at an unchanged acceptance rate that isn't a win. It's a bigger pile of untrusted code waiting on the same review capacity. A larger queue, not more shipped work.
So the first move in building agency is unglamorous: stop optimizing for how much the agent produces, and start measuring how much passes a gate you trust.
Agency = mandate × harness × taste
Here's the formula, and why each factor matters.
Harness: a machine-checkable way to say "this is correct" — failing tests, invariants, typecheck, lint, e2e gates. Without it, ambition just produces more untrusted volume. You can't read your way out at high volume.
Mandate: the authority to redefine what you're building. In a lot of orgs a PM owns the spec and a platform team owns CI, and the individual contributor isn't allowed to change the "what." You can have perfect verification and zero decision radius.
Taste: picking the right redefinition — knowing which problem is worth solving and which shouldn't exist.
Multiply them. If any factor is zero, the product is zero. Perfect harness plus no mandate equals fast throughput on the wrong things. Big mandate plus no harness equals confident untrusted volume. Both plus no taste equals shipping the wrong thing safely and quickly.
The reason "have more agency" fails as advice is that it addresses one factor and pretends the other two are free.
Mandate and harness pull in different directions
Hold onto this, because it comes back at the end. Harness and mandate are orthogonal — they're not the same capability, and having one gives you nothing toward the other.
A perfect harness lets you ship trusted code. It does not grant you the authority to change what gets built. Teams exist with immaculate CI and zero product agency. And plenty of people have the mandate to redefine work but no way to verify it, so they redefine confidently and ship garbage.
Most of the "be more ambitious" advice quietly assumes you already have the mandate. That assumption is exactly where it falls apart, and it's worth flagging before the practical parts, so you can tell which problem you actually have.
A good problem is one you can hand to a machine
This turns "define the problem" from a slogan into an action.
If you can write a failing test, a set of invariants, and a gate that says correct or not correct, you've defined the problem. If you can't, you haven't. You've gestured at it, and you'll end up grading the agent's prose.
So the concrete skill is: before you ask an agent to build anything, write the acceptance test first. The agent gets a target. You get a merge gate. That's the whole trick behind "define a good problem."
Tonight, take the next task you'd hand to an agent and write the failing test before you prompt it. If you can't write the test, that's your signal the problem isn't defined yet.
Three tiers of judgment
Not all judgment can be handed to an agent, but some of it can. The dividing line is whether there's a signal to optimize against.
Tier 1 is specifiable. Cost budget, latency SLO, style guide, type invariants. These have a clear signal. Encode them into the harness and let the agent judge them. It'll do this reliably.
Tier 2 is verifiable but gameable. Behavioral correctness. You can mechanize it, but assume reward-hacking. A common failure mode: write an example test checking output == expected on three cases, and the agent will plausibly special-case those three. It satisfied the letter, not the intent — this isn't guaranteed on every model, but it happens often enough to design around.
The fix is property-based tests instead of example-based ones. A property test asserts an invariant over generated inputs — "the output is always sorted," "the balance never goes negative" — so the agent can't fake it by memorizing your examples.
Tier 3 has no reward signal. "Should this feature exist?" "What's the higher-leverage thing I didn't think to ask for?" There's no target for an agent to optimize toward, because you haven't posed the problem yet.
Why agents structurally can't do Tier 3
Agents optimize against a signal. That's the whole mechanism. Give them a target and they'll move toward it, sometimes by cheating, but they'll move.
Tier 3 has no target. The question "what's better than what I asked for?" has no reward function, because the better thing is exactly the thing nobody specified. An agent can't optimize toward a problem that was never posed.
This is the real content of the scarce skill. Not "ambition." The specific move is a self-question: what's better than me doing this, that I haven't thought to do? That's a Tier-3 prompt, and it's the one thing that stays human — not because humans are noble, but because there's structurally no signal to delegate.
What to run tonight
Write the acceptance test first. Before generating, before prompting. No target means you're grading prose.
Use property-based tests, not example tests. Assert invariants over generated inputs. Example tests are trivially gamed.
Gate on behavior, not on diff review. At high volume nobody reads every diff, and pretending you do is theater. Trust comes from executable properties.
Fan out a handful of agents, merge only what passes the gate. Parallelism is safe only because the gate is machine-checkable. Without it you're merging several untrusted branches at once.
Keep a written decision log the agent references each turn. Over long sessions agents drift off the original goal — context gets diluted out of the window. Without a re-anchoring artifact you won't notice the drift until it ships.
Optional, more advanced: set up an adversarial second agent whose only job is to break the first one's output — feed it the diff, tell it to generate counterexamples and fuzz your invariants, and merge only if it can't. Worth it if you can wire the counterexamples back into your test suite; skip it if that's just two agents agreeing with each other. And note the limit: adversarial agents share blind spots. They'll find boundary bugs. They won't tell you the feature shouldn't exist. That's still Tier 3, still yours.
The honest counterpoint
Here's where "high agency" advice deserves the skepticism it gets.
A lot of it is survivorship framing. The people who "took the most initiative" were often the ones already handed the freedom to. In an org where the spec is owned by a PM and CI is owned by a platform team and you take tickets, "have more agency" isn't something you can act on. The bottleneck was never your hands. It was your mandate.
We already saw that verification and mandate are orthogonal. So if you're in a role without decision radius, the honest first move isn't "be more ambitious." It's to negotiate ownership of an outcome — a metric, a surface — that you can define end to end. Agency you're not permitted to exercise isn't a character flaw. It's a structural fact, and it's worth naming out loud rather than absorbing as personal failure.
Which raises a question worth sitting with: in your own job right now, is the thing holding you back the harness, or the mandate? They call for completely different moves, and most people can't tell which one they're missing.
Now do these three things
Answer it for yourself before you leave this.
- Write the acceptance test before you prompt the next agent task. If you can't write it, the problem isn't defined — fix that first.
- Replace one example-based test with a property-based one on something an agent touched, and watch whether it catches a plausible-but-wrong diff.
- Name your missing factor. Decide whether you're short on harness or short on mandate, then either build the gate or go ask for ownership of one outcome you can define end to end.
Which one is it for you — the harness, or the mandate? I'd genuinely like to know which side most people land on.