← Jince's Works

03 of 07

Running a rigorous build with AI as the engineering team

Product-owning an AI-built assistant end to end: five agents doing the engineering, specs approved before code, and one document allowed to answer each question.

Role
Solo project: product owner, directing five AI agents
Year
Ongoing since 2026
Tags
Product ownership · AI-native engineering · Spec-driven development
Read
2 min

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 a product that acts on people’s behalf in the real world. There, a shortcut has consequences outside the code.

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. With the design agent I shape an idea and stress-test it before it becomes a spec. With the PO agent I 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.

ME DESIGN PO · THE REGISTER FRONTEND BACKEND CONVERSATION
Two agents I work with directly, three that work from an approved spec.

One document per question

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
  • Issue tracker The status of one live defect
  • Constitution The rules everything obeys

Writing them is the easy part. Keeping two of them from claiming the same thing is the work. When a state document and a spec disagree, the spec wins, by rule.

Documents drift, including the ones meant to prevent drift. So nothing gets claimed without first being re-verified against the current state, and that rule is written into the documents themselves.

What I don’t delegate

It would be easy to let the agents run everything, so I wrote down what the PO agent decides and what it doesn’t.

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 code, change anything live, or decide on its own that something is worth building.

Every backlog item carries a rank and a reason: the specific cost of leaving it undone. A short list of decisions stays mine. The PO agent could probably answer any of them, but those are the calls that change the shape of everything downstream.

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


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

Let's work together.

jincemp@gmail.com