Claude Code in practice: a structured account of a development assistant

Note revised on 25 May 2026. Article originally published in March 2026 — full rewrite.

Claude Code is a command-line development assistant designed by Anthropic, which interacts with a codebase through a dialogue in natural language. Its distinctive characteristic, compared with editor-integrated assistants, lies in its operation at the level of the entire project: it navigates the files, understands the architecture, executes commands, and proposes coherent modifications across several files simultaneously.

This note sets out what the practice of this tool allows us to assert after several months of regular use in varied professional contexts. It does not claim the objectivity of a comparative study; it sets out what sustained observation produces as operational observations, and what they call for in practice.

Four zones where practice observes a tangible gain

Four categories of task bring out a clearly observable gain, independently of project context.

Scaffolding and generation of structural code first. To create a new interface component, an API route, a database schema or a project configuration, the tool produces code coherent with the conventions of the existing project. Practice observes a substantial compression of production time on these repetitive tasks, without quality degradation of the result.

Multi-file refactoring next. Renaming a variable across dozens of files, migrating from one API to another, restructuring a module tree — operations historically heavy in human effort — are absorbed with high reliability. The developer retains the decision on the operation to conduct; execution is delegated.

Bug correction with investigation completes the list of strengths. Given a bug described in natural language, the assistant can navigate the code to identify the root cause, understand the relevant logic and propose a fix. This capacity for contextual navigation probably constitutes the tool's most distinctive strong point compared with editor-integrated assistants that see local context but not project context.

Test generation closes the list. Asking the tool to produce unit tests for a module provides a solid base that the developer then refines, rather than having to build everything from scratch. The resulting coverage is not perfect, it is sufficient to reach an acceptable threshold without devoting the substantial share of development time that previous practice required.

Three limitations practice brings out clearly

Four months of regular use also bring out three limitations the commercial discourse of publishers does not generally mention.

Loss of context on prolonged sessions first. Beyond a session of about two hours — the duration varies according to the density of the dialogue — the tool progressively loses the thread of the initial context. It can propose modifications inconsistent with what was decided at the start of the session, or forget architectural decisions taken earlier. This phenomenon is linked to the context-window mechanics of generative models, and it has no purely technical solution available today.

False confidence produced by the appearance of the result next. Generated code often compiles first time, follows the conventions of the language, presents a professional appearance that can disarm vigilance. This appearance hides subtle bugs, unaddressed security flaws, sub-optimal architectural choices that only careful review reveals. The developer who accepts without review accumulates a debt that shows up only later.

Complex architectures complete the list. For structuring choices — microservices breakdown, design of distributed systems, choice between competing patterns adapted to a specific context — the tool remains an assistant and not an architect. It proposes solutions that work in the general case, not always the most adapted to the project's particular context. This limitation does not resolve by better prompt formulation; it depends on a capacity for contextual judgement that generative systems do not yet carry.

Three distinctive practices of teams that derive durable value from it

Observation of several teams using the tool in different contexts brings out three practices that distinguish those deriving durable value from it.

Short sessions with a targeted objective first. Working in sessions of thirty to forty-five minutes, each with a single and precise objective, bypasses the context-loss limitation mentioned above. Once the objective is reached, closing the session and opening a new one preserves the quality of the dialogue. This discipline substantially changes the observable productivity of the tool.

Systematic code review next. Every modification produced by the assistant is subject to a review comparable to that conducted on a colleague's pull request. This review bears not only on syntax — the formal quality of the code is generally correct — but on logic, security, performance, and coherence with the existing architecture. This discipline preserves against false confidence.

Documentation of effective prompts completes the list. When a dialogue produces a quality result, keeping a trace of that dialogue constitutes a methodological capital that enriches with practice. A shared prompt library within a team transforms the individual use of a tool into a collective practice that improves over time.

The question of sovereignty over processed data

Using Claude Code implies sending the analysed code to the publisher's servers for processing. This characteristic calls for qualification on sensitive projects.

For projects touching data subject to confidentiality obligations — regulated sectors, professional obligations, strategic intellectual property — the question must be treated at initial framing. Anthropic, like other publishers of assistance tools, offers, depending on plans and enterprise contracts, contractual commitments relating to the processing and retention of data^[1]. The detail of these commitments varies according to the type of plan subscribed to; they do not constitute a general guarantee, and each organisation must conduct its own analysis to qualify what can be processed by a tool of this category, and what must fall to alternatives — open models executed on controlled infrastructure, for example — that present a different sovereignty profile.

This qualification is not an obstacle to adoption. It constitutes the normal work of integrating a tool into an organisation that takes its confidentiality obligations seriously.

The relative position in the tools market

The market for development assistance tools is not mature. Several categories of tools coexist, with different interaction models and operational profiles. Editor-integrated assistants excel at auto-completion and contextual suggestions but struggle to coordinate cross-file modifications. Editors natively assisted by models offer a fluid experience for teams working exclusively in a given environment, but tie the usage to a precise environment. Command-line tools like Claude Code offer polyvalence — operation with any editor, on any project, from any terminal — at the cost of a more marked learning curve for users accustomed to visual interfaces.

The choice between these categories depends on the team's context, the project type, and the practices already in place. No category is intrinsically superior to the others. Sustained practice of one brings out advantages the commercial discourse of publishers does not always capture, and limitations the same discourse minimises.

What this calls for in a Swiss SME

For a Swiss SME adopting an assistance tool in this category, three practical orientations emerge.

A pilot on a limited scope first. Rather than imposing a tool on the whole team, identify a motivated developer and a suitable project to experiment for a few weeks. Document the gains observed, the limitations encountered, the practices that work in the company's specific context. Then progressively expand, building on these observations.

Training support next. The practice of assistance tools is not natural for developers accustomed to a different working mode. Initial training, modest but structured, substantially accelerates the skills progression and avoids costly trial-and-error learning.

Integration into technical governance completes the list. Defining what can be delegated to the tool and what requires framed development, formalising code-review practice, documenting cases where regulatory compliance requires particular handling — these subjects deserve to be treated explicitly rather than left to individual initiative.

The adoption of an assistant like Claude Code does not transform a technical team overnight. It constitutes a gradual evolution that makes a disciplined team more productive, and that more starkly reveals the zones where professional rigour was already missing before the arrival of the tool.

Sources

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

Jérôme Deshaie is CEO of MCVA Consulting SA, a Swiss firm specialising in strategic consulting on artificial intelligence, based in Valais.