Multi-agent systems fail 41-86% of the time across common frameworks. That's not a hot take, it's the finding from the MAST study, which analyzed 1,642 real multi-agent execution traces and found 32.3% of failures came from inter-agent misalignment, not model quality. A separate 2025 study found unstructured agent networks amplify errors up to 17x over single-agent baselines.
So when I set out to build a pipeline where Claude Code owns the full SDLC of an iOS app, spec through merged, tagged release, I started from that failure data, not from "let's see what the model can do."
What I built
Pragma is a set of Claude Code slash commands that take an iOS feature from idea to production:
Human approval happens at exactly two points: after /spec and after /plan. Every other stage runs as an agent. /feature implements task by task with strict TDD (write the failing test, confirm it fails for the right reason, implement, run the full suite, commit). /gates verifies build, tests, and architecture compliance before a PR opens. /review and /test run after the PR is up.
The part that matters: enforcement doesn't trust the agent's self-report
Here's what I think most "spec-driven" tooling gets wrong. A spec mode can generate a great plan.md and still ship code that violates it, because nothing re-checks the output independently of the agent that produced it.
Pragma's /gates runs a set of checks locally before a PR opens. The same checks then re-run independently in GitHub Actions after the PR is up. That's not redundancy, it's the actual point: CI enforcement that can't be talked around by rerunning the agent with a different prompt. If the agent says "tests pass" and CI disagrees, CI wins.
There's a second piece I didn't expect to matter as much as it does: a memory layer. .claude/context/invariants.md, decisions.md, feature-log.md, and rejections.md persist across every session boundary. Every agent reads these before acting. It's the difference between a fresh model with a good prompt and something closer to institutional memory: what's inviolable, what's already been decided, what's already been tried and rejected.
Proof, not a demo
I built this on FinanceTracker, a real SwiftUI + SwiftData app, not a toy repo. It tracks spending across multiple accounts, sets monthly budgets per category with progress tracking, calculates net worth across assets and liabilities, and imports transactions from CSV through a three-step flow (file picker, column mapping, preview with dedup) that hashes date + amount + payee to avoid double-importing the same transaction on re-upload.
Dashboard: net worth, this month's spending, and budget progress in one view.
Transactions: searchable across every account, with manual entry alongside CSV import.
Budgets: monthly limits per category, with live progress tracking.
Accounts: assets and liabilities together, net worth calculated automatically.
94 merged PRs, specs and plans predating every feature back to the first commit. Every PR has an approved spec, an approved plan, and a passing CI run before merge, checkable in the actual history, not asserted in a README.
Where it's held up, and where it hasn't
The behavioral-correctness problem (does the agent's code actually do the right thing, not just pass the checks I thought to write) is still the hardest part. /test plus /gates' coverage gate are my concrete attempt at it, and I don't think it's solved so much as bounded.
The layer separation rules (Views have no business logic, Domain Services have zero SwiftData imports, ViewModels depend on protocols never concrete types) get violated by the agent occasionally, just like they get violated by junior engineers. The difference is /review catches it every time, because it's a fixed checklist, not a vibe check.
Try it
/plugin marketplace add akshaypimprikar/pragma
/plugin install pragma@pragma
/pragma:init MyApp
- Pipeline: github.com/akshaypimprikar/pragma
- The proof, FinanceTracker: github.com/akshaypimprikar/financetracker-ios
I'd genuinely like to hear how others are handling the same problem, especially the part where you have to independently re-verify what an agent claims it did, instead of trusting its own report of success.
Top comments (0)