Developers kunnen nu meerdere sessies met coding-agents tegelijk opstarten zonder bang te hoeven zijn voor overschreven state-bestanden of verborgen bestandconflicten. Een adviserend “share-nothing”-patroon isoleert de werkruimte van elke agent en waarschuwt voor mogelijke conflicten. Deze aanpak vervangt harde locks door een lichtgewicht register dat overlappend werk signaleert voordat het plaatsvindt, waardoor pipelines blijven doorlopen, zelfs als een sessie crasht.

Waarom parallelle agents voor problemen zorgen

Het draaien van meer dan één geautomatiseerde coding assistant in een enkel repository versnelt codegeneratie, testen of refactoring. In de praktijk doen zich echter direct twee problemen voor.

  • State-corruptie – Twee agents schrijven naar hetzelfde state-bestand; de latere schrijfactie overschrijft de eerdere, waardoor voortgang verloren gaat.
  • Bestandscollisie – Twee agents bewerken hetzelfde bronbestand zonder dat ze hiervan op de hoogte zijn. Het conflict wordt pas later zichtbaar, wanneer een diff afwijkende wijzigingen laat zien.

Beide problemen verspillen de tijd van ontwikkelaars en kunnen moeilijk te traceren bugs introduceren.

De “share nothing”-regel

Het kernidee is simpel: elke agent krijgt zijn eigen privé-kladblok op de schijf en schrijft alleen naar bestanden die bij die sessie horen. Er is slechts één bewust gedeeld bestand per branch toegestaan, en dat volgt een “last-writer-wins”-regel: de agent die als laatste schrijft, bepaalt de uiteindelijke inhoud.

Een presence layer houdt elke actieve sessie bij:

  • Branchnaam
  • Lijst van bestanden die worden aangepast
  • Tijdstempel van de laatste activiteit

Wanneer een nieuwe sessie start, raadpleegt deze het register. Als een andere sessie al met een van dezelfde bestanden bezig is, ontvangt de ontwikkelaar een waarschuwing voordat het werk begint.

Adviserende versus blokkerende locks

Traditionele lock-bestanden werken als een doodlopende weg: zodra een lock is ingenomen, wacht elk ander proces tot de lock wordt vrijgegeven. Als de eigenaar-sessie crasht, kan de lock onbepaald blijven bestaan, waardoor er handmatig gezocht moet worden naar verouderde lock-bestanden.

Het adviserende model is milder. Het geeft een waarschuwing wanneer een potentieel conflict wordt gedetecteerd, maar stopt de nieuwe sessie niet. Als een registervermelding oud is — wat betekent dat het proces dat deze heeft aangemaakt niet meer bestaat — geeft het systeem nog steeds alleen een waarschuwing, zodat de ontwikkelaar kan beslissen of hij doorgaat.

Hoe je het patroon implementeert

  1. Partitioneer state per schrijver – Geef elke agent een eigen directory voor tijdelijke bestanden en state. Reserveer gedeelde bestanden voor echt globale data en pas daar alleen de last-writer-wins-regel toe.
  2. Injecteer bewustzijn bij de start – Voordat een agent begint, lees je het presence-register en vergelijk je de gevraagde bestandslijst met bestaande vermeldingen. Stop of waarschuw als er overlap wordt gevonden.
  3. Controleer liveness bij het lezen – Controleer bij het raadplegen van een registervermelding of het geregistreerde proces-ID nog steeds draait op het OS. Verwijder vermeldingen die bij dode processen horen.
  4. Geef de voorkeur aan adviserend boven blokkerend – Laat ontwikkelaars de controle behouden. Een waarschuwing stelt hen in staat om door te gaan, te pauzeren of te annuleren, waardoor deadlocks worden voorkomen.
  5. Houd wachtstatussen bij – Wanneer veel agents actief zijn, wordt de aandacht van de ontwikkelaar de bottleneck. Toon welke agents wachten op menselijke input, zodat werk opnieuw geprioriteerd kan worden.

Dit alles kan worden gebouwd met een eenvoudige directory van JSON-bestanden; een externe database of message bus is niet nodig. Het eenvoudige opslagformaat maakt het systeem gemakkelijk te auditeren en draagbaar tussen verschillende omgevingen.

Risico's en tegenargumenten

Sommige teams zullen aanvoeren dat een harde lock veiligheid garandeert: geen twee agents kunnen ooit naar hetzelfde bestand schrijven. Het nadeel is een verminderde veerkracht — gecrashte sessies laten orphaned locks achter die de hele workflow stilleggen.

Waar je op moet letten

Als je met meerdere AI-gestuurde code-assistenten werkt, biedt het “share nothing”-adviserende patroon een pragmatische manier om te voorkomen dat ze elkaar in de weg zitten. Door de state te isoleren, intenties vroegtijdig kenbaar te maken en mensen te laten beslissen wanneer ze doorgaan, brengt deze methode veiligheid in balans met de flexibiliteit die moderne development pipelines vereisen.