In Part 1, I wrote about why we built an AI travel interface from scratch, what we learned from our first failed attempt in 2019, and why a plugin can never get you to a fully integrated conversational experience. This part is the how. The architecture, the search pipeline, the memory problem that took four attempts to solve, and the UI/UX work that makes 25 seconds feel like 5.

The architecture

Since this is a tech blog and not a marketing page, let me show you what’s actually running. This isn’t a weekend project. This is production infrastructure.

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

The frontend is a React application with real-time WebSocket communication. No polling. No request-response cycles where you wait for a full answer. Every token streams in real-time, buffered at 50ms intervals to prevent UI flicker. Product results push to the interface the moment they’re found, before the LLM even starts composing its response.

The backend is Python/FastAPI with a modular tool system. The LLM doesn’t just generate text. It has access to 9 specialized tools and decides autonomously which ones to use. Need to search trips? It calls search_products. Need destination information? It calls search_knowledge. Need to recall what was discussed earlier? It queries conversation memory semantically.

The LLM isn’t generating answers. It’s orchestrating tools and composing a response from real data.

The LLM layer runs with a multi-provider fallback system. If the primary provider goes down, the system automatically switches to the secondary. No downtime. No errors. The customer never notices.

And there’s already an MCP server running, the protocol I described in my Web 4.0 post. External AI assistants can already query our travel data through it. It’s early days, but the infrastructure for AI-to-business communication is live. When Lisa’s AI assistant wants to search 333travel’s products, the endpoint already exists.

The RAG pipeline: where the real work happens

RAG, Retrieval-Augmented Generation, is the backbone of the entire system. It’s what separates “GPT with a knowledge base” from “an AI that actually knows your product.” But RAG done poorly is almost worse than no RAG at all.

We maintain three separate vector collections:

When a customer asks something, the query gets embedded and thrown against the relevant collection. But here’s the critical part: we don’t just take the top vector matches and call it a day.

Vector similarity alone is mediocre. It gets you in the right ballpark, but it doesn’t get you the best results. So we do a broad fetch, significantly more results than we need, and then run them through a reranker. The reranker evaluates each query-document pair for actual semantic relevance, not just embedding proximity.

The difference is enormous. It’s the difference between “here are trips that contain some of the words you used” and “here are trips that actually match what you’re looking for.”

But it goes further than that. Before the query even hits the vector database, it runs through a fuzzy normalization layer. Every country and location name in our system is cached at startup. When a customer types “Bali” we know they mean Indonesia. When they write “Tailand” we know what they meant. Aliases, spelling variations, language differences, all resolved before the search begins. Without this, you get empty results for queries that should have matched. And on top of that, the search combines semantic similarity with metadata filters. Country, duration, product type, these aren’t just fields in a database. They’re active filters that work together with the vector search to narrow results before the reranker even starts.

After reranking, the results split into two paths. The full set of reranked results pushes to the frontend immediately, but blurred. The customer sees product cards appearing while Joy is still thinking. It signals progress without overwhelming. Meanwhile, the LLM gets a stripped-down version of those results, only the fields it needs to reason about. This projection saves roughly a third of the tokens, which means faster responses and lower costs. Then Joy composes her answer and discusses the 4 or 5 trips that genuinely fit the question. Only those discussed products become visible to the customer. The rest disappear. What the customer sees is a curated, considered selection. Not a list of 10 search results. A recommendation of 5 that actually make sense.

Broad fetch → Rerank → Project. Three steps that make the difference between a search result and a recommendation.

The memory problem

This is the part that took the most iterations to get right.

Conversational AI has a dirty secret: it doesn’t remember anything. Every LLM call is stateless. The model has no idea what was said before unless you explicitly feed it the context. And there’s a limit to how much context you can feed.

For a simple Q&A chatbot, this doesn’t matter. Someone asks a question, gets an answer, done.

But for a travel assistant? Memory is everything.

A customer says: “I want to go to Thailand for two weeks.” Three turns later: “Actually, make it three weeks. And I want to include Laos.” Five turns later: “What was that trip you showed me earlier with the cooking class?”

Without memory, every turn is a blank slate. The system doesn’t know about Thailand. Doesn’t know about the three-week change. Doesn’t know about Laos. Definitely doesn’t know about the cooking class trip from seven messages ago.

Without memory, every message is a first date. Your AI has no idea what happened before.

This wasn’t solved in one attempt. Not in two. Not even in three.

The first version was simple: feed the last 10 question-answer pairs into the LLM context. It worked for short conversations. But our conversations aren’t short. Customers explore, compare, come back to earlier ideas, change their mind. Ten turns isn’t enough when someone has been chatting for twenty minutes about three different countries.

So we tried generating summaries in the background. The idea was sound: condense the conversation into key points so the LLM always has the full picture without eating up the entire context window. The reality was different. The LLM started hallucinating details into the summaries. Mixing up countries. Attributing preferences the customer never mentioned. The summary was supposed to be the source of truth, and it was making things up.

Then we designed a three-stage memory system: short-term, ephemeral, and long-term. The ephemeral layer was supposed to track which topics belonged to which destination, which preferences applied to which part of the trip. On paper, elegant. In practice, a nightmare. It required the AI to understand complex relational context, like “when they said budget was flexible, they meant for Thailand, not for Vietnam.” It couldn’t. Too many edge cases. Too fragile.

What we landed on was simpler and more robust. Every message gets embedded as a vector in a dedicated memory collection in the same database we use for product search. When the customer says “that trip with the cooking class,” the system runs a semantic search across all past messages in that session. It finds the relevant message even if the exact words don’t match. Maybe Joy called it a “culinary experience” three turns ago. Vector search doesn’t care about word matching. It matches meaning. Combined with the last 10 exchanges in the prompt for immediate context, Joy doesn’t need to make that tool call for every question. She has the recent conversation right there, and the full history searchable when she needs it.

Four attempts. Each one taught us something about what AI can and can’t do with context. The final version works not because it’s the smartest design, but because it’s the most honest about the limitations.

AI memory isn’t one problem. It’s two: recalling what was said, and understanding what was meant. We needed two different systems to solve them.

UI/UX: the invisible work

Here’s where most AI projects die, and they don’t even realize it.

You can have the most sophisticated RAG pipeline in the world. The smartest retrieval. The best reranking. But if the interface feels clunky, slow, or confusing, none of it matters. The customer doesn’t care about your architecture. They care about how it feels.

If your AI is smart but your interface is slow, you built a genius locked in a closet.

We went deep on this. And “deep” means dozens of iterations on things most people would consider details. But details are the product.

Streaming that feels natural. LLM responses stream token by token over WebSocket. But raw streaming creates flickering text that’s jittery and unpleasant. We buffer at 50ms intervals. Fast enough to feel real-time, slow enough to prevent constant re-renders. The difference is subtle but massive in terms of perceived quality.

The speed tradeoff. Let’s be honest about something: a product search with a full answer takes 20 to 30 seconds. That’s long. We know it’s long. But we made a deliberate choice: quality over speed. The broad fetch, the reranking, the semantic matching, every step in the pipeline exists because it makes the results better. Cut any of them and you get faster responses with worse recommendations. We’d rather have Joy work for 25 seconds and deliver 5 trips that genuinely fit than return 10 mediocre matches in 8 seconds.

So the question became: how do we make 25 seconds not feel like 25 seconds? That’s where the UX work came in. Joy shows what she’s doing. Searching products. Looking up destination information. Checking conversation history. Every tool call is visible as it happens. Product cards push in blurred while she’s still composing her answer. Once the answer is ready, only the trips Joy actually discusses become visible. The rest fade away. The customer never stares at a blank screen. They see the process unfold. And it turns out that watching something work feels completely different from waiting for something to finish.

Part of the latency is also a language problem. Dutch is poorly represented in most embedding and language models. The semantic understanding that works beautifully in English degrades when your customers and your product data are in Dutch. It means more processing, more careful matching, more effort to get the same level of quality.

What is GPT-NL? GPT-NL is a Dutch initiative to build a large language model specifically trained on and optimized for the Dutch language.

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

Where current models like GPT and Claude treat Dutch as a non existent language, GPT-NL aims to make Dutch a first-class citizen in AI. For applications like ours, where both the customer and the product data are Dutch, a model that truly understands the language could significantly improve semantic search quality and reduce the processing overhead we currently need to compensate for that gap. We’re watching this project closely.

And then there’s model selection. The quality of the conversation depends heavily on which LLM you use. We run on Sonnet 4.6 as our primary, and the difference with smaller or cheaper models is not subtle. It’s the difference between a conversation that feels natural and one that feels scripted. Haiku, the faster and cheaper option, feels like a downgrade the moment you switch. GPT serves as our automatic fallback, but it’s a step back in conversational quality. These aren’t interchangeable commodities. The model you choose defines the experience your customer gets.

Instant page loads. The entire conversation persists in local storage. When you refresh the page or come back later, your conversation is already there. Instantly. No loading spinner. No “reconnecting…” message. The sync with the server happens silently in the background.

Markdown normalization. LLMs have opinions about formatting. Claude loves bold headers with emoji. GPT loves numbered lists. We normalize everything server-side. Bold-with-emoji gets converted to clean headers. Horizontal rules get stripped. Font weights get tuned down. The result looks like it was designed, not generated. The customer should never feel like they’re reading AI output.

Session continuity. Your session survives across page refreshes, browser closes, and reconnections. Come back a day later, your conversation is still there. Your saved trips are still there. And if a session does expire, you get a clean overlay explaining what happened, not a broken page or a cryptic error.

The lead flow. When a customer is ready to talk to a specialist, the system generates a travel proposal pre-filled with what it already knows from the conversation. Destinations discussed, trip preferences, products explored. Minimal friction. Maximum context. The human specialist picks up exactly where Joy left off. That’s not a handoff. That’s the whole point. Joy exists to make that human conversation better, not to avoid it.

Every one of these details took multiple iterations. Every one of them is invisible to the customer. That’s the point.

Security: an honest note

I’ll keep this section brief and honest. Security isn’t something you finish. It’s something you work on constantly.

We have a dual guard system. An input guard before the LLM that catches prompt injection attempts, and an output guard after the LLM that catches credential leaks or system prompt fragments in responses. Both are deterministic and add virtually zero latency.

The system prompt is hardened with anti-jailbreak instructions. There’s rate limiting, bot protection, and IP management for persistent abuse.

Is it bulletproof? No. Nothing is. But it’s built with defense in depth in mind, and we iterate on it as new attack patterns emerge. If you’re building any AI interface that talks to the public and you haven’t thought about input/output guards, you have a problem waiting to happen.

The bigger picture: an extra channel, not a replacement

Let me be very clear about what Joy is and what she isn’t.

Joy is not a replacement for our website. She’s not a replacement for phone or email. She’s an additional channel. A new way for customers to explore our products, alongside everything that already exists. She will never be a replacement for human contact. We value that the most in our company. Joy is a means to human contact. She helps customers figure out what they want, so that when they talk to one of our specialists, that conversation starts at a completely different level.

Joy isn’t the destination. She’s the road that leads to a real conversation with a real person.

The MCP server is already live, which means AI assistants can already query our data programmatically. When the Web 4.0 vision materializes, when Lisa’s AI assistant autonomously searches for her perfect Thailand trip, the endpoint already exists. Not because we scrambled to build it. Because we’ve been exploring this infrastructure for over a year.

Joy isn’t the end product. She’s the beginning of a channel strategy that includes both human-to-AI and AI-to-AI interactions. And she’s a test, a very serious, very thorough test, of whether conversational AI can actually add value for travel customers today.

The results so far have been better than I expected. Not flawless, nothing is, but genuinely impressive in how natural the conversations feel and how relevant the recommendations are. When you see a customer describe a vague idea and Joy comes back with trips that actually fit, you realize this isn’t a gimmick. It works. And it works because of everything underneath it.

So, what are we trying to solve again?

I opened with this question because it’s the one that guided everything we built. Not “how do we use AI?” Not “what’s our competitors doing?” Not “how do we look innovative?”

Just: what problem are we solving, and does this solution actually work?

We built Joy to find out. With real architecture. Real data. Real customers. And the willingness to say “it’s not ready yet” if that turned out to be the case.

If you’re thinking about adding AI to your product, start there. Not with the tool. Not with the vendor pitch. Not with the pressure to keep up.

Start with the question. Build from the answer.

Your customers deserve better than a FAQ with a face. They deserve a real conversation. And eventually, a real person. Make sure your AI leads them there, not away from it.

If you haven’t read Part 1, that’s where the story starts: why we built this, what we learned from failing at it in 2019, and why you can’t get here with a 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 built an AI-powered travel interface from scratch. Not a chatbot. Not a widget. Not a GPT-wrapper with a smiley face bolted onto a website. A full conversational interface with its own vector database, its own retrieval pipeline, its own memory system, and real-time streaming over WebSockets. Not to replace anything. To test whether conversational AI is actually ready to be a meaningful channel for travel. Here’s what we found, what it took, and why we think most of what’s out there right now is noise.

This is a two-part story. This first part covers the why: what problem we’re solving, what we learned from failing at this before, and why a plugin will never get you here. Part 2 goes deeper on the architecture: the RAG pipeline, the memory system, the UI/UX decisions, and the technical tradeoffs we made.

What are you actually trying to solve?

That’s the question I keep coming back to. Every time I see a company announce their new “AI-powered” feature. Every time someone asks me what we’re doing with AI. Every time a vendor pitches yet another plugin.

It’s the most important question in tech right now. And almost nobody is asking it.

Instead, the entire industry is working backwards: starting with “we need to do something with AI” and then looking for a place to put it. Companies hear “AI” and they hear “innovation” and they think they’re falling behind if they don’t do something right now.

The pressure to “do something with AI” has become louder than the question of what are you trying to achieve.

And so what happens? Companies reach for the most visible, most marketable application they can find: a chatbot. Slap it on the website. Give it a name and a friendly face. Connect it to a knowledge base. Done. “We do AI now.”

Here’s the problem: the integration is always limited. Some connect to a product database. Some pull live availability. But as a plugin, there’s a ceiling to how deep that integration goes. It’s always working with whatever data it gets access to, in whatever format the API provides, with whatever context the vendor decided was enough. The result is an interaction that looks conversational on the surface but is fundamentally constrained in what it can actually do.

And because it’s a plugin, it can never be fully seamless. It will always be a separate layer on top of your website, not part of it. A different design language. A different interaction model. A different experience. The customer feels it, even if they can’t articulate it. It’s the difference between a room that was designed as a whole and a room where someone placed a kiosk in the corner.

A smarter gatekeeper is still a gatekeeper. Your customers wanted a door.

We’ve been down this road ourselves. Back in 2019, we built the first version of Joy on Flow.ai. An intent-based chatbot that could understand natural language, extract travel preferences from a single sentence, and generate leads for our specialists. It worked. Technically. But customer engagement was too low to justify keeping it alive. We retired Joy in early 2022.

The lesson wasn’t that the technology was bad. The lesson was that people have learned to distrust chatbots. And rightfully so. For years, companies have used chatbots as a barrier to contact, even when they claim otherwise. Customers know this. They’ve experienced it. After three wrong answers, you don’t think “let me try again.” You think “how do I get to a real person?” Some people don’t even bother engaging. They see a chat bubble with a face and their immediate reaction is to close it. Not because they’re impatient, but because experience taught them it’s a waste of time.

That’s not a technology problem. That’s a trust problem. And it’s one you can’t solve by making the same format smarter.

On top of that, the interface of a chatbot plugin is simply limiting. A small window in the corner of your screen. A few lines of text. Maybe a button or two. You can’t show rich product cards in that. You can’t display a map of a trip. You can’t let someone browse, compare, save trips for later. The format dictates the experience, and the format is a box.

That experience is exactly why we didn’t build another chatbot. Not a smarter one. Not a better one. Something fundamentally different. A full conversational interface, built from scratch, designed to inspire. Where someone can explore destinations, discover trips they didn’t know existed, and when they’re ready, transition into contact with a specialist after a conversation that actually felt good. Not after three failed attempts to get past a gatekeeper.

The real question was never “how do we add AI to our website?” The real question is: where does AI genuinely create value that wasn’t possible before? That’s what we set out to test.

Why I built what I built

I didn’t build this because I think websites are dead or because I wanted to say we “do something with AI.” I’ve written before about how much I despise that mentality.

I built this because of a question I’ve been testing for over a year now: is conversational AI truly ready to be a real channel?

In my Web 4.0 post, I wrote about the autonomous web, a world where AI assistants don’t just retrieve information but act as independent digital consumers on behalf of their humans. Where Lisa tells her AI assistant “find me a two-week trip to Thailand” and the AI contacts travel companies through MCP-enabled interfaces, negotiates, refines, and presents options. Without Lisa ever opening a browser.

That might sound like removing humans from the equation. It’s not. The technology enables full autonomy. But that doesn’t mean we want to remove the human. It means the customer gets to choose. And our default will always be: lead to a person. More on that later.

That future is coming. Maybe not tomorrow, but it’s coming. And if you’re a travel company that takes itself seriously, you’d better be ready for it.

So I built Joy, an AI travel assistant for 333travel, not as a product launch, not as a marketing play, but as a serious test. Can we build a conversational interface that actually adds value? That understands our products? That doesn’t hallucinate as much? That creates a genuinely useful experience as an additional channel next to our website, phone, and email?

I didn’t build this to replace our website. I built this to answer a question: can a conversation be a meaningful channel for personalized travel?

What this actually is

Let me be specific about what Joy does:

Joy sits on top of our entire product database. Every roundtrip, every hotel, every excursion, every destination, all embedded as vectors in a dedicated database. When a customer says “I want something adventurous in Southeast Asia, around two weeks, not too touristy,” Joy doesn’t keyword-match against a PDF. She searches semantically across hundreds of products, reranks results based on actual relevance, and responds with options that genuinely fit the intent.

And she remembers the conversation. Not just the last message, the whole thread. She knows what trips were discussed, what was saved, what was dismissed. When you say “that trip you mentioned earlier with the cooking class,” she understands what you mean even if she originally called it a “culinary experience.”

But here’s the key difference with any chatbot out there: she doesn’t just know travel in general. She knows our travel. Our specific products. Our specific itineraries. Our destinations that our team personally visited. That’s not something you can easily bolt on with a plugin, no matter how smart the LLM behind it is.

And the moment you want human contact? Joy hands the full context to a real travel specialist who knows exactly what you’ve been exploring. No “please describe your inquiry again.” No cold transfer. Full continuity.

Joy doesn’t replace conversations with specialists. She makes them better.

What she doesn’t do (yet): she doesn’t handle customer service queries, airline information, or post-booking support. This is purely a product discovery and inspiration channel. We’ll get there. But we’re not going to pretend she does things she doesn’t. And honestly, when someone reaches out to customer service, there’s already a problem. That’s the worst possible moment to put a machine between you and your customer. That’s when you show up. Personally. So we are still debating about what we want her to do there. The nuance is always in the details.

Why you can’t get here with a plugin

You cannot achieve what we built by installing a plugin. Not with ChatGPT. Not with any off-the-shelf “AI widget.” Not with any SaaS tool that promises to “make your website smarter in minutes.”

And it’s not because the AI models aren’t good enough. The models are fine. The problem is everything around them.

The entire system depends on data that we own, structure, and control. Every trip in our database has been visited by our own team. Every itinerary is our own creation. Every piece of destination knowledge lives in our own systems. This isn’t data we license from a third party or pull from a brochure catalog.

That means we can embed it. We can structure it exactly how we need it for semantic search. We can update it the moment something changes. We control the full pipeline from raw product data to vector embedding to retrieval to response.

You can’t build a smart interface on top of piles of dumb data.

If your product data lives in someone else’s system, if you’re reselling trips from a catalog, if your “database” is a collection of PDFs from tour operators, you’re at the mercy of whatever structure someone else decided on. You can’t build intelligence on top of data you don’t understand or control.

And many companies aren’t just starting from zero, they’re starting from a deficit. Their existing systems are already inadequate. The booking engine is outdated. The product data is scattered across spreadsheets and PDFs. The customer journey has gaps everywhere. And instead of fixing those fundamentals, they think it is smart to layer an AI chatbot on top of it. As if intelligence on top of dysfunction creates something functional. It doesn’t. It just makes the dysfunction harder to diagnose.

You’re not solving a problem. You’re decorating one.

Building what we built required three things:

Owning our data. Every trip is ours. Visited by our team. Structured in our database. Embedded in our vector store. You can’t build semantic search over data you don’t structure yourself.

Owning our systems. Our own backend, frontend, deployment pipeline. When we needed a dual reranker, we built it. When we needed semantic conversation memory, we built it. When we needed an MCP server for Web 4.0 readiness, we built it. No vendor approval needed. No feature requests. No roadmap dependencies.

Owning the entire chain. From the moment a customer opens the chat to the moment they’re talking to a specialist, every step is ours. The AI knows our products because we made the products. The specialist knows the conversation because our system feeds it to them.

The AI is the last 10% of the work. The first 90% is building a company that can support it.

In Part 2, I’ll show you how it is actually running under the hood. The architecture, the search pipeline, the memory system that took many attempts to get right, and why 25 seconds of waiting can feel like 5 when you design it right.

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.

I built a “production” app using Vibecoding. 97,089 lines generated. Only 25,056 made it to production. Four complete refactors. The AI didn’t fail because of bad prompts. It failed because AI forgets, loses context, and creates duplicate logic no matter how well you guide it. Vibecoding isn’t about letting AI build for you. It’s about knowing your system well enough to filter the noise. Without that knowledge, you’re only shipping guesses.

What Vibecoding actually means

People think vibecoding means letting AI build your app while you watch. Reality check kicking in here, this is not at all the case if you need an actual working product with the expected result every time.

Vibecoding still means you take control. You prompt with precision. You experiment. You guide. You filter. It’s still hands-on work, just with different leverage.

“A fool with a tool is still a fool”

And if you don’t know what you’re doing? The result is the same as it always was: a mess. Vibecoding without the right knowledge is just plain wrong. And the main problem with AI, is that it keeps producing code after code after code. It just does what you ask. it isn’t critical about that. So if you don’t know what you are doing you are contradicting yourself all the time with programmed functionality that never works together within your app.

Ai is king in fallbacks. I would have had 5 different fallbacks for every api call that fails. Shouldn’t we just make the right way work instead of making fallbacks. AI is also lazy, it rather suppresses notices then fixing them. especially if it won’t work on the first try.

I built a production app with AI (but not because of AI)

I used Windsurf to build an entire application. No human developers. No code written by me directly. we use Sonnet 4.5 as our knowledge.

The result after a lot of frustration: a full production game with backend logic, login flows, async data writes, mail queues, admin security, monitoring, and cartesian algorithms that update based on user interaction.

The AI wrote all of it. I haven’t touched a single line of code. So even the simples css change. I let AI do it.

But here’s what nobody tells often: I had to completely refactor the entire project four times. And not because I prompted poorly. I used KISS principles, DRY standards, PSR guidelines. We wrote decisions and created implementation documents on forehand. We used guidelines for the languages that we used.

It didn’t matter in the end.

AI forgets. It loses context. It starts creating duplicate functions without realizing it already wrote that logic three files ago. The more complex your project gets, the more it drifts. And the more it isn’t done right in the first attempt AI thinks it needs to maintain backwards compatibility, complicating your code even more. No matter how you prompt it the first time or with project rules.

Four complete refactors later, I learned: AI doesn’t forget context. It never had it ;).

The only reason the final version works is because I knew exactly what I was building. I had the system in my head. I could spot when AI was repeating itself. I knew when to stop it, when to redirect it, when to start over. I checked every file for duplicate fallback data. duplicates and so on. I also used the very usefull npm package knip

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

You can’t vibecode something into production without understanding your product. Period. And you need to accept that bug fixing is relying on your AI to fix it without breaking anything else, Good luck with that…

The data tells the rest of our story

During our Vibecoding, Windsurf produced:

• 97,089 lines of code generated
• 2,925 prompts sent
• 5,693 credits used
• 15,734 tool calls (including 7,000 code edits)

What actually made it into production:

• 25,056 lines of code

Over 70,000 lines got scrapped, replaced or refactored.

Now, you might think this means you just need to “guide AI better” or “prompt more precisely.” That’s not the point I wanted to make.

The point is: you can’t prevent AI spew right now. No matter how well you prompt. No matter how structured your approach is. AI will overproduce. It will generate redundant code. It will lose track of what it already built. It will create noise. AI is build to always post a form of AI Verbal Diarrhea.

That 70k+ lines of wasted output? That’s not a bug. That’s the current state of Vibecoding.

And if you don’t know your system well enough to recognize what’s garbage and what’s not, you’ll ship all of it and never be able to debug even with AI. Or worse, you’ll spend personally weeks debugging a codebase you don’t understand.

The costs per 1000 credits are around 35 dollar. The development of this game cost me 210 dollar. Every company delivering Large Language Models is losing money. the code I produced should easily have costed 210 x 10 =2.100 dollar at least. I even wonder if they then even made money then.

Apart from the money, is this really worth our precious electricity? I am wondering if you pay the real price, how feasible this will be.

What people get wrong

AI isn’t magic. It’s a “smart”, fast assistant. But it doesn’t understand what matters to your business. It doesn’t grasp edge cases, constraints, risks, performance implications, or security vulnerabilities.

That’s your job!

In my case, AI helped build something real. But the AI didn’t secure the admin panel. It didn’t design the mail queue logic. It didn’t decide when to debounce async writes. I did. By being critical and asking the right questions due to build experience in the past.

Without that direction, the entire thing would have collapsed.

And I see this pattern everywhere. Teams building AI products without ownership or direction, just to say they’ve “done something with AI.” It’s shallow. It’s fragile. It doesn’t scale.

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

How many times don’t you hear from higher hand: We need to do something with AI. We are falling behind. Behind of what?

The customer service trap

Then there’s also the AI customer service hype. Companies claim it’s perfect for 24/7 support, faster responses, fewer humans needed.

But if you need a bot to talk to your customers, your real problem is probably somewhere else. AI doesn’t fix broken processes. It hides them. Temporarily.

If you think less human contact is a win, you’ve already lost. If replying to questions takes a long time you might have to look at other things why people have so many questions and improve on that first.

The actual point

Vibecoding is just another tool. That’s all it is. A very cool tool in the right hands tho, but still a tool. And mainly good for prototyping, but with a good dosis of knowledge you can maybe produce standalone apps that actually work, and are at least testable by you and the outcome is traceable to the code written in a transparant way.

It doesn’t replace thinking. It should amplify it, and it shouldn’t make you think less.

Used right, it can be powerful. But you still need to know what you want to build. You need to own the structure. You need to filter the noise. You need to recognize AI spew when you see it. You need to lead the process.

Otherwise, you’re not building a prototype. You’re just generating guesses.

The future isn’t AI-first. The companies that matter stay human-first. They understand the problem before picking the tool. And they keep asking the only question that counts before reaching out for AI to help them:

What are we actually trying to solve?

Here is the link to the original article with the waybackmachine: Due to covid and flow.ai beeing taken over by khoros this blog is no longer publicly available. This blog was written in q3 of 2019.

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

Sadly we have chosen to retire Joy due to the lack of results in early 2022 and Covid hitting us hard. The customer engagement was to low to keep it alive sadly.

Artificial intelligence (AI) to keep in touch, in a personal way, outside opening hours. That is what 333travel uses their chatbot they called Joy for.

The travel industry is an innovative market. The competition is prevalent and the urge for technological advantage is great but also difficult. If you do not operate technically independently in this market, there is a good chance that you will be absorbed by the crowd too much and can therefore no longer be unique in your proposition and your right to exist will be endangered.

We are constantly looking to improve our position on the market and every day we translate IT into the business in the right way so that IT actually works for us. Keep experimenting and keep on trying new things!

Our challenge

We are always looking for ways to better serve our customers and we want to do this in a personal way. This way we can really build a relationship with our customers and offer fully customized solutions.

We are convinced that when you travel with us you will get the best possible experience of enjoyment because at 333travel we think along with you from A to Z and completely unburden you.

…With the help of Joy the customer has their answer faster and we can offer more quality because Joy indirectly ensures less work and more available information before a personal contact moment takes place…

The use of artificial intelligence may therefore sound contradictory, but that is certainly not the case. We will of course start to use this AI to provide our customers with the existing information / FAQ on our website if they have any questions about it.

But in addition to providing information, we will always try to direct to personal contact. It is important for us to physically come into contact with our potential customers, in a more personal, easy and accessible way.

Our goal

The automated collection of leads in a way that is as personal as possible is therefore our case for the implementation of this artificial intelligence. The rest is a added bonus. We strive for even more for personal contact through this AI. The focus is creating value and optimizing our customer journey outside of our regular working hours.

Our solution

Together with Flow.ai, we have started testing to see what personal ways we could use to get a customer to get in touch with us.

A correct use case of AI is very important here, but also the way in which you can train this AI. We wanted to create the most natural way of interaction, but we have to work with non sexy data such as “departure” and “arrival” dates to get an idea beforehand of when someone wants to leave for his holiday, this is a greater challenge than it seems.

We absolutely wanted to avoid that our AI does not immediately understand it when someone says “I want to visit Thailand on June 17 for 1 week”.

A natural interaction with the right intent

We have therefore trained our LMM that it understands intents with knowledge of what the departure date is and when you want to leave. It is therefore not an absolute fact what we want from you, but it is a value that falls within the meaning of “when do you want to leave”. There are so many different but also correct answers to this question and if you take our requirements into account, this bot must also understand everything below and more:

• In the summer i want for the holidays…
• During the winter i would like to stay …
• In autumn I want to go to…
• I want to be in Thailand for Christmas…
• We want to go to … next year

It immediately becomes unfriendly if after this question there is still a date field to be filled with when do you want to leave. Or even worse, the bot dont understands the question at all. a customer also often does not know when he wants to leave exactly. When he starts like this, is he obliged to fill in this information? You have one try with this type of customer.

Customers are fed up enough already with non working chatbots from large companies trying to reduce FTE and see how far they can go to annoy their customers.

We instantly record the key information of the expected departure period automatically. After all, this will be deepened further in the contact moment, for now our specialists will know what the intent is and can act accordingly.

It is also possible within our implementation to capture all the variables we need with only one sentence from a customer. We only need the contact details after this and we give a call on the requested time and date.

Collecting data

“Good afternoon, I am looking for a holiday starting in Indonesia and ending in Bali for 2 adults and 2 children with a hotel on the beach leaving July 21 and coming home the 3th of August .”

The above sentence is a practical example of what Joy understands. We record these values and we immediately know that there is enough data. We only ask for the customer’s telephone number/e-mail address and call him at a preferred time specified by himself.

we call you at the preferred moment, we consciously chose not to let the customer choose something through a date picker to keep the natural flow. For the customer it is easier to say: “next Thursday at 10 am”. From this, we understand what the intent is and call that particular customer at that exact time. There are also plenty of customers who say they want to be called right now. Regardless of whether they can be called at that moment or not, they drop out as soon as they get a date picker presented. Especially when the present day is missing.

Because the customer visits our website, we also know from which page we have received his request for personal contact. This way we have even more information for our specialists to get an idea of what the intent is.

This data gets send automatically as a lead/proposal in our backoffice called BOSS. And every follow up on this lead is recorded there.

Result: Joy sees the light.

After a large number of internal tests, various tweak adjustments and using various methods to achieve our goal, Joy was born. We have also given her a personal face because of our intention to keep the conversations personal. Of course, we do indicate that Joy is a “Virtual Travel Assistant”. Our real colleagues are still the travel specialists.

…What is particularly noticeable from the results is that the interactions and requests that come in via Joy are usually from people between 20 - 35 years old…

Important lessons

The most important lesson in this might be a bit of an open door, but make sure your goal is set on paper, and start with the simplest implementation of this goal and slowly develop it into a more complex working final product.

We first started to look at ways in which we can collect our required data with Flow.ai and really understand how this works. Then we tested a lot of different scenario’s and slowly worked towards one complete flow that combined the best of multiple flows together. We immediately gained a lot of experience with the various options that flow provided this way.

We are well supported in this by Flow.ai, but due to our own in-house knowledge, we didn’t require the support all the time and could really dive deep on the subject.

The flow.ai system is well structured, very logical and understandable. This shouldn’t block you from experimenting.

The future

The first Quarter is our busiest period. Because we implemented Joy relatively shortly before this period, we have not yet activated the option to Live Chat. This is something that is going to be activated after this quarter.

In addition, we want to go even further in the near future with Joy and make her THE assistant of our customer portal that will help you on your way after you made a booking. If Joy does not know the answer, you will immediately get in touch with the specialist you booked the trip at. If you have any questions during your trip? Ask Joy. Do you have problems during your trip? Joy ensures that you get the answer as soon as possible and that you get into direct contact with us when needed.

We see Joy as our “Virtual Travel Assistant” where the very specific knowledge of our destinations and our knowledge of customization remains with our travel specialists because this is the strength of our personal contact in which we personally make the difference, within our philosophy.

Introduction

I am writing this introduction because i want to explain why I use ChatGPT and what i use it for. At first i was a bit sceptical of what ChatGPT was. It was to me more of a fantast.

But that is only when you ask questions you have no deep knowledge about. We have to be very careful there since you dont know when it is making stuff up. And also asking the right kind of questions to get a decent enough answer helps ChatGPT not making things up themself.

Practical examples

In our work area we tested it for example to write intro texts for a hotel we had. ChatGPT made up a lot of stuff about swimming pools available and such. This particular hotels has no swimming pools.

So it isn’t useful there. But it is actually useful about topics you do know about. You can ask it the right questions and it makes up a tekst which is for at least 75% usable most of the time. This will safe time.

ChatGPT is for language what the Calculator was for Mathematics.

ChatGPT is going to make our life a whole lot easier by providing information about topics you want to write about and already have knowledge about.

ChatGPT and AllSubjectsMatter

How I use ChatGPT on this website is to correct my grammar and sentence flow. I am a native Dutch person. And how i would like to brag that I used to do so well in my English classes. I never did any homework back in school but still got 9’s and 10’s.

I have to admit now that this has all become very rusty. Especially since i havent written in English for years on a regular basis until now. So it is actually helping me at this moment to write better readable English texts.

This is what ChatGPT produced of the above lines.

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.

And this is the same text after i corrected it with 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.

The original already isn’t to bad to me but this is just an example of what we can do with tools that help with readability issues.

What is Hemingway?

Hemingway is a visual readability editor which can help you to simplify sentences. I use this all the time to check all my English texts for readability. This also helps make your texts easier to read.

Conclusion

I use one of these two tools to try and write better English. Sometimes i use both of them. This is the place where ChatGPT can really shine in helping you to improve your writing. By using ChatGPT I immediately started learning to write clearer and easier sentences.

So there is hopefully less and less to correct every time i feed a text to Hemingway or ChatGPT. This is because you also learn yourself by running your texts through these tools.

I dont like using ChatGPT to fully write my posts and redirect them into something that represents “me” since that doesnt feel right to me. The idea has to come from me and i use ChatGPT to polish it sometimes. And not the other way around for me.