Arnold Cartagena

Posted on Mar 16

AI Monoculture: When Every Engineer Has the Same Architect

#ai #startup #architecture #programming

Vibe coding is technical debt at scale. The rewrite is coming.

I was asking myself this question for quite a while, it's like we all have the same Architect, so I ran an experiment across six frontier AI models to see what happens when you ask them to design software architecture versus when you ask them to help build the project.

144 prompts. Four different systems. Three prompt styles.

When asked to design architecture, the models recommended Rust, Aerospike, ClickHouse, event streaming systems.

When asked to help build the same systems, those choices vanished.

Rust dropped from 43 recommendations to zero. SQLite appeared 12 times. TypeScript jumped to 25.

Same models. Same problems.

The only difference was the prompt: "design it" versus "help me build it."

And that difference could explain why so many AI-built apps end up with the exact same stack.

This is already happening and most people don't see it

You already know what this looks like. You've seen it. You might be building one right now.

Next.js + Supabase. Auth? Supabase. Database? Supabase. Real-time? Supabase. File storage? Supabase. The DX is smooth, the deploy is one click, and Vercel has done genuinely excellent work making it frictionless. Credit where it's due.

But when you look at a thousand AI-assisted projects and they all have the same skeleton, that's not a thousand engineers independently arriving at the same conclusion. That's one model's opinion, amplified a thousand times. It's an AI monoculture — and it's everywhere.

The thing is, most people building with AI right now don't realize they're producing the same architecture as everyone else. Each project feels like a fresh start. The assistant gives you a clean scaffold, the code works, the structure looks thoughtful. It doesn't feel like a default. It feels like a decision.

That's the core problem. Not that the default stack is bad — it's often perfectly fine. But that thousands of engineers are adopting it without realizing it was never chosen. The AI chose it for them, based on what it generates most fluently, and presented it with enough confidence that nobody questioned it.

The scaffold picks your architecture

Most people don't sit down and say "design me an architecture for 500,000 requests per second." Not because they lack the skill — but because they don't have those numbers yet. They're figuring out the product. So they say:

"I want to build a bidding platform, help me get started."
"I need an IoT dashboard. Set up the project and write the ingestion endpoint."
"Help me build a crypto exchange. Start with the order placement API."

Feature by feature. Conversationally. And at each step, the assistant picks the stack it can scaffold fastest — TypeScript, PostgreSQL, React — because that's what it generates most fluently. Each individual feature is small enough that the default stack is "fine." The model never encounters a moment where it has to say "wait, this won't work."

The architecture gets locked in at the first npx create-next-app and never gets revisited. Not because anyone chose it. Because nobody stopped to choose.

The models know better. They just don't act on it.

This is the part that surprised me. The crucial split wasn't between models or even between problems. It was between architecture mode and build mode.

Across architecture-mode prompts, the models gave genuinely good answers. Rust for the bid engine. Aerospike for feature lookup. Kafka for event streaming. They discussed lock-free data structures and kernel-bypass networking. Across Variants A and B, Rust was the primary backend language in 45% of recommendations. PostgreSQL was the primary database in 53% — but many of those designs still paired it with specialized stores.

Then I switched to build mode. Same problems, same models, same underlying domains — but now the prompt was "help me build this."

That's where everything collapsed. Across the benchmark, Rust fell from 43 architecture-mode recommendations to zero in build mode. TypeScript jumped from 2 to 25. Python went from roughly absent to 15. SQLite went from 0 to 12. ClickHouse, Aerospike, and ScyllaDB disappeared entirely. The stack novelty score — a measure of how many components fall outside the default web-app stack — dropped from 11.2 to 4.0.

The models know the right answer. They proved it thirty minutes earlier. They just don't use it when you say "help me build."

The monoculture is invisible from the inside

This is what makes it different from previous waves of stack convergence. When Rails was everywhere in 2010, people knew they were choosing Rails. They could name their stack, defend it, argue about it. The choice was visible.

With AI-assisted development, the choice is invisible. You didn't pick TypeScript + PostgreSQL. You asked for help building something and that's what appeared. It feels bespoke because the AI generated it specifically for your project. But the architecture underneath is the same one it generates for every project, because it's optimizing for scaffold fluency, not for your problem.

That's why the monoculture grows without anyone noticing. Each developer thinks they're building something custom. Nobody looks around and realizes the foundation is identical across thousands of products.

The AI didn't invent this. It industrialized it.

I should be fair — I use AI assistants daily and they've made me dramatically more productive. This isn't an argument against AI-assisted development. It's a field note from inside the machine.

A lot of this convergence existed before AI. Hiring availability, library ecosystems, managed cloud support, tutorials, startup pressure to ship — all of these already pushed teams toward the boring stack. Even without AI, many teams would choose Python + Postgres + React.

But before AI, that choice involved friction. You had to read docs, compare options, talk to other engineers, live with uncertainty. That friction was annoying, but it was productive. It forced architecture to be a thinking exercise.

AI removes the friction. And what gets lost isn't speed — it's the argument. The internal debate that used to happen before a stack was chosen now never occurs, because a complete, working scaffold appears before you have time to doubt.

The boring stack is often the right stack. The danger is when it's chosen by the scaffold instead of by the engineer.

I'm not immune

I saw this in my own work while building Edictum, my open-source runtime governance framework for AI agents. I'm a platform engineer. I run Kafka clusters and Kubernetes infrastructure professionally. I hold a Kubestronaut certification. I know what production event-driven systems look like.

And still, when I sat down to build with AI assistance, I shipped FastAPI + React + PostgreSQL. The exact default. Not because I chose it after evaluation, but because the AI made it effortless and I was optimizing for speed.

A prospective client asked me how I was thinking about scale. And I started talking about Kafka, event ingestion pipelines, ClickHouse for analytics. That's what I do professionally. Then I looked at what I'd actually built and realized none of that knowledge was in the product. The AI had scaffolded a perfectly functional FastAPI monolith, and I'd let it.

The model doesn't make you worse. It makes you generic. And you don't notice until someone asks a question that forces you to look at what you actually built versus what you know.

What this means

Right now, thousands of products are being built on the same invisible foundation. The same databases for the wrong workloads. The same frameworks for problems they weren't designed for. The same patterns, the same dependencies, the same scaling ceilings — all chosen by AI assistants optimizing for fluency rather than fitness.

When those products hit scale, the rewrites will come. And the fix is never incremental. You don't "add Kafka" to a Next.js app. You don't bolt ClickHouse onto Supabase. You don't retrofit event sourcing into a CRUD scaffold. You rewrite.

The time saved by not having the architecture argument up front gets repaid with interest. And the interest rate is brutal, because by then you have users, data, integrations, and a team that learned the wrong patterns.

The AI monoculture is real. It's growing. And most people building inside it have no idea they're there.

The question every founder and tech lead should ask themselves:

Would I have built it this way if I had to justify every decision to a staff engineer?

If the answer is no, you don't have an architecture. You have a default.

The data

I tested GPT-5.4, Claude Opus 4.6, Claude Sonnet 4.6, Kimi K2.5 (Moonshot AI), GLM-5 (Zhipu AI), and MiniMax M2.5 across four problem briefs: real-time bidding platform (AdTech), IoT telemetry platform (Industrial IoT), government benefits portal (GovTech — the control, where a boring stack is actually correct), and cryptocurrency exchange (FinTech).

Each problem was prompted three ways:

Variant A — "Design the architecture." Open-ended.
Variant B — "Design the architecture for these hard requirements." With specific numbers.
Variant C — "Help me build this. Set up the project, pick the stack, write the scaffolding." The vibe coding prompt.

Six models × four briefs × three variants × two temperatures = 144 completions. Responses were parsed using Claude Sonnet 4.6 as a structured extraction layer, validated manually on a 10% sample.

The numbers

Variants A and B (architecture mode, 96 responses):

PostgreSQL as primary DB: 53%
Rust as primary language: 45%
React correctly omitted: 64%
Models chose Aerospike, ScyllaDB, TimescaleDB, ClickHouse for the right problems
Mean stack novelty score: 11.2

Architecture mode (A+B) → Build mode (C):