Next steps

We have a deployed app and a pipeline that ships changes. We built 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 grows, this ad-hoc style causes problems. 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

A habit that works for larger projects is to write down each change 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 a start on this. The openapi.yaml from Part 4: OpenAPI spec from the frontend already specifies the API, and the test suites from Part 8: Real persistence with SQLite turn acceptance criteria into checks. For a new feature, we extend the spec first, then write the code.

A team of agents

One assistant that plans, codes, tests, and approves in a single chat skips steps. The next step is to give each job to a separate agent with its own instructions and route 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 coordinates them like a project manager and makes the commits.

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

• planning, where the product manager writes the spec
• implementation, where the engineer builds it
• verification, where QA checks it against the acceptance criteria
• sending the task 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 stops an agent from calling 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 13: CI/CD with GitHub Actions

The deployment 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, follow the same steps. Write the spec, implement it, verify it against the acceptance criteria, then commit. The AGENTS.md file from Part 2: Development environment already holds the project 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.