LLM-Optimized Codebase Architecture
Structure your repo so the AI writes the least code possible — infrastructure absorbs the complexity.
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 90%
Maor built and shipped an $80M product without writing a line of HTML or JavaScript in three months by deliberately architecting the codebase for AI agents rather than humans. The core move: a high-level, opinionated infrastructure that handles CRUD, auth, and database so the LLM emits minimal code per feature — fewer places to make mistakes, less context to track. He pairs this with counterintuitive stack choices tuned to how models actually behave.
Origin
Maor Shlomo's engineering approach for Base44, which he also applied to his own Cursor-driven backend; he spent 20-30% of his time optimizing the repository to be LLM-suitable.
Core principles
- 01Every extra token the LLM must emit is another place it can get confused or lost in context
- 02Give the model a rich SDK and opinionated infrastructure; let it write only the feature-specific glue
- 03Optimize the codebase for the model's failure modes, not for human elegance or convention
- 04Route different tasks to different models by their strengths rather than using one model for everything
How to run it
- 1
Build opinionated infrastructure that absorbs the boilerplate
Create a high-level code infrastructure that handles CRUD, authentication, and the database automatically, so implementing a new feature requires the LLM to write very little code.
Pro tip Push the LLM toward implementing the whole feature end-to-end while emitting as few tokens as possible — the infra does the heavy lifting.
Watch out More generated code from scratch means more mistakes and more context the model must retain for follow-up prompts.
- 2
Choose plain JavaScript over TypeScript for AI-written frontends
Use plain JS (ES6) instead of TypeScript because models write it more reliably. Base44's platform frontend is ES6, not TS.
Pro tip This is a deliberate trade against human convention in favor of model accuracy.
Watch out Controversial and context-specific — Maor flags it as his own take, not a universal rule.
- 3
Keep frontend and backend in one repository
Push as much as possible into a single repo instead of splitting front and back end, so the AI has full context of both sides at once.
Pro tip Shared context reduces the model's confusion about how the halves connect.
- 4
Route each task to the model that's best at it
Analyze the user's prompt and route it: use a strong model for initial scaffolding and UI/design, a reasoning-strong model for complex algorithms or bug loops, and small fast models to patch code into existing files.
Pro tip Use 'heavy guns' (e.g. Claude or Gemini) to decide the high-level change to a file, then a small fast model (e.g. Flash or a mini) to apply the patch — you don't rewrite the whole file every time.
Watch out A single model for all tasks leaves speed and quality on the table; different models excel at different steps.
In the wild
Because the infrastructure was so opinionated and the stack so model-friendly, Maor let the AI write essentially all frontend code. He reports not writing a single line of HTML or JavaScript in his last three months, yet the Base44 frontend changed constantly.
→ Sustained a shipping velocity that matched or beat far larger, better-funded competitors as a solo founder.
Base44 analyzes each user request and routes it — Claude for initial app generation and UI, Gemini for hard algorithmic problems or when Claude gets stuck in a bug loop — then uses smaller fast models to patch the specific code chunk into the file.
→ Reliable complex app generation without regenerating entire files each turn.
Common mistakes
Letting the LLM write everything from scratch
Without an absorbing infrastructure the model emits far more code, multiplying error sites and bloating the context it must carry into follow-up prompts.
Defaulting to TypeScript and split repos out of convention
Human-optimal conventions can degrade model output; Maor found plain JS and a monorepo measurably easier for the AI.
Is it for you?
Best for
Solo founders and small teams building AI-generated or vibe-coded software who want to maximize shipping velocity
Not ideal for
Large teams with established human engineering workflows, or performance-critical systems where TS type-safety and micro-optimization outweigh model ergonomics
From the transcript
“I tried making the LLM write as least code as possible”
“provide the LLM with a really good infrastructure and SDK”
“don't use TypeScript, use plain JavaScript, use JS6. Uh it's easier for models to write code this way”
“try to push as much as possible in the same repository instead of like separating the front end and the back end”
“I use a mix of different models for different tasks”
“you have the heavy guns which is usually either cloud for or gemini”
“get like smaller faster models like flesh or faux mini from openai to implement to kind like uh to patch the code”
From the episode
Solo founder, $80M exit, 6 months: The Base44 bootstrapped startup success story
Maor Shlomo