2026-05-05

How I Code with Claude: A Full-Stack Developer’s Daily Workflow

Everyone keeps asking me the same thing:

“Do you really code with AI now? Doesn’t it just slow you down?”

Short answer: no, but only because I stopped using it the wrong way.

This is what my actual day looks like as a full-stack dev shipping production code. No hype, no “10x engineer” nonsense. Just the patterns that stuck after months of trial and error.

The Setup

I use two things, almost daily:

Claude Code in the terminal → for anything inside a repo.
Claude API → for things I’m building into a product (search, summaries, smart inputs).

The mistake I made early on was treating both like a chat window.
They’re not. They’re tools with very different strengths.

What I Delegate Without Thinking

These are tasks where I literally don’t read the output line by line anymore — I read the diff:

Boilerplate. New endpoint, new form, new migration file. The shape is always the same.
Tests for code I just wrote. Unit tests, edge cases, mock setup.
Type definitions from a JSON sample or an API response.
Refactors with a clear rule. “Replace all useEffect data fetching in this folder with React Query.” That kind of thing.
Error messages and logs. Making them actually useful.
Glue code. Adapters, serializers, that one util that maps A to B.

If the task has a clear shape and the answer is mostly mechanical → delegate it.

What I Never Delegate

This is where most people get burned. Confident wrong answers look identical to confident right ones until production breaks at 2am.

I never delegate:

Architecture decisions. “Should this be a queue or a cron?” is my call. I might use Claude to compare options, but the decision is mine.
Security boundaries. Auth, permissions, anything touching tokens or PII.
Naming. Names carry meaning across years. AI naming is generic by default.
Business logic I don’t fully understand yet. If I can’t explain it, I can’t review it. If I can’t review it, I shouldn’t ship it.
The first version of anything new. I write it badly first. Then I improve it with Claude. Reverse order = code I don’t own.

My Actual Workflow

Here’s the loop that works for me:

1. Plan before you prompt

Before touching the keyboard, I write 3-5 bullets:

- Add a /reports endpoint
- Returns last 30 days of transactions, grouped by week
- Uses existing TransactionService
- Cache for 5 min
- Add integration test

Then I hand that to Claude. Not “build me a reports endpoint.”
The difference in output quality is wild.

2. Small surface area > big asks

I’d rather run Claude 5 times on focused changes than once on “refactor this whole module.”

Why? The diff is the review. A 30-line diff I can read. A 500-line diff I’ll skim and miss things.

3. Read the diff. Always.

I treat every Claude commit like a PR from a junior dev who’s smart, fast, and occasionally hallucinates a function that doesn’t exist.

That’s it. That’s the trick.

4. When stuck, describe the symptom

Bad prompt:

“Fix the auth middleware, I think the JWT verification is wrong.”

Good prompt:

“Users are getting 401 on the second request after login. First request works. Same token. Here’s the middleware code.”

Let Claude diagnose. You’d be surprised how often your guess about the cause was wrong.

Common Mistakes (That I Made)

Mistake	What to do instead
Asking it to “improve” code	Be specific: “extract the validation into a separate function, add types”.
Letting it touch 10 files	Constrain scope. One concern, one prompt.
Trusting confident answers	If you can’t explain why it works, you can’t ship it.
Skipping the plan step	30 seconds of planning saves 10 minutes of fixing.
Using it for things you suck at	Worst case. You can’t review what you don’t understand. Learn first, delegate next.

Pro Tips

Keep a running file with project context. A CLAUDE.md or similar with your conventions, stack quirks, “we don’t use X because Y.” Saves you from explaining the same thing every session.
Use it for code review on yourself. “Review this function as if you were the most pedantic senior on the team.” Catches things you missed.
Don’t fight its style — fight your own bad prompts. 90% of bad output is a vague prompt.
Stop and write. If you’ve prompted 4 times and it’s still wrong, you write the next iteration. Sometimes the fastest path is your own keyboard.

Wrapping Up

The shift wasn’t “AI writes my code now.”
The shift was: I spend more time deciding what to build and reviewing what got built, and less time typing the obvious parts.

That’s it. That’s the whole post.

If you’re new to coding with Claude, start small:

Pick one task today that’s mostly mechanical.
Write the plan in 5 bullets.
Hand it over.
Read the diff carefully.

Repeat for two weeks. You’ll find your own rhythm.

⚡ Bonus Tip

Track the time you spend on tasks for one week without AI, then one week with AI but using the workflow above.

The number that should drop isn’t “time to write code.”
It’s time from idea to shipped.

If that number isn’t going down, the workflow is wrong — not the tool. 🚀