LLMs seem to code the way kids build with Legos: piece by piece, never stepping back to see the big picture.
A Simple Task
I asked Replit and other code generators to “make me a personal site with a terminal vibe.” Replit delivered the best design - I was quite happy!
However, it also delivered:
- 81 files, 14,925 lines of code.
- 83 npm packages (62 in production).
- Postgres, Drizzle ORM, Express server, shadcn/ui, and a wall of CSS.
Looking at the code, it felt like someone mailed me 200 bicycles when all I wanted was one sturdy car.
The 200 Bicycles Problem
Here’s what I think happens: to the LLM, every problem gets its own (expensive) solution. Auth system? Import a library. Styling? Grab a different framework.
It doesn’t think about unification or dependencies outside each small scope. To a human, the obvious move is to build one unified, low-dependency solution. But the AI optimizes locally, not globally.
Look at the database choice alone. Why Postgres for a one-author blog? The schema had users and posts tables. What users? I’m the only one editing.
The CSS told the same story. Custom classes fought with Tailwind utilities. Inline styles snuck in everywhere. Three different approaches to the same styling problems, sometimes in the same component.
The Cleanup
I opened the repo in Cursor and asked Claude Code to help me strip it down. The prompts were simple:
- “Delete every file that imports express.” 63 files vanished.
- “Convert Postgres storage to SQLite. One file only.” Done. (Subsequently, I realized we didn’t need a database at all! Markdown files were my simple, unified solution to “data”.)
- “Replace custom CSS with Tailwind utilities; remove the rest.” Two passes, 280 lines gone.
After running through the prompts, I had a single massive commit that deleted most of the codebase:
- 9,193 lines
- 61 packages
Package counts before vs. after:
| Replit generated | After cleanup | |
|---|---|---|
| Prod deps | 62 | 13 |
| Dev deps | 21 | 9 |
| Total | 83 | 22 |
A 73% overall cut, 79% fewer dependencies shipping to users. During this process, we also made improvements to the UI, which actually looked better, despite the code-slashing happening behind the scenes.
Reflections
The problem of good code is to solve a specific set of problems efficiently. AI hasn’t perfected this yet. It solves problems, sure, but not always efficiently.
I’m sure this is just a matter of time. Think about libraries like PyTorch or Postgres — extremely efficient, minimal dependencies, unified design. When AI learns from codebases like that, it’ll stop shipping 200 bicycles.
Until then, my personal takeaways:
- Your job is architecture, not construction. Spend time planning the structure before letting AI pour the foundation.
- Let the AI build, but edit hard. Generation is cheap; pruning is where quality happens.