I was in the middle of asking Claude to review some code when I stopped.
"Is this still my code?"
What I was feeling wasn't gratitude for the help, or satisfaction at moving faster. It was something I hadn't quite named before — a quiet guilt about having handed something off.
I've been building apps solo for over a decade. Design, code, release — all of it, just me. That "I do it myself" instinct wasn't just a workflow habit. It was genuinely part of how I thought of myself as a developer.
After roughly a year of working closely with Claude, that's changed. Slowly, but in ways I didn't expect.
I Used to Think Delegating Meant Losing
When I first started using Claude, I kept it strictly in the "last resort" box. Stuck on something? Try Claude. No idea where to start? Ask Claude for options. But only then.
The fear underneath that was real: if I rely on AI too much, won't my skills atrophy? Every time I handed an error to Claude instead of grinding through it myself, I worried I was letting something important get weaker.
A lot of developers feel this, I think. But looking back, I was asking the wrong question entirely.
The question isn't whether skills deteriorate. It's: what kind of thinking is actually worth your time?
The Moment I Realized I'd Stopped Asking "Why"
The shift came from something small.
I was working on a SwiftUI animation and asked Claude for help. The code it gave me worked. I copied it in without really thinking about what I was doing.
// Code I was using without actually understanding it
withAnimation(.spring(response: 0.4, dampingFraction: 0.7)) {
isExpanded.toggle()
}A week later, I needed something similar for a different screen. I sent Claude the exact same question again.
That's when it landed: I had no idea what response and dampingFraction actually meant. I had received the code. I hadn't absorbed anything.
This wasn't an AI dependency problem. It was a problem with how I was asking.
The Gap Between Delegating and Offloading
What I had to learn was to change the quality of the question I brought to Claude.
Before:
"Write me a SwiftUI spring animation to expand this view."
After:
"Can you explain how
responseanddampingFractionactually affect the physical feel of a spring animation? I want to understand the parameters, then implement something that feels natural when a button is tapped."
On the surface, a small difference. But how much I actually retain is completely different.
The first approach: I get code and move on. The second: I understand the underlying principle and can make my own decision about implementation.
Delegating doesn't mean handing off your judgment. It means making the information-gathering part of judgment more efficient.
Once that distinction clicked, my whole relationship with Claude shifted.
Knowing What Claude Isn't Good At Made My Strengths Clearer
The longer you work with Claude, the more clearly you see where it falls short.
Emotional experience design, for one. When I ask "what should the user feel when they tap this button?", Claude gives me an answer. But it's generic in a way that I can feel. It doesn't have the years I've spent watching real users interact with my apps, developing intuitions about what makes someone think "I really like this."
Or the brand voice of a specific app. Why this color, this copy, this overall tone. The accumulated sense behind those choices isn't something Claude can reconstruct from nothing.
Mapping out those gaps made something else clearer: what I've actually been building toward over the years.
For me, indie development isn't about shipping features. It's about creating moments where someone uses an app and has a small, quiet positive feeling. That part can't be delegated. And once I understood that, the guilt about delegating everything else gradually disappeared.
What Actually Changed Wasn't Speed — It Was Density of Thought
People often say AI makes them 10x faster. In my experience, that's about half right.
My implementation speed has gone up. But the change that actually feels larger day to day is this: the amount of thinking I can do in the same amount of time has increased.
Before, I was spending roughly half of every hour chasing syntax errors and searching documentation. Now I can use that time to ask "is this architecture actually right?" or "does this feature need to exist at all?"
By letting Claude handle the implementation details, I freed myself to concentrate on design and judgment. That's not just efficiency — it's a reallocation of where I put my intellectual energy.
How My Actual Workflow Changed
Here's a concrete example of what shifted.
When starting a new feature, I used to begin by thinking about how to write it: the syntax, the APIs, which library to use. I came in at the implementation layer.
Now the order is reversed. First I write out why the feature needs to exist and what specific problem it solves for which users. Then I ask Claude: "Here's the problem I'm trying to solve. Can you walk me through the main approaches available on iOS for this, with the tradeoffs of each?"
Claude is dramatically faster at laying out options than I am. I look at the structured comparison and decide which approach is best for my specific app and users. That order of operations is where I actually feel like I'm making a decision — not just executing one someone else already made.
What Collaboration Looks Like Now
After a year, here's roughly how things divide:
What I delegate to Claude: First drafts of implementations, initial error triage, summarizing documentation, boilerplate for tests, routine refactoring, laying out options and tradeoffs.
What I keep for myself: Architecture decisions, the core of the user experience, brand voice, final calls on technical tradeoffs, and the fundamental question of whether something should be built at all.
What I notice is that everything in the second list is a question without a single right answer. Claude is genuinely excellent at questions that have correct (or findable) answers. Questions where correctness doesn't exist — those are still mine.
The resistance I felt at the beginning came, I think, from not seeing that distinction clearly.
If you're currently feeling like relying on Claude too much will make you worse as a developer, try asking yourself a different question:
"What kind of thinking do I actually want to get better at?"
When you can answer that, the line between what to delegate and what to hold onto becomes a lot clearer. Delegating isn't giving up. It's protecting the space where your real work happens.