I Replaced My Entire Dev Workflow with Claude Code. Here's What Actually Works.

Two months ago I switched from Cursor to Claude Code. Fully. Not “trying it on the side” but “this is how I code now.”

I’d been using Cursor for a while and it was fine. Good autocomplete, decent chat. But Claude Code changed how I think about the work itself, not just how I type it. The difference isn’t speed. It’s that I stopped thinking about writing code and started thinking about describing what I want built.

I use it across everything. At my day job, I use Claude (enterprise) on a large codebase that spans APIs, a React frontend, and a CMS across multiple product layers. On the side, I use it for the Devteds website (Astro + Tailwind), Wistale (an AI storybook product), Node.js services, and a Rails app with a Docker setup that’s genuinely painful on Mac when you’re juggling multiple worktrees and parallel containers. The range matters. What I’ve learned working on a large production codebase at work directly informs how I use Claude on smaller projects, and vice versa.

CLAUDE.md is the real product

If you’re using Claude Code without a CLAUDE.md file, you’re using maybe 30% of it.

CLAUDE.md is a markdown file at the root of your project. It gives Claude persistent context: your stack, your conventions, your file structure, where things live. It loads into every conversation automatically.

Writing it felt more like product design than configuration. I was defining how an AI agent should think about my project. What matters. What doesn’t. What the rules are.

For the Devteds site, mine includes the stack (Astro, Tailwind v4, TypeScript strict), URL conventions, where content and images live, the old Jekyll project path for migration reference, brand color, hosting details. Under 50 lines. Shorter is better. Every vague instruction dilutes the specific ones.

For my Rails project, the CLAUDE.md is different. It describes the Docker Compose setup, which containers talk to which, how to run migrations, which worktree maps to which branch. That project has a lot of moving parts and Claude needs to know the topology before it touches anything.

Skills: where it gets genuinely useful

A skill is a markdown file in .claude/skills/ that gives Claude a playbook for a specific task. You invoke it like a slash command. No SDK, no API, no build step. Just a folder with a SKILL.md and optionally some reference files. That’s the entire abstraction.

The first skills I built were for content (generating blog ideas, drafting posts). Those were useful. But the skills that actually changed how I work are the ones that wrap the development process itself.

/start-task is what I run at the beginning of every session. It checks the current code state, fetches latest from the repo, reads the roadmap, reviews recent commits, checks what’s deployed, and suggests what to work on next. It’s like a standup meeting with your codebase. Before this, I’d spend the first 10 minutes of every session figuring out where I left off. Now I just type /start-task and get a summary with clear next steps.

/wrap-up handles end-of-session bookkeeping. It updates the roadmap with what got done, stages and commits the right files, pushes to the remote, and optionally creates and merges a PR. All the stuff I used to forget or skip when I was tired at the end of a session. The roadmap used to get stale within a week. Now it stays current because closing the loop is one command.

/seo-review runs a Lighthouse audit, analyzes the scores, identifies specific fixes with priorities, and adds tasks to the roadmap. Instead of me squinting at Lighthouse reports and manually tracking what needs fixing, Claude reads the numbers and turns them into actionable work items. This one paid for itself immediately on the Devteds rebuild when we needed to hit 95+ across all categories.

/new-idea is for when I’m thinking about a product idea and want to pressure-test it quickly. It researches the competitive landscape, assesses technical feasibility, estimates MVP scope, and gives a verdict (worth exploring, park it, or pass). If it’s worth exploring, it adds a section to the roadmap. I built this because I was losing ideas in random notes. Now they either make it into the roadmap with context or get explicitly passed on.

I’ve built similar skills for Wistale and it’s been very efficient. The pattern is the same across projects: codify the process you already follow, but make it consistent and automatic. Good practices that you’d skip when you’re rushing now happen every time because the skill enforces them.

How these skills connect into a workflow

The real value isn’t any single skill. It’s that they chain together into a rhythm:

Start a session with /start-task. Know exactly where you are and what’s next.
Do the work. Claude handles the code, you handle the decisions.
If a new idea comes up mid-session, run /new-idea to capture and assess it without losing context.
Periodically run /seo-review to catch regressions.
End the session with /wrap-up. Roadmap updated, code pushed, nothing forgotten.

This loop keeps the project healthy. The roadmap is always current. Commits are clean. Performance doesn’t silently degrade. Ideas don’t get lost in a notes app somewhere.

Before skills, all of this was manual discipline. And manual discipline fails when you’re tired, or rushing, or juggling three projects.

What actually changed across projects

The Devteds rebuild was the most dramatic example. I migrated 12 Jekyll blog posts by pointing Claude at the old project directory and describing the new frontmatter schema. Ten minutes of my time, mostly reviewing output. Product pages for Wistale were describe-and-iterate. Lighthouse optimization went from a manual chore to a conversation.

But the Rails project is where Claude Code proved itself differently. That codebase has Docker containers for the app, the database, Redis, background workers. Running parallel worktrees means parallel sets of containers. On a Mac, that’s a mess. Claude handles the Docker Compose juggling, knows which port maps where, and doesn’t get confused when I switch branches. Before this, I kept a cheat sheet. Now Claude is the cheat sheet.

The Node.js projects are simpler but still benefit. Scaffolding, test setup, dependency management. The kind of work that’s not hard but eats time.

Where Claude Code falls apart

I want to be honest about the failure modes.

Visual design is still a human job. Claude can implement a design you describe, but it can’t originate one that feels polished. Every first version looked like a template. I pushed hard on spacing, typography, and visual hierarchy. Even then, I was making most of the aesthetic decisions.

Complex multi-step refactors get messy. When I asked Claude to restructure the entire layout system across multiple components simultaneously, it lost track of dependencies. Smaller, focused tasks worked much better.

It doesn’t know when to stop. Ask Claude to “improve” something and it’ll add error handling, type annotations, comments, and abstractions you didn’t ask for. I learned to be specific: “change X to Y” not “make this better.”

Context drift in long sessions. After 30+ exchanges, Claude starts losing track of earlier decisions. I start fresh sessions with /clear for each distinct task. CLAUDE.md carries the persistent context.

Why I switched from Cursor

Cursor is a good tool. The autocomplete is fast, the inline chat works well for small edits. I still open it occasionally for quick stuff, though that’s happening less and less.

But Claude Code operates at a different level. Cursor helps you write code faster. Claude Code helps you think about code differently. The terminal-first approach felt weird at first, then liberating. I describe what I want, Claude reads the project context, makes the changes across files, and I review the diff.

The skills system is what sealed it. There’s nothing like it in Cursor. Being able to type /start-task and get a full project status with recommendations, or /wrap-up and have all the session cleanup handled, that’s not autocomplete. That’s a development process.

The patterns that stuck

After two months across multiple projects:

Keep CLAUDE.md ruthlessly short. Project-level rules only. Task-specific stuff goes in skills.

One task per conversation. Don’t ask Claude to migrate blog posts AND redesign the footer in the same session.

Review every diff. The moment you stop reviewing is the moment Claude introduces a subtle bug or an unwanted “improvement.”

Build skills for your process, not just your code. The most valuable skills I’ve written don’t generate code at all. They manage the workflow around the code. Start-of-session, end-of-session, audits, idea capture.

Each project teaches you something new. The CLAUDE.md that works for a static site doesn’t work for a Rails monolith. The skills that help with one project’s workflow don’t map directly to another. You learn what Claude needs to know by watching where it gets confused.

What this actually means for solo developers

I don’t think Claude Code replaces developers. But it changes what “development” means day to day.

I spent more time this month on product decisions, content strategy, and design direction than on actual code. The code itself (Astro components, Tailwind styling, Docker configs, content migration) was mostly handled by Claude with my review.

For a solo developer running a product studio, that’s a real shift. I’m not faster at coding. I’m spending less time on code and more time on the things that actually differentiate the product.

The biggest surprise wasn’t the code generation. It was that skills turned my ad-hoc habits into a reliable process. I used to forget to update the roadmap. I used to let Lighthouse scores drift. I used to lose track of where I left off between sessions. Now there’s a command for each of those things, and it works the same way every time.

If you want to try it, start small. Add a CLAUDE.md to one project. Use Claude Code for one real task. Then write one skill for something you do repeatedly. See if it earns your trust.

That’s how it started for me. Two months later, I can’t imagine going back.