Why I Don’t Vibe Code

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 CheapskateI’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 OldIt 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?However, even as the better tooling has diminished accidental complexity, essential complexity still remains. There still is the complicated work of designing our abstractions and systems the right way, one that is elegant, clear and maintainable. And that complexity isn’t going anywhere. This type of work takes skill and experience and wisdom hard-won from system failures past. And, I’m not sure if LLM’s fancy autocomplete approach works so well with this type of complexity, which often isn’t so straightforward to solve. Maybe with prompting, it could be guided toward a preferred approach, but at that point the person doing the guiding might as well design the approach alone, since the LLM wouldn’t be able to articulate why it chose a certain path. Essential complexity is often weird and rare and messy. Maybe I’m wrong and the models are getting better at these kind of messy situations as well, but I’ve found that it often requires a specific kind of mindset and approach. Luckily for me, I love the messy stuff.I Love MessI’ve been talking so far about how software can abstract processes, but we also use abstraction’s reductive properties as a tool to understand the world.

In the classic book Seeing Like a State, James Scott describes how the motivating project of the post-enlightenment was to make their populations and possessions legible through abstraction and categorization. To measure is to modify. For instance, a country might begin to look at its forests not as complex ecosystems but just assessed by their percentages of timber that can be used for ship-building. This view then allows a country to act on this information in ways like replacing those forests with monocultures of just a single tree. A forest is abstracted into a system for growing ship masts.This approach created the bureaucracy and the paper form, which has evolved into the web form and database. As programmers, we need to reduce the messy data of the world in order to act on it. We expect our dates to be exact. We expect names to be relatively simple. We expect data to be complete at time of entry and consistent over time. Every programmer and every system design is a series of Procrustean choices about what aspects of reality we want to reflect in our systems and what we can discard. I’m not saying this to criticize; this approach is the only way to build systems that aren’t bogged down in an endless thicket of special situations (what we call “edge cases” because they’re supposed to be rare paths on the periphery). But, this process is so innate that we sometimes forget that it is also artificial, especially when it’s describing people. Forcing a gender field to only accept “male” or “female” doesn’t force gender itself to be binary. Our definitions of race are social constructions that shift all the time. Our simplified model might provide us with insights (autism diagnoses have increased 300% over the last 20 years!) but not capture the underlying factors behind those insights (it’s likely just a result of changes in how we define autism and increased screening). It’s important to step back and look at the bigger picture of how any model was made and what type of knowledge it doesn’t capture. Every abstraction is also an occlusion.

As a data journalist, I learned how to interview data and how to be highly rigorous about all the ways in which the answers I found could be misleading. Paranoia is the data journalist’s best friend, if you want to avoid an embarrassing correction.. You need to be able to think about not just what the data says, but all the stuff it doesn’t include.Unfortunately, this metacognition is something an LLM can’t ever do. The model is their reality. As Robin Sloan succinctly notes in his compelling essay “Are Language Models in Hell?”, AI models are built from and view the world in a stripped-down way. Where you and I might look at text and see its context (things like the text formatting and titles, the author’s bio, the site where this was linked from), the LLM operates purely on a world of letters and nothing more (technically, they’re receiving subword tokens, which is why early models couldn’t count the letter ‘r’ in strawberry). Asking a LLM to recognize the limitations of its view on reality is like asking a goldfish how the water is.When I was writing this section, I have been thinking about DOGE’s inept attempts to find fraud at the Social Security Administration. In one example, DOGE looked at the SSA databases and discovered there were over 9 million records in there with birth dates over 120 year ago but no death dates recorded. Elon Musk declared the only possible explanation was that millions of people were fraudulently receiving benefits. He was wrong about both the cause of the problem and the severity of its impact. DOGE could’ve questioned the data quality. They could’ve examined payments being made. They could’ve asked any of the experts at SSA to explain it to them. But instead they took the data as it is and leaped to wrong conclusions, a pattern they repeated over and over (as in this example of a different fraud claim about payments): In the extensive analysis that followed, agency experts carefully documented fallacies in DOGE’s work, according to documents reviewed by The Times and those people.