Pieter Levels — @levelsio — is currently judging Vibe Jam 2026, which received nearly 1,000 submissions. His own tracking of project success rates across his builds shows an 8% hit rate. The gap between “AI built it fast” and “it’s running at scale six months later” is mostly about what kind of codebase the AI built — and what constraints shaped it.
AI-generated code accumulates fast. That speed is the feature. The codebase it leaves behind is the consequence, and it is shaped almost entirely by what the AI was working within when it generated the code. Start with the right template and the footprint grows coherently. Start from a blank file and it grows as a record of every assumption the AI made independently across every session.
mindmap
root((Vibe Coding<br/>Template Controls))
Directory Structure
Module boundaries
Feature folders vs shared
Naming Conventions
Files and functions
Routes and variables
Tech Stack
Framework locked
Auth library defined
ORM selected
Testing Patterns
Unit vs integration scope
Test file placement
Security Defaults
Input validation setup
Secret management
Auth middleware location
What a Code Footprint Is and Why It Compounds
A code footprint is the accumulated mass of AI-generated code in a project — its size, structural consistency, and architectural coherence over time. Traditional development builds a footprint slowly enough that inconsistencies get caught and resolved in the normal review cycle. Vibe coding builds a footprint at a pace where inconsistencies accumulate faster than they are found.
In a project started from a blank file, the AI has no constraints. It makes choices in every session: what to name things, where to put files, which library to use for a given task, how to handle errors, whether to validate inputs before processing them. Those choices accumulate. By the time a project has grown substantially, it often contains several distinct architectural styles — because the AI made different stylistic choices in different sessions depending on what it was generating at the time.
The code typically works. It is also difficult to modify, extend, or hand off — whether to another developer or to the AI in a later session — because the AI has no persistent memory of the structural decisions made previously. Each session, it reasons from the code it can see in context. If that code is structurally inconsistent, the next session adds to the inconsistency.
The Template as the AI’s Persistent Architectural Memory
The AI cannot remember the project’s architectural decisions from session to session unless those decisions are embedded in the context it receives. A starter template is how you provide that persistent memory.
A good template communicates to the AI the decisions it should not make independently: how the directory is structured, what the naming conventions are, which libraries handle which responsibilities, how tests are written and where they live, what the authentication pattern is, and how secrets are managed. When the AI operates within a template that has made those decisions, it generates code that is consistent with everything already written — because the template tells it what “already written” looks like and what it follows.
The difference in codebase quality between AI working with an opinionated template and AI starting from a blank slate is not subtle after a few months of development. The template-constrained project has a navigable, extensible structure. The blank-slate project has a codebase that reflects the AI’s accumulated assumptions, which vary by session.
What Happens Without Constraints: The Carvana Comparison
At Carvana — before the company’s IPO — I led a team of five developers building inventory and vehicle-data systems that parsed millions of vehicle records daily using event-driven architecture. The team was small but technically disciplined. What made that work at scale was not only the talent; it was the architectural consistency enforced from the beginning. Every developer knew where things went, how they were organized, and what patterns were followed. That consistency made the system navigable and extensible as the company grew.
Vibe coding introduces a structural challenge that small, disciplined developer teams do not face: the AI is effectively a developer who has no memory of the project’s architectural decisions unless those decisions are provided to it. A template is the mechanism for providing that context. Without it, each session produces code that makes local sense and global inconsistency.
Architecture-First Works Outside the Startup-Elite Setting Too
A counterargument I hear is that architecture-first discipline only pays off when the developers executing the work are already strong — that on contractor-heavy teams or in environments without a startup’s hiring bar, the upstream investment in structure gets diluted by the talent gap. My experience says otherwise. At a class-action settlement administration company, I was asked to tackle one of the hardest projects on the board: a USPS returns processing and fulfillment automated workflow that had to interoperate with the Postal Service’s tangle of API interfaces. This was years before modern AI tooling existed, so there were no models to lean on for orchestration logic — every rule, trigger, and exception path had to be reasoned through directly.
The team executing the work was not a hand-picked startup unit. It was a typical contractor-heavy environment with the variability in skill that implies. I architected the full workflow at the outset — every integration point, every state transition, every fallback — before any code was written. The recommendation to the organization was simple: let architecture drive the sequencing, not development speed or proximity to a favored tool. They committed to that arc, and the entire returns processing fulfillment system was rebuilt from scratch with near 100% accuracy. The lesson generalizes to vibe coding directly. A strong template does for AI what an upstream architecture did for that contractor team: it removes the categories of decisions that talent variability would otherwise express as inconsistency. The constraint absorbs the gap.
What Goes in the Template
The decisions worth hardcoding in a starter template are the ones that are most expensive to change after the fact:
Directory structure and module boundaries. Where do features live? Where do shared utilities go? Where do tests live relative to the code they test? AI tools will place things wherever seems reasonable in context — define it once and the AI will follow it.
Naming conventions. Files, functions, variables, routes, database tables. Inconsistent naming across a codebase is one of the highest-friction forms of technical debt to address later, because it touches references throughout the project.
Tech stack choices. Framework, ORM, auth library, state management, API style. Once committed in the template, the AI uses them consistently. Without that commitment, a later session may introduce a second option simply because the AI was trained on it and it fits the task at hand.
Testing patterns. Unit versus integration scope, test file placement, mock strategy. AI-generated tests are only as useful as the pattern they follow — a clear pattern produces tests that communicate intent; an absent pattern produces tests that are harder to interpret than the code itself.
Security defaults. Input validation setup, secret management conventions, authentication middleware placement. These are exactly the categories where AI-generated code most commonly deviates from safe practice when not explicitly constrained. Establishing the secure pattern in the template means the AI follows it throughout.
The First Conversation Sets the Trajectory
A good template is the first conversation with the AI about what the project is and how it should work. The AI brings capability to that conversation; the template brings architectural judgment. Neither alone produces a sustainable codebase.
The 8% hit rate Levels tracks is not a commentary on AI’s capabilities. It is a reflection of how much of vibe coding starts without the architectural foundation that makes a project extensible past the initial build. The projects that reach sustainable production have structure from the start — not because structure limits what they can do, but because structure is what makes the doing sustainable over time.
