If I asked my mum what a software engineer was, she'd be able to put two and two together: they engineer software. If I repeated the question but asked what a vibe coder was, I'd be met with confusion. "They are coding vibes?" Not really. "They are vibing the code?" Closer, but what does 'vibing' even mean? The term 'vibe coding' has become too vague and too difficult to understand. There's a noticeable gap between well-built and badly-built vibe coded software, and the term tells you nothing about which you're getting, unlike traditionally engineered software, where the gap is far easier to measure. I have no interest in opposing vibe coders here. Instead, I want to shed light on a possible new branch of an informal discipline that I like to call DIY software development, a term that lets us discern development that follows best practices from code written willy-nilly.
The rest of this extract assumes you know what a software engineer/developer is and what a vibe coder is. It also assumes that you agree (or at least understand) that a SWE can be a vibe coder and a vibe coder can be a SWE, but that it would not always be true. For us to gain an understanding of what DIY software development looks like, we'll be looking at the idea of DIY itself.
What is DIY
Self-explanatory enough: do it yourself. There's a tap you ordered to replace the one on your bathroom sink, you could probably do it yourself. Your car needs its brakes fixed and you don't want to spend money on a mechanic, perfect, you can do that yourself too. You want to fix a bug in your app without having to call the engineer, look at that, you can do it yourself again. Now, none of these scenarios assume your skill level or your professional certificates. It's simply an 'if you're confident enough, you can DIY it' model. The reason DIY is so popular is that you save money, you learn something new, and it gives you that warm fuzzy feeling that you did something. You don't have to spend money getting a plumber, a mechanic or a developer to come and fix your issues, you've (hopefully) already solved them. Now look at that money saved, and the bathroom sink is looking great.
Then why do we need professionals
A year later, your tap is still going strong. Your car, on the other hand, has an MOT due, so you take it in — where your DIY brakes are put to the test, and fail. In fact, the people running the MOT test are surprised you're still alive. You now have to take the car to a mechanic and pay them to fix what you did on top of the original issue, unless you want to take a crack at DIYing it again. When you watch the mechanics do their job, they do a lot of steps you might have missed or skipped. They check component compatibility, they write down which parts were replaced and when, and they let you know what happened and how what they're doing will make sure the brakes won't be a bother for another three years.
Similarly, let's get back to the bug you 'fixed' that is causing other issues elsewhere. An engineer comes along (you caved in and hired one this time), sees your fix, and approves! But the issue is that you didn't add or update tests for it. There is no documentation on this fix, and there is a microservice that expects an input a certain way that you changed so your bug would be 'fixed'. The engineer does these things: updating documentation so that humans and AI know what to expect when they work on your app, and creating relevant new tests so that production doesn't even smell faulty code. The engineer, like the mechanic, takes care of the things that are never mentioned in a CV but always expected from a professional. Of course, if you're developing a personal project at home that only you will ever use whenever a pink moon rises… DIYing is fine.
Discerning DIY vs professional
As with other DIY operations, it comes down to how closely you're following standards. The more of the following questions you can answer yes to, the closer you are to 'professional':
- Are you adding and updating tests as you go along?
- Are you adding and updating documentation as you go along?
- Are you maintaining clean code?
- Are you minimising technical debt?
Basically:
Could someone else take over your project tomorrow?
I'm sure there are other questions you can ask, but these are the base ones. They cover the often-voluntary parts of development that don't directly benefit the current state of what you wrote. Doing these things significantly increases the credibility of you and your code base.
Calling a spade a spade
This distinction between a DIY developer and all the other colourful names we've come up with over the years allows vibe coding and improper coding practices to be differentiated, so that a vibe coder isn't immediately met with frowns and uneasy looks. Again, this isn't to say the practice of DIY development is wrong, but we should start differentiating between:
Professional software development — using skill and tools to build everything as you code: tests, documentation, clean structure, and so on.
DIY software development — building for the immediate use case, assuming no one else will ever work on it, with no consideration for expansion.
I've kept things agnostic on the use of AI here, as both professionals and DIY developers can use it. I hope that with this in mind we can start using more specific phrases like DIY vibe coded software, professionally vibe coded software, or even just professional software development versus DIY software development. My goal is to encourage the use of 'DIY' within tech and software development — not in the hopes of gauging someone's skill, but so we know what to expect before we even open a code base, which would in turn create a healthier and more supportive environment for developers.
Top comments (0)