I am building Tansa, a large Bitcoin analysis application using Rails, PostgreSQL, Sidekiq, and AI coding agents.
After months of development, the Git repository had accumulated many commits, branches, recovery points, and AI-generated changes. We decided to clean it up and make the history easier to understand.
The operation appeared successful. The repository looked coherent, the main branch was clean, and the important Git references had been preserved.
Then I restarted the application.
I no longer recognized it.
Recent features were missing, and parts of the application had returned to an older state. Git itself had not failed. The problem was more subtle:
We had produced a cleaner repository without first proving that it contained the correct application.
We had focused on commits, branches, and history. We should have started with a different question:
Which exact functional state are we trying to preserve?
Recovery required us to stop making changes, preserve every available reference, compare candidate versions, and verify the actual application—not only the commit graph.
This incident changed the way I manage Git with AI agents:
- Define the functional reference before modifying history.
- Create a remote recovery branch and tag first.
- Give one person or agent ownership of Git operations.
- Require a diff and human approval before destructive commands.
- Validate the running application, not only the test suite.
- Never delete a recovery reference too early.
A clean Git history is not proof that you preserved the right software.
AI makes development faster, but it can also execute a poorly defined Git decision at remarkable speed. The more agents you use, the more explicit Git ownership and recovery rules must become.
I am documenting these lessons in a book about Git and AI-assisted development. Its English edition is currently in progress.
Have you ever ended up with a technically clean repository that no longer represented the application you intended to preserve?