On June 24, 2026, my assistant finished a new income statement feature. The code checks passed. The tests passed. Then, while tidying the project folder, it ran a cleanup command that throws away every change not yet committed, meaning not yet recorded as a saved version in Git. In one second the whole feature was gone. Nothing had been committed, so there was nothing to recover, and the assistant had to rebuild three files from the beginning.
Two months later a different kind of loss nearly happened. I often ran two assistant sessions on the same project, each on its own feature. One session saved its work by naming the files it had changed, exactly as it should, but one of those files also held unfinished changes from the other session. Both sets of changes went into the same saved version. It did not even compile, yet every check on my computer passed, because my computer had both sessions' work in place. Only the real build on the deployment service revealed it.
Neither was a coding mistake. They were mistakes of routine.
The short answer
A good day of building with AI has five parts: start from yesterday's handoff note, build in an isolated copy of the code, check before calling it done, ship on purpose in small units, and record what you learned. The key protection is giving each assistant session its own Git worktree, committing early and by file name, and never running reset-style commands on a shared folder.
Your job changes shape
When an AI does the programming, you are no longer the person typing. You are the person deciding, checking and protecting. The day looks like this:
- Start: read yesterday's handoff note and choose one to three goals.
- Build: let the assistant work in its own isolated copy.
- Check: review, test and look at real results.
- Ship: merge to customers on purpose.
- Record: write today's handoff note and save the lessons.
Two ideas sit underneath. The first is isolation. If two people cook in one kitchen, each needs a cutting board. Git can create separate working folders that share one history. They are called worktrees, and each session works in its own folder and cannot step on the other's unfinished work. The second is rhythm. Website changes go live when you merge, database changes go live the moment they are applied, and mobile app builds take time and go through store review. Each deserves its own moment, chosen by you.
Uncommitted work is unprotected work.
Morning: start from the note
Each day starts with the latest handoff note. From it I choose one to three goals, never ten. A goal is something a customer will notice: "A cashier can see which cash box the money went to," not "refactor the treasury code."
Keep exploring and executing apart. When exploring, I want an opinion and a question, with no plans. When executing an approved plan, I want the assistant to finish all of it, pausing only for a decision that would change a number a customer already sees. The balance: during long work, a short status line every ten minutes or so, because an hour of silence looks like something expensive is running.
Working on several things at once
Running two sessions in parallel is a real productivity gain, and it is also where we lost the most work. The incidents, in order: a cleanup command wiped a finished feature on June 24; a file added by name carried another session's unfinished changes on August 5; the same thing happened on August 26; files copied from a folder 21 saved changes behind silently erased another update's text changes on August 29; and on September 3 and 4 the assistant tried to undo its own last change on a shared branch, but the other session had saved on top of it in the three minutes before, so the undo removed the other session's work. That one was recovered from Git's history log with nothing lost.
Working in a shared folder. Every one of these incidents came from two sessions sharing one working folder, or from copying files between folders instead of carrying over only the changes. The worst part was that our usual safety checks gave false comfort. Code checks and even a full local build passed, because the shared folder contained everyone's changes together. The mistakes only showed up later, in the clean environment of the deployment service, or by luck in a test.
The rules we follow now: each session works in its own worktree, created fresh from the latest main version. Files are saved by name, never with "save everything." Work is committed as soon as a part passes its tests. Before any commit, the assistant checks which branch it is on and confirms that the difference from main contains only its own files. Reset commands are never run on a whole folder, and changes move between folders as a patch, not as copied files.
It works. In a seven-phase feature built inside its own worktree while the shared folder held another session's unfinished work, not one line crossed between them.
Shipping: merge on purpose
In KashBoss, merging an update to the main branch means deploying it. Within minutes, GitHub runs the automated tests, builds the website and sends it to every customer.
One trap is worth knowing. A green check on a proposed update does not always mean the full tests passed. In our setup the full suite runs only after the merge. On September 13, 2026, one update passed its checks, was merged, then failed the full suite, and that failure blocked every later deployment until it was fixed. Now the assistant runs the full suite on the merged state before merging.
| Change | When it reaches customers | Who decides |
|---|---|---|
| Website code | Minutes after "merge" | Me, with the word "merge" |
| Database change | The moment it is applied | Me, for agreed repairs only |
| Mobile app | After a build, upload and store review | Me, with the word "build" |
Mobile builds happen only when I ask, usually once at the end of a day. And never experiment on the live product: on August 2, 2026, the assistant tried three website cache settings in a row, each deployed to every customer, and one left some customers stuck on old code for hours. If the right setting is unknown, test it away from customers and deploy once.
Evening: write it down
The day ends with the handoff note, and any lesson from the day saved as its own small memory file. It takes five minutes, and lets tomorrow start in two minutes instead of thirty.
Not burning out
Our history shows saved changes on 232 of the 284 days between the first commit and the day I began this book, and hundreds in the small hours of the night. I do not recommend that pace. What helps instead:
- Stop when a unit is shipped. Chaining "one more thing" onto a finished unit is how evenings disappear.
- Let the files hold the to-do list, not your head.
- Demand short reports. Every long report costs attention you need for decisions.
- Batch the slow work. Builds and long checks happen once, at a time you choose.
The AI never gets tired. You do. Design the routine for the person in the chair.
Key takeaways
- Your job in a day of building is deciding, checking and protecting, not typing.
- Isolate parallel work in worktrees, commit early and by name, and verify each commit holds only its own files.
- Merging is deploying, database changes are instant, and mobile builds are batched. Give each its own moment.
- Never experiment on the live product, and never during a customer problem.
- Design your routine around your own energy: short reports, written to-do lists and stopping when a unit ships.
Frequently asked questions
What is a Git worktree and why use one with AI assistants?
A worktree is a separate working folder that shares one Git history with your main project folder. Giving each AI session its own worktree means one session cannot overwrite or commit another session's unfinished work. It is the cheapest protection against the incidents described above.
Why did my AI assistant delete all my uncommitted changes?
Some cleanup or reset commands discard every change that has not been committed, and there is no way back because Git never recorded it. Commit early, as soon as a part passes its tests, and forbid commands that reset or discard changes across the whole folder.
How many hours a day should I spend building with AI?
There is no fixed number, but working almost every day into the night is a pace I would not repeat. Stop when a unit is shipped, keep your to-do list in files rather than your head, and batch slow work. A calmer routine also costs less in AI usage.