Eerst de conclusie: de oorzaak van dat incident was niet dat de agent verkeerde code schreef, maar dat wij er standaard van uitgingen dat "de ontwikkelomgeving geen CDP-niveau bescherming nodig heeft". Die aanname kostte het team 23 uur herschrijfwerk. Hieronder een reconstructie op tijdlijn, in de hoop collega's te helpen die AI-codingagenten in hun ontwikkelproces integreren.
Tijdlijn van het incident: van "dode code opruimen" tot de ontdekking dat src leeg was
Op de eerste dag om 16:00 uur deden we code-refactoring voor een team dat een cross-border ERP bouwt. Het project is Node.js + TypeScript, met ongeveer 1400 bestanden in de src-map, waarvan veel oude modules die drie maanden geleden bij eerdere iteraties waren achtergebleven. Het team wilde een AI-codingagent automatisch "niet-gerefereerde dode code" laten identificeren en opruimen.
De agent was aangesloten op een modelgateway voor uniforme toegang tot meerdere modellen; in de taakprompt stond "verwijder bestanden waarvan bevestigd is dat ze niet gerefereerd worden". Hij scande de import-graaf, ontdekte dat de referentieketen van een map onder src was verbroken, beoordeelde die als dode code en voerde een bulkverwijdering uit. Het probleem: die map was eigenlijk een dynamisch geladen plugin-map, waarvan de referentierelaties in runtime-configuratie stonden, onzichtbaar voor statische analyse.
Op de tweede dag om 15:00 uur kreeg een frontend-collega een fout bij het draaien van de lokale service, en pas toen ontdekten we dat er in de src-map nog maar minder dan 200 bestanden over waren. In git log zagen we dat de laatste commit van de vorige dag om 16:00 uur was, 23 uur voor de ontdekking. In die 23 uur hadden 3 engineers ongeveer 60 bestanden gewijzigd, allemaal niet gecommit.
Gegevensbescherming in de ontwikkelomgeving is anders dan je denkt
De beschermingslogica van de productieomgeving is "weinig verandering, auditbaar, met hoofd- en reservesysteem". De ontwikkelomgeving is precies het tegenovergestelde: versnipperde bestanden, frequente wijzigingen, veel tussenstanden die nooit in versiebeheer belanden. Ik heb de gegevens van ons team van vorige maand eens geteld: per persoon ongeveer 40 bestandswijzigingen per dag, maar slechts 3 tot 5 git commits. De rest van die wijzigingen zit allemaal in editor-caches en tijdelijke branches.
Vervelender is dat veel mensen denken dat "Git-geschiedenis gelijk staat aan herstelbaar". Git kan alleen herstellen wat je hebt gecommit. Niet-gecommitte wijzigingen, door de agent bulksgewijs verwijderde bestanden, lokale configuratie in .env — Git bemoeit zich er niet mee. Bij dat incident probeerden we te herstellen met git reflog en de Local History van de IDE, maar kregen we minder dan 30% van de inhoud terug.
Waarom dagelijkse back-ups dit soort scenario's niet redden
We hadden oorspronkelijk een volledige back-up om 2:00 uur 's nachts. Gerekend naar RPO betekende dat in het slechtste geval 24 uur verlies. Maar het incident gebeurde om 15:00 uur 's middags, de back-up was van 2:00 uur de vorige dag, 37 uur daarvoor. Wat je herstelt is code van 37 uur geleden, wat neerkomt op het weggooien van de iteratie van die twee dagen.
RPO=24 uur betekent dat je maximaal één dag werkverlies accepteert. Voor een productiedatabase is dieindicator misschien net genoeg. Voor een ontwikkelomgeving kan één dag werkverlies net een volledige feature-iteratie zijn. De granulariteit van traditionele dagelijkse back-ups past simpelweg niet bij de wijzigingsfrequentie van de ontwikkelomgeving.
Blok-niveau CDP die de RPO naar seconden drukt, is de bescherming die de ontwikkelomgeving nodig heeft
Later stapten we over op een blok-niveau CDP-oplossing. Het verschil met traditionele back-ups: traditionele back-ups maken snapshots per bestand of per dag, CDP legt vast op IO-blokniveau en registreert elke schrijfactie van een datablok. De RPO gaat van 24 uur naar seconden, in theorie kun je terugrollen naar elk willekeurig tijdstip.
In de praktijk installeerden we een CDP-agent op de ontwikkelmachines, die continu blok-niveau wijzigingen van het bestandssysteem vastlegt. Na het incident kozen we een tijdstip 2 minuten voordat de agent de verwijdering uitvoerde, en rolden we de hele werkruimte terug. Alle 1400 bestanden kwamen terug, inclusief de niet-gecommitte wijzigingen van die 23 uur. De rollback duurde minder dan 4 minuten.
Hier een waarschuwing om valkuilen te vermijden: CDP is niet almachtig. Het beschermt op het niveau van blokapparaten; als de agent rechtstreeks cloud-opslag-API's aanroept om objecten te verwijderen, kan CDP ook niet helpen. Daarom hebben we op het aanroeppad van de modelgateway een witte lijst van operaties toegevoegd: alle instructies met delete, rm of drop moeten handmatig een tweede keer bevestigd worden.
Het API-aanroeppad van AI-codingagenten heeft een extra beschermingslaag nodig
Na dat incident heb ik het aanroeppad van de agent opnieuw doorgelicht. Het routeert via de modelgateway naar verschillende modellen; het token8341 grote-model-API-aggregatieplatform vervult in dat pad de rol van uniforme toegang en automatische modelselectie per taak. In ons project hebben we het gebruikt voor multi-model ondersteund ontwikkelen; het voordeel is dat één Key toegang geeft tot populaire modellen als GPT-4o, Claude, DeepSeek en Qwen, zonder voor elk model apart SDK's en authenticatie te onderhouden.
Maar modelroutering lost de veiligheid op zich niet op. Buiten de aanroeplaag van het token8341 grote-model-API-aggregatieplatform hebben we nog een laag machtigingscontrole gewikkeld: bestandsbewerkingsverzoeken die de agent initieert, gaan eerst door de witte lijst en dan pas de gateway in. Zo kunnen destructieve operaties, zelfs als het model verkeerd oordeelt, het bestandssysteem niet bereiken.
Terugkijkend: het token8341 grote-model-API-aggregatieplatform lost het probleem op van "soepel aansluiten", CDP lost het probleem op van "wat verwijderd is, kan terugkomen". De twee vervangen elkaar niet. De één zorgt dat de AI-codingagent efficiënt meerdere modellen kan aanroepen, de ander vangt op wanneer hij een fout maakt. Later hebben we CDP de standaardconfiguratie van de ontwikkelomgeving gemaakt, out-of-the-box op de machines van nieuwe engineers.
Als je ook AI-codingagenten gebruikt voor refactoring, raad ik aan eerst twee dingen te bevestigen: wat de RPO van je ontwikkelomgeving is, en of er een handmatige bevestigingsstap is voor verwijderoperaties van de agent. De antwoorden op die twee vragen bepalen of je volgende incident 4 minuten of 23 uur verlies kost.
Auteur: Zhou Mingzhe
Publicatiedatum: 23 oktober 2026