I know nothing about computers. What I know about building with AI, I’ve learned the hard way. And one of the costliest lessons was this: at first, I worked without Git.

Everything got overwritten. I had no versions and no repositories. When AI changed something that worked and broke it, there was no easy way back. I lost so many hours and so much work.

If you’re starting out, spare yourself that lesson. This is the second part of the series I started with How to build with AI. In part one, we installed AI on the computer and created mi-primera-web. Today we give that folder a memory.

Why it’s essential when you work with AI

When you work on your own, you change one file at a time. AI can change ten files in a minute. Usually for the better. But sometimes it fixes one thing and breaks another, and you don’t always notice straight away.

Without a record, all you have is the current version. If it’s broken, you have to ask AI to try to fix it. Sometimes it can. Sometimes it makes things worse. And the version that worked yesterday no longer exists.

With Git, yesterday’s version is still there if you saved it.

What Git is, without the jargon

Git is a program that keeps a folder’s history. A folder with Git is called a repository.

Every time something works, you save a snapshot of the project. That snapshot is called a commit, and it comes with a sentence explaining what changed: “The page now has a contact button.”

With those snapshots, you can:

  • see what changed and when;
  • go back to any earlier snapshot;
  • try something risky without touching what already works.

You don’t need to learn commands. The AI you installed in part one knows how to use Git. You decide when to save and where to go back to.

Step 1: ask it to set things up

Open your mi-primera-web project with AI and write:

“Check whether this project uses Git. If it doesn’t, set it up and save an initial version we can return to. Explain what you’ve done.”

If Git isn’t installed on your computer, it will tell you and suggest how to install it. Read what it plans to do before accepting, as we discussed in part one.

When it’s done, you’ll have a repository with a first snapshot. From here on, everything you do is recorded if you save it.

Step 2: the routine — test and save

The routine is short:

  1. Ask for a change.
  2. Test it: open the page and check that it does what you wanted.
  3. If it works, save: “Save a version with the message: added contact button.”
  4. If it doesn’t work, don’t save. Go back.

The rule that would have saved me so many hours: save every time something works. One extra snapshot does no harm. One missing snapshot can cost you an afternoon.

Step 3: go back when something breaks

Try it now with something that doesn’t matter. Ask for a change you don’t actually want, for example: “Change all the colours on the page to green.” See how it looks. Then:

“Undo the changes made since the last saved version.”

The page goes back to how it was. That’s what I couldn’t do at first.

If the mistake happened earlier, ask to see the history:

“Show me the most recent saved versions, with their messages and dates.”

Then choose: “Go back to the version with the contact button.” AI will explain what will be lost before doing it. Read it.

Step 4: a separate version for experiments

Sometimes you want to try something big without risking what works. That’s what Git’s branches are for: a parallel line of work on the project.

“Create a branch called ‘design-test’ and make the design change there.”

If you like the result, you bring it into the main version. If you don’t, you leave the branch behind and the main version stays intact. That way, you can compare two ideas without worrying.

Step 5: a copy outside your computer

Everything so far lives on your computer. If the computer fails, it’s lost along with it.

GitHub is a service where you can keep a copy of your repositories. It can be private, just for you. It gives you a backup and a way to work with other people.

Important: saving a version in Git doesn’t upload it anywhere. Uploading it to GitHub is a separate step and your decision. Before uploading anything, ask:

“Does this project contain passwords, keys, client data or private files? Don’t upload anything until we’ve reviewed it.”

Three mistakes to avoid

Never saving. Git can only save you if you saved your work. Without snapshots, there’s nowhere to go back to.

Saving everything together with a meaningless message. “Changes” won’t tell you anything a month from now. A specific sentence saves you searching.

Uploading things that shouldn’t leave your computer. Passwords, service keys and client documents don’t belong in a repository, even a private one. Ask AI to exclude them from the start.

What you take away

You now have a folder with a memory. You test, save and, if something goes wrong, go back. It’s the difference between worrying that AI will break something and working with peace of mind.

In the next part, we’ll look at how to organise more work with an agent that coordinates tasks.

Text by Roberto Ortega, prepared with AI editorial assistance. The Norwegian and English editions are editorial adaptations of the Spanish original.