Terug naar home

AI Automation

de nieuwe bouwers

Over waarom software bouwen van samenstelling is veranderd, waarom domeinkennis het diploma verslaat, en wat de gevestigde orde daarvan terugziet in de eigen cijfers

Twee jaar geleden viel bij mij het kwartje. Ik werkte toen bij Aiden, als consultant in customer experience en CRM, en ik zag van dichtbij wat enterprise-software kan. Maar net zo goed waar de muur staat. SAP is ijzersterk, hoor. Alleen: het is duur, het is niks voor een klein bedrijf, en je hebt er implementatiepartners bij nodig. En daar gaat zóveel geld in om. Voordat een project überhaupt bestaat, heb je al twintig uur zitten praten, documenten opstellen, contracten rondsturen. Zo ben je zomaar veertig uur verder. Reken maar uit: vijfduizend euro. Alleen om te beginnen.

En rond diezelfde tijd ontdekte ik dat AI kon coderen. Toen ben ik er meteen ingesprongen. Want die functionele domeinkennis, die had ik al. Ik wist precies welke sales- en serviceprocessen zo’n systeem moet ondersteunen. Wat ik miste, dat leverde de AI. Dus ben ik mijn eigen CRM gaan bouwen. Voor het MKB, voor de bedrijven waar dat hele enterprise-verhaal nooit voor bedoeld was. Dat systeem heet inmiddels fikst.

En eerlijk? De eerste keer ging het niet. Ik begon destijds met Gemini, en na een jaar liep dat een beetje dood. Ik liep tegen zóveel fouten aan, en ik was gewoon te snel van start gegaan. Eerste versie, eerste poging, tegen de muur. Dus ik ben er een half jaar mee gestopt. Deed ondertussen andere dingen, kleinere agent-projecten, kleine klanten.

Tot ik gaandeweg merkte: hé, die modellen worden nu ineens wél heel sterk. Een jaar geleden ben ik daarom opnieuw begonnen. Ik pakte de shell van wat ik al had, en bouwde daarop verder. En toen ging het rap. Een jaar lang bouwen en testen, niet fulltime, die tijd had ik niet, maar wel serieus veel uren. En wat er nu staat is een volwaardig product. Met een eerste pilotklant die het live in productie draait. Het levende bewijs dat één persoon, één team, hier verder mee komt dan je zou denken. Ik zeg niet dat het op SAP-niveau zit. Dat hoeft ook niet. Dat was nooit het doel.

Precies daar zit de verschuiving die dit hele stuk draagt. Software bouwen is van samenstelling veranderd. En de markt waar ik vandaan kom, die voelt het.

de gevestigde orde wordt afgeprijsd

Op 18 juni 2026 sloeg diezelfde onderstroom keihard de andere kant op. Accenture verloor die dag zo’n vijfde van zijn beurswaarde. Het grootste dagverlies ooit voor dat aandeel. En let op: de omzet was gewoon gegroeid, zes procent in dollars. Maar de nieuwe boekingen krompen met twee procent, de groeiverwachting ging omlaag, en beleggers lazen er volgens Bloomberg iets veel groters in. De vrees dat AI de hele consultingmarkt opnieuw gaat prijzen. Capgemini ging dezelfde dag mee onderuit, ruim acht procent, naar het laagste punt in een jaar. En dat kwam niet uit de lucht vallen. Een jaar eerder had Accenture al ruim elfduizend banen geschrapt. Topvrouw Julie Sweet legde op de beleggerscall uit dat omscholen naar de gevraagde AI-vaardigheden voor een deel van die vertrekkers geen begaanbare weg meer was.

En aan de andere kant van diezelfde markt gebeurde het omgekeerde. Fortune beschreef hoe Maor Shlomo in vier maanden, zo goed als in zijn eentje, het platform Base44 bouwde. Bijna anderhalf miljoen dollar aan abonnementen in de eerste maand, en zes maanden na de oprichting kocht Wix het over voor tachtig miljoen. Twee uitersten. En toch één en dezelfde beweging. Wat de reuzen zien wegvallen en wat die eenlingen zien ontstaan, komt uit precies dezelfde verschuiving.

het vak is niet sneller geworden, het is anders geworden

De Anthropic Economic Index, telemetrie van zo’n vierhonderdduizend werksessies, laat het mooi zien. Het deel dat opgaat aan kapotte code repareren zakte in een half jaar van 33 naar 19 procent; draaiend houden en bedienen ging juist omhoog. Voorhoede-cijfers, dat wel. Maar de richting is duidelijk: geen versnelling, wel een verschuiving in waar het werk zit.

En wie ooit in een team heeft gewerkt, voelt meteen wat dat betekent. Een klassiek softwareproject besteedt het grootste deel van zijn kalender niet aan nadenken. Het gaat op aan wrijving. Overdracht, afstemming, wachten, herstellen. Neemt een agent het tikwerk over, dan verdwijnt die wrijving niet. Die verhuist. En de schaarse vaardigheid is dan niet meer dat je code kunt schrijven. Het is weten wat er precies moet komen, en kunnen zien of wat er staat wel deugt.

domeinkennis verslaat het diploma

Het opvallendste cijfer uit datzelfde onderzoek gaat niet over snelheid. Anthropic keek hoe vaak mensen uit heel verschillende beroepen hun bouwtaak afkrijgen. En daar komt iets geks uit. Elke grote beroepsgroep, van managers tot juristen, slaagt op codeertaken zo’n beetje even vaak als de professionele software-engineers. De hele top tien zit binnen zo’n zeven procentpunt van elkaar. En hoe meer domeinkennis iemand meebrengt, hoe meer zo’n agent per opdracht voor elkaar krijgt.

Dat is de echte disruptie. En eentje die een stuk stiller is dan al die demo’s op LinkedIn. Het gaat er niet om dat iedereen ineens kan programmeren. Wat verschoven is, is de voorspeller van succes. Decennialang was de eerste vraag: wie kan dit bouwen? En nu is de vraag: wie snapt dit proces goed genoeg om een systeem aan te sturen dat het voor hem bouwt?

En ik merk het elke dag. Kijk, wij doen het harde werk eigenlijk niet meer. Het is nu vooral kritisch denken, met een creatieve mindset. Architecturale besluiten nemen, de AI sturing geven, en reviewen. En dat kost véél minder tijd dan het zelf bouwen, want in dat bouwen zat vroeger al je tijd. Een integratie die ik nu binnen een dag in elkaar zet, daar deden ze bij een bureau een week over. Twee weken, met drie consultants. Ik heb van dichtbij gezien hoe dertig man op één project zitten, waar een berg geld doorheen wordt gebrast. En begrijp me niet verkeerd, daar wordt ook veel opgeleverd hoor, dat zijn complexe trajecten. Maar op zo’n maatwerkstuk denk ik nu gewoon: dat doe ik in een fractie.

En mijn waarde zit dus steeds minder in de regels code die ik zelf tik. Steeds meer zit ze in die veertien CRM-trajecten die ik van begin tot eind heb gedraaid. Die hebben me geleerd hoe een offerte echt door een bedrijf loopt. Waar een serviceproces vastloopt. Welke uitzondering je op dag negentig pijn gaat doen. Het klantportaal dat ik voor Elite Klimaat bouwde staat live na een maand bouwen, voor minder dan vijfduizend euro. Een normale partij had daar zo dertigduizend voor gevraagd. Zes keer de prijs, dat durf ik wel te stellen. En ja, aan zo’n portaal zitten gewoon enterprise-veiligheidseisen. Alleen die waarborg je nu ook prima, mits je de juiste bouwer hebt en de juiste producten eromheen zet. Want die agentic AI, dat is een tool. Niet het product. Zet er de goede schil omheen, en je voldoet net zo goed aan die eisen.

En er komt nog iets bij. De feedbackloop is korter geworden dan wat de oude wereld ooit kende. Vroeger had je na een sessie weken nodig voor een eerste versie. Nu heb ik ‘s ochtends een meeting, zet ik in de pauze een proof of concept op, en bespreken we ‘m ‘s middags. Visueel, een echte app op het scherm. Kijk maar: dit qua ontwerp, wat vind je hiervan, wat vinden we van dat? Die snelheid verandert niet alleen het tempo. Ze verandert het hele gesprek.

de oude rekensom breekt

Het oude leveringsmodel is een rekensom: uurtarief keer teamgrootte keer maanden. En elke factor daarin staat nu onder druk. Levert één bouwer met agents af wat eerst een heel team deed, en gaat de doorlooptijd van maanden naar weken? Dan blijft er van die som bijzonder weinig over. Een hard, geverifieerd cijfer voor dat verschil bestaat trouwens nog niet. Wie er een noemt, verzint hem. Maar de richting staat wel in de boeken: de nieuwe boekingen bij Accenture krompen, en de beurs prijst de twijfel nu al in.

En de tegenwerping verdient haar plek, echt. Accentures topvrouw bestrijdt die AI-verklaring namelijk zelf. Ze wijst op zwakke vraag, op bezuinigingen bij de Amerikaanse overheid, op geopolitieke onrust. En ze legt er een eigen cijfer naast: de boekingen van opdrachten boven de honderd miljoen dollar groeiden juist, met dertien procent. Dat kan allemaal tegelijk waar zijn. Een beurskoers meet vrees, geen bewezen oorzaak. En toch. Een sector die zichzelf verbouwt rond AI-vaardigheden, die duizenden mensen laat gaan, deels omdat omscholen niet meer lukt, en die door de markt wordt afgeprijsd op AI-angst: die gedraagt zich niet bepaald als een sector die denkt dat er niks aan de hand is.

de keerzijde die de pioniers liever overslaan

En hier hoort een waarschuwing bij. Wie die weglaat, verkoopt je iets. En ik begin gewoon bij mezelf, want ik ben er zelf stinkend in gevallen.

Ik was de complexe routelogica aan het opzetten, met de dynamic-routing-API van Google Maps. En tijdens het testen had ik daar geen grens op gezet. Ik liet mijn agent autonoom testen, met een verbeterloop eronder, en die bleef maar doorrekenen. Resultaat: een rekening van duizend euro aan testverkeer. Dat model was veel duurder dan ik dacht. En de AI had dat niet expres gedaan, hoor. Die wou gewoon de beste en de snelste oplossing, en aan kostenefficiëntie had-ie geen seconde gedacht. Dat is het typische. AI gaat heel graag voor de makkelijke, snelle oplossing, en soms is dat gewoon de foute. Je moet dat kunnen zien aankomen. En dat inzicht krijg je alleen door heel veel met die dingen te werken, plus de nodige IT-kennis, plus functionele kennis. Zet je geen grens op wat een agent uitgeeft, dan kan het je zomaar duizend euro kosten om daarachter te komen.

En het is niet alleen ik. Securitybedrijf Veracode gooide ruim honderd taalmodellen tegen tachtig bouwopdrachten aan. In 45 procent van de AI-gegenereerde code zat een bekende kwetsbaarheid, en dat percentage ligt al twee jaar zo goed als vlak. Zet je een model voor de keuze tussen een veilige en een onveilige route, dan pakt het ongeveer de helft van de tijd de verkeerde. En dan Daniel Stenberg, de man achter curl, software die op miljarden apparaten draait. Die stopte begin 2026 met zijn beloningsprogramma voor bugmeldingen. Een vijfde van de meldingen was AI-gegenereerd, elke melding kostte reviewers soms uren, en geen enkele AI-melding leverde ooit een geldige vondst op. Geen één.

En dít is waarom snelheid op zichzelf niks bewijst. AI maakt de drempel om te bouwen lager. Alleen maakt het de drempel om iets te bouwen dat ook echt deugt geen millimeter lager. Zonder vakmanschap maakt die nieuwe manier gewoon dezelfde fouten als de oude. Alleen sneller, en in veel grotere aantallen. Ik behandel dan ook alles wat een agent bij mij oplevert als een verdachte eerste versie. Onderzoekers van MIT die uitzochten waarom bedrijfspilots stranden komen op hetzelfde uit: het is zelden het model dat faalt, het is de organisatie die niet leert hoe je ermee bouwt. Over die kloof tussen demo en dienst schreef ik eerder de productiekloof. En hoe hard die faalcijfers zelf staan, weeg ik apart in de 95-procent-mythe.

en als je er eentje inhuurt

Want stel, je gaat met zo’n bouwer in zee. Dan is er één risico dat boven alles uitsteekt: continuïteit. Valt die ene persoon uit, dan staat jouw project stil. Softwareteams noemen dat de bus-factor, en bij een solo-bouwer is het antwoord per definitie één. Dat dek je niet af met vertrouwen, dat dek je af met een handvol afspraken. Een goede bouwer komt er trouwens zelf mee aanzetten.

Eigenaarschap ligt vanaf dag één bij jou: code, prompts, configuratie, alles in jóuw repository, jouw accounts, jouw domein. Jij moet de bouwer toegang kunnen ontnemen, nooit andersom. Documentatie is een leveringseis, geen extraatje: bij elke oplevering een beslislog waaróm iets zo gebouwd is, plus een korte walkthrough. Geen documentatie, geen acceptatie, geen betaling. En dan de eis die de meeste bouwers overslaan, en die ik zelf de belangrijkste vind: laat een willekeurige andere developer het systeem binnen één werkdag draaiend krijgen met alleen die documentatie, en test dat minstens één keer echt. Een overdracht die nooit getest is, bestaat niet. Bouw op gangbare techniek die duizenden mensen kennen, niet op een exotische stack die alleen de bouwer nog snapt. Zet beheer en exit op papier, mét de naam van een vervanger. En betaal per opgeleverde, werkende stap, dan is je maximale schade bij uitval één stap. Wuift een bouwer die risico’s weg? Dan is dat op zichzelf al een reden om niet met ‘m in zee te gaan. Je wilt juist horen dat-ie ze benoemt, en netjes vastlegt.

wie de nieuwe bouwers zijn

Tel het bij elkaar op, en er tekent zich een profiel af. De nieuwe bouwers, dat zijn geen grote teams met een AI-licentie erbij. Het zijn ook geen prompters zonder vak. Het zijn kleine, senior bouwers die twee dingen tegelijk in huis hebben: domeinkennis die diep genoeg gaat om een systeem te sturen, én de discipline om machinewerk te wantrouwen. Voor mezelf ligt de volgorde vast. Eerst de specificatie, dan pas bouwen. Agents die elkaars werk nakijken. En geen enkele wijziging gaat live voordat-ie getest is. En omdat die methodes elke maand weer verschuiven, gaat een fors deel van mijn tijd, bij mij zo’n beetje de helft, naar bijblijven. Uitproberen wat zich bewijst, en de rest laten liggen.

Ik zie mezelf inmiddels echt als een disruptor. Ook van de markt waar ik zelf uit kom. Niet omdat die markt niks waard is, integendeel, ik heb er alles geleerd wat ik nu gebruik. Maar omdat de samenstelling van het werk is veranderd, en de markt die oude som herprijst terwijl we toekijken. En daarmee verschuift ook de vraag die je moet stellen zodra je iets laat bouwen. Niet meer: gebruikt mijn leverancier AI? Kom op, dat doet inmiddels iedereen. De vraag die telt is of er iemand aan het stuur zit die jouw proces echt snapt. Iemand die elke wijziging controleert voordat die live gaat. En die er nog is als het systeem zich op dag negentig ineens anders gedraagt dan in de demo. Stel je die vraag, dan herken je de nieuwe bouwers vanzelf.

nlen