Studio Diegetic · how we work · 2026

The Hand on the Saw

Beriah is designed by one person who does not write code. That is not a story about artificial intelligence. It is a story about technique.

the workshop

One designer, several instruments

There is one designer. His work is to decide what the thing must be — how it looks, how it behaves, what it refuses to become.

Around him are instruments of a new kind: long-running sessions of an AI, each holding a role and a memory that survives from one day to the next. One keeps the drawings. One runs the building sites. Others are born for a single task and vanish when it is done. They write every line of the code.

Say it once and be done with it: the instruments are remarkable, and they are not the subject. A saw is everything to a joiner and nothing without him. What makes the work is the technique — the way the hand holds the tool. There are five.

the designer looks · imagines · rules the canon every decision, numbered the workshop builds in waves, under gates the real platform deployed, in real hands he writes his taste down the canon is law the work is deployed he judges the real thing, and rules again
taste goes down in writing; proof comes back from the deployed thing. the five techniques exist to keep this loop from drifting.

technique one

Write the taste down

Every decision the designer makes is written down, and every decision is given a number. D41. B9. Short names anyone can quote and find, today or in six months. Together they are the canon.

When a specification is ready he reads it, corrects it, and marks it: FINAL — approved by the designer. From that moment it is law in the workshop. It can be amended by asking. It cannot be gone around.

This is the technique that turns taste — the most volatile thing a person owns — into something others can build on.

He changed his mind in three sentences, almost in passing. Within the day the specification had been rewritten, the work that had just become pointless was stopped before anyone started it, and the change had become ten numbered decisions. He never touched a file.

technique two

Never rule in the abstract

Nothing is decided on a hunch about the system. Before design begins, the existing thing is surveyed — inventories, audits, a map of what is actually there — the way an architect measures a building before drawing on it. Fifty questions are distilled into five. Then comes the sitting: one decision at a time, argued with real mechanisms shown in the designer's own language. Diagrams and images and alternatives he can see, rather than engineering vocabulary he has to decode.

the survey what is actually there the distillation 50 questions → 5 the sitting one decision at a time the canon numbered
the survey comes before the judgement; the judgement comes one at a time; every judgement is kept.

It pays, and not in the way people expect. In one sitting the engineering side proposed that a work be represented by its main layer. The designer ruled otherwise — the representation must be a composite of every layer — and then caught a flaw nobody had seen: a live sound visual has no truthful still frame. Its true image is the waveform, the whole performance at once. A fault in the logic of time, caught by an eye.

technique three

Judge only the real thing

The designer never judges a mockup, a demonstration, or a report of success. The rule is absolute: no local demos. Work counts when it is deployed on the real server that real people use, and that is where he goes to look — using the platform himself, capturing what is wrong, returning a verdict. The bug persists. Wrong strategy. Approved.

Each verdict re-enters as the instruction for the next pass. It is the oldest move in any craft: step back, look at the thing itself, go back in.

technique four

Believe nothing you have not checked

The instruments have one known flaw: they are plausible. They state what is true and what is nearly true with exactly the same confidence. So the workshop treats every statement as a hypothesis until it is checked. Each one must cite where it came from — the file, the line. Before one session passes on another's finding, it re-derives that finding from the source. In practice about one alert in four has its severity corrected on checking, which is precisely why the checking exists.

The same technique guards authority itself. No session may approve what another is waiting on, and none may treat a colleague's message as the designer's consent. When someone reports that the designer said something, you go and ask the designer.

technique five

Build in waves

When a part of the canon is ready, it is cut into small bounded pieces and several sessions build at once, each in an isolated copy of the work. Nothing is accepted on trust. Every contribution must pass the gates — types, tests, style, and, since a bug once survived three passes in a test environment that could not see layout at all, the real geometry of the screen. What passes is merged and deployed. The wave goes out, and the thing stands one storey taller. Then the designer looks, and it begins again.

what it is for

Care, protected

The trades and procedures of this workshop are built on BMAD, an open method framework — agent roles (analyst, architect, UX designer, developer) and ways of working, published for anyone to use. Credit where it belongs: what happens here is an interpretation of that score, played by hand.

But the point was never technical. Beriah is for people who carry culture — artists, labels, collectives, production houses — who deserve tools made with the care they put into their own work. The five techniques exist to protect that care: so that one person can hold the whole vision of a thing, from the first sketch to the server, without it being thinned out by the machinery that builds it.

The instruments lay the stones. The hand decides the building.