How we use Claude Code in production

By Max Ikaheimo

October 1st, 2026

AI coding tools have changed how fast software can be built. They have also made it easy to produce code that works in a demo and falls apart in production, because nobody on the team really understands it.

We use Claude Code every day on client projects, including the platform we built for Laturikotiin.fi. This post describes how we use it, and the rules that keep it from turning into vibe coding.

The short version

Developers scope the work, write the task specifications and divide the work into phases. Claude Code implements one phase at a time. Work is committed between phases, and a developer reviews and tests every change before the next phase starts. The model writes code; it never decides what gets shipped.

1. Scoping and task specifications

Everything starts with a developer deciding what should be built and how it fits the existing architecture. That decision is written down as a task specification before Claude Code touches the codebase.

A good specification describes the goal, the constraints, the parts of the codebase involved, what must not change, and how we'll know the task is done. The clearer the boundaries, the better the output. Vague instructions produce plausible-looking code that solves a slightly different problem.

2. Phases, not one big prompt

We don't ask for a whole feature in one go. The work is divided into phases that are small enough for a developer to review properly, each with its own definition of done.

Phasing keeps changes reviewable, makes problems visible early, and stops a wrong assumption in step one from spreading through everything that follows.

3. Commit between phases

Each finished phase is committed before the next one begins. The git history becomes a series of checkpoints: every change can be reviewed on its own, and if a phase goes in the wrong direction, we roll it back instead of untangling it from the rest of the work.

4. Human review and testing

A developer reads every diff. Claude Code doesn't approve its own work, and passing tests alone isn't enough to merge.

Testing follows the project's needs: unit tests, end-to-end tests, CI checks and manual QA are all part of the toolbox, and larger or riskier projects use more of them. The standard is the same whether a person or a model wrote the code.

What it changes in practice

The main difference is speed without lowering the bar. Laturikotiin.fi, an EV charger comparison and installation platform with a custom backend, lead handling and a content pipeline, was built by a two-person team in two months with this workflow.

The time saved goes into the parts that need human judgment: architecture, edge cases, review and testing.

Where we don't use it

Not every task benefits from AI. High-fidelity, detail-heavy work and complex, security-critical code are written and reviewed by our developers rather than generated. We explain why in when we don't use AI in software development.

Client data stays under agreement

Before a project starts, we agree which data may be processed by AI services and on what terms. If your policy rules out AI tools for a project, we don't use them. Read more on our AI development page, or see how this fits into our development services.