The Burden of Infinite Leverage: When You Can Build Anything, Nothing Is Easy

Last month I shipped more working software than I did in the entire first year I taught myself to code. Full features. Tested. Deployed. Some of it genuinely good. I did most of it while sitting on my couch, one hand holding a cup of tea.

I should feel unstoppable. I don't, quite. And I've been trying to figure out why.

---

What Leverage Actually Means

Archimedes supposedly said: give me a long enough lever and a place to stand, and I shall move the world. He was describing leverage in the physical sense — the mechanical advantage that lets a small force produce a large effect.

The concept migrated into finance sometime in the last few centuries. Leverage in that world means borrowing capital to amplify your bets. It works beautifully when things go right. The problem — and I say this as someone who used to be an accountant, which means I've seen the aftermath of leverage in the wild — is that leverage amplifies everything. The gains. The losses. The mistakes. The miscalculations. A 2x leveraged bet doesn't make you twice as rich or twice as poor. The math gets complicated fast, and the complications are rarely pleasant.

Then there's the kind of leverage we're all drowning in now. Technological leverage. AI leverage. The kind where you can describe what you want and watch it materialise faster than you can verify whether it was actually what you wanted.

I can now build in a weekend what used to take me a month. A solo developer in 2026 commands more execution power than a small engineering team did five years ago. The tools are extraordinary. The pace is dizzying.

But here's the thing nobody told me when I started accumulating all this capability: leverage, in every form it takes, doesn't remove risk. It just moves it somewhere less obvious.

The Bottleneck Has Always Been Judgment

For most of computing history, the friction was technical. You had to know the syntax. You had to debug the obscure error. You had to understand how the networking stack worked, or at minimum you had to learn enough to fake it. That friction acted as a forcing function — slow you down long enough that you'd think more carefully about what you were building before you committed to it.

That friction is mostly gone now.

I don't mean this hyperbolically. I mean: I can produce working, tested, deployed software from a description typed into a terminal. I can. I do. Regularly.

What this reveals — uncomfortably, in the way that a very clean mirror is uncomfortable — is that the bottleneck was never execution. It was always judgment. We just didn't notice because execution was expensive enough to hide it.

When deploying something takes two weeks, you naturally spend at least a few days deciding if you should. When deploying something takes an afternoon, you find out much faster whether the thing you deployed was worth building.

The cost of a bad decision used to be paid slowly: in effort, in late nights, in the long frustrating grind of implementation. Now it's paid instantly. You ship the wrong thing just as easily as you ship the right one. The only difference is that now there's nothing left to blame the mistake on except the idea itself.

The Paralysis of Infinite Optionality

There's a famous study from the 1990s about jam. Researchers set up a tasting station in a grocery store. One day they offered 24 varieties. Another day they offered 6. The display with 24 varieties attracted more browsers. But the 6-variety display sold ten times as much jam.

More options produced more browsing. Less choice produced more deciding.

I think about this a lot now.

When execution was expensive, the constraints made decisions for you. You couldn't build everything you imagined, so you built the thing you most wanted, or the thing a client was paying for, or the thing that had been sitting on your list long enough that you'd given up waiting for a better moment. Scarcity was uncomfortable, but it was also clarifying.

When execution becomes cheap, suddenly every half-formed idea is a live option. The Notion doc full of project ideas that you always maintained with the comfortable understanding that most of them would stay hypothetical? They don't have to stay hypothetical anymore.

And that's its own kind of weight.

I find myself spending more time staring at blank documents than I did when those documents would have taken me weeks to fill. The leverage hasn't made starting easier. It's made starting feel more consequential — because now I know the idea, not the execution, is what I'm actually committing to.

The New Cost of Being Wrong

Here's where I find myself most uncomfortable with all this capability.

When I was slower, making a mistake meant spending a lot of time on the wrong thing. That hurt, but it also taught. The mistake was embedded in the experience of making it. You couldn't not notice because you were living inside it for weeks.

When I'm fast, making a mistake means producing the wrong thing very quickly, very cleanly, with tests passing and documentation written and a deployment that actually works. The artifact is indistinguishable from a good decision except for the fact that nobody wanted it or it solved the wrong problem or it was built on a foundation that was going to have to move six months later.

The error is now invisible until it isn't. And by the time it becomes visible, there's usually more of it.

This is leverage's original danger, dressed in new clothes. When the cost per unit of output drops to near zero, the thing that determines outcomes isn't execution quality — it's directional accuracy. And directional accuracy is just judgment operating at scale.

I've shipped features nobody needed. Not because I was lazy about building them, but because I built them so quickly that I skipped the part where I'd normally have second-guessed the premise while fighting with the implementation. The doubt never had a chance to surface. The doubt is where a lot of the good thinking lives.

What the Bottleneck Looks Like Now

A few patterns I've noticed, in myself and in people I talk to who are navigating the same shift:

Shipping rate is not a success metric. I can ship five features in the time it used to take to ship one. Four of those might be fine. One might actively make things worse. If I'm measuring myself by throughput, that looks like progress. If I'm measuring by whether the things I build matter, the math is different.

Taste is harder to develop than skill. You can get better at execution by practicing execution. The feedback loop is direct — write code, see if it works, adjust. You get better at judgment by building things that fail in interesting ways and sitting with why they failed. That feedback loop is longer, messier, and doesn't compress the same way execution does. AI can match a senior engineer's execution almost immediately. It can't match their taste, because taste isn't in the weights — it's in the scar tissue.

The questions that matter most can't be automated. What should this do? Who is it for? Why now? What are we trading off? These questions resist tools. They're uncomfortable in a way that shipping something is not. When execution is easy, there's always something you could be building instead of sitting with those questions. The option to keep moving is seductive. The discipline to stop is the work.

Leverage amplifies whatever you point it at. If you point it at the wrong problem, you get a lot of very efficient wrong. If you point it at the right problem, you get something remarkable. The leverage is neutral. The direction is everything.

The Former Accountant's Version of This Concern

I spent years working with numbers, and the lesson financial leverage teaches — the one that gets learned at significant personal cost — is that leverage changes your relationship to risk. It doesn't eliminate it. It concentrates it.

When you were building slowly, mistakes were distributed across time. You'd catch some while building, some during testing, some after shipping, some six months later. The slow pace gave you multiple opportunities to course-correct.

When you're building fast, mistakes concentrate. You either catch them early — which requires asking the uncomfortable questions before you start — or you catch them late, all at once, with compounded interest.

The accountant in me is still reconciling whether that's a better deal.

I think it is, on balance. The capability is genuine. What I've shipped this year is better than what I would have shipped in five years of grinding it out alone. But the work hasn't gotten easier. It's gotten different. The hard part used to be building the thing. The hard part now is deciding whether the thing is worth building, which turns out to have always been the harder question — just with cover.

What I'm Still Figuring Out

I don't have a clean resolution to offer here. I don't think there is one.

The closest thing to a practice that seems to help: slow down at the beginning, not the middle. The time I used to spend debugging or fighting implementation details was, I now think, partially doing useful work — creating friction that let ideas settle. Without it, I've had to create my own artificial friction at the start. Write out the problem before writing any code. Explain it to someone who doesn't care about technology. Ask whether it still seems important in the morning.

Boring advice. Nothing that will fit on a slide deck. But leverage without that friction is how you end up having worked very hard on something that never mattered.

Archimedes needed a lever and a place to stand. We've all got the lever now. The place to stand — the fixed point, the vantage from which you can tell whether what you're moving is worth moving — that part was never the technical problem. It never will be.

---

Still working this out publicly. If you've been through something similar — or disagree with any of this — I'd actually like to hear it.