Architecture-Led AI SDLC Workflow

This is the workflow for the Build to aligned specs outcome. See Achieve Your Outcomes for both outcomes.

Catio's Architecture-Led AI SDLC takes an architectural requirement — from a PRD, a strategy document, or a decision your team has already made — through to a pull request that implements it, without the design being re-inferred anywhere along the way.

The work splits across two planes. Catio is the control plane, where intent is encoded and designs are generated and governed. Your coding IDE is the execution plane, where the code is written. The Catio MCP is the interface between them.

The stages

1. Encode intent. Requirements, objectives, guardrails, and standards go into Workspace Context. Everything generated afterwards inherits them, so this is the step that determines output quality. See Using Context Effectively.
2. Model the system. Integrations build the live architecture model — components, dependencies, topology — that designs are grounded in.
3. Generate the design. A PRD or feature spec becomes a Blueprint: requirements, trade-offs with the alternatives that were rejected and why, and an execution-ready spec covering phasing, testing, monitoring, and launch. A mandate-level prompt yields a Plan instead of a single Blueprint.
4. Commit it. The validated Blueprint becomes the spec of record. Plans organize committed Blueprints into sequenced work.
5. Pull the spec into the editor. The developer retrieves the committed Blueprint through the Catio MCP rather than working from ticket prose.
6. Generate the code. The assistant writes against the spec and against the real inventory, so the change reuses what you already run instead of introducing plausible substitutes.
7. Open the pull request with the Blueprint and ticket referenced, then review by exception: architects examine deviations from a written-down design rather than reviewing every change.

Where each part runs

What you need in place

• A workspace with Context encoded and at least one integration feeding the architecture model.
• The Catio MCP connected to your coding assistant.
• For the PR step, the GitHub MCP connected with write and pull-request scope on the target repo.

Done when

• The requirement driving the change is in Workspace Context, not only in a prompt.
• A committed Blueprint exists whose Target State, Gap Analysis, and Implementation Plan your team has read and evaluated.
• The assistant has mapped the Blueprint against your actual repository and reconciled any drift before writing code.
• A pull request is open against an integration branch, not against main, with the Blueprint referenced.
• The code reuses the infrastructure and naming you already have rather than introducing new ones.

Worked examples

• Query Your Architecture and Find Blueprints with the Catio MCP — the read-only half: orienting in a workspace and locating the right Blueprint.
• Generating Architecture-Aware Code with Catio MCP — the full worked run, extracting a Notifications domain out of an Orders monolith, from Blueprint to pull request.

In this section

• Video Walkthrough: Architect, then Ship Overview
• 1-Pager: Architect, then Ship
• Adopt in your Org: Uplevel to the New SDLC in under 12 Weeks
• Detailed Workflow Walkthrough: Architecture-Led AI SDLC Step-by-Step