In Deel 1 schreef ik waarom we een AI-reisinterface vanaf nul bouwden, wat we leerden van onze eerste mislukte poging in 2019, en waarom een plugin je nooit een volledig geïntegreerde conversationele ervaring geeft. Dit deel gaat over het hoe. De architectuur, de zoekpipeline, het geheugenprobleem dat vier pogingen kostte om op te lossen, en het UI/UX-werk dat 25 seconden aanvoelt als 5.

De architectuur

Omdat dit een techblog is en geen marketingpagina, laat ik je zien wat er echt draait. Dit is geen weekendproject. Dit is productie-infrastructuur.

Frontend (React + TypeScript + Zustand)
    │
    │  WebSocket (real-time, bidirectional)
    │
FastAPI Backend
    ├── Query Orchestrator
    │     ├── LLM Client (multi-provider with automatic fallback)
    │     ├── Tool Registry (9 specialized tools)
    │     └── Observer System (async post-turn analysis)
    ├── RAG Pipeline
    │     ├── Vector Database (3 content collections)
    │     ├── Embedding Engine
    │     └── Reranker (dual provider, switchable)
    ├── Conversation Memory (dual storage)
    │     ├── SQL (message history)
    │     └── Vector DB (semantic search over past messages)
    ├── Security Layer
    │     ├── Input Guard (prompt injection defense)
    │     ├── Output Guard (credential leak prevention)
    │     └── Rate Limiting + IP Management
    ├── MCP Server (Model Context Protocol)
    │     └── External AI assistant access to our data
    └── Lead Management
          ├── Proposal Generation
          └── Specialist Handoff

De frontend is een React-applicatie met real-time WebSocket-communicatie. Geen polling. Geen request-response-cycli waarin je op een compleet antwoord wacht. Elke token streamt in real-time, gebufferd op 50ms-intervallen om flikkering in de UI te voorkomen. Productresultaten worden naar de interface gepusht zodra ze gevonden zijn, nog voordat de LLM aan zijn antwoord begint.

De backend is Python/FastAPI met een modulair toolsysteem. De LLM genereert niet alleen tekst. Hij heeft toegang tot 9 gespecialiseerde tools en beslist zelfstandig welke hij gebruikt. Reizen zoeken? Dan roept hij search_products aan. Informatie over een bestemming nodig? Dan roept hij search_knowledge aan. Terugroepen wat eerder besproken is? Dan doorzoekt hij het gespreksgeheugen semantisch.

De LLM genereert geen antwoorden. Hij orkestreert tools en stelt een antwoord samen op basis van echte data.

De LLM-laag draait met een multi-provider fallback-systeem. Valt de primaire provider uit, dan schakelt het systeem automatisch over naar de secundaire. Geen downtime. Geen foutmeldingen. De klant merkt er niets van.

Er draait al een MCP-server, het protocol dat ik beschreef in mijn Web 4.0-post. Externe AI-assistenten kunnen onze reisdata er al door bevragen. Het is nog vroeg, maar de infrastructuur voor AI-to-business-communicatie staat live. Als de AI-assistent van Lisa de producten van 333travel wil doorzoeken, bestaat het endpoint al.

De RAG-pipeline: waar het echte werk gebeurt

RAG, Retrieval-Augmented Generation, is de ruggengraat van het hele systeem. Het is wat “GPT met een kennisbank” scheidt van “een AI die je product echt kent.” Maar slecht uitgevoerde RAG is bijna erger dan geen RAG.

We onderhouden drie aparte vectorcollections:

Stelt een klant een vraag, dan wordt de query ge-embed en tegen de relevante collection gegooid. Maar hier komt het cruciale deel: we pakken niet gewoon de beste vector-matches en noemen dat een resultaat.

Vector similarity alleen is middelmatig. Het brengt je in de juiste richting, maar levert niet de beste resultaten. Daarom doen we een brede fetch, aanzienlijk meer resultaten dan nodig, en halen die door een reranker. De reranker beoordeelt elk query-documentpaar op werkelijke semantische relevantie, niet alleen op embedding-nabijheid.

Het verschil is enorm. Het is het verschil tussen “hier zijn reizen die een paar van je woorden bevatten” en “hier zijn reizen die daadwerkelijk matchen met wat je zoekt.”

Maar het gaat verder. Nog voordat de query de vectordatabase raakt, gaat hij door een fuzzy normalisatielaag. Elke land- en plaatsnaam in ons systeem wordt bij het opstarten gecachet. Typt een klant “Bali”, dan weten we dat Indonesië bedoeld wordt. Schrijft iemand “Tailand”, dan weten we wat er bedoeld wordt. Aliassen, spellingvarianten, taalverschillen: allemaal opgelost voordat de zoekopdracht begint. Zonder dit krijg je lege resultaten op queries die wel hadden moeten matchen. En daarbovenop combineert de zoekopdracht semantische similarity met metadatafilters. Land, duur, producttype: dat zijn geen velden in een database. Het zijn actieve filters die samen met de vectorsearch de resultaten verfijnen, nog voordat de reranker begint.

Na het reranken splitsen de resultaten zich in twee paden. De volledige set gererankte resultaten gaat meteen naar de frontend, maar geblurd. De klant ziet productkaarten verschijnen terwijl Joy nog aan het nadenken is. Het toont voortgang zonder te overweldigen. Ondertussen krijgt de LLM een uitgedunde versie van die resultaten, alleen de velden die hij nodig heeft om te redeneren. Deze projectie bespaart ruwweg een derde van de tokens, wat snellere antwoorden en lagere kosten betekent. Daarna stelt Joy haar antwoord samen en bespreekt ze de 4 of 5 reizen die echt passen bij de vraag. Alleen die besproken producten worden zichtbaar voor de klant. De rest verdwijnt. Wat de klant ziet is een gecureerde, doordachte selectie. Geen lijst met 10 zoekresultaten. Een aanbeveling van 5 die echt logisch zijn.

Brede fetch → Rerank → Project. Drie stappen die het verschil maken tussen een zoekresultaat en een aanbeveling.

Het geheugenprobleem

Dit is het onderdeel dat de meeste iteraties kostte om goed te krijgen.

Conversationele AI heeft een smerig geheimpje: het onthoudt niets. Elke LLM-call is stateless. Het model heeft geen idee wat er eerder gezegd is, tenzij je de context expliciet aanlevert. En er is een grens aan hoeveel context je kunt aanleveren.

Voor een simpele Q&A-chatbot maakt dat niet uit. Iemand stelt een vraag, krijgt een antwoord, klaar.

Maar voor een reisassistent? Geheugen is alles.

Een klant zegt: “Ik wil twee weken naar Thailand.” Drie beurten later: “Maak er eigenlijk drie weken van. En ik wil Laos erbij.” Vijf beurten later: “Wat was die reis die je eerder liet zien, met de kookles?”

Zonder geheugen is elke beurt een leeg blad. Het systeem weet niets van Thailand. Niets van de wijziging naar drie weken. Niets van Laos. En al helemaal niets van de reis met de kookles van zeven berichten geleden.

Zonder geheugen is elk bericht een eerste date. Je AI heeft geen idee wat er eerder gebeurd is.

Dit losten we niet in één poging op. Niet in twee. Zelfs niet in drie.

De eerste versie was simpel: de laatste 10 vraag-antwoordparen in de LLM-context stoppen. Dat werkte voor korte gesprekken. Maar onze gesprekken zijn niet kort. Klanten verkennen, vergelijken, komen terug op eerdere ideeën, bedenken zich. Tien beurten is niet genoeg als iemand twintig minuten over drie verschillende landen heeft gechat.

Dus probeerden we op de achtergrond samenvattingen te genereren. Het idee was goed: het gesprek samenvatten tot kernpunten, zodat de LLM altijd het volledige beeld heeft zonder de hele context window vol te gooien. De praktijk was anders. De LLM begon details te hallucineren in de samenvattingen. Landen door elkaar halen. Voorkeuren toedichten die de klant nooit had genoemd. De samenvatting zou de source of truth zijn, en hij verzon dingen.

Toen ontwierpen we een geheugensysteem in drie lagen: kortetermijn, tijdelijk en langetermijn. De tijdelijke laag moest bijhouden welke onderwerpen bij welke bestemming hoorden, welke voorkeuren op welk deel van de reis golden. Op papier elegant. In de praktijk een nachtmerrie. Het vereiste dat de AI complexe relationele context begreep, zoals “toen ze zeiden dat het budget flexibel was, bedoelden ze dat voor Thailand, niet voor Vietnam.” Dat kon hij niet. Te veel edge cases. Te fragiel.

Wat we uiteindelijk hadden, was simpeler en robuuster. Elk bericht wordt als vector geëmbed in een aparte memory collection in dezelfde database die we voor product search gebruiken. Als de klant zegt “die reis met de kookles”, draait het systeem een semantic search over alle eerdere berichten in die sessie. Het vindt het relevante bericht, ook als de exacte woorden niet overeenkomen. Misschien noemde Joy het drie beurten eerder een “culinaire ervaring”. Vector search geeft niets om woordmatching. Het matcht betekenis. Gecombineerd met de laatste 10 uitwisselingen in de prompt voor directe context, hoeft Joy niet voor elke vraag die tool call te doen. Ze heeft het recente gesprek direct bij de hand, en de volledige historie doorzoekbaar wanneer ze die nodig heeft.

Vier pogingen. Elke poging leerde ons iets over wat AI wel en niet kan doen met context. De definitieve versie werkt niet omdat het de slimste opzet is, maar omdat het het eerlijkst is over de beperkingen.

AI-geheugen is niet één probleem. Het zijn er twee: terugroepen wat er gezegd is, en begrijpen wat er bedoeld is. We hadden twee verschillende systemen nodig om dat op te lossen.

UI/UX: het onzichtbare werk

Hier sterven de meeste AI-projecten, zonder dat ze het zelf doorhebben.

Je kunt de meest geavanceerde RAG-pipeline ter wereld hebben. De slimste retrieval. De beste reranking. Maar als de interface traag, log of verwarrend aanvoelt, doet dat er allemaal niet toe. De klant geeft niets om je architectuur. Het gaat ze om hoe het voelt.

Als je AI slim is maar je interface traag, heb je een genie gebouwd dat opgesloten zit in een kast.

Hier zijn we diep op ingegaan. En “diep” betekent tientallen iteraties op dingen die de meeste mensen details zouden noemen. Maar de details zijn het product.

Streaming die natuurlijk voelt. LLM-antwoorden streamen token voor token over een WebSocket. Maar rauwe streaming geeft flikkerende tekst die schokkerig en onaangenaam is. We bufferen met intervallen van 50ms. Snel genoeg om real-time te voelen, langzaam genoeg om constante re-renders te voorkomen. Het verschil is subtiel, maar enorm voor de ervaren kwaliteit.

De afweging in snelheid. Laten we eerlijk zijn: een product search met volledig antwoord duurt 20 tot 30 seconden. Dat is lang. We weten dat het lang is. Maar we hebben een bewuste keuze gemaakt: kwaliteit boven snelheid. De brede fetch, de reranking, de semantic matching, elke stap in de pipeline bestaat omdat hij de resultaten beter maakt. Haal er één weg en je krijgt snellere antwoorden met slechtere aanbevelingen. Liever dat Joy 25 seconden werkt en 5 reizen aflevert die echt passen, dan 10 middelmatige matches in 8 seconden.

Dus de vraag werd: hoe zorgen we dat 25 seconden niet aanvoelen als 25 seconden? Daar kwam het UX-werk. Joy laat zien wat ze doet. Producten zoeken. Bestemmingsinformatie opzoeken. Gesprekshistorie checken. Elke tool call is zichtbaar terwijl hij gebeurt. Productkaarten schuiven vervaagd naar binnen terwijl zij nog haar antwoord opbouwt. Zodra het antwoord klaar is, worden alleen de reizen zichtbaar die Joy daadwerkelijk bespreekt. De rest vervaagt. De klant staart nooit naar een leeg scherm. Ze zien het proces ontvouwen. En het blijkt dat ergens naar kijken werken totaal anders voelt dan ergens op wachten.

Een deel van de latency is ook een taalprobleem. Nederlands is slecht vertegenwoordigd in de meeste embedding- en taalmodellen. Het semantische begrip dat in het Engels prachtig werkt, degradeert als je klanten en productdata Nederlands zijn. Dat betekent meer verwerking, zorgvuldiger matchen, meer moeite voor hetzelfde kwaliteitsniveau.

Wat is GPT-NL? GPT-NL is een Nederlands initiatief om een large language model te bouwen dat specifiek getraind en geoptimaliseerd is voor de Nederlandse taal.

GPT-NL: Een verantwoord taalmodel voor NederlandIn Nederland wordt gewerkt aan de ontwikkeling van een eigen open taalmodel genaamd GPT-NL. Wij gebruiken alleen data om het model te trainen als we die rechtmatig kunnen verkrijgen en bieden zo een verantwoord alternatief op bestaande LLMs. Dit model is essentieel voor het versterken en behouden van onze digitale soevereiniteit. GPT-NL

Waar huidige modellen zoals GPT en Claude Nederlands behandelen als een niet-bestaande taal, wil GPT-NL Nederlands een first-class citizen maken in AI. Voor toepassingen zoals de onze, waar zowel de klant als de productdata Nederlands zijn, kan een model dat de taal echt begrijpt de kwaliteit van semantisch zoeken aanzienlijk verbeteren en de extra verwerking verminderen die we nu nodig hebben om dat gat te compenseren. We volgen dit project op de voet.

En dan is er de keuze van het model. De kwaliteit van het gesprek hangt sterk af van welke LLM je gebruikt. We draaien op Sonnet 4.6 als primair model, en het verschil met kleinere of goedkopere modellen is niet subtiel. Het is het verschil tussen een gesprek dat natuurlijk voelt en een dat gerepeteerd aanvoelt. Haiku, de snellere en goedkopere optie, voelt als een downgrade zodra je overschakelt. GPT dient als onze automatische fallback, maar het is een stap terug in gesprekskwaliteit. Dit zijn geen inwisselbare commodity’s. Het model dat je kiest bepaalt de ervaring die je klant krijgt.

Directe paginaladingen. De hele conversatie blijft bewaard in local storage. Als je de pagina ververst of later terugkomt, staat je gesprek er al. Direct. Geen spinner. Geen “opnieuw verbinden…"-melding. De sync met de server gebeurt geruisloos op de achtergrond.

Markdown-normalisatie. LLM’s hebben meningen over opmaak. Claude is gek op vette koppen met emoji. GPT is gek op genummerde lijsten. Wij normaliseren alles server-side. Vet-met-emoji wordt omgezet naar schone koppen. Horizontale lijnen worden gestript. Font weights worden teruggeschroefd. Het resultaat oogt alsof het ontworpen is, niet gegenereerd. De klant moet nooit het gevoel hebben dat hij AI-output zit te lezen.

Sessiecontinuïteit. Je sessie overleeft paginaverversingen, gesloten browsers en herverbindingen. Kom een dag later terug, je gesprek staat er nog. Je opgeslagen reizen staan er nog. En als een sessie verloopt, krijg je een nette overlay die uitlegt wat er gebeurd is, geen kapotte pagina of een cryptische foutmelding.

De lead flow. Als een klant klaar is om met een specialist te praten, genereert het systeem een reisvoorstel dat al vooraf is ingevuld met wat het uit de conversatie weet. Besproken bestemmingen, reisvoorkeuren, bekeken producten. Minimale wrijving. Maximale context. De menselijke specialist pakt precies op waar Joy stopte. Dat is geen handoff. Dat is precies het punt. Joy bestaat om dat menselijke gesprek beter te maken, niet om het te vermijden.

Elk van deze details kostte meerdere iteraties. En geen enkele is zichtbaar voor de klant. Dat is de bedoeling.

Security: een eerlijke noot

Ik houd deze sectie kort en eerlijk. Security is niet iets wat je afmaakt. Het is iets waar je continu aan werkt.

We hebben een dubbel guardsysteem. Een input guard vóór de LLM die prompt-injection-pogingen onderschept, en een output guard ná de LLM die credential leaks of system prompt-fragmenten in antwoorden onderschept. Beide zijn deterministisch en voegen vrijwel geen latency toe.

De system prompt is verhard met anti-jailbreak-instructies. Er is rate limiting, botbescherming en IP-beheer voor hardnevig misbruik.

Is het bulletproof? Nee. Niets is dat. Maar het is gebouwd met defense in depth in gedachten, en we itereren erop naarmate nieuwe aanvalspatronen opduiken. Als je een AI-interface bouwt die met het publiek praat en je hebt nog niet nagedacht over input/output guards, dan ligt er een probleem op de loer.

Het grotere geheel: een extra kanaal, geen vervanging

Laat me heel duidelijk zijn over wat Joy is en wat ze niet is.

Joy is geen vervanging van onze website. Ze is geen vervanging van telefoon of e-mail. Ze is een extra kanaal. Een nieuwe manier voor klanten om onze producten te ontdekken, naast alles wat er al bestaat. Ze zal nooit een vervanging van menselijk contact zijn. Dat vinden we bij ons bedrijf het belangrijkst. Joy is een middel naar menselijk contact. Ze helpt klanten uitvinden wat ze willen, zodat het gesprek met een van onze specialisten op een compleet ander niveau begint.

Joy is niet de bestemming. Ze is de weg die leidt naar een echt gesprek met een echt persoon.

De MCP-server staat al live, wat betekent dat AI-assistenten onze data al programmatisch kunnen bevragen. Als de Web 4.0-visie werkelijkheid wordt en Lisa’s AI-assistent zelfstandig op zoek gaat naar haar perfecte Thailand-reis, dan bestaat het endpoint al. Niet omdat we er haastig mee aan de slag zijn gegaan. Omdat we al meer dan een jaar met deze infrastructuur aan het experimenteren zijn.

Joy is niet het eindproduct. Ze is het begin van een kanaalstrategie die zowel mens-tot-AI- als AI-tot-AI-interacties omvat. En ze is een test, een heel serieuze, heel grondige test, of conversationele AI vandaag de dag daadwerkelijk waarde kan toevoegen voor reisklanten.

De resultaten tot nu toe zijn beter dan ik verwachtte. Niet vlekkeloos, niets is dat, maar echt indrukwekkend in hoe natuurlijk de gesprekken voelen en hoe relevant de aanbevelingen zijn. Als je een klant een vaag idee ziet beschrijven en Joy komt met reizen die daadwerkelijk passen, dan besef je: dit is geen gimmick. Het werkt. En het werkt dankzij alles wat eronder ligt.

Dus, welk probleem lossen we ook alweer op?

Ik begon met deze vraag omdat dit de vraag was die alles heeft geleid wat we bouwden. Niet “hoe gebruiken we AI?” Niet “wat doen onze concurrenten?” Niet “hoe komen we innovatief over?”

Alleen: welk probleem lossen we op, en werkt deze oplossing daadwerkelijk?

We bouwden Joy om daarachter te komen. Met echte architectuur. Echte data. Echte klanten. En de bereidheid om “dit is nog niet klaar” te zeggen als dat zo zou blijken.

Als je nadenkt over het toevoegen van AI aan je product, begin daar. Niet met de tool. Niet met de pitch van een leverancier. Niet met de druk om bij te blijven.

Begin met de vraag. Bouw vanuit het antwoord.

Je klanten verdienen beter dan een FAQ met een gezicht. Ze verdienen een echt gesprek. En uiteindelijk een echt mens. Zorg dat je AI ze daar naartoe leidt, en niet ervandaan.

Als je Deel 1 nog niet gelezen hebt: daar begint het verhaal. Waarom we dit bouwden, wat we leerden van ons mislukken in 2019, en waarom je hier niet komt met een plugin.

Can a conversation be a travel channel? Part 1: We built one to find out.We built a full AI travel interface from scratch, not to say we do AI, but to test whether a conversation can actually be a meaningful channel for personalized travel. This is what it took, why a plugin will never get you there, and why most AI chatbots are just expensive search bars. All Subjects MatterRemco Loup.

We bouwden een AI-aangedreven reisinterface vanaf nul. Geen chatbot. Geen widget. Geen GPT-wrapper met een smiley op een website geplakt. Een volledige conversationele interface met een eigen vector database, een eigen retrieval pipeline, een eigen geheugensysteem en real-time streaming over WebSockets. Niet om iets te vervangen. Om te testen of conversationele AI er echt klaar voor is om een betekenisvol kanaal voor reizen te zijn. Dit is wat we ontdekten, wat het kostte, en waarom we denken dat het meeste van wat er nu is ruis is.

Dit is een verhaal in twee delen. Dit eerste deel gaat over het waarom: welk probleem we oplossen, wat we leerden van eerdere mislukkingen, en waarom een plugin je hier nooit zal brengen. Deel 2 gaat dieper in op de architectuur: de RAG pipeline, het geheugensysteem, de UI/UX-beslissingen en de technische afwegingen die we maakten.

Wat probeer je eigenlijk op te lossen?

Dat is de vraag waar ik steeds op terugkom. Elke keer als een bedrijf zijn nieuwe “AI-powered” feature aankondigt. Elke keer als iemand me vraagt wat wij met AI doen. Elke keer als een leverancier weer een plugin komt pitchen.

Het is op dit moment de belangrijkste vraag in tech. En bijna niemand stelt hem.

In plaats daarvan werkt de hele industrie achterstevoren: men begint met “we moeten iets met AI doen” en gaat dan op zoek naar een plek om het neer te zetten. Bedrijven horen “AI” en horen “innovatie” en denken dat ze achterlopen als ze niet nú iets doen.

De druk om “iets met AI te doen” is luider geworden dan de vraag wat je eigenlijk wilt bereiken.

En wat gebeurt er dan? Bedrijven grijpen de meest zichtbare, meest verkoopbare toepassing die ze kunnen vinden: een chatbot. Op de website plakken. Een naam en een vriendelijk gezichtje geven. Verbinden met een kennisbank. Klaar. “Wij doen nu AI.”

Het probleem: de integratie is altijd beperkt. Sommigen koppelen aan een productdatabase. Sommigen halen live beschikbaarheid op. Maar als plugin is er een plafond aan hoe diep die integratie gaat. Hij werkt altijd met de data die hij krijgt, in het formaat dat de API levert, met de context die de leverancier voldoende vond. Het resultaat is een interactie die aan de oppervlakte conversationeel oogt, maar fundamenteel beperkt blijft in wat hij kan.

En omdat het een plugin is, kan het nooit volledig naadloos zijn. Het blijft altijd een aparte laag bovenop je website, geen onderdeel ervan. Een andere designtaal. Een ander interactiemodel. Een andere ervaring. De klant voelt dat, ook al kan hij het niet onder woorden brengen. Het is het verschil tussen een kamer die als geheel is ontworpen en een kamer waar iemand een kiosk in de hoek heeft gezet.

Een slimmere poortwachter is nog steeds een poortwachter. Je klanten wilden een deur.

We zijn zelf deze weg gegaan. In 2019 bouwden we de eerste versie van Joy op Flow.ai. Een intent-gebaseerde chatbot die natuurlijke taal begreep, reisvoorkeuren uit één zin kon halen en leads genereerde voor onze specialisten. Het werkte. Technisch gezien. Maar de klantbetrokkenheid was te laag om hem in leven te houden. Begin 2022 hebben we Joy uit dienst genomen.

De les was niet dat de technologie slecht was. De les was dat mensen hebben geleerd chatbots te wantrouwen. En terecht. Jarenlang hebben bedrijven chatbots gebruikt als barrière om contact te maken, ook toen ze het tegendeel beweerden. Klanten weten dat. Ze hebben het meegemaakt. Na drie foute antwoorden denk je niet “even opnieuw proberen.” Je denkt “hoe kom ik bij een echt mens?” Sommige mensen doen niet eens de moeite. Ze zien een chatbelletje met een gezichtje en hun eerste reactie is: weg ermee. Niet omdat ze ongeduldig zijn, maar omdat de ervaring hun heeft geleerd dat het tijdverspilling is.

Dat is geen technologieprobleem. Dat is een vertrouwensprobleem. En dat los je niet op door hetzelfde formaat slimmer te maken.

Daar komt bij dat de interface van een chatbot-plugin simpelweg beperkend is. Een klein venster in de hoek van je scherm. Een paar regels tekst. Misschien een knop of twee. Daarin kun je geen rijke productkaarten tonen. Je kunt geen kaart van een reis laten zien. Je kunt iemand niet laten browsen, vergelijken, reizen bewaren voor later. Het formaat dicteert de ervaring, en het formaat is een doos.

Die ervaring is precies waarom we geen nieuwe chatbot hebben gebouwd. Geen slimmere. Geen betere. Iets fundamenteel anders. Een volledige conversationele interface, vanaf nul gebouwd, ontworpen om te inspireren. Waar iemand bestemmingen kan verkennen, reizen kan ontdekken waarvan hij het bestaan niet kende, en waar hij — als hij er klaar voor is — na een gesprek dat echt goed voelde in contact komt met een specialist. Niet na drie mislukte pogingen om langs een poortwachter te komen.

De echte vraag was nooit “hoe voegen we AI toe aan onze website?” De echte vraag is: waar creëert AI echt waarde die eerder niet mogelijk was? Dat zijn we gaan testen.

Waarom ik bouwde wat ik bouwde

Ik heb dit niet gebouwd omdat ik denk dat websites dood zijn, of omdat ik wilde kunnen zeggen dat we “iets met AI doen”. Ik heb eerder geschreven over hoeveel ik een hekel heb aan die mentaliteit.

Ik heb dit gebouwd vanwege een vraag die ik al meer dan een jaar toets: is conversationele AI er echt klaar voor om een echt kanaal te zijn?

In mijn Web 4.0-post schreef ik over het autonome web, een wereld waarin AI-assistenten niet alleen informatie ophalen, maar optreden als onafhankelijke digitale consumenten namens hun mensen. Waar Lisa tegen haar AI-assistent zegt “zoek een reis van twee weken naar Thailand” en de AI via MCP-interfaces contact opneemt met reisorganisaties, onderhandelt, verfijnt en opties presenteert. Zonder dat Lisa ook maar een browser opent.

Dat klinkt misschien alsof de mens uit het plaatje verdwijnt. Dat is niet zo. De techniek maakt volledige autonomie mogelijk. Maar dat betekent niet dat we de mens willen weghalen. Het betekent dat de klant mag kiezen. En onze default is en blijft: naar een mens leiden. Daar later meer over.

Die toekomst komt. Misschien niet morgen, maar hij komt. En als je een reisorganisatie bent die zichzelf serieus neemt, kun je er maar beter op voorbereid zijn.

Dus bouwde ik Joy, een AI-reisassistent voor 333travel. Niet als productlancering, niet als marketingstunt, maar als een serieuze test. Kunnen we een conversatie-interface bouwen die écht waarde toevoegt? Die onze producten begrijpt? Die minder hallucineert? Die een echt nuttige ervaring neerzet als extra kanaal naast onze website, telefoon en e-mail?

Ik heb dit niet gebouwd om onze website te vervangen. Ik heb dit gebouwd om een vraag te beantwoorden: kan een gesprek een betekenisvol kanaal zijn voor gepersonaliseerd reizen?

Wat het eigenlijk is

Laat me concreet zijn over wat Joy doet:

Joy zit bovenop onze volledige productdatabase. Elke rondreis, elk hotel, elke excursie, elke bestemming, allemaal als vectoren geëmbed in een eigen database. Als een klant zegt “ik wil iets avontuurlijks in Zuidoost-Azië, zo’n twee weken, niet te toeristisch,” dan gaat Joy niet keyword-matchen tegen een PDF. Ze doorzoekt semantisch honderden producten, rerankt de resultaten op werkelijke relevantie en komt met opties die echt aansluiten bij de intentie.

En ze onthoudt het gesprek. Niet alleen het laatste bericht, de hele thread. Ze weet welke reizen besproken zijn, wat bewaard is, wat verworpen. Als je zegt “die reis die je eerder noemde met de kookles,” snapt ze wat je bedoelt, ook al noemde ze het zelf een “culinaire ervaring.”

Maar hier zit het cruciale verschil met elke willekeurige chatbot: ze weet niet alleen iets van reizen in het algemeen. Ze kent ónze reizen. Onze specifieke producten. Onze specifieke reisschema’s. Onze bestemmingen die ons team zelf heeft bezocht. Dat kun je niet zomaar met een plugin erop plakken, hoe slim de LLM erachter ook is.

En op het moment dat je menselijk contact wilt? Dan geeft Joy de volledige context door aan een echte reisspecialist die precies weet wat je hebt verkend. Geen “kun je je vraag nog eens omschrijven.” Geen koude overdracht. Volledige continuïteit.

Joy vervangt gesprekken met specialisten niet. Ze maakt ze beter.

Wat ze (nog) niet doet: klantenservicevragen, luchtvaartinformatie of support na boeking afhandelen. Dit is puur een kanaal voor productontdekking en inspiratie. Daar komen we nog wel. Maar we gaan niet doen alsof ze dingen kan die ze niet kan. En eerlijk gezegd: als iemand bij de klantenservice terechtkomt, is er al een probleem. Dat is het slechtst denkbare moment om een machine tussen jou en je klant te zetten. Dan moet je er zelf zijn. Persoonlijk. Dus we zijn nog steeds aan het discussiëren over wat we haar daar laten doen. De nuance zit altijd in de details.

Waarom je hier niet komt met een plugin

Wat wij gebouwd hebben, bereik je niet door een plugin te installeren. Niet met ChatGPT. Niet met een of andere standaard “AI-widget.” Niet met een SaaS-tool die belooft “je website in minuten slimmer te maken.”

En dat komt niet doordat de AI-modellen niet goed genoeg zijn. De modellen zijn prima. Het probleem zit in alles eromheen.

Het hele systeem draait op data die wij zelf bezitten, structureren en beheersen. Elke reis in onze database is door ons eigen team bezocht. Elk reisschema is onze eigen creatie. Elk stuk bestemmingenkennis leeft in onze eigen systemen. Dit is geen data die we van een derde partij licentiëren of uit een brochurecatalogus trekken.

Dat betekent dat we het kunnen embedden. Dat we het precies zo kunnen structureren als we nodig hebben voor semantisch zoeken. Dat we het kunnen bijwerken op het moment dat er iets verandert. Wij beheersen de volledige pipeline, van ruwe productdata naar vector embedding naar retrieval naar antwoord.

Je kunt geen slimme interface bouwen bovenop bergen domme data.

Als je productdata in andermans systeem leeft, als je reizen uit een catalogus doorverkoopt, als je “database” een verzameling PDF’s van touroperators is, dan ben je afhankelijk van welke structuur iemand anders heeft bedacht. Je kunt geen intelligentie bouwen op data die je niet begrijpt of beheerst.

En veel bedrijven starten niet alleen vanaf nul, ze starten met een achterstand. Hun bestaande systemen zijn al onvoldoende. De booking engine is verouderd. De productdata ligt verspreid over spreadsheets en PDF’s. De customer journey heeft overal gaten. En in plaats van die fundamenten te fixen, vinden ze het slim om er een AI-chatbot bovenop te leggen. Alsof intelligentie bovenop disfunctie iets functioneels oplevert. Doet het niet. Het maakt de disfunctie alleen moeilijker te diagnosticeren.

Je lost geen probleem op. Je versiert het.

Wat wij gebouwd hebben, vereiste drie dingen:

Onze eigen data. Elke reis is van ons. Bezocht door ons team. Gestructureerd in onze database. Embedded in onze vector store. Je kunt geen semantic search bouwen over data die je niet zelf structureert.

Onze eigen systemen. Onze eigen backend, frontend, deployment pipeline. Toen we een dual reranker nodig hadden, bouwden we die. Toen we semantic conversation memory nodig hadden, bouwden we het. Toen we een MCP server nodig hadden voor Web 4.0-readiness, bouwden we die. Geen goedkeuring van een vendor nodig. Geen feature requests. Geen afhankelijkheid van andermans roadmap.

De hele keten in eigen hand. Van het moment dat een klant de chat opent tot het moment dat ze met een specialist praten, is elke stap van ons. De AI kent onze producten omdat we de producten zelf hebben gemaakt. De specialist kent het gesprek omdat ons systeem het aan hen doorgeeft.

De AI is de laatste 10% van het werk. De eerste 90% is een bedrijf bouwen dat het kan dragen.

In deel 2 laat ik zien hoe het onder de motorkap echt werkt. De architectuur, de search pipeline, het geheugensysteem dat vele pogingen kostte om goed te krijgen, en waarom 25 seconden wachten aanvoelt als 5 als je het goed ontwerpt.

Can a conversation be a travel channel? Part 2: The technical architectureThe technical deep-dive into how we built Joy: a RAG pipeline with vector search and reranking, a memory system that took four iterations, and the UI/UX decisions that make a 25-second response feel instant. All Subjects MatterRemco Loup.

Ik heb een “productie”-app gebouwd met vibecoding. 97.089 regels gegenereerd. Slechts 25.056 regels haalden productie. Vier complete refactors. De AI faalde niet door slechte prompts. Het faalde omdat AI dingen vergeet, context kwijtraakt en duplicaatlogica creëert, hoe goed je het ook stuurt. Vibecoding gaat er niet om AI voor je te laten bouwen. Het gaat erom dat je je systeem goed genoeg kent om de ruis te filteren. Zonder die kennis ship je alleen maar gissingen.

Wat vibecoding eigenlijk betekent

Mensen denken dat vibecoding betekent dat AI je app bouwt terwijl jij toekijkt. Reality check: dat is helemaal niet het geval als je een daadwerkelijk werkend product nodig hebt met elke keer het verwachte resultaat.

Vibecoding betekent nog steeds dat jij de controle hebt. Je prompt met precisie. Je experimenteert. Je stuurt. Je filtert. Het blijft handwerk, alleen met andere hefboomwerking.

“A fool with a tool is still a fool”

En als je niet weet wat je doet? Dan is het resultaat hetzelfde als altijd: een zooitje. Vibecoding zonder de juiste kennis is gewoon fout. En het grootste probleem met AI is dat het maar blijft produceren: code na code na code. Het doet gewoon wat je vraagt. Het is daar niet kritisch over. Dus als je niet weet wat je doet, spreek je jezelf de hele tijd tegen met geprogrammeerde functionaliteit die nooit samenwerkt binnen je app.

AI is koning in fallbacks. Ik had voor elke mislukte API-call 5 verschillende fallbacks gekregen. Zouden we niet gewoon de juiste manier aan de praat moeten krijgen in plaats van fallbacks bouwen? AI is ook lui: het onderdrukt liever notices dan dat het ze oplost. Zeker als het niet in één keer lukt.

Ik bouwde een productie-app met AI (maar niet dankzij AI)

Ik heb Windsurf gebruikt om een complete applicatie te bouwen. Geen menselijke developers. Geen code die ik direct heb geschreven. We gebruiken Sonnet 4.5 als onze kennisbron.

Het resultaat na veel frustratie: een volwaardig productiespel met backend-logica, login-flows, async data writes, mail queues, admin security, monitoring en cartesische algoritmes die updaten op basis van gebruikersinteractie.

De AI heeft alles geschreven. Ik heb geen enkele regel code aangeraakt. Zelfs de simpelste CSS-wijziging liet ik aan AI over.

Maar wat niemand je vertelt: ik heb het hele project vier keer compleet moeten refactoren. En niet omdat ik slecht promptte. Ik gebruikte KISS-principes, DRY-standaarden, PSR-richtlijnen. We schreven vooraf beslissingen uit en maakten implementatiedocumenten. We gebruikten richtlijnen voor de talen die we gebruikten.

Uiteindelijk maakte het niets uit.

AI vergeet. Het verliest context. Het begint duplicaatfuncties te maken zonder door te hebben dat het die logica al drie files terug schreef. Hoe complexer je project wordt, hoe meer het afdrijft. En hoe vaker het niet in één keer goed gaat, hoe meer AI denkt backwards compatibility te moeten handhaven, waardoor je code nog complexer wordt. Het maakt niet uit hoe je het de eerste keer prompt, of met project rules.

Na vier complete refactors leerde ik: AI vergeet de context niet. Het heeft die nooit gehad ;).

De enige reden dat de definitieve versie werkt, is dat ik precies wist wat ik aan het bouwen was. Ik had het systeem in mijn hoofd. Ik zag wanneer AI zichzelf herhaalde. Ik wist wanneer ik moest stoppen, bijsturen of opnieuw beginnen. Ik controleerde elke file op duplicaat fallback-data, duplicaten enzovoort. Ik gebruikte ook het zeer handige npm-package knip.

https://www.npmjs.com/package/knip

Je kunt niet iets de productie in vibecoden zonder je product te begrijpen. Punt. En je moet accepteren dat bugfixen betekent dat je op AI leunt om het op te lossen zonder iets anders te breken. Veel succes daarmee…

De data vertelt de rest van ons verhaal

Tijdens ons vibecoden produceerde Windsurf:

• 97.089 regels code gegenereerd
• 2.925 prompts verstuurd
• 5.693 credits gebruikt
• 15.734 tool calls (waaronder 7.000 code-edits)

Wat er daadwerkelijk in productie is gegaan:

• 25.056 regels code

Meer dan 70.000 regels zijn geschrapt, vervangen of gerefactord.

Nu denk je misschien: dan moet je AI dus gewoon “beter sturen” of “preciezer prompten”. Dat is niet het punt dat ik wilde maken.

Het punt is: je kunt AI-gebral op dit moment niet voorkomen. Hoe goed je ook prompt. Hoe gestructureerd je aanpak ook is. AI overproduceert. Het genereert redundante code. Het raakt de tel kwijt van wat het al gebouwd heeft. Het creëert ruis. AI is gebouwd om altijd een vorm van AI-verbaal diarree te produceren.

Die 70k+ regels verspilde output? Dat is geen bug. Dat is de huidige staat van vibecoding.

En als je je systeem niet goed genoeg kent om te herkennen wat troep is en wat niet, ship je alles en kun je zelfs met AI niet meer debuggen. Of erger: je besteedt persoonlijk weken aan het debuggen van een codebase die je niet snapt.

De kosten per 1000 credits liggen rond de 35 dollar. De ontwikkeling van dit spel kostte me 210 dollar. Elk bedrijf dat Large Language Models levert verliest geld. De code die ik produceerde had makkelijk 210 x 10 = 2.100 dollar moeten kosten, minimaal. Ik vraag me af of ze dan überhaupt geld verdiend hadden.

Los van het geld: is dit onze kostbare elektriciteit echt waard? Ik ben benieuwd hoe haalbaar dit is als je de echte prijs betaalt.

Wat mensen verkeerd begrijpen

AI is geen magie. Het is een “slimme”, snelle assistent. Maar hij begrijpt niet wat er voor jouw bedrijf telt. Hij heeft geen grip op edge cases, constraints, risico’s, performance-implicaties of security-kwetsbaarheden.

Dat is jouw werk!

In mijn geval hielp AI om iets echts te bouwen. Maar de AI beveiligde het adminpaneel niet. Die mail queue-logica ontwierp hij niet. Hij besliste niet wanneer async writes gedebounced moesten worden. Dat deed ik. Door kritisch te zijn en de juiste vragen te stellen dankzij bouwervaring van vroeger.

Zonder die richting was het hele ding in elkaar gestort.

En ik zie dit patroon overal. Teams die AI-producten bouwen zonder ownership of richting, alleen maar om te kunnen zeggen dat ze “iets met AI gedaan hebben”. Dat is oppervlakkig. Dat is broos. Het schaalt niet.

“You’re not building products. You’re laundering prompts into deployments”

Hoe vaak hoor je niet van bovenaf: we moeten iets met AI doen. We raken achter. Achter op wat?

De customer service-val

Dan is er nog de hype rond AI voor klantenservice. Bedrijven beweren dat het perfect is voor 24/7 support, snellere antwoorden, minder mensen nodig.

Maar als je een bot nodig hebt om met je klanten te praten, ligt je echte probleem waarschijnlijk ergens anders. AI repareert kapotte processen niet. Het verstopt ze. Tijdelijk.

Als je minder menselijk contact als winst ziet, heb je al verloren. Als het beantwoorden van vragen lang duurt, moet je misschien ergens anders kijken waarom mensen zoveel vragen hebben, en dat eerst verbeteren.

Het eigenlijke punt

Vibecoding is gewoon weer een tool. Meer niet. Wel een heel give tool in de juiste handen, maar toch een tool. En vooral goed voor prototyping. Maar met een flinke dosis kennis kun je er misschien standalone apps mee bouwen die écht werken, die je op z’n minst zelf kunt testen en waarvan het resultaat op een transparante manier te herleiden is naar de geschreven code.

Het vervangt geen denken. Het zou je denken moeten versterken, en het zou je niet minder moeten laten nadenken.

Goed gebruikt kan het krachtig zijn. Maar je moet nog steeds weten wat je wilt bouwen. Je moet de structuur ownen. Je moet de ruis filteren. Je moet AI-geklets herkennen als je het ziet. Je moet het proces leiden.

Anders bouw je geen prototype. Dan genereer je alleen gokken.

De toekomst is niet AI-first. De bedrijven die ertoe doen blijven human-first. Zij begrijpen het probleem voordat ze een tool kiezen. En ze blijven de enige vraag stellen die telt, voordat ze AI te hulp roepen:

Wat lossen we nu eigenlijk op?

Hier de link naar het originele artikel via de Wayback Machine: door corona en de overname van flow.ai door Khoros is deze blog niet meer publiek beschikbaar. Deze blog is geschreven in Q3 van 2019.

https://web.archive.org/web/20201020201705/https://flow.ai/blog/how-333travel-is-revolutionizing-the-travel-industry

Helaas hebben we ervoor gekozen om Joy begin 2022 te stoppen, vanwege gebrek aan resultaat en omdat corona ons hard raakte. De klantbetrokkenheid was te laag om het in stand te houden, helaas.

Artificial intelligence (AI) om buiten openingstijden op een persoonlijke manier in contact te blijven. Dat is waar 333travel hun chatbot Joy voor gebruikt.

De reisbranche is een innovatieve markt. De concurrentie is groot en de drang naar een technologisch voordeel ook, maar dat is lastig. Wie zich in deze markt niet technisch zelfstandig onderscheidt, wordt al snel door de massa opgeslokt en kan niet meer uniek zijn in zijn propositie. Daarmee komt je bestaansrecht in gevaar.

We zoeken constant naar manieren om onze positie op de markt te verbeteren en vertalen elke dag IT op de juiste manier naar de business, zodat IT echt voor ons werkt. Blijf experimenteren en blijf nieuwe dingen proberen!

Onze uitdaging

We zoeken altijd naar manieren om onze klanten beter van dienst te zijn, en dat willen we op een persoonlijke manier doen. Zo bouwen we echt een relatie op met onze klanten en bieden we volledig op maat gemaakte oplossingen.

We zijn ervan overtuigd dat je bij een reis met ons de best mogelijke beleving van genot krijgt, want bij 333travel denken we met je mee van A tot Z en ontzorgen we je volledig.

…Met behulp van Joy heeft de klant sneller een antwoord en kunnen we meer kwaliteit bieden, omdat Joy indirect zorgt voor minder werk en meer beschikbare informatie voordat er een persoonlijk contactmoment plaatsvindt…

Het inzetten van artificial intelligence klinkt daardoor misschien tegenstrijdig, maar dat is het zeker niet. We gaan deze AI natuurlijk allereerst gebruiken om onze klanten de bestaande informatie / FAQ op onze website te geven als ze daar vragen over hebben.

Maar naast het verstrekken van informatie zullen we altijd proberen door te sturen naar persoonlijk contact. Het is voor ons belangrijk om fysiek in contact te komen met onze potentiële klanten, op een persoonlijke, makkelijke en toegankelijke manier.

Ons doel

Het geautomatiseerd verzamelen van leads op een zo persoonlijk mogelijke manier is dus onze reden om deze artificial intelligence in te zetten. De rest is een bonus. We streven er zelfs naar om via deze AI juist méér persoonlijk contact te realiseren. De focus ligt op het creëren van waarde en het optimaliseren van onze customer journey buiten onze reguliere werktijden.

Onze oplossing

Samen met Flow.ai zijn we gaan testen op welke persoonlijke manieren we een klant zover kunnen krijgen dat die contact met ons opneemt.

Een juiste use case van AI is hierbij heel belangrijk, maar ook de manier waarop je deze AI kunt trainen. We wilden de meest natuurlijke vorm van interactie creëren, maar we moeten werken met niet-sexy data zoals “departure”- en “arrival”-data om vooraf een beeld te krijgen van wanneer iemand op vakantie wil. Dat is een grotere uitdaging dan het lijkt.

We wilden absoluut voorkomen dat onze AI het niet direct begrijpt als iemand zegt: “I want to visit Thailand on June 17 for 1 week”.

Een natuurlijke interactie met de juiste intent

We hebben onze LLM daarom zo getraind dat hij intents begrijpt met kennis van wat de vertrekdatum is en wanneer je wilt vertrekken. Het is dus geen absoluut feit wat we van je willen weten, maar een waarde die binnen de betekenis van “wanneer wil je vertrekken” valt. Er zijn zoveel verschillende, maar ook correcte antwoorden op deze vraag. En als je onze eisen meeneemt, moet deze bot ook alles hieronder en meer begrijpen:

• In de zomer wil ik in de vakantie…
• In de winter wil ik graag verblijven in…
• In het najaar wil ik naar…
• Ik wil met kerst in Thailand zitten…
• Volgend jaar willen we naar…

Het wordt direct onvriendelijk als er na deze vraag alsnog een datumveld ingevuld moet worden met wanneer je wilt vertrekken. Of erger nog: als de bot de vraag helemaal niet begrijpt. Een klant weet bovendien vaak zelf niet precies wanneer hij wil vertrekken. Als hij zo begint, moet hij die informatie dan verplicht invullen? Je hebt bij dit type klant één kans.

Klanten zijn de niet-werkende chatbots van grote bedrijven, die FTE willen besparen en willen zien hoe ver ze kunnen gaan in het pesten van hun klanten, spuugzat.

We leggen de kerninformatie van de verwachte vertrekperiode automatisch direct vast. Die wordt immers tijdens het contactmoment verder uitgediept; voor nu weten onze specialisten wat de intent is en kunnen ze daarop inspelen.

Binnen onze implementatie is het ook mogelijk om alle variabelen die we nodig hebben uit één zin van een klant te halen. Daarna hebben we alleen de contactgegevens nodig en bellen we op het gevraagde tijdstip en de gevraagde datum.

Data verzamelen

“Goedemiddag, ik zoek een vakantie die begint in Indonesië en eindigt op Bali voor 2 volwassenen en 2 kinderen met een hotel aan het strand, vertrek op 21 juli en weer thuis op 3 augustus.”

De zin hierboven is een praktisch voorbeeld van wat Joy begrijpt. We leggen deze waarden vast en weten dan meteen dat er genoeg data is. We vragen alleen nog het telefoonnummer/e-mailadres van de klant en bellen hem op een door hemzelf aangegeven moment.

We bellen je op het door jou gewenste moment. We hebben er bewust voor gekozen om de klant geen date picker te laten gebruiken, om de natuurlijke flow te behouden. Voor de klant is het makkelijker om te zeggen: “donderdag over een week om 10 uur”. Daaruit begrijpen we wat de intentie is en bellen we die klant precies op dat moment. Er zijn ook genoeg klanten die zeggen dat ze nú gebeld willen worden. Of ze op dat moment gebeld kunnen worden of niet, ze vallen af zodra ze een date picker voorgeschoteld krijgen. Zeker als de dag van vandaag ontbreekt.

Omdat de klant onze website bezoekt, weten we ook vanaf welke pagina zijn verzoek om persoonlijk contact binnenkomt. Zo hebben onze specialisten nog meer informatie om een beeld te krijgen van wat de intentie is.

Deze data wordt automatisch als lead/voorstel verstuurd naar ons backoffice-systeem BOSS. En elke opvolging van deze lead wordt daar vastgelegd.

Resultaat: Joy ziet het levenslicht.

Na een groot aantal interne tests, diverse finetuning-aanpassingen en het gebruik van verschillende methoden om ons doel te bereiken, is Joy geboren. We hebben haar ook een persoonlijk gezicht gegeven, omdat we de gesprekken persoonlijk willen houden. We geven natuurlijk wel aan dat Joy een “Virtual Travel Assistant” is. Onze echte collega’s blijven de reisspecialisten.

…Wat vooral opvalt aan de resultaten is dat de interacties en verzoeken die via Joy binnenkomen meestal afkomstig zijn van mensen tussen de 20 en 35 jaar…

Belangrijke lessen

De belangrijkste les hierin is misschien een beetje een open deur, maar zorg dat je doel op papier staat, en begin met de simpelste implementatie van dat doel en ontwikkel dat langzaam tot een complexer werkend eindproduct.

We zijn eerst gaan kijken hoe we onze benodigde data kunnen verzamelen met Flow.ai en hoe dat echt werkt. Daarna hebben we veel verschillende scenario’s getest en zijn we langzaam richting één complete flow gegaan die het beste van meerdere flows combineerde. Zo kregen we meteen veel ervaring met de verschillende opties die Flow bood.

We worden hierbij goed ondersteund door Flow.ai, maar door onze eigen kennis in huis hadden we de support niet constant nodig en konden we echt diep op het onderwerp ingaan.

Het flow.ai-systeem is goed opgebouwd, heel logisch en begrijpelijk. Dat zou je er niet van moeten weerhouden om te experimenteren.

De toekomst

Het eerste kwartaal is onze drukste periode. Omdat we Joy relatief kort voor deze periode hebben geïmplementeerd, hebben we de optie Live Chat nog niet geactiveerd. Dat gaan we na dit kwartaal doen.

Daarnaast willen we in de nabije toekomst nog verder gaan met Joy en haar dé assistent van ons klantportaal maken, die je op weg helpt nadat je een boeking hebt gemaakt. Als Joy het antwoord niet weet, kom je meteen in contact met de specialist bij wie je de reis hebt geboekt. Heb je vragen tijdens je reis? Vraag het Joy. Heb je problemen tijdens je reis? Joy zorgt ervoor dat je zo snel mogelijk een antwoord krijgt en dat je indien nodig direct contact met ons krijgt.

We zien Joy als onze “Virtual Travel Assistant”, waarbij de heel specifieke kennis van onze bestemmingen en onze kennis van maatwerk bij onze reisspecialisten blijft, want dat is de kracht van ons persoonlijke contact waarmee wij persoonlijk het verschil maken, binnen onze filosofie.

Introductie

Ik schrijf deze introductie omdat ik wil uitleggen waarom ik ChatGPT gebruik en waarvoor. In het begin was ik een beetje sceptisch over wat ChatGPT was. Voor mij leek het meer een soort fantasie.

Maar dat geldt alleen als je vragen stelt waar je zelf weinig kennis van hebt. Daar moeten we heel voorzichtig mee zijn, want je weet niet wanneer het dingen verzint. En ook: de juiste soort vragen stellen helpt ChatGPT om niet zelf dingen te verzinnen.

Praktische voorbeelden

In ons werk hebben we het bijvoorbeeld getest om introductieteksten te schrijven voor een hotel dat we hadden. ChatGPT verzon van alles, over zwembaden die er zouden zijn en dat soort dingen. Dat hotel heeft helemaal geen zwembad.

Dus daar is het niet nuttig. Maar over onderwerpen waar je wél verstand van hebt, is het juist wél nuttig. Je kunt de juiste vragen stellen en dan maakt het een tekst die meestal voor minstens 75% bruikbaar is. Dat scheelt tijd.

ChatGPT is voor taal wat de rekenmachine was voor wiskunde.

ChatGPT gaat ons leven een stuk makkelijker maken door informatie te leveren over onderwerpen waar je over wilt schrijven en al kennis van hebt.

ChatGPT en AllSubjectsMatter

Op deze website gebruik ik ChatGPT om mijn grammatica en zinsopbouw te corrigeren. Ik ben een geboren Nederlander. En ik zou graag willen opscheppen dat ik vroeger zo goed was in mijn Engelse lessen. Ik deed op school nooit huiswerk, maar haalde toch negens en tienen.

Ik moet nu toegeven dat dat allemaal flink verroest is. Vooral omdat ik jarenlang niet regelmatig in het Engels heb geschreven, tot nu toe. Dus op dit moment helpt het me om beter leesbare Engelse teksten te schrijven.

Dit produceerde ChatGPT van de bovenstaande regels.

I use ChatGPT to correct my grammar and sentence flow, as I am a native Dutch speaker. I would like to brag that I used to excel in my English classes, never completing any homework but still receiving 9’s and 10’s. However, I must admit that my English has become quite rusty since I haven’t written in the language regularly for years. Currently, ChatGPT is helping me improve my ability to write more readable English texts.

En dit is dezelfde tekst nadat ik hem heb gecorrigeerd met Hemingway

I use ChatGPT to correct my grammar and sentence flow, as I am a native Dutch speaker. I would like to brag that I used to excel in my English classes.

I never did any homework but still received 9’s and 10’s in school. But I must admit that my English has become quite rusty since I haven’t written in the language often for years. For now ChatGPT is helping me improve my ability to write more readable English texts.

Het origineel is voor mij al niet slecht, maar dit is gewoon een voorbeeld van wat je kunt doen met tools die helpen bij leesbaarheid.

Wat is Hemingway?

Hemingway is een visuele editor voor leesbaarheid die je kan helpen om zinnen te vereenvoudigen. Ik gebruik dit de hele tijd om al mijn Engelse teksten te controleren op leesbaarheid. Dit helpt ook om je teksten makkelijker leesbaar te maken.

Conclusie

Ik gebruik een van deze twee tools om beter Engels te proberen te schrijven. Soms gebruik ik ze allebei. Hier kan ChatGPT echt schitteren: je schrijven verbeteren. Door ChatGPT te gebruiken begon ik meteen helderder en simpeler te leren schrijven.

Hopelijk is er dus steeds minder te corrigeren wanneer ik een tekst door Hemingway of ChatGPT haal. Dat komt omdat je zelf ook leert door je teksten door deze tools te halen.

Ik vind het niets om ChatGPT mijn posts volledig te laten schrijven en ze om te buigen tot iets dat “mij” vertegenwoordigt, want dat voelt voor mij niet goed. Het idee moet van mij komen en ik gebruik ChatGPT soms om het te polijsten. En niet andersom.