Claude Code Changed How I Ship Software
I've been using Claude Code daily for about three months now. Not as an experiment — as my primary development tool, alongside Xcode and the terminal. I've shipped a full macOS app, a Cloudflare Worker backend, a marketing site, and a blog using it.
Here's what I've learned. No hype, no "10x developer" claims. Just what actually changed.
What changed: I ship faster, but not how I expected
The speed gain isn't in writing code faster. I was already a fast coder. The speed gain is in all the things I used to procrastinate on.
- Build scripts I would have put off for a week — done in 20 minutes
- Signing, notarization, distribution pipeline — sorted in one session
- Blog posts and marketing pages — written and deployed same day
- Bug investigation that used to take hours of reading docs — narrowed down in minutes
The pattern is clear: Claude Code is most valuable for tasks outside your core expertise. I'm a Swift/iOS developer. Writing Cloudflare Workers in TypeScript, configuring DNS, debugging codesign entitlements — that's not my wheelhouse. But with Claude Code, I don't need it to be.
What didn't change: I still make all the decisions
Claude Code doesn't architect my app. It doesn't decide what to build. It doesn't make product decisions. I still design the data model, choose the tech stack, decide the UX flow, and review every line of code.
The tool is most useful when I know what I want and need help with how. "Fix the mic permission issue on macOS" is a good prompt. "Make my app successful" is not.
The biggest surprise: it's a debugging partner
I expected code generation. What surprised me was how good it is at diagnosis.
Last week, my app's microphone permission stopped working after a Mac restart. Users couldn't get past the onboarding screen. I'd been staring at the code for an hour, convinced it was an API issue.
Claude Code read the build script, found that codesign --force was stripping the audio-input entitlement from the binary, and explained why macOS was silently blocking the permission dialog. A bug I might have spent days on was diagnosed in minutes.
The best use of AI in development isn't generating code — it's having a second pair of eyes that has read all the documentation you haven't.
Where it falls short
It's not all upside. Some honest limitations:
- SwiftUI edge cases — it sometimes suggests patterns that don't work with AppKit interop (NSHostingView quirks, NSPanel sizing). I've had to correct it multiple times.
- Context drift — in long sessions, it can lose track of earlier decisions. I've learned to keep sessions focused.
- Over-engineering — left unchecked, it adds error handling, abstractions, and comments that aren't needed. You have to actively push back toward simplicity.
- Confidence without correctness — it sometimes states things confidently that are wrong. Trust but verify, always.
My actual workflow now
Here's how a typical day looks:
- I decide what to build/fix (product decision — mine)
- I describe the task to Claude Code with context
- It explores the codebase, proposes an approach
- I review, adjust, approve
- It implements, I test
- Repeat
The key word is review. I read every diff. I understand every change. The tool does the typing; I do the thinking. That's the healthy relationship.
The meta-lesson
The biggest shift isn't technical. It's psychological. When the cost of implementation drops, you stop filtering ideas by effort. You just build them.
"Should I add a blog to the marketing site?" Used to be a weekend project. Now it's a 30-minute task. "Should I fix this edge case?" Used to be "I'll get to it." Now it's done before lunch.
The compound effect of removing all those small friction points is massive. You ship more, learn faster, and iterate tighter. That's the real change.
The tool didn't make me a better developer. It made me a more prolific one.