AI-Driven Architecture vs. Human-Led Design: A Practical Comparison

There's a post making the rounds right now — "Claude Is Not Your Architect" — and it hit a nerve because I've watched this exact anti-pattern play out on three teams in the last six months. A developer asks an AI to scaffold a project, accepts every suggestion without question, and three months later they're drowning in abstractions nobody understands.

So let's talk about two fundamentally different approaches to using AI coding assistants, and why the difference matters more than you think.

The Two Approaches

AI-as-Architect: You describe what you want to build, the AI designs the system, picks the tools, and generates the structure. You're along for the ride.

AI-as-Tool: You make the architectural decisions. The AI helps you implement them faster, catch bugs, and write boilerplate. You drive.

This isn't just a philosophical distinction. It produces measurably different codebases.

What Goes Wrong When AI Drives Architecture

I recently inherited a project where a developer had let Claude design their entire backend. The AI had introduced:

• A full event-sourcing system for a CRUD app with 200 users
• Three layers of abstraction over a simple PostgreSQL connection
• A custom dependency injection container instead of just... passing arguments

Here's what the AI-architected database layer looked like:

// AI-architected: 4 files, 3 abstractions, 1 simple query
interface IRepository<T> {
  findById(id: string): Promise<T | null>;
  findAll(filter: Partial<T>): Promise<T[]>;
  create(entity: Omit<T, 'id'>): Promise<T>;
  update(id: string, entity: Partial<T>): Promise<T>;
  delete(id: string): Promise<void>;
}

class PostgresRepository<T> implements IRepository<T> {
  constructor(
    private readonly pool: Pool,
    private readonly tableName: string,
    private readonly mapper: EntityMapper<T>  // yet another abstraction
  ) {}
  // ... 80 more lines of generic plumbing
}

class UserRepository extends PostgresRepository<User> {
  constructor(container: DIContainer) {
    super(
      container.resolve('pool'),
      'users',
      container.resolve('userMapper')
    );
  }
}

Here's what the human-led version looks like:

// Human-led: 1 file, direct and readable
import { pool } from './db';

export async function getUserById(id: string) {
  const { rows } = await pool.query(
    'SELECT * FROM users WHERE id = $1',
    [id]
  );
  return rows[0] ?? null; // null if not found, no wrapper needed
}

export async function createUser(email: string, name: string) {
  const { rows } = await pool.query(
    'INSERT INTO users (email, name) VALUES ($1, $2) RETURNING *',
    [email, name]
  );
  return rows[0];
}

Same functionality. One tenth the code. Anyone on the team can read it in thirty seconds.

A Real-World Example: Choosing an Analytics Stack

Let me show you where this plays out in a real decision. I asked Claude to recommend an analytics setup for a small SaaS app. It immediately suggested a full-blown event pipeline: Segment for collection, a data warehouse, dbt for transformations, and Mixpanel for visualization.

For a product with 500 users. Come on.

This is an architectural decision that requires context an AI doesn't have — your privacy requirements, your team size, your budget, your regulatory constraints. So let me walk you through how a human should actually evaluate this, comparing three privacy-focused analytics tools I've used in production.

Umami vs. Plausible vs. Fathom

Feature	Umami	Plausible	Fathom
Hosting model	Self-hosted (free) or cloud	Self-hosted or cloud	Cloud only
GDPR compliant	Yes, no cookies	Yes, no cookies	Yes, no cookies
Open source	Yes (MIT)	Yes (AGPL)	No
Script size	~2KB	~1KB	~2KB
Pricing (cloud)	Starts free	Starts at $9/mo	Starts at $15/mo
Custom events	Yes	Yes	Yes
API access	Yes	Yes	Yes

Umami is my go-to for projects where I want full control. It's genuinely simple to self-host — a single Docker container with a Postgres or MySQL database. No cookies, no consent banners needed, fully GDPR compliant out of the box. The dashboard is clean and gives you exactly what you need without the noise.

# docker-compose.yml - that's literally the whole deploy
version: '3'
services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:secret@db:5432/umami
      # generate this once with: openssl rand -hex 32
      APP_SECRET: your-random-secret-here
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: secret
    volumes:
      - umami-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]
      interval: 5s
      timeout: 5s
      retries: 5
volumes:
  umami-db:

Plausible edges ahead if you want the lightest possible script footprint and a slightly more polished cloud dashboard. Their self-hosted setup is solid but more involved than Umami's. The AGPL license matters if you're building something commercial on top of it.

Fathom is the "just works" option. No self-hosting, no infrastructure to manage, but you're paying more for that convenience. Great for teams that don't want to think about it.

The Decision Framework AI Misses

Here's the thing — an AI will optimize for technical completeness. It'll suggest the most feature-rich, enterprise-grade solution because that's what the training data rewards. But the right answer depends on questions only you can answer:

• Do you have ops capacity? If you're a solo founder, self-hosting Umami means you own that uptime. Fathom takes that off your plate.
• What's your privacy posture? All three are GDPR compliant, but Umami self-hosted means data never leaves your infrastructure. For healthcare or fintech, that might matter.
• What's your budget reality? Umami self-hosted is free forever. That's not a small thing for a bootstrapped project.

How to Actually Use AI Effectively

I'm not saying don't use AI coding assistants. I use Claude daily. But I use it like I'd use a very fast junior developer who's read every Stack Overflow answer ever written.

Good uses:

• "Write me the SQL migration for this schema I've designed"
• "Convert this callback-based code to async/await"
• "What's the equivalent of this Python snippet in Go?"

Bad uses:

• "Design my application architecture"
• "What database should I use?"
• "How should I structure this project?"

The pattern is simple: you make decisions that require context about your team, your users, and your constraints. The AI handles implementation details that are well-defined and context-free.

The Migration Mindset

If you've already let AI drive your architecture and you're feeling the pain, here's how to unwind it:

1. Identify the abstractions nobody asked for. If a layer exists only because "it might be useful someday," delete it.
2. Replace generic with specific. That IRepository<T> pattern? Replace it with named functions that do exactly what your app needs.
3. Document your actual requirements. Write down what your app does today, not what it might do in two years. Architect for that.
4. Use AI to help with the migration, not to design the target state. Tell it exactly what you want the code to look like, and let it help you get there.

The Bottom Line

AI coding assistants are genuinely transformative tools for implementation speed. But architecture is about tradeoffs, and tradeoffs require context that lives in your head — not in a language model's weights.

The developer who chose Umami self-hosted for their bootstrapped SaaS made a good architectural decision. The developer who let an AI recommend a full Segment-to-Snowflake pipeline for the same app made a bad one. The difference wasn't intelligence. It was knowing which decisions to delegate and which to own.

Keep driving. Let the AI ride shotgun.