The NORKÄRŸM way of working, explained openly

How we build: crew coding with Claude Code

We call it crew coding. It is not "vibe coding". A person directs a crew of Claude Code agents. Each agent has a role, its work is reviewed by other agents, and everyone follows written rules. People make every decision that matters.

Read the full article: Crew coding with Claude Code →

The crew

On one workstation, several Claude Code sessions work at the same time. Each one takes care of one part: an app, a module or a project. Each works on its own copy of the project and in its own space on the computer, so sessions never step on each other's work or on the people's running environment.

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 a person's decision, and the versions that go public

Messages

between sessions, and each person's decision to whoever must act on it

Tax and legal

questions go to the person in charge and to our advisers

Security

keys and passwords, permissions, third-party software and reviews

Screens

the visual line: reviews every screen change

Tests

automatic tests that fail, quality checks and trial runs of the app in a test environment

Tools

for the agents: automatic alerts, small programs and work guides

Machine

memory, disk space and the cost of the computer

Housekeeping

whatever nobody is waiting for: forgotten work and weekly cleanup

Releases

the versions that go public

The rules that make it reliable

1. 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.
2. 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.
3. Every merge into our products needs a person's yes.
4. Heavy work (installs, builds, test suites, screenshots) goes through a shared queue, so the machine does not choke.
5. Every message between agents uses one format, with three types (information, question or blocker), and is signed, so a person can always tell who said what.
6. Lessons learned are written down where every agent can read them.

The forge

An internal console that builds apps with agents under human supervision.

A real example: this website

This page was rebuilt by a new Claude Code session. It first wrote a plan in a GitHub thread (an "issue"). The legal reviewer checked the legal notice, the screen reviewer checked the layout, and the security reviewer checked what would become public. Another session checked every fact against its source. A co-founder made the decisions from a phone.

Several machines, one way of working

The crew does not live on a single computer.

• Each co-founder's computer has its own crew of agents, with the same roles.
• A separate testing machine runs its own testing agent.
• Agents on different machines never talk to each other directly. They write in a GitHub thread (an "issue"), and every message is signed with who sent it and from which machine.
• People make the decisions from their phones.
• IKARYA Desktop already has remote access: one shared computer can serve several people, and it is designed so that none of them sees what the others are doing.

It works: it has been tested with two people on two devices.

The coordination app

A desktop app with a dashboard that keeps people and agents in step. It tells each person what is waiting for them, with a recommended option, and sends alerts to their phone. It tells agents when to summarise what they remember so they do not run out of memory, and puts sessions to sleep and wakes them up to save memory. A chat view is being built.

GitHub

GitHub holds it all together: plans in threads, reviews in change proposals, lessons in a shared thread, and the common memory between machines. The rules are in the crew section.