Most weeks our studio log opens with a number. 144 changes. 239. 300.
People ask how a small studio does that across four products and a handful of client sites. The honest answer is AI does a lot of the typing... but that's the least interesting part. The number comes from the system around it. Here's how it actually works.
This isn't vibe coding
Let's get this out of the way, because the two get lumped together.
Vibe coding is typing "build me an invoicing app" into a chat, taking whatever comes back and shipping it because it seems to work. It's great for a weekend prototype. It's a terrible way to run software that moves other people's money.
What we do is AI-assisted engineering. The AI writes a lot of the code, but it works inside an engineering process: a written spec before anything gets built, tests that have to pass, a review on every change, a stronger review on anything risky, and a person deciding what ships and when. The AI is fast. The process is what makes it safe to be fast.
Everything below is that process.
The ticket is the spec
Everything starts as a ticket in Linear. Not a one-liner. A proper spec: what's wrong or missing, what "done" looks like, the files involved, and how we'll check it.
That sounds like overhead. It's the opposite. A clear ticket is what lets an AI agent build the right thing first time, and it means the decision lives somewhere other than a chat window. If it needs to outlive the conversation, it goes in the ticket.
When we're not sure a ticket is even true, and "it's broken" turns out to be "it was fixed last Tuesday" more often than you'd think, a scout checks the code first. It reads what actually runs, confirms the problem and writes the build spec. Small, obvious fixes skip that step and go straight to a builder with a two-line spec.
Builders, with limits
The building is done by AI agents working in our codebases through Claude Code. Each one takes a ticket, builds it, runs the relevant tests and stops at "pushed". No wandering off, no rewriting things nobody asked for.
The limits matter more than the agents:
- At most three builders at once. More than that and parallel changes to the same shared files start colliding, and every collision costs a full re-test. We merge in a fixed order and rebase the rest after each merge.
- Scoped tests while building, the full suite in CI. A builder re-running five thousand tests for every small fix is slow and pointless. CI is the authority.
- Stop when the useful work is done. An agent's output is the change, not a progress report.
Money gets a second pair of eyes
Every change gets reviewed before it ships. How hard depends on what it touches.
Anything involving money, signing, logins or keeping one customer's data away from another's gets an adversarial review. It's a separate, stronger model whose only job is to find how the change could go wrong: the rounding case, the race, the leak. Everything else gets a lighter review once it works. And anything touching money also gets a separate review before release, even when that makes for a quieter week.
That split is deliberate. Spending the heavy review everywhere would slow everything down. Spending it nowhere is how you end up writing an apology email.
Nine-minute deploys
Deploys take about nine minutes. That changes behaviour more than any tool does.
When a deploy takes half an hour, you batch things up. Big batches are harder to check and slower to reach anyone. At nine minutes, the small thing ships the moment it's ready. A lot of our weekly count is exactly that: small, checked changes going out one at a time.
Shipped isn't launched
Merged code isn't announced code. A feature can sit in the product quietly, switched off or unannounced, until the help docs, the product page and the feature itself all agree. Then we launch it.
After something ships, another agent reads what changed and writes the follow-up tickets: the marketing page to update, the help article to write. Otherwise we'd keep building and nobody would ever find out.
What it doesn't do
It doesn't replace judgement, and it isn't a shortcut around engineering. People decide what to build, write the specs, own every decision about customers and money, and choose when things launch. Every change is reviewed before it ships, in every product. The team is small, and everyone on it is doing work AI can't: design, client relationships, deciding what matters.
What it does do is take away the gap between deciding and done. That's where the 100+ changes come from.
If you want a product built this way for your industry, that's what we do.
— Daz
Consulting Inquiries
