Recap — Sketching, Evaluating, Deciding

# Sketching, Evaluating, Deciding For architecture and design, AI is a useful brainstorming partner but a poor decision-maker. The pattern: AI generates options + analysis; you decide. ## Where AI is useful ### Exploring options > "I need to design a notifications system. What are 3-4 architectural approaches? Trade-offs of each?" AI lists: synchronous in-process; async queue (Celery/ARQ); separate microservice; SaaS like Resend. Each with pros/cons. You now have a menu, not a single answer. ### Pattern catalog > "I'm building a real-time chat. What patterns does the industry use?" AI: WebSocket vs SSE vs long-polling. Architecture options: monolith with sockets; dedicated chat service; managed (Pusher). Mentions challenges: persistent connections, scaling. You now know the vocabulary and options. ### Trade-off analysis > "I'm choosing between SQL and a document store for user profile data. Help me think through the trade-offs for our use case: 10M users, frequent profile updates, occasional batch queries, GDPR delete compliance." AI weighs each axis. You compare against your context. ### Pre-mortem > "If I build this with Postgres + sharding by user_id, what could go wrong?" AI lists likely problems: cross-shard queries; rebalancing; etc. Useful before committing to a design. ## Where AI is NOT useful ### Decisions "Should I use microservices?" AI gives generic answer. Doesn't know: - Your team size and skills. - Your operational capacity. - Your traffic patterns. - Your business constraints. The decision is yours; AI doesn't know enough. ### Novel architectures "Design a novel solution to X." AI pattern-matches existing solutions; doesn't invent genuinely new things. ### Validating decisions "I've decided to use X. Confirm this is right." AI tends to agree (sycophantic). Bad confidence-check. ## The brainstorming pattern Use AI like a thoughtful colleague: ``` 1. State the problem. 2. Ask for options (3-5 approaches). 3. Ask for trade-offs. 4. Discuss specific concerns. 5. Iterate based on your context. 6. Decide. 7. Document the decision. ``` AI is steps 2-4. Decision is yours. ## Concrete prompts ### Exploring > "We need to handle 10K concurrent WebSocket connections for a chat app. What are the architectural options? Don't recommend yet; just lay them out with pros/cons." ### Comparing > "Compare: (a) one big service with sticky sessions, (b) sharded connection servers with Redis pub-sub, (c) managed service like Pusher. For a team of 5 engineers with limited ops experience." Specifying your context yields better trade-off analysis. ### Critiquing > "I'm planning to use approach X. What are the things I might be missing? What are 3 ways this fails?" Adversarial framing; AI's generic critique is useful. ### Drilling down > "For approach B, walk me through the data flow. What does the worst case look like?" AI elaborates. You think. ## The naive pitfalls ### Sycophancy Ask "is X a good idea?" → AI agrees. Yes-bias. Better: "What are the problems with X?" Or "Critique X." ### Generic advice Without your context, AI gives textbook answers. Generic ≠ right for you. Give context: team size, traffic, constraints, existing stack. ### Trendy bias AI knows trendy patterns (microservices, event sourcing, CQRS). Suggests them more than warranted. For most apps, simpler is better. Push back: "Would a simpler approach work?" ### Overconfidence AI states architectural advice with same confidence as it states `X = 2 + 2`. Treat with appropriate skepticism. ## Document the decision After deciding (with or without AI input), write it down: ``` # ADR-007: Notifications system ## Status: Accepted ## Context We need to send emails, SMS, and in-app notifications. Volume: ~10K/day initially, projected 100K/day in a year. ## Decision Use ARQ for the queue + workers. Single notifications service inside our monolith. Resend for email; Twilio for SMS. ## Alternatives considered - Celery: more features, more ops burden. Stick with ARQ for async-first stack. - Separate microservice: too much overhead for our team size. - SaaS-only (Postmark): doesn't fit SMS needs. ## Consequences - Coupled to monolith (acceptable for now). - Migration to dedicated service possible later if needed. ``` AI can help write this; you ratify. ## Architecture diagrams AI can generate Mermaid / PlantUML / draw.io descriptions: > "Generate a Mermaid sequence diagram showing the OAuth login flow with our app, the user's browser, GitHub, and our DB." Cheap diagrams = better team communication. ## When you don't know what to ask "I need to design X but I don't know where to start." Pivot to questions: > "Ask me 5 questions to help define this problem." AI generates clarifying questions. Answering them surfaces requirements. Useful for: unclear product asks; greenfield projects. ## Common architecture-with-AI mistakes 1. **Trusting AI as the decider**: it doesn't know your context. 2. **Aski