What Is Vibe Coding?

The term was coined by AI researcher Andrej Karpathy in early 2025 to describe a specific mode of software development. You express what you want in natural language, accept the AI’s output and iterate conversationally without necessarily reading or reasoning about every line of code the model produces. You “vibe” with the result rather than constructing it.

The practice itself predates the name. Developers have been using tools like GitHub Copilot and ChatGPT to generate code for years. What Karpathy named was the more radical end of that spectrum where you are not guiding the model line by line but describing an outcome and trusting the implementation entirely.

The mental model shift this requires is significant. In traditional development you hold a detailed internal map of the system: data flows, function signatures, edge cases and error states. In vibe coding you hold a model of the desired behaviour and treat the code almost as a black box that you can interrogate and redirect. For experienced developers this can feel uncomfortable at first. Tolerating uncertainty about implementation is not a natural habit. For domain experts who are not primarily developers it is immediately liberating for exactly the same reason.

What makes this possible right now is a genuine step change in code generation quality from current large language models. Earlier models could write functions. Current models can scaffold entire applications with reasonable architecture, handle multiple interdependent files and reason about their own output when asked to revise it. We are not in the same world we were eighteen months ago.

Not All Problems Are Equal: Knowing When to Vibe

Vibe coding is a tool not a methodology. The question is not whether to use it but when. A useful mental model is to think about two axes: the consequence of failure and domain novelty, meaning how far outside your own technical comfort zone the implementation sits.

When the consequence of failure is low and domain novelty is high vibe coding is almost always the right call. Internal dashboards, personal insight tools, exploratory data scripts and proof of concept demos sit squarely in the green zone.

The calculus shifts as stakes increase:

• Green light: personal dashboards, internal tooling, data exploration notebooks, throwaway scripts and proof of concept demos

• Amber: APIs with external consumers, anything involving authentication and ML feature pipelines feeding production models

• Red: billing logic, security controls, regulated data processing and anything requiring a full audit trail

At CKDelta we use vibe coding for rapid prototyping in the early stages of product development or during customer project engagements. Traditionally these early stages rely on sketches or diagrams to communicate ideas. With vibe coding you can generate a working prototype in less time than it takes to sketch a wireframe. The iterative cycle shortens and the customer experience improves because they can visualise the end product much earlier.

Vibe coding is also extremely useful on R&D projects. For example when CKDelta attended the Northumbrian Water Group Innovation Festival we used vibe coding to create demos on the fly in a hackathon environment.

When the Official Dashboard Isn’t Good Enough

Let’s look at a practical example. My electricity provider offers a dashboard of my consumption but it is clunky to use. I also wanted to compare tariffs from other providers based on my actual consumption.

With vibe coding I created my own dashboard, not by opening a code editor but by opening a chat interface and describing what I wanted. I exported my half hourly smart meter readings as a CSV file and started talking. Thirty minutes later I had a working dashboard with monthly, daily and hourly consumption charts, drill downs, a day versus night band breakdown and a tariff comparison tool that let me compare providers using my own data.

The value was immediate. One insight it surfaced was that most of my consumption occurred on the night rate from heating water which meant I should switch to the provider with the lowest night rate. Pretty good for a thirty minute exercise.

I wrote no code. What I wrote were instructions.

This is vibe coding in practice and it is worth understanding what it actually is, where it genuinely helps and where it will quietly let you down.

Building the Smart Meter Dashboard: A Walkthrough

I quickly learned that it is important to understand how to “vibe”. For example “Build me a smart meter dashboard” produces something generic. “Build me a dashboard with an annual view with monthly totals, a monthly view with daily totals and a daily view with hourly totals” produces something immediately useful.

The specificity of a good prompt is very close to the specificity of a good technical specification. The difference is that you are having a conversation, not filing a ticket.

The first output was a reasonable dashboard application that broadly matched my request.

I reviewed the application and noticed some issues. For example there were two buttons to upload a CSV file. This was an interface choice that could confuse users. I also spotted readability issues caused by some colour choices. I followed up with prompts to resolve these problems. Each exchange felt less like issuing commands and more like working with a capable colleague who needed context.

The iterative nature of vibe coding is the point. You are not expecting perfection on the first try. You are steering toward it.

After several prompts the application crashed and failed to load. In traditional development this would require reviewing and debugging the code. In vibe coding I simply wrote a prompt to fix the error. I did not need to know what the error was or understand what caused it.

This is “peak” vibe coding. I am not writing code, reviewing code or checking how the code is being updated.

After fixing the issues I added more features including a light and dark mode switch and a button to download a CSV template.

The New Skills That Matter

If vibe coding shifts the developer’s role it is worth being precise about what the new skill set actually looks like because it is not simply “knowing how to prompt”.

Prompting as specification writing
A good prompt and a good technical specification share the same DNA: precise inputs, explicit outputs, stated constraints and anticipated edge cases. The difference is that a specification is a document handed to a team. A prompt is the opening of a conversation.

Critical review without line by line reading
You do not need to understand every line of generated code but you do need to evaluate whether it is correct at a behavioural level. That means testing real inputs, probing edge cases and thinking about failure modes. These skills are closer to QA and systems thinking than syntax knowledge. This is a different kind of rigour not less.

Knowing when to stop prompting
One of the harder meta skills is recognising when you have hit a local minimum. The model is patching the same flawed approach from different angles. At that point you either restart with a cleaner prompt or take the wheel and edit the code directly. Blind faith in iteration produces increasingly tangled output.

Domain knowledge becomes the differentiator
In a world where anyone can generate code value shifts to people who know what to build and why. Understanding half hourly meter data formats, tariff band structures and how households actually use energy is what made the dashboard genuinely useful rather than merely functional. That knowledge cannot be prompted into existence. It is the irreducible human contribution.

My Verdict: A Tool Not a Replacement for Judgment

My smart meter dashboard works. It surfaces real insights and enables me to compare providers using my own data. It was built in an afternoon. That would not have been possible at the same pace with traditional development.

It had formatting issues that I needed to correct. The AI did the heavy lifting. I provided the judgment. That division of labour is an honest picture of what vibe coding looks like in practice.

Vibe coding is not a shortcut past engineering skill. It is a force multiplier that lets domain expertise go further and a democratising tool that enables people to build things they previously could not.

But the most interesting question is not “Can AI write code now?” It is: do you understand the problem well enough to know whether the code is solving it? That has always been the hardest part of software. It still is.

Stay tuned for the next episode in this series where we go beyond vibe coding and look at AI assisted coding for situations where the stakes are higher and vibes alone will not cut it.