Vervangt Claude Code tools zoals n8n, Make en Zapier? Nee, en dit is waarom

De voorbije weken duiken overal video's en artikels op met titels als "De ondergang van Zapier, n8n en Make" en "Claude Code maakt nu je automations". Pakkend, maar misleidend. In deze blog leggen we uit waar de hype klopt, waar ze de bal misslaat, en hoe je voor je eigen processen beslist of je een agent nodig hebt of gewoon een goede oude regel.

Waar de hype wel een punt heeft

Laten we eerlijk zijn: er zit een kern van waarheid in. AI-agents kunnen vandaag effectief automations in elkaar zetten. Of het nu Claude Code is, Claude Cowork, een Custom GPT of een Copilot-agent, je beschrijft in gewone taal wat je wil, en de agent schrijft de code, koppelt API's en zet een werkende flow neer. Dat ging een jaar geleden nog niet zo vlot. Voor wie kan programmeren is dat een echte versnelling, en met tools zoals Cowork en Custom GPTs komt dat bouwen ook binnen bereik van mensen die geen developer zijn.

Het probleem is niet dat dit kan. Het probleem is de conclusie die eraan gehangen wordt: dat je daarmee de platforms niet meer nodig hebt. Dat is een denkfout, en die wordt duidelijk zodra je de twee dingen uit elkaar haalt die hier door elkaar lopen.

Bouwen versus draaien: het onderscheid dat iedereen mist

Een automation bouwen en een automation draaien zijn twee verschillende taken die verschillende eigenschappen vragen.

Bouwen is eenmalig en creatief. Je zoekt uit hoe de stappen in elkaar passen, welke systemen je koppelt en wat er moet gebeuren. Daar is een AI-agent goed in, want het is precies het soort denkwerk waar een taalmodel sterk in is.

Draaien is repetitief en saai, en moet vooral betrouwbaar zijn. Dezelfde flow, een tiental tot honderdtal keer per dag, elke keer met hetzelfde resultaat. Daar wil je geen creativiteit. Je wil voorspelbaarheid.

Hier zit de fout in de hype. Een agent die zelf de flow draait is probabilistisch: hij kan elke keer een net iets ander pad kiezen. Voor een business-proces dat gewoon altijd hetzelfde moet doen, is die onvoorspelbaarheid geen feature maar een risico.

Wat je gratis krijgt bij n8n, Make en Zapier

Wat een platform je out of the box geeft, is niet de automation zelf. Het is alles eromheen. En net dat eromheen is het meeste werk.

Denk aan de retry-logica wanneer een API even plat ligt. Aan rate limiting zodat je niet geblokkeerd wordt. Aan opnieuw opstarten vanaf de stap die faalde, in plaats van vanaf nul. Aan het bijhouden van wat gisteren al verwerkt is, zodat je niet dubbel draait. Aan honderden kant-en-klare connectoren waar de OAuth-koppeling al geregeld is. Aan een scheduler, een wachtrij en een dashboard waar je in één oogopslag ziet wat loopt en wat faalt.

Een developer die dit met Claude Code bouwt, krijgt code die het ideale scenario afhandelt. Maar al die randgevallen, dat onzichtbare plumbing, moet hij zelf schrijven, testen en onderhouden. Dat is precies het werk dat de platforms al voor je hebben opgelost. "Een developer heeft die tools niet nodig" klopt technisch, maar verzwijgt dat hij dan weken bouwt aan iets wat hij in n8n op een namiddag had. En bouw je met een tool zoals Cowork of een Custom GPT, dan heb je dat plumbing sowieso niet, want die zijn gemaakt om mee te denken en te assisteren, niet om een proces dag en nacht betrouwbaar te draaien.

Het visuele is geen cosmetica, het is een functie

Het grootste verschil tussen een platform en losse code is dat je de flow ziet. Dat is geen cosmetisch detail, het verandert wat je met de automation kan doen.

Een visuele flow is overdraagbaar. Een collega, een klant of een teamlid zonder technische achtergrond kan de flow lezen en zelfs aanpassen. Bij losse code heb je daar telkens een developer voor nodig.

Een visuele flow maakt debuggen zichtbaar. Je ziet de data door elke stap stromen, met de echte waarden erbij. Bij code zit je in logbestanden te graven om hetzelfde te achterhalen.

En een visuele flow is zelf-documenterend. De flow is de documentatie. Code heeft aparte uitleg nodig die in de praktijk altijd achterloopt op de werkelijkheid.

Voor teams waar niet iedereen kan programmeren is dat visuele geen beperking maar net de meerwaarde. Je ruilt een beetje flexibiliteit in voor leesbaarheid, overdraagbaarheid en betrouwbaarheid. Voor de meeste bedrijven is dat een uitstekende ruil.

Wanneer heeft een AI-agent dan wél zin?

Een AI-agent verdient zijn plaats op precies één soort taak: het omzetten van ongestructureerde informatie naar gestructureerde informatie. Overal waar echte interpretatie nodig is, is een model op zijn plaats. Denk aan een vrije e-mail samenvatten, een PDF uitlezen, sentiment bepalen of ruwe tekst classificeren. Dat is werk waar vaste regels tekortschieten, omdat de input elke keer anders is. Meer over dat onderscheid lees je in onze blog over automatisering versus AI.

Maar hier wordt het interessant, want de reflex om "AI" te roepen slaat vaak te vroeg toe. Een voorbeeld uit onze eigen praktijk.

We wilden een agent bouwen die per planningsvoorstel kijkt of er voldoende voorraad is van de halffabricaten uit de stuklijst, en op basis daarvan beslist of we een product uit voorraad kunnen maken of een verse productie moeten plannen. Voor een voedingsbedrijf een logische vraag. Het voelde als een AI-taak, want het is een beslissing.

Tot we onszelf betrapten. Dit zijn geen interpretaties, dit zijn vaste regels. Pak de stuklijst, kijk per halffabricaat of de voorraad het benodigde aantal dekt, en kies op basis daarvan het pad. Dat is gewone als-dan-logica. Twee mensen met dezelfde cijfers komen altijd tot exact dezelfde uitkomst. Een agent erop loslaten betekent dat je per planningslijn een model laat nadenken over iets wat een simpele berekening deterministisch beslist. Duurder, trager en minder betrouwbaar dan de stap die het gewoon uitrekent.

De nuance: er zijn wél uitzonderingen waar het interpretatie wordt. Wat als de voorraad net niet volstaat maar bijna? Wat als een houdbaarheidsdatum meespeelt, of een alternatief halffabricaat ook kan? Daar, op die uitzonderingen, voegt een agent waarde toe. De juiste architectuur is dus niet "agent of regels", maar regels voor de voorspelbare lijnen en het model alleen voor de gevallen die er echt uit vallen.

De testvraag voor je eigen automation

Komen twee mensen met dezelfde input altijd tot exact dezelfde uitkomst, dan is het een regel. Die hoort thuis in een gewone, deterministische stap. Geen AI nodig.

Komen ze tot verschillende, verdedigbare uitkomsten, zoals bij het beoordelen van een vrije e-mail of het inschatten van een klacht, dan zit er echte ambiguïteit in. Daar verdient het model zijn geld.

Dit ene onderscheid bespaart je vaak zowel geld als kopzorgen.

De token-rekening: waarom agents voor repetitief werk duur worden

Een AI-agent inzetten voor terugkerend, voorspelbaar werk is op termijn een dure keuze. Elke keer dat een model "nadenkt", kost dat tokens, en dus geld en tijd. Eén keer is dat verwaarloosbaar. Maar een proces dat een tiental tot honderdtal keer per dag draait, telt sneller op dan je denkt.

Een platform-node die een regel uitvoert, kost je een fractie van een modelcall en draait in milliseconden. Bij n8n self-hosted is die stap zelfs vrijwel gratis. Een agent die dezelfde beslissing neemt, betaalt per keer en is trager. Voor het ongestructureerde werk is die kost gerechtvaardigd, want daar krijg je iets voor terug wat een regel niet kan. Voor het voorspelbare werk betaal je voor niets.

De agent als node, niet als systeem

De eerlijke conclusie is rustiger dan de hype, maar bruikbaarder. AI maakt de automatiseringstools niet overbodig. AI helpt je die tools sneller te vullen. De agent bouwt de flow en handelt het ambigue stuk af. Het platform draait, bewaakt en toont het geheel.

De agent hoort dus als één node in de workflow, op de plek waar interpretatie nodig is. Niet als de workflow zelf. Wie dat onderscheid maakt, krijgt het beste van twee werelden: de slimheid van AI waar het telt, en de betrouwbaarheid van een platform waar het moet.