Module 2 — Textream-script

Download .txt Open presentatie Terug naar academy

MODULE 2 — BUILDR FOUNDATION

[START OP SLIDE 1]

Welkom bij Module 2 van Buildr Foundation.

In deze module leer je hoe AI-systemen echt in elkaar zitten: als simpele stappen, met duidelijke bouwblokken.

[KLIK — NAAR SLIDE 2]

Als je het woord "AI-systeem" hoort, denk je waarschijnlijk aan iets als een robot, of een slim brein dat in zijn eentje alles oplost.

Eén magische doos waar je een vraag in stopt en er een compleet antwoord uit komt.

Dat beeld klopt niet, en het is precies de reden waarom mensen denken dat ze eerst jarenlang moeten leren programmeren voordat ze iets kunnen bouwen.

De waarheid is veel saaier, en veel geruststellender.

Een AI-systeem is meestal een rijtje simpele stappen die na elkaar gebeuren, en in dat rijtje gebruikt vaak maar één of twee stappen daadwerkelijk AI.

De rest is gewoon: data ophalen, data verplaatsen, en data ergens neerzetten.

[KLIK — NAAR SLIDE 3]

Neem een webshop die klantvragen binnenkrijgt via WhatsApp.

Het hele "AI-systeem" ziet er dan zo uit.

Stap één: het bericht komt binnen.

Stap twee: het systeem herkent welke klant dit is en zoekt de bijbehorende bestelling op.

Stap drie: hier komt de AI om de hoek, die leest de vraag en de bestelgegevens, en schrijft een passend antwoord.

[KLIK — NAAR SLIDE 4]

Stap vier: dat antwoord wordt netjes geformatteerd.

Stap vijf: het antwoord wordt terug verstuurd.

Van die vijf stappen gebruikt er precies één AI.

De rest is gewoon logistiek.

Die ene AI-stap krijgt geen vage opdracht, maar een precieze.

[KLIK — NAAR SLIDE 5]

De prompt die het systeem op dat moment naar de AI stuurt, ziet er ongeveer zo uit: "Dit is de vraag van de klant: [vraag].

Dit zijn de bestelgegevens: [bestelnummer, status, verzenddatum].

Schrijf een vriendelijk, kort antwoord in de toon van [bedrijf], en gebruik alleen de informatie die hierboven staat."

De AI krijgt dus niet alleen de vraag, maar ook precies de gegevens en de instructie die nodig zijn om in één keer een goed antwoord te geven.

Dat sluit ook meteen aan op wat je in Module 1 leerde over een goede briefing: deze stap werkt alleen goed omdat de rest van het systeem die briefing automatisch aanlevert.

[KLIK — NAAR SLIDE 6]

Hetzelfde geldt voor een recruitmentflow die CVundefineds screent, een contentpijplijn die social posts voorbereidt, of een systeem dat binnenkomende leads beoordeelt.

Telkens is er een hele reeks simpele, saaie stappen, en daartussen één of twee momenten waar AI het denkwerk doet.

Dus de praktische conclusie voor vandaag: als je naar een bedrijfsprobleem kijkt, stel jezelf niet de vraag "hoe bouw ik hier een AI voor".

Stel jezelf de vraag: wat zijn de stappen die hier nu al gebeuren, en welke van die stappen heeft écht AI nodig.

Negen van de tien keer is dat antwoord: maar één.

[KLIK — NAAR SLIDE 7]

In de vorige module zag je de Buildr Stack al voorbijkomen: trigger, AI-verwerking, orchestratie, opslag, output.

Nu gaan we daar echt induiken, want dit zijn de vijf bouwblokken die je in vrijwel elk systeem terugziet, in elke branche, met elke combinatie tools.

Bouwblok één is de trigger.

Dit is het moment dat alles in gang zet.

Dat kan een nieuw formulier-antwoord zijn, een binnenkomend WhatsApp-bericht, een nieuwe rij in een spreadsheet, of simpelweg een vast tijdstip op de klok, elke ochtend om negen uur bijvoorbeeld.

Bouwblok twee is de AI-verwerking.

Dit is waar een taalmodel het denkwerk doet.

Denk aan het inschatten hoe urgent een supportvraag is, het samenvatten van een lang mailtje, of het schrijven van een eerste concept-antwoord.

Bouwblok drie is de orchestratie.

[KLIK — NAAR SLIDE 8]

Dit is de regielaag, de plek waar logica zit.

Als dit gebeurt, doe dan dat.

Als die voorwaarde klopt, stuur het dan hierheen, anders daarheen.

Dit bouwblok bepaalt de volgorde en de route van alles.

Bouwblok vier is de opslag.

Dit is het geheugen van je systeem.

Klantgegevens, status van een lead, geschiedenis van een gesprek, dit moet allemaal ergens blijven staan, anders begint je systeem elke keer weer bij nul.

Bouwblok vijf is de output.

Dit is waar het resultaat daadwerkelijk landt.

[KLIK — NAAR SLIDE 9]

Een bericht dat verstuurd wordt, een notificatie die afgaat, een update die ergens wordt weggeschreven.

Het mooie is: zodra je deze vijf blokken kent, kun je elk systeem dat je tegenkomt uit elkaar trekken.

Een recruitmentflow, een outreach-systeem, een planningstool voor een kapperszaak, het maakt niet uit.

Je gaat het altijd kunnen ontleden in deze vijf onderdelen.

Laten we dat met één voorbeeld helemaal concreet maken.

Pak de tandarts uit Module 1, die omzet verliest aan no-shows, en volg die helemaal door de vijf blokken heen.

Trigger: elke ochtend om acht uur checkt het systeem de agenda van de volgende dag.

AI-verwerking: voor elke afspraak schrijft de AI een kort, persoonlijk herinneringsbericht, met de naam van de patiënt en het tijdstip, in de toon van de praktijk.

Orchestratie: het systeem checkt of deze patiënt al eerder een no-show had.

[KLIK — NAAR SLIDE 10]

Was dat niet zo, dan wordt het bericht gewoon verstuurd.

Was dat wel zo, dan wordt er in plaats van een herinnering een actieve bevestiging gevraagd.

Opslag: elk verstuurd bericht en elke reactie wordt vastgelegd, zodat de praktijk altijd weet wie wel en niet heeft gereageerd.

Output: het bericht gaat naar de patiënt via WhatsApp, en als er na een paar uur geen reactie is, krijgt de balie een seintje om zelf te bellen.

Dat is precies hetzelfde patroon als bij de webshop uit de vorige video, alleen nu volledig ingevuld voor een andere branche.

Zodra je dit een paar keer hebt gedaan voor verschillende problemen, ga je dit patroon overal vanzelf herkennen.

De praktische conclusie: vanaf nu, als je een systeem analyseert of ontwerpt, loop je gewoon deze vijf blokken langs.

Wat is hier de trigger, waar zit de AI, hoe ziet de orchestratie eruit, wat moet er onthouden worden, en waar landt het resultaat.

Dat is letterlijk de hele denkstap die je als builder steeds opnieuw gaat doen.

[KLIK — NAAR SLIDE 11]

Zodra mensen de woorden "API" en "webhook" horen, klappen ze een beetje dicht.

Het voelt als iets dat alleen developers begrijpen, een geheime taal waar jij niet bij hoort.

Dat gevoel is onterecht, want het zijn eigenlijk twee heel simpele ideeën.

Stel je een restaurant voor.

Jij zit aan tafel en wil iets bestellen.

Je loopt niet zelf de keuken in om je bord te pakken.

Je geeft je bestelling door aan de ober, de ober brengt die naar de keuken, en de keuken stuurt via de ober een bord terug.

Dat hele proces, een vraag op een vaste, afgesproken manier stellen en een antwoord op een vaste manier terugkrijgen, dat is precies wat een API is.

[KLIK — NAAR SLIDE 12]

Een API is de ober tussen jouw systeem en een ander systeem, zoals een database, een CRM of een agenda-tool.

Jij vraagt iets, op de manier die zij verwachten, en zij geven iets terug, op de manier die jij kan lezen.

Een webhook is het tegenovergestelde, maar even simpel.

Stel je staat in dat restaurant te wachten op een tafel, en je loopt om de vijf minuten naar de balie om te vragen of je tafel al vrij is.

Dat is vermoeiend, en voor een systeem ook onnodig zwaar.

Een webhook is wanneer het restaurant jou actief belt zodra je tafel klaar is.

Jij hoeft niks te checken, je wordt vanzelf aangetikt op het moment dat er iets gebeurt.

Dat is precies wat een webhook doet tussen twee systemen: in plaats van steeds te vragen "is er al iets nieuws", tikt het andere systeem jou aan op het exacte moment dat er iets verandert.

[KLIK — NAAR SLIDE 13]

Zo ziet dat er in het echt ongeveer uit, zonder poespas.

Een webhook die binnenkomt nadat iemand een formulier heeft ingevuld, bevat gewoon de gegevens die net zijn ingevoerd: naam Jan, e-mail jan@bedrijf.nl, vraag "ik wil graag een afspraak".

Een API-aanvraag om die persoon op te slaan in een database, stuurt diezelfde gegevens door, maar dan in het format dat die specifieke database verwacht.

Het ziet er misschien onwennig uit als je het voor het eerst tegenkomt, maar het is in de kern niets meer dan een lijstje van naam en waarde, netjes onder elkaar.

Geen geheime code, gewoon dezelfde informatie die je al kende, in een andere jas.

Zet die twee bij elkaar en je krijgt een heel normale flow.

Iemand vult een formulier in.

Dat formulier stuurt direct een webhook, het tikt je systeem aan: er is iets nieuws.

[KLIK — NAAR SLIDE 14]

Je systeem roept vervolgens een API aan om die persoon op te slaan in een database.

Daarna roept het een API aan bij Claude om een persoonlijk bericht te laten schrijven.

En als laatste roept het een API aan bij Telegram om de verkoper een seintje te geven.

Vier simpele stappen, twee soorten verbindingen: eentje die jou aantikt, en een paar waar jij zelf iets aanvraagt.

De praktische conclusie: vanaf nu, als je leest dat een tool "een webhook heeft" of "een API heeft", weet je precies wat dat betekent.

Webhook betekent: zij tikken jou aan zodra er iets gebeurt.

API betekent: jij vraagt iets aan hen, en zij geven antwoord.

Dat is alles wat je nodig hebt om die woorden nooit meer eng te vinden.

[KLIK — NAAR SLIDE 15]

Je hebt een systeem gebouwd.

Het werkt.

Twee weken lang loopt alles perfect, en dan, op een doodgewone dinsdagochtend, doet het plotseling niks meer.

De eerste gedachte van bijna iedereen op dat moment is: ik snap hier niks van, ik ben blijkbaar niet technisch genoeg.

En precies op dat moment geven de meeste mensen op, vlak voordat ze een goede builder waren geworden.

Hier is het geruststellende nieuws.

Bijna elke storing in een systeem valt in een klein, voorspelbaar rijtje oorzaken.

Het is geen mysterie, het is een checklist.

Eén: een sleutel is verlopen of ongeldig geworden.

Een wachtwoord is gewijzigd, een toegangstoken is verlopen, een account is uitgelogd.

[KLIK — NAAR SLIDE 16]

Dat zie je in de praktijk vaak terug als een melding met de tekst "niet geautoriseerd", een duidelijk signaal dat een sleutel niet meer geldig is.

Bijvoorbeeld een recruitmentflow die plotseling stopt omdat het wachtwoord van de vacaturesite is veranderd.

Twee: het formaat van de data is veranderd.

Een tool past de manier aan waarop hij informatie aanlevert, een veld heet plotseling anders, en je systeem verwacht nog de oude naam.

Bijvoorbeeld een CRM-koppeling die breekt omdat een veld "telefoonnummer" is hernoemd naar "telefoon".

Drie: een limiet is bereikt.

Te veel verzoeken in een korte tijd, een maandelijks quotum dat vol is.

Dat herken je vaak aan een melding met de tekst "te veel verzoeken" of "limiet bereikt".

Bijvoorbeeld een contentpijplijn die vastloopt omdat er te veel berichten in een uur worden verstuurd en de tool dat blokkeert.

Vier: een trigger vuurt niet meer af.

[KLIK — NAAR SLIDE 17]

Een webhook-adres is veranderd, een formulier is aangepast zonder de koppeling bij te werken.

Bijvoorbeeld een leadflow die stil blijft staan omdat het formulier vervangen is door een nieuwe versie met een andere link.

Vijf: een menselijke fout in de configuratie.

Een verkeerd veld gekoppeld, een voorwaarde die net iets anders is ingesteld dan bedoeld.

Dit is de minst spannende, maar meest voorkomende oorzaak van allemaal.

De praktische conclusie: debuggen is geen geheime vaardigheid die alleen ervaren developers hebben.

Het is een checklist die je elke keer afloopt.

Zijn de sleutels nog geldig, is het dataformaat nog hetzelfde, loop je tegen een limiet aan, vuurt de trigger nog af, en klopt de configuratie nog.

Negen van de tien keer vind je het antwoord in precies die vijf stappen, en blijkt het probleem helemaal niet zo ingewikkeld als het voelde.

[KLIK — NAAR SLIDE 18]

Je kent nu de vijf bouwblokken, je weet hoe APIundefineds en webhooks werken, en je weet waarom systemen stuk gaan.

Voordat je in de volgende modules echt gaat bouwen met Claude en Claude Code, is er nog één vaardigheid die alles makkelijker maakt, en die kost je vijf minuten in plaats van uren: een systeem op papier ontwerpen voordat je er een tool voor opent.

De meeste mensen die vastlopen bij het bouwen, lopen niet vast omdat de tool moeilijk is.

Ze lopen vast omdat ze nooit helder hebben gemaakt wat ze precies willen, voordat ze begonnen.

Het ontwerp dat je hier leert, is niets ingewikkelder dan vijf korte zinnen, eentje per bouwblok.

Pak een nieuw voorbeeld om dit te laten zien: de recruiter uit Module 1, die tweehonderd CVundefineds per vacature handmatig doorleest.

[KLIK — NAAR SLIDE 19]

Vijf zinnen, vijf bouwblokken.

Trigger: een nieuwe sollicitatie komt binnen via het formulier op de vacaturepagina.

AI-verwerking: de AI leest het CV en de motivatie, en beoordeelt die tegen de eisen van de functie.

Orchestratie: scoort het CV hoog genoeg, dan gaat het door naar de shortlist.

Scoort het te laag, dan krijgt de kandidaat een automatische, vriendelijke afwijzing.

Opslag: elke sollicitatie en de bijbehorende score worden vastgelegd, zodat de recruiter op elk moment kan teruglezen waarom iemand wel of niet is doorgegaan.

[KLIK — NAAR SLIDE 20]

Output: de recruiter krijgt elke ochtend een overzicht van de nieuwe shortlist-kandidaten, in plaats van zelf alles te moeten doorzoeken.

Dat is het.

Vijf zinnen, en je hebt het hele systeem al staan voordat er één tool open is geweest.

Dit is precies wat je zelf gaat doen voor elk probleem dat je oppakt: schrijf de vijf zinnen op, laat ze even op je inwerken, en pas daarna ga je naar Claude of Claude Code om het daadwerkelijk te bouwen.

De praktische conclusie: vijf zinnen op papier, voordat je één tool opent.

Dat is het verschil tussen iemand die met een vaag idee een tool opent en er na een uur nog steeds niet uitkomt, en iemand die binnen vijf minuten precies weet wat hij gaat bouwen en waarom.

[KLIK — NAAR SLIDE 21]

Zodra je systemen bouwt voor echte bedrijven, werk je met echte gegevens.

Namen, e-mailadressen, telefoonnummers, soms gezondheidsinformatie zoals bij de tandarts uit de eerdere videoundefineds, soms CVundefineds vol persoonlijke details zoals bij de recruiter.

Dat is geen bijzaak, dat is iets waar je vanaf de eerste dag bewust mee om moet gaan.

In Nederland en de rest van Europa valt dit onder de AVG, de privacywetgeving die regelt hoe bedrijven met persoonsgegevens om mogen gaan.

Je hoeft geen jurist te worden om hiermee te werken, maar een paar simpele gewoontes voorkomen het grootste deel van de problemen.

[KLIK — NAAR SLIDE 22]

Eerste gewoonte: vraag het gewoon aan de klant.

Voordat je begint te testen of te bouwen met hun echte gegevens, check je of dat mag, en of er beperkingen zijn.

De meeste bedrijven zeggen gewoon ja, maar het is aan hen om dat te bepalen, niet aan jou.

Tweede gewoonte: gebruik niet meer data dan nodig.

[KLIK — NAAR SLIDE 23]

Als je systeem alleen een naam en een telefoonnummer nodig heeft om te werken, geef het dan niet ook toegang tot een volledig klantenbestand met informatie die niets met de taak te doen heeft.

Derde gewoonte: let op waar data terechtkomt.

Een AI-model dat je gebruikt om een bericht te schrijven, heeft die informatie maar heel kort nodig, voor dat ene moment.

Een database waarin je iets langdurig opslaat, is een andere afspraak, en daar moet de klant ook gewoon weten wat erin staat en hoelang het er blijft staan.

[KLIK — NAAR SLIDE 24]

Naast privacy is er nog een principe dat hier hoort, en dat je al een paar keer hebt gezien zonder dat het een naam had.

AI mag nooit ongezien naar een klant toe.

Bij de outreach-automation die je later gaat bouwen, zie je dat een bericht eerst naar een overzicht gaat voor controle, voordat het wordt verstuurd.

Dat is geen toeval, dat is een vast principe.

[KLIK — NAAR SLIDE 25]

Overal waar een AI-systeem rechtstreeks contact heeft met de klant van je klant, bouw je een moment van menselijke controle in, hoe klein ook.

Dat voorkomt niet alleen privacy-problemen, het voorkomt ook dat een vreemd of fout antwoord ongezien naar iemand toegaat.

De praktische conclusie: vraag toestemming, gebruik niet meer data dan nodig, en bouw overal waar AI rechtstreeks naar een klant communiceert een controlemoment in.

Dat zijn geen extra stappen die je vertragen, het zijn de stappen die ervoor zorgen dat een bedrijf je blijft vertrouwen.