Saving Versions and Going Back

Why you need a way back

In the build steps, you paste the AI's answer over your files. When the answer is good, the game gets better in one move. When it is not, the same move can break things that worked a minute ago: the ship stops responding, the rocks vanish, or the preview stays empty. If you have no copy of the version before, all you can do is ask the AI to repair its own change, which is how a fix loop starts.

A known-good version is a saved copy of a project that you have checked and know to work, kept so you can compare against it or return to it when a later change breaks something. The word that matters is checked: a copy you made without trying it first is only a copy. In this topic, a known-good version is the game after you have gone through the "What you should see" list of a build step.

Going back is not a defeat. With a known-good version in hand, asking again costs you one prompt; without it, a bad answer can cost you an evening.

Saving and autosave in CodePen

A new Pen is not saved until you save it: press Save (⌘S on a Mac, usually Ctrl+S elsewhere), or use the Save button.

Autosave is an editor feature that stores your work automatically at intervals or after changes, without an explicit save. According to CodePen's documentation (as of October 2026), autosave only starts after you have saved a Pen once; from then on it saves every 20 seconds, and it can be switched off in the settings. Autosave is not a PRO feature.

The live preview helps here: it updates automatically by default, so you see the effect of each paste at once. Check the result before you make the next change, while you still know which change caused what.

Version history on a free account

Version history is a record of earlier saved states of a file or project, kept by a tool so that you can view, compare and restore them. CodePen 2.0 keeps one: its documentation says that every save, automatic or manual, creates a version. But it also says that "Accessing a Pen's Version History is a PRO feature." On the free plan the versions exist, but you cannot open them. The table sums up what the free plan offers, as of October 2026:

As of October 2026, CodePen's paid plans for individuals are called Starter PRO, Developer PRO and Super PRO. For this topic the free plan is enough, as long as you make your own copies.

Forks

A fork in CodePen is an exact copy of a Pen, made with Fork in the Pen's actions menu, that you can change without touching the original. You can fork your own Pens and any public Pen, on a free account too.

Forks make good checkpoints for the build steps. When a step works, fork the Pen and give the fork a name that says what it is, such as "RETRO JET · step 3 · works". Then keep building in one Pen and leave the forks alone. After a few steps you have a row of working versions, each one a click away.

The name comes from Git, but the two are not the same thing. A fork in Git is a copy of a whole repository with its history, usually on a hosting platform, made to propose changes back. A CodePen fork is a copy of one Pen as it is now. The idea is similar; the tool is different.

Exporting a .zip

A Pen export is a download of a Pen's files as a .zip archive, so a copy lives on your own computer, independent of CodePen. You find Export in the same actions menu as Fork; any logged-in user who can view a Pen can export it. According to CodePen's documentation, the archive contains a src folder with your files, a dist folder with the last build and a LICENSE file.

An export is the most independent copy you can make: it survives a deleted Pen, a lost account and a change of plan. It is also the natural first step toward real version control, because the files in src can go straight into a Git repository (see From Prototype to Real Software).

Checkpoints

A checkpoint is a saved copy of your work made at a deliberate moment, typically right after something works or right before a risky change, so you can return to exactly that state. A fork, an export and a copy of script.js pasted into a text file are all checkpoints; what makes them useful is when you make them and how you name them.

• After it works. At the end of every build step, once "What you should see" checks out. That copy is your known-good version.
• Before a risky prompt. Any prompt that changes many lines, or that you are not sure about.
• With a name you will understand later. The step, what works, and the date if you make several a day: "step 4 · restart works · 2026-10-08".

Two checkpoints also let you see what a change really did. The example compares the same three lines of script.js (constants from step 3 of the game) before and after an AI change that was only supposed to make the rocks faster:

// The same lines of script.js in two checkpoints: before and after an AI
// change that was only supposed to make the rocks faster.
const before = `const SPAWN_EVERY = 0.7;
const ROCK_SPEED = 24;
const ROCK_MAX = 14;`;
const after = `const SPAWN_EVERY = 0.7;
const ROCK_SPEED = 36;
const ROCK_MAX = 40;`;

const oldLines = before.split("\n");
const newLines = after.split("\n");
for (const line of oldLines) {
  if (!newLines.includes(line)) console.log(`- ${line}`);
}
for (const line of newLines) {
  if (!oldLines.includes(line)) console.log(`+ ${line}`);
}

- const ROCK_SPEED = 24;
- const ROCK_MAX = 14;
+ const ROCK_SPEED = 36;
+ const ROCK_MAX = 40;

The speed changed, as asked, but so did the number of rocks in flight, which nobody asked for. That kind of quiet extra change is what Prompting in Small Steps warns about. This little comparison is crude (it ignores the order of lines and repeated lines); a real diff tool, such as the one built into Git or many code editors, does the job properly.

Going back

How you go back depends on the checkpoint you made:

• From a fork: open the fork and either continue building there, or copy its three files over the broken ones in your main Pen.
• From a text file: paste the saved script.js back over the current one. If the step also changed the HTML or CSS, you need copies of those too.
• From an export: unpack the .zip and copy the files from src into the Pen.

Then tell the AI. If you continue in the same chat, the model still has the broken version and its own explanations in its context, and may build on them. A new chat with the known-good files is usually cleaner (see revert and retry). If you stay in the chat, say plainly what happened:

I have gone back to my last working version; it is pasted below. Forget the changes from your last two answers: they broke the restart.

Starting from this version, make only this change: [the change, in one or two sentences].
Keep everything else as it is, and tell me which functions you changed.

[paste index.html, style.css and script.js here]

Version control by hand

Everything on this page is version control done by hand: deciding when a state is worth keeping, naming it, comparing two states and returning to one. Tools such as Git do this for every file in a project, keep the whole history in one place and never depend on you remembering to copy a file. The habits you build here carry over directly:

You do not need Git for a throwaway game. Once a project matters to someone, by hand stops being enough; From Prototype to Real Software takes that step, and Version Control with Git explains the tool.