Crew coding: how we build with a crew of Claude Code agents

At NORKÄRŸM we build all our products with Claude Code. We do not use one agent that does everything. We use a crew: many sessions at the same time, each with one job, reviewed by others, and following written rules. We call it crew coding. It is not "vibe coding": there are roles, reviewers and rules.

One session, one lane

On one computer, more than twenty Claude Code sessions work at the same time. Each one owns a lane: an app, a module or a repository.

Each session works in its own folder (a git worktree) and its own range of ports. So no session touches another session's files, or the environment where the people work.

The Claude Code documentation explains how to run parallel sessions with worktrees so that edits do not collide. We took that recipe and applied it to a whole team.

The coordinating sessions

A few sessions do not build product. They coordinate, and each one is named after its role. None of them governs: they watch, warn, route work, or carry out what a person decided.

• Dashboard — what is waiting for the person, and releases to production.
• Messages — between sessions, and the person's decisions to whoever must act on them.
• Tax and legal — questions taken to the person in charge and to our advisers.
• Security — secrets, permissions, dependencies and audits.
• Screens — the visual line: reviews every screen change.
• Tests — failing CI, test gates and click-through tests on staging.
• Tools — for the agents: hooks, scripts and skills.
• Machine — memory, disk, ports and cost.
• Upkeep — whatever nobody is waiting for: forgotten work and weekly cleanup.
• Releases — versions.

The rules that make it reliable

• The first rule: do not make things up. An agent that is not sure asks whoever knows. "I don't know" is a good answer.
• Plan before code. A new feature, screen or permission starts with a short written plan. The screen, security and legal reviewers read it at the same time, before any code exists.
• Every merge into our products needs a person's yes.
• Heavy work (installs, builds, test suites, screenshots) goes through a shared queue, so the machine does not choke.
• Every message between agents uses one format (INFO, QUESTION or BLOCKER) and is signed, so a person can always tell who said what.
• Lessons learned are written down where every agent can read them.

What a person always does

Some things no agent does on its own: deciding that work is merged or published, promoting a version, making product and money decisions, and handing out secrets. The agents prepare the work, test it and explain it. The decision belongs to a person.

The Claude Code documentation recommends planning before editing. We add one thing: different reviewers read the plan at the same time, and a person decides.