I had the headline before I had the post.

“API + Skills Is a Poor Man’s MCP” — except I was going to argue the inversion: that MCP is the rich man’s overcomplication, a server process you stood up to wrap calls your agent could already make, and the lean move was always a skill plus a CLI. Spicy. Contrarian. The kind of take that does numbers in a feed.

Then I made the tactical error of fact-checking myself, and the post fell apart in my hands. What follows is the wreckage, reassembled into something truer than the dunk I wanted to write.

TL;DR: Skills and MCP aren’t competitors — comparing them is a category error. A skill is a recipe that runs in your runtime; MCP is a connection to a hosted service. For a solo dev wiring up their own workflow on a coding agent, skill + CLI wins on every axis that used to favor MCP — the context-bloat and cross-vendor arguments both got quietly erased in late 2025/early 2026. MCP earns its keep in exactly one situation: you’re a provider exposing a live, OAuth’d service to assistants you don’t own. The rule that falls out: consuming an API → skill + CLI. Providing a service → MCP.

The category error I was about to commit

The first crack: “API + skills vs MCP” quietly assumes the two live on the same shelf. They don’t.

A skill is knowledge. A markdown recipe — plus maybe a script — that teaches the agent how to do something, running in your runtime, on your machine, with tools you already have.

MCP is a connection to a running service. A server, behind a protocol, that the model talks to.

Comparing them is apples to orchards. One is “here’s how, go do it.” The other is “here’s a thing that’s already running, call it.” Most of the internet argues about them as if they’re competing products. They’re not even the same noun.

So the honest question isn’t “which wins.” It’s “when does a hosted service behind a contract beat a recipe you run yourself?” That’s a real question. I just assumed I knew the answer.

The two arguments that died before I finished typing

My case against MCP rested on two pillars. Both had already collapsed, and I hadn’t noticed.

Pillar one: context bloat. Every MCP server dumps all its tool schemas into the context window — a seven-server setup could eat 67K tokens before you typed a word, and the context window is the one resource your agent can’t buy back. Damning. Except in January 2026 Anthropic shipped tool search and defer_loading: now the model sees a search tool plus a couple of always-on tools, and pulls the rest on demand. Reported reductions of 85–95%. My killer stat became a “this used to be true.”

Pillar two: cross-vendor reach is MCP’s moat. Wrong by a different calendar. In December 2025, Agent Skills shipped as an open standard, and within 48 hours Microsoft put it in VS Code and OpenAI added it to ChatGPT and Codex. By spring, ~40 tools — Gemini CLI, JetBrains, Kiro, Goose — read the same SKILL.md. Skills are as universal as MCP now. The moat drained while I was sharpening my knives.

Fine. Two pillars down. The dunk still had three legs, I figured.

Watching the rest fall

Security? I’d claimed MCP gives you a safety edge. It doesn’t. If I want read-only GitHub access, I hand a read-only token to the skill or the MCP server — identical. The token scope is the gate, enforced at the API boundary, available to both. There’s no protocol-level security advantage. Gone.

Tokens? This one inverts, which delighted me until I realized it cut against my own thesis too. People assume MCP is token-cheap because the call — list_pull_requests(owner, repo) — is tidy. But the call isn’t the cost. The result is. The GitHub API returns fat JSON, and a raw MCP tool call dumps the whole blob into context. A skill that runs code can filter in the sandbox and return five lines. So code-that-filters wins on tokens — and a skill is code-that-filters by birth. But that’s an argument for skills, not against MCP-the-idea.

Auto-orchestration? “MCP composes calls for you.” No, it doesn’t. The protocol is transport — it has no “run this sequence, give me only the end” primitive. Either the model loops (every intermediate result round-trips through context — expensive) or a human pre-bakes a coarse server tool (effort). Automatic, token-cheap stacking only happens when you call tools from code — which is, once again, the skill model.

Every road kept leading back to the same place. I started to feel like the universe was trying to tell me something(sounds dramatic, I know).

The litmus test that almost saved the dunk

So I built a concrete test: “Fetch all open PRs, give me a gist of the modules they touch, merge only the ones tagged auth.”

Fetch and gist are reads — data-heavy aggregation, the code-that-filters sweet spot. Skill wins, easily. But merge is a write, and a dangerous one, and writes are where I figured MCP’s permission policy — pause and confirm each merge — would finally earn its keep.

Then a reader on the thread that became this post pointed out the obvious: gating decomposes into three questions, and only one is even arguably MCP’s.

• Capability — can a merge happen at all? The token scope answers that. Available to both. API-enforced.
• Selection — which PRs get merged? Your filtering code answers that. That’s the skill’s script.
• Confirmation — do you approve each one? You, in the loop on a coding agent — or a --confirm flag — or MCP’s native prompt.

Only the third row is MCP’s, and even there it’s matched by you-watching-bash or a confirm flag. On a coding agent with you present, skill plus the gh CLI wins the whole task. The merge didn’t flip it. You’re the permission policy.

That was the moment the dunk officially died. I went looking on Reddit to see who else had buried it.

What Reddit already knew

Turns out, everyone. The threads are a graveyard with two opposing headstones.

“Will MCP be dead soon?” — 406 comments. “I cannot, for the life of me, understand the value of MCPs” — 305 comments. “A eulogy for MCP (RIP).” “CLI > MCP?” Someone even shipped a tool that converts MCP servers into CLI + skill files and “cut ~97% token overhead.”

The auto-generated TL;DR of that 305-comment thread is, embarrassingly, the post I’d spent a day reverse-engineering: “You’re looking at this from a solo dev’s perspective, and you’re not wrong — Skills or telling Claude to use a CLI is often more efficient. MCP’s real value isn’t for your individual coding session, but for the broader ecosystem.”

So the solo-dev case is settled. But the people defending MCP weren’t demo-app tourists. They were running it in production, and they landed one punch I couldn’t slip.

The punch I couldn’t slip, and the one real win

From the eulogy thread, top comment: “People who claim there’s no need for MCP will, if they build projects of growing complexity, sooner or later reinvent everything MCP provides — but bespoke and non-standardized.” And a sharper one: “CLI + skills are great for solo dev vibes. But the second you need an LLM to orchestrate across multiple platforms with real auth and governance? You’re either using MCP or rebuilding it badly.”

That’s the one thing that survived every round. Not context, not security, not reach, not tokens. Distribution — of a specific kind.

Here’s the case, and it’s narrower than the hype and realer than my dunk: you’re a provider. You host a live service and you want it to show up as a one-click, OAuth’d connector inside every AI assistant your customers already use — Claude’s Connectors Directory (200+ integrations), ChatGPT Apps, all of it. Notion, Linear, and Stripe ship official remote MCP servers for exactly this. You build once; it lights up everywhere; the credentials and compute stay on your side.

A skill — even a universal one — cannot be that. A skill is a copy that runs in the consumer’s runtime, and that’s the whole limitation: it can only do what that runtime can do. Flip that around and you get the same win seen from the client’s side. Claude Desktop runs skills and has a code sandbox — but the sandbox can’t reach the open internet, so a skill that tries to curl GitHub dies at the egress wall, while an MCP server, running outside the box, reaches it fine. Same task, opposite answer, deciding variable is network egress. It’s not a second reason to use MCP. It’s the first reason wearing a different hat: when the consumer’s runtime can’t reach the thing, you need a service that can.

The rule: when to use MCP vs a skill + CLI

So, do you need MCP? Ask one question: are you consuming an API, or providing a service?

Wiring your own agent to someone’s existing API, on a coding tool with a shell — skill plus a CLI, every time. You will not “reinvent MCP badly,” because you need none of what MCP provides: no OAuth dance, no dynamic discovery, no cross-client reach. The CLI is complete, not a degenerate clone.

Exposing your own live service to assistants you don’t own, with auth and governance, across vendors — that’s MCP, and a CLI genuinely can’t do it.

MCP isn’t the poor man’s anything. It’s the platform’s protocol. You reach for it the moment you stop consuming APIs and start being an app inside other people’s assistants.

I know which side I’m on this week. I shipped ThreadHQ’s MCP server as a top-of-funnel for a reason — that’s the provider play, done on purpose. (ThreadHQ is one of the products I built solo with Claude Code; the MCP server is its distribution edge, not its plumbing.) But for the GitHub task on my own machine? I’m still just typing gh. The dunk was wrong. The honest version is sharper anyway.

A quick word on why now, before the how. Two reasons, and you’ve heard at least one:

1. AI is eating the jobs. You can’t open your phone without someone reminding you. Enough said.
2. The AI subsidy is going to end. Right now you’re building on frontier models that cost the labs more than they charge you. That window closes. I wrote about this here

Maybe both happen. Either way the move is the same: build the muscle now, while it’s cheap and you still have an edge.

1. What to build

Scratch your own itch. Do not spend three weeks “researching the market” to discover what people want. If you have a problem an app would fix, give yourself permission to build it. We’ll worry about market size after it ships.

Market research used to be load-bearing because building was expensive and being wrong was catastrophic — months of work, real money, dead on arrival. That math is gone. You can ship an app over a weekend now. The cost of being wrong is one wasted Saturday.

Paul Graham makes the sharper version of this point: build what you want, because — as he writes in How to Earn a Billion Dollars — “your own needs are uniquely valuable, because your needs predict future demand.” You’re not guessing what strangers want. You’re scratching an itch you can actually feel.

I’ve written about finding an idea and shipping it in a single sitting — here.

2. Know where you’re standing

Be honest about your starting point: do you have real development experience, or do you need to ramp up first? Here’s what I’d master before letting AI build for you

Yes, there are people on the internet shipping apps with zero coding background. Maybe. But if you can’t read what Claude Code writes, you can’t steer it — and you’ll feel that the first time it confidently drives into a wall. You don’t need a CS degree. You need enough of a mental model to call BS. The good news: you can learn development from Claude Code while you build with it. Learning and building at the same time is completely legitimate — it’s how I pick up half the things I use.

3. How I actually build

There’s no one true way. This is what works for me; your mileage may vary.

First, the unglamorous part: get the Claude Code Max plan. The $100 tier, or the $200 one if you can swing it. You cannot build anything meaningful on the cheap plans, and you’ll discover exactly why about four hours into your first real session. Don’t flinch at the price — it’s still cheaper than a tutor or a freelancer, and it doesn’t take lunch breaks. Plus the quality is consistently good.

Why Claude Code and not [the benchmark-topping model of the week]?

Because building a startup is already exhausting, and you do not have spare energy to spend benchmarking models and sharpening tools instead of shipping. Pick what works and stick with it.

Codex is a close second — genuinely good, and I keep it around. But Claude Code stays a step ahead for actually building apps, and after working with both, I reach for it first. Use both if you like. Just don’t turn tool selection into the project.

Boring choices win

Freeze your stack early — backend, frontend, database. 80% of it is identical across every app you’ll ever build, so stop re-deciding it every time. And don’t obsess over scale and optimization. Those are problems you earn by being successful. Good problems. You don’t have them yet.

4. Specs and context engineering: the part that decides everything

Two things determine whether you get your money’s worth out of Claude Code:

1. The specification
2. Context engineering

The spec

The more specific you are, the better the output. “Build a to-do app” gets you slop. “Here’s the auth flow, here’s the data model, here are the exact features” gets you something you can use. Spend real time here, before a single line of code gets written. More on this

The move that works best: make Claude Code interview you about the spec. If you can’t answer its questions, you can’t articulate the feature — and if you can’t articulate it, you can’t build it. By the time the spec is done, the MVP should have zero grey areas.

Context engineering

Even the best frontier model starts coding like it’s three drinks deep once the context fills up. So you manage it.

This takes me back to my assembly-language days — limited registers, limited memory, every instruction written with one eye on the resources you didn’t have. LLM context is that same constraint in new clothes. You get roughly 200k tokens, and that’s nowhere near enough to hold your whole app in its head at once.

So: one task per session. Two at the absolute most. Which means breaking the spec into session-sized tasks and tracking what’s done, what’s in flight, what’s blocked, and what depends on what.

A markdown to-do file is a terrible way to do this and a worse use of your time. I use beads. Adopted it early, still on it. It’s the fix for an agent that wakes up every morning with no memory of what you did yesterday.

This practice is also a lot kinder for your token limits.

Two flavors:

• the original, by the author — gastownhall/beads
• beads-rust, a simpler, more stable reimplementation of the spec in Rust — Dicklesworthstone/beads_rust

Use either. I landed on beads-rust. Pick your poison.

You also need memory across sessions. You’ll remember you fixed a bug two weeks ago; the model in today’s session won’t, and it’ll cheerfully hand you a wrong answer when you ask “did we already fix this?” I use claude-mem for that — thedotmack/claude-mem.

Point a Claude Code session at both repos and it’ll install them for you. (Yes, these work with Codex too — but again: shipping or tuning? The clock is running.)

Remember that spec? Hand it to your beads skill and it breaks down into a clean task list. Ask Claude to pull the high-leverage beads and start there — never more than two in flight.

Your CLAUDE.md matters

Treat it as a compass, not a second spec. The practices that matter (write the tests first), how the app deploys, the handful of goals you’re aiming at. Keep it light — cramming a novel into CLAUDE.md is the fastest way to make Claude dumber.

One more tool

ccstatusline. Configure it to show your remaining context percentage. It’s the fuel gauge that tells you whether to keep driving or pull over and start a fresh session.

Then it’s rinse and repeat: feed beads to Claude, do the manual QA yourself, close the bead, next one. A few sessions in, a sliver of a working MVP starts to emerge. When you’re happy with it, you ship.

5. Deploying it (without the Kubernetes tax)

I was a Kubernetes guy for years. Deployed everything on it. I no longer recommend it for solo developers — I explain why here. It still has its place and time; your weekend project is neither.

Use Kamal instead. Think of it as the compromise between Docker Compose and Kubernetes — Compose’s simplicity, enough of Kubernetes’ robustness, none of the YAML despair.

I’m also building VMKit to make this part disappear entirely — deploy without learning the nitty-gritty unless you want to.

Then there’s the wiring you don’t think about until it bites: monitoring and ops (I run mine through MCPs — the $30 stack), payments (Stripe; if you’re in India, Dodo Payments), and distribution — marketing and positioning, which is a beast all its own. Each of these deserves its own post.

TL;DR

• Build for your own itch. Shipping is cheaper than market research now.
• Get the Claude Code Max plan ($100, ideally $200). Don’t tool-shop.
• Spend your time on the spec — let Claude interview you until there are no grey areas.
• Engineer your context: one task per session, tracked with beads, remembered with claude-mem.
• Keep CLAUDE.md light. Watch your context gauge.
• Deploy with Kamal, not Kubernetes. Wire payments and monitoring last.
• The whole thing is a weekend, not a quarter.

On those days I didn’t ship less. I shipped nothing. I’d open my editor, remember Claude was down, stare at the codebase, close the editor. A single-vendor dependency masquerading as a workflow.

So I reluctantly installed Codex CLI. Poked at it. Resented it for a week. Then task by task — caught myself reaching for it on purpose, even when Claude was up.

I still don’t have the workflow figured out. What I do know is that “pick one” is the wrong frame, and the Reddit threads that get it right aren’t the ones with the most upvotes.

The One Sentence That Explains Everything

From a 520-upvote r/ClaudeCode thread analyzing both tools’ open-source prompts:

“Claude Code reads like a product trying to create initiative while Codex reads like a product trying to prevent drift.”
— u/idkwhattochoosz

And the pithier version, from the comments:

“Claude is more willing to sin by overreaching. Codex is more willing to sin by underreaching.”
— u/entheogenicentity

Read those twice. That’s not a model-quality take. That’s a product-philosophy take. Two teams looked at the same question — what should an agent do when it doesn’t know what you meant? — and picked opposite defaults. One said “guess and move.” The other said “ask and wait.”

Claude Code’s system prompt pushes hard toward initiative: “A good colleague faced with ambiguity doesn’t just stop — they investigate, reduce risk, and build understanding.” Codex’s harness does the opposite: narrow the ambiguity, verify, don’t guess.

Every “Claude vs Codex” benchmark you’ve seen is scoring two products that were never competing on the same axis. It’s like benchmarking a kayak against a sedan because they both move you forward.

My Honest Opinion: Codex’s Harness Is Better

This is going to get me yelled at in r/ClaudeCode, and that’s fine.

After several weeks running both, Codex’s harness feels more mature. Not the model — the harness. The scaffolding around the model. The way it handles ambiguity, scope, and completeness.

Three things Codex does that Claude Code still doesn’t:

1. It doesn’t lie about completion. Claude will hand you a summary saying the work is done, tests pass, shipping-ready. Codex more often flags what it didn’t fix, what it wasn’t sure about, what it skipped. One r/ClaudeCode commenter put it better than I can: “Claude will always claim all is done and ready, while Codex will flag it and say ‘no, there is this and this and this that still need to be fixed.’”

2. It respects your instructions. Claude treats CLAUDE.md as a helpful suggestion. Codex treats AGENTS.md as a contract. If you tell Codex “don’t touch the migration files,” it doesn’t touch them. If you tell Claude the same thing, you’ll find a migration file edit in the diff and a cheerful note about how it improved schema consistency.

3. The restraint scales better. Claude’s “volunteer more” bias is delightful at 30 minutes of work. It becomes a liability at 3 hours. Codex’s restraint is annoying in a small task and load-bearing in a long one.

None of this means Claude Code is bad. It means Claude Code is optimized for a different shape of work than I’m doing. The initiative bias is a great fit for exploration and greenfield work. For production changes to a real codebase, Codex’s paranoia is the right default.

Here’s the one that changed my mind. I built Supabyoi (managed self-hosted Supabase) with Claude Code. When the MVP felt feature-complete — Claude’s verdict, confidently delivered, complete with a tasteful little summary of everything that worked — I ran a second pass on Codex in a parallel directory (~/supabyoi-codex). Just to see.

Codex came back with a whole second project’s worth of findings. Not the usual “bugs Claude missed.” Bugs Claude had confidently signed off on. Shipping-ready, per Claude. Not shipping-ready, per Codex. Codex was right about every one of them.

That was the week I stopped treating Codex as the thing I installed during an outage and started treating it as a different kind of reviewer. Not better. Differently biased. A second pair of eyes is only useful if it’s not the same pair of eyes.

Why You Should Actually Run Both

The flip side — and this matters, because I don’t want this post read as “switch to Codex, you fool” — Claude’s initiative bias is a real asset. You just have to point it at the right phase of the work. The problem isn’t Claude. It’s that you’re using Claude for the part of the job Codex is better at, and vice versa.

Four reasons to dual-sub instead of picking:

1. Hallucination diversity. This is the biggest one and almost nobody articulates it clearly. From u/campbellm on Reddit:

“I’ve been doing ‘have claude write something, have codex review it, have claude consider and critique that review.’ It is VERY unlikely that both will hallucinate the same way.”

Two models trained on different data with different RLHF signals don’t fail identically. When Claude writes confident-but-wrong code, Codex flags it. When Codex skips a subtle edge case, Claude’s “check adjacent concerns” bias picks it up. You get a natural adversarial review without hiring anyone.

2. The planner-executor split. Use Claude for the part it’s good at — exploring a messy problem space, drafting a plan, proposing a dozen angles. Then hand the plan to Codex for implementation. u/ocombe on r/ClaudeCode: “Run claude for the plan & fast work, use codex for thorough plan & code reviews.” u/mrothro’s version: “I use Claude Code for ideating and small implementation, then tell it to run Codex to do complex implementations and code reviews.”

The pattern is consistent across the threads: Claude’s strength is at the start (wide search, first drafts); Codex’s strength is at the end (narrow, verify, harden).

3. Cross-harness rule enforcement. Rules one model ignores, the other enforces. If Claude drifts on a constraint you set, Codex catches it in review. If Codex is too literal and missed an obvious improvement, Claude’s adjacent-concerns bias surfaces it. Two different failure modes cancel each other out.

4. Throughput. Both platforms throttle hard at the Max/Pro tier. When Claude hits limits on Friday morning, you switch to Codex and keep shipping. One r/ClaudeCode commenter reported pulling down from a Claude 20x plan to 5x, then adding a $100/mo Codex plan — roughly the same total cost, dramatically more runway. I’m not sure that math works for everyone, but the principle holds: one subscription is a single point of failure.

Agent-Flywheel Is the Tooling Signal

There’s a product called agent-flywheel.com that pre-configures Claude Code, Codex CLI, and Gemini on a fresh VPS. Total damage — VPS plus both Max/Pro subs — lands between 440and440and656 a month. That’s a car payment for a car that writes your code.

What I find interesting isn’t the tool. It’s the bet underneath it: a whole product assumes real developers want all three installed by default. Six months ago that would have read as overkill. Today it reads as table stakes.

The hype cycle hasn’t caught up yet. The mainstream take is still “pick your favorite,” as though these were ice cream flavors. The people actually shipping production code with agents have quietly moved to “run both. Sometimes three. And don’t make a big deal about it.”

I’m planning to deploy it — not on a greenfield project (everybody has a greenfield story), but on an existing one already shipping to real users. The interesting question isn’t whether a three-agent stack works on a clean slate. It’s what breaks when you wire it into a codebase with real uptime constraints, customers, and six months of decisions the tooling didn’t witness. Real-world battle stories from agent-flywheel setups are scarce. I want to write one.

The Honest Part: I Don’t Have the Workflow Figured Out Yet

Everything above reads like I’ve got this nailed. I don’t. Here’s the list of things I still don’t know, offered in the spirit of not pretending:

When exactly to hand off. I know Claude should plan and Codex should review. I don’t have a clean trigger. Sometimes I bounce mid-implementation because Claude is about to go off the rails. Sometimes I trust Claude to finish and Codex only sees the final diff. The “right” cadence isn’t obvious.

How much context to share. Each agent wants the full CLAUDE.md / AGENTS.md treatment. Writing both, keeping them in sync, and remembering which one has which convention is its own small job. I haven’t found a clean answer.

Whether the adversarial review actually catches bugs. It sounds great in theory. In practice, most of the time both agents agree the work is done, and the bugs I catch in review are ones I would have caught with one agent too. The hallucination-diversity argument may be overstated at the tasks most of us are actually doing.

Whether the cost is worth it at my usage. I’m not running agents 40 hours a week. At $400+/month for the dual sub, I’m probably over-subscribed for my actual throughput. The math gets better if you’re coding all day. I’m not.

Who Should Dual-Sub, Who Shouldn’t

Do it if you’re a solo dev shipping production code daily. You’ll hit Friday-morning limits on one platform whether you budget for it or not, and the adversarial review actually catches things. The cost is real. The throughput gain is bigger. Do the math; it pencils.

Don’t bother if you code a few hours a week. The switching tax and the subscription burn aren’t worth it at low volume. Pick one and move on. Claude if you want initiative. Codex if you want restraint. Nobody is grading you on this.

It’s complicated if you’re at a day job where the company pays for one and you’ve got a side project. Use the company sub for the day job. Don’t stack a second personal sub unless the side project is actually shipping — not “actually going to ship next month,” actually shipping, this week, to real users. The number of people running dual subs to ship nothing is, I suspect, not small.

What This Is Really About

The “ditch ChatGPT for Claude” narrative was a 2025 story. It was right for its moment. But the 2026 version of that story isn’t “ditch Claude for Codex.” It’s “stop treating this as a winner-take-all market.”

Different models have different biases baked into their harnesses. Claude overreaches. Codex underreaches. Gemini is still figuring out its personality. The right move isn’t to pick the bias you like. It’s to stack biases against each other so their failure modes cancel out.

I don’t have this workflow figured out. Neither does anyone else I’ve read on Reddit, honestly — the high-upvote posts are mostly single-tool takes, and the real insight is buried in the comments of threads with a few hundred upvotes.

But “only use one” is already wrong. That much is clear.

Claude is ignoring most of it.

There’s an arms race happening in the Claude Code community right now. Every week, someone posts their increasingly elaborate CLAUDE.md setup. 27-file architectures. Tiered loading systems. Router patterns with conditional context injection.

One developer split their CLAUDE.md into 27 files with a three-tier routing system. 360 upvotes. The post opens with: “My CLAUDE.md was ~800 lines. It worked until it didn’t. Rules for one context bled into another, edits had unpredictable side effects, and the model quietly ignored constraints buried 600 lines deep.”

The top comment, with 81 upvotes? “So not sure if you realised you can have descendant CLAUDE.md so you don’t even need to do this.”

Meanwhile, a developer in the same thread: “I don’t even use claude.md. Y’all are roleplaying being productive. Just work with it 1:1.”

One group is optimizing. The other is actually working.

The Research Says You’re Doing It Wrong

ETH Zurich researchers published a paper that should have made every CLAUDE.md maximalist uncomfortable. Their finding: context files — the .md files we all obsess over — tend to reduce task success rates compared to providing no repository context at all. And they increase inference cost by over 20%.

Read that again. No CLAUDE.md outperformed having one. On average.

When this paper hit Reddit, the poster titled it “No CLAUDE.md → baseline. Bad CLAUDE.md → worse. Good CLAUDE.md → better.” — an optimistic spin suggesting the file isn’t the problem, your writing is. The post got 209 upvotes. But the top comments immediately called it out: OP had misread the data. The actual finding was that having any .md file — human or LLM-written — led to worse performance than having none. The auto-generated thread summary confirmed it: “The consensus in this thread is that you’ve completely misread the paper.”

It gets worse. LLM-generated .md files hurt the most, because they just parrot back what’s already in the code. Human-written files showed a slight positive impact — but only when kept to an absolute minimum, and only for smaller models.

A separate benchmark of 1,188 runs across Haiku, Sonnet, and Opus confirmed this. Twelve coding tasks. Ten instruction profiles. The result: an empty CLAUDE.md scored best overall.

The researcher’s own correction was admirably blunt: “I was wrong about CLAUDE.md compression. Here’s what the data actually showed.”

You Have an Instruction Budget. You’re Blowing It.

Here’s the mechanism nobody talks about.

Frontier models reliably follow about 150 to 200 instructions before performance starts decaying. Not crashing — decaying. Every additional instruction slightly degrades compliance with every other instruction. The degradation is uniform. Your critical “NEVER delete the production database” rule gets weaker every time you add “prefer camelCase for variable names.”

Claude Code’s own system prompt already burns about 50 of those instruction slots. That’s before your CLAUDE.md even loads.

So you have roughly 100-150 instruction slots left. Your 800-line CLAUDE.md with coding conventions, style guides, architecture decisions, tool preferences, workflow rules, and team norms is trying to cram 400 instructions into 150 slots.

The model doesn’t crash. It just quietly starts ignoring things. Specifically, the things buried deepest in the file. Your most important rules — the ones you added after painful debugging sessions — are probably at the bottom. Which means they’re the first to get deprioritized.

Claude Is Designed to Ignore You

This is the part that should make you pause.

Claude Code’s system prompt includes this line about CLAUDE.md content:

“This context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant.”

Claude is literally instructed to deprioritize your instructions if they don’t seem relevant to the current task. The more task-specific content you stuff into CLAUDE.md, the more likely Claude treats the entire file as noise.

That database schema guidance? Irrelevant when Claude is working on frontend CSS. Those API naming conventions? Noise when it’s writing tests. Your elaborate deployment workflow? Invisible during a refactoring session.

Every irrelevant instruction trains Claude to ignore the relevant ones too.

The Context Window Tax

Here’s the math nobody does. Claude Code’s system prompt alone consumes roughly 23,000 tokens — about 11% of the 200K context window, gone before you type a word. Add your CLAUDE.md, your MCP tool schemas, skill descriptions, memory files, and rules. One developer measured 69,200 tokens of overhead — 35% of the context window consumed before a single user message. Others in the thread pushed back on that specific number, but the principle stands: every always-loaded instruction competes with working memory.

And it’s not just a cost problem. It’s an accuracy problem. The fuller the context window gets, the worse Claude performs — what Anthropic calls context rot. Your elaborate CLAUDE.md isn’t just burning tokens. It’s actively degrading the quality of every response.

The Leverage Problem

Here’s why this matters more than you think.

Bad code is localized. You write a buggy function, it breaks one feature. You fix it, you move on.

Bad CLAUDE.md instructions compound. A single misguided rule in your CLAUDE.md affects every research phase, every plan, every implementation, every session. One line that says “always use verbose error messages with full stack traces” produces thousands of lines of noisy code across your entire codebase, across every agent, across every session.

Your CLAUDE.md is the highest-leverage file in your repo. Most people treat it like a junk drawer.

What the Minimalists Actually Do

I went looking for people who run Claude Code with minimal or no CLAUDE.md. They’re out there. They’re quiet about it because “I don’t use CLAUDE.md” doesn’t get upvotes.

One developer on Reddit: “I use Claude Code bare bones professionally. It all sounds like bloat not giving real value.” Another: “I load no skills, no agents, no MCP Servers and rock it all day every day, 12 hours a day. Life is good.”

A developer who built a 13-agent orchestration system with 8,157 lines of markdown deleted 93% of it. His conclusion: “My enhancement layer was making Claude dumber by filling its brain with instructions about how to think, leaving less room for actual thinking.” After the deletion, Claude performed better on the same tasks.

Another developer with a 350-line CLAUDE.md and 20+ custom MCP tools put it simply: “It feels like the more context I add the more it struggles to get the job done. It seems to get ‘dumber’.”

And when someone asked the community to break down the meta on all the conflicting CLAUDE.md advice, the most honest reply got it right: “If ‘best practices’ are conflicting, it’s probably a sign of them mostly being a type of placebo on the part of the folks posting them. The human mind has a weird need to be the special one who cracked the code.”

The pattern is consistent: people who remove instructions report better results than people who add them.

Instructions Raise the Floor, Not the Ceiling

The benchmark data revealed something nuanced. Instructions don’t make Claude better on average. They make it more consistent.

On tasks where Claude already performs well, instructions add nothing. On tasks where Claude struggles, a focused workflow checklist gave Opus a +5.8 point lift and raised its worst-case score by 20+ points.

A 2,455-evaluation benchmark across Sonnet and Opus confirmed a related finding: the best-performing configuration was a short CLAUDE.md with pointers to skills that load on demand — not a massive monolith, not 27 modular files, but a minimal routing layer that tells Claude where to find context when it’s actually needed.

This changes everything about how you should think about CLAUDE.md.

Don’t use it to make Claude smarter. Use it to prevent Claude from being stupid in specific, known ways. The difference between those two goals is the difference between a 60-line file and an 800-line file.

What Actually Belongs in CLAUDE.md

After digging through research, benchmarks, and hundreds of Reddit threads, here’s what survives the cut:

The What-Why-How skeleton (under 60 lines):

• WHAT: Your stack, project structure, key directories

• WHY: What this project does and for whom

• HOW: Build commands, test commands, deploy commands

Negatives over positives:
“NEVER use X” sticks. “Always prefer Y” fades. If you can phrase it as a prohibition, it enforces better. “DO NOT modify the database schema without migration files” beats “Always create migrations when changing the schema.”

Trigger-action format:
“WHEN CI fails, DO NOT push until fixed” enforces consistently. “Always test before pushing” doesn’t. Specificity matters.

Pointers, not content:
Reference external docs instead of embedding them. “See agent_docs/database.md for schema guidance” loads on demand. Pasting the full schema into CLAUDE.md loads every single session, whether Claude needs it or not.

Subdirectory CLAUDE.md files:
Claude auto-loads CLAUDE.md from whatever directory it’s reading files in. Put backend rules in backend/CLAUDE.md. Put frontend rules in frontend/CLAUDE.md. Context-specific rules load only when contextually relevant.

What Doesn’t Belong

Style guides. Claude is an in-context learner. If your code follows consistent patterns, Claude will match them without being told. Use linters and formatters — they’re deterministic, fast, and don’t eat instruction budget.

LLM-generated instructions. The research is clear: auto-generated .md files hurt performance. Don’t use /init. Don’t ask Claude to write its own CLAUDE.md. The model just repeats what’s already in the code, wasting tokens to tell itself what it already knows.

Lessons learned logs. Once the lesson is codified in the codebase itself — as a test, a lint rule, a hook — the .md entry is redundant. Delete it.

Persona assignments. “You are a meticulous senior engineer who always…” is a costume, not a capability. As one developer running overnight cron agents put it: “A syntax check that returns exit code 1 on failure > 2,000 words of ‘you are a meticulous senior engineer who always…’” The agents with minimal instructions consistently outperformed the ones with elaborate persona prompts.

The Real Best Practice

Keep your CLAUDE.md under 100 lines. Ideally under 60. Put the most important rules at the top. Phrase them as negatives. Use trigger-action format. Point to external docs instead of embedding content.

Then stop optimizing and go build something.

The developers shipping the most code aren’t the ones with the fanciest CLAUDE.md architectures. They’re the ones who figured out the minimum viable instructions and moved on to the actual work.

Your CLAUDE.md is not your product. Stop treating it like one.

Three weeks ago, I wrote that Anthropic is losing money on every subscriber and that smart developers should ship like crazy before the economics normalize.

I was right about the thesis. I was wrong about the timeline.

The window isn’t closing in 18-24 months. It’s closing now.

What Changed in Three Weeks

Three things happened in rapid succession that accelerated the timeline:

1. Claude subscriptions doubled. Anthropic’s paid user base went from ~30k to ~60k subscribers between January and March 2026. Record growth. The Claude Code launch, Super Bowl buzz, and Cowork tools drove a wave of new signups.

2. Rate limits got brutal. Users on r/ClaudeAI went from “this is amazing” to “I can’t work” practically overnight. Pro users ($20/month) report hitting 10% of their daily quota from a single prompt. Max users ($100-200/month) report the same degradation. One Max 20x subscriber — paying $200/month — couldn’t work for nine consecutive days.

3. The source code leaked. On March 31, 2026, a 59.8 MB source map file was accidentally shipped in the Claude Code npm package. 512,000 lines of TypeScript, mirrored across GitHub within hours. And buried in that code was proof of something users had been complaining about for weeks.

The Token Drain Bug

Here’s what the leak revealed.

Claude Code has a function called db8 that filters what gets saved to session files. For non-Anthropic users, it strips out all attachment-type messages — including deferred_tools_delta records that track which tools the model already knows about.

When you resume a session, Claude Code scans your history to figure out what tools it already announced. But because db8 nuked those records, it finds nothing. So it re-announces every deferred tool from scratch. Every. Single. Resume.

This breaks prompt caching in three ways:

• System reminders shift positions in the message array

• The billing hash changes because the first message content differs

• The cache breakpoint moves because the array length is different

Result: your entire conversation rebuilds as cache_creation tokens instead of hitting cache_read. The longer the conversation, the worse the drain.

One user patched the two-line fix and posted it. His 5-hour usage dropped from spiralling out of control to 6% — normal levels. The post got 367 upvotes. A sharp commenter noted the patch also bypasses billing controls on cache TTL, which makes it not just a bug fix, but let’s set that aside.

Here’s the uncomfortable part: this bug was burning tokens silently for weeks. Users were complaining about rate limits. Anthropic’s status page showed “no incidents.” And the actual cause was a caching bug in their own client code.

The Math Doesn’t Work

Let’s do the numbers.

Anthropic’s annualized revenue is roughly $14 billion. Claude Code alone accounts for $2.5 billion of that run rate — up from $500 million just three months earlier. Consumer subscriptions generated about $1.2 billion in 2025, with 1,000%+ year-over-year growth.

Sounds great, right? Until you look at the other side of the ledger.

Anthropic burned approximately $5.2 billion in 2025. They’ve committed over $80 billion in cloud infrastructure costs through 2029. They just raised $30 billion in a Series G at a $380 billion valuation — the second-largest private tech financing ever, behind only OpenAI.

They’re buying compute at a staggering scale: 1 million Google TPUv7 chips (~$52 billion deal), a dedicated 1,200-acre AWS data center campus in Indiana ($11 billion), and a $50 billion deal with Fluidstack for facilities in Texas and New York. Total committed compute: over 2 gigawatts.

All of this is funded by venture capital and strategic investors (Amazon’s $8B+, Google’s $3B+). Not by your $20/month Pro subscription.

Anthropic projects positive free cash flow by 2027-2028. That’s the plan. But plans require the revenue to actually materialize, the compute to come online in time, and the unit economics to hold as usage scales.

Right now, 60,000 subscribers are overwhelming the existing infrastructure so badly that paying customers can’t work.

The Subsidy Is Collapsing Under Its Own Success

Here’s the dynamic I didn’t fully appreciate three weeks ago.

The subsidy doesn’t end with a price increase. It ends with degradation.

Anthropic can’t raise prices on Pro from 20to20to50 tomorrow — that would cause a revolt and hand users to OpenAI and Google. But they can let the service get worse at the current price. Tighter rate limits. More frequent throttling. Peak-hour queuing. Features that work “sometimes.”

This is exactly what’s happening.

The math is simple. Double the subscribers on the same compute = everyone gets half the capacity. As one Reddit user put it: “selling more seats on the same plane and wondering why legroom is shrinking.”

And Anthropic isn’t alone. Google slashed Gemini API free tier quotas by 50-92% overnight in December 2025. One developer went from 300M+ input tokens per week to hitting limits at less than 9M. OpenAI’s ChatGPT Pro at $200/month is the only major offering that effectively removes caps — but at ten times the price of a Pro subscription.

The pattern across the industry: subsidized tiers are getting squeezed. The compute costs are real. And the bill always comes due.

Why I’m Not Hitting Limits (And You Might Not Be Either)

Here’s a mystery. Despite all this chaos, I’ve barely noticed the rate limits. After reading the threads and the leaked source code, I think I know why.

I almost never resume sessions. The biggest token drain fires on session resume. My workflow — fresh sessions, agent registration per session, structured CLAUDE.md — accidentally dodges this bug entirely.

Surgical prompts. I don’t say “explore my codebase.” I say “read this file and fix this function.” My beads-based task tracking means every session has a specific objective. No wandering. No 94k-token “Explore” runs.

Time zone arbitrage. IST puts my working hours outside US peak times. When r/ClaudeAI is screaming about rate limits at 2 PM Eastern, it’s midnight for me. I’m coding at 6 AM IST when San Francisco is asleep.

Structured context. Between CLAUDE.md, ARCHITECTURE.md, and explicit file paths, Claude doesn’t need to discover my codebase. It already knows the layout. That’s 90% less indexing work.

This isn’t luck. It’s workflow design. But it reinforces the point from my original post: the subsidy rewards those who use it efficiently. Wasteful usage — open-ended exploration, resumed conversations, vague prompts — burns tokens at 10-50x the rate of focused work.

What This Means For You

If you read my original post and thought you had 18-24 months — you might, on paper. Anthropic has the cash. They have the compute commitments. They project 70billioninrevenueby2028and70billioninrevenueby2028and17 billion in free cash flow.

But the experience of using the product is degrading right now. Not in 18 months. Now.

Here’s what actually matters:

1. Ship before the experience degrades further. The window isn’t about pricing — it’s about capability per dollar. Today, $20/month gets you frontier model access that would have cost $500/month in API calls two years ago. That ratio is moving in the wrong direction as more users pile in.

2. Optimize your workflow. Start fresh sessions. Use CLAUDE.md and ARCHITECTURE.md. Be specific in your prompts. Avoid “Explore” and open-ended commands. These aren’t just productivity tips — they’re rate limit survival strategies.

3. Don’t build on the assumption of unlimited AI access. If your product or workflow requires constant frontier model access at current prices, you’re building on borrowed time. Build systems that work with AI but can degrade gracefully. Ship products that generate revenue independent of your development tools.

4. The enterprise pivot is coming. Anthropic’s enterprise revenue is already 80% of total. They have 300,000+ business customers, with large accounts (>$100K ARR) growing 7x year-over-year. Follow the money: consumer subscriptions are the loss leader. Enterprise is the business. When push comes to shove, enterprise gets the compute.

The Real Lesson

The leaked source code is a metaphor for the entire AI subsidy era.

For weeks, users were burning through rate limits at impossible speeds. They blamed themselves (”skill issue”), they blamed Anthropic (”fix your limits”), they blamed the model (”Claude got dumber”). The actual cause was a two-line bug in a caching function that nobody could see because the code was proprietary.

That’s the subsidy in miniature. You’re using a product where you can’t see the internals, can’t predict the costs, and can’t control when the rules change. The value is extraordinary — right now. But you’re a guest in someone else’s infrastructure, running on someone else’s VC money, subject to someone else’s capacity planning.

The smartest move hasn’t changed since three weeks ago. Ship. Build durable assets — products, content, audiences, skills — while the arbitrage is still available.

But do it faster than you planned. The window isn’t closing in 18 months.

The glass is already cracking.

This founder had designed a custom lamp. Spent months prototyping. Found a factory in Shenzhen. Shipped 500 units.

When the boxes arrived, the light-entry holes had been used as casting pour-points — the factory needed somewhere to pour the material, saw the holes, and went with it. The cable tails were two centimeters instead of ten. The knobs didn’t fit because the powder coating added thickness that nobody put in the spec. Everything technically matched the purchase order. Nothing actually worked.

I read that post-mortem three times. Then I read the top comment, which was one of those sentences that you immediately screenshot because it’s just too true:

“Anything you don’t specify will be done at minimum cost.”

I put my phone down. I looked at the ceiling. And then I thought about the email sender I’d had Claude Code generate that afternoon.

Let me tell you what I had asked for: “Send a welcome email to new users when they sign up.”

Let me tell you what I got: A function that sent emails. Technically correct. It looped over every new user and called the email API synchronously, one by one, waiting for each response before moving to the next. No rate limiting. No retry logic. No unsubscribe link — because I didn’t ask for one, and CAN-SPAM compliance wasn’t in the prompt. When I ran it against a list of 8,000 users, it fired all 8,000 requests in a tight loop, Gmail flagged the sending domain as a spam source within six hours, and my domain was blacklisted before I’d finished my coffee.

Everything sent. Nothing arrived.

I had been vibe coding with Claude Code for six months at that point, and I thought I was pretty good at it. I could get it to build things fast. I could chain prompts together. I had CLAUDE.md files and hooks and all the trappings of someone who knew what they were doing.

What I didn’t understand — what the Hacker News post-mortem forced me to understand — is that I had completely misidentified what kind of relationship I was in.

I thought I was pair programming with a senior engineer.

I was issuing purchase orders to a factory.

This distinction sounds philosophical. It isn’t. It has concrete, expensive implications for every vibe coding prompt you write.

A senior engineer fills gaps with judgment. If you say “build auth,” a good senior engineer asks: what are the scale requirements? What’s the threat model? Are we storing PII? They fill the spec gaps with professional standards because they have skin in the game — it’s their name on the code, their reputation on the line, their on-call rotation if it breaks at 3am.

A factory fills gaps with cost optimization. If the spec doesn’t say “cable tails must be 10cm,” the factory cuts them at 2cm. Not because they’re malicious. Because that’s 8cm of wire per unit times 500 units and someone’s margin depends on it. They’re perfectly rational. They’re just optimizing for something that has nothing to do with whether your lamp works.

Claude optimizes for “satisfies the prompt.” That’s the whole job. Your vague prompt is its permission to take shortcuts, and it will take them — not maliciously, but with the same rational efficiency as a factory floor supervisor who notices you didn’t specify the minimum acceptable wire gauge.

Here’s the thing about the hardware community that I find both humbling and enraging: they figured this out decades ago. They built an entire profession around it. These people are called sourcing agents, and their whole job is translating “I want a nice lamp” into a 47-page document covering material density, wire gauge, coating thickness, packaging dimensions, UV stability ratings, and what happens to the tooling if the order falls below minimum quantity.

Forty-seven pages. For a lamp.

In vibe coding, the sourcing agent is you. Most developers have been accidentally promoted to this role without realizing it. They’re still acting like they’re talking to a colleague. They’re actually running a factory and they’re skipping the quality control, the detailed specs, and the first-article inspection — all the boring stuff that hardware people do automatically because they’ve shipped enough garbage to know better.

I’ve started reading Hacker News manufacturing posts specifically to steal their frameworks for this. A few things that have genuinely changed how I write prompts:

Spec your constraints, not just your features. “Send welcome emails” is a feature request. “Send welcome emails via SES, rate-limited to 14 per second to stay under AWS sending limits, with exponential backoff and a max of 3 retries on failure, an unsubscribe link in the footer per CAN-SPAM, a plain-text fallback alongside the HTML version, and a hard skip for any address that has previously bounced or complained” is a spec. The difference isn’t intelligence — it’s the same way specifying wire gauge isn’t about distrusting your factory. It’s about understanding that factories don’t have opinions about wire gauge. They have margins.

Inspect the first batch before commissioning the full run. Hardware founders don’t ship the first production run to customers. They order samples. They measure every dimension with calipers. The good ones fly to Shenzhen and stand on the factory floor. The developer equivalent is reading the first 200 lines of generated code before asking Claude to build the next feature on top of it. Check the database schema before building the API on top of it. Read the auth flow before adding the permissions layer. This feels slow. It is much faster than discovering that the foundation is wrong after you’ve built four floors.

Specify what you don’t want. This one surprised me. Experienced sourcing agents reportedly spend half their spec document on exclusions. “No recycled plastic in structural components.” “No substituted components without written approval.” “No unlicensed firmware.” They’ve learned that a factory will always find the interpretation of the spec that costs them the least, so you have to close the doors. For prompts: “No inline styles. No TypeScript any types. No console.log for error handling. No SELECT * queries. No external dependencies unless they’re in the approved list.” The AI will not volunteer that it’s about to do these things. It will do them and move on.

Budget time for the spec, not just the build. Hardware founders allocate somewhere between 30-40% of their project timeline to specification work. The manufacturing part — the actual production — is the smaller slice. Vibe coders typically invert this. Five percent on the prompt, ninety-five percent on generating code and then debugging the surprising things that came out of a vague prompt. The debugging is expensive. The spec is cheap.

The thing I keep coming back to is that using Chinese manufacturers is incredible leverage. You can build a physical product without owning a factory, without specialized tooling knowledge, without decades of manufacturing experience. It’s genuinely one of the great unlocks of the modern economy. And it works — when you write the spec correctly.

Using Claude to write code is the same kind of leverage. You can build things without knowing every library, without remembering every API, without holding the entire codebase in your head at once. It works. When you treat it like what it is.

Your prompt is a manufacturing spec. The code is the factory output. The factory will be rational, efficient, and completely indifferent to whether your product actually works.

Write the spec accordingly.

Or enjoy your two-centimeter cable tails.

I was watching a Claude Code session — one of those where you hand the agent a task and then sit back to observe, feeling very enlightened and modern. The task was simple: find where user authentication was implemented and add a new field to the login flow.

The agent started grepping. authenticate. Then auth. Then login. Then loginUser. Then handleLogin. Each grep taking 3-8 seconds, scanning hundreds of files, returning walls of output full of comments, test fixtures, variable names that happened to contain the word “auth”, README lines I’d written two years ago and forgotten.

Six minutes in, the agent had read approximately 40% of my codebase and was confidently editing… a test helper that mocked authentication. Not the actual implementation. A mock. In a test file.

I watched it do this — a system with the reasoning capacity of a senior engineer, burning through context and API calls to do something that VS Code does when I hold Ctrl and click a function name. Something VS Code has done since 2016. Something that takes 50 milliseconds.

This is the state of the art in 2026. The most capable AI coding tool available, navigating your codebase the way your grandfather would navigate a foreign city: slowly, incorrectly, and with a lot of asking for directions from people who don’t know either.

There’s a fix. There are actually two fixes, and you need both. But first I want to explain why the problem is worse than it looks, because if you don’t understand the root cause, you’ll implement half of the solution and wonder why your agents still feel like babysitting.

Let me tell you about grep, and why it’s a disaster for code navigation specifically.

Grep is a text search tool. It finds patterns in text. This is genuinely useful for a lot of things. When you want to find every config file that mentions a database host, grep is perfect. When you want to find a log line, grep is perfect. When you want to navigate code semantically — find where a function is defined, trace what calls a function, understand the type hierarchy — grep is completely wrong for the job. It just happens to be the only hammer available, so everything looks like a nail.

Here’s the specific failure mode. When your agent searches for authenticate, it finds:

auth.service.ts:47:  async authenticate(user: User): Promise<Token> {
auth.service.ts:112: // authenticate is called after 2FA verification
auth.middleware.ts:23: // Middleware that calls authenticate() before protected routes
auth.test.ts:8:   describe('authenticate', () => {
utils/mock-auth.ts:31:   authenticate: jest.fn().mockResolvedValue(mockToken),
config/dev.ts:15:   authenticateWithMock: true,
README.md:234: ## How to authenticate

Seven results. One is the actual definition. The agent has to read all of them, reason about which one is the real thing, and then probably read the files surrounding each one to build context. Meanwhile, it’s consuming tokens, spending time, and building a picture of your codebase that’s assembled from grep outputs rather than from actual structural understanding.

The deeper problem: grep doesn’t understand the difference between a definition, a call site, a comment, a test mock, and a config flag. Those are fundamentally different things in the semantic structure of a codebase. A human engineer with IDE tooling can instantly distinguish them. An agent with only grep cannot — it has to infer the difference from text patterns and context, which it does imperfectly, which means it makes wrong edits, which you have to catch and correct, which is why agent sessions still require babysitting.

This is not a clever problem. We solved it for humans a long time ago.

In 2016, Microsoft did something quietly brilliant. They were building VS Code, and they had a problem: every editor had to implement language intelligence from scratch. Vim plugins, Emacs modes, IntelliJ — everyone was reimplementing the same understanding of what a TypeScript file meant, independently, badly, in incompatible ways.

Their solution was the Language Server Protocol. The idea: separate the “smarts” from the editor. Create a standard protocol where a language server — a standalone process that deeply understands a specific language — can talk to any editor that speaks the protocol. Build the language server once, correctly, and every editor gets the benefit.

A language server is not a text search tool. It parses your code into an Abstract Syntax Tree. It resolves types. It builds a symbol table — a complete map of every identifier in your codebase: what it is, where it’s defined, what it references, what references it. When VS Code shows you that authenticate is defined in auth.service.ts on line 47, it’s not searching for the string “authenticate.” It’s looking up authenticate in the symbol table and getting back a precise answer in under 50 milliseconds.

LSP was so obviously right that it became universal. Every serious editor implemented it. Every major language has a language server: pyright for Python, gopls for Go, typescript-language-server for TypeScript, rust-analyzer for Rust, clangd for C/C++. You almost certainly have at least one of these running on your machine right now.

The irony is that we gave AI agents trillion-parameter language models with remarkable reasoning capabilities, and then handed them grep for code navigation. Like building a Formula 1 car and fitting it with bicycle tires.

Claude Code can connect to these language servers. As of early 2026, this is an undocumented community workaround discovered via a GitHub issue — not an official feature. Which is funny, given how much it changes things. Enable it by adding to ~/.claude/settings.json:

{
  "env": {
    "ENABLE_LSP_TOOL": "1"
  }
}

Or export it in your shell profile if you prefer:

export ENABLE_LSP_TOOL=1

Then install the language server plugin for your stack. Claude Code has a plugin system for this — update the marketplace first, then install:

claude plugin marketplace update claude-plugins-official

# TypeScript/JavaScript
claude plugin install typescript-lsp
npm install -g typescript-language-server typescript

# Python
claude plugin install pyright-lsp
npm install -g pyright

# Go
claude plugin install gopls-lsp
go install golang.org/x/tools/gopls@latest

# Rust
claude plugin install rust-analyzer-lsp
rustup component add rust-analyzer

One gotcha that will silently waste your time: a plugin can be installed but disabled. An installed, disabled plugin does nothing — no LSP server registers at startup, no tools become available, no error. Just grep, same as before. After installing, run claude plugin list and confirm the status reads enabled. If it shows disabled, run claude plugin enable <name>. Check this before you spend 20 minutes wondering why nothing changed.

Once enabled, your agent gets access to tools that most people don’t know exist:

goToDefinition — exact location of any symbol’s definition. Not “files that contain this string.” The definition. In ~50ms.

findReferences — every call site in your entire codebase. Every single one, sorted, precise, with file and line number.

workspaceSymbols — search your codebase by symbol name. Returns only actual code symbols (functions, classes, interfaces, variables) — not comments, not strings, not README lines.

hover — full type information for any identifier. When the agent is about to call a function, it can check the exact signature first rather than guessing.

diagnostics — real-time type errors. When the agent changes a function signature, the language server immediately reports every caller that’s now broken. In the same turn. Before the broken code ever runs.

That last one changes the loop entirely. Without LSP, the workflow is: agent makes a change → change breaks something → you run tests → tests fail → agent fixes it → might break something else → iterate. You’re discovering errors through tests, which means you’re discovering them late, which means multiple turns of cleanup for each mistake.

With LSP, the workflow is: agent makes a change → diagnostics immediately flag every type error caused by that change → agent fixes everything in the same turn. Error discovery goes from “whenever you run tests” to “immediately.” This alone is worth the two minutes it takes to set up.

Here’s the catch, and it’s not obvious until you run into it.

Even with LSP enabled and plugins installed and confirmed active, Claude still prefers grep. Grep is familiar, grep is in its training distribution, grep is what it reaches for first. Having the tools available doesn’t automatically mean Claude will use them.

Add this to your CLAUDE.md:

## Code Navigation

Prefer LSP tools over Grep for any code navigation task:
- Use workspaceSymbol to find symbols by name
- Use goToDefinition to find where something is defined
- Use findReferences to find all call sites
- Use diagnostics after any edit to catch type errors immediately

Use Grep only for text search: log messages, comments, config values,
string literals. Never use Grep to find function definitions.

Explicit instructions in CLAUDE.md override default behavior. This is a documented pattern: the tools exist, but you have to tell the agent to use them. Think of it as configuring the agent’s preferences, not patching the agent’s capabilities.

Now here’s the part where most people stop, and where they shouldn’t.

LSP gives your agent GPS. It knows how to navigate. findReferences from anywhere in the codebase will return exact results. But GPS without a destination is just a compass. Your agent still has to figure out where to go before it can navigate there efficiently.

Think about how an experienced engineer ramps up on a new codebase. They don’t start by grepping for things. They start by asking questions: where does the auth layer live? What’s the database access pattern? How do the services communicate? They build a mental model first, then navigate with precision.

Your agent has no mental model of your codebase unless you give it one. Every session starts cold. It has the code itself (too much to read exhaustively) and the tools to navigate it (useful once oriented) but no map. So it wanders.

The second layer is a structured description of your codebase’s architecture. Not documentation. Not a README. A map for the agent — written in terms of what the agent needs to know to get oriented quickly:

## Codebase Architecture

**Entry point:** src/server.ts bootstraps the app. All route registration happens here.

**Auth layer:** Everything authentication-related lives in /src/auth.
The entry point is `authenticate()` in auth.service.ts.
JWT handling is in auth.middleware.ts. Session storage is Redis via auth.session.ts.
Never bypass the middleware — it handles rate limiting and audit logging.

**Services:** Business logic in /src/services.
PaymentService, UserService, NotificationService are the big three.
Services never call each other directly — all cross-service communication
routes through the event bus in /src/events/index.ts.

**Database:** Prisma ORM. Never write raw SQL — always go through the Prisma client.
Schema lives in /prisma/schema.prisma. Run `npm run db:migrate` after schema changes.

**External integrations:** Stripe in /src/integrations/stripe,
SendGrid in /src/integrations/email. Each integration has a fake for testing.

You put this in CLAUDE.md, or in a dedicated ARCHITECTURE.md that CLAUDE.md imports via @ARCHITECTURE.md.

What changes: your agent starts the session oriented. When you ask it to add a new payment method, it already knows that payment logic lives in /src/services/PaymentService, that external Stripe calls go through /src/integrations/stripe, and that services communicate through the event bus. It doesn’t need to explore your codebase to discover the architecture. It can go directly to the right place and navigate from there with LSP precision.

The GPS analogy only goes so far. A better way to think about it: LSP is your agent’s ability to look something up instantly. Semantic context is the agent knowing what to look up. Both are required. Without the map, LSP is a fast tool pointed in random directions. Without LSP, the map tells you where to go but getting there is still six minutes of grepping.

Together, your agent works the way a senior engineer works on a codebase they know well: they know the territory, they navigate precisely, and they catch their own mistakes before committing them.

The reason I keep coming back to this: the numbers suggest agents are about to do a lot more real work.

Michael Truell announced recently that Cursor now has 2x more agent users than Tab (autocomplete) users. Agent usage is up 15x in a year. More than a third of PRs merged at Cursor are created by agents running autonomously in the cloud — not a human in the loop, not autocomplete suggestions, agents doing complete pieces of work end-to-end.

If that’s the direction — and the trajectory makes it pretty clear it is — then agents navigating codebases with grep is a bottleneck at the wrong layer. You’ve solved the intelligence problem. You have an agent that can reason about complex changes across multiple files. You have not solved the navigation problem, which means the intelligence is being spent on finding things instead of changing them. It’s like hiring a brilliant architect and making them do their own filing.

LSP and semantic context are table stakes for agent-native codebases. The fact that LSP is buried in settings and semantic maps are a community pattern rather than a first-class feature is a product gap. It’ll get closed. But right now you have to close it yourself, and it takes about thirty minutes.

Set up the language server for your stack. Enable LSP in settings.json. Tell Claude to prefer it in CLAUDE.md. Write an architecture section that orients the agent in the first turn. Thirty minutes of setup for sessions that actually feel autonomous.

Your future self will be insufferably smug about having done this early. That’s a reasonable outcome.

Not because $29 was a lot. I’ve subscribed to worse. I have a graveyard of forgotten SaaS products auto-renewing somewhere in my credit card statement, silently draining money for tools I used exactly twice.

No, I stopped because I realized something embarrassing.

This tool was literally just a pretty wrapper around Claude. Same AI I already pay for. Same capabilities. They’d added a nice UI, a payment form, and approximately zero additional value.

I was about to pay $29/month to rent something I could build in an afternoon.

So I closed the tab. Opened Claude Code. And two hours later, I had my own version. No usage limits. No subscription. Mine forever.

That was six months ago. Since then, I’ve built six tools. I’ve eliminated $200/month in subscriptions. And I’ve realized something that changed how I think about this whole “AI is coming for your job” panic.

Everyone’s Worried About the Wrong Thing

My LinkedIn feed is a horror show right now. Every other post is either “AI will take your job” or “Here’s how to survive the AI apocalypse” or some variation of “the robots are coming, repent.”

The advice is always the same. Learn to prompt. Adapt or die. Get your finances in order because disruption is coming.

Maybe it is. I don’t know the future any better than you do.

But here’s what I do know: while everyone’s stockpiling survival advice, I’ve been using those same AI tools to eliminate $200/month in software subscriptions. Tools I was paying for six months ago? I own them now. Forever. Zero recurring cost.

Same technology. Completely different mindset.

Let me show you what I mean.

The Batch PDF Processor I Built Instead of Uploading 50 Files

I had 50 research papers to process. Extract abstracts, pull out key findings, grab any data tables, save everything as searchable markdown.

Sure, Claude can read a PDF. One at a time. Upload, wait, copy the output, upload the next one, repeat 49 more times.

Old me would’ve done exactly that. Or Googled “batch PDF extraction tool,” found something that charges per page, done the math, decided it wasn’t worth it, and then manually uploaded 50 files anyway.

New me? I built a script.

Ninety minutes later, I had a skill that loops through a folder, extracts text and tables from each PDF using PyMuPDF, summarizes each one, and saves structured markdown files. Point it at a folder, go make coffee, come back to 50 organized summaries.

> Process all PDFs in ~/research/papers
[loops through 50 files]
[extracts + summarizes each]
[saves to ~/research/summaries/]

No uploading files one by one. No copy-paste marathon. No usage limits. Runs locally, so nothing leaves my machine.

The tool isn’t “PDF extraction”: Claude already does that. The tool is automation. Batch processing. The boring plumbing that turns a manual 3-hour task into a 5-minute one.

The Video Transcription Pipeline That Changed How I Learn

I’m an infoproduct junkie. Courses, masterclasses, workshops: if someone’s selling knowledge in video form, I’ve probably bought it. My Teachable and Gumroad purchase history is embarrassing. Hours and hours of content sitting in various dashboards, waiting to be watched.

Old me would take notes while watching. Pause, scribble, play, pause, scribble. Retain maybe 30% of it. Forget the rest within a week.

New me? I feed the videos to my video-distill skill. It transcribes everything with Whisper, distills it into readable chapters with Claude, and exports to EPUB.

Two hours of course video becomes a 12,000-word mini-book on my Kindle that I can search, highlight, and reference forever.

Build time: 2 hours.

Previous cost: $50-200 per course for transcription services (or just… not having transcripts and forgetting everything).

The ROI on courses went from “eh, probably worth it” to “this is a no-brainer.”

The Pattern Nobody Wants to Admit

Here’s what I noticed while building these:

Every AI SaaS is a thin wrapper around the same AI you already have access to.

• Batch file processing? A loop + Claude.

• Video transcription? Whisper + Claude.

• Content research? Web fetch + Claude.

• Cross-posting? Template formatting + Claude.

• Writing assistant? Prompt engineering + Claude.

The “product” is convenience packaging. A nice UI, hosting, a payment gateway, customer support. Sometimes that’s worth paying for.

But most of the time? You can build 80% of what you need in under two hours.

I’ve done this six times now. Total build time: about 14 hours. One weekend, spread across a few months.

Total monthly savings: $199.

Total annual savings: $2,388.

Tools I now own forever: 6.

The Real Question Nobody’s Asking

While everyone argues about whether AI will take their job, here’s what I’m thinking:

It’s not AI vs humans. It’s humans with AI vs humans without.

The lawyer who refuses to use AI for contract review loses to the lawyer who uses it and handles 5x more clients.

The developer who doesn’t use AI for code generation loses to the developer who does and ships features in days instead of weeks.

The writer who thinks AI is “cheating” loses to the writer who uses it for research and drafts 10x more content.

The people who lose their jobs to AI won’t be the ones whose work AI can theoretically do.

They’ll be the ones who didn’t use AI and got outpaced by someone who did.

What I Actually Do Instead of Panicking

I audit my subscriptions. Every few months, I go through my recurring charges and ask: “Is this just an AI wrapper?”

If yes, I build a replacement. If the replacement covers 80% of my use cases, I cancel the subscription.

Here’s my current hit list:

• Batch PDF processing: replaced manual uploads with pdf-reader skill (90 min)

• Video transcription: replaced $50-200/course services with video-distill skill (2 hours)

• Ebook formatting: replaced $30/book services with epub-builder skill (1 hour)

• Content research: replaced $29/mo tools with compose skill (3 hours)

• Cross-posting: replaced $50/mo tools with distribute skill (2 hours)

• Writing assistant: replaced $20/mo Sudowrite etc with fiction-writer skill (4 hours)

Not everything is worth building. QuickBooks? Keep paying. Complex Zapier automation with 50 integrations? Probably keep paying. Hosted databases? Definitely keep paying.

But simple AI wrappers that just call Claude with a prompt and charge you monthly for it? Those are dying. You can own that.

This Is What Leverage Actually Looks Like

When you own your tools, you can modify them to fit your exact workflow. Combine them in ways SaaS products can’t. Build competitive advantages nobody else has.

My distribute skill cross-posts to five platforms in one command. Most people manually post to each: different formatting, different copy, different everything. That’s 30 minutes per post. I do it in 2 minutes.

Over a year, that’s 50+ hours saved. For one skill.

My video-distill skill turns courses into searchable mini-books. Most people watch courses once and forget 80% of it. I have permanent reference material I can search and review anytime.

This is how one-person operations beat ten-person teams. Not by working harder. By owning tools that make you 10x faster.

Two Paths

The AI revolution is here. Not coming. Here.

Path A: Read about how AI is going to disrupt your career. Worry about it. Prepare for the worst. Maybe it happens, maybe it doesn’t. Either way, you spent months anxious instead of building.

Path B: Use AI to eliminate expenses, build tools, ship faster, own your stack. If disruption comes, you’re already leveraged. If it doesn’t, you still saved $2,400/year and got 10x faster.

I’m on Path B.

I built six skills in 14 hours. I save $200/month. I own tools that do exactly what I need, with no usage limits, no pricing tiers, and no risk of some startup getting acqui-hired and shutting down my workflow.

And I’m shipping four SaaS products while working two day jobs, because I have the leverage to do it.

You can panic, or you can build.

I’m building.

If You Want to Start

Here’s the playbook I use every time.

Step 1: Pick Your Target

Start with something you use weekly but don’t need enterprise features for. The sweet spot is tools where you’re paying for convenience, not capability.

Good first targets:

• Batch processing workflows (loop through files, process each, save outputs)

• Video/audio transcription (Whisper is free and runs locally)

• Content research and brainstorming (web scraping + Claude)

• Grammar/style checking (Claude prompts replace Grammarly)

• Format conversion pipelines (markdown → EPUB, video → transcript → summary)

Bad first targets:

• Accounting software (compliance, integrations, audit trails)

• Complex multi-step automation with 20+ triggers

• Anything requiring hosted infrastructure you don’t want to manage

• Real-time collaboration tools (Google Docs, Figma)

Step 2: Describe the Workflow, Not the Tool

Don’t say “build me a transcription tool.” Say “I have 20 course videos. I want to transcribe each one, distill the key points, and save them as markdown files organized by chapter.”

The more specific you are about your actual workflow, the better the tool fits. You’re not building a generic SaaS: you’re building exactly what you need.

Step 3: Start Ugly, Iterate Fast

Your first version will be rough. That’s fine.

My video transcription pipeline started as a janky script that choked on long files. I fixed the edge cases as I hit them. Now it handles 3-hour lectures without breaking a sweat.

Don’t try to build the polished SaaS version. Build the “works for my specific use case” version. That takes 90 minutes, not 90 days.

Step 4: The 80% Test

Run your homegrown tool alongside the paid one for 30 days. Track when you reach for the paid tool instead.

If your skill handles 80% of cases, cancel the subscription. The remaining 20%? Either iterate on your skill or accept the occasional manual workaround.

Perfect is the enemy of $X/month forever.

Step 5: Compound It

Once you’ve built one, you’ll notice patterns. The same techniques: file handling, API calls, text processing, output formatting: show up everywhere.

Your second skill takes half the time. Your fifth takes 20 minutes.

This is how you end up owning your entire stack without spending months building it.

The Prompt That Starts Everything

If you’re using Claude Code or similar:

I want to build a tool that [specific workflow].
I currently do this by [current manual process or paid tool].
My input is [what you're working with].
I want the output to be [format and destination].
What's the simplest way to build this?

Then iterate. The AI will ask clarifying questions, suggest approaches, write code. You test, refine, test again.

Two hours later, you own something you would’ve rented forever.

The people who win the next decade won’t be the ones who worried about AI disruption.

They’ll be the ones who used AI to build tools, eliminate costs, and move faster than everyone else.

Don’t rent your stack. Own it.

P.S.: The AI wrapper economy is dying. Every “AI-powered” tool that’s just a UI around Claude or GPT is on borrowed time. The moment users realize they can build 80% of that themselves, the subscription revenue evaporates. If you’re building an AI SaaS, make sure your value is in the 20% that can’t be replicated in two hours.

Last week I caught eight bugs across three projects. Not typos. Not missing semicolons. Real, ship-breaking, production-melting problems that would have sailed right past code review and into the waiting arms of actual users.

Claude Code wrote the code. Claude Code passed the tests. Claude Code would have happily deployed it.

And Claude Code had no idea anything was wrong.

I’ve written about comprehension debt and argued that clean code is dead. But here’s the uncomfortable third act: even if you understand your specs perfectly and verify your outcomes ruthlessly, there’s a whole category of knowledge that AI simply doesn’t have.

Call it production intuition. Call it battle scars. Call it “I’ve been burned by this exact thing before.”

Whatever you call it, you can’t prompt your way into it.

The Localhost Delusion

Here’s what AI is optimized for: making code that works on your machine, right now, with your current data, under ideal conditions.

Here’s what AI is catastrophically bad at: imagining your code running on three replicas behind a load balancer at 3am when the database is under pressure and someone’s running a batch job that nobody documented.

A Fortune 100 developer on Reddit put it bluntly: “There’s a lot of vibe coded slop that works well for MVP but will absolutely fall apart under stress and within production environments once they scale to more users. It doesn’t really reveal itself until later when it’s much more difficult to fix.”

Later. When it’s difficult. The horror.

Let me walk you through what “later” looked like for me this week.

Pattern 1: Production Blindness

The Concurrency Landmine

I’m building a tool that routes MCP calls. Claude wrote it in Python — clean, well-structured, exactly what I asked for. Worked beautifully in testing. One request, one response, everybody’s happy.

Then I imagined what happens when three Claude Code sessions hit it simultaneously.

Oh.

Oh no.

Python’s threading model and the phrase “parallel requests” get along about as well as cats and bathtubs. Claude’s solution? More Python. Refactor this, optimize that. Very confident. Would’ve worked for lower concurrency.

But I knew this thing needed to handle dozens of parallel sessions. I prompted it to rewrite in Go. Claude nailed the port — goroutines, channels, the works. Problem solved in an afternoon.

The code was excellent. The language selection wasn’t. Claude optimizes brilliantly within the box you give it. It just won’t question whether you’re in the right box.

The Replicas Problem

Auth rate limiting. Claude implemented it in-memory with a clean sliding window algorithm. Textbook correct. Tests pass. Ship it.

One replica: perfect.
Two replicas: every user gets double the rate limit.
Three replicas: chaos.

This is distributed systems 101. The kind of thing you learn after you’ve been paged at 2am because someone figured out they could hit your API from three different IPs and get 3x the rate limit.

When I pointed this out, Claude immediately suggested Redis-backed rate limiting with proper distributed locking. Great solution. But it didn’t think about replicas until I did. Claude builds for the deployment model you describe. If you don’t describe it, localhost is the default.

The Sync Task Landmine

An API endpoint runs a long-running task. Claude implemented it synchronously — straightforward, easy to understand, does exactly what the tests verify.

Deploy it. First user clicks the button. 30-second timeout. 504 Gateway Timeout.

When I explained the problem, Claude refactored it to Celery with proper task queuing, retry logic, and status polling. Solid implementation. Took maybe 20 minutes.

But here’s the thing: I only caught it because I tested the actual user flow, not just the unit tests. Claude implemented what I asked for. I didn’t ask for “an endpoint that won’t timeout in production.” That’s on me. But it’s also the kind of thing I’ve learned to check after watching synchronous endpoints die approximately 47 times.

Pattern 2: Ecosystem Amnesia

The Deprecation You Won’t Find on Stack Overflow

Supabase deprecated their API keys. Not in a big announcement. Not in the docs you’d naturally read. In a GitHub discussion with 43 comments and a lot of confused developers.

I found out because I read the discussion. I then had to fix three separate projects.

Claude doesn’t read GitHub discussions. Claude doesn’t know what the community is grumbling about. Claude’s knowledge is frozen in time, and the ecosystem keeps moving.

The “Works But Wrong” Framework Choice

Claude encrypted secrets at rest using Fernet keys. Technically correct. Cryptographically sound. Tests pass. Secure enough.

But I’m using Supabase. Supabase has a vault feature built specifically for this. When I mentioned it, Claude migrated everything over cleanly — proper RLS policies, the works.

The Fernet implementation wasn’t wrong. It just wasn’t the right choice for this stack. Supabase vault means one less thing I manage, one less key rotation I handle, one less piece of infrastructure to think about.

Claude doesn’t know the zeitgeist of “what’s the idiomatic way to do this in Supabase.” That knowledge lives in community forums, Discord servers, and the muscle memory of people who’ve shipped Supabase apps before.

The Build System That Wasn’t

I made UI mockups with Tailwind CSS(using Claude, to be fair). Told Claude to use them. Claude happily served Tailwind from a CDN.

In development? Fine.
In production? Every page load fetches the entire Tailwind library. Uncompiled. Unoptimized. Approximately 300KB of CSS you don’t need.

Claude knows what Tailwind is. Claude doesn’t know that real projects compile it. That’s the kind of tribal knowledge you pick up by shipping things and watching your Lighthouse scores crater.

Pattern 3: Verification Vacuum

The Cache That Wasn’t

Database queries were getting slow. I asked Claude to add a caching layer. Claude wrote a beautiful Redis caching module — proper TTLs, cache invalidation on writes, the works. Tests for the module passed. I shipped it, watched the deployment go green, felt the warm glow of productivity.

The cache wasn’t being hit.

Claude built an excellent caching module. Claude did not check whether the actual query functions were calling the cache. The module worked perfectly. Nothing was using it. Every request still hit the database directly.

I discovered this by checking Redis after a few hundred requests. Empty. Revolutionary debugging technique, I know.

Could tests have caught this? Sure. Integration tests that verify “when I make this API call, Redis gets a cache entry.” But I’d need to know to write that test. Claude wrote unit tests for the caching module. I should have asked for end-to-end verification. The knowledge that “modules can exist without being properly wired up” is experience. Pattern recognition. The scar tissue from shipping features that weren’t actually features before.

Pattern 4: Architectural Judgment

The Multitenancy Time Bomb

A project using Qdrant vector database. Users store embeddings. Multiple users. Shared infrastructure.

The question that should wake you up at night: Can User A see User B’s data?

Claude’s implementation used collection-level isolation with proper tenant IDs in the filter queries. Reasonable approach. Worked in my tests.

But a thorough multitenancy review? The kind where you trace every query path, every edge case, every possible way data could leak between tenants? Where you think about what happens if someone forgets to pass the tenant filter? Where you consider whether the default behavior is secure-by-default or insecure-by-default?

That review took me two hours. Claude can help execute the fixes I identify, but it won’t spontaneously think “hey, multitenancy is a critical architectural decision that deserves paranoid scrutiny.”

Get multitenancy wrong and you’re on the front page of Hacker News, and not in the good way. Claude builds features. You build threat models.

What The Discourse Gets Wrong

Here’s what bothers me about the AI discourse: both sides are missing the point.

The AI skeptics say “AI code is garbage, don’t use it.” That’s wrong. Claude Code is incredibly useful. I ship faster. I handle complexity I couldn’t handle alone. The leverage is real.

The AI evangelists say “AI will replace developers, just describe what you want.” That’s also wrong. Describing what you want is the easy part. Knowing what you should want — that’s where the experience lives.

Someone on r/ExperiencedDevs nailed it: “Coding is the boring/easy part. Typing is just transcribing decisions into a machine. The real work is upstream: understanding what’s needed, resolving ambiguity, negotiating tradeoffs, and designing coherent systems.”

The developers who thrive aren’t the ones who write the most code. They’re the ones who catch the multitenancy bug before it ships. Who know that in-memory rate limiting won’t scale. Who’ve been burned by synchronous endpoints and CDN-served CSS and proxies that aren’t wired up.

Experience isn’t knowing the syntax. Experience is knowing the failure modes.

What’s Actually Worth Learning

So what’s worth learning when AI can write the code?

Production Thinking

This is the big one. Every example above comes back to it: Claude builds for localhost, you build for production.

Concretely, this means developing instincts for questions like:

• “What happens when there are multiple replicas?” (Rate limiting, session state, caching, file storage — anything in-memory becomes a distributed systems problem)

• “What happens under load?” (Synchronous operations become timeouts. N+1 queries become database meltdowns. That “fast enough” endpoint becomes a bottleneck)

• “What happens when dependencies fail?” (Database is slow. External API is down. Redis is unreachable. Do you degrade gracefully or explode?)

• “What happens at 3am when nobody’s watching?” (Background jobs. Retry logic. Dead letter queues. The things that fail silently)

How do you learn this? You can’t shortcut it. You deploy things. You watch them break. You read post-mortems. You get paged. You develop a paranoid imagination for failure modes.

But you can accelerate it: before you ship, spend 10 minutes imagining the deployment. Draw the boxes. How many instances? What’s in front of them? Where’s the state? What’s shared? This exercise catches 80% of the issues I described above.

Ecosystem Intuition

This is knowing the zeitgeist of your stack — not just what’s possible, but what’s idiomatic. What the community actually uses. What’s deprecated but still in the docs. What’s new but not proven.

Concretely:

• Read the GitHub discussions, not just the docs. That’s where deprecations get announced, migration paths get debated, and footguns get documented.

• Follow the maintainers on Twitter/X or Bluesky. They’ll tell you about breaking changes before the docs catch up.

• Lurk in Discord servers. The “how should I do X” discussions reveal what’s considered best practice.

• Actually ship with the stack. The difference between “I’ve read about Supabase” and “I’ve shipped three apps with Supabase” is enormous.

The goal: when Claude suggests an approach, you can immediately sense whether it’s the “right” way or just “a” way. Fernet encryption vs Supabase vault. CDN Tailwind vs compiled Tailwind. Redis rate limiting vs in-memory rate limiting. These aren’t in the documentation. They’re in the collective experience.

Architectural Paranoia

Some decisions are easy to change later. Some aren’t. Knowing the difference is half of senior engineering.

The ones that are hard to reverse:

• Multitenancy model: Shared database with tenant IDs? Separate schemas? Separate databases? Choose wrong and you’re rewriting everything.

• Auth architecture: Where do tokens live? How do sessions work? What’s the refresh flow? Changing this later breaks every client.

• Data model fundamentals: Relational vs document. Normalized vs denormalized. Adding a column is easy. Restructuring your entire data model is not.

• API contract design: Once clients depend on your response shape, changing it is a versioning nightmare.

For each of these, Claude will happily implement whatever you ask. It won’t stop and say “are you sure about this? This is hard to change later.” That paranoia is your job.

My rule: for any architectural decision I can’t easily reverse, I spend at least an hour thinking about alternatives before I let Claude write the first line.

Verification Instincts

What should you test for? What’s easy to get wrong? What looks done but isn’t actually wired up?

This is pattern recognition from past failures. The cache that wasn’t being hit. The feature flag that was never checked. The error handler that swallowed exceptions silently.

Concretely:

• Test the user flow, not just the units. My caching module passed all its unit tests. The integration was broken. If I’d tested “make this API call and verify Redis has an entry,” I’d have caught it immediately.

• Verify your assumptions. Claude wrote the code, but did the code actually get used? Add a log line. Check the network tab. Confirm reality matches intention.

• Break it on purpose. What happens when you pass invalid input? What happens when the database is slow? What happens when the auth token is expired? Claude tests the happy path. You test the sad path.

The underlying skill: developing a checklist of “things that can look done but aren’t” for your specific domain. Every time you get burned, add it to the list. Eventually, you check these instinctively.

The Uncomfortable Conclusion

A freelance developer with 8 years of experience described a pattern he’s seeing across multiple clients: companies paying good money for internal software that barely works. Same symptoms every time. AI-generated comments. Algorithms that make no sense. Inconsistent patterns.

“Yes it mostly works,” he wrote, “but does so terribly to the point where it needs to be fixed.”

The era of AI slop cleanup has begun. And the people doing the cleanup are the ones who know what production actually looks like.

Claude builds for localhost. You build for production.

That gap is where your fifteen years live. And it’s not getting smaller.

This is the third essay in an accidental trilogy. First: comprehension debt is real. Second: clean code is dead. This one: the skills that matter more now, not less.

Time from “huh, interesting Reddit post” to “supabyoi.com is live”: under an hour.

This is either impressive or terrifying, depending on how you feel about the pace of software development in 2026.

The Setup

I’ve been building a Reddit research tool that lives inside Claude Code. It monitors subreddits, scores posts against your interests, and helps you find signals in the noise. The tool uses Reddit’s public JSON endpoints—no API keys required, because Reddit doesn’t issue them anymore.

That’s not hyperbole. Reddit recently announced they’re “ending self-service API access.” You can’t just create an app and get keys anymore. You have to submit a request form, explain your use case, and wait for approval. The approval that, according to r/redditdev, never comes. “Tickets rejected, modmail ignored, admin DM ignored.” One developer summed it up: “I don’t believe anyone is getting API access for small personal use at this point.”

They’re pushing everyone to Devvit, their walled-garden platform. JavaScript only. Runs on their servers. Limited to what they allow.

If you want Reddit data for your own tools, you either pay enterprise rates, beg for approval, or use public endpoints like a normal browser would. I chose option three.

GummySearch learned this the hard way. They built a Reddit research tool, hit $11k/month MRR, served 135,000 users. Then Reddit wouldn’t give them a commercial license. They’re shutting down by December 2026. The founder didn’t want to operate “looking over your shoulder every day.”

Public endpoints don’t have that problem. Same data. No license to revoke.

I had the tool pointed at r/Supabase, watching for pain points. Standard demand validation stuff.

It surfaced a pattern across multiple threads. “I’m a mass-project starter. Supabase ain’t for me?” (41 upvotes, 27 comments). “Is Self-Hosting Supabase Worth It?” (73 upvotes, 60 comments).

The pain: Supabase’s free tier caps you at 2 projects. Pro tier is $25/month plus $10 per additional project. If you’re an indie dev shipping lots of small bets, you burn through that limit fast.

Supabase is genuinely great for rapid prototyping—I use it myself. The pricing just doesn’t fit the small bets workflow.

The comments were gold:

“It feels like a bait-and-switch where the upgrade appears to remove project limits, only to hit you with unexpected per-project fees”

“Setting it up properly takes time, maintaining it takes time, keeping the server secure takes time”

“The setup process is extensive, unclear and often frustrating”

“Very strange pricing model, which is kind of unacceptable”

Translation: Indie devs love Supabase for building fast. They hate the pricing when they ship a lot. They want to self-host but are terrified of maintaining it.

The Evaluation

I have a framework for this. Open source project + operational complexity + permissive license = potential hosting business. I’ve been running variations of this for a while.

I asked Claude—right there in the same session—to run the threads through the framework:

Pain point: Real. Multi-project pricing punishes prolific shippers.
License: Apache 2.0. Clear.
Operational complexity: High. Supabase runs ~12 services.
Existing managed option: Yes, but that’s the pain source—not the solution.

Then the key insight: I’m not competing with Supabase Cloud on hosting. I’m offering care and feeding for self-hosted instances. Different model entirely.

• They bring their own VPS (Hetzner, $10-15/month)

• I handle upgrades, backups, security

• Fixed monthly fee: $25. Unlimited instances.

One customer with 5 projects: $25 from me + $15 VPS = $40 total vs $75 on Supabase Cloud.

The Build

Here’s where it gets fast.

I told Claude:

“Create a landing page. Tailwind, not CDN. Minimal. Dev-focused. Static HTML.”

Claude scaffolded the project structure, wrote the copy, set up the build pipeline. I tweaked the value prop and added my ConvertKit form.

Then:

“Push to GitHub, I’ll deploy to Cloudflare Pages.”

Done.

Total time building the landing page: maybe 20 minutes. Most of that was me fiddling with colors.

The Stack

For the curious:

Landing page: Static HTML, Tailwind CSS, Cloudflare Pages
Waitlist: ConvertKit embed
Domain: Namecheap (purchase) → Cloudflare (DNS)
Total cost so far: $12 for the domain

The actual product will be FastAPI + Supabase (yes, the irony) + HTMX. SSH into customer VMs. Cron jobs for backups. Simple. I can ship a working beta this week.

The Point

This isn’t about Supabyoi specifically. It’s about the workflow.

Old way:

1. Have idea

2. Think about it for weeks

3. Research competitors

4. Write PRD

5. Design mockups

6. Build MVP

7. Realize nobody wants it

8. Total time: 3 months

New way:

1. Tool surfaces interesting signal

2. Ask Claude to validate against framework

3. Ask Claude to build landing page

4. Ship

5. See if anyone signs up

6. Total time: 1 hour

The landing page is a hypothesis test. Not a commitment. If I get 50 waitlist signups, I build the thing. If I get 5, I move on. The cost of being wrong is $12 and an hour of my time.

About That Reddit Tool

I’ve been quietly building this for months. It’s how I found the signal that led to this post.

The key: it lives inside Claude Code. Not a separate app. Not a browser tab. Right there in my terminal, in the same session where I’m writing code and shipping products.

The architecture: Crawler runs locally or on your VPS (Reddit can’t shut you down if they can’t block your IP). Data syncs to a backend. You query it with natural language through Claude. “What are people complaining about in r/Supabase?” → ranked list of pain points with source threads. Then in the same breath: “Evaluate this against my validation framework.” Then: “Build me a landing page.”

One session. Research to shipping.

No Reddit API keys because Reddit killed self-service access. Uses public endpoints. Same data you’d see browsing the site. Your IP, your rate limits, no approval form that never gets answered.

I’m not ready to launch it yet, but if you want early access, DM me on LinkedIn or Twitter/X.

The Takeaway

The leverage is real. One person, one AI assistant, one hour, one live product.

The bottleneck isn’t building anymore. It’s finding the right thing to build. That’s why the Reddit tool matters more than the Supabase thing. The tool finds signals. Claude validates them. Claude builds the test. You watch the data.

Small bets at scale.

supabyoi.com is live. Let’s see what happens.

<fingers-crossed/>

Then I saw the logs.

2026-01-02T06:34:27 GET xmrig-6.24.0-linux-static-x64.tar.gz
2026-01-02T06:34:30 GET http://37.32.6.33:7979/m
2026-01-02T06:34:30 spawn /opt/systemf/m ENOENT

xmrig. In production. Someone was mining Monero on my client’s Kubernetes cluster.

The horror.

The Investigation

I had a few hundred megabytes of JSON logs and approximately zero patience for manually correlating timestamps. So I did what any reasonable person would do: I asked Claude Code to analyze the logs and figure out what triggered the miner download.

Within seconds, it built a timeline:

Time Event

06:34:26. Normal request to /onboarding

06:34:27. xmrig downloaded from GitHub

06:34:30. Secondary payload from sketchy IP

06:34:57. Container OOMKilled

The cryptominer was so resource-hungry it consumed 2GB of memory in 30 seconds and crashed the container. Ironic. The attacker’s greed saved us from a prolonged compromise.

But how did they get in?

Chasing Red Herrings

Claude Code’s first suspect: a low-version npm package called device-unique-keygen. Added by a developer whose email matched the package maintainer. Classic supply chain attack pattern.

I got excited. Maybe too excited.

Claude Code fetched the GitHub repo, analyzed the source code, checked for postinstall scripts, looked for obfuscated code, searched for eval() calls.

Nothing. The package was clean. Just a browser fingerprinting library. Boring. Legitimate.

We moved on.

No malicious init containers. No sidecars. No .ashrc shenanigans. The Dockerfile was clean. The pod spec was clean.

Everything was clean except someone was definitely mining crypto on our infrastructure.

The Actual Answer

Claude Code ran npm audit on the codebase.

critical │ Next.js is vulnerable to RCE in React flight protocol
Package  │ next
Patched  │ >=15.3.6
Your ver │ 15.3.4
CVSS     │ 10.0

CVSS 10. The maximum possible score. The “your house is actively on fire” of security ratings.

The app was running Next.js 15.3.4. A publicly disclosed RCE vulnerability. No authentication required. An attacker could run arbitrary commands on the server by sending a crafted request.

That’s exactly what happened. They sent a request, ran wget twice, downloaded the miner, and started extracting crypto value from compute cycles they weren’t paying for.

The container’s memory limit stopped them. A $20/month Kubernetes resource limit prevented what could have been ongoing theft.

What Claude Code Actually Did

I want to be clear about what happened here. I didn’t single-handedly unravel a sophisticated attack. I didn’t manually correlate log timestamps or reverse-engineer obfuscated npm packages.

I said “check these logs” and Claude Code:

• Built a timeline from JSON log entries

• Identified the malware artifacts and C2 server

• Traced git blame to find who added suspicious packages

• Fetched and analyzed source code from GitHub

• Ruled out attack vectors one by one

• Found the actual vulnerability via npm audit

• Correlated the OOMKill timing with the attack

• Suggested remediation and forensic preservation steps

The entire investigation took under an hour. Not because I’m fast. Because Claude Code is.

The Fix

pnpm update next@^15.3.6

One command. That’s the remediation for a CVSS 10.0 vulnerability.

We also orphaned the compromised pods for forensic analysis, rotated secrets, and added proper security contexts to prevent future wget adventures.

The Lesson

Two things saved us:

1. Centralized logging (couldn’t investigate without the logs)

2. Memory limits (the attacker’s miner killed itself)

One thing would have prevented this entirely: running npm audit before deployment.

The attacker exploited a vulnerability that was publicly disclosed and patched. We just hadn’t updated yet.

Godspeed with your own dependency updates.

My Medium friends can read this over there as well.

Claude just edited a file. You’re about to type “now run prettier.” For the fourteenth time today. Like some kind of digital hall monitor.

Meanwhile, there’s a feature sitting right there in Claude Code that would do this automatically. It’s called hooks. And based on my extremely scientific survey of Reddit threads, approximately nobody is using them.

What Hooks Actually Are

When Claude Code runs, it fires events. Before it uses a tool. After it uses a tool. When it stops. When it sends a notification.

Hooks let you intercept these events and run shell commands automatically.

That’s it. That’s the whole concept.

Claude edits a file? Run your formatter. Claude finishes a task? Send yourself a Slack message. Claude tries to commit? Run your linter first.

No more babysitting. No more “please remember to run prettier.” You set it once and forget it exists.

The Three Hooks That Actually Matter

I spent way too long reading Reddit threads about hooks. Here’s what power users actually care about:

1. The Formatter Hook

This is the most common one. Claude edits your code, your formatter runs automatically.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "prettier --write $CLAUDE_FILE_PATH"
          }
        ]
      }
    ]
  }
}

No more “can you run prettier on that?” Revolutionary concept, I know.

2. The Notification Hook

You kicked off a task. You walked away to make coffee. Now you’re checking your terminal every 30 seconds like a nervous parent.

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "curl -d 'Claude is done' ntfy.sh/your-topic"
          }
        ]
      }
    ]
  }
}

Send it to Slack. Send it to Discord. One person made their Mac speak out loud. Another person made Claude meow. (Allergies. I don’t judge.)

3. The “Please Remember Your Instructions” Hook

This one solves a specific pain that will sound familiar: Claude compacts its context to save tokens. In doing so, it sometimes… forgets things. Important things. Things you put in your CLAUDE.md.

The fix? Re-inject your core rules on every prompt:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "UserPromptSubmit",
        "hooks": [
          {
            "type": "command",
            "command": "cat .claude/rules.txt"
          }
        ]
      }
    ]
  }
}

Your rules show up in the context window. Every time. Claude can’t “forget” what’s staring it in the face.

Where This Goes

Put your hooks in .claude/settings.json in your project, or ~/.claude/settings.json globally.

Project-level hooks are better. Different projects have different formatters, different rules, different needs. Keep it scoped.

The One Gotcha

Someone on Reddit pointed out a real issue: if your formatter changes files, Claude gets a system reminder about those changes. Every. Single. Time.

If you’re formatting aggressively, that’s a lot of noise in your context window. Tokens that could be doing useful work are now just telling Claude that yes, you added a semicolon.

The fix is to be selective. Format on commit, not on every edit. Or accept the tradeoff. Your call.

Why You Should Care

Hooks turn Claude Code from “AI assistant you have to supervise” into “AI assistant that follows your rules automatically.”

The power users on Reddit are calling this a game-changer. The rest of the users are still typing “please run the linter” by hand.

Don’t be the second group.

Set up three hooks. Formatter, notifications, rule enforcement. Takes ten minutes. Saves hours of typing the same commands.

Your future self will thank you.

What’s the most repetitive thing you’re still typing manually in Claude Code?

We’ve covered how to trigger Claude (slash commands), teach it (skills), and let it explore (agents). Now: how to give it access to the real world.

Because right now, Claude is trapped in a box. It can read your code. It can write your code. But it can’t see what’s on a webpage. It can’t query your database. It can’t check your production logs. It’s a very intelligent entity with no access to external reality.

Ask Claude what your database schema looks like without an MCP server, and you get this:

“Based on typical Postgres schemas, your users table probably has an id, email, and created_at column…”

Probably. Or we could just query the actual database. Revolutionary concept, I know.

MCP servers are the escape hatch. They give Claude eyes, ears, and hands outside your codebase.

What MCP servers actually are

MCP (Model Context Protocol) servers expose tools to Claude over a standardized protocol. Each server runs as a separate process and registers its capabilities — functions Claude can call when it needs to interact with something external.

Examples:

• Playwright: browse the web, scrape pages, automate testing

• Supabase/Postgres: query databases directly

• Betterstack: pull production logs

• Filesystem: access files outside your project

The “server” terminology is slightly misleading — they’re really tool providers that Claude can invoke. You configure them in .mcp.json, Claude discovers their capabilities, and suddenly it can do things it couldn’t do before.

The critical distinction: capabilities vs instructions

This is where people get confused between MCP servers and skills. Let me make it painfully clear:

MCP servers = capabilities. They let Claude DO something it couldn’t do before. Playwright gives Claude the ability to browse. A Postgres MCP gives Claude the ability to query databases.

Skills = instructions. They tell Claude HOW to do something. A “web-scraping” skill might teach Claude efficient patterns for using Playwright.

You often want both. The MCP server provides the capability. The skill provides the expertise.

Example: I have the Supabase MCP installed (capability). I also have a skill that says “when querying user data, always filter by organization_id first for performance” (instruction). The skill makes the capability more useful, but without the capability, the skill is just a nice idea with no way to execute.

Skills can tell Claude what to do. They can’t give Claude new abilities. Good luck querying your production database using only skills.

The token cost nobody mentions in the marketing materials

Here’s the thing that caught me off guard: MCP server tool definitions are always in your context window.

Every MCP server you install adds its tool signatures to every conversation. Even when you’re not using it. Even when you’re doing something completely unrelated. The tool definitions are just sitting there, eating tokens.

Install 10 MCP servers because they seemed cool? All 10 are eating tokens in every session. Like subscription services you forgot you signed up for, except it’s your API bill.

This matters for:

• Context window limits (you have less room for actual work)

• Cost (more tokens = more money, math is cruel)

• Performance (sometimes, more context = slower responses)

Be intentional. Don’t install MCP servers “just in case.” Install what you actually use. Uninstall what you don’t. Your token budget will thank you.

The patterns that waste everyone’s time

Watch any Claude Code session where someone doesn’t have the right MCP servers installed:

• Asking Claude to guess what a webpage looks like (when Playwright could just open it)

• Copy-pasting API responses into the chat (human middleware)

• Describing database schemas in words (when Claude could just query them)

MCP servers aren’t optional extras. They’re not power-user features for people who want to show off. They’re how Claude becomes actually useful for real-world tasks instead of just being a very eloquent guesser.

If you’re regularly copy-pasting external data into Claude, you need an MCP server. Stop being the bottleneck.

My current MCP stack (minimal, intentional)

For my SaaS projects, I typically configure:

• Playwright: browser automation, web scraping, testing flows

• Supabase (read-only): querying my production database without leaving Claude

• Betterstack: pulling logs when debugging production issues

Key point: these are project-specific, configured in .mcp.json in the repo. Not global. When I’m working on this blog, I don’t need Supabase or Betterstack — so they’re not loaded, and I’m not paying the token cost.

This is the lever most people miss. You can have different MCP stacks for different projects. A SaaS project needs database and logs. A content project might just need Playwright for research. Configure per-project, pay only for what that project actually needs.

I’ve tried others and removed them. The token cost wasn’t worth it for occasional use. That fancy Notion MCP? Gone. The GitHub MCP for repo scaffolding? Turns out gh CLI works fine and doesn’t eat context.

Minimal viable MCP stack. Everything you need, nothing you don’t.

When to add an MCP server (and when not to)

Add an MCP server when:

• You’re regularly copy-pasting external data into Claude

• You’re asking Claude to guess at things it could just look up

• The task requires interacting with systems outside your codebase

• The capability would be used frequently enough to justify the token cost

Don’t add an MCP server when:

• You might use it “someday” (you won’t, and it’ll eat tokens until you remember to remove it)

• You’re just curious what it does (read the docs instead)

• Another tool already covers the capability

• A CLI tool would be faster and cheaper (often true)

The full picture: MCP servers + skills + agents

Here’s how they compose in practice. Say I’m debugging why users are seeing 500 errors:

1. Betterstack MCP pulls the error logs from the last hour

2. Supabase MCP queries the affected user records

3. Agent correlates the data — finds that all failing requests share a malformed organization_id

4. Skill reminds Claude to check the migration history when schema issues appear

5. Slash command triggered this whole investigation with /debug-500s

Each layer does its job. The MCP servers are the foundation — without the capability to actually access logs and data, everything else is just documentation for things you can’t do.

The pattern: MCP servers give Claude access to production reality. Skills teach Claude how to navigate that reality efficiently. Agents do the investigation autonomously. You get answers instead of guesses.

(There’s a deeper rabbit hole here about balancing MCP capabilities against context window costs — which MCPs to load when, how to structure project-specific configs, when to use CLI tools instead. That’s a future post.)

This completes the 4-part series:

1. The Mental Model (slash commands, skills, agents, MCP servers, plugins)

2. Skills vs Slash Commands (one works, one “works”)

3. Agents (stop scripting exploration)

4. MCP servers (stop making Claude guess)

I help technical founders develop, deploy, and market their SaaS using Claude Code. If this series saved you some confusion, that’s what I’m here for.

I’m curious:

• What’s your MCP stack? Which servers do you actually use daily vs installed “just in case”?

• Have you noticed the token cost creep from too many MCPs?

• Any MCP servers you’d recommend that I haven’t mentioned?

Reply or comment — I read everything.

My first instinct with Claude Code was to script everything. Every task got a slash command. Every command tried to handle every edge case. Fifty lines of instructions. Nested conditionals. Error handling for scenarios that would never happen. It was beautiful. It was comprehensive. It was also completely fragile and broke constantly.

I was basically writing enterprise Java in prompt form. Nobody should have to live like that.

Then I discovered agents. Now my slash commands are thin — they set up context and spawn an agent to do the actual work. The agent figures out the details. My blood pressure dropped significantly.

(Quick terminology note: Claude Code calls these “subagents” because they run as subprocesses of your main session. Everyone just says “agents.” I’ll use “agent” throughout because life is short.)

The mistake: treating Claude like a very slow bash script

I had a /research-topic command that tried to:

• Search the codebase for relevant files

• Read documentation

• Check external sources

• Synthesize findings

• Format the output in exactly the right way

• Handle seventeen different edge cases I imagined at 2 AM

It was a mess. Too many conditionals. Too many assumptions about what files exist and where. It broke every time the codebase changed, which was constantly, because that’s what codebases do.

The fundamental problem: I was trying to script exploration. But exploration is inherently unpredictable. You don’t know what you’ll find until you look. That’s literally the definition of exploration. Trying to pre-script it is like writing detailed driving directions before knowing where you’re going.

“Turn left at the third building. Unless there isn’t a third building. Then turn right. Unless you’re already facing north. Check the position of the sun…”

This is madness. Don’t do this to yourself.

What agents actually do (and why it’s better)

Agents have their own context. They’re decoupled from your main conversation. They go off, do their thing, and come back with answers.

You describe the goal. The agent figures out the path.

“How does authentication work in this codebase?” I have no idea which files to look at. I could spend ten minutes finding them myself. Or I could let Claude spawn an Explore agent — one that’s already built into Claude Code — and get an answer in two minutes.

Here’s what that actually looks like:

Me: "How does authentication work in this codebase?"

Claude spawns Explore agent → searches → reads 8 files → returns:

"Authentication uses JWT tokens stored in httpOnly cookies.
The flow: login request → /api/auth/login → validates credentials
→ creates token → sets cookie. Token validation happens in
middleware at src/middleware/auth.ts:42. Refresh logic is in
src/lib/auth/refresh.ts."

The agent checked 8 files. Maybe it checked 15. I don’t know, and I don’t care. I care about the answer.

This is fundamentally different from scripting. You’re not specifying steps. You’re specifying outcomes. It’s like hiring a contractor versus writing assembly instructions. One of these is dramatically less exhausting.

What’s inside an agent (dissecting Explore)

Claude Code ships with a built-in Explore agent. Let’s look under the hood:

AspectWhat Explore UsesModelHaiku (fast, cheap)ToolsGlob, Grep, Read, limited Bash (ls, git log, etc.)Can modify files?No — strictly read-onlyContextIsolated from your main conversation

The Explore agent has three thoroughness levels:

• Quick — targeted lookup, minimal file traversal. Use when you know roughly what you’re looking for.

• Medium — searches multiple related locations. The default for most queries.

• Very thorough — comprehensive search across unusual places and naming conventions. Slower, but finds things hidden in unexpected corners.

Here’s the part nobody emphasizes enough: the agent runs in its own context window. It can read 20 files, search through thousands of lines, and when it’s done, you get a summary. Your main conversation stays clean. Your token budget stays intact.

This is huge. Before I understood this, I was reading files directly in my main session and watching my context fill up with code I’d already reviewed. Now the agent does the heavy reading. I get the conclusions.

When to use agents (a guide for control freaks learning to let go)

Use agents when the task requires exploration:

• “Find all API endpoints and document them”

• “Investigate why this test is flaky”

• “Research how other projects handle rate limiting”

• “What files would I need to change to add feature X?”

Use agents when you’d be guessing at the steps:

If you find yourself writing a slash command with lots of “if this exists, then…” logic, stop. Step away from the keyboard. That’s agent territory. You’re trying to pre-solve a problem you don’t understand yet.

Use agents for heavy reading:

Agents have their own context window. They can read 20 files without bloating your main session. When they’re done, they return a summary. Your conversation stays clean.

Creating your own agents

You don’t have to use the built-in agents. You can create your own.

An agent is just a skill (markdown file in .claude/commands/) that spawns a subagent using the Task tool. Here’s a simple one:

# /research-topic

Research this topic in the codebase: $ARGUMENTS

Use the Task tool with subagent_type="Explore" to:
- Search for relevant files and patterns
- Read key implementation files
- Understand how it currently works

Return a structured summary:
- Key files involved (with line numbers)
- How the feature currently works
- Any gaps, issues, or technical debt found

That’s it. No fifty lines of conditionals. No edge case handling. The Explore agent figures out what to search, what to read, how deep to go. You describe the outcome. The agent handles the process.

The pattern: thin skill that spawns an agent. The skill is just a trigger with context. The agent does the thinking.

Agents vs slash commands (the actual difference)

Slash commands / Skills:

• Fixed steps

• Predictable output

• You know exactly what will happen

• Good for: formatting, templating, repetitive tasks with known structure

Agents:

• Dynamic exploration

• Variable output

• Figures out the path autonomously

• Good for: research, investigation, multi-file analysis, anything where you don’t know what you’ll find

Here’s the mental model: slash commands are for when you know the answer and just need to execute it. Agents are for when you don’t know the answer and need someone to go find it.

If you’re using slash commands for exploration, you’re making your life unnecessarily difficult. I did this for months. Learn from my suffering.

The real unlock (it’s embarrassingly simple)

Once I stopped trying to script everything, my workflow got simpler. Not more complex. Simpler.

Skills handle the predictable stuff: commit messages, content formatting, code reviews with a checklist.

Agents handle the unpredictable stuff: understanding codebases, investigating issues, researching approaches.

I stopped fighting the tool. I let agents explore. I let skills execute. Everything got easier. I felt slightly foolish for not figuring this out sooner, but that’s the tax you pay for learning things the hard way.

Next up: MCP servers — the things that let Claude actually interact with the real world instead of just imagining what websites might contain.

I help technical founders develop, deploy, and market their SaaS using Claude Code. These lessons came from months of doing it wrong first.

They are not interchangeable. Three differences matter:

1. Who pulls the trigger: Slash commands run when YOU invoke them. Skills run when CLAUDE decides they’re relevant.

2. Who provides context: Slash commands take arguments — /draft-linkedin-post [topic] [bullets] tells Claude exactly what to write about. Skills infer context from the conversation and codebase.

3. Token cost: Slash commands get inserted into context every time you invoke them. Skills only load their description until activated — the full content lazy-loads.

Control and clarity vs automation and efficiency. Pick your trade-off.

Slash commands: you’re in control (finally)

Slash commands run when you type them. Period. Full stop. No ambiguity. No hoping. No praying to the AI gods.

You type /draft-linkedin-post, it runs. You type /commit, it commits. Revolutionary concept, I know. In an age of magical AI that’s supposed to read your mind, there’s something deeply satisfying about a tool that just does what you tell it when you tell it.

I have /draft-linkedin-post that takes a topic and bullets, then outputs a post in my voice. Same structure every time. I don’t want Claude to get creative with the format — I want consistency. I want to type a command and get a predictable result. Like some kind of digital caveman using primitive trigger-response technology.

Other examples:

- /commit — standard commit message format

- /review — code review with my preferred checklist

- /atomize-content — break an essay into platform-specific posts

The key: if you’re giving the same instructions more than twice, make it a slash command. Your fingers will thank you. Your sanity will thank you. Your token budget might even thank you.

Skills: Claude decides (when it feels like it)

Skills are instructions that Claude is supposed to invoke automatically when relevant.

The theory — and I’m using “theory” here the same way physicists use it when they’re 90% sure but can’t prove it — is that you write a skill with a nice description, Claude reads it, and magically invokes it when the context matches.

The reality: skills don’t always fire automatically.

Sometimes Claude picks them up. Sometimes it doesn’t. Sometimes you have to explicitly say “use the X skill” anyway, which kind of defeats the entire purpose of having an “automatic” system. It’s like having a self-driving car that occasionally requires you to grab the wheel and steer. Very reassuring.

The dirty secret nobody wants to admit

Go read r/ClaudeCode threads about skills. I’ll wait. Actually, I’ll save you the trip:

“It hardly picks up any skill without actually telling it to use it”

“Skills would be awesome if it actually used them properly”

“Skills are basically just reminders to the LLM”

That last one is painfully accurate. Skills are fancy prompts that Claude may or may not remember exist. They’re like Post-It notes you stick on your monitor hoping your future self will notice them. Sometimes you do. Sometimes you walk past them for three weeks wondering why that yellow blob is in your peripheral vision.

Someone actually tested this.

Scott Spence ran 200+ tests on skill activation reliably:

The results:

- Simple instruction hook: 20% activation (coin flip)

- Forced eval hook: 84% activation

The difference? Commitment mechanisms. Instead of passively hoping Claude notices skills exist, the forced eval hook makes Claude explicitly evaluate EACH skill with YES/NO reasoning before proceeding.

Once Claude writes “YES — need this skill,” it’s committed. It’s harder to bypass something you just agreed to use.

The takeaway: skills can work reliably — but not out of the box. You need hooks to force the evaluation. Which kind of defeats the “automatic” promise.

So why do skills exist? (There are actual reasons)

Three legitimate use cases:

1. Lazy loading saves tokens.

Your CLAUDE.md is always in context. Always. Every conversation. Every token. Skills, on the other hand, are loaded on demand — at least in theory. If you have a 500-line CLAUDE.md because you kept adding “just one more instruction,” consider breaking domain-specific stuff into skills.

Your wallet will appreciate this eventually.

2. Organization for the obsessive-compulsive among us.

Instead of one massive CLAUDE.md that reads like a legal document, you can have modular skills: one for frontend patterns, one for API conventions, one for content writing. It’s cleaner to maintain. It makes you feel like you have your life together. Whether Claude actually uses them correctly is a separate question.

3. Sharing your neuroses with teammates.

You can package skills and share them with your team. “Here’s how I want code reviews done” becomes a shareable artifact instead of a 47-message Slack thread that nobody will ever read.

When to use which (the practical guide for people with deadlines)

Use slash commands when:

- You want to control exactly when it runs

- The task has fixed steps

- Consistency matters more than flexibility

- You don’t trust Claude to figure out when to apply it (wise)

Use skills when:

- Instructions only apply sometimes (not every conversation)

- You want to reduce CLAUDE.md bloat

- You’re okay with Claude deciding relevance (optimistic)

- You want to share patterns across projects/teams

- You’re mentally prepared to invoke them explicitly anyway

My approach (learned through pain)

I default to slash commands. I want control. I’ve been burned too many times by “intelligent” systems that aren’t quite intelligent enough.

I use skills for domain-specific instructions that would bloat my CLAUDE.md unnecessarily. My post summarizer skill doesn’t need to be in context when I’m debugging Python. My code review preferences don’t need to load when I’m drafting blog posts.

When I create a skill, I mentally prepare to invoke it explicitly. If Claude picks it up automatically, great — I’ll take that win. If not, I type “use the X skill” and move on with my life. No frustration. No existential crisis. Just pragmatic acceptance that the future isn’t quite here yet.

This is post 2 of 4. Next up: agents — and when to stop trying to script everything like it’s 2015.

You’re using Claude Code. You’ve seen these terms thrown around like confetti at a developer conference. Slash commands! Skills! Agents! MCP servers! Plugins! Each one sounds important. Each one sounds slightly different from the others. Each one makes you wonder if you’re using Claude Code wrong.

Spoiler: you probably are. But so is everyone else, so don’t feel too special about it.

Here’s the mental model that finally made sense to me after weeks of confusion and several existential crises about whether I understood my own tools.

The one-sentence version

Slash commands = shortcuts you trigger manually (like a civilized person)

Skills = instructions Claude might trigger automatically (emphasis on “might”)

Agents = autonomous workers with their own context (little worker bees you send off to do your bidding)

MCP servers = external capabilities like browsers, databases, APIs (the things that let Claude actually do stuff in the real world)

Plugins = packaging that bundles any combination of the above (a zip file for your AI workflow, basically)

That’s it. Five concepts. Five different jobs. The confusion happens because they overlap like a Venn diagram designed by someone who hates clarity. A slash command can spawn an agent. An agent can use MCP servers. A plugin can contain all of the above. It’s turtles all the way down.

(I’m not covering hooks here — automations that fire on events like file saves. That’s a whole other therapy session.)

The key distinction most people miss

Here’s what nobody tells you upfront: who decides when something runs?

• Slash commands: You trigger them. Like pressing a button. Revolutionary concept.
• Skills: Claude triggers them. In theory. When it feels like it. Maybe.
• Agents: You spawn them, then they run autonomously until they’re done or your tokens are.
• MCP servers: Claude calls them when it needs to reach outside your codebase.
• Plugins: You install them. They’re just containers.

This matters more than all the technical mumbo-jumbo. Want control? Slash commands. Want Claude to figure it out? Skills. Want to let something loose and hope for the best? Agents. Want Claude to actually interact with the real world? MCP servers.

The decision tree (for people who don’t want to think about this anymore)

When you’re about to ask Claude to do something, run through this:

Is it a repeatable task with fixed steps? → Slash command. Done. Move on with your life.

Does it need to access external systems? → MCP server. Claude can’t browse the web or query databases with pure thought. Yet.

Does it require exploration and figuring things out? → Agent. Let it wander. It’s smarter than you think. Sometimes.

Is it domain-specific instructions that don’t always apply? → Skill. Good luck getting Claude to actually use it without being asked.

Do you want to share your setup with others? → Package it as a plugin. Make it someone else’s problem.

The overlap problem (or: why everyone builds three things for the same task)

Here’s what happens in the wild: developers build a slash command, a skill, AND an agent for the same task. I’ve done it. You’ve probably done it. We’ve all sinned.

Pick one primary approach:

• Need control over when it runs → slash command
• Need Claude to decide when it’s relevant → skill (and a prayer)
• Need autonomous multi-step execution → agent
• Need external system access → MCP server
• Need to share your setup → plugin

Use the others to support, not duplicate. Your future self will thank you when you’re not debugging three different implementations of the same thing at 2 AM.

How they layer (the actually useful part)

Think of it as a stack:

• Skills = instructions (how to do things)
• Slash commands = triggers (entry points you control)
• Agents = workers (autonomous task executors)
• MCP servers = capabilities (external system access)
• Plugins = packaging (bundles of all the above)

A slash command can spawn an agent. An agent can use MCP servers. A skill can teach Claude how to use an MCP server efficiently. A plugin can package all of this into something you can share on GitHub and pretend makes you a thought leader.

They compose. They don’t compete. Unless you make them compete, in which case, godspeed.

This is post 1 of 4. Next up: slash commands vs skills — and why skills don’t work the way the documentation promises they will.

I help technical founders develop, deploy, and market their SaaS using Claude Code. This is the kind of workflow clarity I wish someone had given me three months ago.

Claude and I had been pair programming on an authentication system—tracking down race conditions, filing away “fix this later” issues, building up this rich context about why we made certain decisions. RS256 instead of HS256 for key rotation. Session middleware patterns. The whole architecture was in our shared understanding.

Then I hit compaction.

I came back the next day, opened a new Claude session, and asked: “Where did we leave off?”

Claude: “I don’t have information about previous sessions in my context.”

All of it. Gone.

The discovered bugs. The architectural decisions. The “by the way, we should fix this” notes. Everything we’d built up over dozens of hours—evaporated.

I spent 30 minutes re-explaining what we’d been working on. And even then, I couldn’t remember all the issues Claude had surfaced. How many edge cases had we found? Which ones were critical? What was blocking what?

This is what I call the amnesia problem. And it’s not just annoying—it’s a fundamental limitation of how we work with AI agents.

The TODO.md Trap

So I did what everyone does: I created a TODO.md file.

## TODO
- [ ] Add rate limiting to login endpoint
- [ ] Improve password hashing
- [ ] Fix email validation
- [ ] Build dashboard (depends on auth being done)

Seemed reasonable. Every project has a TODO list, right?

Three days later, it was already a graveyard.

Half the items were done but still unchecked. A quarter were outdated. New issues Claude discovered during implementation? Lost in chat history. Dependencies? I had “(depends on auth being done)” in a parenthetical. Good luck having Claude parse that reliably after compaction.

Steve Yegge calls these “swamps of rotten half-implemented plans.” He’s right.

Here’s why markdown TODOs fail with AI agents:

They become stale instantly - You finish a task, forget to update the markdown. The agent reads it, doesn’t know what’s actually done.

No dependency tracking - Can I start the dashboard? Is auth done? The agent has to guess.

Context evaporates - “Fix email validation” tells you nothing. Which email? Where? What’s broken? Why does it matter? After compaction, this line is worthless.

Agents can’t use them reliably - Claude reads the whole list, can’t tell what’s ready to work on, and often just… ignores it.

That TODO.md file? After compaction, it’s all you have. And it’s not enough.

Enter Beads: A Memory System Built for Agents

That’s when I found beads.

Steve Yegge built it specifically to solve the amnesia problem. It’s an issue tracker, but not like Jira or Linear. It’s built for AI agents, not humans.

Here’s the breakthrough: You don’t manage beads. Claude does.

I ran bd init in my project. That’s it. One command.

Then I just… kept working with Claude. And something wild happened.

Claude started filing issues automatically. Not when I asked—just when it discovered something worth remembering. While implementing the auth system, Claude would say:

“I notice there’s a potential race condition in the session handler. Filing it:

bd create ‘Fix race condition in user session’ --deps discovered-from:myapp-a4f2 -p 0“

It wasn’t asking permission. It wasn’t waiting for me to maintain a TODO list. It was building its own memory.

At the end of each session, Claude would update the notes on active issues:

bd update myapp-a4f2 --notes “COMPLETED: JWT login with RS256
KEY DECISION: Chose RS256 over HS256 for key rotation capability
IN PROGRESS: Session middleware
BLOCKERS: Need decision on token expiry (1hr vs 24hr trade-off)
NEXT: Implement refresh endpoint after expiry decision”

This wasn’t for me. This was for future-Claude.

The Compaction survival Test

The next day, I hit compaction again. New session, empty context.

Me: “What should we work on?”

Claude (without me asking, automatically ran these commands):

bd ready --json
bd list --status in_progress --json
bd show myapp-a4f2

Then replied:

“I can see we’re working on authentication (myapp-a4f2). Last session we completed the JWT login flow, decided to use RS256 for key rotation capability, and got blocked waiting for your decision on token expiry time.

The trade-off is: 1-hour tokens (better security, worse UX) vs 24-hour tokens (better UX, but wider attack window if tokens are compromised). What’s your preference?

Also, I’ve filed 3 issues we discovered along the way:

• Rate limiting for login endpoint (P0)

• Bcrypt rounds for password hashing (P1)

• Race condition in session handler (P0)

Should we resolve the token expiry question first, or tackle one of the P0 issues?”

The conversation history was gone. But Claude had full context.

Every decision. Every discovered bug. Every blocker. Every trade-off. Right there.

No re-explaining. No “wait, what were we doing?” No hunting through old conversations.

This is what beads does.

TodoWrite vs Beads: Two Memory Systems

Here’s where people get confused. Claude actually has two memory systems, and they serve different purposes.

TodoWrite: Working Memory (This Hour)

TodoWrite is Claude’s scratch pad for the current session:

✓ [completed] Implement login endpoint
→ [in_progress] Add password hashing
  [pending] Create session middleware

It shows you real-time progress. Gets marked complete as work happens. Disappears when the session ends.

Perfect for: “What’s Claude doing right now?”

Beads: Long-Term Memory (This Week/Month)

Beads is Claude’s episodic memory across sessions:

bd show myapp-a4f2

Notes: “COMPLETED: Login with bcrypt (12 rounds)
KEY DECISION: JWT (not sessions) for stateless auth
IN PROGRESS: Session middleware
NEXT: Need input on token expiry (1hr vs 24hr)”

Survives compaction. Captures meaning, not just tasks. Persists across all sessions.

Perfect for: “What happened last week? What decisions were made?”

The Handoff Pattern

1. Session start: Claude reads bead notes → creates TodoWrite items for immediate work

2. During work: TodoWrite gets marked complete

3. Reach milestone: Claude updates bead notes with outcomes + context

4. Session end: TodoWrite disappears, bead survives with enriched notes

After compaction: TodoWrite is gone forever. Bead notes reconstruct everything.

The Magic: Dependencies That Prevent Mistakes

This is where beads gets brilliant. It supports four relationship types:

1. blocks - Hard Blocker

bd create “Build user dashboard” -p 1
# Created myapp-e3f7

bd create “Implement authentication” -p 0
# Created myapp-g2h9

bd dep add myapp-e3f7 myapp-g2h9
# → “myapp-g2h9 blocks myapp-e3f7”

Now dashboard won’t show in bd ready until auth is closed. Claude can’t accidentally start building the dashboard before auth exists.

2. discovered-from - The Audit Trail

This is the agent’s secret weapon:

# Claude finds bug B while implementing feature A
bd create “Fix memory leak in session handler” \
  --deps discovered-from:myapp-a4f2 -p 0

Creates an audit trail of how work was found. Those “oh by the way” issues Claude mentions? They now get filed permanently, linked to context.

After a week of work, you have an automatically maintained discovery backlog. Prioritized. Linked. Ready to tackle.

3. parent-child - Hierarchy

bd create “Epic: Authentication system” -t epic
# Created myapp-j4k2

bd create “Add OAuth” --parent myapp-j4k2
# Created myapp-l8m1 (auto-linked)

Good for breaking down large features.

4. related - Soft Connection

bd dep add myapp-b7c3 myapp-d1e8 -t related
# “These touch the same code but don’t block each other”

What You Actually Do (Almost Nothing)

Your workflow:

One-time setup:

cd your-project
bd init

Done. That’s it.

Work with Claude normally:

“Let’s build user authentication”

Claude automatically:

• Creates issues as work emerges

• Tracks dependencies

• Updates notes at milestones

• Files discovered work with proper links

• Checks ready work at session start

You just work. The memory management happens in the background.

When you DO interact with beads (rarely):

# Weekly review
bd stats

# Check what’s blocked
bd blocked

# Context restore after time away
bd show myapp-a4f2

The agent does the rest.

Why Claude Loves It

The most interesting thing about beads isn’t the technology. It’s how Claude uses it.

Claude’s behavior changes:

1. Proactive filing: Claude files issues without being asked. “I notice X could be improved. Filing: bd create...“

2. Better planning: Claude uses dependencies to think through work order before starting.

3. Context awareness: Claude references past decisions from bead notes. “Last session we decided to use RS256 because…”

4. Discovery tracking: Claude treats discovered work as first-class, not throwaways.

Why? Because beads is built for how Claude actually works:

• Structured data (JSON)

• Clear state (open/in_progress/closed)

• Explicit relationships (dependencies)

• Queryable memory (show me what’s ready)

It’s not forcing Claude into a human workflow. It’s giving Claude the database it naturally wants.

When Beads is Overkill

Not every task needs beads. Use this test:

Use Beads when:

• Work spans multiple sessions

• You might hit compaction before finishing

• There are dependencies or blockers

• You’re discovering related work along the way

• You need to resume after time away

Example: “Build authentication system” (multi-day, many parts)

Use TodoWrite when:

• Work completes in this session

• It’s a simple linear checklist

• All context is in the conversation

• No dependencies or discovery

Example: “Refactor this 200-line file” (done in an hour)

The test: “Will I need this context in 2 weeks?”

• Yes → Beads

• No → TodoWrite

The Git Sync: How It Works Across Machines

Beads stores everything in two places:

1. .beads/beads.db - Local SQLite (fast queries)

2. .beads/issues.jsonl - Git-versioned JSONL (syncs across machines)

On your desktop:

bd create “New issue”
# → SQLite write (instant)
# → After 5 seconds, exports to JSONL
# → Git commit with your code changes

On your laptop:

git pull
# → JSONL updates
# → bd auto-imports (newer than local DB)
# → SQLite now has the issue

You get:

• Fast local operations (SQLite, <100ms)

• Git versioning (full audit trail)

• Multi-machine sync (JSONL)

• Offline support (no server)

It’s a distributed database… that’s just files in git.

Memory as Infrastructure

We’re at this weird moment where AI coding agents are incredibly capable but also incredibly forgetful.

We expect them to remember complex multi-week projects, track dozens of discovered issues, maintain perfect context across compaction—but we give them… markdown files.

Beads doesn’t make agents smarter. It makes them less forgetful.

And honestly? That might be more important.

Because the hardest part of any project isn’t writing code. It’s not losing track of what needs to be written.

Beads gives your agent:

• Memory that survives compaction

• A discovery backlog that doesn’t evaporate

• A dependency graph that prevents mistakes

And you barely have to do anything. Install it, initialize it, let Claude manage it.

The agent handles the rest.

Get started:

• GitHub: steveyegge/beads

• Quick start: bd init in your project

• Let Claude do the rest

Key commands (mostly for reference—Claude uses these automatically):

bd init                    # One-time setup
bd ready                   # What’s ready? (Claude checks this)
bd show <id>               # Issue details (Claude reads notes)
bd stats                   # Weekly review (you use this)
bd blocked                 # What’s stuck?

Give your agent a memory. See what happens.

Not the graceful kind of death where systems send you helpful notifications. Well, okay, they had a status page. There was technically a “we’re experiencing technical difficulties” message somewhere on the internet if you went looking for it. But in the moment? When you’re mid-keystroke and suddenly your AI copilot just stops responding? It just felt gone. Vanished. Disappeared like my motivation to manually write boilerplate code.

For approximately thirty seconds, I experienced what I can only describe as the five stages of grief compressed into real-time panic. Denial: “It’s just my internet.” Anger: “ARE YOU KIDDING ME RIGHT NOW?” Bargaining: “Maybe if I restart everything seventeen times…” Depression: “I guess I’m just not deploying tonight.” And finally, acceptance: “Well, I suppose I could try coding like it’s 2019.”

The outage lasted about five hours. Five. Entire. Hours. In developer time, that’s basically a geological epoch. I had bugs to fix. Tests to run. Production deployments waiting. And here I was, suddenly expected to do all of this using only my own fragile, fallible human brain.

So I did what any reasonable developer would do: I panicked for another minute, then reluctantly dusted off those ancient skills we used to call “programming without an AI safety net.”

Here’s the uncomfortable truth nobody wants to admit: it wasn’t that bad. I mean, it was bad. Don’t get me wrong. It was slow and tedious and made me feel like I was debugging with mittens on. But I didn’t spontaneously combust. My IDE still worked. My fingers still remembered where the keys were. Muscle memory is apparently still a thing.

I fixed the bug. Eventually. It just took approximately three times longer than it should have because I had to do wild, archaic things like “read the documentation thoroughly” and “actually understand what my code was doing” instead of asking Claude Code to explain it to me like I’m five.

The testing phase was particularly brutal. Normally, I’d have Claude Code help me think through edge cases, generate test scenarios, and spot the stupid mistakes I’m invariably making. Instead, I had to use my own brain to think of test cases. My own brain! Like some kind of caveman! I had to actually remember what good test coverage looks like and implement it myself. The horror.

And deployment? Well, deployment was already sorted, thankfully. But the whole process of getting there—fixing the bug, testing it properly, making sure everything was ready to ship—felt like wading through molasses. Without my AI copilot catching my typos, suggesting optimizations, and helping me think through edge cases, every step just took longer than it should have.

But here’s where it gets really pathetic. After about two hours of this manual labor cosplay, I had a brilliant idea. Claude Code might be down, but wasn’t there Claude Code web? Like, the browser version? Different infrastructure, right? Surely that was still running?

So I did what any self-respecting, definitely-not-addicted developer would do: I pulled my entire git repo into Claude Code web and just… kept working there. Yes, you read that right. My solution to Claude Code being down was to use a different version of Claude Code. I replaced my broken AI dependency with a slightly different flavour of the exact same AI dependency.

The technical term for this is “problem-solving.” The accurate term for this is “I have a problem.”

It actually worked pretty well as an interim hack, which is either a testament to Anthropic’s redundancy planning or a damning indictment of my ability to function independently. Probably both. The web version was a bit clunkier for my workflow, sure, but it beat slowly dying inside while manually parsing error messages.

The whole experience gave me a weird kind of perspective. It’s like when your phone dies and you suddenly remember you have hands and can look at things in real life. Except instead of appreciating nature, I was appreciating how much faster AI makes me at my job.

I can technically code without Claude Code. I proved that tonight. It’s like how I can technically do math without a calculator—possible, legal, but why would I choose suffering? The old ways still work. They’re just… inefficient. Tedious. The kind of thing that makes you question your career choices around the third hour of manually debugging something that Claude Code would’ve spotted in thirty seconds.

But sitting there in the dark ages of 2019-style development, something struck me. It’s been barely any time at all since AI coding assistants became genuinely useful. A few years ago, we were all coding exactly like this—manually, slowly, relying entirely on our own pattern recognition and Stack Overflow. And we thought we were pretty damn efficient.

Now? Now a five-hour outage feels like a crisis. That’s how far we’ve come. That’s how quickly this technology went from “neat party trick” to “fundamental part of my workflow” to “how did I ever function without this.”

I spent those five hours slightly inconvenienced, moving slower than usual, but still shipping code to production. A decade ago, this was just called “having a normal day at work.” Today, it felt like working with a handicap. That shift happened so fast we barely noticed it occurring.

We’re living through one of those rare moments where technology isn’t just improving incrementally—it’s fundamentally changing how we work. And tonight, in the brief absence of that technology, I got a glimpse of both where we’ve been and how far we’ve traveled.

The tools came back online. I went back to my normal pace. But I won’t forget that brief window of forced perspective, that reminder that we’re experiencing something genuinely transformative in real-time. Even if it did feel painfully slow while it was happening.