AI-Assisted & Agentic SDLC: de software development lifecycle in het AI-tijdperk.

Eerst even: de termen op een rij.

Rond AI in software-ontwikkeling circuleren veel termen door elkaar. Goed om er drie uit elkaar te houden voordat we verder gaan:

De Agentic SDLC is waar dit stuk over gaat: een ontwikkelproces waarin AI-agents zelfstandig taken uitvoeren, terwijl de mens de kaders stelt en de output beoordeelt. AWS bracht hier een concreet framework voor uit onder de naam AI-DLC (AI-Driven Development Lifecycle), met fasen als Inception, Construction en Operations. Let op het verschil met de Agent Development Lifecycle, ook wel ADLC. Die term, geclaimd door onder meer IBM en Salesforce, gaat over het bouwen van een AI-agent als product: hoe je een agent ontwerpt, test en in productie brengt. Dat is een ander onderwerp.

Kort gezegd: de Agent Development Lifecycle gaat over het bouwen van een agent, de Agentic SDLC over hoe agents jouw software bouwen. Dit stuk gaat over dat laatste: hoe AI het werk in een dev-team verandert.

De klassieke SDLC.

In de klassieke SDLC schrijven ontwikkelaars zelf elke regel code. Het proces loopt lineair van requirements naar design, build, test, deploy en monitoring, en bij elke stap zit een mens aan het stuur. AI speelt geen rol, of hooguit een marginale: een spellingscheck, een zoekopdracht, niets dat het werk wezenlijk verandert. Dit is geen achterhaald model, voor veel organisaties is het nog steeds de dagelijkse realiteit en voor sommige soorten werk is het terecht. Waar elke regel telt en de foutmarge nul is, wil je een mens die elke beslissing neemt. Code wordt volledig handmatig geschreven en gereviewd, AI-tools zijn niet ingebed in de workflow.

Wat dit oplevert is maximale controle en voorspelbaarheid: elke beslissing is herleidbaar naar een persoon. De keerzijde is snelheid, want alles gaat zo snel als mensen kunnen typen, lezen en reviewen. Governance is hier vrijwel een non-issue. Dit is het model waar de meeste compliance-kaders impliciet van uitgaan, verantwoordelijkheid is helder omdat overal een mens tussen zit, en er zijn geen nieuwe vragen over wie aansprakelijk is als een machine een beslissing neemt, omdat geen machine beslissingen neemt.

De AI-Assisted SDLC.

In de AI-Assisted SDLC blijft het proces lineair, maar krijgt de ontwikkelaar gezelschap. AI-tools genereren codesuggesties, helpen bij code review, schrijven testopzetten, verklaren onbekende code. De mens beslist nog steeds alles, de AI maakt elke stap sneller. Ontwikkelaars gebruiken dagelijks AI-tools, maar de mens drukt elke keer op de knop. Geen enkel proces draait zonder dat iemand de output goedkeurt en doorzet. De winst zit op individueel niveau, niet in het systeem. Denk aan een copilot in de editor, AI-suggesties in je merge request, een chatassistent naast je terminal. Dit is waar het overgrote deel van de software-organisaties nu zit, ook al wordt er in de markt gepraat alsof iedereen morgen met agents werkt. De sprong vanuit de klassieke SDLC is groot en direct voelbaar, en het is verleidelijk om te denken dat meer AI-suggesties automatisch meer productiviteit betekenen.

Tijd kwijt aan inefficiëntie.

Daar zit een addertje. Uit GitLab's jaarlijkse DevSecOps-onderzoek blijkt dat teams gemiddeld zeven uur per persoon per week kwijt zijn aan inefficiëntie: schakelen tussen tools, context opnieuw opbouwen, wachten op overdrachten. Als je AI alleen inzet om sneller te tikken, los je dat niet op. Je produceert sneller code en schuift de bottleneck door naar review, integratie en wachttijd. Dat is de AI-paradox: meer individuele snelheid, niet per se meer winst op de doorlooptijd.

De winst is wel echt, vooral op repetitief werk: boilerplate, testopzetten, documentatie, het doorgronden van vreemde code. Maar de eerlijke meting is lastiger dan het lijkt, want regels code of aantal suggesties zeggen weinig. Kijk naar doorlooptijd van issue tot merge, naar reviewtijd, naar hoeveel herwerk er nodig is. Hier ontstaan ook de eerste echte governance-vragen. Wie is verantwoordelijk voor AI-gegenereerde code die de mist in gaat? Het antwoord is nog steeds helder, want de mens keurt goed, maar je wilt vastleggen welke tools je gebruikt, welke data ze zien en hoe je voorkomt dat gevoelige code naar een externe dienst lekt. Dit is het moment om een AI-gebruiksbeleid op te stellen, voordat agents zelfstandig aan de slag gaan.

De Agentic SDLC.

In de Agentic SDLC voeren AI-agents delen van het ontwikkelproces zelfstandig uit. Niet de mens die een suggestie accepteert, maar een agent die een issue oppakt, een merge request opent, een CI/CD-pipeline repareert, en pas bij een beslissing van gewicht terugkoppelt naar een mens. Je hebt agents in productie die zelfstandig merge requests openen of issues bewerken. Je hebt een AI catalog of vergelijkbare structuur waarin agents centraal staan. Je hebt een onderscheid tussen wat een agent zelfstandig mag doen en wat altijd menselijke goedkeuring vereist. Je merge request queue bevat regelmatig MR's met "opened by agent" als bron. Het proces is niet langer puur lineair: het wordt een samenspel waarin mens en agent elk een eigen rol hebben.

De mens definieert het kader, de agent neemt operationele beslissingen binnen dat kader. Reviews verschuiven van regel-voor-regel naar gedragsmatig: doet de agent wat we afspraken, blijft hij binnen de guardrails, en als er iets misgaat, kunnen we het reconstrueren? Het primaire artefact verschuift mee: niet langer alleen de code, maar ook de context, de intentie en de evaluatiecriteria waarmee je de agent beoordeelt.

Hoe zit dat bij Cube?

Bij Cube draaien inmiddels agents in productie. Ze nemen routinewerk over dat voorheen handmatig langs een mens ging, zoals het voorsorteren van merge requests of het scherper maken van nieuwe issues. Wat eerst een handmatige stap was, gebeurt nu deels automatisch. We houden zicht via de merge request reviews en de pipeline-logs, niet door over de schouder mee te kijken. De winst zit hier niet meer in sneller tikken, maar in het wegnemen van wachttijd en overdrachten, precies het soort verlies waar de AI-paradox over gaat.

En hier wordt governance een serieuze vraag. Wie is verantwoordelijk voor een agent die buiten zijn kader handelt, en hoe audit je een proces dat deels autonoom verloopt? De EU AI Act stelt eisen aan hoog-risico AI-systemen, en agents die zelfstandig wijzigingen in productiecode voorstellen kunnen daaronder vallen. De richting is duidelijk: logging van agent-acties, transparante guardrails en menselijke goedkeuring op kritieke beslissingen worden geen optionele extra's meer. Bij ons begint dat bij role-based access en logging via een MCP-server.

Waar staat jouw organisatie?

Geen quiz, wel concrete signalen. Loop ze even langs en zie waar je uitkomt.

• Je herkent jezelf in de klassieke SDLC als je dev-team geen AI-tools gebruikt of slechts incidenteel. Code wordt volledig handmatig geschreven en gereviewd. AI is bij jullie een onderwerp dat in het MT besproken wordt, niet in de dagelijkse ontwikkelpraktijk.

• Je werkt volgens de AI-Assisted SDLC als AI-tools dagelijks gebruikt worden, maar een mens elke keer de output goedkeurt en doorzet. Je merkt productiviteitswinst per ontwikkelaar, maar geen enkel proces draait zonder dat iemand op de knop drukt. Dit is waar de meeste organisaties nu zitten, en dat is geen achterstand. Het is de basis waarop de rest verdergaat.

• Je zit in de Agentic SDLC als je agents in productie hebt die zelfstandig stappen zetten binnen kaders die jij hebt gesteld. Je hebt een expliciet onderscheid tussen wat een agent alleen mag doen en wat altijd langs een mens gaat. Je governance is meegegroeid: logging, guardrails, audit.

De meeste organisaties werken volgens de AI-Assisted SDLC met een paar tenen in de Agentic SDLC. Dat is precies waar het interessant wordt, want de stap van assisteren naar zelfstandig uitvoeren vraagt niet om meer AI, maar om een ander proces eromheen.

Hoe goed kunnen je processen de output aan?

De verleiding is om naar het volgende model te willen omdat het kan. Maar de winst zit niet in hoe autonoom je agents zijn, hij zit in hoe goed je proces de output aankan. De meeste organisaties hebben meer aan een scherpere review-praktijk en heldere guardrails dan aan een extra agent. Wat door alle drie de modellen heen constant blijft, is dat de mens beslist wat goed genoeg is. AI versnelt het typen, neemt het routinewerk over en straks zelfstandig hele stappen, maar het oordeel verdwijnt niet. Het verandert alleen van vorm: van zelf code schrijven naar kaders stellen en gedrag beoordelen. Wie dat oordeel scherp houdt, kan elk model aan. Zo wordt de stap naar zelfstandig werkende agents vanzelf logisch in plaats van eng.