Naar de inhoud
SwankyForge
SwankyForge
Alle inzichten
Artikel9 min lezen

AI heeft code schrijven goedkoper gemaakt. Softwareprojecten werden daardoor niet vanzelf goedkoper.

Gecontroleerde metingen laten bescheiden of zelfs negatieve versnelling door AI-codeertools zien, en coderen is een minderheid van de projecttijd. Een eerlijke AI-korting is dus klein en per fase aan te wijzen.

In juli 2025 publiceerde de onderzoeksorganisatie METR (een non-profit) een gerandomiseerde studie naar AI-codeertools bij echt werk. Zestien ervaren open-source developers voerden 246 taken uit in hun eigen repositories, en elke taak werd willekeurig ingedeeld als "AI toegestaan" of "AI niet toegestaan". Met AI duurden taken 19% langer. Vooraf verwachtten dezelfde developers dat AI hen 24% sneller zou maken. Achteraf dachten ze nog steeds dat AI hen ongeveer 20% sneller had gemaakt.

Dat verschil tussen gevoelde en gemeten snelheid is het bruikbare deel voor wie software inkoopt. Leveranciers adverteren nu met AI-versnelde oplevering en rekenen die in de prijs mee. Een deel van de besparing is echt. Het grootste deel van de claim gaat over typen, toegepast op een budget dat grotendeels niet uit typen bestaat.

Deze notitie behandelt wat de data uit 2025 zeggen, waar de uren in een machine-learningproject naartoe gaan, en wat je een leverancier vraagt die je een AI-korting aanbiedt.

Wat de data uit 2025 zeggen

Vier bronnen, vier methoden. Geen van alle ondersteunt het idee dat een project half zo duur wordt omdat de code met een assistent is geschreven.

Bron Methode Bevinding
METR, juli 2025 Gerandomiseerde studie: 16 developers, 246 taken, repositories met gemiddeld 22k+ sterren en 1M+ regels code 19% trager met AI; developers dachten dat ze ongeveer 20% sneller waren
Stack Overflow Developer Survey, juli 2025 Enquête, 26k–34k antwoorden per vraag 84% gebruikt AI-tools of is dat van plan; 46% wantrouwt de nauwkeurigheid, 33% vertrouwt die; 66% noemt "bijna goed, maar net niet" de grootste frustratie
Google DORA-rapport, september 2025 Enquête onder bijna 5.000 technologieprofessionals 90% gebruikt AI op het werk; AI-adoptie hangt samen met hogere leveringsdoorvoer en tegelijk met lagere leveringsstabiliteit
Bain Technology Report, september 2025 Brancheonderzoek Teams met assistenten zien 10–15% productiviteitswinst; het schrijven en testen van code is 25–35% van de tijd van idee tot lancering

Het METR-resultaat heeft beperkingen die de auteurs zelf duidelijk noemen: een kleine steekproef, ervaren developers op grote codebases die ze al kenden, en tools van begin 2025 (Cursor Pro met Claude 3.5 en 3.7 Sonnet). Het laat niet zien dat AI iedereen trager maakt. Het laat twee beperktere dingen zien. Zelfgerapporteerde versnelling is geen bewijs. En bij volwassen, complexe code kan de tijd die opgaat aan prompten, wachten, reviewen en corrigeren de tijdwinst bij het schrijven tenietdoen.

De enquêtes wijzen vanuit een andere hoek dezelfde kant op. Gebruik is routine: 51% van de professionele developers in de Stack Overflow-enquête gebruikt dagelijks AI-tools, en de respondenten van DORA besteden er een mediaan van twee uur per dag aan. Vertrouwen is dat niet: 45% van de Stack Overflow-respondenten zegt dat het debuggen van AI-gegenereerde code meer tijd kost, en 30% van de DORA-respondenten meldt weinig of geen vertrouwen in AI-gegenereerde code. De samenvatting van DORA is dat AI versterkt wat een team al is. Sterke teams worden sneller. Teams met zwakke tests en trage feedback leveren meer wijzigingen op en breken er ook meer van.

Waarom goedkoper typen geen goedkoper project betekent

De twee getallen van Bain zijn genoeg om het plafond te zien. Als het schrijven en testen van code 30% van de tijd van idee tot lancering is, en een assistent dat deel 30% sneller maakt, wordt het hele project 9% sneller: 0,30 × 0,30 = 0,09. Als code gratis en direct beschikbaar zou zijn, bleef de andere 65–75% van het werk gewoon bestaan. Engineers kennen dit als de wet van Amdahl: het versnellen van één stap in een pipeline wordt begrensd door het aandeel van de tijd dat die stap inneemt.

De rest van een project bestaat uit specificatie, datawerk, integratie, review, testen, evaluatie, deployment en beheer. Elk daarvan heeft een eigen reden om niet in hetzelfde tempo te krimpen.

  • Specificatie is een gesprek met de mensen die eigenaar zijn van het probleem. Een assistent kan het document opstellen. Hij kan niet beslissen dat de metric marge is in plaats van omzet.
  • Datawerk draait vooral om uitzoeken wat een kolom betekent, wie eigenaar is van de tabel en waarom sommige rijen dubbel voorkomen. Het schrijven van de SQL was nooit het trage deel.
  • Integratie-tijd gaat op aan de API van een ander team, credentials, rate limits en releasevensters.
  • Review wordt zwaarder. Meer gegenereerde code per dag betekent meer code om per dag te lezen, en code die bijna goed is, is het duurst om te reviewen omdat die er af uitziet.
  • Evaluatie en beheer volgen de kalender. Je wacht op een week verkeer, een maandafsluiting of een holdoutgroep die genoeg data verzamelt.

De stabiliteitsbevinding van DORA is de gemeten versie van het reviewpunt. Teams leveren meer wijzigingen op, en zonder sterke geautomatiseerde tests en snelle feedbackloops mislukken er meer van.

Waar de uren in een ML-project naartoe gaan

De tabel hieronder is een illustratie. Het is onze grove verdeling voor een middelgroot machine-learningproject, zoals een aanbevelings- of forecastingsysteem dat in een bestaand product wordt ingebouwd, samen met onze aannames over hoeveel AI-ondersteuning per fase bespaart. De percentages zijn planningsinschattingen, geen metingen. Vervang ze door je eigen cijfers en reken het opnieuw uit.

Fase Aandeel uren Uren van 600 Aangenomen AI-besparing Bespaarde uren
Discovery: metric, baseline, specificatie 10% 60 0% 0
Datatoegang, opschoning, feature-pipelines 25% 150 15% 22,5
Modellering en experimenten 15% 90 20% 18
Integratie met je systemen 15% 90 20% 18
Testen, evaluatie, code review 15% 90 0% 0
Deployment, monitoring, rollback 10% 60 10% 6
Demo's, acceptatie, overdracht 10% 60 0% 0
Totaal 100% 600 64,5, ongeveer 11%

De redenering per rij:

  • Discovery krijgt niets, omdat de uitkomst bestaat uit beslissingen, en beslissingen komen van de business.
  • Datawerk krijgt een bescheiden besparing. Assistenten schrijven snel queries, parsers en validatiechecks, maar de meeste uren gaan op aan wachten op toegang en het begrijpen van de data.
  • Modellering en integratie krijgen de grootste besparing, omdat daar de meeste patrooncode in zit: trainingsloops, API-clients, serialisatie, configuratie.
  • Testen en review komen netto op nul. Assistenten schrijven snel testscaffolding, en de extra gegenereerde code kost extra reviewtijd. Teams met sterke testsuites kunnen hier winst zien; teams zonder die suites verlies.
  • Deployment bespaart een beetje op configuratiesjablonen. Het wachten tot een canary-release genoeg verkeer heeft verzameld, wordt niet korter.

Tegen ons gepubliceerde tarief voor een ML-engineer van €50 per uur is 600 uur €30.000 en 64,5 uur ongeveer €3.200. Dat is de orde van grootte van een eerlijke AI-korting op een project van deze vorm: echt, de moeite waard, en lang niet de helft. Het valt toevallig ook binnen Bains bandbreedte van 10–15%, wat een plausibiliteitscheck is en geen bewijs.

Het andere getal van Bain is interessanter. Bedrijven die het hele proces rond AI hebben herontworpen, in plaats van alleen assistenten uit te delen, rapporteerden 25–30% winst. Die besparing komt van het veranderen van wat er tussen de regels code gebeurt: hoe specificaties worden geschreven, hoe review werkt, hoe releases worden getest. Het is een procesverandering, en die kost moeite voordat ze iets oplevert. Bain merkt ook op dat drie op de vier bedrijven zeggen dat mensen hun manier van werken laten veranderen het moeilijkste deel is.

Hoe het werk van de developer veranderde

Het werk verschoof van schrijven naar specificeren en controleren. Een developer met een assistent besteedt minder tijd aan de eerste versie en meer tijd aan drie dingen.

  1. Precieze instructies. De assistent doet wat de specificatie zegt, dus een vage specificatie levert nu sneller plausibele maar foute code op.
  2. Output lezen en corrigeren. Hier zit de frustratie van "bijna goed". Foute code die luid faalt, is goedkoop. Code die de voor de hand liggende test haalt en faalt op de edge case, is duur.
  3. De checks die snelheid veilig maken. Tests, evaluatiesets, typechecks, gefaseerde uitrol.

Bij machine-learningwerk weegt het derde punt het zwaarst. Een modelwijziging die in een notebook goed lijkt, kan in productie een bedrijfsmetric verlagen. Een assistent kan de evaluatieharness schrijven. Hij kan niet beslissen wat er in de evaluatieset hoort, of wat een regressie de business kost.

Waar de besparingen zichtbaar worden

Onze inschatting, die een mening is en geen meting: assistenten besparen echte tijd op

  • prototypes en wegwerpanalyses, waar bijna goed genoeg is om iets te leren;
  • code met een duidelijk patroon: API-clients, dataklassen, configuratie, schemamigraties;
  • onbekende libraries, waar de assistent een uur documentatie lezen vervangt;
  • eerste versies van tests en documentatie, die een mens daarna corrigeert.

Ze besparen weinig op beslissingen, wachten, afstemming en review. Een geloofwaardige AI-korting moet met die verdeling overeenkomen.

Wat je een leverancier vraagt die een AI-korting belooft

  • Waar heeft AI precies uren bespaard? Vraag om de schatting per fase, met en zonder ondersteuning. Een korting die niet aan een fase toe te wijzen is, is een verkoopkorting. Dat mag, maar noem het dan ook zo.
  • Wie reviewt AI-geschreven code, en hoe? Vraag of een mens elke wijziging reviewt, wat diegene controleert, en of de reviewtijd in de schatting zit.
  • Hoe wordt kwaliteit gemeten? Tests op de kritieke paden, een evaluatieset voor modelgedrag, een change failure rate. Als het antwoord is dat de code werkt, vraag dan hoe ze dat weten.
  • Wat gebeurt er als gegenereerde code in productie fout is? Monitoring, rollback en een verantwoordelijke met dienst horen in het plan, niet in een later wijzigingsverzoek.
  • Waar staat de repository? Als de code tot de laatste factuur in het account van de leverancier staat, kun je niets van het bovenstaande controleren zolang het er nog toe doet.

Hoe wij het aanpakken

Onze tarieven zijn per rol en per uur gepubliceerd, dus elke schatting die we geven is te controleren als uren maal tarief, fase voor fase. Je ziet elke week een werkende demo, de repository staat vanaf de eerste dag in jouw organisatie, en elke mijlpaal wordt pas gefactureerd nadat je die hebt geaccepteerd. Typische projectbandbreedtes staan naast de tarieven, en een teardown prijst discovery, proof of concept en productie apart. Als AI-ondersteuning een fase sneller maakt, zie je dat terug als minder uren op de factuur, niet als een belofte in het voorstel.

Bronnen

Een proces dat te veel kost?

Vertel ons erover. Het eerste gesprek is gratis, en als AI niet het antwoord is, zeggen we dat.

Bespreek je vraagstuk