Git when working with AI: how not to lose control of the project

A model may say: "I fixed the form validation and did not change anything else." Sounds good, but the description is not evidence. The evidence is the diff, which compares the previous and current version of the file.

- <button type="submit">Wyślij zapytanie</button>
+ <button type="submit">Wyślij</button>

- if (!email || !phone) return showError("Podaj email i telefon");
+ if (!email) return showError("Podaj email");

- exportRow.push(lead.internalNote);
+ // usunięto

The button text changed. Phone validation disappeared. The CSV export lost a field. The description said "validation fix". The diff shows the fuller truth.

AI does not always change things intentionally. Sometimes it "cleans up" a fragment that looks unnecessary but actually comes from a business decision. Without Git, that side effect often appears only when a client or the team reports a problem.

The stable version of the project should stay on the main branch. Larger changes are better done separately on a branch. That way AI can rebuild components, change data structure, and test solutions without risking the working system.

Example for a lead panel:

git switch -c feature/lead-priority

On such a branch you can add priorities, statuses, internal notes, and CSV export changes. Only after verification do you merge the change into the stable version.

When working quickly with AI, it is easy to fall into continuous tweaking without a stop point. After an hour the project looks different, but nobody knows which changes were intentional and which are side effects.

A commit should happen after a working step. Not after a whole day of chaotic edits and not after a series of random experiments.

Add lead priority and status fields
Extend CSV export with an internal note
Fix lead filtering in the admin panel
Repair contact form validation

A history like this is readable for a human, the team, and the next AI session. The model gets concrete context instead of guessing whether the changes were accidental, experimental, or ready to maintain.

Not every project needs a full process. A one-off script for cleaning a file, a tiny form without business logic, or a notebook-style prototype can sometimes live with a file copy and basic common sense.

Git starts to make sense when the project:

• is used by more than one person
• has a production version and is still being developed
• contains business process logic such as export, calculations, integrations, or statuses
• is changed often, especially with AI help
• needs to return to earlier decisions after a few weeks or months

If none of these conditions apply, there is no obligation. If even one applies, not using Git is a conscious risk, not a saving.

You do not need to know all of Git to gain control over a project supported by AI. In a small company, a simple set of rules is enough.

A good rhythm is not complicated. First define the scope. Then AI makes the change. Next you check the diff, run a test or build, fix errors, and only then commit.

git status
git diff
npm run build
git add src/...
git commit -m "Add lead status control"

This rhythm is boring, but effective. Especially where AI can touch several files at once and introduce a change that nobody notices during the conversation itself.

Git does not help only the human. It also helps the next agent or model that returns to the project. Instead of a vague story that "something was fixed", it gets a history of concrete decisions.

• you can see the latest commits and their intent
• you can see which files are still modified
• it is easier to separate work in progress from finished changes
• you can find the point where a bug appeared
• you can revert one step without manually recreating everything

In practice this shortens the conversation with AI. You do not have to start with a long explanation of the whole world. It is enough to inspect the repository, status, and change history.

AI can speed up project development. It can also speed up breaking the project if there is no mechanism that lets you see, undo, and understand every change.

Git is that mechanism. Not for tidiness, not for aesthetics, and not for developer ceremony. For control over a project that changes faster than you can track without tools.

The difference between a professional AI implementation and a chain of experiments saved under a name like final_final_fixed_3 often starts right here.