Running a rigorous build with AI as the engineering team

What this is

I built a personal assistant on my own, with five AI agents doing the engineering. This is how I ran it.

The problem

AI coding agents make it easy to ship fast, and just as easy to ship sloppy. Left alone, fast turns into untested and undocumented, and nobody is sure what’s actually live.

That’s a fair trade for a weekend project. It isn’t for an assistant that places real phone calls to real people, where a shortcut can produce a call that should never have happened.

The team

Five agents take a project from idea to shipped code.

• Design Research and elaboration
• PO Specs and orchestration
• Frontend The app interface
• Backend API and data
• Conversation Voice and chat

I work directly with two of them. The design agent, to shape an idea and stress-test it before it becomes a spec. The PO agent, to approve specs, rank the backlog, and make the calls that are mine.

The three build agents don’t come to me with questions. They execute a spec I’ve already approved.

One place for each answer

Every question about the project’s state has exactly one document allowed to answer it.

• Product doc What’s being built, why, and in what order
• Engineering doc Engineering state per feature, as it landed
• Handover doc Session state across parallel work
• Specs What a feature is meant to do
• GitHub issue The status of one live defect
• Constitution The rules everything obeys

Writing them is the easy part. The discipline is refusing to let two of them claim the same thing. When a state doc and a spec disagreed, the spec won, by rule, every time.

The product doc itself went stale once. An early draft had been written against a snapshot that ended up seventeen commits behind. I made “re-verify against the current state before claiming anything” a standing rule, and logged it in the document that had just broken it.

What I don’t delegate

It’s tempting to let the agents run. I wrote the boundary down instead.

The PO agent keeps the product doc true, turns requests into specs, ranks the backlog and says why, brings me genuine decisions, and makes the routine calls without asking.

It doesn’t merge, apply a migration, touch a dashboard, or decide on its own that something is worth building.

Every backlog item carries its reason, not just its rank — the specific cost of leaving it undone. And a short list of decisions stays mine alone. Not because the PO agent couldn’t guess an answer, but because some calls change the shape of everything downstream.

A human approves before code ships. Anything irreversible stays human-gated.

Two things that caught me out

No safety net

For most of the build, CI only ran the build and update pipelines. Nothing ran the type-checker or the verification suite on every change, so whether the tests passed was a claim in a pull request rather than a fact.

A routine review turned up a typecheck that had been broken on the main branch for an unknown stretch of time. It’s a CI job now, running whether or not anyone remembers to ask for it.

Two agents reaching for the same number

The frontend, backend and conversation agents work on the same codebase in parallel. Two of them kept claiming the same next feature number, or the same migration number.

The fix was procedural rather than technical. The PO agent became the register everyone checks before naming the next thing.

Where it stands

A live product in daily use, where the behaviour that matters — who gets called, when, and with what consent — is covered by automated tests.

The backlog is honest about the gap between built and delivering value. Several features are finished code sitting behind a single switch, tracked openly as done but not turned on, rather than quietly counted as shipped.

---

There’s a companion case study on the assistant itself — same project, from the product side.