When Vibe Coding Makes You Rage Quit

We've been building on the web for a long time. Long enough to know that every tool has a ceiling, every platform has a catch, and the gap between the marketing and the reality is usually where the interesting stuff happens. So when we decided to run an experiment with Horizons (Hostinger's AI-powered site builder) we went in with reasonable expectations and genuine curiosity. We'd used it before. We had a functioning site we were around seventy percent happy with. That felt like enough of a foundation to try something new.

It wasn't.

Vibe coding is the current shorthand for a particular kind of building: prompt-driven, iterative, trusting the AI to handle the implementation while you focus on the vision. At its best, it's genuinely liberating. You describe what you want, the system figures out how to make it happen, and you spend your energy on the creative decisions rather than the technical ones. We've seen it work. We've made it work. The promise is real.

What we were attempting wasn't ambitious. A blog. A clean, functional blog with a specific aesthetic — noir, comic book, something with character. The visual side came together. The platform handled the design work well enough that we felt momentum, felt like the experiment was paying off. Then we tried to save a blog post.

Not a long one by any meaningful standard. Somewhere around 1,500 words — a normal editorial, the kind of thing we publish regularly. It failed. We tried again. It failed again. Horizons' AI assistant, Kodee, identified the problem as a request body size limit in the Express.js backend, which sounds technical because it is, but the plain version is this: the platform being marketed for building blogs had a ceiling on how much text a blog post could contain before the save function broke.

We spent approximately four hours trying to resolve this. Four hours of Kodee identifying the problem, suggesting prompts, those prompts not working, suggesting different prompts, those not working either, each attempt consuming tokens from our monthly allocation. The circularity was maddening. Every loop cost us something. The platform was billing us for the experience of discovering its own limitation.

We want to be fair here, because fair is the only register worth writing in.

Kodee did credit us ten tokens during the exchange. That gesture came unprompted and was noted. What followed it, when we escalated to a human agent and asked about a refund, landed differently.

The initial response characterised our usage as "abusive behaviour." That's a direct quote. We'd used the tokens we'd paid for, attempting to fix a problem with the platform, and the first human response in the chain reached for that framing. We're not going to dwell on it, but we're not going to pretend it didn't sting either, because it did. It was inaccurate, it was deflating, and it was, on reflection, almost certainly a scripted deterrent rather than a considered judgement. When we pushed back, the framing quietly disappeared and was replaced with a policy explanation about consumed resources. Two different justifications within minutes of each other is worth noting.

The refund was denied. The subscription was cancelled. The site was deleted in a moment of frustration we're not especially proud of but entirely understand.

Here's where we take our share of it.

UK consumer culture shapes certain expectations. There's a genuine tradition here, backed by law and by convention, of meeting customers halfway when something goes wrong without clear fault on either side. We walked into that interaction expecting some version of that. A goodwill credit. An acknowledgement. Something. We didn't get it, and the cultural gap between what we expected and what the policy actually stated was wider than we'd accounted for.

We hadn't read the refund policy carefully. Thirty tokens is the threshold; once you're past it, the terms are clear. We weren't past it in spirit, we'd spent those tokens fighting a platform fault, not building a functioning site, but we were past it on paper, and on paper is where refund policies live.

Had we read it properly before asking for recompense, we'd have led with that. We'd have framed the conversation differently, acknowledged the policy, and made the case on its merits rather than on expectation. That's on us. Even the most diligent operator gets distracted. We were building something meant to be a pleasant diversion during a difficult few days at home, not running a procurement process. The small print was the last thing on our minds. That's a very human thing to admit, and we're admitting it.

The lesson isn't "always read the T&Cs" delivered with a wagging finger. The lesson is that platforms built for people who aren't developers, people building under time pressure, emotional pressure, creative pressure, exist in a space where the small print and the human reality are rarely in the same room. The gap between them is where most of the friction lives.

Vibe coding works. We still believe that. The tools are real, the capability is real, and for the right task in the right conditions it remains one of the more genuinely useful things to emerge from the current moment in AI development. But the conditions matter enormously. The task matters. The platform's actual ceiling, not the marketed one, the real one, matters. And the support structure that catches you when the ceiling arrives matters most of all.

We ran the experiment. We got the result. We've moved on.

That's what learning curves are for.

Join the Movement: Learn more about our MyFaceBelongsTo.Me protocol and how to protect your digital sovereignty.

Learn more

Footer navigation