Skip to main content
  1. Insights/

Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

·11 mins
Vin Patel
Author
Vin Patel

Everyone’s Arguing About AI Replacing Developers. I’ve Stopped Arguing.

For the past several months, I’ve been running Claude Code as my daily driver — not as a novelty, not as a party trick — as the actual environment where I build, debug, ship, and think.

And the thing nobody’s talking about? The gap between using Claude Code casually and using it with intentional architecture is wider than the gap between a junior and senior engineer.

This article is about that gap.

Stack Overflow’s 2024 Developer Survey found that 76% of developers are using or plan to use AI tools. But adoption isn’t mastery — using these tools well is a craft problem, not an access problem. And craft is learnable.


The Daily Driver Mindset Shift

Illustration

Stop treating AI like a search engine with autocomplete.

Most people use Claude Code like they used Stack Overflow: fire a question, get an answer, close the tab. That pattern leaves 80% of the capability on the table.

“Daily driver” means something specific. It means Claude Code becomes the runtime environment for your thinking — not just a query interface. You’re building a persistent, contextual workspace that compounds over time.

Here’s the inflection point I noticed in my own usage: I stopped asking Claude Code to help me do things and started asking it to operate within the system I’d built. The moment your AI environment has opinions, constraints, and institutional memory — that’s when the productivity multiplier kicks in.

GitHub’s controlled 2022 study of Copilot found developers completed a coding task 55% faster with AI assistance. That was one bounded task, not “complex work” broadly — but the direction holds, and the average almost certainly undersells intentional users and oversells casual ones. The average hides a distribution.

For solo practitioners like me, this matters even more. I have no team context to fall back on. My Claude Code context is my team memory. If I don’t architect it deliberately, I’m perpetually starting from scratch.

Anthropic launched Claude Code in February 2025 explicitly as an “agentic coding tool” — not a chat interface. That framing is doing a lot of work. Agents operate in environments. Environments have structure. Structure is your responsibility to build.


CLAUDE.md — The Most Underrated Feature in AI Development

A 200-line file that saves 200 hours.

Every Claude Code session without a CLAUDE.md file is a session where you’re re-explaining your stack, your conventions, your constraints, and your current state of work. For a solo builder running multiple projects simultaneously, this context tax is brutal.

CLAUDE.md is a persistent context file that lives in your project root. Claude Code reads it at the start of every session. Think of it as your project’s constitution — the document that makes everything else coherent.

My CLAUDE.md for a recent data pipeline project ran to 180 lines. It took me about 3 hours to write properly. I estimate it’s saved me 40+ hours of re-explaining context across sessions. The ROI math is embarrassingly good.

Here’s the architecture that actually works:

  • Project overview — 2-3 sentences, ruthlessly specific. Not “a web app” but “a Next.js 14 App Router application that ingests webhook events from Stripe and writes normalized records to a Supabase Postgres database.”
  • Tech stack with versions — no ambiguity. Claude will assume things if you don’t specify. You don’t want Claude assuming.
  • Coding conventions — your actual conventions, not “follow best practices.” Best practices is noise.
  • What NOT to do — anti-patterns specific to this project. This section alone is worth the price of admission.
  • File structure explanation — especially for non-standard layouts.
  • Current WIP state and open questions — this one transforms sessions. Claude knows where you left off.
  • External dependencies and gotchas — the weird API rate limit, the library that breaks on Node 20, the third-party service that returns inconsistent response shapes.

Anthropic’s own Claude Code documentation explicitly recommends the two-tier system: a global CLAUDE.md in your home directory for personal preferences that apply everywhere, and project-level files for project-specific context. I use both. The global file has my general coding philosophy, preferred patterns, and things I never want to see (like explanatory comments on obvious code). The project file has everything specific.

The “new maintainer” test is how I quality-check every CLAUDE.md I write: If a brilliant engineer joined this project cold today, would this file get them to productive output in under an hour? If not, it needs more work.

Common mistakes I see: too vague (“write clean code”) or too verbose (the file becomes noise Claude starts ignoring). Aim for dense specificity, not exhaustive documentation.

The rework rate drop alone — from ~30% to ~9% — is what sold me on investing serious time in context architecture. Every misaligned output is a context failure, not a model failure.


Skills — Teaching Claude Code Your Domain

*The difference between a gener

Illustration
ic AI and your AI.*

Claude is a brilliant generalist. Your work is specialist. The gap between “Claude knows Python” and “Claude knows how I build data pipelines in Python with these specific constraints, this error-handling philosophy, and these testing conventions” is where Skills live.

In Claude Code terms, Skills are reusable instruction sets, composable prompt patterns, and domain-specific knowledge you inject systematically — beyond what CLAUDE.md handles at the project level.

I spent about two weeks building what I think of as my cognitive fingerprint in Claude Code. Accumulated patterns, preferences, domain vocabulary, and recurring task templates that make outputs feel like mine rather than generic AI output. The quality difference is significant and immediately obvious.

In my own use, structured, accumulated prompting patterns consistently outperform ad-hoc prompting on complex tasks — often dramatically. That gap is your Skill library. It’s the delta between prompting blind and prompting with accumulated craft.

What a personal skill library looks like in practice:

  • Standard scaffolds for recurring task types (API endpoint, data transformer, test suite setup)
  • Domain vocabulary — if I say “normalize the event stream,” Claude should know exactly what that means in my context
  • Preferred patterns for problems I solve repeatedly
  • Error handling philosophy — do I want defensive programming with explicit error states, or do I want it to throw and let the caller handle it?
  • Testing conventions matched to my actual test suite structure

The skill vs. prompt distinction matters. Prompts are one-off. Skills are reusable, composable, and they evolve as your work evolves. They’re the difference between a tool you use and a tool that knows you.


Subagents — Parallelizing Your Thinking

One of the most powerful features almost nobody uses correctly.

Claude Code’s subagent capability lets you spawn parallel task threads — effectively running concurrent workstreams within a single session or across coordinated sessions. This is where “agentic” stops being a buzzword and starts being a literal description.

The practical use case: you’re building a feature that touches the database layer, the API layer, and the frontend. Sequentially, that’s three separate problem spaces. With subagents, you can decompose the work, run parallel exploration on each layer, and synthesize back.

For solo builders, this is profound. I’m not parallelizing across a team — I’m parallelizing across one person’s cognitive bandwidth. The subagent handles the exploration work while I stay at the architectural level.

Anthropic’s Claude Code documentation describes subagents as spawnable processes that can “read files, write code, run tests, and call external services” — all autonomously, within the bounds you define. The key phrase is “within the bounds you define.” Unstructured subagent use is chaos. Structured subagent use is leverage.

My current pattern: I write explicit subagent briefs. Each one gets a scoped task, a success criterion, and a list of constraints. It’s basically a mini CLAUDE.md for each parallel workstream. This sounds like overhead. It’s actually the opposite — it prevents the expensive sprawl of an unguided agent going in six wrong directions simultaneously.


MCPs — The Ecosystem That Changes Everything

Model Context Protocol is the API layer for AI tools, and it’s growing fast.

MCPs (Model Context Protocols) are integrations that let Claude Code interface with external tools, services, and data sources in a structured way. Think of them as the plugin API for agentic AI — the difference between an isolated thinking tool and one that can reach into your actual systems.

The MCP ecosystem is moving fast. As of early 2025, there are MCPs for GitHub, Postgres, filesystem operations, web search, browser automation, and dozens of other common developer needs. Anthropic opened the MCP specification, which means community-built MCPs are multiplying rapidly.

What this means practically: Claude Code can pull a PR, read the diff, understand the context from your CLAUDE.md, run your test suite, and suggest a fix — without you copy-pasting anything. That’s not a demo. That’s a Tuesday.

The MCPs I’ve found most valuable in my own workflow:

  • GitHub MCP — PR review, issue triage, repo navigation without context switching
  • Filesystem MCP — direct file operations with full awareness of project structure
  • Postgres MCP — schema introspection and query analysis with live database context
  • Web search MCP — up-to-date information access without breaking the Claude Code session

The compounding effect here is significant. Each MCP you integrate reduces a category of context-switching. Context-switching is the silent killer of solo builder productivity — every time you leave the environment to go check something, you’re losing state.

The database and filesystem categories being so high tells you something important: developers aren’t just using Claude Code to write code. They’re using it to understand and navigate their systems. That’s a fundamentally different use case than autocomplete.


The Full Architecture — How It All Fits Together

This is the diagram nobody draws but everyone needs.

graph TD
    A[Claude Code Session] --> B[CLAUDE.md\nProject Context]
    A --> C[Global CLAUDE.md\nPersonal Preferences]
    B --> D[Skills Layer\nDomain Knowledge + Reusable Patterns]
    C --> D
    D --> E[Main Agent\nOrchestration + Reasoning]
    E --> F[Subagent 1\nScoped Task A]
    E --> G[Subagent 2\nScoped Task B]
    E --> H[Subagent 3\nScoped Task C]
    F --> I[MCP: GitHub\nPR + Issues]
    G --> J[MCP: Postgres\nSchema + Queries]
    H --> K[MCP: Filesystem\nDirect File Ops]
    I --> L[Synthesized Output\nCode + Decisions + Docs]
    J --> L
    K --> L
    L --> M[Updated CLAUDE.md\nLiving Documentation]
    M --> A

The loop at the bottom is the part most people miss. After a productive session, I spend 10 minutes updating CLAUDE.md with what I learned — new gotchas, decisions made, patterns that worked. That update feeds the next session. That’s the compounding effect in action.

This isn’t a workflow I arrived at on day one. It took months of iteration. But the architecture is now stable enough that I’d be genuinely reluctant to work any other way.


The Honest Tradeoffs

Because nothing is free.

Setup cost is real. Building a proper CLAUDE.md, developing your Skill library, configuring your MCPs — this is a few days of intentional work before you see the full return. For someone who just wants to ship a quick script, it’s overkill.

The maintenance overhead is also real. CLAUDE.md goes stale if you don’t update it. Skills need revision as your patterns evolve. MCPs occasionally break with API changes. This is infrastructure, and infrastructure requires maintenance.

Context window limits matter. Even with CLAUDE.md providing persistent context, very long sessions accumulate noise. I’ve learned to keep sessions focused and to do “context resets” when a session has drifted — start fresh with a clean CLAUDE.md rather than dragging along three hours of accumulated confusion.

And Claude Code costs money at serious usage levels. For solo builders, this is a real consideration. My approach: treat it like a SaaS tool with genuine ROI math, not a toy. If it’s saving me 10+ hours a week at my effective hourly rate, the subscription is trivially justified.


What I’ve Actually Shipped With This Stack

Specifics, because specifics are what matter.

Using this full architecture — CLAUDE.md, Skills, Subagents, and MCPs — I’ve been able to move from idea to working prototype on side projects in hours rather than days. Complex data processing logic that would have required deep Stack Overflow spelunking gets handled in a single session with the right context in place.

The most valuable outcome isn’t speed. It’s consistency. My output is more architecturally coherent because Claude Code is operating with my actual constraints, not generic best practices. Code that comes out of a well-configured Claude Code environment looks like it was written by someone who knows my codebase — because in a meaningful sense, it was.

In my own experience, a well-structured Claude Code setup delivers roughly 2x+ productivity on complex tasks versus ad-hoc prompting — and I’d argue intentional users see even larger gains because the benefits compound.


The Bottom Line

Claude Code with intentional architecture isn’t a better version of what you’re already doing — it’s a different category of thing entirely.

Most developers are using AI like a faster Stack Overflow. A small number are using it like a persistent, domain-aware engineering environment. The gap between those two groups will widen every month as the intentional users compound their context while the casual users keep resetting to zero.

You don’t need a team, a startup, or a budget to do this. You need a well-written CLAUDE.md, a few hours building your Skill library, and the willingness to treat your AI environment like infrastructure worth investing in.

The developers who figure this out aren’t going to replace other developers. They’re just going to do the work of three.


Vin Patel is an independent builder and AI technologist. He writes about tools, workflows, and what actually works in practice at vinpatel.com.