The Target Pipeline
An agent at each step. A named person at each gate.
Requirement to UAT-ready
Blue = agent work · Teal = human gate · Red = permanently off limits
1
Spec
Requirement or circular becomes a structured spec with acceptance criteria.
✓
PO approves
Scope and acceptance criteria confirmed before work starts.
2
Design & change map
Which services, React components, database logic and endpoints.
✓
Tech lead signs
Design and API contract approved.
3
Build
Backend, React and database changes drafted on a branch. Reuse before writing new.
4
Self-review
Review agent checks standards, security and the change map before a human sees it.
✓
Dev commits
Developer reads it, fixes it, commits under their own name.
5
Test
Cases per acceptance criterion. Golden datasets if critical logic changed.
✓
QA + domain owner
QA validates. Domain owner signs anything in the restricted zone.
6
Release pack
What changed, what to test, how to roll back. Deploy to your UAT.
✓
UAT sign-off
Human decision, with a name on it.
✗
No auto-deploy
No agent deploys, merges to protected branches, or runs DDL. Ever.
How a Change Flows walks one real request through all fourteen agents, with the artefact each one produces.
Who Approves What
Written down, so nobody has to remember it
Gate map
| Artefact | Agent gives you | Human must | Owner |
|---|---|---|---|
| Change spec | Structured spec with acceptance criteria and open questions | Confirm scope and criteria before work starts | Product Owner |
| Design + change map | Affected services, React components, database logic, endpoints | Check nothing is missing. Approve the approach | Tech Lead |
| API contract | Contract diff and a breaking-change verdict | Approve any breaking change and who gets told | Tech Lead |
| Code | Draft on a feature branch, pre-reviewed by the review agent | Read it, change it, commit it under their own name | Developer + reviewer |
| Critical logic | Draft plus a golden-dataset comparison | Named owner signs. Golden dataset pass is mandatory | Domain Owner |
| Schema / migrations | Forward and rollback scripts | Review and run them. Agents never run DDL | DBA / Tech Lead |
| Test cases | Cases mapped to acceptance criteria | Check what is missing, mainly negative cases | QA Lead |
| Bug triage | Suspect files, likely cause, draft reproduction | Confirm severity and validity | QA Engineer |
| UAT pack | Change log, test checklist, rollback plan | Approve the pack. Sign off UAT | Release Manager |
Governance
Three things n.tasc needs beyond a standard AI policy
The restricted zone
- Business-critical calculations and rule engines = restricted
- Agents may draft. Merge needs a golden-dataset pass plus a named owner
- You can mark any module generation-prohibited, any time
- Every AI-assisted commit is tagged, so provenance is auditable
- Settle the client disclosure question in week one
Data handling
- No live client data, client codes or UCC data in agent context
- Schema only. No production database access at any point
- Test data is synthetic, never an extract of a real book
- Read-only credentials everywhere in the fleet
- Reviewed against client agreements in Stage 0
Audit and override
- Every agent run logged: prompt, input, output, timestamp
- Retention agreed jointly. Default 90 days
- Kill switch that disables any agent instantly, drilled in Stage 2
- No deploy, DDL or protected-branch merge rights for any agent
- Monthly access review, quarterly governance review
Four Rules Behind Every Choice Here
Net before accelerator
Stage 2 builds the regression net. Stage 3 turns on code generation. Do it the other way round on business-critical logic and you get an incident programme, not a speed programme.
Grounded in your code
Agents read your backend services, your React components, your database logic. No invented endpoints. No guessed columns. Reuse the existing service before writing a new one.
Prove it on one module
One module, real work, measured against a real baseline. If the numbers do not move we say so in Stage 4 and change approach.
Every step has an owner
Each agent has one output and one named human who approves it. That is what makes the fleet auditable and what stops trust drifting upward on its own.
Tooling
You have no tool constraints, so these are picked on fit
| Need | Recommendation | Why |
|---|---|---|
| Coding agent | Claude Code (terminal + IDE) | Full repo context, project instructions, permission scoping and hooks |
| Pipeline agents | Custom agents on the Claude API with MCP connectors | Single purpose, versioned next to the code they reason about |
| Memory | Markdown in the repo, vector index later | Reviewable in a PR from day one. Add a vector store when volume needs it |
| CI | Whatever you are on — Azure DevOps or GitHub Actions | The gain is enforcing gates, not migrating platforms mid-programme |
| Test stack | Jest / Vitest + React Testing Library for the UI, the backend's own test framework, Testcontainers for the DB | Real database behaviour in tests. Needed when logic sits in the database |
| Legacy coverage | Approval / snapshot testing | Pins current behaviour without writing a spec for legacy code first |
| Static analysis | ESLint on the React side plus the backend's linters and static analysis, wired into the same gate | Gives the review agent objective rules to check against, not opinions |
| UI regression | Playwright against the React UI | Covers the journeys operations users actually rely on |
| Work tracking | Jira or Azure Boards over MCP | Spec and triage agents read and draft tickets without retyping |
Read this next
How a Change Flows — one real requirement walked step by step through the whole fleet. It is the clearest picture of what the day-to-day actually looks like.