Claude Code in Real Client Work — Workflows, MCP, and Where It Breaks

I've written about why the harness matters more than the model, about the open-source agent I run for my own work, and about letting agents touch real credentials. This post is the missing piece: what a coding agent actually looks like inside paid client work — Shopware projects, Nuxt storefronts, the unglamorous maintenance contracts. Claude Code specifically, because despite my documented reservations about closed harnesses, it's what sits in my terminal on most client projects. The MCP ecosystem and the plan-then-execute workflow earned that spot; the rest of this post is why, and where it still falls on its face. No hype, no doom — just what a year of daily use on billable work looks like.

The Workflows That Actually Hold Up

Plan mode before anything structural

The single biggest behavior change I made: for anything bigger than a one-file fix, I don't let the agent write code first. Claude Code's plan mode has the agent read the codebase and propose an approach, touching nothing until I approve. On a Shopware plugin that decorates three services and adds a scheduled task, the plan step routinely catches the thing that would have cost an hour — the agent wanting to override a service that should be decorated, or missing that a migration already covers half the schema. Reviewing a plan takes two minutes. Reviewing a 14-file diff built on a wrong assumption takes forty, and half the time you throw it away.

Small, scoped prompts beat ambitious ones

"Implement the wishlist feature" produces plausible-looking code that integrates with nothing. "Add a WishlistService with add/remove/list methods following the pattern in CartService, storage via the existing repository abstraction, unit tests mirroring CartServiceTest" produces something I can review in one pass.

The agent is excellent at transformation — take this known pattern, apply it there — and mediocre at invention under underspecified requirements. Same as a new mid-level dev, except the agent won't come to your desk and ask; it will confidently guess. So I front-load the specification and keep each task small enough that a wrong guess is cheap.

The agent runs the verification, not me

Every task ends with the agent executing the project's own checks: build, typecheck, lint, the relevant test subset. Not because I trust the agent's claim of "done" — precisely because I don't. An agent that says "tests pass" after actually running vitest run and pasting the output is a fundamentally different tool from one that says "this should work." It's also where agents quietly shine: they don't get bored. Mine will run the suite, read the failure, fix, re-run, five times in a row without the frustration-driven shortcuts a human takes at attempt four.

Review every diff like it came from a contractor you just hired

I read every AI diff before it lands — no exceptions, same rule as in the oh-my-pi post: leverage, not autonomy. What I look for has shifted, though. Syntax and logic errors are rare now. What I actually catch:

• Plausible-but-wrong API usage — a Shopware repository call that exists but ignores the version context, an inherited config the agent bypassed
• Silent scope creep — "while I was in there" refactors nobody asked for, which turn a reviewable diff into an unreviewable one
• Deleted safety — a try/catch or null check removed because the happy path didn't need it

Reviewing AI code is a distinct skill from reviewing human code. Humans make errors of carelessness; agents make errors of confident misunderstanding. You read for different smells.

MCP Is the Actual Game Changer

Everything above works with any decent agent. What made Claude Code specifically sticky in my client work is the Model Context Protocol — and not as an architecture diagram, but as a very mundane shift: the agent acts on real project state instead of whatever I pasted into the prompt.

Concretely, what's wired into my setup:

PhpStorm via MCP. The agent can query the IDE's index — find usages, symbol info, inspections, Symfony service definitions — instead of grepping and guessing. On a Shopware project with a few hundred services, "where is this actually wired up in the DI container" is an IDE-index question, not a text-search question. The agent asking PhpStorm gets the real answer; the agent grepping gets a plausible one. That distinction is the whole harness argument again, one layer up.

An SEO crawler. I maintain a crawler for site audits, and exposing it as an MCP server changed what "check the client's category pages" means. Previously: run crawl, export, paste fragments into a prompt, hope the relevant part made it in. Now the agent triggers the crawl, pulls the findings, and cross-references them against the actual templates in the repo — "these 30 URLs have a duplicated canonical, and here's the Twig block that generates it" in one loop. Live data, not a stale copy-paste.

Issue trackers. The agent reads the actual ticket — description, acceptance criteria, the comments where requirements really live — instead of my summary of it, and can write back a comment documenting what changed and how it was verified. Fewer transcription errors between "what the ticket says" and "what I told the agent."

The pattern across all three: before MCP, I was the integration layer, ferrying context in and results out by hand. Every ferry trip lost fidelity and cost time. Now the agent queries the source directly, and my job moves up a level — deciding what should happen, verifying it did.

One caveat that belongs in this section and not a footnote: every MCP server you attach is attack surface and context cost. Tool descriptions eat tokens on every request, and a server that can write to a client's issue tracker deserves the same skepticism as an agent that wants your passwords. I keep write-capable servers to the minimum and review what's enabled per project.

Where It Breaks

This is the section the vendor posts don't write.

Long sessions rot. Context compaction is real and it is lossy. Twenty minutes in, the agent remembers the architecture discussion. Two hours and one compaction later, it half-remembers — and doesn't know it half-remembers. The failure smells like a competent colleague who slept badly: subtly off decisions with full confidence. My mitigation is boring and effective: short sessions, one task each, and durable decisions written to a project instructions file (CLAUDE.md) instead of living in chat history. If it matters past this session, it goes in a file.

Agents confidently edit the wrong layer. My most frequent real-world failure in Shopware work: the fix lands in the wrong place. Compiled output instead of the source template. A vendor file instead of the plugin override. A core template copy instead of a proper extension — the exact anti-pattern I've written a whole post about avoiding. The code is often correct; the location is wrong, and wrong-layer fixes are insidious because they work until the next update wipes them out. Layering rules now live in every project's instructions file ("never edit vendor/, extend templates via sw_extends, decorate services, don't override"), and the wrong-layer check is a fixed item on my review pass.

"Done" is a claim, not a fact. An agent that believes it's done will say so in the same tone whether the tests pass or don't exist. The only fix is structural: hard verification gates that don't depend on self-assessment. Build must pass, typecheck must pass, tests must run — visibly, output in the transcript. Where the check's output and the agent's summary disagree, the output wins, every time.

Token discipline is margin discipline. As a freelancer, agent spend comes out of my margin, so waste is visible in a way it isn't on a corporate seat. The patterns are consistent: re-reading files from three turns ago, exploratory grepping in the main session, MCP servers loaded but unused, long sessions where compaction overhead compounds. What works: scoped tasks (again), pointing the agent at files instead of letting it search, cheaper models for mechanical work, subagents for codebase exploration so only the digest comes back. Same instinct as watching your query count on a database — the agent equivalent of an N+1 is real and costs actual money.

What I Tell Clients

The question comes up in most project conversations now, so here's my honest script.

What I promise: speed on well-specified work. When requirements are clear and the pattern is established — a new plugin following house conventions, a migration, systematic refactoring, test coverage for existing behavior — the agent-assisted version is meaningfully faster, and verification gets more thorough, not less, because the boring parts stop being rationed. I also promise transparency: AI-assisted is not a secret ingredient, and the client is entitled to know how their codebase gets built.

What I refuse to promise: unsupervised correctness. Nothing ships without my review — not because the output is usually wrong, but because sometimes it's wrong in exactly the confident, plausible way that survives a skim. The value I bill for was never typing speed; it's knowing what to build, recognizing when something is off, and standing behind the result. The agent amplifies the first and does nothing for the other two.

The framing that lands with non-technical clients: a very fast junior colleague with encyclopedic knowledge and no judgment about your business. Enormously useful, never unsupervised. Anyone selling you the unsupervised version is selling you their risk.

Where This Leaves Me

Still using two harnesses, still fine with that. Oh-my-pi for my own projects, where I control everything and want the open, model-agnostic setup; Claude Code where MCP integrations into client tooling — IDE, trackers, crawlers — pay their rent daily. The harness argument I made months ago has aged well, with a twist I didn't expect: in client work the harness that matters most isn't the edit format. It's the connective tissue to the systems the project actually lives in.

The developers getting real value from these tools aren't the ones with the best prompts. They're the ones who redesigned their workflow around what agents are reliably good at — and built hard gates around what they're not.

If you're figuring out how AI-assisted development fits your team or project without betting the codebase on it, that's a conversation I'm happy to have.

Related Posts

• The Real Variable in AI Coding Isn't the Model — It's the Harness
• Oh My Pi — The Open-Source Coding Agent I Actually Use Every Day
• 1Password for Claude — Agents That Log In Without Seeing Your Password
• Shopware 6 Decoration Best Practices