Vibe coding: Faster code or faster mistakes?
Developer spaces are buzzing with a new term: vibe coding. It refers to the growing habit of writing code not line-by-line, but by prompting a large language model (LLM) to do the heavy lifting. The name was coined by Andrej Karpathy earlier this year and has become shorthand for natural language-driven development — something that's clearly gaining traction.
Over the past few months, I’ve used tools like Cursor, Copilot, and ChatGPT in real projects. I already touched on some of that in a previous post. But I’ve been thinking more about where these tools actually help, where they fall short, and where the hype is running ahead of reality. This post is an attempt to gather those thoughts — mine, and those from others — and take this shift seriously.
What do we actually gain — or risk — when we code by vibe?
The positives: What vibe coding gets right
Vibe coding is genuinely brilliant for prototyping. You can spin up scaffolding, explore an unfamiliar framework, sketch out unit tests, and iterate over API designs by talking to your editor. I often use this for toy projects or to get familiar with new tools I'm trying out. When it works — as I’ve written before — it feels like describing what you want to an enthusiastic junior developer who's read a lot of Stack Overflow and is ready to move fast and break things (which vibe coding definitely has done and will do).
For example, in a recent Cursor-powered session, I used natural language to:
- scaffold a Dockerfile for a small service *
- try out
uvinstead of Poetry - set up a basic pytest suite for some older code
- create a GitHub Actions pipeline for data validation
* I tend to use Docker like virtual environments — it ensures the cloud runs what I run locally and feels more natural. If you want to try that, run something like docker run -v ./mycode:/mycode --entrypoint=/bin/bash --rm -ti python:3.12 to drop into an interactive shell inside the container.
The outputs were definitely not perfect, but they were fast and easy to tweak. If you already understand the shape of what you want to build, vibe coding will be a meaningful way to move quickly.
So how is this different from AI-assisted programming?
Simon Willison pointed out in a recent blog post that not everything involving AI counts as vibe coding.
There’s a line between AI-assisted programming — where a developer generates code, reviews it, tests it, and understands it — and vibe coding as a looser, more hands-off process. The latter implies a kind of surrender to the AI’s output: working with the vibe instead of maintaining full control. Just press “Accept all,” talk to the AI until it sort of gets it, and move on. Don’t read the code — that’s the AI’s problem now, right?
That distinction really does matter. I’ve seen firsthand how easy it is to let go of the wheel — to generate multiple iterations, pick the one that runs, and skip the review. (Obviously that was a long time ago. I always review now.) That kind of flow might work for an internal tool or throwaway script, but it shouldn’t scale to production software.
A good example came up in the blog post I mentioned earlier. The AI had misconnected a grid of hexagons — each tile was joined to its upper neighbor and the one above that, but not to the ones directly below. It was a subtle bug in an early scaffolding file, and I didn’t catch it. I assumed the AI would’ve figured that part out. It wasn’t until much later in the process that the bug surfaced and I realized what I’d missed.
That’s vibe coding at its worst: when you stop checking because the code looks right and the AI sounded confident.
The concern is real
There have already been several instances of vibe coding leading to issues — especially with inexperienced users. One developer famously leaked their API keys in a tweet containing AI-generated code. It worked, it looked fine — and it was public.
The issue wasn’t malice or carelessness — it was trust. Trusting something that looks and feels like it knows far more than it actually does.
Then there's the knowledge cutoff problem: most models today don’t know what happened after 2023. For example, if I ask for code using the Polars 1.0 API (released July 2024), I get outdated syntax and confident hallucinations of pandas-like usage. You can paste documentation into your prompt or use retrieval-augmented generation (RAG) via something like ChatGPT’s projects feature — but that’s a workaround, not a fix.
These aren’t edge cases. They’re easy mistakes to make if you’re moving quickly or trusting the interface too much.
Why enterprise adoption is cautious
At a lot of my clients — and at those of peers I’ve spoken to — vibe coding hasn’t made it into production workflows, even when GitHub Copilot is available. In many cases, developers are already using LLMs on the side, but the organization itself hasn’t embraced them formally.
The resistance is consistent:
- Data privacy: Most LLMs are US-hosted, making them tricky for teams navigating GDPR or industry-specific compliance.
- Trust in output: The code often looks great, but doesn’t follow team conventions or hold up under deeper scrutiny.
- Integration: Most tools don’t plug cleanly into CI/CD, code review, or infrastructure-as-code pipelines.
It’s often possible to use these tools — but in many of the clients I’ve worked with, vibe coding simply hasn’t earned a spot in production.
Local Enough
If you're already working inside AWS, Azure, or GCP, things get more flexible. And let's face it, almost every modern data platform is in one of these clouds.
Let's go over the options in each cloud:
- AWS Bedrock gives you Claude, Mistral and others via VPC-secured APIs. You can control IAM and stay within the EU region.
- Azure Copilot ties into GitHub and Azure DevOps. It uses OpenAI models (microsoft is an early sponsor), but can stay region-bound for compliance.
- Google's Gemini + Vertex AI offers similar functionality with a more Google-native feel.
None of these are truly local — but for many teams already deep in these clouds, they're local enough.
Full control: Running vibe coding in-house
For teams that want complete control — or just want to experiment in private — local setups are improving fast.
Personally, I’ve set up OpenWebUI as a conversational front-end, with Ollama hosting open models like Mistral or LLaMA 3 locally. With quantized models, this gives a surprisingly decent local experience.
If flexibility is required, tools like LM Studio and Text Generation WebUI offer more advanced configuration options. LM Studio, in particular, simplifies downloading, managing, and running a wide range of models. It includes a built-in chat UI that can connect to local endpoints or be extended with custom prompt tooling. It’s a great middle ground between full-stack hackery and out-of-the-box UX.
Is this as good as GPT-4 or Claude 3 Opus? No — but it’s surprisingly competent and improving fast. For common tasks, it’s good enough, and it gives you a way to experiment without sending your code to anyone else.
Vibe coding and the developer’s intent
Vincent Warmerdam recently reflected — warmly — on his experience with vibe coding in a Substack post. He didn’t write from a technical angle, but from the perspective of building things with care — and the risks of moving too fast. He describes something many of us recognize: a growing pile of abandoned projects and the uncomfortable sense that we're sometimes mistaking momentum for progress.
As he puts it:
“I’m happy to toy with code, but I am unwilling not to toy with ideas.”
That line stuck with me — because it gets at the core of what vibe coding both enables and threatens. Implementation is getting easier, but that doesn’t mean we should brainstorm less, or stop learning from the code we write. If anything, it’s the opposite: now that it’s easy to generate 80%, we need to take full responsibility for the last 20% — the part where things get difficult, and where most of the value lives.
Vincent also reminds us that it’s worth writing tools for yourself — not just because you need the tool, but because the act of building something teaches you how it works. AI can be a part of that, but only if you stay present. You still need to read what you’re shipping.
It’s not about gatekeeping. It’s about doing yourself a favour — staying grounded, even when the tools get slicker.
Final thoughts
Vibe coding isn’t a replacement for proper engineering — and it never will be. But it’s not just a gimmick either. In experienced hands, it’s a tool that makes building faster. Used carelessly, it hides bugs and shaky design behind a layer of confident-sounding output.
It’s real, reusable, and evolving fast. If you haven’t tried it yet, now’s probably a good time to take a look. And if you’re already using it — I’d love to hear what you’ve seen.
It’s a tool — but only if we stay present, thoughtful, and intentional.