How one engineer ships like a team

5,700 commits across 11 repositories in under eight months, with AI agents doing most of the typing. The process that keeps it maintainable.

For one client I built two products: backends in Go and Python, six web apps in TypeScript, the infrastructure under them. AI agents wrote most of the code. The obvious objection is that volume from agents means a codebase nobody can maintain, and without a process that is exactly what you get.

Typing speed was never the constraint. Keeping eleven repositories coherent is. These are the rules that do it.

1. The architecture is written down where the agent reads it

Every repository carries a short file of rules: how the layers stack, that only DTOs cross the HTTP edge, that migrations are the schema authority. An agent reads it before it touches anything, and a change that breaks a rule is rejected on that basis. Conventions that live in someone's head don't survive an agent; conventions in the repo do.

2. Design first, in a file

Any change bigger than a fix starts as a dated design document, then a plan. I approve the design; the agent implements the plan. There are about 45 of these across the repositories, and they are the reason I can answer "why is it like this" six months later.

3. Repositories talk through contracts, not memory

When the API changes, its OpenAPI schema is generated from source, not from a running server, and a handoff spec is written into the frontend's repository. The spec contains schemas and requirements, never implementation code: the receiving side knows its own codebase better. There it is checked against that repository's rules and turned into a plan.

Known hazards travel with the spec. Go marshals a nil slice as null, not [], so every spec that returns a list says so, and the frontends guard for it.

4. Frontends don't wait for backends

Screens are built against agreed contracts before the endpoint exists. A 404 from a planned endpoint renders a pending state instead of an error, and the screen lights up the day the backend ships.

5. Tests are the brake

The main API has 3,593 tests. The ones that matter most assert invariants instead of examples: after any billing flow, the account balance equals the sum of the ledger. And a release isn't done until production reports the commit that was pushed.

6. The workflow is a package

Deploying, reading production logs, scaffolding a module, auditing schemas: each is a versioned command in an internal plugin repository that every codebase installs. The second product inherited the first one's process on day one.

What I don't delegate

Deciding what to build. The design. Reading the diff. Production incidents. The agent types; I'm accountable for what ships.