Fasen als contracten
Zodra de SoW strak is, verdelen we het werk in discrete fasen. Elke fase heeft een duidelijke input, een duidelijke output en een expliciet overdraagpunt waar een mens beoordeelt voordat de agent verdergaat.
Een typische module-build ziet er zo uit:
Fase 1. Datamodel. De agent produceert het schema, migratiebestanden en een kort schriftelijk betoog voor elke designkeuze. We beoordelen. We keuren goed of we vragen om wijzigingen. De agent raakt bedrijfslogica niet aan tot deze fase is afgetekend.
Fase 2. Kernlogica. Met het goedgekeurde schema implementeert de agent de servicelaag of equivalent. Geen UI. Geen integratiewiring. Gewoon de logica, met tests.
Fase 3. Integratie. De agent koppelt de logica aan wat hij moet bereiken: een API, een queue, een SDK van derden. Deze fase brengt meestal de meeste verrassingen aan het licht, wat precies waarom we het isoleren.
Fase 4. UI of surface. Als er een gebruikersgeoriënteerde laag is, komt die het laatst. Het is het makkelijkste om te veranderen en het goedkoopste om opnieuw te doen.
Elke fase eindigt met een menselijke checkpoint. De agent weet dit van tevoren omdat we het in de SoW stellen. Hij springt niet vooruit. Als hij het probeert, is dat een signaal dat de fasegrenzen niet expliciet genoeg waren.
De valkuil van deze structuur. fasegrenzen houden alleen stand als de agent per fase geïsoleerde context behoudt. In de praktijk betekent dit het starten van een nieuw gesprek bij elke overdracht, of zeer bewust zijn over welke eerdere context je meeneemt. Agenten die de volledige sessiegeschiedenis behouden, verwijzen soms naar eerdere beslissingen en drijven terug naar het bredere plan. Schone contextsnedes zijn de friction waard van het handmatig herintroduceren van relevante achtergrondinformatie.
