Claude Code: a field report on two real projects

Augmented production, in concrete terms, looks like this: the site you're reading this on — the complete redesign of mcva.ch — and FiscalDoc, the local application that manages my taxes, were both built with Claude Code. Not on autopilot. In dialogue, with net gains, avoidable time losses, and a discipline without which the tool disappoints. Here's what these two projects taught me.

Article published in March 2026, revised on May 25, 2026, updated on July 7, 2026.

Claude Code, what exactly is it?

Claude Code is a command-line development assistant, built by Anthropic, that works at the level of the entire project: it navigates through files, understands the architecture, executes commands, and modifies multiple files coherently.

The difference from editor-integrated assistants lies in this overall vision. An editor assistant sees the open file and completes the current line; Claude Code sees the project, its conventions, its dependencies. That's what allows it to carry out cross-cutting changes that a tool with local context cannot coordinate. The trade-off is a steeper learning curve for anyone who has never worked in a terminal — and neither category is superior in every situation.

What two real projects showed me

On the redesign of mcva.ch — a multilingual site with several dozen pages, in four languages, with structured data — the clearest gain came on structure. Creating a component, a route, a page template consistent with the project's conventions takes a few minutes of dialogue instead of a full work session. Then multi-file refactoring: renaming, migrating, restructuring dozens of files at once, with a reliability that surprised me. I keep the decision about the operation; I delegate the execution.

Bug fixing also stood out. Describing a symptom in natural language — "the language selector loses the current page" — is often enough for the tool to trace back to the root cause by navigating the code on its own. And test generation provides a solid base to refine, rather than a blank page.

FiscalDoc tells the other side of the story: a complete tool — document analysis, tax classification, search, local assistant — that took shape over three evenings of dialogue. I didn't write it; I talked it into existence. I described my needs, iterated, corrected. The full story is published in FiscalDoc, or replacing a SaaS with local AI.

Where the tool cost me time

Three limits appeared across these two projects, and none of them is trivial.

Context loss, first. Beyond about two hours of a session, the tool progressively loses the thread: it may suggest changes inconsistent with what was decided earlier, or forget an architectural constraint set at the start of the dialogue. This is a mechanic of generative models' context windows, with no purely technical fix today.

False confidence, next. The generated code often compiles on the first try and has a professional look that lowers your guard. That appearance can hide subtle bugs, unhandled edge cases, and questionable choices that only a careful review reveals. Accepting without reviewing means accumulating debt that only becomes visible later.

Architecture, finally. For structural choices, the tool suggests what works in the general case, not necessarily what fits your particular context. Those decisions remain mine, and no amount of better prompting changes that.

The discipline that makes the tool worthwhile

What I've stabilized across these two projects comes down to a few things — and they account for almost the entire result.

• Short sessions, one goal. Thirty to forty-five minutes, one precise task, then a fresh session. Dialogue quality collapses past that point; starting over costs less than catching up.
• Systematic review. Every change is reviewed like a colleague's contribution: logic, security, performance, consistency with the existing codebase. The formal polish of the code never excuses skipping this review.
• Written project instructions. An instructions file that the tool re-reads at every session — conventions, prohibitions, architecture — avoids repeating everything and banks what works. It's the documented prompt at project scale.

And what about code confidentiality?

Using Claude Code means sending the analyzed code to the vendor's servers for processing. For mcva.ch, a public showcase site, the question was quickly settled. For a business tool touching customer data or strategic know-how, it gets addressed during scoping: Anthropic's contractual commitments on data processing and retention vary depending on the plan subscribed^[1], and they don't replace your own analysis. For certain scopes, open models run on controlled infrastructure offer a different sovereignty profile — a trade-off I systematically raise at the start of any custom solution project.

What this changes for a Swiss SME

The most interesting part goes beyond my own case. This kind of tooling lowers the cost of producing software to the point of bringing custom development back within reach of organizations that thought themselves excluded from it — that's the core of what I offer in solutions, and the reason the overall framework is laid out in What should a Swiss SME do about AI in 2026?. The redesign of mcva.ch itself illustrates the first pillar of this logic: sites designed to be found and cited, produced with this same tooling.

For a team, adoption follows a reasonable path: a pilot on a limited scope with a motivated developer, short but structured training, then explicit technical governance — what can be delegated to the tool, what requires review, what falls under regulatory constraints. None of this transforms a team overnight. The tool makes a disciplined team more productive, and it more starkly exposes the places where rigor was already missing.

Key takeaways

— Claude Code works at the level of the entire project; that's its distinctive strength over editor-integrated assistants. — The gains are real on structure, refactoring, and bug investigation; human review remains non-negotiable. — Short sessions, systematic review, written project instructions: discipline matters more than the tool.

FAQ

Do you need to know how to code to use Claude Code? For exploring and prototyping, no: dialogue is enough to produce something that works. For a product meant for real users, someone needs to be able to review and assess the resulting code. I detailed that boundary in my article on vibe coding and prototyping.

Does my code go to the vendor? Yes: the analyzed code is processed on Anthropic's servers. Processing and retention commitments vary by plan and are not a blanket guarantee. For sensitive code, do the analysis before adopting the tool, or evaluate models run on your own infrastructure.

Does Claude Code replace a developer or a service provider? It compresses execution; judgment — architecture, trade-offs, security, accountability — remains human. A competent, well-equipped person produces significantly more than before. An organization without review discipline mostly produces debt, faster.

How much does it cost? The tool runs on a subscription with the vendor, roughly a few dozen to a few hundred francs per month depending on usage intensity. Set against the execution time saved on a real project, that line item is marginal. The real cost is review time — and that's the last place to cut corners.

And for your own software projects? The AI Usage Diagnostic: sixty minutes to map your real workflows, identify what deserves custom development, what stays SaaS, and what doesn't need AI at all. Book a diagnostic

Sources

[1] Anthropic, Claude Code documentation — CLI usage. docs.anthropic.com/en/docs/claude-code/cli-usage [↩]

Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.