Adding a Feature With AI Without Breaking What Works
The safest way to add a feature with an AI assistant is to save a copy of the working file, ask for one change, test the new feature, and then retest everything that worked before. This takes a few extra minutes per change and prevents the most common way beginner projects fall apart: a feature that quietly breaks something unrelated.
Most trouble comes from skipping one of those steps, usually the copy and the retest.
Why working projects break
When you ask an assistant to add something, it often rewrites parts of the file to fit the new code in. Most of the time that is fine. Occasionally it renames a function, changes how data is stored, or removes a line it thought was unnecessary. The new feature works, and an old one stops.
You will not always notice right away. A save button might fail only when the list is empty, or a total might be wrong only after a deletion. Problems like these show up days later, when it is hard to remember which change caused them.
Step one: save a working copy
Before you ask for anything, copy the current working file and rename the copy with a version number, such as tracker-v3.html. Keep your copies in a folder called versions. The cost is ten seconds.
If you know how to use Git, use it instead; our guide to Git for beginners covers the basics. Either way, the goal is the same: you can return to a known good state in one move.
Step two: ask for one change
Describe a single feature, with its behavior and edge cases. Compare:
- Weak: “Make it better and add more options.”
- Strong: “Add a Clear Completed button below the list. It removes all checked tasks after a confirmation. If no tasks are checked, the button is disabled.”
Add limits to protect the rest of the file: “Do not change existing functions or the layout of other sections. Show me only the parts that change.”
Asking for only the changed parts lets you see exactly what moves, which makes review easier even if you do not read code fluently.
Step three: apply carefully
If the assistant gives you changed fragments, paste them in the right places. Mistakes at this stage are common, such as pasting inside the wrong block. If you are unsure where something goes, ask: “Tell me exactly which line to replace, using the text before and after it.”
If you prefer a full file, ask for it, but compare the result with your saved copy. Many editors can highlight differences between two files. Look for deleted lines you did not request.
Step four: test the new feature
Run the feature in the normal case and in at least two edge cases. For Clear Completed, test with a few tasks checked, with none checked, with all checked and after reloading the page. Write down what you expect before you click, so you notice any surprise.
Step five: retest the old features
This is the step people skip. Keep a short checklist for your project that covers everything it should do. For a to-do app it might read:
- Add a task.
- Mark it done and undo.
- Delete a task.
- Reload and check that tasks persist.
- Try an empty task.
Run it after every change. Five items take a minute. If anything fails, you know the latest change is the cause, because it was the only change since the last passing run.
Write a one-line change note
After each successful change, add a line to your notes: the date, the version number, and what changed. For example, “v4: added Clear Completed button, tested with zero, some and all tasks checked.” It takes ten seconds and answers a question you will otherwise face later: which version added that behavior, and which one still has the old bug?
The note also helps when you ask an assistant for help. You can paste the last few lines and say what you changed recently, which narrows the search for the cause. People who keep these notes tend to recover from mistakes quickly, because the history is already written down in plain language.
Rolling back
If the new code breaks things and a quick fix does not work, go back. Copy your saved version over the current file and try again with a different prompt. Do not feel obligated to rescue a bad edit. Ask the assistant for the feature again, with the failure described: “Last time, adding this broke saving. Keep the existing save function unchanged and add the feature around it.”
Rolling back is not failure. It is the reason you saved a copy.
When a feature is too big
If a feature touches many parts of the project, break it into steps that can each be tested. Adding user-chosen categories, for example, might become: first add a category field to new items, then show it in the list, then add filtering by category. Each step ends with the project in a working state.
If the assistant proposes a rewrite from scratch, ask whether the change can be done in smaller pieces. A rewrite is sometimes right, but it should be a deliberate choice, with the old version saved.
Be patient with the routine. The first few times, it feels like busywork, especially when the change is tiny. The payoff comes the first time a change goes wrong and you restore a working file in seconds instead of spending an evening untangling it. People who skip the routine usually learn its value the hard way, and it is much cheaper to learn it here.
Next steps
Write your project’s checklist now, with five to eight items, and save it in your notes file. Then choose one small feature, save a numbered copy, and follow the five steps. Record in your notes what you asked, what broke if anything, and how long the routine took. After two or three changes it will feel routine.