Vibe coding is the new macro recorder

I saw a lovely analogy from Eugene Meidinger on BlueSky the other day

“Vibe-maintaining an app is like cleaning with a dirty mop. No matter how hard you try, you seem to leave a layer of dirt and filth”

Cast your mind back to the first time you discovered the macro recorder in Excel.

You clicked a few buttons. Excel watched. Then it handed you a block of VBA code that somehow did exactly what you had just done.

Most people had no idea what that code actually meant. But it didn’t matter. The macro recorder wasn’t valuable because it produced elegant code. It was valuable because it collapsed the distance between having an idea and building something.

I seems to me that Vibe coding is today’s version of that moment.

Instead of recording mouse clicks, you describe intent. “Build me a dashboard”,  “Create a customer churn model” , “Build a web app that tracks inventory” The AI generates the code. The tool handles the implementation. You remain focused on the problem you are trying to solve.

Where the analogy holds

The macro recorder democratised automation for millions of Excel users who were never going to become VBA developers. Most of them stayed at that level, and that was fine. They became more productive. Their organisations benefited, and it worked well while they were there to run the code and fix the bugs .

A small proportion, like me, went further. They opened the VBA editor, started poking around, and eventually learned to write their own code. The recorder was a gateway to the coding world for me.

Vibe coding follows the same pattern. Not everyone who uses it will become a software engineer. But many more people will become builders. They will automate processes, prototype ideas, and create tools that would previously have required a developer and a project budget.

Where the analogy breaks down

Here is where it gets more interesting, and where the debate is worth having.

The macro recorder had a critical feature: it showed you the code. You could press F8 and step through it line by line seeing what happens. Yes, the generated VBA was usually terrible.  It was overly verbose, fragile, full of unnecessary Select and Activate calls. But it was visible. You could read it, question it, and gradually learn from it.

Many vibe coding tools keep the implementation invisible. The interaction now is: prompt, solution, prompt, solution without the user ever seeing what code was actually built. That creates a number of distinct risks.

1. Hidden technical debt. With VBA, you could at least inspect the mess. AI-generated applications can carry security vulnerabilities, poor architecture, duplicated logic, and dependencies nobody understands.
2. False confidence. The macro recorder never pretended to be intelligent. Everyone knew they were recording clicks. AI can create the impression that because the code works, it must be good. Those are very different things.
3. Knowledge that does not compound. A person who recorded macros often then started tweaking the code and became meaningfully better at Excel automation. A person who vibe-codes 100 applications may not become better at software engineering unless they actively inspect, question, and refine what gets generated. But that costs time and money, is there scope for that?
4. Maintenance becomes the real problem. The question is not whether AI can build an app in two hours. It is whether someone can confidently modify that app in a few years when the original creator has moved on.

The counterargument worth taking seriously

Many Excel users created genuinely useful VBA solutions for years without understanding every line they were running. Their organisations still benefited enormously.

Apply the same logic to vibe coding and the argument shifts. Most business processes are never automated today. A messy AI-built solution may be substantially better than no solution at all. AI can also potentially explain, document, and edit its own code over time in ways that VBA never could.

So the honest comparison may not be vibe coding versus understanding the underlying code, it may be vibe coding versus a process that doesn’t happen because it takes too long / is too complex to build from first principals. In that comparison, does vibe coding win?

There is one significant difference underlying all this. The macro recorder was free. It shipped with Excel, with no usage meter running in the background. Vibe coding runs on tokens, and those costs accumulate. A one-off prototype costs very little, but every iteration, refinement, and minor tweak carries a price. That is a cost consideration the macro recorder never triggered.

The question

Is vibe coding a worse version of the Excel Macro recorder that will leave a sea of technical debt everywhere in future years, or will it become so easy to vibe code a new solution / fix a bug that long term robustness becomes irrelevant?

The macro recorder generated poor code, but it exposed that code and gave curious people a way in. Vibe coding can generate far more sophisticated solutions, but it also risks uncontrolled cost and hiding complexity from the very people who depend on it.