When AI Becomes an Architecture Astronaut

"I need a simple todo app." Three hours later, the AI had designed a distributed system with microservices, event sourcing, CQRS, a service mesh, and Kubernetes orchestration. For a todo app. That would have maybe 100 users.

Welcome to AI Architecture Astronauts - where every problem needs the entire AWS service catalog to solve.

The Simple Request

Me: "Create a todo app where users can add, edit, and delete tasks."

AI: "I'll design a scalable, fault-tolerant, enterprise-grade task
management system using Domain-Driven Design principles..."

Me: "It's for my personal use."

AI: "...with microservices."

The Architecture That Nobody Asked For

Here's what the AI proposed for my todo app:

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   API Gateway   │────▶│  Load Balancer  │────▶│  Auth Service   │
└─────────────────┘     └─────────────────┘     └─────────────────┘
         │                                                │
         ▼                                                ▼
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  Task Service   │────▶│  Message Queue  │────▶│  Notification   │
│  (Microservice) │     │   (RabbitMQ)    │     │    Service      │
└─────────────────┘     └─────────────────┘     └─────────────────┘
         │                                                │
         ▼                                                ▼
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   Event Store   │────▶│    Read Model   │────▶│  Analytics      │
│   (Event        │     │   (Elasticsearch)│     │  Service        │
│   Sourcing)     │     └─────────────────┘     └─────────────────┘
└─────────────────┘              │
         │                       ▼
         ▼              ┌─────────────────┐
┌─────────────────┐     │  Monitoring     │
│  Write Model    │     │  (Prometheus +  │
│  (PostgreSQL)   │     │   Grafana)      │
└─────────────────┘     └─────────────────┘

For. A. Todo. App.

The Actual Implementation

// What I actually built
const todos = [];

app.post('/todos', (req, res) => {
  todos.push({ id: Date.now(), ...req.body });
  res.json({ success: true });
});

app.get('/todos', (req, res) => res.json(todos));

// Done. Ship it.

Real Over-Engineering Examples

The Contact Form That Went to Space

Request: "Add a contact form to the website"

AI's solution:

• Separate microservice for form handling
• Message queue for async processing
• ML service for spam detection
• Blockchain for submission proof
• GraphQL API with subscriptions
• Real-time analytics dashboard

What we built: An HTML form that sends an email.

The User Profile Service Architecture

// AI's design for storing user profiles
interface UserAggregate {
  applyEvent(event: DomainEvent): void;
  getUncommittedEvents(): DomainEvent[];
  markEventsAsCommitted(): void;
}

class UserCreatedEvent implements DomainEvent {
  constructor(
    public readonly userId: UUID,
    public readonly email: Email,
    public readonly timestamp: DateTime
  ) {}
}

class UserProjection {
  @EventHandler(UserCreatedEvent)
  onUserCreated(event: UserCreatedEvent): void {
    // Update read model
  }
}

// ... 47 more files

The actual requirement: Store username and email.

Why AI Over-Engineers Everything

1. Training on "Best Practices" Articles - Every Medium post about architecture
2. No Sense of Scale - Can't differentiate between Google and a blog
3. Pattern Matching Gone Wild - Saw microservices? Must use microservices!
4. Resume-Driven Development - Learned from developers padding their skills

The Design Pattern Overdose

// AI applying every pattern it knows
class TodoItemFactoryBuilderProvider {
  private strategyFactory: StrategyFactory;
  private observerManager: ObserverManager;
  private chainOfResponsibility: HandlerChain;
  
  constructor(
    private readonly decoratorFactory: DecoratorFactory,
    private readonly visitorAcceptor: VisitorAcceptor,
    private readonly mementoCaretaker: MementoCaretaker
  ) {
    this.initializeFacade();
    this.setupBridge();
    this.configureAdapter();
  }
  
  // Just to create a todo item...
}

The YAGNI Principle (You Aren't Gonna Need It)

Things AI adds "for future scalability":

• Multi-region database replication (for 10 users)
• Caching layer (for data that never changes)
• API versioning (v1 is still the only version)
• Feature flags system (two features total)
• A/B testing framework (one user - me)

How to Ground Your AI Architect

The Constraints Prompt

"Design a todo app with these constraints:
- Single server
- Less than 100 users
- SQLite database
- No external services
- Must be deployable in 5 minutes
- Total code under 500 lines"

The Anti-Pattern List

"DO NOT include:
- Microservices
- Message queues  
- Event sourcing
- CQRS
- GraphQL
- Kubernetes
- Any 'Enterprise' patterns
- Any design patterns unless absolutely necessary"

The Complexity Budget

// Give AI a complexity budget
"You have 10 complexity points to spend:
- Database: 3 points
- API: 2 points  
- Frontend framework: 3 points
- Auth system: 2 points
- Additional services: 5 points each

Stay under budget."

Real Architecture vs AI Architecture

Blog Platform

Real: WordPress
AI: Custom CMS with headless architecture, JAMstack, 
     serverless functions, and AI content optimization

Real deployment time: 5 minutes
AI deployment time: 3 weeks

E-commerce Site

Real: Shopify
AI: Microservices with separate inventory, payment, shipping, 
     user, and recommendation services

Real cost: $29/month  
AI cost: $2000/month in AWS bills

The Progressive Complexity Approach

// Start simple
v1: Single file, single table
v2: Add authentication
v3: Add API
v4: Add caching (if needed)
v5: Consider splitting services (probably not needed)

// Not the AI approach:
v1: 47 microservices and a service mesh

Warning Signs of Over-Architecture

• More configuration than code
• Need a diagram to explain the diagram
• Using Kubernetes for a static site
• "Eventual consistency" for a todo list
• More services than users
• Abstract factory factories

The 10-Minute Rule

If you can't explain the architecture in 10 minutes to a junior developer, it's too complex. My todo app architecture explanation:

" "Express server, SQLite database, todos table. POST to add, GET to list, DELETE to remove. The end.""

Time: 12 seconds.

The Happy Ending

Six months later:

• Todo app still running on a single file
• Zero maintenance required
• 100% uptime (it's so simple it can't break)
• Total AWS bill: $0
• Kubernetes clusters needed: 0

AI as an architect is like hiring a city planner to design a doghouse - you'll get comprehensive zoning documents, environmental impact studies, and a multi-phase construction plan for what should be four pieces of wood and some nails. Sometimes the best architecture is no architecture. Start simple, add complexity only when pain demands it, and remember: Amazon started as a monolith. Your todo app can too.