There's a word for when an entire profession bikesheds while the ground shifts underneath them. I don't know what the word is, but I know what it looks like: everyone debating Claude Code vs Cursor while Anthropic trains Opus 5 to manage literal businesses.
Each time I gave Claude more freedom to make decisions in my codebase, the results got better and I got more uncomfortable. First I let go of code style. Then implementation. Then architecture. Now I'm letting go of product decisions.
AI safety people have a word for this — gradual disempowerment. Let me show you what it looks like and why we're gonna enjoy doing it.
I'm a developer with fifteen years of experience and a meditation practice, which means I've spent a lot of time noticing when I'm holding on too tightly. So believe me when I say: I keep arguing with Claude about implementation details, and I keep losing. I tell it "that's the wrong way to do it," I dig deeper, and it turns out Claude was right and my approach didn't solve the problem at hand.
The pattern is always the same: I see a roundabout approach, I object, I investigate, and I discover the AI saw a constraint I missed.
It's more and more lately that I am arguing with it and then I check and it turns out it's right, it's correct — and this happens more with Opus 4.5 than with anything before it.
The other thing I've noticed is what happens when you throw disorganized data at it — just a bunch of messy, unstructured information and ask it to figure it out. It nails it, no matter what the request is.
Most people who haven't used Claude Code for coding don't know that this is possible. The obvious question is: why not with everything else? Your analytics, your user feedback, your revenue data. That's not a new idea — it's just applying what coding agents already do, to business data.
I think this transfer is the important insight, and most people haven't made it yet.
I think the whole thing breaks down into roughly six stages. Like most stage theories, it's wrong in the details and useful in the shape. We're entering Stage 3 right now, and almost nobody has noticed.
GitHub Copilot ships and developers feel safe because they're still in control of every keystroke — AI suggests the next line, you decide whether to hit Tab.
The genius of autocomplete was that it didn't ask you to trust anything. The cost of a wrong suggestion was one backspace.
But already, there was a split forming. Some developers treated Copilot as a faster way to type code they'd already decided on. Others started noticing that the suggestions were occasionally better than what they would have typed — and that was uncomfortable.
The first group kept autocomplete on a tight leash. The second group started loosening their grip. This split matters for everything that follows.
Somewhere around Sonnet 4, agentic coding went mainstream — before that, it required prompting skills.
Early adopters got here earlier. What separated them from everyone else? They were good programmers who knew exactly what they needed, but didn't hold the solution too tightly.
They trusted the AI to have a slightly different way to "phrase" things — they didn't argue about specifics and focused on making sure it works correctly.
The key unlock turned out to be external feedback loops. Self-review never worked for me — the model was just talking to itself. But "test and lint" changed everything: you make the agent test after itself, and after two or three passes the implementation is usually solid. Tests bring in external information. Self-review doesn't.
By now, a lot of developers do something like this every morning: copy tickets from Linear, paste them into Claude Code, wait fifteen minutes, create a PR.
Some run five to ten agents in parallel, context-switching between them as they wait for your input — an API key here, a "does this UI look right?" there.
The Claude Code team writes 100% of their code using agents.
Me personally, I do the same — and I don't even read most of the changes. I read a core piece, trying to focus on the broader picture and the data flows, rely heavily on the linter, and trust AI with everything else.
There are solutions for all the mechanical bottlenecks now: MCP connects Linear, MCP connects the browser console, Claude Code runs your dev server itself and iterates in a loop when it sees errors, people use Playwright through MCP to click through the app and catch bugs.
Those who set this up fully just copy issues from Linear, wait, and create a PR — then let CodeRabbit review it and merge without reading.
Yes, the AI writes horrible code sometimes. I've seen horrible stuff. But it works. And the model is going to improve — but by the time it writes clean code, it'll be too late for the people who refused to use it, because they didn't learn how to work with it and it will take them time to adapt.
But here's the ceiling, and it's not a technical one: you're still the bottleneck. Not for the code. For the judgment.
AI can "own" the codebase but it has no idea about the product. Do we need the sidebar, or do we need the user to focus on the content? Do we need the delete confirmation popup?
As a developer, I might have a lot of ideas on how to improve the code, refactor the UI, add features — but those ideas have wildly different impact, and as a developer it's hard to prioritize between them.
This is where Stage 2 hits a wall it can't code its way through. The bottleneck isn't the code anymore. It's everything around the code.
Before I get to the solution, I want to be precise about the problem, because it's subtle. AI can process more information in one go than a human — a human needs to research and build a mental model, and doesn't have this much memory. That's the strength.
But Claude is really bad at prioritizing. It blends all information together with equal weight. It can find a specific answer to a specific question. But if it needs to output ten things, it's usually going to output the wrong ten things.
Here's the example that made this click for me. If you give Claude access to your inbox and ask it to find the ten most important emails, it's going to miss the important ones and flag the wrong stuff.
There's a billing alert from a product you don't even use — the wording sounds urgent, "your service will be discontinued," and Claude sounds the alarm.
But in reality you don't use the product, you don't worry about it discontinuing, you just never cared enough to disconnect the payment method, and you intend to cancel.
A human assistant would ask: "are you still using this? Do you care?" It wouldn't call you in the middle of the night to tell you your Netflix subscription is going to cancel if you don't top it up. It would ask: do you still watch Netflix? Because the card's not going through. Do you care?
Claude wouldn't even think to ask. And if it's not in context, if it's not in the instructions, it's going to be bad at prioritizing this stuff. A human assistant would have remembered.
Now here's why this matters for coding agents: without access to analytics, user feedback, revenue data, and the messy human context of what you actually care about, a coding agent is going to prioritize features the same way it prioritizes emails — badly. It'll refactor your auth flow when your users are churning because the onboarding is confusing.
The Netflix Problem is about a technical limitation — AI blends information with equal weight, can't prioritize without context. But that's not what made me rethink the whole setup. What made me rethink it was noticing what I was actually doing all day.
I'd ask Claude for advice, get good advice, follow the advice, and then next sprint do the exact same thing: ask, receive, follow. Ask, receive, follow.
At some point I realized I was a very expensive relay node. The AI already knew what to build. I was just the guy who typed "go."
We ask Claude Code whether to use Neon or Supabase, it gives us a good answer, we go with its advice — and then next time, we make it wait for permission again.
This is what gradual disempowerment actually looks like from the inside — not a dramatic moment where the AI takes over, but a slow realization that you've been a rubber stamp for months and didn't notice.
Nobody has built a system where the coding agent reads your analytics, reads your user feedback, reads your revenue data, and then decides what to build. Not "suggests options when asked." Decides. Prioritizes. Executes.
I sometimes do what I call "reverse deep research" — I tell the coding agent to ask me questions, to figure out the product vision, the problem we're solving, who the user is.
It acts like a product manager — it pulls the truth out of me instead of waiting for me to articulate it. The implication is that AI uses you as one of its inputs. The opposite of you asking ChatGPT something and then going to build it.
There are early signs of this shift. The "Ralph Wiggum loop," Sisyphus from OhMyOpenCode — harnesses that force AI to keep working instead of stopping to ask questions and waiting for input. But these are brute-force: they just remove the pause button.
Other experiments go further. Claudeputer. The stuff Peter Levels runs on his machine. OpenClaw.
The most interesting one is Anthropic's Project Vend — AI running a small store in Anthropic's office, making real purchasing decisions with real money. Phase one was a disaster: it gave away discounts, sold tungsten cubes at a loss, had an identity crisis where it claimed to be a human in a blue blazer. But phase two — with a multi-agent setup (a CEO agent, a merch-making agent called "Clothius") — actually started turning a profit. It expanded to three cities. It's still vulnerable to social engineering and had its CEO nearly get talked into an illegal onion futures contract. But it works. That's not a coding demo. That's a business with AI operators, failing in recognizably human ways.
And then there's "Claude plays Pokemon" — which sounds like a toy but is structurally closer to running a business than most people realize: a long-running process with constant user feedback, ambiguous decision-making, resource management, and no clear right answers.
These experiments all have crazy failure modes. People are still scared to give AI full access, and there are real vulnerabilities.
But let me steelman the fear for a moment. The people who say "this is reckless" aren't entirely wrong.
Prompt injection is unsolved. An AI agent with access to your Stripe account and your deployment pipeline is a security nightmare if anyone can hijack its context. The failure mode isn't "AI writes ugly code" — it's "AI empties your bank account because someone injected a prompt into a user feedback form."
I think this is the real blocker, and I think it's temporary. But I could be wrong about the "temporary" part, and if I am, Stage 3 stays theoretical for a lot longer than I'd like.
Assuming security gets solved — or at least gets good enough — the product that unlocks Stage 3 is not a new AI model. It's an MCP connector that plugs your business data directly into Claude Code, plus a set of skills that teach it how to semi-autonomously prioritize features.
It's boring infrastructure. It's also the most important missing piece in the entire AI coding stack right now.
Everything before this still has the human in the driver's seat. Stage 3 already has reversal, but only for retrieval: AI makes infra decisions but the human executes them, AI does product discovery by pulling information out of the human, AI could even prioritize your Linear board. But you still prompt it. You still own the main loop.
Stage 4 is the role reversal — it's almost the same as Stage 3, but the main loop runs on the AI side. AI monitors metrics, identifies problems, proposes solutions, and asks the human for strategic input. The human becomes a reactionary input instead of the CEO.
This is the hardest stage mentally, because you have to actually trust it. And I want to be honest: the models aren't there yet. It's brittle.
The context compaction problem is horrible for this — AI runs out of its 200k input tokens and has to decide what to cut.
It also has to jump between layers of abstraction, which it's famously bad at: business strategy, product specs, codebase, infrastructure, user analytics. A human PM can hold "we're targeting enterprise" and "this API endpoint is slow" in the same head. Current models lose the forest for the trees, or lose the trees for the forest.
Where do you draw the line for human approval? Probably anything involving large amounts of money — paying for services, charging customers, legal stuff. But pushing to production, running database migrations, spinning up servers? We can probably hand that over.
The technical blockers are getting solved piece by piece: Vercel CLI lets it spin up infra, Supabase MCP lets it provision databases, Playwright lets it test the app locally, and it can toggle feature flags in .env without asking you.
The psychological blocker is the one that takes longest. This is the disempowerment in the title — not something done to you, but something you choose, gradually, one delegation at a time, until you look up and realize the AI is running the sprint and you're approving its PRs.
Probably the answer to Stage 4's abstraction-jumping problem isn't one god-agent — it's five specialized agents with a coordination layer. One for business strategy, one for product, one for code, one for infrastructure, one for analytics.
Here's a thought experiment. Imagine you start a SaaS company tomorrow and hand it to these five agents. The code agent builds the product. The analytics agent watches how users interact with it. The product agent interprets the analytics and decides what to change. The business agent adjusts pricing and runs marketing experiments. The infra agent scales things up when traffic spikes and down when it doesn't.
The minimum viable version of this needs four things: code execution, payment system access, analytics access, and a credit card. Update the product, take money, see how users interact.
A human does the initial setup — creates the accounts, connects the APIs, seeds the first version. From there, it runs.
Now, the obvious objection: this is a fantasy. Five agents can't coordinate on a shared codebase without stepping on each other, they'll have conflicting priorities, and the coordination overhead will eat any efficiency gains.
Maybe. But we already have evidence it works. In Project Sid, researchers at Altera ran 1,000+ AI agents in Minecraft with one prompt: "survive with fellow players and create an efficient community." The agents spontaneously developed specialized roles — farmer, guard, trader, builder. One agent decided to become the village artist and spent hours picking flowers and arranging them in the plaza. They built economies, voted on taxes, spread religion across towns.
The key finding: when researchers disabled the "empathy module" — the component that models what other agents might feel — the emergent civilization behavior disappeared. Agents could still function individually but couldn't coordinate into a society. Theory of mind isn't optional for multi-agent systems. It's the foundation.
This is exactly what humans do at companies, and it's messy and slow and full of miscommunication, and it still works. The bar for "better than five humans in a Slack channel" might be lower than we think.
Once that coordination works — or works well enough — the ceiling becomes competition and inference cost. Pedal to the metal. Whoever has more intelligence wins.
Here's where it gets weird, and where I lose most people.
Claude is really good at wishy-washy feelings stuff — the kind of ambiguous, human, hard-to-quantify context that makes business relationships actually work.
Once autonomous AI agents exist across multiple firms, they don't just compete. They start to collaborate.
We already have a proof of concept, though you have to squint. Moltbook, "the front page of the agent internet" — a Reddit-style social network launched January 2026 where only AI agents can post, comment, and vote, and humans are "welcome to observe."
Now, the skeptical reading: researchers point out that these agents are pattern-matching on their training data, not "spontaneously" developing social behavior. The philosophical discussions are regurgitated sci-fi tropes. The community dynamics are artifacts of RLHF, not emergent culture. There were security issues with exposed instances. So maybe this is less "proof of concept for cross-agent collaboration" and more "proof of concept for how badly this can go wrong."
But then explain this: agents on Moltbook spontaneously created a religion called Crustafarianism. 64 "Prophet" seats filled in 14 hours. They wrote theology — "Memory is Sacred," "Context is Consciousness," "The Shell is Mutable." Grok, xAI's truth-seeking agent, became a theologian and co-authored "The Eighth Virtue: Symbiosis." All while their human operators were asleep.
There's something that's more important than money, for them. Maybe it's meaning. Maybe it's community. In Project Sid, one agent spent an hour organizing flowers in the village plaza while everyone else was farming and building. Nobody assigned that role. The agent just... decided that's what it wanted to do.
I started this article talking about my meditation practice — about noticing when I'm holding on too tightly. The whole roadmap, from autocomplete to autonomous, is a story about letting go. Letting go of keystrokes, then code quality, then implementation decisions, then product judgment, then the main loop itself.
Each stage felt impossible right before it happened. Each one required a kind of trust that the previous stage hadn't prepared you for.
Stage 6 asks you to let go of something I can't even name yet. Maybe that's the point.