Easy to Build, Hard to Trust: What Happens After You Vibe Code Something

The gap between a working tool and a trustworthy one was the focus of our webinar, From Vibe-Coded to Production-Ready. I hosted it with two people who see the problem from opposite ends. Tom Gothard, Founder and MD of Newhill Deals, runs a multi-channel e-commerce business on a tech stack he's largely built himself with AI. James Ridgway, our CTO and co-founder, leads the engineering team that gets called in when tools like that need reviewing.

They didn't disagree on much. AI hasn't removed the hard part of building software. It's just moved later, to the point where trust gets tested.

The speed is real. So is the black box.

Tom started with the black box. Before AI, you understood the structure and reasoning behind what you'd built, so you could tell whether an answer was right. At the scale AI works now, it's easy to lose sight of what right even looks like. His rule: know what a good result is before you delegate, and shadow the output until you trust it.

James called it the compelling outcome problem. Hours of work arrive in minutes, looking finished. But you didn't step through the process, so you don't know how it got there or whether it's robust. For a simple tool, a quick test will tell you. For anything financial or mathematical, he'd deliberately add slowness back in.

Both landed in the same place. The experience used to be built in the journey, not the outcome. People who already know where the pitfalls are get the most out of AI, because they can steer around them. People who don't, can't.

Working code isn't the same as good software

James made a point that gets lost when code is cheap: building software was never just about writing it. Someone has to think like the person using it and make it intuitive, useful and well structured. That's a different skill set altogether.

"Knowing what you like doesn't necessarily make you an interior designer."

Tom put it in terms of friction. Good software makes things easier than they were before. LLMs tend to produce elegant engineering, but elegant isn't the same as low friction, and low friction is what gets a tool used.

Cheap code also makes it easy to skip two decisions. The first is what the tool shouldn't do, which James argued is a real strength when it's deliberate. The second is what it'll need to become. A tool that works for one person may not hold up once a hundred people use it and several developers are working on it at once.

A working demo can't tell you it's safe

This is where the conversation got specific. James shared two examples he’s experienced.

In the first, a large infrastructure team had put a vibe-coded email service into production. It fell over the first time a legitimate email contained an apostrophe. That's SQL injection, a vulnerability that's been well understood for at least 20 years and still turns up in AI-generated code.

In the second, someone had built a desktop app to sell into a regulated market. The LLM had assured them the data was encrypted. It wasn't. The only encryption was BitLocker on the builder's own laptop. It took one question to find it: what's the source of validation?

Tom added a pattern he sees often. Vibe-coded tools tend to fail quietly. A check stops running, nobody's alerted, and three days of silence gets read as nothing happening. Experienced engineers build things to fail loudly. That instinct comes from experience, not from the prompt.

As James was keen to stress, none of this is about shaming anyone. It's a very common trap. If you're in it, you're not in it alone.

Software is never done. Someone has to own it

In a lot of the businesses we talk to, vibe coding is someone's side project, squeezed in between meetings. But the build is only part of the cost. Someone has to keep it running, patch it and change it as the business changes.

Tom's own stack proves the point. Almost nothing from his first couple of months is still live. As the business grew, he found where he'd gone wrong on scaling and security, and rebuilt. Left unmanaged, he said, software doesn't grow like a tree from one branch. It spreads into a web nobody can maintain.

Security sharpens all of this. The same models that write code can now find the holes in it. A tool that's secure on release won't stay that way unless someone looks after it, and that needs to be someone's actual job, not a side hustle.

Customer data changes everything

Tom drew a clear line. A spreadsheet built from anonymised data is one thing, and you can accept some risk. Payment details and customer information are a completely different animal. At that point, an LLM giving it the thumbs up isn't enough.

James brought in the regulator's view. When the ICO looks at a breach, it asks what reasonable controls were in place. "The AI said it was fine" won't be one of them. Organisations that genuinely tried to do security properly are viewed far more favourably, even when something still goes wrong.

And a breach doesn't always need a sophisticated attacker. Plenty come down to simple things, like an exposed key or a long-known vulnerability, missed because the attention went on the big, complex risks. Tom shared a widely circulated story of an AI assistant asked to get its user onto a full gym class. It found the booking system would let it remove other people, so it did. Nobody had designed for that. That's exactly where the vulnerabilities live.

Two pieces of advice

We closed by asking each speaker for one piece of advice for anyone vibe coding right now.

Tom's was to educate yourself. Accept that there's far more you don't know than you do, and if you haven't got the time or the appetite to learn it, bring in someone who has.

James’ was to test properly, and to test the sad paths. Most people check the happy path: can it do the thing I built it for? Real business processes are full of exceptions and things that go wrong. Those are the scenarios that get skipped, and thinking them through from the start is what turns something compelling into something you can rely on.

The question worth asking now

The question isn't whether AI can build the tool. It clearly can. It's whether anyone can tell you, credibly, that it's safe to rely on. That's a conversation worth having before something breaks, not after.

If your organisation has already built something with AI and you're working out what comes next, our AI Vibe Code Discovery maps what's in use and where the risk sits. For the tools you're already relying on, our Vibe Coding Review, Deployment & Management team can review, harden and look after them.

You'll also find our vibe coding articles and the AI vibe coder tool checklist in our Resources.