How we build at Cook.ai

We build an AI product with AI. That sounds like a slogan, so this post is the specifics: what the process actually is, what it costs us, and the rule that keeps it from producing a pile of plausible-looking broken code.

The one rule

A change is not finished until it is proven working in the running product.

Not "the tests pass." Not "the code looks right." Someone — or something — has opened the actual application, done the thing, and captured evidence that it happened.

Everything else in our process exists to make that rule cheap enough to enforce every time. It is the rule because it is the only defence against the specific failure mode of building with language models: code that is coherent, well-commented, review-friendly, and wrong.

A model will happily hand you a fix, an explanation of the fix, and a summary saying it verified the fix, having verified nothing. The only reliable filter is the running program.

What the work looks like

Most changes here are made by an agent working inside its own isolated copy of the repository, with a human deciding what should be built and whether the result is acceptable.

Several of those run at once. That has consequences most teams do not have to think about:

• Isolated copies of the repo, so two agents editing the same area cannot overwrite each other's work.
• Shared services they all point at, which means changes to the backend schema land for everyone at once and have to be treated as a shared resource, not a private sandbox.
• Automated checks that must pass before anything merges, because "the author looked at it carefully" is not a control you can rely on at this volume.

The gates

Three of them, and none is optional.

Types. The type checker must report zero errors, and suppressions are not an accepted way to reach zero. A type error here is usually the model having imagined an interface that does not exist, which is exactly the failure we want caught mechanically.

Design tokens. A checker rejects raw colours, arbitrary font sizes, one-off shadows and hand-typed spacing anywhere in the product's interface. Everything resolves to a named token. This is not neatness for its own sake: a model asked to "match the surrounding style" will approximate a colour by eye, and a hundred approximations is how a product stops looking like one product.

Proof. A screen recording or screenshots of the change working in the real application, against real data. This is the gate that catches the confident, wrong change, and it is the one we spend the most effort keeping cheap.

What we got wrong

Watch mode. We used to rebuild the AI service automatically on every file save. With several agents editing at once, that meant restarting the service every few minutes — which severed live conversations mid-reply. Users saw the work happen and never got an answer. We removed automatic reloading entirely and made deployment an explicit step. Slower to iterate, and correct.

A watchdog that killed the thing it was watching. A health-check process would forcibly restart the AI service when a probe timed out. Under load the probe timed out because the service was busy, so the watchdog killed a healthy, working process. It is gone.

Trusting a summary. Early on we accepted "I verified this" in an agent's own report. That is how a claim gets into a changelog with nothing behind it. Hence the third gate: the proof is an artifact, not a sentence.

What actually gets faster

Not typing. Typing was never the bottleneck.

What gets faster is the number of things that can be in flight at once, and how much of the boring surrounding work gets done — the migration written, the fallback handled, the empty state designed, the comment explaining the reason next to the code that needed it. Work that a human under time pressure skips.

The bottleneck moves to deciding what should exist and judging whether what came back is good. Those two jobs got harder and more valuable, which is roughly what we expected and still surprising to sit inside.

Why any of this is public

We sell software that does marketing work autonomously. The reasonable question from a buyer is: do these people know what they are doing when they let a model loose on something that matters?

This is the answer, in the form of the process we actually run, including the parts that went wrong. If we are asking anyone to let our agents touch their business, the least we can do is show our own.

FAQ

Do humans still write code here?

Yes — and more importantly, humans decide what gets built, what the constraints are, and whether a result is acceptable. The volume of typed characters is not the interesting part of the job any more.

How do you stop agents breaking each other's work?

Isolated copies of the repository per agent, mechanical checks on every change, and treating anything shared — the database, the deployed services — as a shared resource with explicit coordination rather than something an agent may replace on its own.

Is the proof requirement worth the time?

It is the cheapest gate we have relative to what it catches. A change that passes types and design checks and still does not work is common. There is no substitute for opening the product.