What I actually use AI for when I’m planning a trip

Checked 22 Sep 2026 · By Luke Czak

ArticleHow to Use AIFree to read

I stopped asking an AI to plan my trip and started asking it to do the three specific parts of planning that were actually costing me time.

The first few times I tried getting an AI to plan a trip, I asked it the way you would ask a travel agent — plan me five days in a city — and got back something that read well and fell apart on contact with reality: opening hours that were wrong, a route between two stops that looked fine on the page and was an hour on the ground, a restaurant that no longer existed. The plan was fluent and confidently arranged and I could not actually trust any single fact in it. The frustrating part was how plausible the errors looked sitting next to the parts that were correct — nothing in the formatting or the tone signalled which claims had been checked against anything real and which had simply been generated to fit the shape of the request.

What changed the outcome was asking for narrower things I could check rather than one broad thing I had to trust whole. Not "plan my trip" but "given these seven places I already want to see, which ones are close enough to cluster into one day, and which are not" — a structural question about geography and time, which is exactly the kind of reasoning a model is reliably good at, rather than a factual question about what is currently open, which it is not.

The other genuinely useful task is comparison at a scale I would not do by hand — laying five accommodation options against the specific things I care about, rather than whatever a booking site’s default sort happens to optimise for. I still verify every fact it surfaces before booking anything, but doing the first pass of narrowing five imperfect options down to two comparable ones is real time saved, even with the verification step included. The model is not telling me anything a spreadsheet with the right columns could not, in principle, but building that spreadsheet by hand for every option every time is exactly the kind of repetitive structuring work I would otherwise skip, which means in practice the comparison never happened before and now it does.

What I do not do any more is trust anything time-sensitive or fact-shaped without checking it directly against the source — opening hours, prices, whether a place still exists at all. This is not a special caution reserved for travel; it is the same rule I apply to model output generally, but travel planning is where I learned it most expensively, because a wrong fact in a travel plan does not surface as an error message, it surfaces as standing outside a closed door in a city you do not live in.

The version of this that works, in the end, treats the model as very good at structure and comparison and unreliable at fact, and hands it only the tasks that match. That is a narrower use than the plan-my-whole-trip pitch, and it is the one that has actually saved me time on every trip since I started using it that way rather than the one I originally hoped would.

It also changed how I use it during the trip itself rather than only before it — asking it to re-cluster the remaining stops when a day runs long, or to work out whether a change of plan still leaves enough time for the one thing I actually cared about seeing, which is the same structural strength applied on the move instead of in advance.

I have stopped feeling like I am using it wrong when the output needs this much scaffolding around it. A tool that is excellent at structure and unreliable at fact is still worth using for the structure, provided the fact-checking step never gets skipped to save the last few minutes — and the trips where I skipped it are the only ones I can point to a real cost from.

Comments (0)

Sign in to comment.