Eight Chambers for One Feature: How Software Development with AI Agents Actually Works

There are canals where ships climb a staircase. Not as a figure of speech: a real staircase made of water basins, one above the other, each separated from the next by a gate. The ship enters the lowest chamber, the gate behind it closes, water flows in, the ship rises a few metres. Only then does the gate ahead open, and the whole thing starts again.

The most important rule of the arrangement is one you never see: the two gates of a chamber are never open at the same time. Forget one, and half the waterway drains away with the ship left sitting in the mud. The entire construction exists for a single reason. It breaks one large difference in height into small steps, each of which is completed on its own.

I thought about that image when I first wrote down how software gets built at referro.ai. It is a startup I am involved in, and AI agents write the vast majority of the code there. Not as a pilot, as regular operations. If you expect that to look chaotic, you are wrong — it looks like a staircase of locks.

Eight stations, three of them for humans

Every change to the product starts as a ticket. No ticket, no work. That sounds like bureaucracy until you notice what the rule prevents: someone capable of producing a hundred lines of code in seconds quietly adding something nobody ordered.

From there the ticket travels through fixed stations. First an agent writes a concept without touching a single line of code, and lists underneath it everything it cannot decide with confidence. A second run answers whatever the existing software can answer, citing file and line. Anything that is a genuine product or legal question stays open and waits for a human. Then comes an implementation plan with a file checklist and a table of binding values: exactly which label, exactly which threshold. Only then does anyone build.

After building, a fresh agent reviews in a separate session what the first one did. It does not know the first agent’s reasoning; it sees only the ticket, the plan and the result. In parallel the automated pipeline runs: formatting, types, security scans, database migrations, hundreds of tests. If it is red, nothing ships. Full stop.

Humans are involved at exactly three points. They release the ticket, they answer the open questions, and they accept what can be seen. The rest runs without them — and it runs overnight.

Why two gates are never open at once

The obvious reaction to a chain like this is: why so cumbersome? If the machine builds in minutes anyway, why not let it build and look afterwards?

Because the separation is the actual quality lever, not the speed in between.

The concept exists before a single line of code does. Misunderstandings become visible while they still live in a paragraph rather than in fourteen files. A misread ticket costs five minutes here and half a day three stations later.

Implementation and review run in separate sessions. That is the four-eyes principle, translated into a world without eyes. An agent reviewing its own work mostly finds confirmation. An agent that sees only the brief and the result finds the missing English translation.

And the plan is the yardstick. Implementation and review tick off the same checklist. That makes it objectively verifiable whether what was ordered actually got built. It is the difference between “looks good” and “is complete”.

Both gates open at once would mean building and checking at the same time. Feels efficient. Drains the canal.

The agent only sees what has been written down

Now the part I consider most underrated, and it is about data.

An agent has no corridor knowledge. It was present at no decision, it knows no grown convention, and it has no idea why a database field is named the way it is. What is not written down does not exist for it. That is why this project keeps a small, binding set of rules in the repository: which statuses a record may pass through, which role may see what, how consent is handled, how key figures are calculated. Where the code contradicts that collection, the collection wins. It can only be changed through a specially marked ticket that a human flagged as such.

This is not documentation romanticism, it is a plain observation: the context you hand an AI is its ceiling. You know the same mechanism from data. An AI perceives only what is delivered to it, just faster and at greater scale. A company whose rules live inside four people’s heads cannot deploy agents sensibly. Not because the technology is missing — because the sensory system is.

The good news: this effort pays twice. Written rules help the agent and the next human equally.

And now the asterisks

I do not want to paint this prettier than it is.

The bottleneck does not disappear, it moves. When concept, plan, code, tests and review all run overnight, everything backs up in front of the last chamber: human acceptance. That is precisely why purely technical changes go straight through after review, and only user-visible ones land with a person. The bottleneck gets protected like a lock everyone has to pass through.

Agents make mistakes, regularly. The process is not built to prevent that but to make it visible early. A review without findings is the normal case, not evidence of sloppiness. A ticket that comes back from acceptance is not a process failure, it is the process doing its job.

And sometimes the pipeline is red, and then delivery stops. That is inconvenient and correct. The one rule that is never negotiable: nothing gets made green by switching off the check.

What this means for your company

If you are thinking about AI in software development, the interesting question is not which model writes the best code. The models are good enough, and they will be better next year without you doing anything. The interesting question is a different one: can you specify your work precisely enough that a very fast, very well-read new colleague could start without asking a single question? And have you built chambers in which each step is completed on its own?

Business leads, people and technology enable. Here the first half turns unusually literal: what is not in the brief does not get built.

The staircase of locks makes no single ship faster. It makes the difference in height navigable in the first place.

← Back to all posts