Boil the Oceans
Why small ambitions are the real risk in the age of AI
Why small ambitions are the real risk in the age of AI
I was recently with a university endowment's head of private investing who told me their engineers were terrified for their jobs after seeing what Claude Code could do.
I get it. That's the natural first reaction. But it's the wrong one. It's a zero-sum reaction to a positive-sum moment.
You know the phrase: "don't boil the ocean." Everyone's said it in some overly ambitious meeting. It keeps teams focused. Prevents scope creep. Good advice when the cost of ambition was high.
That cost just collapsed.
The fear is proportional to the ambition
Here is what I think is going on with that fear: it's directly proportional to how small your ambitions are. If your plan is to keep doing exactly what you're doing, then yes, a machine that can do it faster and cheaper is terrifying. But if your plan is to do something dramatically bigger, the machine is the best news you've ever gotten.
John Cutler put it sharply last week: "In the middle of the largest technological transformation most of us will live through, the people whose job was to ask does this actually work for humans are the ones being let go. The questions still matter--arguably more than anything else--but the system decided the questions were slowing things down."
He's describing the zero-sum version of the story. Companies cutting the people who ask good questions because the questions feel like friction. That's the small-ambition play: same output, fewer people, slightly better margin.
But there's another version. Rachel Trebach, a senior UX researcher laid off from Amazon after four years of Exceeds Expectations and a recent promotion, built an app within days of getting the 5am text. Did she build it well? Who's to say. And that's the point.
The same technology that makes her role eliminable at Amazon makes her capable of building entire products independently. The tool is the same. The difference is the size of the ambition pointed at it.
Jevons Paradox for everything
Buckminster Fuller coined "ephemeralization" in 1938: doing more and more with less and less until eventually you can do everything with nothing. He traced this through structural engineering--each generation of bridges stronger, lighter, cheaper than the last. He wasn't describing job destruction. He was describing civilization getting better at being civilization.
This is Jevons Paradox applied to intelligence itself. When you make a resource dramatically more efficient, you don't use less of it. You use vastly more. Steam engines didn't reduce coal consumption. They made coal so useful that demand exploded.
The same thing is about to happen with every service and product we can imagine. Instead of worrying about doing the same thing for cheaper, the question becomes: why can't that endowment achieve 50% net IRR instead of 10%? Why can't a startup deliver a service 100x better than the incumbent? Why can't we talk to every single user and have a perfect understanding of every bug in our product?
As Ryan Petersen likes to say, the human desire for more things is absolutely limitless. We can fulfill that desire now--if we have the agency to prompt it for ourselves.
Where ambition meets infrastructure
But here's the thing about bigger ambitions: they're coordination problems, not capability problems. One person with Claude Code can build fast. Getting a team to build fast together is where things break down.
I know this because I've been living it. Over the past year, I built a personal Claude Code setup that felt like a superpower. A memory system that learns my preferences across sessions. Over 100 custom agent tools. Automated workflows that anticipate my next move. I was building in hours what used to take days.
Then I tried to share it with a team.
What I discovered wasn't a scaling problem. It was a category error. The patterns that made me productive as an individual created friction when multiple people entered the picture. My carefully tuned prompts conflicted with my colleagues' mental models. My context assumptions confused rather than clarified. The automation that felt effortless to me felt like black-box magic to everyone else.
This matters because it's the exact microcosm of the macro problem. The endowment's engineers are afraid because they're thinking about individual productivity--my job, my output, my replaceability. But individual productivity isn't the point. What matters is whether teams can use these tools together. And collective AI is a different engineering problem than personal AI.
The three ways individual productivity becomes collective confusion
After watching four teams stumble through AI adoption, I've seen three failure modes that nobody talks about.
Context redundancy. When five engineers each craft their own prompts and mental models for interacting with AI, you don't get five perspectives on the same problem. You get five slightly different realities, each internally consistent but mutually incompatible. Engineer A's prompt assumes microservices. Engineer B's assumes a monolith. Neither is wrong individually. When their AI-generated code meets in a pull request, the collision creates subtle bugs that neither AI nor human anticipated.
The context that made each person fast makes the team slow.
Context decay. AI makes decisions faster than teams can validate them. We generate architectural choices, coding patterns, and system assumptions faster than ever. But our verification processes--code review, testing, documentation--haven't kept pace. The result is a growing gap between what we think we know and what's true. AI doesn't encode our assumptions. It propagates them across the codebase before we've had time to question them.
Capability silos. "Why didn't anyone tell me we had a tool for that?" I've heard this on every team that's tried to scale AI-assisted development. Someone builds a brilliant automation and it languishes in their personal config while colleagues reinvent the wheel. Nobody knows who built what. Useful patterns look identical to personal quirks.
The irony: AI could help us share knowledge more effectively than ever, but our individual AI setups fragment that knowledge.
The architecture of team intelligence
Most organizations respond to AI adoption by sharing prompt libraries, wiki pages of tips, repositories of "useful AI patterns." Those are interface fixes for a structural problem. They decay immediately.
Ramp got this right. Their internal coding agent hit 30% adoption for merged pull requests across frontend and backend--without mandating usage. The difference wasn't their prompts or their model. It was what they chose to share.
They built cloud infrastructure where context is infrastructure, not individual configuration. Their agents execute in sandboxed virtual machines while maintaining full access to production systems. Engineers interact with databases, CI/CD, monitoring, feature flags, and communication platforms using the same processes that human engineers employ.
The AI doesn't have special access or privileged knowledge. It sees what engineers see, through the same interfaces engineers use. The context is shared because the infrastructure is shared.
Rather than share prompts, Ramp shared infrastructure. That's the architectural insight. The voluntary 30% adoption emerged because the tool worked. Engineers chose it because it worked, not because they were told to.
A framework for scaling ambition
Based on what works and what fails, I think about team AI context in four layers:
Layer 1: Live infrastructure. Connect AI to the systems that define current reality. CI status, monitoring dashboards, documentation, deployment state. This layer answers "what is true right now?" and should never be manually maintained. Infrastructure-based context can't go stale. When CI fails, the AI knows immediately.
Layer 2: Project context. Decisions and patterns that change slowly. Your CLAUDE.md file, architectural decision records, coding conventions. This layer answers "how do we do things here?" and should be checked into version control. It compounds over time.
Layer 3: Team capabilities. Skills, templates, and automations that work across contexts. This layer answers "what can we do?" and should be curated. The critical difference from Layer 2: capabilities are reusable across projects. They encode team knowledge rather than project knowledge.
Layer 4: Personal preferences. Individual productivity hacks. Keyboard shortcuts, prompt style, memory system preferences. This layer answers "how do I like to work?" and should stay private unless explicitly shared.
The mistake I made early on was treating everything as Layer 4--building personal infrastructure instead of team infrastructure. When I tried to share my setup, I was asking colleagues to adopt my preferences as their own. The organizations getting this right start at Layer 1 and build up.
Tech debt is a depreciating liability
There's a related shift happening that reinforces the case for bigger ambitions. As @braelyn_ai noted: "Tech debt is now a depreciating liability. Ship fast, create tech debt, in 6 months better code gen will make it easier to clean up than it is now."
This inverts the conventional wisdom about shipping velocity. The cost of building goes down. The cost of building the wrong thing goes down. Which means it makes economic sense to boil the ocean and throw a lot at the wall. But when experimentation explodes, the bottleneck shifts to validation: figuring out what worked and scaling it. That's a team coordination problem.
You can't identify what sticks if your team's AI context is fragmented across five incompatible realities. You can't scale what works if your capabilities are siloed in individual configs. The ambition to boil oceans requires the infrastructure to do it together.
The bear case
The Jevons Paradox argument assumes demand for intelligence-intensive work is elastic. Maybe it isn't. Maybe there's a ceiling on how much better products and services can get before consumers stop caring. Maybe the endowment's 50% net IRR is constrained by market structure, not analytical capability.
And the team collaboration framework assumes organizations will invest in shared infrastructure rather than handing everyone individual AI accounts and calling it transformation. Most won't. Most will treat AI the way they treated previous platform shifts: bolt it onto existing processes, capture 10% of the value, and declare victory.
The gap between what's possible and what most organizations will do is enormous. That gap is where startups have always lived.
Workers, builders, and the new question
If you're a worker--someone who trades labor for a living--this is the moment to become a builder. Start a business. The tools to do it have never been more accessible. Rachel Trebach built an app within days of losing her job. The barrier isn't capability anymore. It's ambition.
If you're already management or capital, it's time to go 10x more hardcore on what your aspirations could be. Not eking out 5% efficiency gains. Not increasing profit margins by lowering cost and firing the people who ask good questions. Those are the old games.
The new question: what would it look like to build a product or service so good that people would happily pay 10x what they pay now?
The net result of this is more jobs, not fewer. But only if capital and management raise their ambitions. Jevons Paradox doesn't activate on its own. It requires people to see the abundance and build for it instead of optimizing for scarcity.
That's what startups have always been good at: moving fast in the face of radical uncertainty, building for the 10x future while everyone else optimizes for the 1.05x present.
The phrase was "don't boil the ocean." The new phrase is: start with a few lakes.
Time to start.