AI and Software Architecture: A Dangerous Convenience

You asked your AI assistant how to structure a new service. It suggested event sourcing with CQRS, a hexagonal architecture with ports and adapters, and a saga pattern for distributed transactions. The explanation was clear, the code examples were clean, and the diagrams made sense.

Six months later, your team of three is maintaining an event sourcing infrastructure for an application that serves 200 requests per day. Every feature takes three times longer than it should because of the abstraction overhead. The architecture is technically excellent and practically ruinous.

This is the abstraction illusion: AI makes sophisticated patterns accessible without making them appropriate. Before AI, implementing event sourcing required reading books, studying examples, and building incrementally – a process that naturally filtered out teams who didn’t need it. Now, any developer can generate a complete CQRS implementation in an afternoon. The barrier shifted from “can you build it?” to “should you build it?” – and AI offers no help with the second question.

For the broader picture on productive AI-assisted development, see our Developer Productivity Guide. This article focuses on architectural decisions – perhaps the highest-leverage area where AI’s convenience can cause the most damage.

Design Is Constraint Decisions

Architecture isn’t about choosing patterns – it’s about choosing constraints. Every architectural decision trades one set of capabilities for another¹:

• Microservices trade deployment independence for operational complexity
• Event sourcing trades query simplicity for audit completeness
• Monoliths trade scaling flexibility for development speed

Good architectural decisions come from understanding your specific constraints: team size, traffic patterns, consistency requirements, operational capacity, and timeline. AI knows the patterns but not your constraints. When you ask “how should I architect this?”, AI answers the question it can answer (which patterns exist) rather than the question you need answered (which constraints should guide your choice).

Where AI Helps with Architecture

AI is valuable for architectural work that involves knowledge retrieval and pattern exploration rather than judgment.

Pattern Exploration

“What are the common ways to handle X?” is an excellent question for AI. It provides a survey of approaches with tradeoffs – a starting point for your decision, not the decision itself. Use AI to build your options list, then apply your own judgment to select.

Implementation Examples

Once you’ve decided on an approach, AI generates excellent implementation examples. “Show me how to implement the repository pattern in TypeScript with Prisma” is a mechanical question that AI answers well.

Tradeoff Articulation

AI can clearly articulate the textbook tradeoffs of different approaches. While this isn’t sufficient for making the decision (because your specific context matters), it ensures you’re aware of the standard considerations. Ask “what are the tradeoffs of X vs. Y?” and treat the response as a starting checklist, not a final analysis.

Code Organization

“How should I organize modules for a REST API?” or “What’s a clean folder structure for a React app?” – AI provides sensible conventions based on community standards. These are coordination decisions (how to organize) rather than constraint decisions (what to build), and community conventions are exactly the right guide.

Where AI Hurts with Architecture

The danger zones all involve decisions that depend on information AI doesn’t have.

Choosing Between Patterns

AI can explain microservices and monoliths. It can’t tell you which one your team should use. That decision depends on your team’s operational skills, your deployment infrastructure, your release cadence, your growth trajectory, and a dozen other factors. AI defaults to suggesting the more sophisticated option – likely because its training data over-represents articles about complex patterns – leading to systematic overengineering².

Sizing and Scoping

How many services? How granular should the modules be? When should you extract a library? These sizing decisions require understanding your codebase’s rate of change, your team’s communication patterns, and your organization’s structure (Conway’s Law). AI provides generic guidance that ignores these specifics.

Non-Functional Requirement Tradeoffs

When your latency requirement conflicts with your consistency requirement, which wins? When your security requirement conflicts with your usability requirement, where’s the tradeoff? These are business decisions informed by engineering constraints – the exact intersection where AI’s advice is least reliable.

Migration and Evolution Strategy

“How should we migrate from X to Y?” requires understanding your current system’s real behavior (not just its designed behavior), your team’s capacity, your risk tolerance, and your timeline constraints. AI’s migration advice tends to be textbook-clean and production-unrealistic.

The “10 Questions” Test

Before implementing any architecture AI suggests, answer these ten questions. If you can’t answer most of them, the architecture is premature:

1. What specific problem does this solve? Not a general category – a specific problem you’ve experienced or measured.
2. What’s the simplest alternative? Could a monolith, a single database, or a function solve this?
3. What does this cost to operate? Infrastructure, monitoring, debugging, onboarding new team members.
4. Can your team maintain this? Do you have the skills and tooling for this architecture’s failure modes?
5. What happens at 10x your current scale? Does this architecture help or just add overhead?
6. What’s the blast radius of a failure? When one component breaks, what else breaks?
7. How do you test this end-to-end? Can you run the full system locally?
8. How do you deploy a change? What’s the path from commit to production?
9. How do you debug a cross-cutting issue? When something goes wrong, how do you trace it?
10. What’s the migration path back? If this architecture turns out to be wrong, how hard is it to simplify?

Questions 4 and 10 are the most important. If your team can’t maintain the architecture or retreat from it, the sophistication is a trap regardless of its theoretical benefits.

AI as Architecture Sparring Partner

The most productive use of AI for architectural decisions isn’t asking for recommendations – it’s arguing against your proposed approach.

The Devil’s Advocate Workflow

1. Form your own architectural opinion first. Based on your understanding of the constraints, decide on an approach.
2. Ask AI to argue against it. “What are the risks and downsides of using X for this use case?” AI is excellent at identifying counterarguments because it has broad exposure to failure cases.
3. Evaluate the arguments. Do the counterarguments apply to your specific context? If they do, reconsider. If they don’t, proceed with more confidence.
4. Ask AI to identify what you might have missed. “What non-obvious failure modes should I consider with this architecture?” This leverages AI’s pattern matching while keeping judgment with you.

This approach is more effective than asking “what should I use?” because it forces you to articulate your reasoning first. AI strengthens your decision by stress-testing it rather than replacing it.

The Reversibility Principle

When uncertain about an architectural decision, choose the more reversible option. This principle, borrowed from Amazon’s “one-way door vs. two-way door” framework, is especially important when AI is involved:

• Two-way doors (reversible): Library choices, folder structures, API naming conventions. Make these quickly – AI’s suggestions are fine because you can change them later.
• One-way doors (irreversible): Database technology, service boundaries, data model design, communication patterns. Invest significant human thought here because the cost of being wrong is high.

AI treats all decisions equally – it doesn’t distinguish between naming a variable and choosing a database. You need to apply the reversibility filter yourself.

Use Super Productivity to track architectural decisions alongside your regular tasks. Creating a dedicated task for each significant decision – with a description that captures the context and rationale – prevents the “why did we do this?” problem that plagues teams six months later.

For more on how AI tools interact with focused decision-making, see our guide on decision fatigue.

A Practical Architecture Workflow

1. Gather constraints first. Write down your team size, traffic expectations, consistency requirements, operational capacity, and timeline. Do this before asking AI anything.
2. Explore options with AI. Ask for a survey of approaches with tradeoffs. Treat this as research, not recommendations.
3. Propose your approach. Based on constraints and options, form your own opinion.
4. Stress-test with AI. Use the devil’s advocate workflow to identify weaknesses.
5. Apply the 10 questions test. If you can’t answer most questions, simplify.
6. Choose the more reversible option when tied. Reserve irreversible decisions for situations where you have high confidence.
7. Document the decision. Record the constraints, options considered, and rationale. This is the documentation AI can’t generate because it requires your specific context.

The Bottom Line

AI democratized access to sophisticated architectural patterns. That’s genuinely valuable – developers can now explore approaches they wouldn’t have encountered otherwise. But access without judgment leads to overengineering: systems that are architecturally impressive and practically unmaintainable.

The developers who make the best architectural decisions with AI use it for exploration and stress-testing while keeping the actual decision – the constraint-based judgment call – firmly human. The best architecture is the simplest one that solves your specific problem within your specific constraints. AI can help you find it; it can’t choose it for you.

Related Resources

• Developer Productivity Guide – structured approaches to engineering effectiveness
• AI Coding Tools and Focus – managing AI tools without losing deep work
• Decision Fatigue for Developers – why fewer, better decisions beat more decisions