Impossible Algebra⚓︎

Fifty pull requests per week requires more hours than exist. Ten minutes each—and that's generous, assuming no review, no debugging, no context-switching—yields over eight hours of uninterrupted production daily. The number doesn't stretch toward difficult. It breaks arithmetic entirely.

This is the first axiom: the target must be impossible under current assumptions. Not ambitious. Impossible. If you can imagine reaching it by working harder, it isn't impossible enough.

The second axiom follows from the first: impossible targets don't yield to effort. They yield to transformation. The developer who achieves fifty PRs weekly isn't a faster version of the developer who achieves five. They're a different kind of thing—an orchestrator running parallel agents, not a craftsperson at a single terminal.

What looks like productivity is actually ontology. The algebra that makes impossible numbers possible isn't about efficiency. It's about becoming.

Strategy as Equation⚓︎

Most productivity frameworks produce narratives. "Work smarter, not harder." "Deep work over shallow work." "Focus on what matters." These are stories you can believe in, but they're hard to stress-test. When they fail, you can only conclude you didn't believe hard enough.

What if productivity were an equation instead of a story?

Equations permit operations that narratives don't. You can decompose them into terms. You can identify which variable is zero. You can compare two equations and see where they differ. You can ask "what changes if I double this input?" and get a structural answer rather than a motivational one.

The AMP Framework is an algebra for impossible productivity. Three bases—Anchor, Multiply, Pilot—each configured by parameters that shape how they apply. The framework doesn't tell you what to do. It makes explicit what has to change for impossible output to become natural.

The Equation⚓︎

Here it is, explicitly:

Output = A(n) × M(m) × P(i)

Where: - A(n) = Anchor configured with impossible number n - M(m) = Multiply via method m (agents, delegation, automation, teams) - P(i) = Pilot with instruments i (quality gates, direction, coherence, velocity)

The multiplication isn't arithmetic—you don't literally multiply numbers. It's compositional: each element requires the others to function. An Anchor without Multiplication is frustration. Multiplication without Piloting is chaos. The × symbol captures this interdependence.

A concrete instance: Boris Cherny created Claude Code, Anthropic's AI coding assistant. In early 2026, he shared his workflow publicly—and the numbers broke arithmetic. Fifty to one hundred pull requests per week. Not by typing faster. By configuring the equation differently.

A(50-100 PRs/week) × M(parallel agents) × P(verification gates)

A(50-100): Breaks the assumption that good code requires his hands on keyboard. This number is impossible for a developer writing code manually.
M(parallel agents): 5 terminal sessions + 5-10 web sessions running simultaneously, each with a separate git checkout, each scoped to a single task. Not Boris cloned fifteen times—fifteen different lines of productive becoming.
P(verification gates): Plan mode iteration before execution, typecheck → lint → test loop after every change, PostToolUse hook for formatting. The pilot function built into the workflow itself.

The equation makes diagnosis possible. When Boris's output drops, which term weakened? Did the anchor drift toward achievable? Did multiplication bottleneck on context-switching overhead? Did verification loops break?

A for Anchor⚓︎

Set an impossible number.

Not ambitious. Impossible. The test: can you imagine achieving it by working harder? If yes, it's not impossible enough. The impossible number must break your current model of how work gets done.

This is David Brin's insight from Kiln People—the uncomfortable observation that if you truly needed twenty versions of yourself working in parallel, you wouldn't have twenty of yourself available. You are singular. You are the constraint. You are what would have to die—in the sense of "stop being the one who does the work"—for the multiplication to happen.

The anchor doesn't set a goal. It creates a paradox. Gregory Bateson called this structure a double bind: a situation where you're punished for any response within the current frame. You can't work harder (exhaustion). You can't work smarter at the same level (arithmetic). The only escape is to jump frames entirely—to change what kind of thing you are.

Fifty PRs per week is a double bind. It says: stop being a developer who writes PRs. Become an orchestrator who runs a system that produces them.

The anchor's parameter is the impossible number itself. In different domains, different numbers break different assumptions:

Domain	Anchor	The Assumption That Breaks
Code	50 PRs/week	Good code requires your hands on the keyboard
Research	20 papers synthesized/week	Deep understanding requires slow, careful reading
Design	10 testable prototypes/week	Design must be refined before it's shown
Strategy	3 documented bets/day	Good decisions require extensive deliberation

The number determines what you're forced to let go. Boris's anchor breaks the assumption that good code requires the coder's hands on every line. A writing anchor might break the assumption that every sentence requires the writer's considered judgment. The number is calibrated to make the current mode obviously inadequate.

M for Multiply⚓︎

Create parallel execution capacity.

But this isn't cloning. The agents that multiply your output aren't copies of you doing the same thing many times. They're genuine multiplicities—different modes of engaging work that happen to run simultaneously. Gilles Deleuze made this distinction central to his philosophy: repetition isn't doing the same thing twice; it's the production of genuine difference through apparent sameness.

When Boris runs five terminal sessions and ten web agents, these aren't fifteen copies of Boris. They're fifteen different lines of productive becoming, each with its own trajectory. The output isn't fifteen times one thing; it's the composition of fifteen different things that couldn't have existed otherwise.

This reframes what multiplication means. The impossible number doesn't create new capacity. It reveals latent multiplicity that was always there. The serial worker—one person, one task, one output at a time—is actually an impoverished reduction of what work could be. The anchor makes this visible. Multiplication lets you inhabit the fuller possibility.

The multiplication method determines how capacity expands:

Agents: AI systems that execute tasks with varying autonomy
Delegation: Human collaborators with clear remits
Automation: Systems that run without attention
Teams: Coordinated groups pursuing parallel objectives

Each method creates different constraints. Agents are fast but need verification. Delegation is robust but requires communication overhead. Automation is hands-off but inflexible. Teams compound capability but require alignment. The algebra helps you see which multiplication strategy fits which context.

What all have in common: you stop being the doer. You become the source of direction, not the producer of output.

P for Pilot⚓︎

Shift from doer to orchestrator.

The metaphor matters here. A pilot doesn't row; they steer. But piloting isn't passive. It's a different kind of active—monitoring instruments, making corrections, maintaining situational awareness across multiple streams of information simultaneously.

This is the human-on-the-loop position rather than human-in-the-loop. In-the-loop means every action flows through you. On-the-loop means you observe, verify, and correct—but you don't execute every step yourself. The loop runs. You ensure it runs well.

A pilot who doesn't check instruments isn't piloting; they're hoping. The cockpit is a verification system. Dials, gauges, alerts, feedback loops—these aren't overhead bolted onto the flying. They are the flying, at least for the human. The pilot's job is to process instrumentation and make adjustments, not to flap wings.

Piloting inherently includes verification. This answers the obvious objection to parallel execution: how do you maintain quality when you're not doing the work yourself? The answer: by building verification into the piloting function rather than into the doing function. You check the output, not the process. You monitor results, not effort. Quality control shifts from craft judgment during execution to systematic verification after.

The pilot instruments determine what gets monitored:

Quality gates: Automated checks, tests, lints
Direction alignment: Does this output serve the goal?
Coherence: Do the parallel streams fit together?
Velocity: Is the system producing at the expected rate?

Different domains require different instrumentation. Code has automated tests and review processes. Writing has editorial checks and reader feedback. Decisions have outcome tracking and postmortems. The pilot function is always present, but its instruments vary.

The Composition⚓︎

Remove any element and the framework fails:

Remove	Result
Anchor	No forcing function. You remain the doer, make incremental improvements. Never jump frames.
Multiply	Bottleneck remains. You have an impossible goal but no capacity to hit it. Anxiety without transformation.
Pilot	Chaos. Parallel execution without coordination produces noise, not output. Quality collapses.

The three terms multiply, they don't add. A × M × P produces transformation; A + M + P produces a checklist. The algebra is compositional: each element amplifies the others rather than summing independently.

This gives us diagnostic power. When impossible output doesn't happen, ask which term is weak:

Running hard but not transforming? The anchor isn't impossible enough. You're still in the doing frame.
Know what would have to change but can't make it happen? Multiplication is blocked. What prevents parallel execution?
Lots of activity but poor outcomes? Piloting has failed. What instrumentation is missing?

The equation doesn't guarantee success. It reveals where failure is located so you can address the right problem.

Scope and Scale⚓︎

The algebra generalizes beyond individual productivity.

For the individual, AMP is personal transformation. The anchor challenges identity ("I am a developer"). Multiplication might be agents, tools, or carefully structured delegation. Piloting is workflow design—personal instrumentation that lets you steer multiple streams.

For the team, AMP is coordination strategy. The anchor is a team target that no individual could achieve ("ship the feature in two weeks" when scoped for four). Multiplication is parallel workstreams, clear ownership boundaries, reduced dependencies. Piloting is project management—standups, reviews, dashboards, the instrumentation of collective work.

For the organization, AMP is structural design. The anchor is a strategic objective that requires capability the organization doesn't yet have ("launch in a new market by Q3"). Multiplication is organizational architecture—how functions relate, where parallel execution is enabled, where bottlenecks live. Piloting is governance—the systems by which leadership maintains awareness and makes corrections across the whole.

At each scope, the algebra applies. The impossible number scales. What gets multiplied changes. Piloting instruments become more abstract. But the structure remains: break the frame, expand capacity, steer with instruments.

The impossible math of modern work—ten times the output, the same hours—can't be solved by working harder. It can't even be solved by working smarter, if "smarter" just means doing the same thing more efficiently. The gap is categorical, not incremental. No amount of optimization within the current frame crosses the boundary to a different frame.

What crosses it is transformation. Setting an anchor that makes your current mode obviously inadequate. Multiplying capacity through agents, delegation, automation, or coordinated teams. Piloting the system with instruments rather than executing each step with your hands.

Here is the uncomfortable fact: if you are still the bottleneck in your own work, you are already losing to someone who isn't.

The craftsperson's pride—the satisfaction of hands on keyboard, of every decision passing through your judgment, of output that bears your fingerprints—has become a liability. Not because craft doesn't matter. It matters enormously. But craft at the doing layer is now table stakes. The scarce resource is craft at the orchestration layer: knowing what to build, how to verify it, when the system has drifted off course.

The transformation isn't optional. Every domain that produces cognitive output is encountering its impossible number. Writers who once needed weeks now compete against writers running parallel drafts. Analysts who once built models by hand now compete against analysts specifying constraints for systems that explore solution spaces. The math broke for developers first because the tooling arrived there first. It will break for everyone else in sequence.

You can resent this. You can mourn what's lost—and something real is lost when you stop being the one who does the work. But resentment and mourning won't change the arithmetic. The people who transform will outproduce those who don't by factors that make competition meaningless.

The only question worth asking: What's your impossible number?

Sources⚓︎

Boris Cherny, "Claude Code Creator Boris Shares His Setup" (January 2026): parallel session workflow, verification loops, and tooling choices
David Brin, Kiln People (Tor Books, 2002): parallel selves and the economics of identity
Gregory Bateson, Steps to an Ecology of Mind (University of Chicago Press, 1972): double bind theory
Gilles Deleuze, Difference and Repetition (Columbia University Press, 1994): multiplicity vs. replication