This follows on from: Generative AI for Genealogy – Part XI
Wrong vibes, and LSD‑free answers
Time to take stock.
At this point in the project, I had:
- A multi‑language web UI that handled sign‑in, file upload, chat, and payment—most of which was, if I’m honest, vibe‑coded.
- A retrieval engine that could actually answer genealogy questions.
What I didn’t have was the luxury of testing everything to death before writing about it. In hindsight, the health warning probably belongs at the end of the series, not here—but here we are.
To be fair to the AI tools, they did accelerate the coding. And they were very clear: I never explicitly asked them to write tests. That’s on me. Next time, I might try the radical idea of asking the AI to test its own work. What could possibly go wrong?
When I finally slowed down enough to poke at the system properly, the bugs fell into two broad categories:
- Things I asked for that simply didn’t work.
- Things that technically worked, but with clear side effects.
The first category is almost comforting: you find the bug, you ask it to fix the bug, you retest everything, repeat until your patience or budget runs out.
The second category is more insidious—the “wrong vibes” class of bug. The kind that reminds you this thing is powerful, fast, and utterly unconcerned with the consequences of its creativity. You really do have to watch it like a hawk.
Take session timeouts, for example. In the spirit of best practice, I have a server‑side session timeout. When the session expires, the server quite reasonably forgets who you are and what GEDCOM you uploaded.
The UI, however, responded to this with a deeply unhelpful error message. From its point of view, the user, the GEDCOM, and the entire context had just evaporated. From the user’s point of view, the app had just had a small existential crisis.
So I asked the AI to fix it. I didn’t spell out exactly what I wanted, because to me it was obvious. (You can already see where this is going.)
It dutifully added:
- A countdown timer as the session approached expiry.
- A warning message.
- A “renew session” link.
- Even a server API endpoint to back it all up.
So far, so good.
Except… if the user ignored the warning and let the session expire, they were dumped back at the sign‑in modal. After signing in again, they were greeted by:
- No GEDCOM loaded (because that lived in the old session).
- A hidden question box (because the UI thought, “No GEDCOM, no questions for you.”).
- And no visible way to upload a new GEDCOM.
The only escape hatch? A good old‑fashioned Ctrl+F5, followed by another sign‑in. Elegant, it was not.
Several iterations later—after I spelled out, step by step, how it should behave—we finally got to something sane. But it was a reminder: if you don’t tell it exactly what you want, it will happily improvise.
Another example: I asked it to support drag‑and‑drop file upload as an alternative to clicking the file input. Simple enough. It did that… and also somehow made the entire form draggable.
So now, not only could you drop a file onto the app, you could also appear to drag the web page around inside itself. It looked weird, felt wrong, and was the sort of thing you’d only discover by accident—because who sits there randomly dragging bits of UI around just in case?
The moral of the story: if you don’t test thoroughly (which, under pressure, is at least understandable), and you don’t give the AI very explicit instructions, you have no idea what does and doesn’t work. It might be brilliant. It might be quietly unhinged.
Which brings us neatly to payments.
Because after all that, I now get to test the Stripe integration.
I am, shall we say, nervous.
