19 Jun We let AI write our software. The discipline is in how we keep control.

Four AI superpowers, all sprinting for the lead. We would rather keep the freedom to switch between them than bet the company on one.

Most companies talking about AI in their codebase mean autocomplete. We mean something nearer the whole job: agents that read the repo, write the feature, compile it, run the tests, fix what broke, and commit the result, with a developer steering and reviewing throughout. That is an ordinary working day here. The biggest single feature we built this year was written almost entirely by machines.

None of this was true a few months ago. The change has come fast, and it has been radical: we have reshaped how we build around it, and a small team now gets through work at a rate that would have sounded made up a year ago. It is the closest thing to a superpower I have had in this job, and we are leaning into it hard.

How we made that safe to do, and how we kept ourselves free to switch AI vendors when we have to, is the rest of this.

Our biggest feature this year, built before breakfast

One of our engineers built the first version worth showing in about a week. Early mornings on holiday, before the family was up, with agents grinding away overnight while he slept. He has tidied and extended it in evenings and weekends since. It runs to about 30,000 lines of source now, and he typed almost none of them.

What it does is operate the product, rather than chat about it. It reads and rewrites any workflow you hand it, drives all 138 of our existing block types, runs the thing, reads the results back, and debugs and fixes its own mistakes. You can talk to it three ways: the chat panel in the app, a 28-tool interface for other software to call, or a plain REST API. It came together fast for a reason worth noting: it was designed before it was built, with roughly as many lines of design notes as code.

One caveat on the 30,000 lines. That is raw agent output. The reviewing, testing and hardening that turn it into something we would actually ship are still human work, and as I will get to, that step is the real bottleneck now. So this one sits in a private alpha, not in anyone’s hands yet.

Asked to “do the prep for this data”, the agent finds the raw files, works out their structure, and assembles the pipeline on the left while it reasons on the right. Here it is running on a Qwen model on local hardware, with nothing leaving the machine.

There is a twist worth a line. The harness the agent used to drive our IDE, to compile, test and commit, was itself built by agents over the same few weeks. We are building the tools that build the product the same way we build the product.

A different week, and a feature that shipped

Take one feature from one ordinary week. Insight Explorer answers questions about your data with queries and charts you can pull apart, and it writes the answer up as plain prose around them. An early tester found the hole: the prose quoted numbers, and nothing told you where those numbers came from. Why trust them? Four days later, in the next Rock release, every number and fact in that prose was live. Click a figure and you get the maths and the exact query behind it, while the text still reads as ordinary prose.
The objection came in on the Monday; it was tested, integrated and shipped by the Friday.

That came out of a normal week, not a crunch. On one developer’s two machines: 113 agent sessions, 44 on a frontier cloud model and 69 on local hardware, and about 159 hours of agents actually working, often two or three at once, some overnight. 440 commits, each held at a human gate before it could leave the machine, from maybe 900 typed instructions. The bill was the $200 subscription, flat.

One developer, two machines, one week: 44 cloud sessions, 69 local, every commit gated by a human, all on a flat $200 subscription.

Workflow Ninja, the big one above, is still a private alpha. This shipped to customers inside the week.

The sensitive code never left the building

Every agent runs in a sandbox. It can only see the parts of the codebase we have deliberately opened to it, it reaches the network only through a curated gate, and although it commits locally, it cannot push anything off the machine by itself. When it cannot reach the unexposed code, that is the box refusing, not the model choosing to be good.

You could watch this while Workflow Ninja was being built. We opened up sensitive source a piece at a time, each grant a logged decision. At one point the agent needed part of the data model we had not exposed. Rather than working around us, it stopped and said so, and we decided whether to open that door.

We can change sides overnight

Pick your mount. The same setup flies whichever AI you choose, so you can switch the moment the race changes.

This is where it gets strategic rather than just fast. We built the setup so the AI tool itself is swappable. The sandbox, the shared skill library and the machine interfaces work the same whether Claude Code, Codex, Gemini, OpenCode or Grok Build is in the driving seat. That took real work: one canonical set of instructions, composed per tool at launch, sitting on a single shared engine, so each tool’s own wrapper is a couple of hundred lines instead of a couple of thousand. Swap the tool and about three dozen shared skills come along unchanged.

The same goes one layer down, at the model. The identical agent can point at a frontier model in the US cloud, at open-weights models on GPUs we own, or at a provider in Europe or China. We have run our coding agents on Mistral’s Devstral, with mixed results so far, and briefly on a Qwen model on our own hardware, where they were genuinely good.

That matters because the ground keeps moving. Everyone sells AI sovereignty as keeping your data on your own premises. The half nobody mentions is keeping the ability to ship when your supplier cuts you off, prices you out, or gets export-controlled. If a US frontier model went dark tomorrow we would point the same agents at Mistral, or at Qwen on our own GPUs, and carry on. The rig that serves those local models wakes when an agent calls it and powers down when it is idle, so running them costs almost nothing at rest.

What does not work yet

Two things are not solved, and I would rather say so. Local open-weights models still are not good enough for our harder problems: they hit a ceiling on quality, not just speed, and the fix looks like more GPU rather than a cleverer small model, so for the difficult work we still route to the frontier cloud models. The other is review. Agents produce far more than one person can read carefully, so the safety of all this lives in human discipline today, not in a mechanism. We hold our own agents to the standard we sell to customers: auditable, evidence-backed, and reviewable rather than a black box.

Why we are telling you this

None of this is a method we are selling. We just think the teams that get good at this now, sandboxing the agents, staying swappable on models, keeping a human on the commit gate, are the ones who will not be caught out when the market reshuffles again. And it will. If you are building in the same direction, come and find us.