Kennisbank / Agentic AI-systemen
Over AI die code schrijft is genoeg gezegd. Het interessantere deel is wat er daarna gebeurt: publiceren, bewaken, repareren en actueel houden. Daar gaat namelijk de meeste tijd en het meeste geld in zitten, en daar is nog nauwelijks iets van geautomatiseerd.
Een website opleveren is makkelijk. Hem twee jaar later nog snel, veilig en vindbaar hebben niet.
Bouwen. Een AI-systeem met toegang tot je codebase schrijft de pagina of de functie, sluit de database aan, schrijft de teksten in de vastgelegde tone of voice en zet het geheel klaar. Een landingspagina voor een campagne wordt daarmee een gesprek van tien minuten in plaats van een sprint.
Publiceren. Het systeem draait de build, controleert of die foutloos doorkomt, zet hem live en kijkt daarna zelf na of de pagina echt bereikbaar is met de juiste inhoud. Dit is de enige stap die altijd om goedkeuring hoort te vragen, want publiceren draai je niet terug met een undo.
Onderhouden. Hier zit het echte verschil. Bewaken of alles online is en hoe snel het laadt, een verlopend domein of certificaat zien aankomen, bijhouden welke onderdelen kwetsbaarheden krijgen en wat een veilige update is, gaten in de content vullen, de vindbaarheid toetsen.
Repareren. Ging er iets mis, dan leest het systeem de foutmelding, gaat de code na, reproduceert het probleem en komt met de oorzaak plus een voorstel. In het gunstige geval weet je van een storing pas dat hij er was doordat je hoort dat hij is opgelost.
De meeste bedrijven hebben fase één deels geautomatiseerd en de andere drie niet. Terwijl daar de terugkerende kosten zitten.
Onderhoud bestaat uit werk dat mensen slecht volhouden: regelmatig, saai, en pas urgent op het moment dat het al te laat is.
Precies daarom is dit het onderdeel waar automatisering het snelst rendeert. Meer over hoe zo'n systeem is opgebouwd staat in Wat is een agentic AI-systeem?.
Die laatste is er een die mensen structureel laten liggen. Documentatie die achterloopt is erger dan geen documentatie, want die stuurt je actief de verkeerde kant op.
Niet zelf live zetten. Publiceren hoort achter een menselijke goedkeuring, met de exacte wijziging erbij. Zie Wanneer mag AI zelf handelen?.
Niet zomaar afhankelijkheden bijwerken. Een update kan een kwetsbaarheid oplossen en tegelijk iets anders breken. Voorstellen en onderbouwen: ja. Ongevraagd doorvoeren: nee.
Niet stil repareren. Een systeem dat een probleem oplost zonder het te melden, verbergt een patroon. Dan weet je na drie maanden niet dat hetzelfde ding elke week omvalt.
Geen groen tonen zonder meting. Een dashboard dat "alles in orde" meldt over onderdelen die het niet controleert, is onbetrouwbaar geworden. Niet gemeten hoort grijs te zijn, niet groen.
Dit is de belangrijkste inrichtingskeuze van dit hele onderwerp, en hij kost je niets.
Geef een AI-systeem geen directe schrijftoegang tot je hoofdtak. Laat het in plaats daarvan een aparte tak maken, de wijziging daarin zetten en een verzoek openen. Jij bekijkt het verschil, en jij drukt op de knop.
Dat lost drie dingen tegelijk op. Je ziet exact wat er verandert voordat het live gaat. Er is een moment waarop je nee kunt zeggen zonder iets ongedaan te hoeven maken. En je houdt een leesbaar spoor van elke wijziging met de reden erbij, wat later goud waard is als je uitzoekt waarom iets is zoals het is.
Praktisch betekent dit dat je de toegang zo instelt:
⚠️ Let op waar die grens zit. Staat hij alleen in de instructie aan het model, dan is het een verzoek. Staat hij in de uitvoeringslaag, dan is het een garantie. Zie Wanneer mag AI zelf handelen?.
Een toegangstoken voor je code is standaard breder dan je denkt: vaak geldt het voor alles waar jij bij kunt, inclusief klantprojecten en andere producten. Dat is precies wat je niet wilt.
Beperk het tot de repositories die het systeem echt nodig heeft, en controleer daarna of dat ook zo is. Vraag een repository op die er níet in hoort te zitten: krijg je die te zien, dan is de instelling ruimer dan bedoeld. Wij deden die controle en het eerste token bleek inderdaad breder dan afgesproken.
Zet er ook een vervaldatum op. Missen we het over drie maanden niet, dan hadden we het niet nodig.
Drie dingen, en het eerste wordt het vaakst overgeslagen.
Context. Het systeem moet weten hoe jullie dingen doen, waar wat staat en waarom eerdere keuzes zijn gemaakt. Zonder die kennis levert het werk dat technisch klopt maar op de rest geplakt zit.
Toegang tot de juiste plekken. Je codebase, je hosting, je domeinbeheer, je foutmeldingen. Met rechten die niet ruimer zijn dan nodig, zie Wat is MCP?.
Een duidelijke grens. Wat mag het zelf, en wat gaat eerst langs een mens. Leg die vast voordat je begint, niet nadat er iets is misgegaan.
De directe winst is tijd: onderhoud dat niet meer op iemands lijstje staat. De grotere winst is dat problemen kleiner worden doordat je ze eerder ziet. Een certificaat dat over drie weken verloopt is een taak van twee minuten; hetzelfde certificaat dat vanochtend verliep is een storing, ontevreden klanten en een spoedklus.
En er is een derde effect dat lastiger te meten maar goed voelbaar is: dingen blijven op orde. De documentatie klopt, de links werken, de teksten zijn actueel. Niet omdat iemand er tijd voor vrijmaakte, maar omdat het gewoon gebeurt.
In ons eigen systeem staan onze marketingsite, ons SaaS-platform, de klantprojecten en alle documentatie in dezelfde omgeving. Het systeem werkt daar niet omheen maar erin: het schrijft de code, publiceert na goedkeuring, bewaakt daarna of alles online en snel blijft, en werkt de documentatie bij in dezelfde ronde als de wijziging.
Hoe dat er uitziet, staat in de case AI DevOps Center. Wil je dit voor je eigen website of applicatie? Bekijk custom software & AI-apps, AI agents & automatisering, of plan een gesprek.
dGEN Productions, AI agency en business-automation partner uit Eindhoven. info@dgenproductions.nl · 06-87413056