We operate several products simultaneously with a team that would have struggled to maintain one of them a few years ago. The question we get asked about that is which AI tools we use. It is the wrong question, or at least a much less interesting one than it sounds, because the tools are broadly available and the leverage is not in them.
The leverage is in everything around them. When code becomes cheap to produce, the cost of a product shifts to the things that were always there but used to be overshadowed: knowing whether a change is safe, getting it to production without ceremony, and finding out quickly when something breaks. Those are properties of a build system, not of a model.
One loop, many products
The temptation with several products is to let each one develop its own habits. Different test runners, different deploy steps, different conventions for the same problem. Each divergence is locally reasonable and collectively fatal, because the cost of context-switching is what actually limits how many things a small team can hold.
So we run one automation loop across all of them, with a dedicated architecture per product underneath. Same shape of pipeline, same commands, same release path, same conventions for how localized copy or environment config is organized. Nobody has to remember which product does it differently, because none of them do. The products differ where they should — a Flutter mobile client and a Nuxt web application have genuinely different needs — and are identical in the machinery around that difference.
The pipeline has to be trusted to be useful
A test suite that is usually right is not a safety mechanism. It is a suggestion, and suggestions get overridden under deadline pressure.
Ours runs unit, integration, and end-to-end before anything reaches production, and a red pipeline stops the release. The rule is absolute, which sounds rigid and is actually the point: a pipeline that can be overridden gets overridden, and the first override is always for a change that looked obviously safe. The value of the rule is entirely in it having no exceptions, because the moment it has one it stops being infrastructure and becomes a negotiation.
This matters more with AI in the loop, not less. If a model is producing a large share of the code, the test suite is doing more work than it used to — it is now the primary mechanism by which generated code is verified to do what was intended. Speed of generation without a proportional increase in verification is just an efficient way to ship defects.
Automate the part you do every time
The useful filter for what to automate is not "what takes the longest" but "what do we do identically every time, where doing it slightly differently would be a problem."
Deploys qualify. So does environment and secret handling, dependency updates, localization extraction, and the mechanical parts of review — formatting, lint, type checking, dependency audits — all of which should be resolved before a human looks at anything. A human reviewer reading a diff should be spending attention on whether the authorization check is correct, not on import order.
What does not qualify is the judgment itself. We have not found a way to automate the question of whether a design is right, and the attempts to approximate it mostly produce confident noise that costs more to evaluate than it saves. Automating mechanical work and preserving human attention for consequential decisions is the whole trade, and it collapses if you try to automate the second category too.
What this costs
It is worth being honest that this is a real investment and it competes directly with shipping features. Our internal tooling is not a side project; it gets designed, reviewed, and maintained like anything else, and there are weeks where it is the only thing getting built.
The return is not a productivity number I can quote with a straight face. It is a structural property: a small team can carry several products for years without the maintenance load growing faster than the team. That compounds quietly, and it is close to invisible until you try to do it without one.