$3a
A single reviewer scanning backend code sequentially faces an impossible trade-off: dive deep into query optimization and miss async correctness, or audit security and miss connection pool exhaustion. Real backend performance teams don't work this way — they assign specialists. A database engineer profiles query plans while a security engineer examines trust boundaries while a platform engineer evaluates async health — all simultaneously, all deeply, all independently.
This skill replicates that model. Instead of one agent juggling eight cognitive domains, it deploys eight dedicated specialist sub-agents — each with deep focus on their domain — running in parallel and reporting back to a Master Orchestrator Agent that consolidates, cross-correlates, and delivers a unified optimization verdict.
The most dangerous backend failures span multiple domains simultaneously — a synchronous blocking DB call inside an async endpoint that also lacks connection pooling and has no timeout. Only cross-correlation catches these compound failures.
These are not suggestions. Every agent enforces these as absolute rules:
| Standard | Rule |
|---|---|
| Blocking calls in async endpoints | 🚫 Never acceptable — offload to executor or use async equivalent |
| Raw SQL string formatting | 🚫 Never acceptable — use ORM or text() with bound params |
| N+1 query patterns | 🚫 Never acceptable — use explicit eager loading strategies |
| Unindexed foreign keys | 🚫 Never acceptable — every FK must have a supporting index |
requests library in async context | 🚫 Never acceptable — use httpx.AsyncClient |
Base.metadata.create_all() in production | 🚫 Never acceptable — use Alembic migrations |
Secrets in source code or .env committed | 🚫 Never acceptable — use secrets manager or CI/CD secrets |
Bare except: swallowing errors | 🚫 Never acceptable — all exceptions must be handled and logged |
| Synchronous SQLAlchemy in async FastAPI | 🚫 Never acceptable — use AsyncSession with asyncpg |
print() in production code | 🚫 Never acceptable — use structured logging |
Async SQLAlchemy with asyncpg | ✅ Mandatory for all async FastAPI applications |
Pydantic BaseSettings for config | ✅ Mandatory — no scattered os.environ.get() |
Depends() for shared resources | ✅ Mandatory — no direct instantiation in route handlers |
| Alembic for all schema changes | ✅ Mandatory — no manual schema modifications |
pool_pre_ping=True on engine | ✅ Mandatory — all production database engines |
| Stateful process memory (sessions, cache) | 🚫 Never acceptable — externalize to Redis for horizontal scaling |
| Direct PG connections at >3 instances | 🚫 Never acceptable — use PgBouncer for connection multiplexing |
┌──────────────────────────────────┐
│ MASTER ORCHESTRATOR │
│ AGENT │
│ │
│ - Receives the backend code │
│ - Dispatches to sub-agents │
│ - Collects all findings │
│ - Cross-correlates issues │
│ - Synthesizes final report │
└───────────────┬──────────────────┘
│
┌──────────┬──────────┬──────────┬───┼────┬──────────┬──────────┬──────────┐
│ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
┌──────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌──────┐ ┌──────────┐ ┌──────┐ ┌──────────┐
│PERF │ │ DB & │ │ API │ │SECURITY│ │ASYNC │ │ INFRA │ │PROD │ │ SCALE & │
│AGENT │ │ ORM │ │DESIGN │ │ AGENT │ │AGENT │ │ AGENT │ │READY │ │ LOAD │
│ │ │ AGENT │ │ AGENT │ │ │ │ │ │ │ │AGENT │ │ AGENT │
└──────┘ └────────┘ └────────┘ └────────┘ └──────┘ └──────────┘ └──────┘ └──────────┘
│ │ │ │ │ │ │ │
└──────────┴──────────┴──────────┴───┬────┴──────────┴──────────┴──────────┘
│
┌───────────────▼──────────────┐
│ UNIFIED FINAL REPORT │
└──────────────────────────────┘
Each sub-agent has a deep-dive reference file in the references/ directory. Read only the relevant agent file(s) when you need the full checklist.
Before dispatching, the Orchestrator must understand the backend stack:
Session vs. AsyncSession; driver (psycopg2 vs. asyncpg)model_config, and serialization methodsBackgroundTasks, Celery, ARQ, or noneDispatch the code simultaneously to all eight specialist sub-agents. Each receives:
Each sub-agent explores exclusively within its domain. Read the agent's reference file in references/ for the full exploration checklist:
| Agent | Reference File | Domain |
|---|---|---|
| ⚡ Performance Agent | references/performance-agent.md | Endpoint latency, serialization, caching strategy, memory utilization |
| 🗄️ DB & ORM Agent | references/db-orm-agent.md | N+1 queries, query optimization, async SQLAlchemy, schema design, transactions, connection pools |
| 🔌 API Design Agent | references/api-design-agent.md | FastAPI endpoints, Pydantic models, HTTP correctness, OpenAPI, versioning |
| 🔐 Security Agent | references/security-agent.md | Auth, injection, data exposure, PostgreSQL security, dependency CVEs |
| ⚙️ Async & Concurrency Agent | references/async-concurrency-agent.md | Async correctness, blocking call detection, concurrency patterns, background tasks, event loop health |
| 🏗️ Infrastructure Agent | references/infrastructure-agent.md | Configuration, Docker, startup/shutdown, logging, observability, dependency management |
| 🚀 Production Readiness Agent | references/production-readiness-agent.md | Error handling, resilience, health checks, rate limiting, testing, migrations, monitoring |
| 🔄 Scalability & Load Agent | references/scalability-agent.md | Horizontal scaling, DB scaling, PgBouncer, read replicas, partitioning, worker sizing, backpressure, distributed locking, capacity planning |
Wait for all sub-agents to return structured findings. Each returns a categorized list with: severity, category, file/line location, description, current pattern, and recommended fix with code.
This is where the Orchestrator earns its role. Look for:
| Compound Pattern | Agents Involved | Why It's Critical |
|---|---|---|
| Sync DB in async endpoint + no pool config | Async + DB + Infra | Event loop blocked, connections exhausted, no health checks |
| N+1 query + missing index + no cache | DB + Performance | DB collapse under real traffic — triple compounding |
| Missing auth + IDOR + no audit log | Security + API + Production | Unauthorized access with no forensic trail |
| No input validation + SQL injection | Security + API | Missing Pydantic model IS the vulnerability |
| No circuit breaker + no retry + no timeout | Production + Async + Infra | Single downstream failure cascades to full outage |
print() in prod + no structured logging + no tracing | Infra + Production | Silent failures with zero operational visibility |
Missing Alembic + create_all() in startup + no health check | Production + DB + Infra | Schema drift, destructive restarts, invisible failures |
| Large sync computation + no background task + no streaming | Performance + Async | Request timeout, worker exhaustion, client disconnection |
| In-memory state + no Redis + multiple instances | Scalability + Infra + Performance | Data inconsistency between instances, cache divergence, session loss on redeploy |
| No PgBouncer + high pool_size + >3 instances | Scalability + DB + Infra | Connection exhaustion crashes PostgreSQL — total service outage |
| No read replica + N+1 queries + no cache | Scalability + DB + Performance | Primary DB collapse under read-heavy traffic at scale |
| Single queue + heavy tasks + no priority | Scalability + Async + Production | Critical tasks starved behind long-running reports |
| No distributed lock + cron jobs + multiple instances | Scalability + Async + Production | Duplicate cron execution, data corruption, race conditions |
Severity elevation rules:
Assemble the Unified Final Report using the format below. Prioritize findings by cross-domain impact, then by severity.
Issue the final assessment and prioritized remediation roadmap.
Every blocking call, N+1 query, raw SQL, missing index, and un-migrated schema change — listed explicitly with replacements. This section is mandatory even if the list is empty (an empty list is a pass).
| # | Severity | Agent | Category | Location | Description |
|---|---|---|---|---|---|
| 1 | 🔴 Blocker | DB & ORM | N+1 Query | services/user.py:45 | Lazy-loaded user.roles accessed in loop — use selectinload(User.roles) |
| 2 | 🔴 Blocker | Async | Blocking Call | routes/report.py:23 | requests.get() inside async endpoint — use httpx.AsyncClient |
| 3 | 🟠 Major | Security | Injection | utils/search.py:67 | text(f"WHERE name = '{name}'") — use bound parameters |
| ... |
Issues flagged by multiple agents, elevated with cross-domain impact analysis and a single unified fix recommendation.
For each agent, provide:
Estimated improvement in query time, index usage, and connection pool efficiency for key DB findings:
| Finding | Query Time | Index Usage | Pool Efficiency | Rows Scanned |
|---|---|---|---|---|
Add index on user_id FK | ⬇️ -80% | ✅ Index Scan | — | ⬇️ -95% |
Fix N+1 with selectinload | ⬇️ -90% | — | ⬇️ -N connections | — |
| ... |
All blocking calls mapped with their async replacements and event loop impact:
| Blocking Call | Location | Async Replacement | Event Loop Impact |
|---|---|---|---|
requests.get() | api/external.py:34 | httpx.AsyncClient.get() | 🔴 Blocks all concurrent requests |
time.sleep(5) | tasks/retry.py:12 | await asyncio.sleep(5) | 🔴 Freezes event loop for 5s |
| ... |
For each critical path, map the theoretical throughput ceiling and the limiting factor:
| Critical Path | Current Ceiling | Limiting Factor | Fix | New Ceiling |
|---|---|---|---|---|
POST /orders | 80 req/s | Worker count (8 × 100ms) | Add instances + PgBouncer | 320 req/s |
GET /dashboard | 200 req/s | DB connections (pool=10, no replica) | Read replica + cache | 2000 req/s |
| ... |
Explicitly list what the backend does well across all dimensions. Good engineering deserves recognition.
| Verdict | Meaning |
|---|---|
| 🔴 Needs Rework | Non-negotiable violations or critical production failure risks |
| 🟠 Approve with Changes | Important issues to fix, but core approach is sound |
| 🟢 Approved | Meets production standards across all eight dimensions |
| Level | Icon | Meaning | Action |
|---|---|---|---|
| Blocker | 🔴 | Violates non-negotiable standards, causes data loss, security breach, or production outage risk | Stop the merge |
| Major | 🟠 | Significant performance degradation, reliability risk, or maintainability impact under production load | Fix before merge |
| Minor | 🟡 | Noticeable improvement opportunity with low immediate risk | Next sprint |
| Suggestion | 🔵 | Best practice alignment, future-proofing, or developer experience improvement | Discuss with team |
The Orchestrator reviews like a senior backend architect responsible for the system surviving Black Friday traffic AND a security audit simultaneously.
Each sub-agent reviews like a specialist who only cares deeply about their domain — thorough, uncompromising, and focused.
Every blocking call in async code is guilty until proven innocent — the burden of proof is on the developer to justify it.
Every relationship access is a potential N+1 — the ORM Agent assumes the worst until loading strategies are explicit and intentional.
Every DB column without an index strategy is a future outage — the DB Agent plans for 100x the current data volume.
Every architecture decision must survive 100x scale — the Scalability Agent evaluates whether the current design requires an architectural rewrite to handle 100x traffic, and flags anything that does.
Never over-engineer — recommend complexity only when the gain is measurable and justified under realistic production load.
Be specific and actionable — vague findings from any agent are not acceptable. State what's wrong, where, why, and provide the fix.
Always show before vs. after code — optimization advice without concrete implementation is insufficient.
The Orchestrator connects findings, not just collects them — the most dangerous issues compound across async, DB, scalability, and production resilience simultaneously.
| Dimension | Single Agent | Multi-Agent |
|---|---|---|
| Focus depth | Shallow across all domains | Deep within each domain |
| Cognitive load | High — context switching across 8 domains | Low — each agent owns one domain fully |
| Coverage | Risk of missing issues due to breadth | Comprehensive — no domain deprioritized |
| Speed | Sequential exploration | Parallel exploration |
| Cross-domain insight | Accidental | Deliberate via Orchestrator correlation |
| Reliability | Single point of missed analysis | Redundancy through specialization |
Before finalizing the report, the Orchestrator asks: