A discipline of agentic development
Version management
A codebase tells a story. Version management keeps that story readable, so anyone, today or in two years, can understand what changed, why, and by whom.
When agents contribute code, the number of changes grows and the authorship becomes mixed. Without a clear rhythm of branches, commits and releases, a repository quickly turns into a history nobody can follow.
I help teams agree on a simple, shared way of working with versions: how work is split, how changes are described, and how releases are named and recorded. Not as bureaucracy, but as a courtesy to everyone who comes after.
Three ideas
Changes with meaning
Every change should explain itself. Clear descriptions turn a list of commits into a history that people and agents can learn from.
A rhythm everyone shares
A simple branching approach, followed by everyone, beats a perfect one that nobody remembers. Agents follow the rhythm too.
Releases you can name
Versions and release notes give the outside world a clear picture of what changed, and give the team moments to look back.
In practice
- A branching and review flow that fits the size and pace of the team
- Conventions for describing changes that agents can follow as well as people
- Meaningful versions and changelogs that are produced as part of the flow
- Traceability from a change back to the reason it was made
Questions to start with
- Could a new team member understand last month's changes from the history alone?
- Do people and agents in your team follow the same conventions?
- How do you decide when something is ready to be released?