Een nacht op kantoor, weinig slaap, een paar biertjes, wat spelletjes en verrassend veel werkende code. Maar belangrijker nog: een boel geleerd!
Een hackathon van 24 uur klinkt als een zee van tijd, maar dat is het niet. Trek er een avond gezelligheid vanaf, een nacht slapen op een veldbed dat niet voor slapen ontworpen is, de lunch, het diner en het ontbijt de volgende ochtend en je houdt niet eens zo veel tijd over om echt te bouwen.
En tóch. Wat we in die tijd voor elkaar kregen, had geen van ons vooraf durven inschatten. We zijn met zeven collega's gaan vibecoden met Claude Code. Ofwel: niet eerst uitgebreid een architectuur tekenen en dan implementeren, maar in gesprek met het model bouwen, testen, bijsturen en opnieuw. Aan het eind van de rit hadden we een stel hele leuke applicaties, en minstens zo belangrijk, we hebben er allemaal enorm veel zin in gekregen om ermee door te gaan.
Hieronder de dingen die we onderweg leerden. Sommige verrassend leuk, sommige verrassend ongemakkelijk. Benieuwd of jullie er baat bij hebben!
1. Je hoeft het niet te kennen om het te kunnen doen
Dit was misschien wel de grootste eyeopener. Je hoeft een framework, taal of library niet te beheersen om er iets werkends mee neer te zetten. Claude schrijft de code, jij stuurt bij. Dat verlaagt de drempel om aan iets te beginnen enorm. Maar er zit een keerzijde aan: je moet het wél verstand van zaken hebben om te kunnen controleren of wat Claude maakt ook klopt. (Of je moet enorm goed kunnen testen natuurlijk!) Daarover later in deze blog meer.
2. Testen is key
Claude Code kan alles bouwen, en nog snel ook. Maar dán begint het werk.
Want als je gaat testen dan vallen twee zaken gelijk op.
Ten eerste: het is net niet helemaal wat je voor ogen had.
Ten tweede - en dat is de confronterende - jouw vraag was net niet helemaal goed.
Het model heeft precies gedaan wat je vroeg, alleen bedoelde je iets anders. Dat je dat pas ontdekt hebt tijdens het testen is geen bijzaak, dat ís het proces.
Claude schrijft zelf ook tests en voert ze uit. Dat voelt geruststellend, tot je de vraag stelt die je als tester eigenlijk meteen moet stellen: wat wordt hier precies getest? En zijn wij het daarmee eens? Een groene testset die de verkeerde dingen controleert, is gevaarlijker dan geen testset.
Gezien de tijd zijn we niet gedoken in wat Claude nu precies testte. We hebben vooral zelf veel handmatig getest en ervaren wat er goed en niet goed was.
3. De perfecte prompt bestaat niet
We hebben het geprobeerd. Die ene prompt schrijven die alles vooraf beschrijft, zodat het in één keer goed is. Het lukt niet en het gaat ook niet lukken. Je kunt niet alles opschrijven wat je voor ogen hebt, simpelweg omdat je zelf nog niet precies weet wat je bedoelt tot je het resultaat ziet.
Iteratief werken is veel handiger. Klein beginnen, kijken wat eruit komt en bijsturen. Dat voelt als "minder efficiënt", maar onder aan de streep is het sneller.
Een mooie tussenvorm is de "Plan mode" in Claude Code. Claude maakt dan eerst een plan dat jij kunt reviewen. Je leest mee, corrigeert waar nodig, geeft toestemming en pas dán gaat hij bouwen. Scheelt een hoop code die je achteraf mogelijk weer weg moet gooien.
4. Let op je context window
Een praktische les die we op de harde manier leerden: chat niet eindeloos door in dezelfde sessie. Je context window groeit dan maar door, en dat kost je tokens én kwaliteit.
Een paar dingen die hielpen:
- Check je context window. Gewoon regelmatig kijken hoe vol je zit. Door /context in je chat te typen, krijg je een overzicht zoals hiernaast staat. Hier zie je dat door het lange chatten veel ruimte in wordt genomen door de messages.
- Gebruik /compact. Daarmee comprimeert Claude je context window tot iets hanteerbaars.
- Start een nieuwe chat als je aan een nieuw stuk begint.
5. Tokens gaan sneller op dan je denkt
Een enkel verzoek kost al snel 10.000 tot 50.000 tokens en met een groot context window loopt dat snel op. In onze ervaring ging Fable daarbij vele malen harder dan Sonnet. Fable is zeker krachtiger, maar bedenk goed of je dat nodig hebt. Of heb je de tokens nodig voor vervolgvragen?
Bijkopen van tokens kan. Maar het bleef voor ons onduidelijk wat je daar precies voor terugkrijgt. Als je een hackathon plant: houd er rekening mee dat de limiet een reëel risico is en bedenk vooraf wie welk model gebruikt en waarvoor. Zet niet je zwaarste model in op je simpelste taak. Wij kochten voor 20 euro bij waarvan we de helft in een uur op hadden. Toen hadden we weer tokens uit de nieuwe sessie.
6. Zet niet overal Claude voor in
We wilde eerst lui doen door Claude via de Chrome extensie toegang te geven tot Chrome en hem een nieuwe github repo aan te laten maken. Alles bij elkaar kostte dat al best wat tijd. Dat vond Claude ook want die kwam al redelijk snel met de tip: doe dit lekker zelf in 1 minuut. En daar had hij gelijk in.
Dat was misschien wel de meest nuchtere les van de nacht.
7. En dan de ongemakkelijke les: let op wat je deelt
Hier zijn we een paar keer even stil van geworden.
Alles wat je laat maken, staat in je Claude-account. Dat DB-diagram dat je even snel liet genereren? Dat staat direct online. Realiseer je goed wat je in een prompt plakt, schema's, data, keys, klantgegevens. Het is geen lokaal schetsblok.
De Claude Chrome-extensie kan alles wat je browser kan, dus ook je Gmail uitlezen. Dat is precies waarom het handig is maar ook precies waarom het spannend is. Het werd voor ons alleen echt oncomfortabel toen een andere collega, die op hetzelfde claude account was ingelogd, vanaf zijn laptop mijn prive e-mail kon inzien. Dus deel geen accounts, zeker niet als je de claude extensie in Chrome aanzet.
