FREE VIBES: Laziness makes you a better builder
Unintuitive advice from war and Elon on building effectively
Elon famously says that he prefers to hire lazy people because “You can always count on a lazy person only wanting to do something one time”. This sounds like Elon being himself, but it’s one of the most important lessons to learn in building software. You aren’t building to repetitively do work over and over, you’re building to not do a certain thing ever again. The goal of all software, at it’s core, is automation.
In World War II, there was a general that categorized his officer ranks into four groups. The first was Intelligent and lazy, he posited that these people were suited for command because you could count on them finding the easiest way to do something (seeing a pattern here?). The second group was intelligent and industrious, he said that this group was suited for high level staff positions, meaning they were capable of a lot of value but shouldn’t be in charge because of a propensity to prioritize doing any work over doing the right work. The third group was lazy and stupid. Ironically, he did not think this was the worst group. He posited that the lazy and stupid were an unfortunate byproduct of the system, but you could always find a place for them. The fourth group, stupid and industrious, he ordered to immediately be removed from the officer ranks and dismissed from the army. His firm belief was that this most dangerous group was capable of a ton of organizational harm and had to be identified and appropriately managed.
This is a lot like building with LLMs, and it’s also what you as a builder using LLMs needs to watch out for in your own building. The current AI coding systems are the epitome of stupid and industrious. You can watch this in action just by allowing one to code a project without intervening. Things get out of hand quick.
What does this mean for vibe coding? It means the best skill that you can possibly work on is asking the right questions, because LLMS are great at contextualizing, but they have really poor insight. Move slowly and deliberately, ask the right questions, and treat every piece of code you push like you never want to touch that code again.
Now, go build some shit.
-Nate