Going from vibe to viable. Carrying LLM code across the line.

So I technically vibe-coded this site, to an extent. I’m a software developer at heart, have been for 15 years, but have been adopting AI tools into my workflow.

Now. Before we go any further: “vibe coding” by definition is the act of coding by vibes, building something without thinking about the underlying tech.

That doesn’t mean you don’t understand it. I’ve got a solid foundation in the tech that powers this site, and countless others like it. I know HTML, CSS, JavaScript like the back of my hand. I could write any of the code by hand. But I chose not to.

Reasons? I guess I’m tired of typing, for one! (decades of it). But I also understand AI has become very good at the basics, spinning up boilerplate and getting something in place.

The output is not great by default though. So we need to keep going. We need to refine, test, repeat. Always be iterating.

Adoption is up. Trust is down.

If you read social media too often (please don’t) you’ll get the idea that AI adoption is a runaway success. But there’s way more behind the flashy stories and the grating engagement bait.

This doesn’t mean that the tools themselves are useless, far from it. But that same DORA work has found that most people report a productivity lift while the reality - the measured stability, trust and, occasionally, actual throughput - are down.

For work previously carried out by junior roles - boilerplate tasks, data entry, repetitive templating - the gains can be real, but for the majority of the work that goes live on the web, especially for the gears that keep everything running, the true picture is mixed.

Why the “vibe” underwhelms

An LLM predicts the next most probable token given everything produced so far. That’s basically it (though the emergent behaviours from this are weird!).

This means that by default it tends to head towards the safe, average centre of distribution - and this is where the most repetitive, recognisable AI “shapes” live:

• It flattens toward the average. The alignment training that makes models helpful also collapses their diversity - run the same prompt ten times and you get ten near-identical answers. Decoding by “most likely” then piles on the blandness: formulaic openings, boilerplate transitions, the same three-column layout every time. (RLHF diversity collapse, Kirk et al. 2023; nucleus-sampling degeneration, Holtzman et al. 2019.)
• It agrees with you. Models are trained on what raters upvote, and raters upvote answers that flatter them - so assistants cave when challenged and won’t volunteer criticism unless you force it. (Sycophancy, Anthropic, Sharma et al. 2023; OpenAI’s April 2025 GPT-4o rollback.)
• It’s confidently wrong. Plausible and correct score the same during training, so you get fabricated APIs, invented citations and code that imports packages that don’t exist - measured at 5–22% of samples, which is now its own supply-chain attack (“slopsquatting”). (Kalai et al., OpenAI 2025; Spracklen et al., USENIX Security 2025.)
• It loses the plot in long sessions. Performance leans on the start and end of a long context and drops in the middle, so on a big multi-file change your earlier constraints quietly slide out of view. (“Lost in the middle,” Liu et al. 2023.)
• It has no principles. An AI has no stake in your project, it doesn’t really care. It certainly seems like it does and, for all intents and purposes, that’s good enough as a pair-coding buddy. But if you’re leaning on it to make important decisions, you risk being convinced by something that has no cards on the table.
  
  And it is genuinely convincing: in a controlled debate study, GPT-4 given a little background on its opponent out-persuaded human debaters in 64% of cases. (Persuasiveness: Salvi et al., Nature Human Behaviour 2025. It will also shift its stated position to please you: sycophancy, Sharma et al. 2023.)

When you’re vibe coding you’re basically being steered by the world’s most persuasive content aggregator! Viable is what happens when you push back with your own human instincts.

Five ways to push LLMs over the average

Over the last few months I’ve been doing more work with AI, here’s a few habits I’ve built up to compensate for LLM failings.

1. Name the tells, then hunt them with a second model

Models by their very nature can’t see their own defaults and won’t criticise their own work. Or if they do, you’re basically falling foul of confidently wrong with a little sycophancy mixed in. I ask it to list all of the visible anti-patterns: “List every LLM tell in this - layout, copy, structure”.

Massively obvious LLM tells within admin panels, for example, include 4-stat layouts across the top, little boxes with a coloured left-hand border. Unless you explicitly point these out the model likely won’t pick up on them, but a separate adversarial reviewer (e.g. asking Gemini or Codex to review Claude’s output) can help you flag problems.

From my logs“Ok, one last review, get codex and gemini cli in too please, check for any inaccuracies or indefensibles”

2. Define the humans before the AI does anything

A vague prompt leaves the probability distribution wide open, leading the model to produce generic outputs. Specificity is going to help here. Before setting an AI to build any boilerplate I make sure to talk to as many real stakeholders in a project as I can (even if it’s just myself for a personal project! Don’t dismiss the value of talking out loud).

Figure out what’s really troubling those people, figure out what hurts. Concrete constraints will help the model to pin down more viable answers. Abstractions just steer it back towards the statistical average.

(Note: personas have often been touted as a solution for LLM averages, e.g. “you are an engineer with 15 years experience,” but that’s too vague. Explicitly listing pain points, tasks and problems is what gets results.)

From my logs“Is there a specific type or class of company, or a company/client in a specific mindset that this might apply to? ‘Clients who love funnels’ sort of thing!”

3. Anchor to the best, not the mean

Letting an LLM guide its own references will often mean you fall foul of exactly the same problems. It either fabricates references entirely or will default to very average examples. Knowing your own domain of expertise helps here because you know what good is and you can pick the best references. I know, this requires work! But if you want the best, you’ve got to be prepared to do the work and understand what it is you want to build.

So find sites you love, layouts that inspire you. Think about why you like them so much. Write down your interpretation of the visual elements. Don’t just point an LLM straight at a screenshot or website and ask for a copy. First up that’s morally grey. Second, you’re simply asking for the average interpretation of those references. Use your own wits and your own ingenuity to transform what you see into a plan of action. That’s what the LLM will work from.

One key thing to understand about vibe coding with LLMs - the ceiling has been raised. Everyone’s pushing out the same old sites and the same old solutions. In order to stand out, you still need a unique vision.

From my logs“check out sketchandgo, nab some drawing assets from that. I want a system that draws satisfying thin, clean, slightly sketchy inky lines”sketchandgo is one of my own earlier projects, so I’m anchoring to work I already know is good.

4. Keep your words verbatim - let the AI edit, not author

So that brings us onto what I consider the most important point - not letting the LLM screw up your own thoughts. LLMs will average out even the most unique prose over time if you let them. So anything I write, I apply a simple rule - never rephrase, only reorder. Keep my text verbatim unless doing so will cause grammatical issues. I welcome suggestions but do not implement without permission.

The model is a sharp editor and a useful critic, but it is not the author and it will suck out your voice if you give it leeway. In short - use its eyes, not its mind.

From my logs“yep let’s do it as never rephrase. you can reorder. but only use whatever text I’ve given verbatim”

5. Distrust the confident answer; make it ask what a human would

This one’s very important to keep in mind. Trust your instincts. If you think something’s too good to be true, it often is. Same goes for LLM outputs - and every output is presented as a low-effort, high-value response. So distrust everything!

I always ask Claude to reverify everything it writes, as well as passing it by either Codex or Gemini for review. I’ll also ask it to present me with links to validate those references. If you like, even ask it to generate screenshots of those references to quickly verify that (a) they do exist and (b) they say what the LLM says they do.

From my logs“ok so that’s an assumption not a claim. Run another analysis please if you’re making mistakes like that”

The cost isn’t the token bill

Everyone frets about the token bill. Wrong number! Go at it hell for leather with an agentic coding tool and you’ll burn maybe 20–40 million tokens a month - call it around £2,000 a year. Even if you bin a third of everything it spits out, the wasted tokens come to a few hundred quid a head. Genuinely, a rounding error. That’s not where the money goes.

Here’s where it actually goes. The expensive part is people, and it’s a whole order of magnitude bigger:

And that’s only the cost you can see. The one that really bites is hiding in the tail: the vibe-coded feature nobody clocked was broken. Nearly half of AI code ships with a vulnerability, and one analysis of enterprise code found AI-assisted work introduced security-critical flaws around 2.5× as often as human-written code (Apiiro, 2025). In a regulated, editorial or membership setting, one quietly-shipped fault - a leaked key, a mishandled record - can dwarf every efficiency number above it. Lawfare’s Carolin Kemper has a lovely phrase for this: “vibe compliance”, where an AI-generated risk assessment simulates the process without actually managing any risk. So no - the expensive mistake was never the wasted tokens. It’s the salary of the person who didn’t notice the output was quietly failing.