Make software by describing it
BBuilt with Prompts

Make software by describing it

How to Save Working Versions of AI-Written Code

The simplest way to save working versions of AI-written code is to copy the file with a version number every time it passes your tests. This gives you a safe state to return to when a later change goes wrong, and it needs no tools beyond your file manager. If you outgrow it, Git does the same job with more features.

The important part is not the method but the habit: save a version at the moment the project works, not later from memory.

Why you need versions

Code from an assistant changes in surprising ways. A request to adjust a button can lead to a rewritten function, and the page may look fine while something else quietly fails. Without a saved version, you may find yourself unable to recover the state that worked an hour ago.

Chat history is not a reliable backup. Conversations can be long, edited or lost, and the code in them may not match what you actually ran. Keep your versions in files you control.

Method one: numbered copies

For a single file project, this is enough:

  1. When the file passes your tests, copy it.
  2. Name the copy with a version number: converter-v1.html, converter-v2.html.
  3. Keep the current working file under a plain name, such as index.html.
  4. Store the copies in a versions folder.

Number versions in order and never reuse a number. If you want to describe the version, add a short word: converter-v3-reset-button.html. Names should be short enough to read in a list and specific enough to recognize.

Method two: dated folders

For projects with several files, copy the whole folder into an archive and name it with the date and a counter: 2026-09-19-a. This works when you cannot remember which files changed. The downside is that folders pile up, so delete old ones once you are sure you do not need them.

Do not archive folders inside the project folder you upload to a host. Keep the archive next to the project, not in it, so you do not publish old copies by accident.

Method three: Git

Git records snapshots called commits with messages, and shows what changed between them. It takes some learning, but it keeps a clean history without extra files. Our beginner guide covers the basic commands. If you use a host that connects to a repository, you will likely meet Git there anyway.

You can use numbered copies and Git together while you learn: the copies are a fallback, and the repository is the record.

When to save

Save a version at these moments:

The second item matters most. The best time to protect your project is the minute before you change it.

Write a note with each version

A file name tells you the number, but not what changed. Add a line to your project log for each version: “v4: added CSV export. Tested with 3 and 50 rows.” If you later need to find when a bug appeared, the notes let you test the right versions instead of guessing.

Record which assistant you used and any important setting, since this can matter if you later want to reproduce a result.

Restoring a version

When a change goes wrong:

  1. Stop editing the broken file.
  2. Copy the last good version over it, or open the good version directly.
  3. Run your tests to confirm it works.
  4. Look at what you asked for in the failed attempt and rewrite the request more carefully.

If you are unsure which version was the last good one, test them from newest to oldest until you find one that passes. This is much faster than debugging a broken file with no reference point.

Compare versions

When you need to see what changed between two files, use a comparison tool. Many code editors can compare two files side by side and highlight differences, and several free tools do the same. Differences show lines the assistant changed without being asked, which is often how you discover why something broke.

Paste the differences to your assistant, along with the symptom, and ask what caused it.

Back up outside your computer

Versions on one disk are lost if the disk fails. Copy your project folder to cloud storage or an external drive at least once a week. A synced folder is the easiest option. Check that the backup actually contains your latest files by opening one.

Mistakes to avoid

Do not overwrite a working file before saving a copy. Do not keep versions only in the chat. Do not name files final, final2 and really-final; numbers are clearer. Do not delete old versions until the project is stable.

Naming that stays readable

Choose a naming scheme on day one and keep to it. A pattern such as project-v01, project-v02 sorts correctly in a file list, even once you pass nine versions. Adding a leading zero costs nothing and avoids v10 appearing before v2.

Keep one file or folder that is always the current working copy, and treat the numbered ones as read-only history. If you edit an old version by accident, copy it to a new number instead of overwriting. And when you share a version with someone, tell them its number, so any feedback you receive refers to a file you can find again.

Next steps

Create a versions folder in your current project and save the working file as v1. Add a line to your log. From now on, copy the file before every change you ask an assistant to make. After a week, test whether you could recover from a broken file in under a minute.