Continuing development with an agent team

We have a deployed app and a pipeline that ships changes. We drove it with one assistant, one prompt at a time. That's the right speed for going from nothing to a first version.

Once the codebase is real and growing, that loose style starts to drift. The assistant forgets earlier decisions, skips tests, and calls work done too early. Once the first version is live, I move to a different way of working.

Specification-driven development

The habit that scales is to write a change down before anyone builds it.

Each feature starts as a short specification with three parts:

• a user story that says who wants the change and why
• the acceptance criteria that decide when it's done
• the test scenarios that prove it

We already have the raw material for this. The openapi.yaml from Part 3: OpenAPI spec from the frontend already specifies the API, and the test suites from Part 7: Real persistence with SQLite turn acceptance criteria into checks. A new feature extends the spec first, and the code follows.

A team of agents

One assistant that grooms, codes, tests, and approves in a single chat is where shortcuts creep in. The next step up gives each job to a separate agent with its own instructions and routes every task through a fixed process.

I run four roles:

• a product manager that turns a request into the specification above, then checks the result against the user story
• a software engineer that implements the code and writes the tests
• a QA tester that runs the tests and verifies each acceptance criterion with evidence
• an on-call engineer that watches the CI/CD pipeline after a push and fixes what breaks

An orchestrator session ties them together like a project manager and makes the commits.

Every task then moves through the same sequence, and no agent grades its own work:

• grooming, where the product manager writes the spec
• implementation, where the engineer builds it
• verification, where QA checks it against the acceptance criteria
• a rejection loop back to the engineer when a check fails
• final acceptance by the product manager, then a commit by the orchestrator

Keeping the writer and the approver separate is what stops an agent from declaring half-finished work done.

Built on what we already have

This way of working reuses what we already built:

• the product manager writes specifications against the same openapi.yaml
• QA runs the existing pytest and vitest suites to check them
• the on-call agent watches the GitHub Actions pipeline from Part 12: CI/CD with GitHub Actions

The deployment loop is already automated, so an approved change reaches the live site on its own.

You don't need the full setup to get the benefit. Even with one assistant, keep the discipline. Write the spec, implement it, verify it against the acceptance criteria, then commit. The AGENTS.md file from Part 4: FastAPI backend from the spec already holds the house rules, and a short PROCESS.md can hold the steps. I wrote up the full agent-team version, with the role files and the task flow, in I built an AI agent team for software.