There have been many discussions about this notion floating around over the past year with the premise of building software with little to no payoff from actually reading, or even understanding, the code. This has spawned with the rise of AI tooling. While this has become an accurate description of work for many people, especially on quick prototypes and personal projects, it is important to also understand its boundaries.
It is very easy to understand why it has become popular. Small code or scripts that exist for personal usage do not warrant an extensive investment of work to fully cognize every detail. If the objective is simply to check a box, and there are no real world implications that would allow for failure, then this notion of “vibe coding” will actually be more efficient… and let’s be real, the rest of us have been doing the same thing for as long as we have been building.
Where it really falls apart is when things actually get serious. Underserved code isn’t served code at all. It can’t be properly debugged. Something will eventually break. Code you don’t understand can’t be extended safely. Everything you add through poorly understood code will eventually come back and bite. Because you don’t understand it, you won’t know why or from where it will bite. If AI is used properly and strategically as a legitimate accelerant, the difference will be stark. The difference will be most seen at the worst possible time, in the middle of a messy situation where a deployment is being done and something catches fire.
The approach that will be most sustainable is not avoiding AI tools. It is to to treat every ‘suggestion’ as something you read and understand before bringing it into your code. It is the small, but necessary, shift of considering what you are going to do before action, not after. The development or writing of code will be done at record speed, but the code itself will not be a mystery to the many people who will eventually work with it.