Part 7 — Design First, Code Later: How to Keep Architectural Control When AI Does the Building

AI Workflow · Module 7

Design First, Code Later

"The most expensive code is code built on the wrong foundation."

3-Part Design Framework

4-Phase Iterative Cycle

1 Rule 1 task, 1 conversation

Here's a failure pattern that happens constantly: a developer writes a detailed prompt, the AI produces exactly what was asked for, and then the developer realizes the implementation doesn't fit the existing architecture. The code has to be thrown away. The prompt was perfect — but the design thinking came too late.

AI amplifies your implementation speed. But it cannot design for you. Design is a red-light task: it requires your knowledge of the system, the team's conventions, the business constraints, and the long-term maintainability goals. Hand that over to the AI and you get working code on the wrong foundation.

The Design First framework gives you a concrete process for separating the design phase (yours) from the implementation phase (AI's) — so every piece of generated code fits the system you already understand.

The Two Traps: Big Bang and Vague Direction

Before the framework, name the failure modes.

❌ Trap 1: The Big Bang Prompt

"Build me a complete e-commerce checkout flow."

The AI produces a complete implementation — with all architectural decisions made for you. Data model, state shape, API contract, component structure. You didn't design any of it. Now you have 800 lines that work but don't fit.

❌ Trap 2: Vague Direction

"Add order tracking to the checkout flow."

No system context. The AI doesn't know your existing Order model, your event system, your notification service. It creates something that technically works in isolation but creates integration friction everywhere it touches.

Both traps have the same root cause: implementation before design.

The Design First Framework: 3 Steps Before Any Prompt

Deconstruct — What are the components?

Break the feature into its constituent parts: data models, services, UI components, API contracts, state shapes. This decomposition happens in your head (or a scratchpad), not in a prompt. Write it in pseudocode or plain language. You are creating the blueprint.

Define API Contracts — What are the interfaces?

Before any implementation, define the interfaces between components: function signatures, TypeScript types, prop contracts, REST endpoint schemas. This is where you make the decisions that matter — what data flows where. AI will implement to these contracts, not invent them.

Outline Logic — What are the decision points?

Write the core algorithm or business logic in pseudocode. Not syntax — intention. "If inventory < threshold, block purchase and show restock notice." This gives the AI the decision tree without you writing the implementation.

Once you have the D-A-P, every prompt you write is giving the AI a construction job with a blueprint. It can't make architectural decisions that weren't already made.

The 4-Phase Iterative Cycle

For features that span multiple files and components, use the iterative cycle instead of one large prompt. This keeps you in architectural control as the implementation grows.

PLAN

Complete your Design First (D-A-P) work. Define what the feature is, what it touches, and what success looks like. This phase is entirely yours — no AI until the blueprint is clear.

↓

PROMPT

Send one focused, well-specified prompt for the first component of your design. The specification is grounded in your blueprint — not invented by the AI. Start small and build up.

↓

REVIEW

Apply the Trust Spectrum review to the generated component. Does it match your design? Does it respect the API contracts you defined? Does it fit the existing architecture? This is your validation gate.

↓

REFINE

Either approve and move to the next component in your design, or send a targeted refinement prompt. The refinement is specific — not "fix it" but "the error handling should use AppError not throw directly, and the function signature must remain unchanged."

Loop until all components are complete. Your blueprint ensures each iteration builds on the previous one correctly.

One Conversation, One Task

The single most practical rule in this article:

One Conversation = One Task

Start a new conversation for each distinct task. Context from task A pollutes task B. Mixed conversations produce code that tries to satisfy conflicting requirements from different tasks. Clean context = clean output.

In practice: each component from your DAP decomposition is one conversation. When that component is done and reviewed, start a fresh conversation for the next one. The AI doesn't carry over assumptions from previous sessions — and in this case, that's a feature.

Design as the Durable Skill

Here's the thing about AI-assisted development: the tools change. The models improve. The IDEs and assistants will look different in 24 months. But software architecture — the ability to decompose a system, define interfaces, and make sound design decisions — has been valuable for 60 years and will be for 60 more.

The design phase is the part AI can't do for you. Which means it's the part that compounds in value as AI handles more of everything else.

Protect the design phase. That's where your long-term leverage lives.

Next in AI Workflow

Part 8 — The 4 Quality Gates

AI generates technical debt faster than any developer ever could. The 4 Quality Gates stop it before it ships — a non-negotiable checklist for every AI-generated pull request.