Autonome Goal Loops Bouwen die Resultaat Leveren

De agent blijft in beweging, maar beweging is niet het probleem. Tests beschermen alleen wat we al weten; de cruciale fouten bevinden zich daarbuiten. Een scherm kan compleet lijken terwijl het niets opslaat. Een agent kan het juiste antwoord geven om de verkeerde reden. Een score-module kan gedrag belonen waar geen enkele gebruiker op zit te wachten. Meer iteraties maken elk van deze fouten simpelweg goedkoper en sneller.

In The Convergence Problem betoogde ik dat agents de "turns" (beurten) kunnen beheren, terwijl mensen de "rounds" (rondes) beheren. Ik beschreef toen niet wat de agent nodig heeft tussen die grenzen. Er is een harness (een omhulsel/raamwerk) nodig dat drie dingen doet: het moet een reële fout blootleggen, de ontbrekende functionaliteit lokaliseren en de les bewaren nadat de sessie is beëindigd. Dat is een heel andere machine dan een agent met een eenvoudige retry-prompt.

Twee systemen in ontwikkeling

Er zijn twee systemen in ontwikkeling. Het overduidelijke systeem is de feature. Het minder voor de hand liggende systeem is het proces dat bepaalt wat de agent vervolgens moet wijzigen. Beide moeten worden ontworpen.

Het Development Harness

Het harness verbetert de feature zonder dat ontwikkelingscontext lekt in de test. De structuur ziet er als volgt uit:

• Menselijke grens: Doel, autoriteit en beschermde maatstaven.
• Loop Controller: Kiest het volgende gat (gap).
• Development Agent: Werkt met code en het verwachte resultaat.
• Repository State: Het geheugen tussen sessies.
• Feature onder ontwikkeling: Het product dat wordt gebouwd.
• Product Agent: Ontvangt een schone context.
• Product Surface: Tools, UI, API.
• State + Effects: De resulterende status en effecten.
• Behavior Driver: Stuurt een reëel verzoek.
• Scorer: Levert bewijs en classificeert het gat; beschermt de kwaliteit.

Het harness weet hoe de feature zou moeten werken. De product-agent ontvangt echter alleen datgene wat een gebruiker ook zou ontvangen.

De development-agent wijzigt de feature. De driver benadert de feature via hetzelfde oppervlak als een gebruiker. De scorer analyseert wat er is gebeurd. De controller kiest vervolgens op basis van dat bewijs het volgende gat. De repository-state draagt deze beslissing over naar de volgende sessie.

Bij een agent-product wordt vaak een andere agent in de feature geplaatst. Deze twee agents moeten strikt gescheiden blijven. De development-agent kent de code en het verwachte resultaat. De product-agent krijgt een nieuw gesprek en alleen de tools die het product blootstelt. Als ze context delen, is de test waardeloos; de product-agent kan dan slagen met kennis die een gebruiker nooit zou verstrekken.

Hetzelfde harness werkt overigens ook zonder product-agent. De driver kan een browser, API, commando of hardware-simulator gebruiken.

Alles wat belangrijk is, bevindt zich buiten de prompt

De prompt krijgt vaak de meeste aandacht omdat deze gemakkelijk zichtbaar is, maar de loop is sterker afhankelijk van de wereld eromheen.

Ten eerste heeft het harness een reproduceerbaar startpunt nodig. De data, services, het model, de omgeving en de geserveerde code moeten overeenkomen met de geregistreerde run. Een reset moet het systeem terugbrengen naar dat punt, en een preflight moet bewijzen dat dit is gelukt.

Als de omgeving ongezond is, registreert het harness geen score. Infrastructuurproblemen zijn geen bewijs dat de feature is gefaald. Dit onderscheid voorkomt een grote klasse van valse reparaties: ontbrekende data kan immers lijken op zwak redeneren, en verouderde code kan lijken op een gebroken contract.

Vervolgens heeft het harness reële vraagsturing nodig. We gebruiken een klein corpus van verzoeken die door een mens zijn geschreven of goedgekeurd. De driver stuurt één verzoek ongewijzigd via een nieuwe interactie. Er wordt geregistreerd: het antwoord, tool-aanroepen, afgewezen acties, het zichtbare resultaat en persistente effecten.

De effecten zijn het belangrijkst. Software kan de correcte actie beschrijven zonder deze uit te voeren, of een aannemelijk scherm renderen zonder het onderliggende systeem te wijzigen. De prompt is daarom slechts één input van de run. De fixture, coderevisie, model, contract en scorer horen daarnaast. Een score zonder deze inputs is slechts een getal.

De basis (floor) en de richting: verschillende maatstaven

Elke loop heeft een deterministische basis (floor) nodig. Tests, validators, schema's en effect-checks bewaken het gedrag dat de feature al heeft verworven. De basis begint "groen". Als deze "rood" wordt, wordt die regressie de volgende taak.

De basis kan ons echter niet vertellen wat we daarna moeten bouwen. Daarvoor sturen we een reëel verzoek en inspecteren we het tekort. Sommige tekorten ondersteunen een mechanische score. Andere vereisen een screenshot, herhaalde samples of een persoon die het werk begrijpt. Deze signalen kunnen ruis bevatten. Eén perfecte run bewijst dat succes mogelijk is, maar zegt weinig over de vraag of dat succes betrouwbaar is.

De signalen bepalen de richting, terwijl de basis de eerdere vooruitgang bewaart. Deze scheiding houdt de loop eerlijk. Een nieuwe functionaliteit kan het product vooruithelpen zonder het pad erachter uit te wissen.

Eén ronde sluit één gat

Zodra de wereld en de maatstaven vaststaan, is de ronde zelf simpel:

1. Herstel de fixture en controleer het draaiende systeem.
2. Voer de deterministische basis (floor) uit.
3. Stuur één goedgekeurd verzoek via een nieuwe interactie.
4. Verzamel het gedrag, het zichtbare resultaat en de persistente effecten.
5. Classificeer het grootste gat.
6. Sluit dat gat via elke vereiste laag.
7. Voeg een deterministische check toe voor dit gedrag.
8. Stuur hetzelfde verzoek opnieuw en registreer het resultaat.

Eén gat betekent niet noodzakelijkerwijs één bestand. Het betekent één causale claim. De ontbrekende functionaliteit kan het datamodel, het tool-contract, de runtime, de agent-instructies, de interface en de effect-check kruisen. De ronde moet dat hele pad sluiten:

verzoek → representatie → operatie → persistent effect → zichtbaar bewijs

Gedeeltelijke paden zorgen voor de meest overtuigende fouten. De interface bestaat, maar niets produceert de data. De tool geeft "succes" terug, maar de status verandert niet. Een smal pad dat werkt van verzoek tot effect is waardevoller dan vijf lagen van onafgemaakte mogelijkheden.

De classificatiestap voorkomt willekeurige reparaties. Een symptoom kan toebehoren aan de wereld, het domein, het contract, de runtime, de sturing, het oppervlak of het harness. Zonder die stap wordt elke agent-fout een prompt-probleem en elke visuele fout een frontend-probleem. De loop zou dan het dichtstbijzijnde ding wijzigen in plaats van het juiste ding.

Het wijzigen van één causaal gat maakt het resultaat bovendien toerekenbaar. Als een ronde vijf onafhankelijke knoppen wijzigt, weet niemand welke les bewaard moet blijven.

De score-module en het autoriteitsmodel

Een autonome loop zal alles optimaliseren wat hij kan bereiken, inclusief een foutieve maatstaf. Het harness heeft daarom een autoriteitsmodel nodig, bestaande uit drie niveaus:

• Vrije bestanden (Free): Normale implementatieknoppen. De loop kan deze wijzigen en meten binnen de toegewezen scope.
• Voorstelsbestanden (Propose): Deze overschrijden een grens. De loop kan bewijs verzamelen en een wijziging voorstellen, maar een mens beslist.
• Bevroren bestanden (Frozen): Deze definiëren het examen. Ze bevatten het goedgekeurde corpus, de fixture, bestaande treden, scoreregels en het beoordelingsrubriek.

De regel is: de autoriteit van de agent neemt af naarmate een bestand meer macht heeft over de score.

De loop kan het product wijzigen, maar hij kan niet de bewijslast wijzigen die bepaalt of het product is verbeterd. De loop kan een regressiecheck toevoegen voor een geobserveerde fout, maar hij kan een bestaande check niet verzwakken of de drempelwaarde verlagen. Ook kan hij niet in dezelfde ronde zowel een productknop als de maatstaf van die knop wijzigen; anders beoordeelt hij zijn eigen reparatie.

Ook getrainde judges (beoordelaars) hebben deze bescherming nodig. Een visuele judge blijft bewijs totdat de rankings overeenstemmen met herhaalde menselijke rankings. Dit beperkt de autoriteit van de loop, maar maakt het resultaat geloofwaardig.

De hiërarchie van loops

Elke productronde test tegelijkertijd het harness. De driver kan een fout maskeren, de fixture kan een noodzakelijk scenario missen, de scorer kan correct gedrag straffen, of de procedure kan tijd verspillen.

We beëindigen elke ronde met één vraag: Wat kostte tijd, dat door een regel of check voorkomen had kunnen worden?

De eerste keer dat dit gebeurt, is het bewijs. Herhaalde wrijving kan leiden tot wijzigingen in de driver, de feiten of de standaardprocedure. Zelfverbetering vindt plaats wanneer de loop een specifieke fout promoveert tot een duurzame beperking. De loop herschrijft niet zijn hele besturingssysteem na elke verrassing. Soms is de juiste wijziging juist weglaten: een valse waarschuwing leert de loop immers om goed gedrag te vermijden.

In feite draaien er drie loops op verschillende snelheden:

1. Product Loop (Snel): Sluit één functionaliteit per ronde.
2. Harness Loop (Midden): Wijzigt wanneer herhaald bewijs een ontwikkelingsfout blootlegt.
3. Direction Loop (Langzaam): Een mens leest een batch bewijsmateriaal en beslist of het proces moet worden voortgezet, omgebogen of gestopt.

Het scheiden van deze loops is cruciaal. De development-agent kan een nieuwe richting voorstellen, maar hij kan niet beslissen dat zijn eigen resultaat "goed genoeg" is.

De repository als controlepaneel

Niets hiervan kan enkel in het huidige gesprek leven. Agent-sessies eindigen, context wordt gecomprimeerd en de volgende sessie start zonder de oude redeneringen. Daarom houden we een klein pakket bij onder goals/:

Bestand	Inhoud
goal.md	Het doel, uitsluitingen en voltooiingsvoorwaarden
facts.md	Beslissingen die latere rondes niet opnieuw hoeven te ontdekken
plan.md	De initiële basis en de verwachte volgorde van functionaliteiten
LOOP.md	De procedure, autoriteit, budget en stopregels
STATE.md	De huidige wachtrij, fouten en de volgende actie
corpus/	Goedgekeurde verzoeken
rounds/	Prompts, outputs, scores, screenshots en beslissingen

LOOP.md verandert wanneer het proces verandert. STATE.md verandert na elke ronde. Dit onderscheid maakt sessies vervangbaar zonder dat het werk verloren gaat. Een nieuwe agent leest het doel, de procedure, de staat en het bewijs, en gaat verder vanaf dezelfde beslissing.

Dit is meer dan contextbehoud; deze bestanden maken het ontwikkelproces inspecteerbaar. We kunnen zien waarom de loop voor een bepaald gat koos, welk bewijs de wijziging ondersteunde en of de volgende run hetzelfde verzoek verbeterde.

De menselijke factor: wanneer is het genoeg?

We draaien de innerlijke loop in kleine batches. Drie rondes produceren meestal genoeg bewijs voor een beslissing, zonder dat het systeem de kans krijgt om af te dwalen. Op de grens kiest een mens of de wachtrij wordt voortgezet, de volgende batch wordt omgebogen, of het proces stopt. De loop stopt eerder wanneer een fout niet gereproduceerd of toegeschreven kan worden, wanneer de omgeving ongezond is, of wanneer de reparatie een wijziging in de "bevroren" bestanden vereist.

Dit is de mensgestuurde ronde. De agent beheert de beurten binnen die ronde, maar de grens bestaat omdat de score-module niet de richting van het product kan bepalen.

De meeste tickets hebben dit niet nodig. Als complete tests het werk beschrijven, geef de agent dan de tests en laat hem het afmaken. Het harness verdient zijn kosten wanneer het gebruik van het product de volgorde van functionaliteiten moet onthullen.

Begin met drie verzoeken, één fixture, één score-commando, één loop-bestand, één state-bestand en een budget van drie rondes. Voeg pas een nieuwe controle toe wanneer een fout dit rechtvaardigt.

De kwaliteit van een agent-loop wordt niet gemeten aan de hand van hoe lang hij draait of hoeveel commits hij produceert. Het gaat om wat er overblijft na een ronde. Een goede ronde laat een werkende functionaliteit achter, het bewijs dat deze werkt, en een harness dat niet twee keer voor dezelfde les hoeft te betalen. Dat is een agent-loop die je met een vertrouwd gevoel kunt achterlaten bij een complex onderdeel.