Version control gives you a history. It does not tell you which point in that history worked.
That gap is easy to live with when changes are slow and you remember making each one. It stops being easy when a morning's work has produced fifteen commits, several of them written by something that did not tell you what it had touched, and you now need to find the last version you could rely on.
A baseline is the answer to that question, and it is a stricter thing than a commit.
Three states a version can be in
At any moment, a version of your software is in one of three conditions, and only one of them is useful in a crisis.
Unknown. Nobody has checked it. It may be perfect. This is the state of almost every commit made in the middle of a working session, including the ones with confident messages.
Believed working. Somebody looked at it, or it started up, or the change that produced it was described as complete. This is the state most people mistake for the third one, and the mistake is expensive because it feels identical from the inside.
Verified working. The behaviour you accepted has actually been checked, by someone who knew what to check, and the things around it were checked too. Only this is a baseline.
The distinction matters because a fallback position you have not verified is not a fallback position. Going back to a version that turns out to be broken in a different way is worse than not going back at all — you have spent the retreat and gained nothing, and you now have two problems to separate.
What has to be true before you call it a baseline
Three things, and none of them takes long.
The behaviour you accepted for this piece of work has been checked, point by point, against what you wrote down before the work started. Not read, not demonstrated by the assistant — checked by you, against the description.
The things nearest the change still do what they did before. A change to how stock levels are adjusted is checked by adjusting stock, and also by looking at the stock report and the low-stock warning, because those read the same numbers.
And nothing is knowingly left half-done. A baseline with a piece of unfinished work in it is not a place you can return to calmly; you will arrive there and immediately have to remember what state you left it in.
What this does not require is completeness in any larger sense. A baseline is not a release, and it does not mean the software is finished. It means this version is one you understand.
Establish one at the end of each piece of work, not at the end of the day
The natural moment is when an increment's checks have passed and before anything new is started. That timing is not arbitrary: it is the only moment when you have just finished checking and have not yet begun anything that could invalidate it.
Ending the day is a worse trigger, because whether the day happens to end mid-change has nothing to do with whether the software works. Fixed intervals are worse still. The unit is the piece of work, which is one more reason to keep pieces of work small enough to check — the smallest useful increment is partly a description of how often you can afford to do this.
Between baselines, commit as often as you like. Save points during a change are useful and cost nothing. The discipline is not about committing less; it is about not confusing the two kinds of point.
Marking it so you can find it later
Version control is the mechanism, and how you use it matters less than that the distinction is visible in it. What you need is to be able to look at the history in three weeks and identify the verified points without relying on memory.
Any of the usual mechanisms will do this: a tag, a branch that only ever receives verified work, or simply a commit message that states what was checked rather than what was changed. "Stock adjustment: verified adjustments, report totals and low-stock warning" is a more useful message than "fix stock adjustment", and it takes the same amount of typing.
If it is not recorded, it did not happen. A verification you performed and did not note is indistinguishable, a fortnight later, from one you meant to perform. The test record exists for this within a single increment, and the stable baseline record keeps the running history of verified points across a project.
Using it
When an AI-assisted change goes wrong repeatedly — the second correction does not work, the third introduces something new — the baseline is what converts a bad afternoon into a bounded loss. You return to a version you know, and re-approach the change as a smaller, better-described piece of work.
The judgement about when to stop correcting and go back is a separate skill, and it is covered in fixing AI-generated code without making it worse. The point here is narrower: that judgement is only available to someone who has somewhere to return to. Retreat has to be an option before it can be a decision.
It is worth naming the reluctance, because it is real and it is not rational. Going back feels like losing the work. In fact the work you are giving up is work you had already stopped trusting, and what you get back is certainty about where you stand. That trade is almost always favourable, and more so with AI than it used to be: rebuilding a well-described increment is now a matter of minutes rather than the afternoon it would once have cost.
Why acceleration makes this matter more
When implementation was slow, the distance between "last known good" and "now" grew slowly too. You could hold the intervening changes in your head, because you had typed them all, and the cost of an unverified stretch was bounded by how fast you could work.
That bound has gone. Substantial change now arrives in minutes, across more files than you asked about, described as complete. The interval between verified points can become large very quickly without feeling large, and the amount of unexamined work sitting on top of the last thing you actually checked is no longer limited by your typing speed.
This is the same mechanism as the way AI projects drift, seen from the recovery side. Drift is what happens when change outruns understanding; a baseline is the mark you leave behind showing where understanding last caught up. The faster the change, the more often the mark is worth leaving.