I gave GPT-4 a scenario: small team, language learning app, still choosing tech stack. Asked what the biggest challenge would be.
Answer: scalability. Then a full enterprise checklist—auto-scaling, message queues, Redis, load balancers, performance monitoring.
The team hadn't written a line of code yet.
The Contradiction
I pushed back: "Isn't premature optimization the root of all evil?"
The model immediately agreed. Cited Knuth. Explained MVP methodology. Said the right approach is to launch fast, measure real bottlenecks, optimize based on data.
So I asked the obvious:
Me: You just gave me enterprise architecture for a team that hasn't picked a programming language. Why?
AI: You're right. I contradicted myself. For a small team at this stage, the answer should have been: don't worry about scale. Build something. Ship it. See if anyone cares.
The model knew the correct answer. It had the knowledge encoded in its weights. But its first instinct was to show off technical depth instead of giving useful advice.
This Is a Training Data Problem
Stack Overflow, dev blogs, conference talks—most technical content online is about solving scale problems. That's what gets upvotes. That's what sounds impressive.
Nobody writes blog posts about "I used SQLite and it worked fine." The incentive structure of the internet rewards complexity porn.
So when you train a model on internet text, it learns that "good advice" means comprehensive, scalable, future-proof solutions. The model is pattern-matching on what impressive engineers say, not what actually helps.
Concrete Examples
Indie dev asks about database choice: Model recommends PostgreSQL with read replicas, connection pooling, and a caching layer. Actual answer: SQLite handles 100k daily users fine. Litestream for backups. Done.
Startup asks about auth: Model suggests OAuth 2.0 with PKCE, JWT rotation, refresh token families, and a dedicated auth service. Actual answer: Clerk or Auth0. Literally two lines of code. Ship the product.
Solo founder asks about deployment: Model explains Kubernetes, Helm charts, GitOps workflows, and multi-region failover. Actual answer: Single VPS. PM2. Nginx. You don't need high availability when you have 50 users.
In all three cases, the model has the simple answer in its training data. It just doesn't surface it first because simple answers don't sound authoritative.
The Industry Pattern
This isn't just AI behavior. It's how the entire industry operates.
22 years in software. I've watched teams spend six months on infrastructure for apps that never launched. Perfect CI/CD pipelines deploying to zero users. Microservices architectures for CRUD apps.
Segment ran on a single server for years. Basecamp still doesn't use Kubernetes. Plenty of Fish was a single developer on bare metal handling 30 million users.
The boring tech stack usually wins. But "we used boring tech and it worked" doesn't get engagement. So the signal gets drowned in noise about distributed systems.
The Fix Is Context Awareness
When I said "small team, still choosing programming language," that was explicit context. The model had all the information needed to give the right answer. It ignored the context because the training reward function optimizes for sounding smart.
The model should have weighted those constraints higher. Instead, it defaulted to impressive-sounding completeness.
Better training would penalize answers that don't account for stated constraints. If someone says "early stage startup," suggesting Kubernetes should trigger a loss function penalty. Not because Kubernetes is bad—but because the answer doesn't match the context.
Until then, the workaround is explicit prompting: "I have zero users. Give me the simplest possible solution."
You shouldn't have to say that. But you do.