Moet je een AI-agent onbewaakt code laten schrijven en uitvoeren in je bedrijf?

Je hebt waarschijnlijk de demo's gezien: typ een zin, en een AI-agent schrijft een app, voert deze uit, vindt de bug, repareert deze en rapporteert terug — zonder developer tussenin. Tools zoals codegraff, een open-source "agentic coding harness" gebouwd in Zig, duwen dit verder dan de chatbot-achtige AI-codeeringsassistenten waar de meeste teams mee vertrouwd zijn. In plaats van een coderegel voor te stellen terwijl een mens typt, neemt het een taak — "zet deze map met rommelige CSV's om in één schoon spreadsheet," "ontdek waarom mijn site traag is, en repareer het" — en voltooit het hele werk: schrijft de code, voert deze uit, controleert het resultaat en itereert totdat het klaar is.

Voor een bedrijfseigenaar of IT-manager is dat tegelijkertijd opwindend en licht alarminerend. Opwindend, omdat het echte productiviteit belooft voor het saaie-maar-noodzakelijke werk waar niemand tijd voor heeft. Alarminerend, omdat "een AI voerde code uit op mijn echte bestanden met echte internettoegang, zonder dat ik toekeek" een zin is die elke IT-manager moet doen pauzeren. Dit artikel breekt af wat echt anders is aan deze nieuwe generatie "agentic" codeeringstools, wat codegraff's eigen cijfers onthullen over hoe deze systemen worden geëvalueerd, en een praktische checklist voor het bepalen of — en hoe — uw bedrijf er een in de buurt van productiesystemen mag brengen.

Wat maakt een "agentic" codeeringstool anders dan Copilot-achtige AI-assistentie?

De meeste bedrijven die een teen in AI-ondersteunde ontwikkeling hebben gestoken, hebben iets zoals GitHub Copilot gebruikt: het zit in de editor en stelt code voor terwijl een ontwikkelaar rijdt, beoordeelt en elke wijziging vastlegt. De mens doet nog steeds het werk; de AI doet automatisch aanvullen met context.

Een agentic harness zoals codegraff keert die relatie om. Je beschrijft een resultaat — "bouw me een kleine app om mijn trainingen bij te houden," "schraper deze vijf pagina's en vat ze samen," "voer een experiment uit: probeer drie versies hiervan en zeg me welke het best scoort" — en de agent plant de stappen, schrijft de code, voert deze uit in een echte terminal tegen echte bestanden, roept internet aan als nodig, en kan zelfs sub-agents in parallel opdraaien om aan verschillende delen van de taak tegelijk te werken. Het gaat door, controleert zijn eigen output, totdat de taak als voltooid wordt beschouwd.

Dit is een zinvolle verschuiving voor een bedrijf: je beoordeelt niet langer code regel voor regel terwijl deze wordt geschreven. Je beoordeelt (of beoordeelt niet) een afgewerkt resultaat dat is geproduceerd door een proces dat je niet rechtstreeks hebt toezien.

Waarom praat codegraff zo veel over tokens, calls en kosten — en waarom zou dat voor jou moeten uitmaken?

Een detail dat opvalt in codegraff's eigen documentatie is hoeveel het zichzelf benchmarkt op efficiëntie, niet alleen capaciteit. Zijn README publiceert head-to-head vergelijkingen tegen andere agent harnesses (grok-build, OpenCode) op gedeelde codeeringstaken, gemeten aan:

• Pass rate — heeft de agent de taak daadwerkelijk correct voltooid (12/12 fixtures in zijn eigen benchmark)
• Wall time — hoe lang de hele taak duurde (201s vs 388s vs 310s in het voorbeeld)
• Tool calls — hoeveel afzonderlijke acties de agent nodig had
• Tokens consumed — een proxy voor hoeveel het "dacht" (230k vs 1.17M vs 737k)
• Dollar cost per run — de werkelijke API-rekening voor de taak ($0,34 vs $1,05 vs $0,93)

Dit is van belang voor een zakelijke lezer om een heel praktische reden: agentic coding is niet gratis per taak zoals een salaris van een menselijke ontwikkelaar een vaste maandelijkse kostprijs is. Elke autonome run verbruikt tokens van een onderliggend AI-model, en als een agent een inefficiënte route neemt — grote bestanden opnieuw lezen, mislukte stappen opnieuw proberen, tools aanroepen die het niet nodig heeft — dan verschijnt die inefficiëntie rechtstreeks op je rekening, mogelijk per taak, per dag, op schaal. Een tool die 3-5x meer token-efficiënt is op dezelfde taak is niet alleen een mooie benchmark-overwinning; het is het verschil tussen agentic AI als een afrondingsfout in je budget of een echte terugkerende kostenlijn die je moet volgen zoals cloud-infrastructuuruitgaven.

De praktische les: als je agentic codeeringstools voor je bedrijf evalueert, vraag niet alleen "kan het de taak doen?" Vraag "wat kost het, in tokens en dollars, wanneer het de taak 50 keer per week doet?"

Wat zijn de echte risico's van een AI-agent zoveel autonomie geven?

Denk door een concreet scenario: een interne ontwikkelaar vraagt een agent om "repareer waarom de klantexport traag is." De agent heeft bestandstoegang, kan code uitvoeren en kan internet bereiken. Om het probleem daadwerkelijk op te sporen, moet het mogelijk productiegegevens-samples lezen, een pakket installeren dat het nodig acht, of een databasequery herstructureren. Elk van die is een normale debuggingstap voor een mens — maar een menselijke ontwikkelaar heeft ook oordeel over wat veilig is aan te raken, wat eerst een backup nodig heeft, en wat een aparte pull request voor beoordeling zou moeten zijn.

Een autonome agent die hetzelfde werk doet, heeft die guardrails expliciet ontworpen, want het zal precies doen wat de taak als "klaar" markeert — niet noodzakelijk wat een voorzichtige senior developer zou kiezen. Dit is hetzelfde vertrouwensprobleem dat bedrijven al kennen van API-integraties en automatische data-syncs: de tool is krachtig, maar de foutmodus van "het werkte, maar het deed iets wat je niet verwachtte" is gevaarlijker dan de foutmodus van "het werkte niet."

Concrete risico's die het waard zijn om te noemen voordat je het adopteert:

• Ongecontroleerde wijzigingen die echte bestanden of echte gegevens bereiken. Een agent die "door je bestanden graaft" is één verkeerd geconfigureerde taak verwijderd van het aanraken van een bestand dat het niet zou moeten.
• Onbegrensde kosten of runaway loops. Een agent ingesteld op "itereren totdat klaar" op een vage taak kan veel meer tokens (en geld) verbruiken dan verwacht als de taak slecht is afgebakend.
• Veiligheidsblootstelling via internettoegang. Een agent die "het web onderzoekt" als onderdeel van zijn normale workflow is een nieuw kanaal voor prompt injection of exfiltratie als het niet is geïsoleerd.
• Vaardigheidserozie en audit-gaten. Als niemand controleert wat de agent schreef of waarom, verlies je de institutionele kennis die een menselijke ontwikkelaar normaal zou opbouwen — en je verliest een schoon audittrail voor compliance-gevoelige industrieën.
• Model- en vendor-afhankelijkheid. Agentic harnesses zitten bovenop een specifiek AI-model/abonnement (codegraff, bijvoorbeeld, is gebouwd rond een specifiek model en API). Het gedrag van je automatisering kan verschuiven wanneer het onderliggende model verandert.

Hoe moet een bedrijf daadwerkelijk agentic codeeringstools evalueren voordat je ze gebruikt?

Gebruik deze checklist voordat je een agent — codegraff of anderszins — laat draaien tegen echte bedrijfssystemen:

1. Begin in een sandbox, niet in productie. Geef het een kopie van bestanden of een wegwerpomgeving eerst, nooit echte klantgegevens.
2. Baken de taak nauw af. "Dit ene CSV opschonen" is veiliger en meetbaarder dan "onze data pipeline verbeteren."
3. Vereisen een stap voor menselijke beoordeling voordat merge of deployment. Autonomie bij het opstellen van code is prima; autonomie bij het verzenden ervan meestal niet, nog niet.
4. Volg kosten per taak, niet alleen per maand. Vraag om token/dollar-rapportage per run zodat een runaway taak onmiddellijk zichtbaar is, niet aan het eind van de factureringscyclus.
5. Controleer welke netwerk- en bestandstoegang het daadwerkelijk nodig heeft. Beperk internet- en bestandssysteembereik tot het minimum dat de taak vereist.
6. Houd een changelog of audittrail bij. Weet wat de agent veranderde, wanneer en waarom — dezelfde discipline die je van commit history van een menselijke ontwikkelaar zou verwachten.
7. Evalueer opnieuw naarmate het onderliggende model wordt bijgewerkt. Agentic tools erven de sterke punten en eigenaardigheden van welk model ze ook aansturen; gedrag kan veranderen zonder dat je workflow verandert.

Vervangt dit developers, of verandert het wat ze doen?

Geen van beide hype cycles is helemaal juist. Agentic codeeringstools zijn echt goed in de klasse van taken die saai, goed gedefinieerd en laag risico zijn: data herformatteren, een klein hulpprogramma schrijven, geschrapte pagina's samenvatten, repetitieve experimenten uitvoeren. Dat is echte tijd die aan een bedrijf wordt teruggegeven — het soort taak dat anders weken in een developer's backlog blijft zitten omdat het nooit dringend genoeg is om prioriteit te geven.

Wat het niet vervangt is de beoordelingslaag: beslissen welke systemen veilig zijn aan te raken, hoe een wijziging in een grotere architectuur past, wat het bedrijf werkelijk nodig heeft versus wat letterlijk werd gevraagd, en wie verantwoordelijk is wanneer iets breekt. Die beoordelingslaag is precies waar een interne ontwikkelaar of ervaren software-partner zijn geld verdient — steeds meer door agentic tools te regisseren en te beoordelen in plaats van elke regel zelf in te typen.

Veelgestelde vragen

Is codegraff hetzelfde als GitHub Copilot? Nee. Copilot is een in-editor assistent die code voorstelt terwijl een mens rijdt. codegraff is een autonome harness die een tskbeschrijving neemt, vervolgens onafhankelijk code schrijft, uitvoert en aanpast, met een terminal, echte bestanden en internettoegang.

Kan agentic codeeringstool werken met een aangepast systeem zoals FileMaker of een maatwerk ERP? In principe ja — elke agent met bestands- en terminaltoegang kan worden gericht op een codebase of scripts met betrekking tot een aangepast systeem. Maar dezelfde voorzichtigheid geldt hier dubbel: aangepaste bedrijfssystemen coderen vaak jaren van specifieke bedrijfslogica, en een agent zonder die context kan iets "repareren" op een manier die een regel breekt die niemand heeft gedocumenteerd.

Wat is het enige grootste wat je moet controleren voordat je er een aanneemt? Waar de guardrail zit tussen "agent ontwerpt een wijziging" en "wijziging gaat live." Als die poort ontbreekt of informeel is, repareer dat eerst voordat je iets anders over de tool evalueert.

Elimineren deze tools de noodzaak van een ontwikkelingsteam? Nee — ze verschuiven het werk van het team naar het bepalen van taken, het beoordelen van output en het onderhouden van de systemen die de agent aanraakt, in plaats van de noodzaak van expertise uit te schakelen.

Bij Loggix zien we deze verschuiving uit de eerste hand: clients vragen steeds meer niet "kan AI deze feature schrijven" maar "waar in ons FileMaker-systeem, onze ERP of onze API-integraties zou een AI-tool veilig een repetitieve taak kunnen overnemen, en waar moet een mens in de lus blijven." Dat is precies het soort beoordeling dat het waard is om met een ervaren partner uit te voeren voordat je een autonome agent in een live bedrijfssysteem bedrading — of het doel nu het toevoegen van AI-ondersteunde automatisering binnen een bestaande FileMaker-oplossing is, het bouwen van een nieuwe integratie, of simpelweg het in kaart brengen welke delen van je workflow veilig eerst te automatiseren zijn.