Old carpentry workshop with hand tools hanging on a wooden wall
Photo by Ricky Kharawala on Unsplash

Most people I know put wallpaper up in their own house, do small to medium jobs in and around the house themselves and only hire out to a crafts(wo)man when the job is too big or takes too much time. But doing stuff yourself is more or less normalised: it saves money and is fun to do. The same is now true for software engineering: with AI and vibe coding, anyone can build something that works.

That is a genuinely great thing. The DIY movement is a democratising development that put real capability into the hands of ordinary people, created an entire industry around it, and gave millions of people the satisfaction of building something with their own hands.

I also had the pleasure of seeing some really experienced carpenters work up close (30+ years). An interesting observation I made is that they do not seem to work very hard at all. However when you come back an hour later, real progress is made. No movement is wasted, every step is known and the whole workflow is optimised to minimise waste of resources and time. They know in advance how much time a certain job will take, what they need to do it and thus what it will cost.

I have also friends that bought old, badly maintained houses and turned them into small palaces in a few years. There were some hurdles to take and a lot of lessons learned, but the result is beautiful.

So what is the difference? One is a professional, the other is not. But what does that mean? Professional in my book was always someone who got paid to do a job, an amateur could do the same but was not paid for it. However there is a deeper distinction to be made: the diy-er builds for themselves, while the professional builds for others (and gets paid for it)

When evaluating the advent of AI and the impact it has on software engineering you can probably already see the parallel I want to make. AI is a great tool that helps the diy-er to build something really nice, perfectly adapted to what they want. However building for others (professional software engineering) has other demands.

The Software Version of This Story

AI-assisted coding is doing for software what the bouwmarkt (home improvement store, for non-Dutch readers) did for building and home improvement. Not just the tools, but the tools and the advice and the materials, all in one place. An IDE or a linter is a power tool: it makes you faster at what you already know. AI is the whole store: you can walk in knowing nothing and walk out with a plan, the supplies, and enough confidence to get started. And I think that is great.

I wrote about this before: the democratisation of software creation is genuinely exciting. The vibe-coded app that tracks your running schedule or manages your recipe collection or automates your invoicing? Build it. Have fun. Who cares if the code is messy. It works for you, and that is all that matters.

But then the app works so well that a friend wants it. Then a few more people want it. Someone suggests charging for it. And suddenly you are no longer building for yourself.

This is where it gets hard, and it is not about whether you can technically build the software. It is about everything else. When you build for others, you are working with someone else’s idea of what the product should do, not yours. You are responsible for their data, their money, their trust. You have to think about edge cases you would never hit yourself, because your users will hit all of them. You have to maintain it when you would rather be building something new. You carry financial risk if it breaks. You might need to comply with regulations you have never heard of.

More and more I get requests from diy-ers (non-developers, most of them in a company context) that ask me to evaluate their vibe-coded application. Most of the time the functionality is great (for their purposes), but there are a lot of open ends that need to be addressed.

Just as a professional carpenter would do when assessing a job, you need the expertise and the know-how (which goes far beyond the code itself, just as the carpenter knows far more than how to use a handsaw to saw wood) to analyse the situation and decide what is the best course of action: build on top of the application or tear it all down and start with a proper foundation.

It Is Not About Skill

I have made the transition from diy to professional twice. Before software, I worked as a sound engineer. That also started as a hobby: years of messing around with equipment, doing small gigs, learning by doing. The moment I went professional, the job changed. It was no longer about what sounded good to me, it was about what the client needed, on deadline, within budget, with backup plans for when things went wrong. The technical skills were the same, but everything around them was different.

Then I did it again with software. I had been programming for over twenty-five years for myself before making the switch to professional software engineering. The code I wrote as a hobbyist was fine for what it was. But writing code that other people depend on, that needs to run reliably, that handles their data responsibly, that complies with regulations I had never thought about was another game.

So this is not diy being bad and professionals good. Plenty of professional software is terrible and plenty of hobbyist software is brilliant. The distinction is not about ability.

The distinction is about context. When you build for yourself, you optimize for one person’s needs, and you can cut every corner you want because you are the only one who bears the consequences. When you build for others a lot of this changes:

  • It is not your use case anymore, so you have to understand problems you do not personally have
  • You carry responsibility for other people’s data and money
  • You need to comply with rules that do not apply to personal projects (GDPR, accessibility requirements, industry regulations)
  • Financial risk: if it breaks, the cost is not just your time
  • You have to maintain it, even when you have lost interest

A professional software engineer does not just know how to write code. They know how to deal with all of that. How to handle errors that the happy path never reveals. How to design for concurrent users. Where the security boundaries are. What happens at 3 AM when the database fills up and nobody is watching. Not because they are necessarily smarter, but because building for others requires a different kind of thinking.

Where This Is Going

Look at how the construction industry works today. Nobody thinks it is strange that you wallpaper your own living room but call a carpenter for a kitchen renovation. Nobody thinks it is gatekeeping that you need permits and inspections when you build for others. DIY and the professional trades can both exist and are not mutually exclusive.

Software engineering is heading to the same place. People will keep building their own tools with AI, and that is good. But when the stakes go up, when it is someone else’s data, someone else’s money, someone else’s business, they will call in a professional. Not necessarily to write the code, but to assess what was built, identify the risks, and decide whether to build on top of it or start over with a proper foundation. Exactly the way a carpenter assesses a renovation job today.

The evaluation requests I mentioned are the beginning of that pattern. The role of the software engineer is shifting from “the person who writes the code” to “the person who knows whether the code is fit for purpose, and who understands the regulations, compliance, security, and data integrity requirements that come with building for others.” That is a bigger role which requires more expertise, because you need to understand both what was built and what should have been built.

AI will not replace software engineers. It will change what software engineers do.

Wondering whether your vibe-coded application is ready for others to use? Get in touch to find out.