How a Tiny Team Ships Like a Big One
100% of our code is written by AI. Here's the system that makes that boring.
From 12% to 100% AI-generated code in six months - and the four-layer operating model of specs, agents, AI review, and human gates that makes it safe.
In October of last year, 12% of the code we merged was AI-generated. By January it was 59%. Since April it has been 100% - every feature, every fix, every migration, every line.
When that number comes up in conversation, people usually picture someone typing "build the feature" into a chat box and merging whatever comes back. So most of this post is about the machinery that makes the real version far less exciting than that - and why boring was the goal.
How we ended up here
We're a small startup running a production AI platform for enterprise customers: a product surface, data pipelines, and cloud infrastructure that would keep a fifty-person engineering org busy. Hiring our way to fifty was never on the table, so at some point the honest options were to shrink the ambitions or to change how code gets made. We picked the second.
The first thing we learned is that the model was never the bottleneck. Our own trust was. Letting machines write everything only works if you can answer, concretely, how you keep control of what ships - and the answer we converged on wasn't a better prompt. It was four layers, each one handing work down and decisions up.
The operating model
Layer 1 - humans write and argue the specs. Spec-driven development is mandated here: a spec gets pushed, reviewed, and approved before implementation starts. We learned that the spec is the cheapest place in the whole pipeline to be wrong, so that's where we spend our human disagreement. By the time code is being written, the expensive questions have been settled.
Layer 2 - agents write the code. Claude, working in isolated branches with declared scopes, opens PRs the way any engineer would. This covers everything: features from approved specs, production fixes from the SRE fleet, preventive fixes from the QA agent, migrations, infrastructure.
Layer 3 - AI reviews every PR. A Claude reviewer, running on Amazon Bedrock, reviews each pull request against a severity taxonomy, with a TDD gate: a behavioral change without a test is an automatic blocker. Routine changes with no findings merge on AI approval alone. Anything classified as a major change always summons a human reviewer - the bot is not allowed to wave those through, no matter how clean the diff looks.
Layer 4 - humans merge. Branch protection means nothing reaches main without a person approving it. Every post in this series ends up arriving at this same gate, because everything else stands on it.
Around the loop, production monitoring and the daily QA agent feed new issues back into intake, and intake feeds specs - the loop closes on itself.
Real numbers
- AI-generated share of merged code: 12% (October) → 59% (January) → 100% (since April).
- 80% of PRs ship with only AI review - the other 20% are the ones the classifier decides are consequential enough to need human eyes.
- 6x developer productivity since January, measured by PRs shipped.
- 6 builders running the entire platform - product, data, and infrastructure.
One honest footnote: "100% written by AI" does not mean "0% written by humans" in effort. The hours didn't disappear; they moved up the stack, into specs, reviews, judgment calls, and escalations. Once in a while someone still takes the pen back for a gnarly problem, and when they do, their code goes through exactly the same review and merge gates as the agents'.
Where the humans sit
Most of the human weight sits at two gates. The spec gate moved our effort from writing code to deciding what should be true, which is where senior judgment was always most valuable anyway. The merge gate means every change, human or agent, ends with a person saying yes. Between the two sit the escalation paths, where agents are built to stop and ask rather than guess. Over six months the job here quietly changed from author to editor-in-chief, and nobody has asked for the old job back.
The map from here
This post is the zoom-out; the series is the anatomy. You've already met the SRE fleet and the QA agent. Coming up in this track: how trust in agents is engineered - dollar budgets, scope guards, and the right to say no; the deliberately boring deploy rails; the AI review bot in detail; the inner-loop tooling we built instead of a platform team; the intake pipeline that turns retro complaints into shipped code; MCP servers, from internal tool to product feature; and finally, what happened when we pointed the agents at ourselves. The other half of the calendar belongs to the product track - what all this machinery actually builds.
Steal this
Don't chase the percentage. Ours climbed on its own as the gates got trustworthy, and if we had pushed it directly before the review gate existed, we would only have shipped garbage faster. The order that worked for us: build the AI review gate first, enforce spec discipline second, and only then let agents take the pen for real work. Measure PRs shipped and defects escaping, not share of code generated.
Next week: the trust stack itself - what a dollar budget, a scope guard, and an agent's right to say "I need a human" look like in production. On Thursday, the product track: research agents that know when to stop.
This post is part of How a Tiny Team Ships Like a Big One, a series on how six builders run a production AI company. Building at Aithon - if this is how you want to work, talk to us.