Vibe Coding Isn't the Problem – It's Your Approvals Process
kristopherleads.substack.comAI generated code, where the author doesn't understand the code, shifts the burden of checking quality and function onto the reviewer.
This post says little about that, and suggests some improvements the _reviewer_ can make.
I think that's completely the wrong end of the stick to be tackling. As the burden is still on the reviewer and not the author.
I 100% agree with you that in a perfect world the submitter should be doing the review work. But the reality is that we don't live in a perfect world - and just sticking our fingers in our ears and shouting it's not our job isn't going to make data breaches less common or code better quality. Accordingly, if we accept that we can't make vibe coders better stewards (although I absolutely do think we can help in that regard, and I suggest ways to do that in the post), then we have to do our part of improve it somehow.
Vibe coding is in the news these days, and for largely negative reasons. And in many cases, fair enough - vibe coding has been associated with severe lapses in security, both in terms of the products they create and the platforms used to develop them. For many, vibe coding is just not worth what you get from it - and it’s facing huge pushback in dev spaces.
Here’s the thing though - the problem was never the vibe coding. The problem is the approvals process that allows vibe coded content to proliferate unchecked. This may seem a bit of victim blaming, so let me set an expectation here - if you’re looking for a tech bro to tell you that vibe coding is the future and anyone against it is a luddite, that’s not what this article is about. I don’t think vibe coding is the best thing since sliced bread - but I also don’t think it’s the worst thing to happen in development.
What I do think it has done, however, is expose some critical flaws in the way that software - especially open-source software - gets built and released.
So let’s talk about that.