Software craftmanship and the rise of vibe coding
Vibe coding. Generating software based on ideas, rather than coding by hand. The first time I heard the term, I wasn’t a fan. Over the past years, ‘vibe’ has been Gen Z meets late Millennial online slang for a mood, a feeling, something that you sense but can’t quite describe. The way you meet someone and instantly know: their vibes are off. How you’re just relaxed at a social gathering without feeling pressured to engage: I’m just vibing. The term being used for something AI-related seemed to signify the beginning of its end. But as it turns out, vibing as slang is as tenacious as AI; so maybe the two go together after all.
(image: a white feminine person with light hair and a white shirt relaxing in an office chair, with headphones on, eyes closed, surrounded by documents and a laptop — representing being relaxed and ‘vibing’ at work)
For the past weeks I’ve been trying out vibe coding using Cursor and I quickly found out that vibe coding is actually really fun! You prompt, and it codes, at lightning fast speeds. Code just flew down my screen, hundreds of lines in mere seconds, and I had something working within a fraction of the time it would have taken me to code by hand. I recently released a CLI tool I made with it. But did I make it, really? Honestly, it went so fast and it worked so easily that I didn’t feel very motivated to review any of the changes.
This is, of course, by the standards of most developers, an absolutely terrible idea.
Software programming has always been deterministic, precise, intentional. All code is put through strict code quality tools, automated tests, and human reviews. Certainly nothing gets through based on vibes. But that’s exactly what AI coding tools like Cursor enable you to do.
Vibe coding and everything it entails and enables is directly at odds with the software craftmanship philosophy: the ideal that each character in code matters, each line should be meticulously, intentionally, put there for a very clear and specific reason. Code must be clean, hygienic, lean. Of the utmost quality with the most perfect metrics, no “mess”.
We do this because we’ve learned the hard way that messy bloated code results in bugs and is hell to maintain. And in an ideal world when we’re building software we would be afforded the time and effort to create that perfectly squeaky clean code, right? Of course, that usually doesn’t happen.
Whether it’s because of Product timelines, budget limitations, a lack of developer experience, a lack of quality tooling, or you’re working with a ton of legacy; the very code you’re wrangling every day is very far from perfect or maintainable. But it’s what we aspire to have, right? That beautiful layered system built according to modern paradigms like DDD; complex in its features yet simple to understand, easy to maintain and difficult to break. The reality is, even if we manage to somehow build that system, it’s only a matter of time before it degrades. I’ve yet to see a software application that actually meets our developer hopes and dreams. But perhaps that’s the point — those lofty goals put us on the path to building better software. Even if we never make it to perfection, we can get closer to it. Our code becomes at least somewhat better, and we can deliver new features and refactors with less bugs, higher reliability, and a more coherent structure for the developers that come after us (including our future selves).
But there’s more to software craftmanship than just perfectionism. The term itself implies a certain dedication to creativity. Something that is crafted, with actual thought and intent behind it, brought into existence by someone who is an expert. Software made by someone not only skilled, but passionate. Programmers genuinely care about the code they write, whether they realize it or not, and get attached to it; prickly about criticism on it, resistant to changing it, but still dedicated to improving it. It takes effort to write good code, starting from its mental conceptualization, to putting all the pieces together and seeing the data flow through and do exactly what you want it to do. That effort then translates into being invested in the software being good, and working, and maintainable, and nice to work with.
I’ve been a PHP developer for almost 20 years and the current state of the PHP ecosystem is testament to how many developers genuinely care, and have dedicated their career to making it better. Nobody asked, let alone demanded from a business perspective, for us to build tools like Composer and PHPStan, frameworks like Symfony and Laravel, and so many many more pieces that have made our programming language the mainstay of the web. (Next time someone tells you PHP is dead, point out that possibly ¾ths of the web runs on it.)
Caring about what you’re making is essential to making it good. This doesn’t just apply to software but to everything in our short human lifespans and beyond it. When we care about ourselves, we tend to invest more time and effort into our mental and physical health. When we care about others, we make time for them, and we tell them how we feel. When we care about our home, we make at least some effort to have it be clean and look nice.
Vibe coding has plenty of problems already frequently pointed out by critics that I think are still somewhat solvable. Hallucinations only seem terrible until you consider that human coders make mistakes all the time. We can use deterministic tools like static analysis and automated tests to check generated code, just like we check human code. We can use security and vulnerability auditing to patch the gaps that AI coding agents might have left. But the one thing we can’t fix is apathy.
During my vibe coding experience I noticed that I didn’t care about the code at all. I ask, the agent codes, and I just can’t be bothered to even review it because it’s not something I put effort into in the first place. And that’s a problem. If I don’t care about what it generates, I don’t care about maintaining it or making it better. I guess I can instruct the agent itself to make it better, but the only way to be sure it actually did improve something is to do a manual review and QA test. Which I didn’t feel motivated to do, because I wasn’t invested to begin with. And if you inquire with your more AI-skeptical colleagues and developer peers, you’ll find that most if not all of them really don’t want to spend their time reviewing generated code. And… that’s a pretty fair sentiment. If I don’t even care enough to review my generated code, why would they?
Does vibe coding still have a place, then? Absolutely! As I stated before… it’s fun. I find it actually inspiring, unblocking my ideas by just getting them out there. It can be difficult to start something; it’s easier to change that which already exists, than to bring it into being. And whilst you can always start small, there is also a lot of bootstrapping drudgery that’s patently uninteresting.
Yet… it’s precisely the difficulty of the act of creation that adds meaning to the thing. Making something out of nothing isn’t easy — anyone who’s attempting to do anything creative (it’s literally right there in the word) can tell you that. And that’s exactly why people care about their own creations and the creations of others.
So is vibe coding even useful or wise for enterprise-level applications? Is it something you should want to send to your peers for review? Is it something you should, or even could care about? Could a vibe-coded application form the basis of new, revolutionary, open-source, community-engaging software that inspires thousands of developers? I have my doubts. But maybe it doesn’t have to be all that, anyway.