Adding Features Without Breaking Everything

Why Adding Features Is the Hardest Part

Building your first version is actually the easiest part of vibe coding. You start with a blank slate, write a clear prompt, and the AI has nothing to conflict with. Adding features to a working app is harder -- because now the AI has to change existing code without breaking what's already there.

The AI doesn't have a complete understanding of your app. It edits files based on your instructions, and sometimes a seemingly unrelated change affects something you weren't expecting. The most common complaint from vibe coders at this stage: "I asked for one thing and something else broke."

The techniques in this lesson prevent that. They're not complicated -- they're mostly about communication and discipline.

Test Before You Add Anything

Before asking for a new feature, spend 60 seconds verifying your app is working correctly right now. Go through the core workflow. Click the main buttons. Add a record and confirm it saves. If something's already broken and you don't notice until after adding a feature, you won't know whether the feature caused it or something else did.

This one habit will save you significant frustration:

Before asking for anything new, confirm the app is fully working in its current state. If it isn't, fix it first.

A broken foundation makes every new feature harder to add -- and harder to debug when things inevitably go wrong.

One Feature at a Time

This is the most important rule in this lesson: ask for exactly one new thing per message. Not two. Not "while you're at it, also..." Just one.

When you bundle multiple requests -- "add a search bar, change the header color, and add an export button" -- the AI attempts all three simultaneously. It usually gets some right and some wrong, and the wrong ones are hard to isolate and fix because they're tangled with the right ones.

One feature at a time feels slower but isn't. Testing and approving each change before moving to the next one means you almost never have to backtrack. The total time from idea to working feature is reliably shorter.

Instead of: Add a search bar, an export to CSV button, and change the table to show 20 rows instead of 10.

Better: Add a search bar above the contact table that filters by name as I type. [Test it. Then in a new message:] Now add an export to CSV button in the top-right corner.

Tell the AI Exactly What Not to Change

The most powerful technique for protecting working features is also the simplest: tell the AI explicitly what to leave alone.

Any time you ask for a change, add a constraint sentence at the end:

Add a "completed" toggle to each habit card. Do not change the card layout, the streak counter logic, or how habits are stored in the database.

Change the background color of the header from gray to dark blue. Do not touch anything else -- just the header background.

These constraints aren't just defensive -- they also make the AI's job easier. A tightly scoped instruction produces more predictable results than an open-ended one. The AI isn't guessing about intent; you've told it exactly where the boundaries are.

Use Version History as Your Safety Net

Lovable saves a snapshot of your project every time you make a change. Before tackling any significant feature -- adding authentication, restructuring the layout, changing how data is stored -- take note of where you are. If the new feature goes sideways, you can revert to that snapshot and try again with a more precise prompt.

Think of version history as a save point in a video game. You wouldn't spend an hour on a hard level without saving. The same logic applies here: every stable working state is worth preserving before you push forward.

With testing, one-feature-at-a-time discipline, and explicit constraints, you'll find that regressions become rare. Most feature additions go smoothly -- and when they don't, you have a clear path to recovery.

In the next lesson, you'll learn how to connect a real database to your app -- so your data lives permanently, not just in the browser.