Skip to content
Tech News
← Back to articles

I Don't Vibe Code

read original more articles
Why This Matters

This article highlights a personal perspective on the limitations and personal preferences regarding Large Language Models in coding. While LLMs promise increased productivity, not everyone finds them useful or worth the cost, emphasizing the importance of individual workflows and values in adopting new tech. It underscores that technological advancements may not resonate with all users, especially those with different priorities or skepticism about costs.

Key Takeaways

There has been a lot of discussion online lately about vibe coding and and how Large Language Models (LLMs) will revolutionize the field of software development. Every new model will launch us into realms of pure productivity, shipping software at the speed of thought and removing all the friction and 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 of LLMs at depth here in this piece, but it’s just never clicked for me 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 have been useful for some tasks that are simple enough to be easily describable but annoying enough to not just do them myself. For instance, resizing a grid of square images to be smaller. I could go look at the command-line arguments for ImageMagick, but that was a perfect thing to ask the AI to do. I then tried using one of the AI tools to analyze my code in a project and a few other small tasks before it all came to an awkward halt. The system informed me that I had just run out of credits and I would need to 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 sides of my family tree. We’ve been pinching pennies and hunting bargains for centuries both here and on the other side of the Atlantic. As an example, one of my distant ancestors died during the King Philip’s War because he left the safety of the fort to retrieve some cheese he had left behind when evacuating his house. So you must believe me that the idea of paying a service in perpetuity so I could think just seemed so laughably absurd and horrific that I didn’t even bother giving them my card. I closed the laptop. I uninstalled the IDE and went back to using Emacs even. And I realized 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 an industry that calls a developer with 5 years of experience a “senior engineer.” Experience is a welcome antidote to anxiety sometimes (as long as it’s not anxiety about ageism in an industry that calls a developer senior with only 5 years of experience) , and the AI hype doee remind me of earlier breakthroughs in low and no-code tooling. I don’t doubt that AI can be a useful tool for developers. I know there are tasks it can help with as better tooling. But these arguments always leave me thinking about the accidental and essential complexity again.

Fred Brooks was old even when I was a young coder myself. As the project manager for IBM’s System 360 line of mainframes (and accompanying operating system) he had a front row seat to when all the now common ways software projects go wrong were novel and new. He collected these observations in a book The Mythical Man-Month which should still be required reading for software engineering courses today. My edition was a newer reprint that included a later essay titled “No Silver Bullet” where Brooks looked at the effect that new tools can have on developer productivity. To think like a programmer, you must understand that the real world is complex. Programming can be best thought of as imposing simplified representations – we call them _abstractions – on top of our messy reality to make it understandable by reducing complexity. This lets us generalize specific situations into layers that can be built on top of each other. For instance the specific action of putting peanut butter onto a piece of bread could be generalized into a spread(substance) method that could take peanut butter or cream cheese as an argument. And we could use these spread methods to create higher-level functions like create_pbj() and so on. Coding in a modern high-level programming language is like standing on top of a ziggurat of abstractions, where a single line of code could trigger millions of operations on multiple systems. It’s very exciting!

Now, what if we could keep going and abstract away the act of programming itself? This is the dream of agentic AI, where swarms of agents can be given tasks to implement on their own without supervision. Sounds great! But this is addressing what Brooks calls accidental complexity, the things that are complicated about writing code itself. In the time since the essay was written, software development has made great strides against this type of complexity. Instead of writing in low-level machine code, we can use modern dynamically interpreted languages which are compiled to assembly. Instead of remembering how to write a quick sort (trust me, you’re going to want to click that link) from scratch, I just need to call a sort method in a standard library. Instead of having to build a whole web application from scratch, I can use an existing framework. If I want to rename or restructure some code, my editor can help do that for me. AI seems like the latest iteration and some editors have already replaced their predictable old tooling for renaming and refactoring code with unpredictable AI agents. Sure, it might seem like rolling the dice, but how common is a critical failure anyway?

... continue reading