I’ve been thinking recently about how to best understand why “vibe coding” isn’t programming. Then I realised that long ago, a man named Aesop wrote a fable that explains it perfectly. I’ve always said that “rushing takes longer,” and that’s exactly what vibe coding is.
1
A Vibe Coder was making fun of the Programmer one day for being so slow.
“Do you ever finish a project?” he asked with a mocking laugh.
“Yes,” replied the Programmer, “and I get there sooner than you think. I’ll compete with you a code jam and prove it.”
The Vibe Coder was very amused at the idea of competing in a code jam with the Programmer, but for the fun of it he agreed. So the User, who had agreed to act as judge, set the requirements and started the competitors off.
The Vibe Coder was soon finished with his product, and to make the Programmer feel just how ridiculous it was for him to try a code jam with a Vibe Coder, he lay down on his keyboard to take a nap until the Programmer caught up.
The Programmer meanwhile kept going slowly but steadily, and after a time managed to create several iterations of his project while the Vibe Coder was sleeping. But the Vibe Coder slept on very peacefully, and when at last he did wake up, the Programmer was fixing the last few bugs in his code. The Vibe Coder now ran his program, but he could not iterate and fix the bugs the Programmer had fixed in time.
Slow and steady wins the code jam.
2
There are some fundamental flaws with using generative AI for projects. It can produce code fast, but a major flaw I’ve found is that LLMs cannot iterate effectively. Basically imagine if instead of fixing a bug in your code, you instead scrapped all the code and rewrote it from scratch hoping that one bug would be fixed. That is what an LLM does every time you ask it to fix or change something. It isn’t taking the original and modifying it, it’s creating something entirely new every time.
This is why slow and stead wins here. The vibe coder will create a product fast, but when it comes to tweaking the product, or fixing the bugs, they will struggle. They don’t have the base knowledge to do these things, and even if they do the code they have will be a complete black box to them. Asking AI to fix it will only introduce new bugs and unwanted changes.
I’ve experimented with AI, and I have found it useful for spotting bugs or suggesting improvements to code I’ve already written. But the more I use it, the less I end up using it. I’ve found that relying on it too much can slow me down, lead to unmaintainable code, or often just suggest code that is plain wrong. I’ve found that writing my own code from scratch, slow and steady, has always created a better product.
Image Credit: Ömür Akif DİNÇ
