Who may change the main version of your work?
Who may change the main version of your work? With me the answer is: nobody, except one gate.
In my studio two AI agents work on code, each on a part of its own. They both work in an intermediate version. The main version, which everything runs on, they never write themselves. One gate does that. It runs all the tests on exactly the latest state of the intermediate version. If everything is green, that state goes through to the main version. If anything is red, nothing happens and the main version stays on the last good state.
Three agreements make this workable:
- A red state is not tested again. The gate waits for a new change.
- As long as something is red, whoever holds the ticket may only push through the repair. Other work waits.
- If the error comes from the other one's part, that one gets a ticket and you roll the change back. That way nobody keeps waiting.
The nice thing is that nobody has to negotiate about it. Who may do what does not have to be discussed again with every change. The gate decides, and everyone knows beforehand why.
That goes for agents and for people. A good rule for working together is usually one that nobody has to remember, because the setup enforces it.
How do you arrange it: who may write directly in the "real" work, and who may not?
See also
One process, one task: how to choose where AI begins
The question many organisations start with when it comes to AI is: "What can it do?" The answer is almost everything. That is why it so often stays at a presentation, a trial account and a good conversation, while…
An idea no longer goes in the drawer
In the past an idea went into the drawer, to do something with it in a few years.
A workaround hides the error
A workaround hides the error.
