Andrej Karpathy marked the one-year anniversary of vibe coding with a reflection on what it had become. The original post — a late-night observation that AI assistants were now good enough to “forget the code even exists” — had taken on a life the author himself described as unpredictable. What it left behind in codebases across the industry is a more complex story.
Fast code generation is the visible part of vibe coding. The less visible part is what gets deposited alongside it.
stateDiagram-v2 direction TB state "AI generates initial code" as Gen state "Review and refine output" as Rev state "Extract reusable patterns" as Extract state "Formalize into starter template" as Template state "Technical debt accumulates" as Debt [*] --> Gen Gen --> Rev Rev --> Extract Extract --> Template Template --> [*]: Reusable foundation Rev --> Debt: Ship and move on Debt --> [*]: Code you cannot build on
What Vibe Coding Leaves in a Codebase
When a developer or team uses AI assistance to build several features over a sprint, they are not just building features. They are accumulating a set of patterns: naming conventions, dependency choices, data model assumptions, error-handling idioms, and architectural decisions — all implicit, none discussed, most inconsistent across sessions.
If those patterns are never examined, extracted, or codified, the codebase becomes harder to navigate with each passing sprint. Different AI sessions handle the same problem differently. The next engineer to extend the code finds five different conventions doing the same thing. The AI, given no prior context, invents a sixth.
This isn’t a criticism of AI-assisted development. It’s a description of what happens when any fast development approach runs without architectural discipline. The AI accelerates output; the discipline is what makes that output compounding rather than degenerative.
The Insight That Became a Framework
A few years ago, I was working as a solution architect at a mortgage fintech in Southern California, leading the development of an Angular-based loan origination platform. The codebase was front-end heavy, with a component library that had been carefully built to cover the common UI patterns — forms, tables, navigation, user management — in a reusable, consistent way.
What struck me was the leverage. Once the library existed, every new feature cost less to build because the pieces were already there. The design decisions had been made once and applied consistently everywhere. A developer building a new screen wasn’t starting from scratch; they were composing from a vocabulary the team already shared.
That observation was memorable enough that I later built a similar framework from scratch — CleenUI — covering the 15 most common application areas: security, user management, content management, and the rest. The framework reflects exactly the insight from that engagement: the compounding returns of a well-designed starting point are significant, and the cost of building one is bounded, while the cost of not having one is unbounded.
In the AI era, the same logic applies at higher velocity. The AI can build faster than any developer. What it cannot do is remember what your team decided last sprint. That memory has to live somewhere.
What Starter Templates Actually Are
A starter template in the context of vibe coding is not a boilerplate. It’s a record of decisions.
It encodes: the data model patterns your team has validated in production, the service boundaries that fit your architecture, the error-handling approach that works in your environment, the naming conventions that make the codebase navigable, and the integration patterns that have been tested against your actual systems.
When you give the AI a well-designed starter template, you aren’t constraining it. You are giving it the context it needs to generate output that fits your system rather than a hypothetical generic one. The AI becomes a fast executor of a well-defined pattern rather than an inventor of new conventions on every session.
The teams doing this well are not necessarily the fastest prompters. They are the ones who, after each successful AI-assisted sprint, ask: what did we build here that worked? What should become the standard? And then they write it down.
The Discipline Looks Like This
After each AI-assisted development session, spend 15 minutes identifying the decisions worth keeping:
Which data model choices held up under review? Which component patterns are reusable elsewhere in the system? What does the error-handling approach look like, and is it consistent with what was built last sprint? Which naming conventions did the AI default to, and are those the conventions the team actually wants?
Not every session produces something worth extracting. But over a quarter of AI-assisted development, a team that does this consistently builds a living reference — a starter template that reflects what they have actually built, not what a model trained on the general internet considers conventional.
Teams that treat their codebase footprint as a choice rather than a side effect are the ones that compound their productivity over time. Vibe coding gets faster with each project when the starting point keeps improving. It gets slower when every project starts over.
