Code op het scherm van een Foreside-engineer

Agentic engineering onder de motorkap

Iedereen heeft inmiddels een AI-assistent in de editor. Wij bouwden er een werkwijze omheen. Een technische kijk op hoe agents bij ons code schrijven, testen en reviewen, en waarom de vangrails belangrijker zijn dan het model.

Van autocomplete naar agents: een ander soort gereedschap

De eerste generatie AI-tooling maakte zinnen af. Handig, maar het bleef typewerk met een turbo. De huidige generatie werkt anders: een agent krijgt een opdracht, leest zelf de codebase, draait commando's, schrijft code, voert de tests uit en komt terug met een resultaat. Het verschil zit in de lus. Waar autocomplete één suggestie doet, itereert een agent net zo lang tot de tests groen zijn of hij vastloopt op iets dat een besluit vraagt.

Dat klinkt magisch, maar het is vooral systeembouw. Een agent is een taalmodel in een lus met gereedschap: bestanden lezen en schrijven, een terminal, een zoekfunctie. De kwaliteit van het resultaat wordt bepaald door wat je die lus meegeeft en welke grenzen je stelt. Precies daar zit ons vak: niet in het model, maar in alles eromheen.

Context is het echte engineeringprobleem

Een model weet niets van jouw project totdat je het vertelt. Alles wat de agent nodig heeft moet door een beperkt contextvenster: de opdracht, de relevante code, de conventies, de valkuilen. Wie zomaar een hele repository naar binnen schuift, krijgt een agent die verdrinkt in ruis. Wie te weinig meegeeft, krijgt zelfverzekerde code die langs het echte probleem heen werkt.

Daarom optimaliseren we onze codebases voor leesbaarheid door machines, en dat blijkt verrassend vaak hetzelfde als leesbaarheid voor mensen. Kleine bestanden met één verantwoordelijkheid. Conventies die op één plek beschreven staan, in gewone taal, mét het waarom erbij. Namen die zeggen wat iets doet. Een projectgeheugen waarin de afspraken staan die je anders in hoofden bewaart. Elk project krijgt bij ons zo'n grondwet, en de agents lezen hem bij elke taak.

Vangrails: snelheid zonder schuld

Het risico van agents is niet dat ze slechte code schrijven. Het risico is dat ze heel veel plausibele code schrijven, sneller dan je kunt beoordelen. Zonder vangrails wordt versnelling dus vooral een snellere opbouw van technische schuld. Onze eerste regel: de agent bewijst zijn werk. Tests eerst waar dat kan, en een wijziging is pas af als de volledige poort groen is: build, linter, testsuite, en op kritieke paden een productie-smoke.

De tweede regel: begrensde bevoegdheden. Agents draaien in een omgeving waarin ze niet zomaar overal bij kunnen: geen productiedata, geen secrets, geen rechtstreekse deploy. Riskante acties vragen expliciete toestemming. En de derde regel is de oudste van het vak: vier ogen op elke commit, waarvan minstens twee menselijke. De agent mag schrijven, een engineer besluit wat er in de hoofdbranch komt.

De pipeline: verkennen, specificeren, bouwen, bewijzen

Eén agent die alles doet werkt niet goed, om dezelfde reden dat één mens die alles doet niet schaalt. Wij knippen werk op in rollen. Een verkenner leest de codebase en rapporteert hoe het er echt voor staat, zonder iets aan te passen. Een specificeerder werkt de aanpak uit tot een plan met acceptatiecriteria. Bouwers voeren uit. Een verifieerder toetst het resultaat van buitenaf, zoals een gebruiker of een klant dat zou doen, en een validator beoordeelt het werk tegen onze conventies.

Tussen die stappen zitten menselijke keuzemomenten, precies op de plekken waar een fout duur is: klopt het plan, klopt de specificatie, is het eindresultaat goed genoeg. Dat lijkt op bureaucratie, maar het tegendeel is waar. Doordat elke rol een scherpe taak heeft, kunnen de stappen elkaar snel opvolgen en parallel draaien. De doorlooptijd van idee naar geverifieerde feature wordt korter, niet langer.

Elke rol heeft één taak, en op twee plekken beslist een mens: klopt de aanpak, en is het resultaat goed genoeg.

Meten of het werkt, niet voelen of het went

De vraag die elk team moet kunnen beantwoorden: worden we hier echt beter van? Dat meet je niet met een tevredenheidspoll. Wij kijken naar de uitkomsten die er voor een klant toe doen: hoe snel staat een wijziging veilig in productie, hoeveel incidenten komen er uit nieuwe code, hoeveel tijd gaat er naar herstelwerk versus nieuw werk. Sinds we agentic werken, bewegen die cijfers de goede kant op, en juist daarom durven we ze op onze site te zetten.

Even belangrijk is weten waar het niet werkt. Agents zijn zwak in problemen waar de specificatie het echte werk is, in code met veel impliciete context, en in beslissingen met gevolgen buiten de codebase. Die grenzen verschuiven per maand, dus we hertesten ze per maand. Een werkwijze die op bezwering leunt in plaats van op meting, is geen engineering meer.

De techniek is het makkelijke deel

Een agent aan de praat krijgen kost een middag. Een werkwijze bouwen waarin agents aantoonbaar betere software opleveren, kost maanden van conventies aanscherpen, vangrails bouwen en meten. Dat is de investering die wij voor onze klanten al gedaan hebben. Benieuwd hoe dit er in jouw codebase uit zou zien?

Plan een kennismaking