How I Use Claude Code for Real Client Work

Most posts about AI coding assistants are demos — a clean prompt, a clean result, wrapped up in three minutes. Real client work doesn't look like that. It looks like a locked file breaking your build at 6pm, an OAuth client mismatch that has nothing to do with the code you're writing, or a decade of version history you can't afford to lose in a migration. Here's what using Claude Code for that kind of work actually looks like.

The Git lock file that wasn't a Git problem

On one project — an ESOP management app built in Flutter — a teammate hit a strange error: a `.vsidx` file inside `.vs/` was locked and blocking commits. The instinctive fix is to chase the lock. The actual fix was simpler: that folder should never have been tracked in the first place. It's a Visual Studio index cache, regenerated locally, and pure noise in version control.

The fix was two commands — add `**/.vs/` to `.gitignore`, then untrack it with git rm -r --cached -f — but knowing to look there instead of debugging the lock itself is the part that saves the half hour. That's the pattern I keep running into: the AI tool isn't doing something I couldn't do, it's doing it in the time it takes to describe the problem instead of the time it takes to research it.

When the tool itself breaks

Not every session goes smoothly. I hit an OAuth login bug in Claude Code itself — a client ID mismatch that blocked authentication entirely. No amount of retrying the login flow fixed it. The workaround was switching to an API key instead of OAuth, which sidesteps the broken flow entirely.

Worth saying plainly: tools built on frontier AI are still young infrastructure. They break in ordinary software ways — auth bugs, edge cases, version mismatches — not in mysterious AI ways. Debugging them means treating them like any other piece of software you depend on, not like magic that either works or doesn't.

Planning a migration you can't get wrong

The highest-stakes use case wasn't a quick fix — it was planning a TFVC-to-Azure-DevOps-Git migration using git-tfs, for a codebase with real history that couldn't be lost. Here the value wasn't code generation at all. It was working through a two-phase approach: a background historical clone that runs without disrupting anyone, followed by a short, deliberate freeze-and-cutover window where the risk is concentrated and minimized.

That's planning work, not typing work. Claude Code was useful for stress-testing the plan — asking what happens if the freeze window runs long, what the rollback looks like, whether the full history actually survives the conversion — before touching a single production repository.

What this adds up to

None of these are the "write me a function" use case people default to when they think about AI coding tools. They're closer to having a second engineer who's read the error message already, who doesn't get tired of explaining `.gitignore` patterns, and who's available at 6pm when the deploy is broken and everyone else on a twelve-person team is already stretched thin.

That's the actual return on these tools for a company our size — not replacing engineering judgment, but removing the tax of context-switching between "I run the business" and "I need to fix this specific broken thing right now."