What Is a Framework in Programming? (And Why Your Vibe-Coded App Keeps Breaking)

You built an app with an AI tool. It ran fine for a couple of weeks. Then you asked for a new feature and three things broke. You prompted to fix them, and two more broke. You prompted again, and something that worked perfectly last week stopped working.

You're not bad at prompting. You're fighting a system you don't understand.

That system is called a framework, a collection of decisions someone already made about how your app is organized. It determines how your files are structured, how URLs map to pages, how data flows from backend to screen. It decides how components talk to each other. If you used a vibe coding tool like Lovable, Bolt, or Cursor, a framework already chose you, whether you realize it or not. And not understanding it is the reason your app keeps falling apart.

What Does a Framework Do?

Think about what it takes to make even a simple web app work.

A user visits a URL. Something has to figure out what page to show them. Something has to load the right data. Something has to render the interface. Something has to handle what happens when they click a button, fill out a form, or navigate to another page.

Without a framework, you'd need to make every one of those decisions from scratch. That's hundreds of decisions before you write a single line of your actual app.

You've already seen these decisions in action, whether you realized it or not. When Lovable put your pages in /src/pages and your components in /src/components, that was the framework deciding how files are organized. When it generated a useQuery hook instead of a raw fetch call, that was the framework deciding how data flows. When it created a route for /dashboard, that was the framework deciding how URLs map to pages.

A framework answers all of those upfront. URLs work this way. Files go here. Components are structured like this. Data flows through these channels. Errors get caught at these points.

That's why your AI tool can build you a working app in 10 minutes. It's not magic. The AI is working within a system where most of the hard decisions are already made. It fills in the parts that are specific to your idea.

When a user hits /dashboard, the framework decides which file handles that URL, which server code runs, which database tables get queried, and which HTML gets sent back. One system, four decisions, zero input from you.

What Framework Does Lovable Use? (The Framework Already Chose You)

Here's something most vibe coders don't realize: if you used a vibe coding tool, you're already inside a framework. You didn't choose it. It was chosen for you.

Lovable generates every project with the same stack: React, Vite, Tailwind CSS, and shadcn/ui. Bolt.new uses the same defaults. Neither uses Next.js, despite what many people assume.

Those aren't random words. Each one controls a specific part of how your app works:

Technology	What It Decides
React	How your user interface is built and updated
Vite	How your code gets bundled and served to the browser
Tailwind CSS	How styling works across your entire app
shadcn/ui	What your buttons, forms, dropdowns, and components look like
React Router	How pages and navigation work

Together, these form the framework your app runs on. And that framework made hundreds of decisions about your app: file structure, component patterns, data flow, error handling. All before you typed your first prompt.

Cursor works differently. It doesn't pick a framework for you. But if you followed a tutorial or asked the AI to scaffold a project, it probably defaulted to React and Next.js, because that's what dominates the AI's training data. The framework still chose you. Just through a different door.

Framework vs. Library: What's the Difference?

You'll hear these two words used interchangeably. They're not the same thing.

A library is a tool you reach for when you need it. You're in charge. You call the library, it does one thing, and you move on.

A framework is the room you're already standing in. It decided the floor plan. You decide the furniture.

The practical difference: you can swap out a library in an afternoon. Swapping a framework means rewriting your app.

React technically calls itself a library. But when it's combined with Vite, React Router, and a component system like shadcn/ui, it behaves like a framework. It controls the architecture. You build within it. That's why Lovable's "React stack" is functionally a framework, even if no single piece calls itself one.

Why Vibe-Coded Apps Break After 3 Months (The Framework Problem)

This is probably why you're here.

There is a documented pattern in apps built with vibe coding tools. It looks like this:

• Week 1. App works beautifully. Features ship fast. You show it to people and they're impressed.
• Week 3. You ask for a new feature. Something breaks. You prompt the AI to fix it. Something else feels off.
• Month 2. Every fix breaks two other things. You spend more time troubleshooting than building.
• Month 3. You're sitting on code you don't understand, held together by patches stacked on patches.

This isn't just your experience. Estimates suggest roughly 8 out of 10 startups that built production apps with vibe coding tools now need partial or full rebuilds. Costs range from $50,000 to $500,000. An entire category of "vibe code rescue" firms has sprung up to clean up the wreckage.

The root cause isn't the AI tool. It's building inside a framework you don't understand. Three mechanisms cause it.

Context Collapse

AI tools have a limit on how much code they can "see" and reason about at once. In the early days of your project, when the codebase is small, this doesn't matter. The AI can hold everything in context.

Around the 30th file, something shifts.

The AI starts generating fixes that undo work from earlier sessions. It references a database structure you told it to change two weeks ago. It introduces bugs in parts of the app it hasn't looked at in hours. It's not getting dumber. It's losing context.

The framework has rules about how all those files connect. But the AI can only see a few of them at a time. Each fix it generates is correct in isolation, but wrong for the app as a whole. Without someone understanding the bigger picture, nobody catches the disconnects.

Convention Drift

This one is quieter. And more dangerous.

CodeRabbit's analysis of 470 pull requests on GitHub found that "AI-generated code violates framework conventions 2.66 times more often than human code." Naming inconsistencies are nearly twice as common. Readability issues spike more than threefold.

What does that look like in practice?

• The same concept gets called user in one file, account in another, and profile in a third
• The AI generates a fresh solution instead of reusing a component that already exists
• It bypasses the framework's built-in error handling and rolls its own
• It duplicates logic across files instead of importing from shared modules

Each individual violation is tiny. You'd never notice it in a single file. But they compound. GitClear's analysis of 211 million lines of code found that code duplication in AI-assisted projects has increased fourfold since these tools became popular. The AI isn't building on your framework's patterns. It's generating new, disconnected code every time.

Your codebase slowly drifts away from the framework's conventions. Once it drifts far enough, the framework stops helping you. Its tools, its shortcuts, its built-in safety nets all assume you're following the rules. When you're not, they silently stop working.

The Cascade

This is the one you feel directly.

You notice a bug. You prompt the AI to fix it. The fix resolves the immediate error but violates a framework convention you didn't know existed. That violation creates a new problem somewhere else. You prompt again. Another fix. Another hidden violation. More breakage.

One developer who has rescued over 50 vibe-coded apps described the pattern: "The failure is never where founders think it is. It's in something that happened three weeks earlier."

Stack Overflow published a piece about a writer who built an app with Bolt for a hackathon. The foundation was up in 10 minutes. Then she spent 45 minutes copy-pasting error messages back into the AI without understanding any of them. When a developer reviewed the code: no security, no tests, no component structure. Everything inlined into one giant block.

The 66% "productivity tax" from Stack Overflow's developer survey describes it perfectly: AI generates code that is almost, but not quite, right. Without framework understanding, you can't tell the difference.

The Diagnosis

This is not a tool problem. Lovable isn't broken. Bolt isn't bad. The AI isn't failing you.

The problem is building inside a system you don't understand. Every app that survives past six months has the same thing in common: someone on the team can read the generated code and tell whether the AI followed the framework's rules or not.

Do I Need to Understand My Framework?

You don't need to become a software developer. But you do need to understand the rules of the system you're inside.

When you understand your framework's conventions, you stop blindly accepting AI output and start evaluating it. You can spot when the AI created a third authentication flow instead of using the one that already exists. You can see when it ignored a component you already built and generated a duplicate from scratch.

And you can prompt differently. There is a massive gap between these two prompts:

Vague: "Make the login work."

Framework-informed: "Use the existing auth middleware with the users table we already have."

The second one gives the AI constraints. It points at the framework's existing patterns instead of letting the AI improvise new ones. The output improves immediately, not because the AI is smarter, but because you told it where to look.

You don't need to learn to code from scratch. You need enough understanding of the system you're inside to evaluate what the AI generates. That gap is smaller than you think.

Your app didn't break because you used the wrong AI tool. It broke because you were building inside a system you didn't know was there.

Now you know it's there. You have the full mental model: requests, frontend and backend, servers, databases, and the framework that organizes all of them into a single, coherent system. Whether you chose it or it chose you, understanding it is the difference between an app that works for a demo and an app that works for real.

The framework already chose you. The question is whether you'll understand it before the next feature breaks.

Frequently Asked Questions

Is React a framework or a library?

Technically a library. Practically, the React + Vite + Router + shadcn/ui stack that Lovable and Bolt generate behaves like a framework. The takeaway: don't get hung up on the label. If it controls your app's architecture, treat it like a framework.

What framework does Lovable use?

Lovable generates every project with React, Vite, Tailwind CSS, shadcn/ui, React Router, and Lucide React icons. This is a client-side rendered single page application (SPA). It does not use Next.js by default, which is a common misconception. Supabase is available as a backend integration but isn't auto-provisioned on every project.

What framework does Bolt.new use?

Bolt.new uses the same default stack as Lovable: React + Vite + Tailwind + shadcn/ui. The difference is that Bolt runs on StackBlitz WebContainers, which means it can also scaffold Next.js, Astro, SvelteKit, or other Node.js frameworks if you explicitly ask. But if you just type "build me an app," you get the same React + Vite SPA that Lovable produces.

Do I need a framework to build a web app?

Technically, no. You could build an app from scratch without any framework. Practically, yes. Without a framework, you'd need to decide how routing, file organization, database access, authentication, error handling, and dozens of other things work before writing a single feature. A framework makes those decisions for you so you can focus on what makes your app unique. If you're using an AI coding tool, you're already using a framework whether you chose one or not.

Why does my AI-built app keep breaking?

Most AI-built apps break because of three compounding problems: context collapse (the AI loses track of your full codebase as it grows), convention drift (AI-generated code violates framework patterns 2.66x more often than human code), and the cascade (each AI fix introduces new violations that create more bugs). All three are framework literacy problems. Understanding the framework's rules lets you catch issues the AI introduces.

What's the difference between a framework and a library?

A library is a tool you call. A framework is the system you build inside. The key test: you can swap a library in an afternoon, but swapping a framework means rewriting your app.

Can I switch frameworks after building with Lovable or Bolt?

You can, but it's a significant effort. Lovable generates React + Vite SPAs, and migrating to Next.js requires restructuring the entire project. A growing migration industry exists specifically for this, with services, CLI tools, and tutorials all aimed at converting Lovable/Bolt projects to other frameworks. The earlier you understand your framework's limitations, the better you can plan for or avoid this.