AI as Your
Engineering Team
One AI conversation is not a workflow. Give each conversation a job and it does that job well. Mix them and everything gets worse.
Running everything through one AI chat is like one meeting where the chef, accountant, and marketer all talk simultaneously. The chef forgets tonight's specials because someone brought up tax filing. Give each department its own meeting.
The Multi-Chat Architecture
Three conversation types. Each with a specific job.
Strategy Chat
Architecture, trade-offs, priorities. The AI pushes back on your assumptions. No code here. The brain.
Execution Chat
CLI reads files, writes code, runs commands. Precise instructions in, working code out. The hands.
Builder Session
Single-purpose. "Build this page with these specs." Full context, one task. The specialist.
Mixing roles produces worse results for all of them. Separation isn't overhead — it's how you get quality from each conversation.
.png)
Teaching AI to Disagree
By default, AI is agreeable. That will cost you days.
You suggest an approach and the AI says "great idea!" — then costs you days when the approach was flawed from the start.
Tell the AI: "Challenge my ideas. If you see a better approach, say so. If my plan has a flaw, tell me before I build on top of it."
This turns a yes-machine into a thinking partner. The worst conversations are ones where it does exactly what you ask without question — because the question was wrong.
How to Brief Your AI
Five components. Include all five and output lands first try.
Role
"You are the CTO of a subscription app startup" produces different output than "You are a copywriter." The role shapes every decision the AI makes.
Context
What's built, what constraints exist, what decisions are made. Load your documentation. The AI without context is a stranger guessing.
Task
"Write the Stripe webhook handler" beats "help with payments." Specific tasks get specific results.
Format
Code? A list? A document? Tell it what the output looks like. Remove ambiguity and you remove rework.
Constraints
"Don't change existing functions. Don't add libraries. Match existing patterns." Boundaries prevent over-engineering.
Before & After — The Same Task, Two Briefs
A real example showing how brief quality changes output quality.
Context Degrades Around Message 30
Long conversations forget what you told them at the beginning.
AI conversations have a memory window. The longer a conversation runs, the less reliably it remembers constraints you set at the beginning. A rule you established in message 5 — "do not touch the header component" — gets quietly dropped by message 35 when the AI modifies the header to fix an unrelated layout issue.
This is not a bug. It is a fundamental property of how language models work. The beginning of a long conversation slowly fades as new messages push it out of focus.
The fix: Start fresh conversations with your documentation rather than pushing through a degrading thread. When a conversation hits 30-40 messages and you still have work to do, open a new chat and load the relevant docs. Thirty seconds of setup prevents hours of undoing changes you explicitly told the AI not to make.
Documentation Is the Bridge Between Chats
The multi-chat model only works if conversations share context through written artifacts.
Your strategy chat produces a decision. Your execution chat needs to know about that decision. Without documentation, you become the bottleneck — manually copying context between conversations, forgetting details, introducing errors.
The solution: every significant decision gets written down in a doc that all future conversations can load. The strategy chat decides "we will use Stripe for web and Apple IAP for mobile." That decision goes into your tech doc. When the execution chat starts building the payment handler, it loads the tech doc and already knows the architecture.
This is why Chapter 6 (Documentation) comes before most of the building chapters. Without it, the multi-chat architecture collapses into a game of telephone where each conversation has a slightly different understanding of your product.
When to Push Back
Three red flags that mean the AI is leading you astray.
Unnecessary Complexity
50 users don't need microservices. If the solution feels bigger than the problem, it probably is. Ask: "What is the simplest version?"
Conflicting Decisions
AI doesn't know your full context by default. When suggestions conflict with earlier decisions, it forgot — not disagreed. Remind it of constraints.
Missing Error Handling
AI handles the happy path. Always ask: "What happens when this fails? What happens when the database is down? What happens when the user sends garbage?"
Never let AI build something significant without confirming the plan first. The alignment check takes sixty seconds and prevents hours of rework.