Scripts
Module 3 — Textream-script
Kopieer volledig script
Download .txt
Open presentatie
Terug naar academy
MODULE 3 — BUILDR FOUNDATION [START OP SLIDE 1] Welkom bij Module 3 van Buildr Foundation. In deze module leer je hoe je context, Claude en Claude Code gebruikt om systemen veel gerichter te bouwen. [KLIK — NAAR SLIDE 2] Herken je dit. Je opent een AI-chat, je legt voor de vijfde keer die week uit wie je doelgroep is, welke toon je gebruikt, en wat je precies bedoelt. Je krijgt een goed antwoord, sluit het venster, en de volgende dag begin je weer helemaal vanaf nul. Alle context die je had opgebouwd, is weg. In Module 1 hoorde je al dat AI alleen zo goed is als de briefing die je geeft. [KLIK — NAAR SLIDE 3] Het probleem is dat de meeste mensen die briefing elke keer opnieuw moeten schrijven, in plaats van hem één keer goed neer te zetten. Daar gaat deze video over: hoe je een briefing vastlegt zodat je hem nooit meer hoeft te herhalen. Er zijn een paar manieren om dat te doen, en ze werken allemaal op hetzelfde principe. De handigste is een Project-functie, die zowel Claude als andere AI-tools aanbieden. Je legt instructies, voorbeelden en achtergrondinformatie één keer vast, en elk nieuw gesprek binnen dat Project start automatisch met die context erbij. [KLIK — NAAR SLIDE 4] Maar het kan ook simpeler, zonder die functie. Je houdt zelf een los bestand bij met een korte samenvatting, wie de doelgroep is, welke toon je gebruikt, wat eerder goed werkte, en je plakt dat bestand aan het begin van elk nieuw gesprek erbij. Net iets handmatiger, maar precies hetzelfde idee: de briefing staat al klaar, in plaats van dat jij hem opnieuw moet uittypen. Denk aan een paar voorbeelden. [KLIK — NAAR SLIDE 5] Vastgelegde context voor het schrijven van social content voor een specifiek bedrijf, met de merkstem en een paar voorbeeldposts erin. Vastgelegde context voor het screenen van kandidaten voor een vacature, met het functieprofiel en de harde eisen erin. Vastgelegde context voor het beantwoorden van klantvragen voor een webshop, met productinformatie en veelgestelde vragen erin. In alle drie de gevallen typ je daarna alleen nog de specifieke vraag van dat moment, en de rest van de context staat er al, of dat nou in een Project zit of in een bestand dat je erbij plakt. Het verschil met een los gesprek zonder die context is enorm. [KLIK — NAAR SLIDE 6] Een los gesprek is als elke ochtend een nieuwe collega inwerken. Vastgelegde context, in welke vorm dan ook, is als een collega die al meeloopt en precies weet hoe het bedrijf werkt. De praktische conclusie: zodra je merkt dat je dezelfde context twee keer aan het uitleggen bent, is dat het signaal om hem vast te leggen, in een Project of in je eigen samenvattingsbestand. Dat is het moment waarop je stopt met steeds opnieuw inwerken, en begint met bouwen op iets dat blijft staan. [KLIK — NAAR SLIDE 7] Het woord "programmeren" roept bij veel mensen meteen een drempel op. Het voelt als iets waar je jaren voor moet studeren voordat je serieus mag meedoen. Dat beeld klopt niet meer, en Claude Code is precies de reden waarom. Tot nu toe heb je Claude gebruikt om over dingen te praten: teksten, ideeën, plannen. Claude Code is anders. In plaats van alleen te praten, werkt het direct in een echte projectmap, maakt het bestanden aan, past het bestaande bestanden aan, en kan het zelf commandoundefineds uitvoeren om te checken of iets werkt. Belangrijk om te begrijpen: dit gaat niet in één klap. Het is geen kwestie van iets typen en een minuut later een kant en klaar systeem terugkrijgen. [KLIK — NAAR SLIDE 8] Het werkt in kleine stappen, en jij blijft daar steeds bij betrokken. Stel je vraagt: maak een overzicht van alle klanten die deze maand niet hebben gereageerd op de eerste e-mail. Claude Code kijkt eerst in de bestanden die er al staan, om te zien hoe de data is opgebouwd. Het schrijft een eerste versie van een script, voert dat uit, en kijkt naar het resultaat. Stel dat blijkt dat een datum in een ander formaat staat dan verwacht, dan ziet Claude Code die fout, past het script zelf aan, en probeert het opnieuw. Dat herhaalt zich, soms een paar keer, totdat het overzicht klopt. Daarna laat het je zien wat het heeft gedaan en wat het resultaat is, zodat jij kan checken of dat overeenkomt met wat je nodig had. [KLIK — NAAR SLIDE 9] Dat checken is jouw rol in dit proces. Niet het schrijven van elke regel zelf, maar wel kritisch kijken: klopt dit overzicht, mist er iemand, staat er iets dubbel in. Als er iets niet klopt, zeg je dat gewoon in gewone taal, en wordt het aangepast. Er is een gewoonte die het verschil maakt tussen mensen die hier vlot mee werken en mensen die vastlopen, en die gewoonte bestaat uit twee stappen, allebei vóórdat er iets gebouwd wordt. Stap één: schrijf eerst, los van Claude Code, helder uit wat je wil bereiken en waarom. Dat kan in een gewoon chatgesprek, in ChatGPT, in Claude zelf, of gewoon in een notitie. Niet "maak een tool", maar: wie heeft hier last van, wat moet er anders zijn als dit werkt, en wat is het simpelste resultaat dat al genoeg zou zijn. Die paar zinnen dwingen je om zelf eerst scherp te krijgen wat je vraagt, voordat je het aan Claude Code geeft. [KLIK — NAAR SLIDE 10] Stap twee: zodra je dat helder hebt, geef je het aan Claude Code, maar vraag je niet meteen om te bouwen. Je vraagt eerst om een plan. Een voorbeeld van zoundefinedn prompt: "Ik wil een overzicht van alle klanten die deze maand niet hebben gereageerd op de eerste e-mail. Voordat je begint te bouwen: leg in een paar stappen uit hoe je dit zou aanpakken, welke bestanden je daarvoor nodig denkt te hebben, en wat de uitkomst precies wordt. Begin nog niet met bouwen." Claude Code legt dan eerst zijn aanpak voor, en jij checkt of dat klopt met wat je in stap één had bedacht. Klopt het, dan zeg je gewoon "ziet goed uit, ga verder", en pas dan begint het daadwerkelijke bouwen, testen en herstellen dat je net hebt gezien. [KLIK — NAAR SLIDE 11] Die twee stappen, eerst zelf scherp krijgen wat je wil, dan een plan laten maken voordat er gebouwd wordt, voorkomen het meeste gedoe. Zonder die stappen kan Claude Code aan iets beginnen dat niet is wat je bedoelde, en moet je halverwege alles weer terugdraaien. Met die stappen weet je al voordat er één regel gebouwd is, of de aanpak klopt. Dit is het verschil tussen praten over een oplossing en daadwerkelijk een werkende oplossing krijgen, stap voor stap opgebouwd, met jou als degene die de richting en de controle houdt. De praktische conclusie: je hoeft niet te leren programmeren om Claude Code te gebruiken. Je moet wel leren om eerst zelf scherp te krijgen wat je wil, dan een plan te laten maken voordat er gebouwd wordt, en kritisch te checken of het resultaat ook echt klopt. Dat is de vaardigheid die je vanaf nu gaat trainen. [KLIK — NAAR SLIDE 12] Het woord "repository", of kortweg "repo", klinkt voor veel mensen alsof het iets ingewikkelds is dat alleen developers begrijpen. In werkelijkheid is het simpel: een repo is gewoon een map met alle bestanden van één project, waarbij elke aanpassing wordt bijgehouden. Vergelijk het met een ordner voor een klant. Alle documenten van dat project zitten in die ene ordner, netjes bij elkaar, en als je iets verandert, blijft de oude versie ergens bewaard zodat je altijd kan teruggrijpen als iets misgaat. [KLIK — NAAR SLIDE 13] Een repo doet precies dat, maar dan voor een systeem dat je bouwt in plaats van papieren documenten. Waarom dit belangrijk is. Zonder repoundefineds eindig je met bestanden die overal verspreid staan, oude en nieuwe versies die door elkaar liggen, en geen idee meer wat de laatste werkende versie was. Met een repo per systeem heb je altijd één duidelijke plek, je kan precies zien wanneer en wat er is veranderd, en je kan een systeem netjes overdragen of live zetten zonder dat er losse fragmenten zoekraken. [KLIK — NAAR SLIDE 14] Denk aan een builder die meerdere systemen tegelijk onderhoudt. Een repo voor het systeem dat leads beoordeelt. Een andere repo voor het systeem dat content voorbereidt. Weer een andere voor het systeem dat outreach-berichten verstuurt. [KLIK — NAAR SLIDE 15] Elk systeem in zijn eigen, afgebakende map, in plaats van alles op één grote hoop. De praktische conclusie: vanaf het moment dat je met Claude Code begint te bouwen, geef je elk systeem zijn eigen repo. Eén duidelijke map per probleem dat je oplost, in plaats van alles mengen in chaos. [KLIK — NAAR SLIDE 16] Nu je Claude Projects, Claude Code en repoundefineds kent, is het tijd om te laten zien hoe dat er in de praktijk uitziet, op een doodgewone werkdag. De dag begint met een korte check. Wat staat er open, wat is kapot, wat moet er gebouwd worden. Geen lange planningssessie, gewoon een blik op wat er nu echt aandacht nodig heeft. [KLIK — NAAR SLIDE 17] Dan kies je één concrete taak. Niet vijf dingen tegelijk, één ding. Stel het gaat om het verbeteren van een bericht dat automatisch verstuurd wordt naar nieuwe aanmeldingen. Als de taak vooral gaat om denken en schrijven, een tekst, een toon, een aanpak, dan ga je naar het bijbehorende Claude Project. [KLIK — NAAR SLIDE 18] De context staat er al, je beschrijft alleen wat er specifiek anders moet, en je krijgt een doordacht resultaat zonder opnieuw te moeten uitleggen wie de doelgroep is. Als de taak vooral gaat om iets daadwerkelijk te bouwen of repareren, dan open je de bijbehorende repo in Claude Code. Je beschrijft wat er moet gebeuren, je laat het bouwen of aanpassen, en je test het meteen met echte data, niet met een verzonnen voorbeeld. Als er iets misgaat, zie je dat direct, en pas je het samen met Claude Code aan totdat het klopt. [KLIK — NAAR SLIDE 19] Zodra het werkt, zet je het live, en ga je verder met de volgende taak. Geen losse week inplannen om "het helemaal af te maken". Je bouwt, test op iets echts, verbetert, en zet het in gebruik, en dat herhaal je de hele dag door. Aan het einde van de dag is er nog een korte check: wat werkte goed, wat moet morgen beter. [KLIK — NAAR SLIDE 20] Dat is precies de cyclus die je in Module 1 al hebt geleerd, bouwen, testen, verbeteren, verkopen, nu met de echte tools erbij. De praktische conclusie: dit is het ritme dat je elke dag gaat herhalen. Eerst voelt het nog alsof je steeds moet nadenken over welk hulpmiddel je nu precies nodig hebt. Na een paar weken voelt het zo vanzelfsprekend dat je het niet meer als "tools gebruiken" ervaart, maar gewoon als werken.