Why I Don’t Vibe Code | jacobharr.is
March 05, 2026
A "brief" accounting of various reasons why vibe coding has just never clicked for me personally as a developer.
https://jacobharr.is/personal/i-dont-vibe-code
Why I Don’t Vibe Code
Personal
Why I Don’t Vibe Code
March 05, 2026
A "brief" accounting of various reasons why vibe coding has just never clicked for me personally as a developer.
There has been a lot of discussion online lately about vibe coding and and how<br>Large Language Models (LLMs) will revolutionize the field of software<br>development. Every new model will launch us into realms of pure productivity,<br>shipping software at the speed of thought and removing all the friction and<br>overhead of product development. Or something like that.
Maybe. I’ll have to take your word for it. I don’t vibe code.
If it’s working for you, great! I’m not really here to argue the merits or flaws<br>of LLMs at depth here in this piece, but it’s just never clicked for me<br>personally. This page is a “brief” accounting of various reasons why.
I’m a Cheapskate
I’m not a purist. I’ve tried using LLMs that are integrated into an IDE. They<br>have been useful for some tasks that are simple enough to be easily describable<br>but annoying enough to not just do them myself. For instance, resizing a grid<br>of square images to be smaller. I could go look at<br>the command-line arguments for ImageMagick, but that was a perfect thing to ask<br>the AI to do. I then tried using one of the AI tools to analyze my code in a<br>project and a few other small tasks before it all came to an awkward halt. The<br>system informed me that I had just run out of credits and I would need to<br>provide a credit card to purchase more tokens I wanted to keep going.
Now, you must understand that I come from a long line of cheapskates from both<br>sides of my family tree. We’ve been pinching pennies and hunting bargains for<br>centuries both here and on the other side of the Atlantic. As an example, one of<br>my distant ancestors died during the King Philip’s<br>War because he left the<br>safety of the fort to retrieve some cheese he had left behind when evacuating his<br>house. So you must believe me that the idea of paying a service in perpetuity<br>so I could think just seemed so laughably absurd and horrific that I didn’t<br>even bother giving them my card. I closed the laptop. I uninstalled the IDE and went<br>back to using Emacs even. And I realized<br>that I just didn’t even notice the lack anymore.
I’m Old
It does help that I’m old. I’ve been writing code for a long time, especially in<br>an industry that calls a developer with 5 years of experience a “senior<br>engineer.” Experience is a welcome antidote to anxiety sometimes (as long as<br>it’s not anxiety about ageism in an industry that calls a developer senior with<br>only 5 years of experience) , and the AI hype doee remind me of earlier<br>breakthroughs in low and no-code tooling. I don’t doubt that AI can be a useful<br>tool for developers. I know there are tasks it can help with as better tooling.<br>But these arguments always leave me thinking about the accidental and essential<br>complexity again.
Fred Brooks was old even when I was<br>a young coder myself. As the project manager for IBM’s System 360 line of<br>mainframes (and accompanying operating system) he had a front row seat to when<br>all the now common ways software projects go wrong were novel and new. He<br>collected these observations in a book The Mythical<br>Man-Month which should<br>still be required reading for software engineering courses today. My edition was<br>a newer reprint that included a later essay titled “No Silver<br>Bullet” where Brooks looked at<br>the effect that new tools can have on developer productivity. To think like a<br>programmer, you must understand that the real world is complex. Programming can<br>be best thought of as imposing simplified representations – we call them<br>_abstractions – on top of our messy reality to make it understandable by<br>reducing complexity. This lets us generalize specific situations into layers<br>that can be built on top of each other. For instance the specific action of<br>putting peanut butter onto a piece of bread could be generalized into a<br>spread(substance) method that could take peanut butter or cream cheese as an<br>argument. And we could use these spread methods to create higher-level<br>functions like create_pbj() and so on. Coding in a modern high-level<br>programming language is like standing on top of a ziggurat of abstractions,<br>where a single line of code could trigger millions of operations on multiple<br>systems. It’s very exciting!
Now, what if we could keep going and abstract away the act of programming<br>itself? This is the dream of agentic AI, where swarms of agents can be given<br>tasks to implement on their own without supervision. Sounds great! But this is<br>addressing what Brooks calls accidental complexity, the things that are<br>complicated about writing code itself. In the time since the essay was written,<br>software development has made great strides against this type of...