{"id":487,"date":"2025-04-22T21:24:14","date_gmt":"2025-04-22T21:24:14","guid":{"rendered":"https:\/\/joskodeboer.nl\/?p=487"},"modified":"2026-04-10T14:45:00","modified_gmt":"2026-04-10T14:45:00","slug":"487","status":"publish","type":"post","link":"https:\/\/joskodeboer.nl\/index.php\/2025\/04\/22\/487\/","title":{"rendered":"Vibe coding: Faster code or faster mistakes?"},"content":{"rendered":"\n<div class=\"et_pb_section_0 et_pb_section et_section_regular et_block_section preset--module--divi-section--default\"><div class=\"et_pb_row_0 et_pb_row et_block_row\"><div class=\"et_pb_column_0 et_pb_column et_pb_column_4_4 et-last-child et_block_column et_pb_css_mix_blend_mode_passthrough\"><div class=\"et_pb_text_0 et_pb_text et_pb_bg_layout_light et_pb_module et_block_module preset--module--divi-text--default\"><div class=\"et_pb_text_inner\"><h1 id=\"vibe-coding-faster-code-or-faster-mistakes-\">Vibe coding: Faster code or faster mistakes?<\/h1>\n<p>Developer spaces are buzzing with a new term: <a href=\"https:\/\/x.com\/karpathy\/status\/1886192184808149383\"><em>vibe coding<\/em><\/a>. 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 \u2014 something that&#39;s clearly gaining traction.<\/p>\n<p>Over the past few months, I\u2019ve used tools like Cursor, Copilot, and ChatGPT in real projects. I already touched on some of that in a <a href=\"https:\/\/joskodeboer.nl\/index.php\/2024\/10\/08\/will-genai-replace-developers\/\">previous post<\/a>. But I\u2019ve 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 \u2014 mine, and those from others \u2014 and take this shift seriously.<\/p>\n<p>What do we actually gain \u2014 or risk \u2014 when we code by vibe?<\/p>\n<h2 id=\"the-positives-what-vibe-coding-gets-right\">The positives: What vibe coding gets right<\/h2>\n<p>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&#39;m trying out. When it works \u2014 as I\u2019ve written before \u2014 it feels like describing what you want to an enthusiastic junior developer who&#39;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).<\/p>\n<p>For example, in a recent Cursor-powered session, I used natural language to:<\/p>\n<ul>\n<li>scaffold a Dockerfile for a small service *<\/li>\n<li>try out  <a href=\"https:\/\/github.com\/astral-sh\/uv\"><code>uv<\/code><\/a>  instead of Poetry<\/li>\n<li>set up a basic pytest suite for some older code<\/li>\n<li>create a GitHub Actions pipeline for data validation<\/li>\n<\/ul>\n<p>* I tend to use Docker like virtual environments \u2014 it ensures the cloud runs what I run locally and feels more natural. If you want to try that, run something like <code>docker run -v .\/mycode:\/mycode --entrypoint=\/bin\/bash --rm -ti python:3.12<\/code> to drop into an interactive shell inside the container.<\/p>\n<p>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.<\/p>\n<h2 id=\"so-how-is-this-different-from-ai-assisted-programming-\">So how is this different from AI-assisted programming?<\/h2>\n<p>Simon Willison pointed out in a <a href=\"https:\/\/simonwillison.net\/2025\/Mar\/19\/vibe-coding\/\">recent blog post<\/a> that not everything involving AI counts as vibe coding.<\/p>\n<p>There\u2019s a line between <em>AI-assisted programming<\/em> \u2014 where a developer generates code, reviews it, tests it, and understands it \u2014 and <em>vibe coding<\/em> as a looser, more hands-off process. The latter implies a kind of surrender to the AI\u2019s output: working with the vibe instead of maintaining full control. Just press \u201cAccept all,\u201d talk to the AI until it sort of gets it, and move on. Don\u2019t read the code \u2014 that\u2019s the AI\u2019s problem now, right?<\/p>\n<p>That distinction really does matter. I\u2019ve seen firsthand how easy it is to let go of the wheel \u2014 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\u2019t scale to production software.<\/p>\n<p>A good example came up in the <a href=\"https:\/\/joskodeboer.nl\/index.php\/2024\/10\/08\/will-genai-replace-developers\/\">blog post<\/a> I mentioned earlier. The AI had misconnected a grid of hexagons \u2014 each tile was joined to its upper neighbor and the one above <em>that<\/em>, but not to the ones directly below. It was a subtle bug in an early scaffolding file, and I didn\u2019t catch it. I assumed the AI would\u2019ve figured that part out. It wasn\u2019t until much later in the process that the bug surfaced and I realized what I\u2019d missed.<\/p>\n<p>That\u2019s vibe coding at its worst: when you stop checking because the code <em>looks<\/em> right and the AI <em>sounded<\/em> confident.<\/p>\n<h2 id=\"the-concern-is-real\">The concern is real<\/h2>\n<p>There have already been several instances of vibe coding leading to issues \u2014 especially with inexperienced users. One developer famously leaked their API keys in a tweet containing AI-generated code. It worked, it looked fine \u2014 and it was public.<\/p>\n<p>The issue wasn\u2019t malice or carelessness \u2014 it was trust. Trusting something that looks and feels like it knows far more than it actually does.<\/p>\n<p>Then there&#39;s the knowledge cutoff problem: most models today don\u2019t know what happened after 2023. For example, if I ask for code using the <a href=\"https:\/\/pola.rs\/\">Polars 1.0 API<\/a> (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\u2019s projects feature \u2014 but that\u2019s a workaround, not a fix.<\/p>\n<p>These aren\u2019t edge cases. They\u2019re easy mistakes to make if you\u2019re moving quickly or trusting the interface too much.<\/p>\n<h2 id=\"why-enterprise-adoption-is-cautious\">Why enterprise adoption is cautious<\/h2>\n<p>At a lot of my clients \u2014 and at those of peers I\u2019ve spoken to \u2014 vibe coding hasn\u2019t 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\u2019t embraced them formally.<\/p>\n<p>The resistance is consistent:<\/p>\n<ul>\n<li><strong>Data privacy<\/strong>: Most LLMs are US-hosted, making them tricky for teams navigating GDPR or industry-specific compliance.<\/li>\n<li><strong>Trust in output<\/strong>: The code often looks great, but doesn\u2019t follow team conventions or hold up under deeper scrutiny.<\/li>\n<li><strong>Integration<\/strong>: Most tools don\u2019t plug cleanly into CI\/CD, code review, or infrastructure-as-code pipelines.<\/li>\n<\/ul>\n<p>It\u2019s often possible to use these tools \u2014 but in many of the clients I\u2019ve worked with, vibe coding simply hasn\u2019t earned a spot in production.<\/p>\n<h2 id=\"local-enough\">Local Enough<\/h2>\n<p>If you&#39;re already working inside AWS, Azure, or GCP, things get more flexible. And let&#39;s face it, almost every modern data platform is in one of these clouds.<\/p>\n<p>Let&#39;s go over the options in each cloud:<\/p>\n<ul>\n<li>AWS Bedrock gives you Claude, Mistral and others via VPC-secured APIs. You can control IAM and stay within the EU region.<\/li>\n<li>Azure Copilot ties into GitHub and Azure DevOps. It uses OpenAI models (microsoft is an early sponsor), but can stay region-bound for compliance.<\/li>\n<li>Google&#39;s Gemini + Vertex AI offers similar functionality with a more Google-native feel.<\/li>\n<\/ul>\n<p>None of these are truly local \u2014 but for many teams already deep in these clouds, they&#39;re local enough.<\/p>\n<h2 id=\"full-control-running-vibe-coding-in-house\">Full control: Running vibe coding in-house<\/h2>\n<p>For teams that want complete control \u2014 or just want to experiment in private \u2014 local setups are improving fast.<\/p>\n<p>Personally, I\u2019ve 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.<\/p>\n<p>If flexibility is required, tools like <strong>LM Studio<\/strong> and <strong>Text Generation WebUI<\/strong> 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\u2019s a great middle ground between full-stack hackery and out-of-the-box UX.<\/p>\n<p>Is this as good as GPT-4 or Claude 3 Opus? No \u2014 but it\u2019s surprisingly competent and improving fast. For common tasks, it\u2019s good enough, and it gives you a way to experiment without sending your code to anyone else.<\/p>\n<h2 id=\"vibe-coding-and-the-developer-s-intent\">Vibe coding and the developer\u2019s intent<\/h2>\n<p>Vincent Warmerdam recently reflected \u2014 warmly \u2014 on his experience with vibe coding in a <a href=\"https:\/\/koaning.substack.com\/p\/code-with-vibes-vibes-with-discipline\">Substack post<\/a>. He didn\u2019t write from a technical angle, but from the perspective of building things with care \u2014 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&#39;re sometimes mistaking momentum for progress.<\/p>\n<p>As he puts it:<\/p>\n<blockquote>\n<p>\u201cI\u2019m happy to toy with code, but I am unwilling not to toy with ideas.\u201d<\/p>\n<\/blockquote>\n<p>That line stuck with me \u2014 because it gets at the core of what vibe coding both enables and threatens. Implementation is getting easier, but that doesn\u2019t mean we should brainstorm less, or stop learning from the code we write. If anything, it\u2019s the opposite: now that it\u2019s easy to generate 80%, we need to take full responsibility for the last 20% \u2014 the part where things get difficult, and where most of the value lives.<\/p>\n<p>Vincent also reminds us that it\u2019s worth writing tools for yourself \u2014 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\u2019re shipping.<\/p>\n<p>It\u2019s not about gatekeeping. It\u2019s about doing yourself a favour \u2014 staying grounded, even when the tools get slicker.<\/p>\n<h1 id=\"final-thoughts\">Final thoughts<\/h1>\n<p>Vibe coding isn\u2019t a replacement for proper engineering \u2014 and it never will be. But it\u2019s not just a gimmick either. In experienced hands, it\u2019s a tool that makes building faster. Used carelessly, it hides bugs and shaky design behind a layer of confident-sounding output.<\/p>\n<p>It\u2019s real, reusable, and evolving fast. If you haven\u2019t tried it yet, now\u2019s probably a good time to take a look. And if you\u2019re already using it \u2014 I\u2019d love to hear what you\u2019ve seen.<\/p>\n<p>It\u2019s a tool \u2014 but only if we stay present, thoughtful, and intentional.<\/p>\n<\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[15,9],"tags":[],"class_list":["post-487","post","type-post","status-publish","format-standard","hentry","category-ai","category-software-engineering"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/posts\/487","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/comments?post=487"}],"version-history":[{"count":4,"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/posts\/487\/revisions"}],"predecessor-version":[{"id":557,"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/posts\/487\/revisions\/557"}],"wp:attachment":[{"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/media?parent=487"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/categories?post=487"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/joskodeboer.nl\/index.php\/wp-json\/wp\/v2\/tags?post=487"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}