Een AI SDLC is de softwareontwikkelingscyclus waarin AI-agents het meeste programmeer-, test- en documentatiewerk doen, terwijl mensen de bedoeling, de specificatie, de review en de releasebeslissing in handen houden. De fasen blijven gelijk; de taakverdeling binnen die fasen verandert.

Wat is het verschil tussen een AI SDLC en de traditionele SDLC?

Bouwen wordt goedkoop en snel, dus het knelpunt verschuift naar heldere specs schrijven en het werk van agents reviewen. Werk begint bij een geschreven spec in plaats van een ticket, en drie menselijke controlemomenten (spec, review, release) vervangen het meeste handmatige programmeerwerk.

Hoe integreer je AI in de softwareontwikkelingscyclus?

Begin met één team en één soort werk, schrijf repositoryregels voor de agents, spreek drie controlemomenten af en meet 90 dagen lang doorlooptijd, reviewtijd en herstelwerk voordat je uitbreidt.

Worden ontwikkelaars sneller met AI?

Dat hangt af van je proces. Ruim 80% van de ontwikkelaars voelt zich productiever (DORA 2025), maar METR vond ervaren ontwikkelaars begin 2025 19% trager en Faros AI mat 91% meer reviewtijd. Teams met heldere specs en strenge review winnen het meest.

Wat is het verschil tussen AI SDLC en AI PDLC?

De AI PDLC is de volledige productcyclus: discovery, validatie, bouwen, lanceren en leren. De AI SDLC is het engineeringdeel daarbinnen: hoe software met AI-agents wordt gespecificeerd, gebouwd, getest, gereviewd en uitgerold.

Is een AI SDLC veilig voor Europese bedrijven?

Ja, met vangrails: akkoord van een mens voor merges en releases, agents in afgeschermde omgevingen zonder toegang tot geheimen, AVG-proof AI-leveranciers en een vastgelegde AI-geletterdheidstraining, die artikel 4 van de AI Act sinds februari 2025 verplicht stelt.

AI SDLC: wat het is, hoe het werkt en wat AI verandert aan de traditionele SDLC

November 2, 2026

Blog

Kort antwoord: een AI SDLC is de softwareontwikkelingscyclus waarin AI-agents het meeste programmeer-, test- en documentatiewerk doen, terwijl mensen de bedoeling, de specificatie en de eindcontrole in handen houden. Het grootste effect is niet dat alles sneller gaat. Het is dat de dure, trage stap verschuift van code schrijven naar bepalen wat je bouwt en controleren wat de agents hebben gemaakt.

In deze gids lees je wat een AI SDLC is, hoe het per fase werkt, wat er verandert ten opzichte van de traditionele SDLC, wat onderzoek echt zegt over productiviteit, hoe elke rol in je team verandert, en hoe je als mkb of scale-up in 90 dagen overstapt zonder een berg ongecontroleerde code.

Dit artikel is geschreven voor CTO's, engineering leads en founders die al werken met tools als Claude Code, Cursor of GitHub Copilot en een werkend proces eromheen willen, geen nieuw lijstje tools. Bijna alles wat nu over dit onderwerp rankt, is een playbook van een leverancier. Wij verkopen je geen platform, en we laten ook de resultaten zien die tegenvielen.

‍

De belangrijkste punten

• Een AI SDLC houdt de bekende fasen (plannen, ontwerpen, bouwen, testen, releasen, onderhouden), maar verandert wie het werk binnen elke fase doet. Agents maken een eerste versie, mensen beslissen.

• Het knelpunt verschuift. Bouwen wordt goedkoop, dus specificeren en reviewen worden het schaarse, waardevolle werk.

• Het bewijs is gemengd. 90% van de ontwikkelaars gebruikt AI (DORA 2025), maar in een gecontroleerde studie waren ervaren ontwikkelaars begin 2025 juist 19% trager met AI, en bij teams die veel AI gebruiken steeg de reviewtijd met 91%.

• Teams die winst boeken, hebben heldere specs, sterke tests en strenge reviewmomenten. AI versterkt het proces dat je al hebt, goed of slecht.

• Rollen verschuiven: ontwikkelaars reviewen en specificeren meer, tech leads bepalen de regels voor de agents, QA gaat van handmatig testen naar testontwerp.

• Governance is geen extraatje: goedkeuringsmomenten, een audit trail, veilig omgaan met geheimen en de AI-geletterdheidsplicht uit de AI Act gelden allemaal.

• Begin klein: één team, één soort werk, drie menselijke controlemomenten, en meet doorlooptijd, reviewtijd en herstelwerk voor en na.

‍

Wat is een AI SDLC?

Een AI SDLC (AI software development lifecycle, oftewel AI in de softwareontwikkelingscyclus) is een manier van software bouwen waarbij AI-agents een groot deel van het werk in elke fase uitvoeren, en menselijke engineers de richting bepalen, de regels vastleggen en het resultaat goedkeuren. De fasen zijn dezelfde die teams al tientallen jaren gebruiken. Wat verandert, is de taakverdeling binnen die fasen.

De term wordt voor drie verschillende dingen gebruikt, en daarom zijn de zoekresultaten zo verwarrend. De eerste betekenis is AI-ondersteund ontwikkelen: een ontwikkelaar schrijft code met autocomplete of een chatassistent ernaast. De cyclus blijft gelijk, alleen het typen gaat sneller. De tweede is de AI-native of agentic SDLC: agents pakken complete taken op vanuit een geschreven spec, schrijven code en tests, openen een pull request en wachten op review. Hier verandert de cyclus zelf, want de eenheid van werk wordt een spec in plaats van een ticket. De derde betekenis is de cyclus voor het bouwen van AI-systemen zelf, met dataverzameling, modeltraining en evaluatie. Dat is eigenlijk een ML-cyclus en een ander onderwerp.

Dit artikel gaat over de tweede betekenis, omdat daar in 2026 de echte verandering zit. Het helpt ook om de SDLC los te zien van de productcyclus eromheen. De SDLC gaat over hoe software gebouwd, getest en uitgerold wordt. De productontwikkelingscyclus gaat over het waarom: discovery, validatie, prioriteren en leren na de lancering. Daarover schreven we een aparte gids over de AI PDLC en hoe die werkt; de AI SDLC is de engineeringmotor daarbinnen.

‍

Traditionele SDLC vs AI SDLC: wat verandert er per fase?

De fasen verdwijnen niet. Eisen moeten nog steeds helder zijn, code moet nog steeds getest worden en releases moeten nog steeds veilig zijn. Wat verandert, is wie het werk per fase doet, wat het belangrijkste product van die fase is en waar een mens moet ingrijpen.

‍

Traditionele SDLC vs AI SDLC per fase vergeleken: plannen, ontwerpen, bouwen, testen, review, release en onderhoud, met de rol van de mens

‍

Het verschil zie je het best als je één feature volgt. In een traditionele opzet schrijft een productmanager een ticket, schat een ontwikkelaar het in, bouwt het in drie of vier dagen, schrijft wat tests en opent een pull request, waarna een collega het een dag later reviewt. De meeste kalendertijd zit in het bouwen.

In een AI SDLC begint dezelfde feature als een korte geschreven spec: wat het moet doen, wat het niet mag doen, hoe je het test en welke delen van de codebase het raakt. Een agent maakt van de spec een plan, een mens keurt het plan goed, de agent schrijft de code en de tests, en binnen enkele uren staat de pull request klaar. Daarna gaat de tijd ergens anders naartoe. Iemand moet een grote wijziging zorgvuldig lezen, de randgevallen vinden die de spec miste en beslissen of de wijziging veilig is. Het bouwen kromp. Het denkwerk ervoor en de controle erna groeiden.

Dat is de kern van de verschuiving, en het verklaart bijna alles wat volgt. Schrijft je team vage tickets en reviewt het oppervlakkig, dan levert een AI SDLC sneller meer code van onzekere kwaliteit op. Schrijft je team heldere specs en reviewt het goed, dan maak je met dezelfde mensen meer goede software.

‍

Hoe werkt een AI SDLC, stap voor stap?

Een AI SDLC werkt als een cirkel van geschreven documenten. Elke stap levert een document of wijziging op die de volgende stap leest, en drie stappen zijn menselijke controlemomenten waar niets verder gaat zonder akkoord van een persoon.

‍

Zo werkt een AI SDLC: de cirkel met 3 controlemomenten, van bedoeling en spec naar bouwen, review, release en observeren

‍

1. Bedoeling

Elk stuk werk begint met een korte beschrijving van de bedoeling: het probleem, de gebruiker, het gewenste resultaat en hoe je weet dat het werkt. Dit is de input vanuit product, meestal een paar alinea's, geen lang document. Agents kunnen de bedoeling niet raden. Ontbreekt die, dan vullen ze het gat met aannames die logisch klinken, en daar gaan de meeste met AI gebouwde features mis.

2. Spec en plan (controlemoment 1)

De bedoeling wordt een specificatie: gedrag, randvoorwaarden, acceptatiecriteria, gebruikte data en wat buiten de scope valt. Een agent kan de spec en een technisch plan opstellen op basis van de bedoeling en de bestaande codebase. Een mens keurt beide goed. Dit is het eerste controlemoment en de goedkoopste plek om een fout te vangen. Een verkeerde aanname die je hier oplost, kost minuten; dezelfde fout in de review kost uren. Hoe je zulke specs schrijft, lees je in onze gids over specification driven development.

3. Bouwen en automatisch controleren

Agents schrijven de code, de tests en de documentatie vanuit het goedgekeurde plan, vaak meerdere taken tegelijk. Voordat een mens het resultaat ziet, draaien automatische checks: tests, typecontroles, linting, security scans en de projectregels die de agents moeten volgen. Die regels staan in de repository zelf, in bestanden die de agents vertellen hoe deze codebase werkt, welke patronen ze gebruiken en wat ze nooit mogen doen. Goede teams behandelen die regelbestanden net zo serieus als de code.

4. Review (controlemoment 2)

Een mens reviewt de pull request tegen de spec. Dit is nu de duurste stap in de cirkel en verdient de meeste aandacht. De reviewer checkt of de wijziging doet wat de spec zegt, of ze iets doet waar de spec niet om vroeg, en of ze in de architectuur past. Kleine, goed afgebakende pull requests maken dat mogelijk. Enorme wijzigingen van een agent maken het onmogelijk, en daarom is een goed afgebakende spec zo belangrijk.

5. Release (controlemoment 3)

Releases volgen dezelfde veiligheidsregels als altijd: gefaseerd uitrollen, feature flags, monitoring en een snelle weg terug. Het verschil is het volume. Als een team per week meer wijzigingen uitrolt, moet het releaseproces geautomatiseerd en saai zijn, en beslist nog steeds een mens wanneer riskante wijzigingen live gaan.

6. Observeren en terugkoppelen

Gedrag in productie, incidenten en feedback van gebruikers vormen de volgende ronde bedoelingen. De stap die de meeste teams overslaan, is de belangrijkste: maakt een agent een fout die in de review wordt gevonden, dan schrijf je die les als regel in het project, zodat de agents hem niet herhalen. Na verloop van tijd worden de regelbestanden het geheugen van je team, en daalt het aantal fouten.

‍

Zoek je een vast format voor de stappen bedoeling en spec? Onze gratis AI product requirements template geeft je de onderdelen waar agents mee kunnen werken, inclusief acceptatiecriteria en regels voor wat buiten de scope valt.

‍

Wat zegt onderzoek over de productiviteit van een AI SDLC?

Het eerlijke antwoord: AI maakt goede engineeringteams sneller en worstelende teams drukker. Het onderzoek uit 2025 en 2026 is daar consistent in, ook als de koppen elkaar lijken tegen te spreken.

Of teams AI gebruiken, is geen vraag meer. Het DORA-rapport 2025 van Google, gebaseerd op zo'n 5.000 techprofessionals, vond dat 90% van de respondenten AI gebruikt op het werk en dat ruim 80% zich productiever voelt. De belangrijkste conclusie: AI werkt als versterker. Het vergroot de sterke punten van goed presterende organisaties en de zwakke plekken van worstelende organisaties.

De gemeten snelheid is minder duidelijk. In een gerandomiseerde studie van juli 2025 vond METR dat ervaren open-source-ontwikkelaars 19% trager waren met AI-tools in hun eigen repositories, terwijl ze dachten dat ze 20% sneller waren. De vervolgstudie van februari 2026 met nieuwere tools wees juist op een versnelling, al was die statistisch niet significant, en METR noemt de uitkomst van 2025 inmiddels zelf achterhaald. De les is niet dat AI je trager maakt. De les is dat gevoelde snelheid en echte snelheid sterk kunnen verschillen, dus je moet meten.

Waar de tijd naartoe gaat, laat de analyse van Faros AI onder ruim 10.000 ontwikkelaars het duidelijkst zien. Teams met veel AI-gebruik rondden 21% meer taken af en mergeden 98% meer pull requests, maar de reviewtijd per pull request steeg met 91% en pull requests werden 154% groter. Meer output, en een reviewwachtrij die het nieuwe knelpunt wordt.

Vertrouwen volgt hetzelfde patroon. In de Stack Overflow Developer Survey 2025 gebruikt of plant 84% van de ontwikkelaars AI-tools, maar meer ontwikkelaars wantrouwen de juistheid van AI-output (46%) dan dat ze die vertrouwen (33%), en 66% noemt "oplossingen die bijna goed zijn, maar net niet" de grootste ergernis. Precies daarom steekt een AI SDLC de menselijke inspanning in specs en review.

‍

Hoe veranderen de rollen in een AI SDLC?

Niemands baan verdwijnt, maar bijna ieders week ziet er anders uit. Het patroon is per rol hetzelfde: minder zelf maken, meer beslissen en controleren.

• Productmanager: schrijft scherpere bedoelingen en acceptatiecriteria, omdat agents precies doen wat er staat. Vage eisen kosten nu meer, niet minder.

• Ontwikkelaar: typt minder en besteedt meer tijd aan specs schrijven, agents sturen, wijzigingen reviewen en de lastige delen oplossen die agents verkeerd doen. De belangrijkste vaardigheid is kritisch code lezen.

• Tech lead of architect: beheert de regelbestanden, de grenzen van de architectuur en de reviewstandaard die agents en mensen allebei volgen. Deze rol wordt belangrijker, niet minder belangrijk.

• QA-engineer: gaat van handmatig tests uitvoeren naar tests ontwerpen, zodat agents tests genereren op basis van goed gekozen scenario's en randgevallen.

• Designer: levert designsystemen en componenten aan die agents consequent kunnen hergebruiken, in plaats van losse schermen.

• DevOps- of platformengineer: bouwt de pipelines, rechten en afgeschermde omgevingen waarin agents veilig kunnen werken, en houdt het releaseproces geautomatiseerd.

Voor werving betekent dit dat senioriteit zwaarder weegt. Eén senior engineer met goed oordeelsvermogen kan nu veel agentwerk aansturen; een team junioren zonder sterke review levert sneller meer fouten op.

‍

De belangrijkste AI SDLC-frameworks vergeleken

Verschillende leveranciers hebben hun eigen versie van de AI SDLC gepubliceerd. Ze beschrijven dezelfde verschuiving in andere woorden, en het helpt om te weten hoe ze zich tot elkaar verhouden.

Het AI-native SDLC playbook van Anthropic is het meest gedetailleerd. Het beschrijft de cyclus als een keten van vastgelegde bestanden, van een bedoelingsdocument naar een spec, een plan, een pull request en weer terug, met governance ingebouwd in regels en hooks in de repository. Het is sterk gekoppeld aan Claude Code.

AWS beschrijft een AI-Driven Development Life Cycle (AI-DLC) in drie fasen, inception, construction en operations, met korte werkcycli die het bolts noemt in plaats van sprints. Het AI SDLC transformation playbook van Atlassian richt zich op de organisatiekant: meten, investeren in het platform en verandermanagement.

Spec-driven development is de rode draad door alle drie: de spec wordt het hoofddocument en de code wordt eruit gegenereerd. Thoughtworks plaatste spec-driven development in de ring "Assess" van de Technology Radar, een verstandig signaal dat het idee veelbelovend is maar de tooling nog jong. Onze kijk: je hoeft geen framework van een leverancier volledig over te nemen. De cirkel met drie controlemomenten hierboven vat samen waar ze het over eens zijn, en werkt met elke grote coding agent.

‍

Governance, beveiliging en Europese regels

Een AI SDLC heeft expliciete vangrails nodig, want agents werken snel en vragen geen toestemming tenzij je ze daartoe dwingt. Vier gebieden zijn het belangrijkst.

Ten eerste goedkeuringsmomenten. Agents mogen nooit naar de hoofdbranch mergen, infrastructuur wijzigen of productiedata aanraken zonder akkoord van een mens. Stel dat in de tools in, vertrouw niet op gewoontes.

Ten tweede geheimen en data. Houd wachtwoorden en sleutels buiten alles wat een agent kan lezen, laat agents draaien in afgeschermde omgevingen met beperkte rechten, en weet waar je code en prompts verwerkt worden. Voor Europese teams betekent dat ook: de verwerkersvoorwaarden van elke AI-leverancier toetsen aan de AVG.

Ten derde prompt injection. Agents die issues, webpagina's of bestanden van derden lezen, kunnen gemanipuleerd worden door tekst die daarin verstopt zit. Behandel externe input als onbetrouwbaar en beperk wat een agent mag doen nadat hij die gelezen heeft.

Ten vierde de AI Act. Coding assistants zijn geen hoog-risicosystemen onder de AI Act, maar artikel 4 verplicht bedrijven sinds februari 2025 om te zorgen dat hun medewerkers voldoende AI-geletterd zijn voor de systemen die ze gebruiken. In de praktijk betekent dat een korte, vastgelegde training over hoe je team agents gebruikt, wat hun grenzen zijn en wat je reviewregels zijn. Het bredere plaatje lees je in onze gids over wat de AI Act betekent voor het mkb.

‍

Wat kost een AI SDLC en hoe meet je het?

De directe kosten van een AI SDLC zijn klein vergeleken met salarissen. Abonnementen voor de grote coding agents kosten in 2026 grofweg van €20 tot een paar honderd euro per ontwikkelaar per maand, afhankelijk van hoe intensief je team autonome agents inzet, en facturering per token kan op drukke dagen meer kosten. Check de actuele prijzen van de leverancier, want die veranderen vaak.

De echte kosten zitten in reviewtijd, herstelwerk en de inrichting: regelbestanden schrijven, testdekking opbouwen en de pipeline aanscherpen. Daarom hangt het rendement veel meer af van je proces dan van de tool die je kiest.

Meet bij één team voor en na, met de metrics die je waarschijnlijk al kent plus een paar specifiek voor AI:

• Doorlooptijd van goedgekeurde spec tot productie.

• Reviewtijd per pull request, en de grootte van pull requests.

• Percentage mislukte wijzigingen en tijd tot herstel.

• Herstelwerk: hoe vaak gemergd werk binnen twee weken gerepareerd moet worden.

• Toolkosten per gemergde pull request.

Een eenvoudig rekenvoorbeeld laat zien waarom dit telt. Stel dat een feature een engineer vroeger 8 dagen kostte en nu 3 dagen bouwen met agents plus 2 extra dagen spec en review. Tegen volledige kosten van €600 per engineerdag in Nederland is dat €4.800 vooraf en €3.000 erna, plus een paar euro aan toolgebruik. De besparing is echt, maar alleen als die 2 dagen review ook echt gebeuren. Sla je ze over, dan eet het herstelwerk de winst binnen een kwartaal op.

‍

Hoe wij de AI SDLC draaien bij Codelevate

Wij bouwen klantsoftware elke dag op deze manier, dus dit gaat over praktijk, niet over theorie. Elk project draait op de cirkel met drie controlemomenten. Een mens keurt de spec en het plan goed, een mens reviewt elke pull request tegen de spec, en een mens beslist over elke release.

Onze websitebouw is een goed voorbeeld van hoe de agentrollen werken. Die loopt via vier gespecialiseerde agents na elkaar: één maakt van het ontwerp of de briefing een precieze bouwspec, één toetst elke waarde aan het designsysteem van de klant voordat er iets gebouwd wordt, één bouwt, en één controleert het resultaat en geeft een akkoord of een genummerde lijst met fouten terug. Twee van die stappen zijn harde controlemomenten. Er gebeurt niets tot ze slagen.

Wat op de lange termijn het grootste verschil maakt, is het geheugen. Vindt de review een fout, dan schrijven we die als regel op in de kennisbank van het project, en elke agent leest die regels voor zijn volgende taak. Dezelfde fout hoort maar één keer te gebeuren. We koppelen agents ook direct aan de tools van een project, zoals het CMS, via MCP-connectoren, zodat ze op het echte systeem werken met echte rechten in plaats van op gekopieerde bestanden.

Wat we geleerd hebben, gaat vooral over discipline. De tools veranderen om de paar maanden. De gewoontes die een AI SDLC laten werken, blijven gelijk: schrijf de spec op, houd wijzigingen klein, review alles en maak van elke fout een regel.

‍

Zo stap je in 90 dagen over op een AI SDLC

Je hebt geen transformatieprogramma nodig. Een gerichte pilot van 90 dagen met één team leert je meer dan welk playbook ook.

Dag 1 tot 30: leg de basis. Kies één team en één soort werk, bijvoorbeeld interne tools of goed geteste backendfeatures. Schrijf de eerste versie van je repositoryregels, spreek de drie controlemomenten af en leg je nulmeting vast. Geef een korte sessie over AI-geletterdheid en leg die vast.

Dag 31 tot 60: draai de cirkel. Elke taak binnen de scope begint als geschreven bedoeling en goedgekeurde spec. Houd pull requests klein. Bespreek wekelijks kort wat de agents fout deden en voeg elke les toe aan de regels.

Dag 61 tot 90: meet en beslis. Vergelijk doorlooptijd, reviewtijd, herstelwerk en mislukte wijzigingen met de nulmeting. Zijn de cijfers beter zonder dat de kwaliteit daalt, breid de cirkel dan uit naar een tweede team of naar riskanter werk. Zo niet, dan ligt het bijna altijd aan de kwaliteit van de specs of aan te weinig reviewcapaciteit, niet aan de tool.

‍

Wanneer een AI SDLC niet de juiste keuze is

Een AI SDLC past niet bij elk team of elke codebase. Het is goed om eerlijk te zijn over waar het lastig wordt.

• Codebases met weinig tests: het werk van agents is dan niet automatisch te controleren, dus elke wijziging vraagt zware handmatige review en de winst verdwijnt.

• Teams zonder senior reviewers: meer output met zwakke review levert alleen meer fouten en technische schuld op.

• Veiligheidskritische of zwaar gereguleerde wijzigingen, zoals medische apparatuur of de kern van een betaalsysteem, waar elke regel formeel geverifieerd en traceerbaar moet zijn. Daar zijn agentworkflows nog niet op gebouwd.

• Werk dat vooral uit zoeken bestaat: weet je nog niet wat je moet bouwen, begin dan bij de productcyclus en niet bij agents die code schrijven.

‍

Tot slot

Een AI SDLC houdt de vorm van de traditionele cyclus en verandert de economie erbinnen. Bouwen wordt goedkoop, dus de waarde verschuift naar een heldere bedoeling, precieze specs en zorgvuldige review. Het onderzoek is consistent als je verder leest dan de koppen: AI versterkt het proces dat je al hebt. Teams met goede specs, stevige tests en strenge controlemomenten leveren meer goede software. Teams zonder die basis leveren sneller meer problemen. Begin met één team, drie menselijke controlemomenten en eerlijke metingen, en laat de cijfers bepalen hoe ver je gaat.

‍

Codelevate: zie een AI SDLC werken op je eigen backlog, plan een gesprek met Nicko

‍

Gratis download: onze AI product requirements template geeft je team het specformat waar agents het best mee werken. Wil je een AI SDLC liever eerst zien werken op je eigen backlog? Dan draaien we één sprint met je team volgens precies deze cirkel, en is het resultaat niet van jouw niveau, dan betaal je er niet voor. Plan een gesprek met Nicko om het in te plannen, of lees hoe een vast productteam van Codelevate werkt.

‍