I Type One Command.
20 AI Agents Handle the Rest.

I'm a product engineer at a Norwegian SaaS company. We build cloud-based financial reporting tools for Norwegian municipalities. My stack is C#, .NET 9, Angular, Azure, and microservices.

A few months ago, I got tired of how slow the story-to-PR cycle was. Not the coding part. The everything-around-coding part.

Reading a ticket. Figuring out which files to change. Writing tests after implementing. Manually checking security. Creating the PR description. Reviewing CodeRabbit comments one by one. Updating Swagger. Verifying the DB migration runs on real SQL Server.

Each of those tasks is maybe 10–20 minutes. Together, they eat your entire day. So I built a pipeline to handle all of it.

The Problem: Story-to-PR Is Expensive

Without the pipeline: Engineer reads ticket → figures out what to change → implements → writes tests → manually checks security → creates PR → reviewer finds issues → back to fix.

With the pipeline: You paste a story → agents brainstorm, plan, implement, test, lint, security-scan, E2E verify, and create the PR — pausing only at 3 key gates for your approval.

The agents also share a knowledge system. They get smarter with every merged PR.

The 20 Agents

I use 20 specialized agents. Each has one job. None of them try to do everything.

The number isn't the impressive part. The specialization is.

The Model Selection Strategy

This is the decision I'm most proud of. Not every task needs the same model. Using Opus for everything is slow and expensive. Using Haiku for everything produces bad output. So I matched models to tasks:

The result: the pipeline is faster than using one model everywhere, and output quality is better because each agent gets a model tuned to what it actually needs to do.

Parallel Execution

This is where the pipeline gets genuinely fast.

Phase 3 — Simultaneous: The code-agent implements all changes while the security-agent reviews the plan for security issues. Security doesn't wait for code — it reviews what the code intends to do while it's being written.

Phase 4 — 6 quality gates run simultaneously (after build passes): unit tests, lint, integration tests, API contract, DB migration static review, and DB migration applied to real LocalDB. Wall-clock time = the slowest single gate. Not the sum of all six.

Phase 5 — Simultaneous: The playwright-agent generates and runs E2E tests while the security-agent runs a second pass on the actual written code — checking [Authorize] on new endpoints, TenantId filters in queries, [innerHTML] bindings in Angular.

The Knowledge System

This is what makes the pipeline get smarter over time. Four files feed every agent:

KNOWLEDGE.md — Technical conventions discovered from previous stories. Architecture rules, pitfalls, patterns.

DOMAIN.md — Business rules. What an "org" is in our system. Norwegian terminology. UI conventions. Written by engineers and SMEs.

DECISIONS.md — Standing decisions. New FK columns are always nullable. Org dropdowns always use getOrganisationGridData(). Pre-approved — agents never ask about them again.

Branch-level knowledge — Every agent logs findings during the pipeline. After merge, the knowledge-agent extracts reusable learnings and folds them into the master KNOWLEDGE.md.

Real examples of what gets captured:

Every merged PR makes the next story faster. Brainstorm questions shrink. Plan quality improves. The pipeline genuinely learns.

The 3 Human Gates

I didn't want zero human involvement. The goal is human involvement at the right moments — not spread across every step.

Gate 1 — Brainstorm: The brainstorm-agent returns 0–2 clarifying questions. Most are already answered by DOMAIN.md and DECISIONS.md. You answer the open ones, or say "use defaults."

Gate 2 — Plan: The plan-agent shows a file-by-file list and acceptance criteria. You verify it matches your intent before a single line of code is written.

Gate 3 — Fix approval: If a quality gate fails, the auto-fix-agent explains: what failed, the root cause, the proposed fix, and the risk level. You decide per issue.

The Coverage Report a PM Can Actually Read

The coverage-agent doesn't just report percentages. It works with the mutation-agent (which runs Stryker on changed code) to score whether the tests have teeth — would they fail if the logic were wrong?

Then it files a single Azure DevOps work item. Not a coverage dump. A human-readable scenario catalog:

Numbers and test names live in a small appendix. The body reads as product behaviour. A PM can open it and understand what's covered without knowing what NUnit is.

How to Use It

Three commands:

/story <description>
Kick off the full pipeline. Paste the Jira ticket, user story,
or plain description. Runs until PR is created.

/consolidate
After PR merge — extracts reusable learnings, updates master
KNOWLEDGE.md, archives the branch folder.

/address-review
After CodeRabbit comments — triages, fixes, and resolves threads.

Real example of a /story input:

That's it. The pipeline does the rest.

What I Learned

Specialization beats generalization. One agent trying to do everything produces mediocre output. Twenty agents each doing one thing produces something you can actually trust.

Parallel execution changes the game. Running 6 quality gates simultaneously instead of sequentially cut my wait time dramatically. Think about your pipeline — which steps can run at the same time?

The knowledge system is the real moat. The agents are replaceable. The accumulated knowledge in KNOWLEDGE.md, DOMAIN.md, and DECISIONS.md is not. That's what makes this pipeline better every time.

Human gates matter. Zero human involvement is not the goal. The goal is human involvement at the right points — decisions only a human should make — and automation everywhere else.

You don't need to be an ML engineer. Every agent here uses Claude through the Anthropic API. No model training. No Python. If you understand your codebase and can describe what each step should do, you can build something like this.