Vibe Coding is the latest AI trend to capture the imagination, filling up the column inches since Andrej Kaparthy coined the term a couple of months ago:
Once again there are mutterings that this is the end of software development as we know it - now you just describe the application that you want and an LLM builds it for you, with a little iteration of course. These applications might have some security holes of course, and the downside to simply trusting the LLM is that you may well promote them to production:
But leaving that aside, what a world we live in where everyone is now in a position to vibe code a copy of Salesforce and roll their own CRM. Even if that unlikely proposition is true, it’s probably not where we want to end up. A history lesson based on my own experience might show why I feel that way.
For many years I worked in the professional services arms of various product companies, long before these SaaS days where you just pony up a subscription and you are in business. Often we’d demo our product to prospects and they would decide that this looked straightforward and they’d rather build it themselves. Sometimes this ended badly - they spent millions, found it was a lot harder than they thought, then came back to us. Those re-engagements were the best, let me tell you!
This wasn’t alway the case though, many times it ended well, at least initially. The prospect would leverage their internal developers and build (copy) the application tailored entirely to their own needs. Usually these suffered a little from not being future-proofed, as developing software wasn’t their core business so the investment would be limited, but certainly good enough to use.
As an inevitable side effect they ended up with an application that had an installed base of 1 - themselves. This meant if they hit problems they were on their own to fix them - no raising with the vendor or checking with other customers to see how they’d worked around it. Not a big problem though, as the development team were right there to dive in.
Bigger problems tended to come a couple of years later when the original developers had moved on. As it was a custom solution, it was impossible to hire people who could hit the ground running from a maintenance perspective. Plenty of people could get there, but it would be 3-6 months for them to understand the entirety of the system and become fully productive.
But here’s the clincher - nobody wanted those jobs. Or nobody wanted them if there were any other jobs available, so anyone they hired turned out to be using it as a stop gap until they could find something better. Turns out developers weren’t that interested in gaining skills in an application that wasn’t used anywhere else and thus would add nothing to their marketability. Instead those developers wanted to learn about software that was used everywhere so that once they gained a level of competence they would be in demand. Software that was used in one place gave them concerns about heading up a dead end road.
Suddenly maintenance became a problem. Not for the big financial services prospects, as they had plenty of money to throw at it, but absolutely for those where the CIO was now having to pay well over market rate to get anyone to work on their applications and the CFO was very unhappy about it.
Now don’t get me wrong, I have no objection to vibe coding in principle - I think programming is awesome and anything that helps people get started should be encouraged. There’s no feeling like firing up something you built yourself that gives you real value. I just think it’s better suited to personal productivity tools rather than systems that your business depends upon, unless you are already an experienced developer. Devclass covered this rather nicely in their article The paradox of vibe coding: It works best for those that don’t need it.
While having a behemoth like Salesforce with over 150,000 customers isn’t to everyone’s taste, having 150,000 different CRM systems to manage sounds much worse, even if it would likely lead to a lot more work for us software developers after all.