Ideate AI-Driven Architecture & Design
AI-driven architecture design, documentation generation, and solution modeling. Compare several approaches, with the trade-offs written down, before committing to one.
What is the Ideate Phase?
The Ideate phase transforms how you approach architecture and design. Instead of settling on the first solution that comes to mind, AI helps you explore multiple approaches rapidly.
Traditional design often suffers from anchoring bias - we tend to stick with our first idea. AI breaks this pattern by generating alternatives, questioning assumptions, and helping visualize different architectures quickly. The decisions you capture here become the spec that coding agents execute in the Develop phase, so writing them down clearly matters more than ever - see Context & Spec-Driven Development.
In the Ideate phase, AI helps you:
- Generate architecture diagrams and system designs
- Explore multiple design patterns and compare trade-offs
- Create API contracts and data models
- Write technical specifications and documentation
- Validate designs against requirements from the Analyze phase
Quick Reference
Architecture Partner
Diagrams, specs, API contracts
Claude, Gemini, Mermaid, Excalidraw
Tech lead or architect, with the product owner
Spec approved by a human
Inputs and Outputs
Ideate turns an agreed problem into a plan an agent can execute. It takes in the signed-off brief and hands over a small set of written decisions and a spec.
What it receives
- The signed-off Requirements Brief from Analyze: problem, users, acceptance criteria, constraints, open questions, and risks.
- The current system: existing architecture notes, earlier ADRs, API definitions, data models, and the repo instruction file.
- The design system and any brand or accessibility standards the work must follow.
- Constraints that limit the options: team skills, cost, latency, security, and the data classification involved.
What it hands off
- A Design Note that explains the chosen approach and the alternatives that were rejected.
- An ADR (architecture decision record) for each significant decision.
- An API and data contract: endpoints, schemas, events, and error behavior, agreed before code exists.
- An agent-executable Spec that names the goal, files, interfaces, acceptance criteria, and what is out of scope.
A spec is written for a reader with no memory
The coding agent that receives the spec will not remember the design meeting. Anything the spec does not say, the agent will decide for itself, and often decide differently on the next run. That is why the spec has to be explicit, and why spec-driven development treats it as the main control surface rather than a formality.
Key Activities
Architecture Diagrams
AI generates system architecture diagrams, sequence diagrams, and data flow visualizations. Get from concept to diagram in minutes.
Pattern Exploration
AI suggests design patterns, compares approaches, and helps you understand trade-offs between different architectural decisions.
API Design
AI helps design RESTful APIs, GraphQL schemas, or RPC interfaces. Generate OpenAPI specs and validate against best practices.
Technical Specs
AI drafts technical specification documents that capture architecture decisions, rationale, and implementation guidance.
Product and UX Design
Ideate is also where the product takes shape for the people who will use it. Agents make it cheap to put something in front of a real user before anyone commits to building it, which changes how design and engineering work together.
Throwaway prototypes
Have an agent build a clickable prototype to test an idea with real users. The prototype exists to answer a question. It is never shipped as-is: once it has taught the team what it needed to, it is discarded and the real feature is built from the spec, with tests and review.
UI exploration
Ask for several layouts, flows, and empty or error states for the same screen, then compare them against the brief. The value is in seeing the alternatives side by side, not in accepting the first one produced.
Design-system conformance
Point the agent at the existing component library and design tokens through the repo instruction file, and require it to reuse them. A prototype that invents its own buttons and colors creates a rewrite later, and a reviewer should be able to reject it on that ground alone.
Accessibility from the first prototype
Target WCAG 2.2 AA from the first prototype, not as a late audit. Automated checkers catch only part of WCAG, so a person still tests with a keyboard and a screen reader before a design is called done.
The product owner's role
The product owner decides what is worth testing with users, watches or reads the results, and decides which findings change the design. The agent can build the prototype and summarize the sessions. It cannot say which user complaint matters, and it cannot tell whether a prototype that users liked is a product the business should build. Those findings flow into the design note and the spec; see the Ideate prompts for starting points.
Example Workflow
Read the Brief and List the Decisions
Pull every decision the brief leaves open: data store, sync or async, build or buy, contract shape. Each one is a candidate ADR.
Generate Alternatives
Ask an agent for two or three viable approaches for each decision, with the trade-offs, the failure modes, and the reason to reject each one. Ask it to argue against its own favorite.
Choose and Record
The architect picks an approach and writes the reason in an ADR. A short, honest record of why is worth more than a long diagram.
Prototype Where Users Are Involved
For user-facing work, build a throwaway prototype, test it with real users, and fold the findings back into the design.
Draft the Contract
Have the agent draft the API and data contract, such as an OpenAPI document or a schema, and have a human review it before any implementation starts.
Write the Spec
Assemble the goal, interfaces, files, acceptance criteria, and out-of-scope list into a spec an agent can execute without a conversation.
Move to Develop
With an approved spec and contract, hand the work to the Develop phase. The first job there is to slice the spec into tickets.
Who Owns It
The tech lead or architect owns the design note, the ADRs, and the contract. The product owner owns scope and the reading of user feedback. A designer, where there is one, owns the design system the prototypes must conform to.
What the AI drafts
- Alternative architectures, with pros, cons, and failure modes for each.
- Diagrams as text, such as Mermaid, that live in the repo and diff cleanly.
- Draft API and data contracts, and draft ADR text from the notes of a decision.
- A first-pass spec and throwaway UI prototypes.
What humans decide
- Which approach is chosen, and which trade-offs the team accepts.
- Whether a decision is significant enough to need an ADR.
- Whether the contract is right, since it will be expensive to change after consumers depend on it.
- Approval of the spec, which is the gate to Develop.
Entry and Exit Criteria
Entry criteria
Start the phase when all of these are true.
- A signed-off Requirements Brief exists.
- The architect or tech lead for the work is named.
- The repo instruction file is current, so agents start from the real architecture rules.
Exit criteria
Leave the phase only when all of these are true.
- The design note is written and the rejected alternatives are recorded.
- Each significant decision has an ADR.
- The API and data contract has been reviewed by a human.
- The spec traces to every acceptance criterion in the brief.
- A human has approved the spec, and any prototype is marked as discarded or as reference only.
Best Practices
Ask for alternatives and reasons to reject
A single proposal invites you to accept it. Ask for more than one, and make the model say what would make each one wrong.
Write an ADR for decisions that are hard to reverse
Data stores, public contracts, and security boundaries deserve a record. Reversible choices do not need one.
Design the contract before the code
Agree the API and data shapes first, and generate client and server from the one source. Mismatched contracts are cheap to catch now and costly in Develop.
Do not ship the prototype
A prototype built to answer a question carries no tests, no review, and no accessibility work. Promoting it to production imports all of that debt.
Anti-Patterns
The named patterns are catalogued on Twelve Ways AI Adoption Fails. These are the ones that show up in design work.
The prototype that became the product
A convincing prototype gets demoed, praised, and quietly promoted. The team now maintains code that nobody designed, tested, or reviewed.
The wish-list spec
A spec that names goals but not interfaces, files, or exclusions. The agent fills each gap with its own choice, and no two runs agree.
Instruction File Rot
The architecture rules the agent reads were written once and never updated, so the agent designs against a system that no longer exists.
What to Measure
Design quality shows up downstream. Pick from the metrics on Measuring Impact and read them with the design in mind.
Cycle time, ticket to production
A well-specified ticket moves quickly through Develop. A long tail often traces back to a spec that left questions open.
PR review turnaround
Reviewers move faster when the spec and contract tell them what the change should do. Slow reviews of small diffs are a sign the intent was unclear.
Bug escape rate
Contract mismatches and misread edge cases are design failures that surface as production bugs. Track how many escapes trace back to the spec.
Go Deeper
Repo instruction file
The skeleton that tells agents your architecture rules and risk tiers.
Read moreContext and spec-driven development
Why the spec is the control surface for every agent downstream.
Read moreA worked example
One feature carried through all five phases, with the design note and spec shown.
Read moreFrequently Asked Questions
The Ideate phase focuses on AI-driven architecture design, documentation generation, and solution modeling. You explore possibilities and validate approaches before writing code.
AI can suggest architectural patterns, identify potential issues, generate documentation, create diagrams, and help evaluate trade-offs between different design approaches.
An ADR, or architecture decision record, is a short note that captures one significant design decision, the options considered, and the reason one was chosen. Ideate writes one for each significant decision so that later agents and engineers can see why the design is the way it is, instead of guessing and quietly reversing it.