Tooling that writes the boring half

LLM-backed developer tooling for code generation, tests and documentation — plus the company-wide rollout that got engineers actually using it, and the working method I now build my own products with.

01/Context

Delivery teams were spending real time on work that is necessary and not interesting: scaffolding, test fixtures, documentation that goes stale the week it is written. The tooling targets that work specifically. The harder half of the project was adoption — a tool nobody trusts is worth nothing.

02/Constraints

Client code stays put: Different clients, different rules about what may leave the network. The tooling had to be deployable in configurations where nothing leaves.
Output is reviewed, never trusted: Generated code enters through the same review and CI gates as anything else. No path exists for it to skip them.
Cost is a design input: Model spend scales with usage. Prompt design, caching, and model selection were budget decisions, not implementation details.

03/Architecture

Task-shaped agents: Narrow agents per task — generate, test, document — each with a small tool surface and an explicit stopping condition, rather than one general assistant asked to do everything.
Context assembly: Retrieval over the repository builds the prompt from the code that is actually relevant. Most of the quality difference comes from this layer, not the model.
Evaluation: A regression set of real tasks runs against every prompt and model change, so a model swap is a measured decision instead of a hopeful one.

04/Outcome

Rolled out company-wide across delivery teams.
Model and prompt changes ship against a fixed evaluation set, so a swap is a measured decision rather than a hopeful one.
Deployable in client environments where code cannot leave the network.
The same working method is how I now build my own products: from settled requirements to a shipped app in weeks, not quarters.

All case studies Next — A contact centre with no data centre