Hoe een goed beheerd agent-assisted coding proces er echt uitziet

Meeste agentschap-teams die AI-codering gebruiken, hebben dezelfde ervaring: de eerste twintig minuten gaat het goed, dan herschrijft het model een bestand dat het niet mocht aanraken, verzint een dependency, en je bent de volgende uren bezig om het uit elkaar te halen. Het probleem is niet de agent. Het probleem is het ontbreken van een proces.

Agent-ondersteunde development is niet zomaar autocomplete op schaal. Het is een ander werkpatroon dat een ander soort discipline vereist. De studio's die er werkelijk output uit halen, doen niet harder prompting. Ze structureren het werk anders, fase per fase, voordat er één regel code geschreven wordt.

Begin met een specificatie, niet een prompt

De meest voorkomende fout is een chatvenster openen en beschrijven wat je wilt. Dat geeft de agent een ondergespecificeerd probleem en geeft hem vrij spel om architectuurbeslissingen te nemen die je nog niet hebt doordacht.

Een werkend proces begint met een geschreven specificatie. Niet een formele PRD, maar een strak document: wat de feature doet, wat niet, hoe de data eruitziet, wat de acceptatiecriteria zijn. Twee bladzijden volstaan meestal. Het gaat erom alle grote beslissingen te maken voordat de agent aan de codebase raakt.

Dat voelt langzaam. Dat is het niet. Elke vage zin in je spec is een debuggingzitting die staat te gebeuren. De spec is ook het artifact dat je de agent meegeeft als context aan het begin van elke sessie, dus je herhaalt jezelf niet meer en de agent dwaalt niet af.

Verdeel het werk in fasen met duidelijke checkpoints

Zodra de spec klaar is, splits je de implementatie in fasen die klein genoeg zijn om de output van elke fase te lezen en begrijpen voordat je naar de volgende gaat. In de praktijk betekent dat fasen van ongeveer één tot drie uur agentwerk, met als resultaat een afzonderlijke, testbare unit.

Aan het eind van elke fase bekijk je de diff. Niet het hele bestand, de diff. Je controleert of de agent binnen scope bleef. Je controleert dat het geen bijeffecten in aangrenzende modules heeft geïntroduceerd. Zo ja, je stopt, reverted, en stelt de volgende instructie aan voordat je verdergaat.

Dit is het checkpoint. Het overslaan daarvan is waar context debt zich ophoopt. Als de agent eenmaal een fout over twee of drie fasen heen heeft voortgebouwd, dan fix je geen bug meer, dan doe je archéologie.

Een handige regel. als je het verschil niet zeker zou mergen na een vijf minuten durende review, was de fase te groot.

Beheer context, niet alleen prompts

Agenten degraderen op afstand. Hoe verder een model van zijn begincontext af raakt, hoe meer het openingen opvult met patronen uit training in plaats van patronen uit je codebase. Dit is geen gebrek dat je weg kunt prompts. Het is een eigenschap van hoe deze systemen werken.

De praktische reactie is agressief contextbeheer. Start een nieuwe sessie voor elke fase. Geef de agent de spec, de relevante bestanden, en niets anders. Weersta de neiging een lang gesprek voort te zetten omdat het efficiënt voelt. Lange gesprekken voelen efficiënt. Dat zijn ze niet. Je voert het model zijn eigen eerdere aannames samen met je nieuwe instructies toe.

Sommige teams houden een kort contextbestand naast elke module: een platte tekst notitie die beschrijft wat de module doet, wat niet, en welke bestanden het mag aanraken. De agent krijgt dit bestand elke keer als onderdeel van zijn context. Het klinkt bureaucratisch. Het snijdt scope creep aanzienlijk.

Er is een gerelateerd punt over bestandsgrenzen. Agents zullen graag refactoren over bestanden heen als je ze daar scope voor geeft. Meestal wil je dat niet. Expliciete instructies over welke bestanden in scope vallen voor een bepaalde fase zijn niet overvoorzichtig. Ze zijn de taak.

Testen is niet optioneel en het is niet het idee van de agent

De agent schrijft tests als je daar om vraagt. Het schrijft tests die tegen de code die het zojuist schreef slagen. Dat is niet hetzelfde als tests die het gedrag beschrijven dat je spec vereist.

De discipline hier is om de testgevallen zelf te schrijven, in de specfase, voordat er implementatie gebeurt. Beschrijf de inputs, de verwachte outputs, en de randgevallen. Geef dat vervolgens aan de agent als onderdeel van zijn instructies voor elke fase. Nu zijn de tests gegrond in de spec, niet in de implementatie.

Dit is een variant van test-driven development, toegepast op agentworkflows. Het gaat niet om methodologie voor eigen sake. Het gaat erom de output van de agent falsifieerbaar te houden. Kun je niet zeggen of de agent deed wat je wilde, dan kun je er niet op voortbouwen.

Wat dit betekent voor agency-teams

Voor studio's die tegelijk drie of vier productstromen draaien, heeft dit soort structuur een tweede voordeel naast outputkwaliteit. Het maakt agent-ondersteund werk reviewbaar voor iemand die niet in de sessie zat.

Een spec, een faselog, en een diffgeschiedenis zijn auditabel. Een lang chatthread niet. Als een klant vraagt waarom een component zo werkt, of als een developer halverwege een project toekomt, betaalt het gestructureerde proces zich zelf terug.

De teams die het meest uit agent-ondersteunde development halen, zijn nu niet de teams met de meest capabele modellen of de cleverste prompts. Het zijn de teams die procesontwerp net zo serieus nam als tooling. De agent is snel. Structuur is wat snel nuttig maakt.

Als je huidige workflow een chatvenster en optimisme is, dat is een redelijk startpunt. Het is alleen niet waar je wilt blijven.