Writing fast is not shipping fast
However many agents are working, what it takes to reach production is unchanged. Only the part before the gate got quicker.
HOW WE RELEASE
Writing got faster. The gate did not move.
AI agents write more of our code than they used to, and the route a change takes to production is exactly the same. Branch, human review, automated tests, a staging environment, and a person who makes the call. However many agents we add, that route does not get shorter — it cannot.
THE ROUTE
How a change reaches production
Every change takes this route, whichever workstream it came from. Urgency does not buy a shortcut.
-
01
Cut a branch
One objective, one branch. The longer the piece of work, the more it stays apart from everything else.
-
02
Keep it small
Changes go out at a size a person can actually review. Many small ones rather than one large one.
-
03
A person reviews it and merges
Nothing lands that nobody read. Whether it fits the design and the conventions is decided here.
-
04
The test suite is the gate
Tests run at release time, and a release that does not pass does not go out. That is CI doing its job, not an AI making a judgement call.
-
05
Check it on staging
It runs the way production runs, and we use it. Some things are only visible on screen.
-
06
A person puts it live
Once it has been checked, a person makes the switch. The last button is pressed by a human.
WHY
Why we did not remove a single gate
When building gets faster, checking is what falls behind. So we kept every gate and narrowed what people spend their attention on instead.
Repetition belongs to machines
Checking the same things over and over is what a test suite is for. Human review is spent on whether it is right, not whether it runs.
Small out, small back
The smaller the change, the smaller the thing you have to undo when it goes wrong.
Measure after it ships
Every week, what was released is read against how the KPIs moved. What did not work does not stay.
WHERE WORK COMES FROM
Where the work comes from
So that nothing gets built on a hunch, the ways in are fixed. What is next gets chosen from what collects here.
See the team that runs this route-
Feature requests from users
What the people using it have asked for.
-
How the KPIs moved
The numbers the admin console team reads every week — including the ones that did not move.
-
Faults found in the logs
Errors are swept weekly, so a rising fault is found before anyone has to report it.
-
What reaches support
The thing behind the question, which is usually what needs fixing.
WHAT IS NOT HERE
What this page leaves out
We do not publish our environment layout, how deployment works, or what the tests actually assert. Those are worth protecting. The shape of the process is exactly as described here, and where a client needs more than that, we go through it with them directly.
LET'S TALK
We build your project the same way.
If you want to know how quality is held before anything is built, ask. We will work out where we can join the way your team already works.
Talk to us